Traficul clientului VPN și starea firewall-ului: flux extern și intern

Handshake-ul VPN se încheie, clientul primește o adresă, iar un serviciu din spatele gateway-ului refuză în continuare conexiunea. Firewall-ul face adesea exact ce i s-a spus. A permis fluxul extern al tunelului, care este un pachet diferit de conexiunea aplicației decapsulate. Urmează două decizii: ce flux permiteți și dacă granița urmărește deloc starea.

Până nu separați cele două, fiecare modificare de regulă este o presupunere.

Firewall-ul vede două pachete diferite

Înainte de decapsulare, firewall-ul vede trafic adresat punctului final VPN: un flux UDP extern către ascultător. După decapsulare, un pachet redirecționat poartă adresa internă a clientului și destinația serviciului.

O permisiune pentru fluxul extern nu autorizează conexiunea TCP redirecționată. Ele pot fi evaluate în lanțuri diferite, pe interfețe diferite și cu adrese diferite după traducere.

Comparați capturile din poziții echivalente pe ambele părți. O captură la marginea tunelului și o captură pe server arată tuple diferite pentru aceeași sesiune.

Prima decizie: a permite tunelul sau serviciul

Dacă clientul are nevoie doar de punctul final VPN în sine, permisiunea externă poate fi suficientă. Dacă are nevoie de un serviciu dincolo de gateway, este nevoie de o permisiune de redirecționare pentru acea destinație și acel port. O regulă de tunel care permite și serviciul este o alegere de proiectare pe care ar trebui să o numiți, nu un accident.

Păstrați intervalul clientului și sfera serviciului înguste. O permisiune din subrețeaua tunelului către întreaga rețea locală este o decizie de a avea încredere în fiecare gazdă, nu o scurtătură pentru o singură aplicație.

Scrieți ambele reguli separat. Regula tunelului și regula serviciului eșuează în moduri diferite și se depanează cu dovezi diferite. Când una eșuează, știți ce strat să inspectați mai întâi.

A doua decizie: cu stare sau fără stare la fiecare graniță

O regulă pentru fluxul stabilit poate admite răspunsuri pentru un schimb permis, dar comportamentul depinde de produs. Un grup de securitate din cloud urmărește de obicei starea; o listă de control de acces a subrețelei adesea nu o urmărește și necesită tratare explicită în ambele direcții. Nu presupuneți că fiecare graniță de pe traseu tratează starea la fel. Enumerați fiecare graniță și marcați-o cu sau fără urmărirea stării înainte de a proiecta regulile.

Dacă o regulă se schimbă, fluxurile urmărite existente pot continua să funcționeze în timp ce cele noi eșuează, sau invers. Acea diferență este un indiciu util, nu un motiv să goliți toată starea conexiunilor pe un gateway activ.

Testați cu o cerere nouă și controlată și inspectați contoarele relevante. Un test curat este mai bun decât o resetare perturbatoare. Notați numele contorului în jurnalul modificărilor, astfel încât următorul test să folosească aceleași dovezi.

Verificați calea de întoarcere sub aceeași politică

Trimiteți o cerere nouă de la client la serviciu, apoi verificați contoarele dus și întors la fiecare graniță. Confirmați că răspunsul folosește calea așteptată, mai ales dacă este implicată traducerea.

Păstrați înguste intervalul de client prevăzut și sfera serviciului și verificați calea de întoarcere sub același set de reguli care a permis cererea. O regulă care funcționează doar pentru că un flux vechi este încă deschis nu este o regulă funcțională.