Viktigt meddelande: |
Den här artikeln förklarar hur du dirigerar trafik från en site-to-site-tunnel till en annan tunnel för att nå enheter bakom en site-to-site-anslutning. Den förklarar hur man dirigerar trafik från plats A till plats B genom HQ-brandvägg / gateway (dirigera plats-till-plats genom plats-till-plats-tunnel), felsöka problem, dirigeringsregler om du vill att dina klient-VPN ska nå en server som finns på en annan plats (klient-till-plats genom plats-till-plats), SecuExtender IPSec-konfiguration.
Alternativ 1: Routa trafik från Remote VPN-tunnel till en annan site-to-site VPN
1) Konfigurera VPN-tunnlar
Förutsättning: En site-to-site-anslutning mellan platserna måste redan vara upprättad.
När tunneln har upprättats kommer vi att ansluta den med L2TP över IPSec.
För instruktioner om hur du konfigurerar ett VPN, se:
VPN - Konfigurera IPSec Site-To-Site VPN
Du kan hitta information om L2TP över IPSec:
VPN - Konfigurera L2TP över IPSec VPN med PSK [Fristående läge]
För att förenkla processen kan du använda guiden för att skapa en VPN-tunnel och L2TP över IPSec.
2) Konfigurera routningsprinciper
För att tillåta trafik mellan huvudkontoret (HQ) och Site B måste du konfigurera policyer och rutter för VPN-tunneln.
På HQ-brandväggen:
-
Skapa en policyväg som dirigerar inkommande förfrågningar från L2TP-tunneln till Site B-tunneln. Detta dirigerar inkommande förfrågningar från L2TP-tunneln genom HQ-brandväggen till Site B-tunneln
- Källa: L2TP-klientens undernät
- Destination: Site B undernät
- Nästa hopp: VPN-tunnel "Site B tunnel"
Observera att destinationsadressen är vår klients adress.
2. Skapa en policy som tillåter svar från Site B och dirigerar dem in i tunneln till Site B. Detta är avgörande för trafiken som återvänder från Site B till HQ.
-
- Källa: Vilken som helst
- Destination: L2TP-tunnel
- Nästa hopp: VPN-tunnel "L2TP-tunnel"
På plats B:
-
Skapa även en policyväg som tillåter inkommande förfrågningar från huvudkontoret och vidarebefordrar dem i tunneln till Site B. Skapa även en policyväg som tillåter svar från huvudkontoret och vidarebefordrar dem i tunneln till Site B:
Se till att Asymmetric Routing är aktiverat för sömlös anslutning. Du hittar det här alternativet här:
Konfiguration > Säkerhetspolicy > Policykontroll
Om du aktiverar den här funktionen aktiveras den "triangulära" rutten, så att brandväggen kan använda en asymmetrisk ruttopologi i nätverket och förhindra att anslutningen återställs när svaren kommer tillbaka.
Genom att följa dessa steg kan du effektivt dirigera trafik mellan dina VPN-tunnlar och upprätthålla en smidig och säker anslutning mellan huvudkontoret och Site B.
Alternativ 2: Routning från VPN-tunnel till en annan VPN-site
1) Routa trafik från Site A till Site B via HQ Site
Om du vill att Site A ska nå Site B och vice versa måste du skapa policyvägar på varje brandvägg för att låta HQ-brandväggen veta vart den ska skicka förfrågningarna som kommer in, och vart den ska skicka svaren också.
1.1 Policyvägar - HQ-brandväggen
På HQ-brandväggen måste du först konfigurera en regel som tillåter förfrågningar från Site A som ska till Site B. Dessa måste dirigeras i tunneln till Site B, och detta är viktigt både för ICMP-förfrågningar (som kommer från Site A), men också för ICMP-svar (som kommer från Site B och nu går tillbaka till Site B igen).
Inkommande: alla - Källa: "Site A subnet" -> Destination: "Site B subnet" - Next-hop Tunnel - "Site B VPN tunnel"
För det andra måste du konfigurera en regel som tillåter svar från Site B som går till Site A (när du har skickat en begäran från Site A) och dessa måste dirigeras in i Site A-tunneln. Detta är viktigt både för ICMP-förfrågningar (som kommer från Site B), men också för ICMP-svar (som kommer från Site B och nu går tillbaka till Site A igen).
Inkommande: alla - Källa: "Site B subnet" -> Destination: "Site A subnet" - Next-hop Tunnel - "Site A VPN tunnel"
1.2 Policyvägar - Brandvägg för plats A
Sedan måste du konfigurera en regel som tillåter förfrågningar från Site B som går till Site A (när du har skickat en förfrågan från Site B). Dessa måste dirigeras"tillbaka" till Site A-tunneln, och detta är viktigt både för ICMP-förfrågningar (som kommer från Site B) och för ICMP-svar (som kommer från Site B och nu går tillbaka till Site B igen).
Inkommande: alla - Källa: "Site B subnet" -> Destination: "Site A subnet" - Next-hop "Site A VPN tunnel"
1.3 Policyvägar - Brandvägg för plats B
Sedan måste du konfigurera en regel som tillåter förfrågningar från Site A som går till Site B (när du har skickat en förfrågan från Site A). Dessa måste dirigeras"tillbaka" till Site B-tunneln, och detta är viktigt både för ICMP-förfrågningar (som kommer från Site A), men också för ICMP-svar (som kommer från Site A och nu går tillbaka till Site A igen).
Inkommande: alla - Källa: "Site A subnet" -> Destination: "Site B subnet" - Next-hop "Site B VPN tunnel"
2) Verifiering/felsökning
När du har konfigurerat alla policyvägar är det viktigt att verifiera att routingen faktiskt fungerar. Kanske har du motstridiga rutter i dina brandväggsregler (överlappande subnät, befintliga policy/statiska rutter etc.) eller så är det något annat som är fel.
Observera att detta kan vara mycket förvirrande eftersom det finns många rutter som du behöver ta hand om. Det enklaste sättet att göra detta är att manuellt kartlägga alla paketflöden på ett papper (PC -> Gateway A - gateway måste dirigera till HQ, HQ måste dirigera till Site B - Site B måste dirigera svaret tillbaka till HQ igen ... etc.), fråga dig själv - "vem är ansvarig för routning, och är routningen på plats?".
Nedan hittar du två scenarier där du kan behöva ändra konfigurationer för att routingen ska fungera.
2.1 Test genom att pinga brandväggen
Det första är att testa genom att pinga från en PC på Site A till en server eller PC på Site B:
Röd pil - ICMP [ping]-förfrågan
Grön pil - ICMP [ping]-svar
2.2 Policyvägar - Brandvägg för plats B
Det första testet som du kan göra är att pinga brandväggen, men eftersom routingen som du nu har skapat är ENDAST för inkommande any (Exklusive Zywall) så innebär det att routingen inte kommer att gälla om pingen kommer från Site A, når Site B Firewall och sedan är det Firewall som ansvarar för att svara på den förfrågan. ICMP-svaret kommer då att se ut så här:
ICMP-förfrågan
PC (ICMP-förfrågan) -> Site A Gateway -> VPN-tunnel till HQ -> HQ Gateway skickar trafik till Site B Gateway
ICMP-svar
Site B Gateway (ICMP Reply) -> Site B Gateway -> VPN-tunnel till HQ -> HQ Gateway skickar trafik till Site A Gateway -> Site A Gateway skickar paket tillbaka till PC
Därför behövs denna policyväg:
Inkommande: ZyWall- Källa: "Site A subnet" -> Destination: "Site B subnet" - Next-hop "Site B VPN tunnel"
2.3 Policyvägar - Brandvägg för plats A
Om du pingar Site B Gateway från Site A Gateway (inbyggt ICMP-verktyg) kommer policyroutningen på Site A inte att gälla för svaren från Site B, om Site B försöker pinga Site A Gateway.
Därför behöver vi en policyrutt som ser ut så här:
Inkommande: ZyWall- Källa: "Site B subnet" -> Destination: "Site A subnet" - Next-hop "Site A VPN tunnel"
2.4 Test genom pingning av en server / PC
Eftersom datorn finns i nätverket 192.168.20.0/24 och servern finns i nätverket 192.168.30.0/24 känner servern inte igen nätverket 192.168.20.0/24 och kommer därför sannolikt att blockera ICMP-paket som kommer från okända subnät. När du utför tester ska du därför alltid:
- Inaktivera eventuell inbyggd brandvägg (t.ex. Windows Defender/brandvägg)
- Inaktivera andra antivirusprogram och säkerhetsprogram för slutpunkter som är installerade på servern/datorn.
Dirigera klient-till-plats-trafik genom en webbplats-till-plats-tunnel
Uppmärksamhet! Detta fungerade inte med Dynamisk VPN! Vänligen välj endast Site2Site VPN!
1) Konfigurera SecuExtender IPSec VPN
För att IPSec VPN-klienter ska kunna dirigeras in i en annan tunnel måste de använda fasta IP-adresser.
Om det krävs att många olika klienter dirigeras rekommenderas att använda IP-adresser som ligger nära varandra så att ett intervall kan skapas. Detta minskar antalet nödvändiga rutter.
Det subnät som IP-adresserna ligger i behöver inte finnas på brandväggen.
Ange den fasta IP-adressen på IPSec VPN Client
2) Konfigurera routning för brandvägg
På brandväggen navigerar du till
Configuration > Object > Address
och klicka på
dyn_repppp_1för att skapa intervallet för IPSec VPN-klientens IP-adresser.
Nu kan vi lägga till de nödvändiga rutterna under
Configuration > Network > Routing
med ett klick på
dyn_repppp_3
2.1 En brandvägg på plats
Vi behöver skapa två routrar:
- En för den utgående trafiken, dvs. från den dynamiska VPN-klienttunneln till fjärrundernätet via site-to-site-tunneln.
- En för inkommande trafik, dvs. från det fjärranslutna subnätet över site-to-site-tunneln till VPN-klienttunneln.
De nya rutterna bör se ut ungefär så här:
Ett annat sätt för den inkommande trafiken från fjärrundernätet över fjärr-VPN-tunneln att passera är att aktivera "asymmetrisk rutt":
Detta aktiverar "triangel"-rutten som gör att brandväggen tillåter användning av asymmetrisk ruttopologi i nätverket och inte återställer anslutningen när svaret kommer tillbaka.
2.2 Brandvägg på plats B
På fjärrplatsen kan det vara nödvändigt att skapa liknande rutter så att enheten på huvudplatsen vet hur den ska hantera trafiken från VPN-klienterna som kommer från filialplatsen.
På huvudkontoret skapar vi IP-intervallet för de fjärranslutna VPN-klienterna så att vi kan använda det för att dirigera trafiken.
Nu skapar vi motsvarande rutter på huvudkontoret också.
En utgående rutt, så från HQ-subnätet över site-to-site-tunneln till de avlägsna VPN-klienterna.
Och en inkommande rutt, från VPN-klienternas fjärrnät över site-to-site-tunneln till huvudkontorets lokala LAN. Om trafiken dirigeras till ett lokalt subnät väljer vi "Auto" som next-hop, USG hanterar detta automatiskt.
Rutterna bör se ut ungefär så här:
+++ Du kan köpa licenser för dina Zyxel VPN-klienter (SSL VPN, IPsec) med omedelbar leverans med 1 klick: Zyxel Webstore +++