Zyxel Firewall [VPN Routing] - Routing af trafik fra VPN-tunnel til et andet VPN-site [VPN Routing].

Denne artikel forklarer, hvordan man router trafik fra en site-to-site-tunnel ind i en anden tunnel for at nå enheder bag en site-to-site-forbindelse. Den forklarer, hvordan man router trafik fra site A til site B gennem HQ firewall / gateway (route site-to-site through site-to-site tunnel), fejlfinding af problemer, routingregler, hvis du vil have dine klient-VPN'er til at nå en server, der er placeret på et andet site (client-to-site through site-to-site), SecuExtender IPSec-konfiguration.

Alternativ 1: Routing af trafik fra Remote VPN-tunnel til en anden site-to-site VPN

1) Opsætning af VPN-tunneller

Forudsætning: Der skal allerede være etableret en site-to-site-forbindelse mellem lokationerne.

Når tunnelen er etableret, vil vi forbinde den ved hjælp af L2TP over IPSec.

For instruktioner om, hvordan du opretter en VPN, se venligst:

VPN - Konfigurer IPSec Site-To-Site VPN

Du kan finde oplysninger om L2TP over IPSec:

VPN - Konfigurer L2TP over IPSec VPN ved hjælp af PSK [Stand-alone-tilstand].

For at forenkle processen kan du bruge guiden til at oprette en VPN-tunnel og L2TP over IPSec.

2) Konfiguration af Routing-politikker

For at tillade trafik mellem hovedkvarteret (HQ) og Site B, skal du opsætte politikker og ruter for VPN-tunnelen.

På hovedkvarterets firewall:

1. Opret en politikrute, der dirigerer indgående anmodninger fra L2TP-tunnelen til Site B-tunnelen. Dette er routning af indgående anmodninger fra L2TP-tunnelen gennem HQ Firewall til Site B-tunnelen

   • Kilde: L2TP-klientens undernet
   • Destination: Site B-undernet
   • Næste hop: VPN-tunnel "Site B-tunnel"

Bemærk, at destinationsadressen er vores klients adresse.

2. Opret en politik, der tillader svar fra Site B og dirigerer dem ind i tunnelen til Site B. Dette er afgørende for trafikken, der returnerer fra Site B til HQ.

• • Kilde: Enhver
  • Destination: L2TP-tunnel
  • Næste hop: VPN-tunnel "L2TP-tunnel"

På websted B:

1. Opret også en politikrute, der tillader indgående anmodninger fra hovedkvarteret og sender dem videre i tunnelen til Site B. Opret også en politikrute, der tillader svar fra hovedkvarteret og sender dem videre i tunnelen til Site B:

Sørg for, at Asymmetric Routing er aktiveret for problemfri forbindelse. Du kan finde denne indstilling her:

Konfiguration > Sikkerhedspolitik > Politikkontrol

Aktivering af denne funktion aktiverer den "trekantede" rute, så firewallen kan bruge en asymmetrisk rutetopologi i netværket og forhindre nulstilling af forbindelsen, når svarene kommer tilbage.

Ved at følge disse trin kan du effektivt dirigere trafikken mellem dine VPN-tunneller og opretholde en jævn og sikker forbindelse mellem hovedkvarteret og Site B.

Alternativ 2: Routing fra VPN-tunnel til et andet VPN-site

1) Rute trafik fra Site A til Site B gennem HQ Site

Hvis du vil have Site A til at nå Site B og omvendt, skal du oprette policy routes på hver firewall for at lade HQ firewall vide, hvor de skal sende de forespørgsler, der kommer ind, og hvor de også skal sende svarene hen.

1.1 Politikruter - HQ Firewall

På HQ-firewallen skal du først konfigurere en regel, der tillader forespørgsler fra Site A, der skal til Site B. De skal dirigeres i tunnelen til Site B, og det er vigtigt både for ICMP-forespørgsler (der kommer fra Site A), men også for ICMP-svar (der kommer fra Site B og nu skal tilbage til Site B igen).

