Por que L2TP/IPsec precisa UDP 1701 ademais de IPsec

As devasas que permiten IKE e ESP pero non UDP 1701 rompen as conexións L2TP dun xeito que parece un problema de credenciais. A razón é que L2TP é un segundo protocolo que viaxa dentro do primeiro. IPsec transporta e autentica o intercambio, e L2TP executa o seu propio túnel sobre UDP 1701, que a pila local aínda ten que entregar. Saber onde aparece cada cabeceira explica que dispositivo necesita que regra.

Dous protocolos, dous conxuntos de portos

Unha conexión L2TP/IPsec usa IKE en UDP 500, atravesamento NAT en UDP 4500 onde hai tradución, e ESP como protocolo IP 50 onde non a hai. O propio L2TP é un protocolo de túnel en UDP 1701, e execútase despois de que IPsec autenticase o par. As dúas metades fallan de xeito distinto, e as liñas de rexistro que informan delas veñen de compoñentes diferentes. Un conxunto de regras que só cobre a primeira metade produce unha conexión que negocia e logo morre na etapa do túnel.

Os números de porto describen extremos de transporte, e ESP non é un porto en absoluto. Por iso unha interface de devasa que só ofrece regras TCP e UDP non pode expresar unha política IPsec completa. O protocolo 50 debe permitirse como protocolo, e unha regra que só menciona UDP nunca coincidirá con el.

A envoltura explica o porto

No cable, unha conexión L2TP/IPsec mostra normalmente IKE en 500 e ESP encapsulado en 4500. A cabeceira UDP 1701 sitúase dentro da carga protexida, por iso unha captura na interface exterior non a mostra. O equipo local aínda ten que entregar ese datagrama ao demonio L2TP, e a entrega ocorre tras o desencapsulado. Por iso a regra 1701 pertence á devasa do propio extremo, mesmo cando ningún dispositivo intermedio ve nunca o porto.

A orde de procesamento explica a maior parte da confusión. Se a pila aplica a política IPsec antes do filtro do equipo, o paquete L2TP desencapsulado compárase como UDP 1701; se a orde se inviste, os portos exteriores son o que ve o conxunto de regras. Ambos os comportamentos existen na práctica, por iso o mesmo conxunto de regras parece funcionar nunha plataforma e fallar noutra.

Comproba a ruta en orde

Captura primeiro a interface exterior e confirma que IKE e ESP encapsulado se moven en ambas as direccións. Despois revisa os contadores da devasa local para o tráfico desencapsulado. A orde importa, porque unha captura que non mostra nada en absoluto significa que o problema está máis arriba do equipo.

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 do intercambio e mostra se o par responde. A listaxe de regras mostra se existe unha regra 1701 e onde se sitúa respecto de calquera política de descarte. A listaxe de sockets confirma que o demonio L2TP está ligado e escoitando, o que descarta un servizo que nunca se iniciou. Le as tres cousas antes de cambiar unha regra, porque un oínte ausente e un porto filtrado producen queixas idénticas do usuario.

O que unha exploración de portos non pode mostrar

Unha exploración externa de UDP 1701 contra un servidor ben configurado normalmente non informa de nada, e ese é o resultado esperado. O porto non está exposto a internet; só se chega a el despois de que IPsec autenticase o par. Tratar o resultado pechado como unha avaría leva a abrir un porto que debería permanecer pechado. A exploración non pode ver dentro do túnel máis do que pode ver o tráfico da aplicación.

Proba cun cliente real no seu lugar, e le a etapa á que chega. Se a conexión negocia e logo se atasca, o sospeitoso é o demonio L2TP ou o filtro local; se nunca negocia, son os portos exteriores. Ese único reparto elimina a maior parte das conxecturas sobre que regra engadir, e a estratificación do protocolo faino previsible en vez de misterioso.