Por que o L2TP/IPsec precisa de UDP 1701 além do IPsec

As firewalls que permitem IKE e ESP mas não UDP 1701 quebram as ligações L2TP de uma forma que parece um problema de credenciais. A razão é que o L2TP é um segundo protocolo que viaja dentro do primeiro. O IPsec transporta e autentica a troca, e o L2TP executa o seu próprio túnel sobre UDP 1701, que a pilha local ainda tem de entregar. Saber onde aparece cada cabeçalho explica qual dispositivo precisa de qual regra.

Dois protocolos, dois conjuntos de portas

Uma ligação L2TP/IPsec usa IKE em UDP 500, atravessamento NAT em UDP 4500 onde existe tradução, e ESP como protocolo IP 50 onde não existe. O próprio L2TP é um protocolo de túnel em UDP 1701, e funciona depois de o IPsec autenticar o par. As duas metades falham de forma diferente, e as linhas de registo que informam sobre elas vêm de componentes diferentes. Um conjunto de regras que cobre apenas a primeira metade produz uma ligação que negocia e depois morre na fase do túnel.

Os números de porta descrevem extremos de transporte, e o ESP não é porta nenhuma. Por isso uma interface de firewall que só oferece regras TCP e UDP não consegue exprimir uma política IPsec completa. O protocolo 50 tem de ser permitido como protocolo, e uma regra que só menciona UDP nunca vai corresponder-lhe.

O invólucro explica a porta

Na rede, uma ligação L2TP/IPsec mostra normalmente IKE em 500 e ESP encapsulado em 4500. O cabeçalho UDP 1701 fica dentro da carga protegida, por isso uma captura na interface exterior não o mostra. O host local ainda tem de entregar esse datagrama ao daemon L2TP, e a entrega acontece após a desencapsulação. Por isso a regra 1701 pertence à firewall do próprio extremo, mesmo quando nenhum dispositivo intermédio vê a porta.

A ordem de processamento explica a maior parte da confusão. Se a pilha aplica a política IPsec antes do filtro do host, o pacote L2TP desencapsulado é comparado como UDP 1701; se a ordem for inversa, as portas exteriores são o que o conjunto de regras vê. Ambos os comportamentos existem na prática, por isso o mesmo conjunto de regras parece funcionar numa plataforma e falhar noutra.

Verifique o caminho por ordem

Capture primeiro a interface exterior e confirme que IKE e ESP encapsulado se movem nos dois sentidos. Depois verifique os contadores da firewall local para o tráfego desencapsulado. A ordem importa, porque uma captura que não mostra nada significa que o problema está acima do host.

sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'
sudo nft list ruleset | grep -i -A2 1701
sudo ss -lunp | grep 1701

A captura confirma a primeira metade da troca e mostra se o par responde. A lista de regras mostra se existe uma regra 1701 e onde se situa em relação a qualquer política de descarte. A lista de sockets confirma que o daemon L2TP está ligado e a escutar, o que exclui um serviço que nunca arrancou. Leia as três coisas antes de alterar uma regra, porque um ouvinte ausente e uma porta filtrada produzem queixas idênticas do utilizador.

O que uma análise de portas não consegue mostrar

Uma análise externa de UDP 1701 contra um servidor bem configurado normalmente não reporta nada, e esse é o resultado esperado. A porta não está exposta à internet; só se chega a ela depois de o IPsec autenticar o par. Tratar o resultado fechado como uma avaria leva a abrir uma porta que devia permanecer fechada. A análise não consegue ver dentro do túnel mais do que consegue ver o tráfego da aplicação.

Teste antes com um cliente real, e leia a fase a que chega. Se a ligação negocia e depois encrava, o suspeito é o daemon L2TP ou o filtro local; se nunca negocia, são as portas exteriores. Essa única divisão elimina a maior parte das suposições sobre que regra acrescentar, e o empilhamento do protocolo torna isso previsível em vez de misterioso.