Zyxel tűzfal [VPN Routing] - A forgalom átirányítása a VPN alagútból egy másik VPN oldalra [VPN Routing]

Ez a cikk elmagyarázza, hogyan lehet a forgalmat egy helyközi alagútból egy másik alagútba irányítani, hogy elérje a helyközi kapcsolat mögötti eszközöket. Elmagyarázza, hogyan lehet a forgalmat az A oldalról a B oldalra irányítani a HQ tűzfalon/átjárón keresztül (oldalról oldalra történő irányítás oldalról oldalra történő alagúton keresztül), problémák/problémák elhárítása, útválasztási szabályok, ha azt szeretné, hogy az ügyfél VPN-jei elérjenek egy másik oldalon található kiszolgálót (ügyfélről oldalra történő irányítás oldalról oldalra történő irányításon keresztül), SecuExtender IPSec konfiguráció.

1. alternatíva: A forgalom átirányítása a távoli VPN-alagútból egy másik site-to-site VPN-be

1) VPN-alagutak beállítása

Előfeltétel: A telephelyek közötti kapcsolatnak már létre kell jönnie.

Miután az alagút létrejött, L2TP over IPSec segítségével fogjuk összekapcsolni.

A VPN beállítására vonatkozó utasításokat lásd:

VPN - IPSec Site-To-Site VPN konfigurálása

Az L2TP az IPSec-en keresztül című dokumentumban talál információkat:

VPN - L2TP over IPSec VPN konfigurálása PSK használatával [Stand-alone mód]

A folyamat egyszerűsítése érdekében használhatja a varázslót a VPN-alagút és az L2TP over IPSec létrehozásához.

2) Útválasztási házirendek konfigurálása

A főhadiszállás (HQ) és a B oldal közötti forgalom engedélyezéséhez házirendeket és útvonalakat kell beállítania a VPN-alagúthoz.

A főhadiszállás tűzfalán:

1. Hozzon létre egy házirend-útvonalat, amely az L2TP-alagútból érkező kérelmeket a B webhely alagútjába irányítja. Ez az L2TP-alagútból a HQ tűzfalon keresztül a bejövő kéréseket a B webhely alagútjába irányítja.

   • Forrás: A Hálózaton keresztül a következő útvonalakat kell létrehozni: A Hálózaton keresztül a következő útvonalakat kell létrehozni: L2TP-ügyfél alhálózat
   • Cél: Site B alhálózat
   • Következő ugrás: VPN-alagút "B oldal alagút"

Vegyük észre, hogy a Célcím az ügyfelünk címe.

2. Hozzon létre egy házirendet, amely engedélyezi a B oldalról érkező válaszokat, és továbbítja azokat az alagútba a B oldalra. Ez a B oldalról a központba visszatérő forgalom szempontjából kulcsfontosságú.

• • Forrás: A HQ HQ-nak és a HQ-nak a HQ-ról történő átirányítása: Bármelyik
  • Cél: L2TP alagút
  • Következő ugrás: VPN-alagút "L2TP-alagút"

A B oldalon:

1. Hozzon létre egy olyan házirend-útvonalat is, amely engedélyezi a központból érkező kéréseket, és továbbítja azokat az alagútba a B oldalra:

Győződjön meg róla, hogy az aszimmetrikus útválasztás engedélyezve van a zökkenőmentes kapcsolat érdekében. Ezt az opciót itt találja:

Konfiguráció > Biztonsági házirend > Házirend-szabályozás

A funkció engedélyezése aktiválja a "háromszög útvonalat", lehetővé téve a tűzfal számára, hogy aszimmetrikus útvonal topológiát használjon a hálózatban, és megakadályozza a kapcsolat visszaállítását, amikor a válaszok visszajönnek.

A fenti lépések betartásával hatékonyan irányíthatja a forgalmat a VPN-alagutak között, és zökkenőmentes és biztonságos kapcsolatot tarthat fenn a főhadiszállás és a B helyszín között.

2. alternatíva: Útválasztás a VPN-alagútból egy másik VPN-helyszínre

1) Az A oldalról a B oldalra irányuló forgalom átirányítása a főhadiszálláson keresztül.

Ha azt szeretné, hogy az A webhely elérje a B webhelyet és fordítva, akkor mindkét tűzfalon létre kell hoznia házirend-útvonalakat, hogy a HQ tűzfal tudja, hová küldje a beérkező kéréseket, és hová küldje a válaszokat is.

1.1 Házirend útvonalak - HQ tűzfal

