Zyxel Firewall [Rutarea VPN] - Rutarea traficului din tunelul VPN către un alt site VPN [Rutarea VPN]

Acest articol explică cum să direcționați traficul dintr-un tunel site-la-sediu într-un alt tunel pentru a ajunge la dispozitivele din spatele unei conexiuni site-la-sediu. Acesta explică cum să direcționați traficul de la site-ul A către site-ul B prin firewall-ul / gateway-ul HQ (rutare de la site la site prin tunelul de la site la site), depanarea problemelor/problemelor, regulile de rutare dacă doriți ca VPN-urile clienților dvs. să ajungă la un server care se află pe un alt site (client la site prin site la site), configurația IPSec SecuExtender.

Alternativa 1: Rutarea traficului din tunelul VPN la distanță către un alt VPN site-to-site

1) Configurarea tunelurilor VPN

Condiție prealabilă: Trebuie să fie deja stabilită o conexiune de la un site la altul între locații.

După ce tunelul este stabilit, îl vom conecta folosind L2TP peste IPSec.

Pentru instrucțiuni privind modul de configurare a unui VPN, consultați:

VPN - Configurarea VPN-ului IPSec Site-to-Site

Puteți găsi informații despre L2TP prin IPSec:

VPN - Configurarea L2TP peste IPSec VPN utilizând PSK [Mod stand-alone]

Pentru a simplifica procesul, puteți utiliza expertul pentru crearea unui tunel VPN și L2TP over IPSec.

2) Configurarea politicilor de rutare

Pentru a permite traficul între sediul principal (HQ) și Site B, trebuie să configurați politici și rute pentru tunelul VPN.

Pe firewall-ul sediului central (HQ Firewall):

1. Creați o rută de politică care direcționează solicitările primite din tunelul L2TP către tunelul Site B. Aceasta direcționează solicitările primite din tunelul L2TP prin firewall-ul HQ către tunelul Site B

   • Sursă: Subrețea clientului L2TP
   • Destinație: Subrețea Site B
   • Următorul salt: Tunelul VPN "Tunelul site-ului B"

Rețineți că adresa de destinație este adresa clientului nostru.

2. Creați o politică care permite răspunsurile de la Site B și le direcționează în tunelul către Site B. Acest lucru este esențial pentru traficul care se întoarce de la Site B la HQ.

• • Sursă: Orice
  • Destinație: Tunel L2TP
  • Next-hop: Tunel VPN "Tunel L2TP"

Pe site-ul B:

1. De asemenea, creați o rută de politică care să permită cererile primite de la HQ și să le redirecționeze în tunel către Site B. De asemenea, creați o rută de politică care să permită răspunsurile de la HQ și să le direcționeze în tunel către Site B:

Asigurați-vă că rutarea asimetrică este activată pentru o conectivitate perfectă. Puteți găsi această opțiune aici:

Configurație > Security Policy > Policy Control

Activarea acestei funcții activează ruta "triunghiulară", permițând firewall-ului să utilizeze o topologie de rutare asimetrică în rețea și împiedicând resetarea conexiunii atunci când se primesc răspunsuri.

Urmând acești pași, puteți ruta eficient traficul între tunelurile VPN și puteți menține o conexiune sigură și fără probleme între HQ și Site B.

Alternativa 2: Rutarea din tunelul VPN către un alt site VPN

1) Rutați traficul de la site-ul A la site-ul B prin site-ul HQ

Dacă doriți ca Site A să ajungă la Site B și invers, trebuie să creați rute de politici pe fiecare firewall pentru a permite firewall-ului HQ să știe unde să trimită cererile care intră și unde să trimită și răspunsurile.

1.1 Rute de politici - Firewall-ul HQ

Pe firewall-ul HQ, trebuie să configurați mai întâi o regulă care să permită cererile care vin de la Site A și care se îndreaptă către Site B. Acestea trebuie să fie direcționate în tunel către Site B, iar acest lucru este important atât pentru cererile ICMP (care vin de la Site A), cât și pentru răspunsurile ICMP (care vin de la Site B și care acum se întorc din nou la Site B).

