Miks L2TP/IPsec vajab lisaks IPsecile ka UDP 1701

Tulemüürid, mis lubavad IKE ja ESP, kuid mitte UDP 1701, katkestavad L2TP-ühendusi viisil, mis näeb välja nagu volituste probleem. Põhjus on see, et L2TP on teine protokoll, mis sõidab esimese sees. IPsec kannab ja autendib vahetust ning L2TP käitab oma tunnelit üle UDP 1701, mille kohalik pinu peab ikkagi kohale toimetama. Teadmine, kus iga päis ilmub, selgitab, milline seade millist reeglit vajab.

Kaks protokolli, kaks pordikomplekti

L2TP/IPsec-ühendus kasutab IKE-d UDP 500 peal, NAT-i läbimist UDP 4500 peal seal, kus tõlge on olemas, ja ESP-d IP-protokollina 50 seal, kus seda pole. L2TP ise on tunneliprotokoll UDP 1701 peal ja see töötab pärast seda, kui IPsec on partneri autentinud. Kaks poolt ebaõnnestuvad erinevalt ja logiread, mis neist teada annavad, tulevad erinevatest komponentidest. Reeglistik, mis katab ainult esimese poole, tekitab ühenduse, mis läbiräägib ja sureb seejärel tunnelifaasis.

Pordinumbrid kirjeldavad transpordi lõpp-punkte ja ESP ei ole üldse port. Seetõttu ei saa tulemüüri liides, mis pakub ainult TCP ja UDP reegleid, väljendada täielikku IPsec-poliitikat. Protokoll 50 tuleb lubada protokollina ja reegel, mis mainib ainult UDP-d, ei sobi sellega kunagi.

Ümbrik selgitab porti

Võrgus näitab L2TP/IPsec-ühendus tavaliselt IKE-d 500 peal ja kapseldatud ESP-d 4500 peal. UDP 1701 päis asub kaitstud kandevõime sees, seetõttu ei näita välisliidesel tehtud püüdmine seda. Kohalik host peab selle datagrammi ikkagi L2TP-deemonile kohale toimetama ja kohaletoimetamine toimub pärast dekapssuleerimist. Seega kuulub 1701 reegel lõpp-punkti enda tulemüürile, isegi kui ükski vahepealne seade seda porti kunagi ei näe.

Töötlemise järjekord selgitab suuremat osa segadusest. Kui pinu rakendab IPsec-poliitikat enne hosti filtrit, sobitatakse dekapssuleeritud L2TP-pakett UDP 1701-na; kui järjekord on vastupidine, näeb reeglistik väliseid porte. Mõlemad käitumised esinevad praktikas, seetõttu näib sama reeglistik ühel platvormil töötavat ja teisel ebaõnnestuvat.

Kontrolli teed järjekorras

Püüa esmalt välisliides ja kinnita, et IKE ja kapseldatud ESP liiguvad mõlemas suunas. Seejärel kontrolli kohaliku tulemüüri loendureid dekapssuleeritud liikluse jaoks. Järjekord on oluline, sest püüdmine, mis ei näita üldse midagi, tähendab, et probleem asub hostist ülesvoolu.

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

Püüdmine kinnitab vahetuse esimest poolt ja näitab, kas partner vastab. Reeglite loend näitab, kas 1701 reegel on olemas ja kus see asub mis tahes kõrvalejätmispoliitika suhtes. Soklite loend kinnitab, et L2TP-deemon on seotud ja kuulab, mis välistab teenuse, mis kunagi ei käivitunud. Loe kõiki kolme enne reegli muutmist, sest puuduv kuulaja ja filtreeritud port tekitavad kasutajalt identseid kaebusi.

Mida pordiskaneerimine näidata ei suuda

UDP 1701 väline skaneerimine korralikult seadistatud serveri vastu ei teatagi tavaliselt millestki ja see on oodatav tulemus. Port ei ole internetti avatud; selleni jõutakse alles pärast seda, kui IPsec on partneri autentinud. Suletud tulemuse rikkena käsitlemine viib pordi avamiseni, mis peaks jääma suletuks. Skaneerimine ei näe tunnelisse rohkem kui näeb rakenduse liiklust.

Katseta selle asemel päris kliendiga ja loe, millise etapini see jõuab. Kui ühendus läbiräägib ja jääb siis seisma, on kahtlusalune L2TP-deemon või kohalik filter; kui see kunagi ei läbiräägi, on süüdi välised pordid. See üks jaotus eemaldab suurema osa oletustest, millist reeglit lisada, ja protokolli kihistamine teeb selle etteaimatavaks, mitte müstiliseks.