De ce L2TP/IPsec are nevoie de UDP 1701 pe lângă IPsec

Firewall-urile care permit IKE și ESP, dar nu UDP 1701, rup conexiunile L2TP într-un mod care pare o problemă de acreditări. Motivul este că L2TP este un al doilea protocol care călătorește în interiorul primului. IPsec transportă și autentifică schimbul, iar L2TP rulează propriul tunel peste UDP 1701, pe care stiva locală tot trebuie să îl livreze. A ști unde apare fiecare antet explică ce dispozitiv are nevoie de ce regulă.

Două protocoale, două seturi de porturi

O conexiune L2TP/IPsec folosește IKE pe UDP 500, traversarea NAT pe UDP 4500 acolo unde există traducere, și ESP ca protocol IP 50 acolo unde nu există. L2TP însuși este un protocol de tunel pe UDP 1701 și rulează după ce IPsec a autentificat partenerul. Cele două jumătăți eșuează diferit, iar liniile de jurnal care raportează despre ele vin din componente diferite. Un set de reguli care acoperă doar prima jumătate produce o conexiune care negociază și apoi moare în etapa tunelului.

Numerele de port descriu puncte finale de transport, iar ESP nu este deloc un port. De aceea o interfață de firewall care oferă doar reguli TCP și UDP nu poate exprima o politică IPsec completă. Protocolul 50 trebuie permis ca protocol, iar o regulă care menționează doar UDP nu se va potrivi niciodată cu el.

Ambalajul explică portul

Pe rețea, o conexiune L2TP/IPsec arată de obicei IKE pe 500 și ESP încapsulat pe 4500. Antetul UDP 1701 se află în interiorul încărcăturii protejate, de aceea o captură pe interfața exterioară nu îl arată. Gazda locală tot trebuie să livreze acel datagram demonului L2TP, iar livrarea are loc după decapsulare. Așadar regula 1701 aparține firewall-ului punctului final însuși, chiar și atunci când niciun dispozitiv intermediar nu vede portul.

Ordinea de procesare explică cea mai mare parte a confuziei. Dacă stiva aplică politica IPsec înaintea filtrului gazdei, pachetul L2TP decapsulat este potrivit ca UDP 1701; dacă ordinea este inversă, porturile exterioare sunt ceea ce vede setul de reguli. Ambele comportamente există în practică, de aceea același set de reguli pare să funcționeze pe o platformă și să eșueze pe alta.

Verificați calea în ordine

Mai întâi capturați interfața exterioară și confirmați că IKE și ESP încapsulat se mișcă în ambele direcții. Apoi verificați contoarele firewall-ului local pentru traficul decapsulat. Ordinea contează, pentru că o captură care nu arată nimic înseamnă că problema se află deasupra gazdei.

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

Captura confirmă prima jumătate a schimbului și arată dacă partenerul răspunde. Lista de reguli arată dacă există o regulă 1701 și unde se află față de orice politică de eliminare. Lista de socketuri confirmă că demonul L2TP este legat și ascultă, ceea ce exclude un serviciu care nu a pornit niciodată. Citiți toate trei înainte de a schimba o regulă, pentru că un ascultător lipsă și un port filtrat produc aceleași reclamații din partea utilizatorului.

Ce nu poate arăta o scanare de porturi

O scanare externă a UDP 1701 împotriva unui server configurat corect nu raportează de obicei nimic, și acesta este rezultatul așteptat. Portul nu este expus la internet; se ajunge la el doar după ce IPsec a autentificat partenerul. Tratarea rezultatului închis ca o defecțiune duce la deschiderea unui port care ar trebui să rămână închis. Scanarea nu poate vedea în interiorul tunelului mai mult decât poate vedea traficul aplicației.

Testați în schimb cu un client real, și citiți etapa la care ajunge. Dacă conexiunea negociază și apoi se blochează, suspect este demonul L2TP sau filtrul local; dacă nu negociază niciodată, porturile exterioare sunt vinovate. Acea singură împărțire elimină cea mai mare parte din presupunerile despre ce regulă trebuie adăugată, iar stratificarea protocolului face lucrurile previzibile în loc de misterioase.