A HQ tűzfalon először is be kell állítania egy szabályt, amely engedélyezi az A oldalról érkező kéréseket, amelyek a B oldalra mennek. Ezeket az alagútban kell továbbítani a B oldalra, és ez fontos mind az ICMP kérések (amelyek az A oldalról érkeznek), mind az ICMP válaszok (amelyek a B oldalról érkeznek, és most ismét a B oldalra mennek vissza) esetében.

Bejövő: bármilyen - Forrás: - A bejövő: bármilyen: "Site A subnet" -> Destination: "Site B subnet" - Next-hop Tunnel - "Site B VPN-alagút"

Másodszor, be kell állítania egy szabályt, amely engedélyezi a B oldalról érkező válaszokat, amelyek az A oldalra mennek (amikor az A oldalról küldött kérést), és ezeket az A oldal alagútjába kell irányítani. Ez mind az ICMP kérések (a B oldalról érkező), mind az ICMP válaszok (a B oldalról érkező és most ismét az A oldalra visszamenő) esetében fontos.

Bejövő: bármilyen - Forrás: - Forrás: "Site B subnet" -> Destination: "A webhely A alhálózat" - Következő megálló alagút - "A webhely A VPN-alagút"

1.2 Házirend útvonalak - A webhely tűzfala

Ezután be kell állítania egy olyan szabályt, amely engedélyezi a B oldalról érkező kéréseket, amelyek az A oldalra mennek (amikor a B oldalról küldött kérést). Ezeket"vissza" kell irányítani a Site A alagútba, és ez fontos mind az ICMP-kérelmek (amelyek a Site B oldalról érkeznek), mind az ICMP-válaszok (amelyek a Site B oldalról érkeznek, és most ismét a Site B oldalra mennek vissza) esetében.

Bejövő: bármilyen - Forrás: - Forrás: "Site B subnet" -> Destination: "A webhely A alhálózat" - Következő megálló: "A webhely A VPN-alagút".

1.3 Házirend útvonalak - B oldal tűzfala

Ezután be kell állítania egy olyan szabályt, amely engedélyezi az A webhelyről érkező, a B webhelyre irányuló kéréseket (amikor az A webhelyről küldött kérést). Ezeket"vissza" kell irányítani a Site B alagútba, és ez fontos mind az ICMP-kérelmek (amelyek az A oldalról érkeznek), mind az ICMP-válaszok (amelyek az A oldalról érkeznek, és most ismét az A oldalra mennek vissza) esetében.

Bejövő: bármilyen - Forrás: - Forrás: "Site A subnet" -> Destination: "Site B subnet" - Next-hop "Site B VPN-alagút"

2) Ellenőrzés / hibaelhárítás

Miután az összes házirend útvonalat konfigurálta, fontos ellenőrizni, hogy az útválasztás valóban működik-e. Lehet, hogy a tűzfalszabályokban ellentmondásos útvonalak vannak (alhálózati átfedések, meglévő házirend/statikus útvonalak stb.), vagy valami más baj van.

Vegye figyelembe, hogy ez nagyon zavaros lehet, mivel sok útvonalra kell ügyelnie. A legegyszerűbb módja ennek, ha kézzel feltérképezzük az összes csomagáramlást egy papíron (PC -> A átjáró - az átjárónak a központba kell továbbítania, a központnak a B telephelyre kell továbbítania - a B telephelynek a választ ismét vissza kell továbbítania a központba ... stb.), és feltesszük a kérdést: "ki a felelős az útválasztásért, és megvan-e az útválasztás?".

Az alábbiakban két olyan forgatókönyvet talál, ahol a konfigurációkat módosítani kell ahhoz, hogy az útválasztás működjön.

2.1 Tesztelés a tűzfal pingelésével

Az első a tesztelés az A webhelyen lévő PC-ről a B webhelyen lévő kiszolgálóra vagy PC-re történő pingeléssel:

Piros nyíl - ICMP [ping] kérés

Zöld nyíl - ICMP [ping] válasz

2.2mRendszer útvonalak - A webhely tűzfala

Ha a Site B átjárót pingeli a Site A átjáróról (beépített ICMP eszköz), akkor a Site A házirend útválasztása nem vonatkozik a Site B-től visszaérkező válaszokra, ha a Site B megpróbálja pingelni a Site A átjárót.

Ezért szükségünk van egy olyan házirend-útvonalra, amely így néz ki:

Bejövő: ZyWall- Source: "Site B subnet" -> Destination: "A webhely A alhálózat" - Következő megálló: "A webhely VPN-alagút"

2.3 Házirend útvonalak - B oldal tűzfala

Az első teszt, amit elvégezhet, az a tűzfal pingelése, azonban mivel a most létrehozott útválasztás CSAK a bejövő bármelyikre vonatkozik (kivéve a Zywallt), ez azt jelenti, hogy az útválasztás nem fog érvényesülni, ha a ping az A oldalról érkezik, eléri a B oldal tűzfalát, majd a tűzfal felel a kérésre való válaszadásért. Az ICMP-válasz így fog kinézni:

