Ce pachet trebuie să potrivească o politică VPN cu două WAN-uri?

Cererile de rutare a VPN prin al doilea uplink descriu cel puțin două sarcini diferite, iar politica ce rezolvă una nu o atinge pe cealaltă. În prima sarcină, transportul criptat dintre două capete se mută pe altă adresă WAN. În a doua, fluxul de aplicație decriptat al unui utilizator conectat iese către un alt salt următor. Ambele sunt legitime, ambele folosesc rutarea, iar fiecare are nevoie de o potrivire pe un pachet care există în punctul unde se ia decizia. Parcurgeți verificările de mai jos în ordine, pentru că prima determină ce pachet trebuie să numească regulile ulterioare.

Numiți cele două conversații

Imaginați-vă un lucrător la distanță conectat la un gateway de birou, care deschide HTTPS către un server de aplicații intern. Pe fir există două conversații independente, iar ele au adrese diferite la fiecare capăt. Conversația exterioară se desfășoară între cele două capete VPN: de la adresa gateway-ului la adresa partenerului, cu protocolul și portul pe care le-a negociat implementarea. Conversația interioară se desfășoară de la adresa atribuită clientului la adresa serverului de aplicații pe portul 443.

Portul de destinație al aplicației nu este portul de transport al VPN-ului, iar nicio cantitate de politică pe TCP 443 nu va muta tunelul. La fel, o regulă care redirecționează adresa de transport a partenerului nu spune nimic despre unde ajunge cererea HTTP a acelui utilizator după decriptare. Notați ambele conversații cu adresele lor reale înainte de a atinge o regulă, pentru că cea mai mare parte a confuziei în acest domeniu vine din a numi una și a configura cealaltă.

Găsiți unde politica dumneavoastră vede cu adevărat pachetul

Potrivirea trebuie evaluată în lanțul și spațiul de nume în care pachetul este încă în forma pe care ați descris-o. O regulă atașată la intrarea LAN vede pachetul interior necriptat, înainte de a fi rutat către tunel. O regulă aplicată traficului generat local vede pachetele pe care le generează gateway-ul însuși, și nu acoperă automat traficul pe care gateway-ul doar îl redirecționează. Ieșirea încapsulată este din nou un al treilea caz, de obicei tratat pe interfața care poartă tunelul și nu pe partea LAN.

De aceea același fragment de configurație se comportă diferit pe două platforme: punctele de atașare diferă, iar cârligul de politică al unui producător poate sta înainte sau după pasul de criptare. Citiți calea pachetului pentru produsul concret în loc să presupuneți ordinea din diagrama altui producător.

Confirmați transportul pe care l-ați negociat

Pentru IPsec încapsulat în UDP, RFC 3948 pune ESP în interiorul UDP și folosește un marcaj care nu este ESP pentru ca IKE să rămână distingibil pe portul comun. ESP simplu este un protocol IP, nu un port TCP sau UDP, așa că o regulă de firewall scrisă după un număr de port nu îl va potrivi deloc. Această distincție decide dacă politica WAN are nevoie de o regulă UDP, de o regulă de protocol sau de ambele.

Valorile negociate înving valorile reținute. Citiți porturile și adresele actuale ale asocierii din echipament în loc să adăugați TCP 4500 sau un port vechi al producătorului pentru orice eventualitate, ceea ce captează trafic nelegat și ascunde problema reală de clasificare.

Verificați calea de întoarcere înainte de a vă angaja

Succesul în direcția de ieșire dovedește jumătate dintr-un proiect. Un pachet care se întoarce spre grupul de clienți la distanță nu mai este vizibil sub adresa clientului odată ce încapsularea o înlocuiește: destinația exterioară este adresa de transport a partenerului. Dacă al doilea uplink ajunge la acel partener printr-un operator diferit, traducerea și filtrarea lui pot să nu fie de acord cu prima, iar asocierea poate necesita reconstruire în loc de migrare.

Starea traducerii adreselor de rețea este victima obișnuită a unei schimbări de WAN. Notați uplink-ul ales, adresa de sursă exterioară așteptată, traducerea în uz și accesibilitatea partenerului înapoi la ea, apoi mențineți transportul accesibil fără a-l trimite în tunelul pe care îl poartă.

Verificați ambele straturi cu două capturi

O captură pe interfața WAN și una în interiorul tunelului rezolvă întrebarea mai repede decât orice comparație de configurație. Rulați-le de pe gateway în timp ce un client aprobat face o singură cerere, și păstrați ambele fișiere.

sudo tcpdump -ni wan1 'udp port 4500' -c 20
sudo tcpdump -ni tun0 'tcp port 443 and host 203.0.113.10' -c 20
ip route get 203.0.113.10 from 10.8.0.6

Prima captură ar trebui să arate conversația exterioară părăsind interfața pe care intenționați, cu adresa de sursă așteptată. A doua ar trebui să arate conversația interioară o singură dată, neduplicată, cu adresa clientului ca sursă și serverul de aplicații ca destinație. Căutarea rutei confirmă ce tabelă ar folosi routerul pentru acea pereche sursă-destinație, și acolo apare de obicei o eroare de politică. Dacă vreuna dintre capturi nu apare, punctul de decizie este în altă parte decât acolo unde a fost atașată regula, iar corecția aparține acelui loc și nu unei potriviri mai largi.