L2TP/IPsec a través de NAT: què es trenca realment i per què

L’afirmació que NAT trenca L2TP/IPsec és mig certa i, per tant, inútil. La traducció d’adreces és normal, el traversal NAT existeix precisament per sobreviure-hi, i milions de clients es connecten cada dia des darrere d’un router. El que es trenca és una etapa concreta d’un intercanvi concret: IKE no rep mai resposta, el túnel encapsulat es descarta per una política que només permet un protocol, o la traducció caduca mentre el túnel està inactiu. Quan sabeu en quina etapa sou, la solució sol ser una sola regla o un keepalive, no un disseny nou de VPN.

El mite és la pregunta equivocada

La pregunta útil no és «trenca això el NAT» sinó «quina part de l’intercanvi es tradueix i què en fa el dispositiu que tradueix». L2TP/IPsec és un protocol per capes: IKE negocia, ESP protegeix i L2TP transporta PPP dins d’aquesta protecció. La traducció d’adreces interactua de manera diferent amb cada capa, i les signatures de fallada es poden distingir si mireu l’etapa de negociació en lloc del diàleg d’error.

Un router que navega per la web correctament només demostra que TCP amb traducció de port d’origen funciona. No diu res sobre UDP 500, UDP 4500 o el protocol 50, i aquestes són les tres coses de les quals depèn aquest desplegament.

Etapa 1: IKE ha de rebre alguna resposta

El primer intercanvi va al responedor per UDP 500. Si no torna cap resposta, res més no importa: la clau prèviament compartida, la proposta i les credencials queden sense llegir. Observeu la petició i la resposta en lloc d’inferir-ho del temps d’espera del client:

sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas

Una petició sense resposta normalment vol dir que un tallafoc o l’operador aigües amunt descarta el paquet, no que el servidor l’hagi rebutjat. Una resposta amb una càrrega de notificació que anomena una proposta o un problema de certificat vol dir que els paquets van arribar i que la negociació va fallar pel contingut, cosa que és una reparació completament diferent.

Quan tots dos extrems són darrere de traducció, l’iniciador només ha d’arribar al responedor, així que la majoria de desplegaments al costat del client funcionen des de l’etapa 1. L’allotjament al costat del servidor és on comença el problema d’entrada, i és la raó per la qual les dues situacions no s’han de tractar mai com una de sola.

Etapa 2: l’encapsulació canvia el que veu el tallafoc

ESP és un protocol IP, no un port TCP o UDP, i la traducció d’adreces de ports ordinària no té cap camp de port per reescriure-hi. Per això el traversal NAT mou la càrrega protegida dins d’UDP 4500: l’encapsulació dona al dispositiu que tradueix una cosa que sap traduir. Quan això passa, una regla de tallafoc escrita només per a UDP 500 permet la negociació i descarta el túnel, cosa que produeix el resultat confús on el registre mostra una fase 1 correcta i cap trànsit.

El mateix intercanvi IKE també pot passar a UDP 4500 després de detectar un NAT, cosa que sorprèn qui ha permès 500 i res més. Permeteu tots dos ports en totes dues direccions al camí, i recordeu que un tallafoc amb estat pot mantenir el flux només mentre veu trànsit.

El protocol 50 encara importa en camins sense traducció, i en camins on un dispositiu intermedi està configurat per permetre’l. Si diagnostiqueu per eliminació, desactiveu la hipòtesi en lloc d’afegir regles en bloc: permeteu 500, 4500 i ESP, confirmeu que el túnel puja, i després traieu el que ha resultat innecessari. Una regla que ningú no pot explicar és una regla que ningú no traurà quan es converteixi en la causa de la propera caiguda. Escriviu l’estrenyiment al registre de canvis juntament amb l’etapa que ha corregit, perquè el següent enginyer comenci per les vostres proves i no per la mateixa regla general.

Etapa 3: la traducció caduca i el túnel mor

Un dispositiu que tradueix manté estat dels fluxos que reenvia, i aquest estat té una vida útil. Un túnel L2TP/IPsec transporta poc trànsit quan ningú no l’utilitza, així que un túnel inactiu pot sobreviure a la seva traducció i deixar de rebre trànsit de tornada. El client continua convençut que està connectat, el servidor no veu res, i el primer símptoma sol ser un temps d’espera d’una aplicació i no un error de VPN.

La detecció d’igual mort i els keepalives de NAT existeixen per a això, i tots dos extrems han d’estar disposats a enviar-los. Si el vostre servidor és darrere de traducció, el requisit al costat de Windows és un paràmetre de registre documentat que fa que el servidor assumeixi encapsulació UDP per als seus propis paquets sortints; sense això, el responedor envia ESP que el dispositiu que tradueix no pot tornar a mapar. És un problema de configuració del servidor, no del client.

Un canvi d’adreça WAN produeix el mateix resultat des d’una altra direcció: la traducció es reconstrueix al voltant d’una adreça nova, i l’antiga associació de seguretat ara apunta a una tupla que ja no existeix. El comportament de reconnexió pertany a la implementació del client, i per això «reconnecta després que el router reiniciï» funciona en un client i en un altre necessita un commutador manual.

Allotjar darrere d’un NAT d’operador és un problema diferent

Si voleu allotjar un servidor L2TP/IPsec a casa i arribar-hi des de fora, el requisit és accessibilitat d’entrada no sol·licitada, i això no és el que ofereix el traversal NAT. Un NAT d’operador davant del vostre router vol dir que no hi ha cap port que pugueu reenviar que us faci accessible, perquè l’adreça pública és compartida i la traducció és només de sortida.

Cap casella d’IPsec pass-through canvia això, i cap quantitat de configuració del client ho compensa. Les respostes suportades són una adreça realment accessible, un punt final allotjat o una arquitectura on cada participant fa una connexió sortint. La norma d’encapsulació UDP resol el problema de traducció per als fluxos que existeixen; no crea un camí d’entrada on l’operador no n’ofereix cap.

Així que compareu xarxes en lloc d’endevinar. Porteu el mateix dispositiu i perfil a una altra xarxa permesa i mireu quina etapa falla allà. Si funciona en un altre lloc, la diferència és al camí, i això redueix la cerca a les tres etapes anteriors en lloc de tota la configuració.