Incoming: any - Source: "Site A subnet" -> Destination: "Site B subnet" - Next-hop Tunnel - "Site B VPN tunnel"

În al doilea rând, trebuie să configurați o regulă care să permită răspunsurile care vin de la Site B și care se îndreaptă către Site A (atunci când ați trimis o solicitare de la Site A), iar acestea trebuie să fie direcționate în tunelul Site A. Acest lucru este important atât pentru cererile ICMP (care vin de la Site B), dar și pentru răspunsurile ICMP (care vin de la Site B și acum se întorc din nou la Site A).

Incoming: any - Source: "Site B subnet" -> Destination: "Site A subnet" - Next-hop Tunnel - "Site A VPN tunnel"

1.2 Rute de politică - Firewall-ul site-ului A

Apoi, trebuie să configurați o regulă care să permită cererile venite de la Site B care se îndreaptă către Site A (atunci când ați trimis o cerere de la Site B). Acestea trebuie să fie direcționate"înapoi" în tunelul Site A, iar acest lucru este important atât pentru cererile ICMP (care vin de la Site B), dar și pentru răspunsurile ICMP (care vin de la Site B și acum se întorc din nou la Site B).

Incoming: any - Source: "Site B subnet" -> Destination: "Site A subnet" - Next-hop "Site A VPN tunnel"

1.3 Rute de politică - Firewall-ul site-ului B

Apoi, trebuie să configurați o regulă care să permită cererile care vin de la Site A și care se îndreaptă către Site B (atunci când ați trimis o cerere de la Site A). Acestea trebuie să fie direcționate"înapoi" în tunelul Site B, iar acest lucru este important atât pentru cererile ICMP (care vin de la Site A), dar și pentru răspunsurile ICMP (care vin de la Site A și acum se întorc din nou la Site A).

Incoming: any - Source: "Site A subnet" -> Destination: "Site B subnet" - Next-hop "Site B VPN tunnel"

2) Verificare / Depanare

După ce ați configurat toate rutele de politică, este important să verificați dacă rutarea funcționează efectiv. Poate că aveți rute conflictuale în regulile de firewall (suprapuneri de subrețea, rute de politică existente/rute statice etc.) sau există altceva în neregulă.

Rețineți că acest lucru poate fi foarte confuz, deoarece există multe rute de care trebuie să aveți grijă. Cel mai simplu mod de a face acest lucru este de a trasa manual pe o hârtie toate fluxurile de pachete (PC -> Gateway A - gateway-ul trebuie să ruteze către HQ, HQ trebuie să ruteze către Site B - Site B trebuie să ruteze răspunsul înapoi către HQ din nou ... etc.), întrebați-vă - "cine este responsabil pentru rutare și este rutarea în vigoare?".

Mai jos veți găsi două scenarii în care este posibil să fie nevoie să modificați configurațiile pentru ca rutarea să funcționeze.

2.1 Testați prin ping la firewall

Primul este testarea prin ping de la un PC de pe site-ul A către un server sau un PC de pe site-ul B:

Săgeata roșie - ICMP [ping] Request (Cerere ICMP [ping])

Săgeata verde - ICMP [ping] Reply (Răspuns ICMP [ping])

2.2mRute de politică - Firewall-ul site-ului A

Dacă trimiteți ping la Gateway-ul Site B de la Gateway-ul Site A (instrument ICMP încorporat), politica de rutare de pe Site A nu se va aplica pentru răspunsurile primite înapoi de la Site B, dacă Site B încearcă să trimită ping la Gateway-ul Site A.

Prin urmare, avem nevoie de o politică de rutare care să arate astfel:

Intrări: ZyWall- Sursa: "Site B subnet" -> Destinație: "Site A subnet" - Next-hop "Site A VPN tunnel"

2.3 Rute de politică - Firewall-ul site-ului B

Primul test pe care îl puteți face este să efectuați un ping la firewall, însă, deoarece rutarea pe care ați creat-o acum este NUMAI pentru Incoming any (cu excepția Zywall), înseamnă că rutarea nu se va aplica dacă ping-ul vine de la Site A, ajunge la Firewall-ul Site B și apoi Firewall-ul este responsabil pentru a răspunde la această cerere. Răspunsul ICMP va arăta astfel:

ICMP Request

PC (ICMP Request) -> Site A Gateway -> Tunel VPN către HQ -> HQ Gateway trimite traficul către Site B Gateway

Răspuns ICMP

Site B Gateway (ICMP Reply) -> Site B Gateway -> Tunel VPN către HQ -> HQ Gateway trimite traficul către Site A Gateway -> Site A Gateway trimite pachetele înapoi către PC

Prin urmare, este necesară această rută de politică:

Intrări: ZyWall - Sursa: "Site A subnet" -> Destinație: "Site B subnet" - Next-hop "Site B VPN tunnel"

2.4 Testarea prin ping la un server / PC

Deoarece PC-ul se află în rețeaua 192.168.20.0/24, iar serverul se află în rețeaua 192.168.30.0/24, serverul nu recunoaște rețeaua 192.168.20.0/24 și, prin urmare, este foarte probabil ca serverul să blocheze pachetele ICMP care vin din subrețele necunoscute. Prin urmare, atunci când efectuați teste, întotdeauna:

• Dezactivați orice firewall încorporat (de exemplu, Windows Defender / Firewall).
• Dezactivați alte softuri antivirus și de securitate pentru puncte finale instalate pe server / PC.

Rutarea traficului de la client la site printr-un tunel site la site

Atenție: Acest lucru nu a funcționat cu Dynamic VPN! Vă rugăm să selectați doar Site2Site VPN!

1) Configurați SecuExtender IPSec VPN

Pentru a direcționa clienții IPSec VPN într-un alt tunel, aceștia trebuie să utilizeze adrese IP fixe.

Dacă este necesară rutarea mai multor clienți diferiți, se recomandă utilizarea unor IP-uri apropiate, astfel încât să se poată crea un interval. Acest lucru reduce numărul de rute necesare.

Subrețeaua în care se află adresele IP nu trebuie să fie prezentă pe firewall.

Introduceți adresa IP fixă pe clientul VPN IPSec

2) Configurați rutarea firewall-ului

Pe firewall, navigați la

Configuration > Object > Address

și faceți clic pe

pentru a crea intervalul pentru adresele IP ale clientului VPN IPSec.

Acum putem adăuga rutele necesare la

cu un clic pe butonul

Add

2.1 Pe site-ul A Firewall

Trebuie să creăm două rute:

• Una pentru traficul de ieșire, deci de la tunelul dinamic VPN-client către sub-rețeaua de la distanță prin tunelul site-la-sediu.

• Unul pentru traficul de intrare, deci dinspre subrețeaua la distanță prin tunelul site-la-sediu către tunelul client-VPN.

Noile rute ar trebui să arate în felul următor:

O altă modalitate de a permite traficul de intrare din subrețeaua de la distanță prin tunelul VPN la distanță, puteți activa "ruta asimetrică":

Acest lucru va activa ruta "triunghiulară", care face ca firewall-ul să permită utilizarea topologiei de rutare asimetrică în rețea și să nu reseteze conexiunea atunci când se primește răspunsul.

2.2 Pe firewall-ul de pe site-ul B

Pe site-ul de la distanță, ar putea fi necesar să fie create rute similare, astfel încât dispozitivul de pe site-ul principal să știe cum să gestioneze traficul de la clienții VPN care vin de la sucursala site-ului.

Pe site-ul central, creăm intervalul IP pentru clienții VPN de la distanță, astfel încât să îl putem utiliza pentru a direcționa traficul.

Acum creăm rutele corespunzătoare și pe site-ul HQ.

O rută de ieșire, deci din sub-rețeaua HQ prin tunelul site-la-sediu către clienții VPN la distanță.

Și o rută de intrare, deci dinspre gama de clienți VPN la distanță prin tunelul site-to-site către LAN-ul local al HQ. Dacă traficul este direcționat către o subrețea locală, selectăm "Auto" ca next-hop, USG gestionează acest lucru în mod automat.

Rutele ar trebui să arate cam așa:

+++ Puteți cumpăra licențe pentru clienții dumneavoastră Zyxel VPN (SSL VPN, IPsec) cu livrare imediată printr-un singur clic: Zyxel Webstore +++