Indgående: enhver - Kilde: "Site A subnet" -> Destination: "Site B subnet" - Next-hop Tunnel - "Site B VPN tunnel"

For det andet skal du konfigurere en regel, der tillader svar fra Site B, der går til Site A (når du har sendt en anmodning fra Site A), og de skal dirigeres ind i Site A-tunnelen. Dette er vigtigt både for ICMP-anmodninger (der kommer fra Site B), men også for ICMP-svar (der kommer fra Site B og nu går tilbage til Site A igen).

Indgående: enhver - Kilde: "Site B subnet" -> Destination: "Site A subnet" - Next-hop Tunnel - "Site A VPN tunnel"

1.2 Policy-ruter - Firewall på site A

Derefter skal du konfigurere en regel, der tillader forespørgsler fra Site B, der skal til Site A (når du har sendt en forespørgsel fra Site B). De skal dirigeres"tilbage" i Site A-tunnelen, og det er vigtigt både for ICMP-anmodninger (der kommer fra Site B), men også for ICMP-svar (der kommer fra Site B og nu skal tilbage til Site B igen).

Indgående: enhver - Kilde: "Site B subnet" -> Destination: "Site A subnet" - Next-hop "Site A VPN tunnel"

1.3 Policy-ruter - Firewall på Site B

Derefter skal du konfigurere en regel, der tillader anmodninger, der kommer fra Site A, og som skal til Site B (når du har sendt en anmodning fra Site A). De skal dirigeres"tilbage" i Site B-tunnelen, og det er vigtigt både for ICMP-anmodninger (der kommer fra Site A), men også for ICMP-svar (der kommer fra Site A og nu går tilbage til Site A igen).

Indgående: enhver - Kilde: "Site A subnet" -> Destination: "Site B subnet" - Next-hop "Site B VPN tunnel"

2) Verifikation / fejlfinding

Når du har konfigureret alle policy-ruterne, er det vigtigt at verificere, at routingen rent faktisk fungerer. Måske har du modstridende ruter i dine firewall-regler (subnet-overlap, eksisterende policy/statiske ruter osv.), eller også er der noget andet galt.

Bemærk, at dette kan være meget forvirrende, da der er mange ruter, som du skal tage dig af. Den nemmeste måde at gøre det på er manuelt at kortlægge alle pakkeflow på et stykke papir (PC -> Gateway A - gateway skal route til HQ, HQ skal route til Site B - Site B skal route svaret tilbage til HQ igen ... etc.), spørg dig selv - "hvem er ansvarlig for routing, og er routing på plads?".

Nedenfor finder du to scenarier, hvor du måske er nødt til at ændre konfigurationer for at få routingen til at fungere.

2.1 Test ved at pinge firewallen

Det første er at teste ved at pinge fra en pc på Site A til en server eller pc på Site B:

Rød pil - ICMP [ping]-anmodning

Grøn pil - ICMP [ping]-svar

2.2mPolitikruter - Firewall på websted A

Hvis du pinger Site B Gateway fra Site A Gateway (indbygget ICMP-værktøj), vil policy routing på Site A ikke gælde for svarene tilbage fra Site B, hvis Site B forsøger at pinge Site A Gateway.

Derfor har vi brug for en policy route, der ser sådan her ud:

Indgående: ZyWall- Kilde: "Site B subnet" -> Destination: "Site A subnet" - Next-hop "Site A VPN tunnel"

2.3 Policy-ruter - Firewall på Site B

Den første test, du kan udføre, er at pinge firewallen, men fordi den routing, du nu har oprettet, KUN gælder for indgående (ekskl. Zywall), betyder det, at routingen ikke gælder, hvis pingen kommer fra Site A, når Site B Firewall, og firewallen derefter er ansvarlig for at svare på anmodningen. ICMP-svaret vil så se sådan ud:

ICMP-forespørgsel

