L2TP/IPsec através de NAT: o que realmente quebra e por quê

A afirmação de que o NAT quebra o L2TP/IPsec é meio verdadeira e, por isso, inútil. A tradução de endereços é normal, o traversal NAT existe justamente para sobreviver a ela, e milhões de clientes se conectam todos os dias atrás de um roteador. O que quebra é um estágio específico de uma troca específica: o IKE nunca recebe resposta, o túnel encapsulado é descartado por uma política que só permite um protocolo, ou o mapeamento de tradução expira enquanto o túnel está inativo. Quando você sabe em que estágio está, a correção costuma ser uma única regra ou um keepalive, não um novo projeto de VPN.

O mito é a pergunta errada

A pergunta útil não é «o NAT quebra isso», mas «que parte da troca está sendo traduzida, e o que o dispositivo que traduz faz com ela». O L2TP/IPsec é um protocolo em camadas: o IKE negocia, o ESP protege, e o L2TP transporta PPP dentro dessa proteção. A tradução de endereços interage de forma diferente com cada camada, e as assinaturas de falha podem ser distinguidas se você olhar o estágio de negociação em vez da caixa de erro.

Um roteador que navega na web com sucesso só prova que o TCP com tradução de porta de origem funciona. Ele não diz nada sobre UDP 500, UDP 4500 ou protocolo 50, e são exatamente essas três coisas das quais esta implantação depende.

Estágio 1: o IKE precisa receber alguma resposta

A primeira troca vai para o respondedor em UDP 500. Se nenhuma resposta volta, nada mais importa: a chave pré-compartilhada, a proposta e as credenciais ficam sem leitura. Observe a requisição e a resposta em vez de deduzir do tempo limite do cliente:

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

Uma requisição sem resposta normalmente significa que um firewall ou a operadora acima está descartando o pacote, não que o servidor o rejeitou. Uma resposta com carga de notificação que nomeia uma proposta ou um problema de certificado significa que os pacotes chegaram e que a negociação falhou por conteúdo, o que é um reparo completamente diferente.

Quando os dois lados estão atrás de tradução, o iniciador só precisa alcançar o respondedor, então a maioria das implantações do lado do cliente funciona a partir do estágio 1. A hospedagem do lado do servidor é onde o problema de entrada começa, e é por isso que as duas situações nunca devem ser discutidas como uma só.

Estágio 2: a encapsulação muda o que o firewall vê

O ESP é um protocolo IP, não uma porta TCP ou UDP, e a tradução de endereços de portas comum não tem campo de porta para reescrever. Por isso o traversal NAT move a carga protegida para dentro do UDP 4500: a encapsulação dá ao dispositivo que traduz algo que ele sabe traduzir. Quando isso acontece, uma regra de firewall escrita só para UDP 500 permite a negociação e descarta o túnel, o que produz o resultado confuso em que o log mostra uma fase 1 bem-sucedida e nenhum tráfego.

A própria troca IKE também pode passar para UDP 4500 depois que um NAT é detectado, o que surpreende quem permitiu 500 e nada mais. Permita as duas portas nos dois sentidos no caminho, e lembre que um firewall com estado só mantém o fluxo enquanto vê tráfego.

O protocolo 50 ainda importa em caminhos sem tradução, e em caminhos onde um equipamento intermediário está configurado para permiti-lo. Se você diagnostica por eliminação, desligue a hipótese em vez de adicionar regras em bloco: permita 500, 4500 e ESP, confirme que o túnel sobe e depois remova o que se mostrou desnecessário. Uma regra que ninguém consegue explicar é uma regra que ninguém vai remover quando se tornar a causa da próxima queda. Registre o estreitamento no log de mudanças junto com o estágio que ele corrigiu, para que o próximo engenheiro comece pelas suas evidências e não pela mesma regra prática.

Estágio 3: o mapeamento expira e o túnel morre

Um dispositivo que traduz mantém estado para os fluxos que encaminha, e esse estado tem tempo de vida. Um túnel L2TP/IPsec carrega pouco tráfego quando ninguém o usa, então um túnel ocioso pode sobreviver ao seu mapeamento e parar de receber tráfego de volta. O cliente continua convencido de que está conectado, o servidor não vê nada, e o primeiro sintoma costuma ser um tempo limite de aplicação e não um erro de VPN.

Detecção de par morto e keepalives de NAT existem para isso, e as duas pontas precisam estar dispostas a enviá-los. Se o seu servidor está atrás de tradução, o requisito no lado do Windows é um ajuste de registro documentado que faz o servidor assumir encapsulação UDP para seus próprios pacotes de saída; sem ele, o respondedor envia ESP que o dispositivo que traduz não consegue mapear de volta. Isso é um problema de configuração do servidor, não do cliente.

Uma mudança de endereço WAN produz o mesmo resultado por outro caminho: o mapeamento é reconstruído em torno de um novo endereço, e a antiga associação de segurança agora aponta para uma tupla que não existe mais. O comportamento de reconexão pertence à implementação do cliente, e é por isso que «reconectar depois que o roteador reinicia» funciona em um cliente e em outro exige um botão manual.

Hospedar atrás de um NAT de operadora é um problema diferente

Se você quer hospedar um servidor L2TP/IPsec em casa e alcançá-lo de fora, o requisito é acessibilidade de entrada não solicitada, e isso não é o que o traversal NAT oferece. Um NAT de operadora na frente do seu roteador significa que não há porta que você possa encaminhar e que o torne acessível, porque o endereço público é compartilhado e o mapeamento é só de saída.

Nenhuma caixa de IPsec pass-through muda isso, e nenhuma configuração de cliente compensa. As respostas suportadas são um endereço realmente acessível, um endpoint hospedado ou uma arquitetura em que cada participante faz uma conexão de saída. A especificação de encapsulação UDP resolve o problema de tradução para os fluxos que existem; ela não cria um caminho de entrada onde a operadora não oferece nenhum.

Então compare redes em vez de adivinhar. Leve o mesmo dispositivo e perfil para outra rede permitida e veja qual estágio falha ali. Se funciona em outro lugar, a diferença está no caminho, e isso reduz a busca aos três estágios acima em vez de toda a configuração.