L2TP/IPsec a través de NAT: que se rompe de verdade e por que

A afirmación de que NAT rompe L2TP/IPsec é medio certa e por iso inútil. A tradución de enderezos é normal, o traversal NAT existe precisamente para sobrevivela, e millóns de clientes conéctanse cada día desde detrás dun router. O que se rompe é unha etapa concreta dun intercambio concreto: IKE nunca recibe resposta, o túnel encapsulado descártase por unha política que só permite un protocolo, ou o mapeo de tradución caduca mentres o túnel está inactivo. Cando sabe en que etapa está, a solución adoita ser unha soa regra ou un keepalive, non un deseño novo de VPN.

O mito é a pregunta equivocada

A pregunta útil non é se NAT rompe isto, senón que parte do intercambio se traduce e que fai con ela o dispositivo que traduce. L2TP/IPsec é un protocolo por capas: IKE negocia, ESP protexe, e L2TP transporta PPP dentro desa protección. A tradución de enderezos interactúa de forma distinta con cada capa, e as sinaturas de fallo distínguense se mira a etapa de negociación en lugar do diálogo de erro.

Un router que navega pola web con éxito só demostra que TCP con tradución de porto de orixe funciona. Non di nada sobre UDP 500, UDP 4500 nin o protocolo 50, e esas son as tres cousas das que depende este despregamento.

Etapa 1: IKE ten que recibir algunha resposta

O primeiro intercambio vai ao respondedor por UDP 500. Se non volve ningunha resposta, nada máis importa: a clave precompartida, a proposta e as credenciais quedan sen ler. Observe a petición e a resposta en lugar de deducilo do tempo de espera do cliente:

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

Unha petición sen resposta normalmente significa que unha cortalumes ou o operador augas arriba descarta o paquete, non que o servidor o rexeitase. Unha resposta cunha carga de notificación que nomea unha proposta ou un problema de certificado significa que os paquetes chegaron e que a negociación fallou polo contido, o cal é unha solución completamente distinta.

Cando ambos os extremos están detrás de tradución, o iniciador só ten que alcanzar o respondedor, así que a maioría dos despregamentos do lado do cliente funcionan desde a etapa 1. O aloxamento do lado do servidor é onde comeza o problema de entrada, e por iso as dúas situacións nunca deben tratarse como unha soa.

Etapa 2: a encapsulación cambia o que ve a cortalumes

ESP é un protocolo IP, non un porto TCP ou UDP, e a tradución de enderezos de portos ordinaria non ten ningún campo de porto que reescribir. Por iso o traversal NAT move a carga protexida dentro de UDP 4500: a encapsulación dá ao dispositivo que traduce algo que sabe traducir. Cando iso ocorre, unha regra de cortalumes escrita só para UDP 500 permite a negociación e descarta o túnel, o que produce o resultado confuso no que o rexistro mostra unha fase 1 correcta e ningún tráfico.

O propio intercambio IKE tamén pode pasar a UDP 4500 tras detectarse un NAT, o que sorprende a quen permitiu 500 e nada máis. Permita ambos os portos en ambas as direccións na ruta, e lembre que unha cortalumes con estado só pode manter o fluxo mentres ve tráfico.

O protocolo 50 segue importando en rutas sen tradución, e en rutas onde un dispositivo intermedio está configurado para permitilo. Se diagnostica por eliminación, desactive a hipótese en lugar de engadir regras en bloque: permita 500, 4500 e ESP, confirme que o túnel sobe e logo elimine o que resultou innecesario. Unha regra que ninguén pode explicar é unha regra que ninguén eliminará cando se converta na causa da próxima caída. Escriba o estreitamento no rexistro de cambios xunto coa etapa que corrixiu, para que o seguinte enxeñeiro comece polas súas probas e non pola mesma regra xeral.

Etapa 3: o mapeo caduca e o túnel morre

Un dispositivo que traduce mantén estado dos fluxos que reenvía, e ese estado ten unha vida útil. Un túnel L2TP/IPsec transporta pouco tráfico cando ninguén o usa, así que un túnel inactivo pode sobrevivir ao seu mapeo e deixar de recibir tráfico de volta. O cliente segue convencido de que está conectado, o servidor non ve nada, e o primeiro síntoma adoita ser un tempo de espera dunha aplicación e non un erro de VPN.

A detección de par morto e os keepalives de NAT existen para isto, e ambos os extremos deben estar dispostos a envialos. Se o seu servidor está detrás de tradución, o requisito en Windows é un axuste de rexistro documentado que fai que o servidor asuma encapsulación UDP para os seus propios paquetes saíntes; sen el, o respondedor envía ESP que o dispositivo que traduce non pode volver mapear. É un problema de configuración do servidor, non do cliente.

Un cambio de enderezo WAN produce o mesmo resultado desde outra dirección: o mapeo reconstrúese arredor dun enderezo novo, e a antiga asociación de seguridade agora apunta a unha tupla que xa non existe. O comportamento de reconexión pertence á implementación do cliente, e por iso «reconectar tras reiniciar o router» funciona nun cliente e noutro esixe un conmutador manual.

Aloxar detrás dun NAT de operador é un problema distinto

Se quere aloxar un servidor L2TP/IPsec na casa e alcanzalo desde fóra, o requisito é accesibilidade de entrada non solicitada, e iso non é o que ofrece o traversal NAT. Un NAT de operador diante do seu router significa que non hai ningún porto que poida reenviar e que o faga accesible, porque o enderezo público é compartido e o mapeo é só de saída.

Ningunha casilla de IPsec pass-through cambia iso, e ningunha cantidade de configuración do cliente o compensa. As respostas admitidas son un enderezo realmente accesible, un punto final aloxado ou unha arquitectura na que cada participante fai unha conexión saínte. A especificación de encapsulación UDP resolve o problema de tradución para os fluxos que existen; non crea unha ruta de entrada onde o operador non ofrece ningunha.

Así que compare redes en lugar de adiviñar. Leve o mesmo dispositivo e perfil a outra rede permitida e observe que etapa falla alí. Se funciona noutro sitio, a diferenza está na ruta, e iso reduce a busca ás tres etapas anteriores en lugar de a toda a configuración.