Per què L2TP/IPsec necessita l'UDP 1701 a més de l'IPsec

Els tallafocs que permeten IKE i ESP però no l'UDP 1701 trenquen les connexions L2TP d'una manera que sembla un problema de credencials. La raó és que L2TP és un segon protocol que viatja dins del primer. L'IPsec transporta i autentica l'intercanvi, i L2TP executa el seu propi túnel sobre l'UDP 1701, que la pila local encara ha de lliurar. Saber on apareix cada capçalera explica quin dispositiu necessita quina regla.

Dos protocols, dos conjunts de ports

Una connexió L2TP/IPsec fa servir IKE a l'UDP 500, travessia NAT a l'UDP 4500 on hi ha traducció, i ESP com a protocol IP 50 on no n'hi ha. El mateix L2TP és un protocol de túnel a l'UDP 1701, i s'executa després que l'IPsec hagi autenticat el parell. Les dues meitats fallen de manera diferent, i les línies de registre que en donen compte venen de components diferents. Un conjunt de regles que només cobreix la primera meitat produeix una connexió que negocia i després mor a l'etapa del túnel.

Els números de port descriuen extrems de transport, i ESP no és cap port. Per això una interfície de tallafocs que només ofereix regles TCP i UDP no pot expressar una política IPsec completa. El protocol 50 s'ha de permetre com a protocol, i una regla que només esmenta UDP mai no hi coincidirà.

L'embolcall explica el port

Al cable, una connexió L2TP/IPsec normalment mostra IKE al 500 i ESP encapsulat al 4500. La capçalera UDP 1701 se situa dins de la càrrega protegida, i per això una captura a la interfície exterior no la mostra. L'amfitrió local encara ha de lliurar aquest datagrama al dimoni L2TP, i el lliurament passa després del desencapsulament. Per tant, la regla 1701 pertany al tallafocs del propi extrem, fins i tot quan cap caixa intermèdia no veu mai el port.

L'ordre de processament explica la major part de la confusió. Si la pila aplica la política IPsec abans del filtre de l'amfitrió, el paquet L2TP desencapsulat es fa correspondre com a UDP 1701; si l'ordre s'inverteix, els ports exteriors són el que veu el conjunt de regles. Tots dos comportaments existeixen a la pràctica, i per això el mateix conjunt de regles sembla funcionar en una plataforma i fallar en una altra.

Comprova el camí per ordre

Captura primer la interfície exterior i confirma que IKE i ESP encapsulat es mouen en totes dues direccions. Després revisa els comptadors del tallafocs local per al trànsit desencapsulat. L'ordre és important, perquè una captura que no mostra res de cap manera significa que el problema és més amunt de l'amfitrió.

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

La captura confirma la primera meitat de l'intercanvi i mostra si el parell respon. El llistat de regles mostra si existeix una regla 1701 i on se situa respecte de qualsevol política de descart. El llistat de sockets confirma que el dimoni L2TP està lligat i escoltant, cosa que descarta un servei que mai no es va iniciar. Llegeix les tres coses abans de canviar una regla, perquè un oient absent i un port filtrat produeixen queixes idèntiques de l'usuari.

Què no pot mostrar un escaneig de ports

Un escaneig extern de l'UDP 1701 contra un servidor ben configurat normalment no informa de res, i aquest és el resultat esperat. El port no està exposat a Internet; només s'hi arriba després que l'IPsec hagi autenticat el parell. Tractar el resultat tancat com una avaria porta a obrir un port que hauria de romandre tancat. L'escaneig no pot veure dins del túnel més del que pot veure el trànsit de l'aplicació.

Prova-ho amb un client real en lloc d'això, i llegeix l'etapa a què arriba. Si la connexió negocia i després s'encalla, el sospitós és el dimoni L2TP o el filtre local; si no negocia mai, són els ports exteriors. Aquesta única divisió elimina la major part de les conjectures sobre quina regla afegir, i l'estratificació del protocol ho fa previsible en lloc de misteriós.