Viktig merknad: |
Denne artikkelen forklarer hvordan du ruter trafikk fra en site-to-site-tunnel til en annen tunnel for å nå enheter bak en site-to-site-tilkobling. Den forklarer hvordan du ruter trafikk fra sted A til sted B gjennom HQ-brannmur/gateway (rute sted-til-sted gjennom sted-til-sted-tunnel), feilsøking av problemer, rutingsregler hvis du vil at klient-VPN-ene dine skal nå en server som befinner seg på et annet sted (klient-til-sted gjennom sted-til-sted), SecuExtender IPSec-konfigurasjon.
Alternativ 1: Ruting av trafikk fra ekstern VPN-tunnel til et annet site-to-site-VPN
1) Sette opp VPN-tunneler
Forutsetning: En site-to-site-tilkobling mellom lokasjonene må allerede være etablert.
Når tunnelen er etablert, kobler vi den sammen ved hjelp av L2TP over IPSec.
For instruksjoner om hvordan du setter opp et VPN, se:
VPN - Konfigurere IPSec VPN fra sted til sted
Du finner informasjon om L2TP over IPSec:
VPN - Konfigurer L2TP over IPSec VPN ved hjelp av PSK [frittstående modus].
For å forenkle prosessen kan du bruke veiviseren for å opprette en VPN-tunnel og L2TP over IPSec.
2) Konfigurere retningslinjer for ruting
For å tillate trafikk mellom hovedkontoret (HQ) og Site B må du konfigurere retningslinjer og ruter for VPN-tunnelen.
På hovedkvarterets brannmur:
-
Opprett en policyrute som ruter innkommende forespørsler fra L2TP-tunnelen til Site B-tunnelen. Dette er ruting av innkommende forespørsler fra L2TP-tunnelen gjennom HQ-brannmuren til Site B-tunnelen
- Kilde: L2TP-klientens undernett
- Destinasjon: Site B-undernett
- Neste hopp: VPN-tunnel "Site B-tunnel"
Legg merke til at destinasjonsadressen er vår klients adresse.
2. Opprett en policy som tillater svar fra Site B og ruter dem inn i tunnelen til Site B. Dette er avgjørende for trafikken som returnerer fra Site B til hovedkontoret.
-
- Kilde: Hvilken som helst
- Destinasjon: L2TP-tunnel
- Neste hopp: VPN-tunnel "L2TP-tunnel"
På nettsted B:
-
Opprett også en policyrute som tillater innkommende forespørsler fra hovedkontoret og videresender dem i tunnelen til Site B. Opprett også en policyrute som tillater svar fra hovedkontoret og videresender dem i tunnelen til Site B:
Sørg for at Asymmetric Routing er aktivert for sømløs tilkobling. Du finner dette alternativet her:
Konfigurasjon > Sikkerhetspolicy > Policykontroll
Hvis du aktiverer denne funksjonen, aktiveres den "trekantede" ruten, slik at brannmuren kan bruke en asymmetrisk rutetopologi i nettverket og forhindre at tilkoblingen tilbakestilles når svarene kommer tilbake.
Ved å følge disse trinnene kan du effektivt rute trafikk mellom VPN-tunnelene og opprettholde en smidig og sikker forbindelse mellom hovedkontoret og Site B.
Alternativ 2: Ruting fra VPN-tunnel til et annet VPN-nettsted
1) Rute trafikk fra område A til område B via hovedkontoret
Hvis du vil at Site A skal nå Site B og omvendt, må du opprette policyruter på hver brannmur for å fortelle hovedbrannmuren hvor den skal sende forespørslene som kommer inn, og hvor den skal sende svarene.
1.1 Policyruter - HQ-brannmur
På HQ-brannmuren må du først konfigurere en regel som tillater forespørsler fra Site A som skal til Site B. Disse må rutes i tunnelen til Site B, og dette er viktig både for ICMP-forespørsler (som kommer fra Site A), men også for ICMP-svar (som kommer fra Site B og nå skal tilbake til Site B igjen).
Innkommende: hvilken som helst - Kilde: "Site A subnet" -> Destinasjon: "Site B subnet" - Next-hop Tunnel - "Site B VPN tunnel"
For det andre må du konfigurere en regel som tillater svar fra Site B som skal til Site A (når du har sendt en forespørsel fra Site A), og disse må rutes inn i Site A-tunnelen. Dette er viktig både for ICMP-forespørsler (som kommer fra Site B), men også for ICMP-svar (som kommer fra Site B og nå skal tilbake til Site A igjen).
Innkommende: hvilken som helst - Kilde: "Site B subnet" -> Destinasjon: "Site A subnet" - Next-hop Tunnel - "Site A VPN tunnel"
1.2 Policy-ruter - Nettsted A-brannmur
Deretter må du konfigurere en regel som tillater forespørsler fra Site B som skal til Site A (når du har sendt en forespørsel fra Site B). Disse må rutes"tilbake" inn i Site A-tunnelen, og dette er viktig både for ICMP-forespørsler (som kommer fra Site B), men også for ICMP-svar (som kommer fra Site B og nå skal tilbake til Site B igjen).
Innkommende: hvilken som helst - Kilde: "Site B subnet" -> Destinasjon: "Site A subnet" - Next-hop "Site A VPN tunnel"
1.3 Policy-ruter - Brannmur for nettsted B
Deretter må du konfigurere en regel som tillater forespørsler fra Site A som skal til Site B (når du har sendt en forespørsel fra Site A). Disse må rutes"tilbake" inn i Site B-tunnelen, og dette er viktig både for ICMP-forespørsler (som kommer fra Site A), men også for ICMP-svar (som kommer fra Site A og nå skal tilbake til Site A igjen).
Innkommende: hvilken som helst - Kilde: "Site A subnet" -> Destinasjon: "Site B subnet" - Next-hop "Site B VPN tunnel"
2) Verifisering / feilsøking
Når du har konfigurert alle policyrutene, er det viktig å verifisere at rutingen faktisk fungerer. Kanskje har du ruter som er i konflikt med hverandre i brannmurreglene (overlapping av delnett, eksisterende policy/statiske ruter osv.), eller det er noe annet som er galt.
Vær oppmerksom på at dette kan være svært forvirrende, ettersom det er mange ruter du må ta hensyn til. Den enkleste måten å gjøre dette på er å kartlegge alle pakkeflytene manuelt på et papir (PC -> Gateway A - gatewayen må rute til hovedkontoret, hovedkontoret må rute til Site B - Site B må rute svaret tilbake til hovedkontoret igjen ... etc.), spør deg selv - "hvem er ansvarlig for ruting, og er rutingen på plass?".
Nedenfor finner du to scenarier der du kanskje må endre konfigurasjonen for at rutingen skal fungere.
2.1 Test ved å pinge brannmuren
Det første er å teste ved å pinge fra en PC på Site A til en server eller PC på Site B:
Rød pil - ICMP [ping]-forespørsel
Grønn pil - ICMP [ping]-svar
2.2mPolitikkruter - Brannmur for område A
Hvis du pinger Site B-gatewayen fra Site A-gatewayen (innebygd ICMP-verktøy), vil ikke policyrutingen på Site A gjelde for svarene fra Site B, hvis Site B prøver å pinge Site A-gatewayen.
Derfor trenger vi en policy-rute som ser slik ut:
Innkommende: ZyWall- Kilde: "Site B subnet" -> Destinasjon: "Nettsted A subnett" - Neste hopp "Nettsted A VPN-tunnel"
2.3 Policy-ruter - Brannmur for nettsted B
Den første testen du kan gjøre er å pinge brannmuren, men siden rutingen du nå har opprettet KUN gjelder for innkommende (unntatt Zywall), betyr det at rutingen ikke vil gjelde hvis pingen kommer fra Site A, når Site B-brannmuren og brannmuren er ansvarlig for å svare på forespørselen. ICMP-svaret vil da se slik ut:
ICMP-forespørsel
PC (ICMP-forespørsel) -> Site A Gateway -> VPN-tunnel til HQ -> HQ Gateway sender trafikk til Site B Gateway
ICMP-svar
Site B-gateway (ICMP-svar) -> Site B-gateway -> VPN-tunnel til HQ -> HQ-gateway sender trafikk til Site A-gateway -> Site A-gateway sender pakker tilbake til PC-en
Derfor er denne policyruten nødvendig:
Innkommende: ZyWall- Kilde: "Site A subnet" -> Destinasjon: "Nettsted B subnett" - Neste hopp "Nettsted B VPN-tunnel"
2.4 Test ved å pinge en server / PC
Fordi PC-en befinner seg på 192.168.20.0/24-nettverket og serveren befinner seg på 192.168.30.0/24-nettverket, gjenkjenner ikke serveren 192.168.20.0/24-nettverket og vil derfor sannsynligvis blokkere ICMP-pakker som kommer fra ukjente undernett. Derfor må du alltid utføre tester:
- Deaktiver alle innebygde brannmurer (f.eks. Windows Defender / brannmur).
- Deaktiver andre antivirus- og sikkerhetsprogrammer som er installert på serveren/PC-en.
Rute klient-til-sted-trafikk gjennom en nettsted-til-sted-tunnel
Vær oppmerksom på dette: Dette fungerte ikke med dynamisk VPN! Velg kun Site2Site VPN!
1) Konfigurere SecuExtender IPSec VPN
For å rute IPSec VPN-klienter inn i en annen tunnel må de bruke faste IP-adresser.
Hvis det er nødvendig å rute mange forskjellige klienter, anbefales det å bruke IP-adresser som ligger nær hverandre, slik at det kan opprettes et område. Dette reduserer antallet nødvendige ruter.
Undernettet som IP-adressene befinner seg i, trenger ikke å finnes på brannmuren.
Angi den faste IP-adressen på IPSec VPN-klienten.
2) Konfigurere brannmurruting
På brannmuren navigerer du til
Configuration > Object > Address
og klikker på
Add
for å opprette området for IPSec VPN-klientens IP-adresser.
Nå kan vi legge til de nødvendige rutene under
Configuration > Network > Routing
med et klikk på
Add
2.1 Brannmur på sted A
Vi må opprette to ruter:
- Én for utgående trafikk, altså fra den dynamiske VPN-klienttunnelen til det eksterne subnettet via site-to-site-tunnelen.
- Én for innkommende trafikk, altså fra det eksterne subnettet via site-to-site-tunnelen til VPN-klienttunnelen.
De nye rutene bør se ut som dette:
Du kan aktivere "asymmetrisk rute" på en annen måte slik at innkommende trafikk fra det eksterne delnettet kan passere via den eksterne VPN-tunnelen:
Dette vil aktivere "trekant"-ruten som gjør at brannmuren tillater bruk av asymmetrisk rutetopologi i nettverket og ikke tilbakestiller tilkoblingen når svaret kommer tilbake.
2.2 Brannmur på område B
På det eksterne nettstedet kan det være nødvendig å opprette lignende ruter slik at enheten på hovedsiden vet hvordan den skal håndtere trafikken fra VPN-klientene som kommer fra filialen.
På hovedkontoret oppretter vi IP-området for de eksterne VPN-klientene slik at vi kan bruke det til å rute trafikken.
Nå oppretter vi tilsvarende ruter på hovedkontoret også.
Én utgående rute, fra hovedkvarterets subnett via site-to-site-tunnelen til de eksterne VPN-klientene.
Og én innkommende rute, altså fra det eksterne VPN-klientområdet via site-to-site-tunnelen til hovedkontorets lokale LAN. Hvis trafikken rutes inn i et lokalt undernett, velger vi "Auto" som next-hop, og USG administrerer dette automatisk.
Rutene bør se omtrent slik ut:
+++ Du kan kjøpe lisenser for dine Zyxel VPN-klienter (SSL VPN, IPsec) med umiddelbar levering med ett klikk: Zyxel Webstore +++

Kommentarer
0 kommentarerLogg på hvis du vil legge inn en kommentar.