ICMP-kérelem

PC (ICMP-kérelem) -> A webhely átjárója -> VPN-alagút a központba -> a központ átjárója forgalmat küld a B webhely átjárójának.

ICMP válasz

Site B Gateway (ICMP válasz) -> Site B Gateway -> VPN alagút a HQ-hoz -> HQ Gateway forgalmat küld a Site A Gateway-nek -> Site A Gateway csomagokat küld vissza a PC-nek.

Ezért van szükség erre a házirend útvonalra:

Bejövő: ZyWall- Source: "Site A subnet" -> Destination: "Site B subnet" - Következő megálló "Site B VPN-alagút"

2.4 Tesztelés egy szerver / PC pingelésével

Mivel a PC a 192.168.20.0/24 hálózaton található, a szerver pedig a 192.168.30.0/24 hálózaton, a szerver nem ismeri fel a 192.168.20.0/24 hálózatot, ezért nagy valószínűséggel blokkolni fogja az ismeretlen alhálózatokból érkező ICMP csomagokat. Ezért a tesztek elvégzésekor mindig:

• Kapcsoljon ki minden beépített tűzfalat (pl. Windows Defender / tűzfal).
• Kapcsolja ki a szerverre/számítógépre telepített egyéb vírusirtó és végponti biztonsági szoftvereket.

Az ügyféltől a telephelyre irányuló forgalom Site-to-Site alagúton keresztül történő átirányítása

Figyelem! Ez nem működik a Dynamic VPN-nél! Kérjük, csak a Site2Site VPN-t válassza!

1) A SecuExtender IPSec VPN konfigurálása

Ahhoz, hogy az IPSec VPN-ügyfeleket egy másik alagútba irányítsa, fix IP-címeket kell használniuk.

Ha sok különböző klienst kell átirányítani, akkor ajánlott olyan IP-címeket használni, amelyek közel vannak egymáshoz, így egy tartományt lehet létrehozni. Ez csökkenti a szükséges útvonalak számát.

Az alhálózatnak, amelyben az IP-címek találhatók, nem kell jelen lennie a tűzfalon.

Adja meg a rögzített IP-címet az IPSec VPN-ügyfélen.

2) Tűzfal útválasztás konfigurálása

A tűzfalon navigáljon a

és kattintson a

az IPSec VPN-ügyfél IP-címek tartományának létrehozásához.

Most már hozzáadhatjuk a szükséges útvonalakat a

egy kattintással a

2.1 A helyszínen A tűzfal

Két útvonalat kell létrehoznunk:

• Az egyiket a kimenő forgalomhoz, tehát a dinamikus VPN-kliens alagútból a távoli alhálózatba a helyközi alagúton keresztül.

• Egy a bejövő forgalomra, tehát a távoli alhálózatról a helyközi alagúton keresztül a VPN-kliens alagútba.

Az új útvonalaknak ehhez hasonlóan kell kinézniük:

A távoli alhálózatról a távoli VPN-alagúton keresztül bejövő forgalom másik módja az "aszimmetrikus útvonal" engedélyezése:

Ez engedélyezi a "háromszög" útvonalat, amely lehetővé teszi, hogy a tűzfal engedélyezze az aszimmetrikus útvonal topológia használatát a hálózatban, és ne állítsa vissza a kapcsolatot, amikor a válasz visszajön.

2.2 A B oldalon lévő tűzfal

A távoli telephelyen szükség lehet hasonló útvonalak létrehozására, hogy a fő telephelyen lévő eszköz tudja, hogyan kezelje a fióktelepről érkező VPN-ügyfelek forgalmát.

A főhadiszálláson létrehozzuk a távoli VPN-ügyfelek IP-tartományát, hogy azt használhassuk a forgalom továbbítására.

Most létrehozzuk a megfelelő útvonalakat a főhadiszálláson is.

Egy kimenő útvonal, tehát a HQ alhálózatból a telephelyek közötti alagúton keresztül a távoli VPN-ügyfelekhez.

És egy bejövő útvonal, tehát a távoli VPN-kliensek tartományából a site-to-site alagúton keresztül a főhadiszállás helyi LAN-jába. Ha a forgalmat egy helyi alhálózatba irányítjuk, akkor next-hopként az "Auto"-t választjuk, ezt az USG automatikusan kezeli.

Az útvonalaknak valahogy így kell kinézniük:

+++ A Zyxel VPN klienseihez (SSL VPN, IPsec) licenceket vásárolhat azonnali szállítással, 1 kattintással: Zyxel Webstore +++