NAT en forquilla: per què el punt final de la VPN falla des de dins

Un servidor VPN que respon des d'una xarxa mòbil i falla des del sofà normalment no és un problema de certificat. El client dins de la LAN demana a l'encaminador que tradueixi un paquet la destinació del qual és l'adreça pública del mateix encaminador, cosa que vol dir que el paquet ha de sortir i tornar a entrar de seguida. Aquesta maniobra és el hairpinning, i força encaminadors o no la implementen o només ho fan quan s'activa una casella. El fet que la prova des de fora passi és el que fa que tot plegat confongui, perquè demostra que l'oient i la regla de reenviament estan bé.

El paquet surt i torna a entrar

Seguiu el paquet. El client resol el nom públic, es connecta a l'adreça pública, i el NAT de destinació de l'encaminador reescriu la destinació cap al servidor intern. La resposta del servidor s'adreça a l'adreça LAN del client, així que torna per la interfície LAN de l'encaminador sense travessar mai la regla NAT que hauria destraduït l'origen.

Ara el client rep un paquet d'una adreça a la qual no ha enviat mai res, i el descarta. Aquesta asimetria és tota la fallada.

La RFC 4787 descriu el comportament que s'espera d'un NAT en aquest cas, i la versió curta és que a la pràctica és opcional fins i tot quan en teoria està especificat. Alguns encaminadors anomenen el paràmetre NAT loopback, d'altres hairpin NAT o NAT reflection, i alguns no n'exposen cap. Un encaminador que no ho té no està mal configurat; fa la cosa normal, i la solució pertoca a un altre lloc. No conclogueu d'una prova local fallida que la regla de reenviament pública és incorrecta.

Comprovació 1: proveu els dos camins per separat

Des de fora de la LAN, connecteu-vos amb el mateix perfil que faria servir un usuari real i confirmeu que la sessió s'estableix. Des de dins, connecteu-vos a l'adreça pública amb el mateix perfil i anoteu l'error exacte i l'hora.

Una prova local precisa conserva el nom d'amfitrió i només substitueix l'adreça: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ envia la petició a l'adreça pública tot presentant encara el nom de servidor correcte. Això separa un problema de resolució de noms d'un problema de traducció, que són fàcils de confondre quan el mateix nom funciona des d'una cafeteria. Fixeu-vos si el client falla a la connexió TCP o més tard a TLS, perquè el primer apunta a la traducció i el segon a la identitat.

Comprovació 2: llegiu què veu el servidor

L'observació més útil és la visió del servidor. Executeu una captura a l'amfitrió VPN filtrada per l'adreça LAN del client i per l'adreça LAN de l'encaminador, i després repetiu l'intent local. Si no arriba res, el paquet no va sobreviure a la traducció.

Si una connexió arriba des de l'adreça LAN de l'encaminador en lloc de la del client, s'està produint hairpinning i l'origen s'ha reescrit. Aquesta és una configuració que funciona, no una avaria.

Comprovació 3: arregleu-ho sense tocar el camí extern

Hi ha tres formes suportades, en ordre creixent de radi d'impacte. La més estreta és el DNS dividit: publiqueu un registre intern perquè el mateix nom de servidor es resolgui a l'adreça interna per als clients de la LAN, cosa que evita del tot el camí públic. La següent és activar l'opció documentada de loopback o reflection de l'encaminador, si en té, i aplicar-la només a aquest servei. La més àmplia és una regla source-NAT a l'encaminador que reescriu el trànsit provinent de la LAN cap al servidor perquè la resposta torni per l'encaminador; en un encaminador Linux és una regla MASQUERADE a POSTROUTING que coincideix amb l'adreça i el port del servidor. Les tres mantenen intacte el camí extern, i aquesta és la propietat que cal preservar.

No amplieu reenviament de ports no relacionat per fer que el camí local s'assembli a l'extern, ni moveu el servei a un altre port per esquivar el problema. Els dos canvis alteren què pot abastar el món exterior per arreglar una cosa que només veu el món interior.

El DNS dividit té un parany que val la pena esmentar. Substitutir un nom d'amfitrió per una IP arbitrària canvia què valida el client, així que el registre intern ha de continuar coincidint amb el nom del certificat.

Comprovació 4: verifiqueu tots dos camins després

Repetiu l'intent extern des de fora de la LAN, repetiu l'intent intern amb el mateix perfil i confirmeu que el registre del servidor mostra dues sessions reeixides diferents en lloc d'un èxit i un silenci. Després comproveu que altres clients encara arriben a l'oient i que les rutes als recursos privats no han canviat.

Manteniu el registre curt: quina adreça va fer servir cada client, què va veure el servidor i quina de les tres solucions es va aplicar. Els requisits de hairpinning de la RFC 4787 són la referència del que s'espera d'un NAT aquí, i expliquen per què un encaminador sense la funció es comporta normalment. Una fallada local que el món exterior no pot reproduir és una qüestió de traducció fins que es demostri el contrari, així que proveu-la com a tal.