Trànsit del client VPN i estat del tallafoc: flux exterior davant de l’interior

L’apretada de mans VPN es completa, el client obté una adreça i un servei darrere la passarel·la encara refusa la connexió. El tallafoc sovint fa exactament el que se li ha dit. Ha permès el flux exterior del túnel, que és un paquet diferent de la connexió d’aplicació desencapsulada. Se’n deriven dues decisions: quin flux permeteu i si la frontera fa seguiment de l’estat.

Fins que no separeu aquestes dues coses, cada canvi de regla és una conjectura.

El tallafoc veu dos paquets diferents

Abans de la desencapsulació, el tallafoc veu trànsit adreçat al punt final VPN: un flux UDP exterior cap a l’oient. Després de la desencapsulació, un paquet reenviat porta l’adreça interior del client i la destinació del servei.

Un permís per al flux exterior no autoritza la connexió TCP reenviada. Es poden avaluar en cadenes diferents, contra interfícies diferents i amb adreces diferents després de la traducció.

Compareu captures des de posicions equivalents als dos costats. Una captura a la vora del túnel i una captura al servidor mostren tuples diferents per a la mateixa sessió.

Primera decisió: permetre el túnel o el servei

Si el client només necessita el punt final VPN, el permís exterior pot ser suficient. Si necessita un servei més enllà de la passarel·la, cal un permís de reenviament per a aquella destinació i port. Una regla de túnel que també permet el servei és una decisió de disseny que hauríeu de nomenar, no un accident.

Manteniu estrets el rang del client i l’abast del servei. Un permís de la subxarxa del túnel a tota la LAN és una decisió de confiar en cada amfitrió, no una drecera per a una aplicació.

Escriviu les dues regles per separat. La regla del túnel i la regla del servei fallen de maneres diferents i es depuren amb proves diferents. Quan una falla, sabeu quina capa cal inspeccionar primer.

Segona decisió: amb estat o sense estat a cada frontera

Una regla de flux establert pot admetre respostes per a un intercanvi permès, però el seu comportament depèn del producte. Un grup de seguretat al núvol normalment té estat; una llista de control de subxarxa sovint no en té i necessita un tractament explícit en les dues direccions. No assumiu que cada frontera del camí tracta l’estat de la mateixa manera. Llisteu cada frontera i marqueu-la amb estat o sense estat abans de dissenyar les regles.

Si una regla canvia, els fluxos seguits existents poden continuar funcionant mentre els nous fallen, o al revés. Aquesta diferència és una pista útil, no una raó per buidar tot l’estat de connexió en una passarel·la en producció.

Proveu amb una petició nova i controlada i inspeccioneu els comptadors rellevants. Una prova neta és millor que un reinici pertorbador. Anoteu el nom del comptador al registre del canvi perquè la propera prova faci servir la mateixa evidència.

Verifiqueu el camí de tornada sota la mateixa política

Envieu una petició nova del client al servei i després comproveu els comptadors d’anada i de tornada a cada frontera. Confirmeu que la resposta fa servir el camí que espereu, sobretot si hi ha traducció pel mig.

Manteniu estrets el rang de client previst i l’abast del servei, i verifiqueu el camí de tornada sota el mateix conjunt de regles que va permetre la petició. Una regla que només funciona perquè un flux antic encara és obert no és una regla que funcioni.