PC (ICMP-forespørgsel) -> Site A Gateway -> VPN-tunnel til HQ -> HQ Gateway sender trafik til Site B Gateway

ICMP-svar

Site B Gateway (ICMP Reply) -> Site B Gateway -> VPN-tunnel til HQ -> HQ Gateway sender trafik til Site A Gateway -> Site A Gateway sender pakker tilbage til PC'en

Derfor er der brug for denne policy-rute:

Indgående: ZyWall- Kilde: "Site A subnet" -> Destination: "Site B subnet" - Next-hop "Site B VPN tunnel"

2.4 Test ved at pinge en server / pc

Fordi pc'en er placeret på 192.168.20.0/24-netværket, og serveren er placeret på 192.168.30.0/24-netværket, genkender serveren ikke 192.168.20.0/24-netværket, og derfor vil serveren med stor sandsynlighed blokere ICMP-pakker, der kommer fra ukendte subnet. Når du udfører tests, skal du derfor altid:

• Deaktivere enhver indbygget firewall (f.eks. Windows Defender / Firewall)
• Deaktiver andre antivirus- og end-point security-softwares, der er installeret på serveren/pc'en.

Rute klient-til-site-trafik gennem en site-til-site-tunnel

Vær opmærksom på dette: Dette virkede ikke med Dynamic VPN! Vælg venligst kun Site2Site VPN!

1) Konfigurer SecuExtender IPSec VPN

For at kunne route IPSec VPN-klienter ind i en anden tunnel, skal de bruge faste IP-adresser.

Hvis det er nødvendigt at route mange forskellige klienter, anbefales det at bruge IP'er, der ligger tæt på hinanden, så der kan oprettes et interval. Det reducerer antallet af nødvendige ruter.

Det undernet, som IP-adresserne befinder sig i, behøver ikke at være til stede på firewallen.

Indtast den faste IP-adresse på IPSec VPN-klienten

2) Konfigurer firewall-rutning

På firewallen skal du navigere til

og klik på

for at oprette området for IPSec VPN-klientens IP-adresser.

Nu kan vi tilføje de nødvendige ruter under

med et klik på

2.1 Firewall på stedet

Vi skal oprette to ruter:

• En til den udgående trafik, altså fra den dynamiske VPN-klienttunnel til det eksterne subnet via site-to-site-tunnelen.

• En til den indgående trafik, altså fra det eksterne subnet over site-to-site-tunnelen ind i VPN-klienttunnelen.

De nye ruter bør se sådan ud:

Du kan aktivere "asymmetrisk rute" på en anden måde, så den indgående trafik fra det eksterne subnet over den eksterne VPN-tunnel kan passere:

Dette vil aktivere "triangle"-ruten, som får firewallen til at tillade brugen af asymmetrisk rutetopologi i netværket og ikke nulstille forbindelsen, når svaret kommer tilbage.

2.2 Firewall på site B

På fjernsitet kan det være nødvendigt at oprette lignende ruter, så enheden på hovedsitet ved, hvordan den skal håndtere trafikken fra VPN-klienterne, der kommer fra filialsitet.

På hovedkontoret opretter vi IP-området for de eksterne VPN-klienter, så vi kan bruge det til at dirigere trafikken.

Nu opretter vi også de tilsvarende ruter på HQ-sitet.

En udgående rute, altså fra hovedkvarterets subnet over site-to-site-tunnelen til de eksterne VPN-klienter.

Og en indgående rute, så fra det eksterne VPN-klientområde over site-to-site-tunnelen ind i HQ's lokale LAN. Hvis trafikken dirigeres ind i et lokalt subnet, vælger vi "Auto" som next-hop, USG administrerer dette automatisk.

Ruterne skal se nogenlunde sådan her ud:

+++ Du kan købe licenser til dine Zyxel VPN-klienter (SSL VPN, IPsec) med øjeblikkelig levering med 1 klik: Zyxel Webstore +++