Kial L2TP/IPsec bezonas UDP 1701 same kiel IPsec

Fajroŝirmiloj, kiuj permesas IKE kaj ESP sed ne UDP 1701, rompas L2TP-konektojn tiel, ke ĝi aspektas kiel problemo pri akreditiloj. La kialo estas, ke L2TP estas dua protokolo vojaĝanta ene de la unua. IPsec portas kaj aŭtentigas la interŝanĝon, kaj L2TP funkciigas sian propran tunelon super UDP 1701, kiun la loka stako ankoraŭ devas transdoni. Scii, kie ĉiu kaplinio aperas, klarigas, kiu aparato bezonas kiun regulon.

Du protokoloj, du havenaroj

L2TP/IPsec-konekto uzas IKE sur UDP 500, NAT-trapasado sur UDP 4500 kie ekzistas traduko, kaj ESP kiel IP-protokolo 50 kie ĝi ne ekzistas. L2TP mem estas tunela protokolo sur UDP 1701, kaj ĝi funkcias post kiam IPsec aŭtentigis la kunulon. La du duonoj fiaskas malsame, kaj la protokolaj linioj raportantaj pri ili venas de malsamaj komponantoj. Regula aro kovranta nur la unuan duonon produktas konekton, kiu intertraktas kaj poste mortas en la tunela fazo.

Havenaj numeroj priskribas transportajn finpunktojn, kaj ESP tute ne estas haveno. Tial fajroŝirmila interfaco ofranta nur TCP- kaj UDP-regulojn ne povas esprimi plenan IPsec-politikon. Protokolo 50 devas esti permesata kiel protokolo, kaj regulo mencianta nur UDP neniam kongruos kun ĝi.

La ĉirkaŭaĵo klarigas la havenon

Sur la drato L2TP/IPsec-konekto kutime montras IKE sur 500 kaj enkapsuligitan ESP sur 4500. La kaplinio UDP 1701 sidas ene de la protektita utilŝarĝo, tial kapto sur la ekstera interfaco ne montras ĝin. La loka gastiganto ankoraŭ devas transdoni tiun datagramon al la L2TP-demono, kaj la transdono okazas post malkapsuligo. Tial la regulo por 1701 apartenas al la fajroŝirmilo de la finpunkto mem, eĉ kiam neniu meza aparato iam vidas la havenon.

La prilabora ordo klarigas la plej grandan parton de la konfuzo. Se la stako aplikas la IPsec-politikon antaŭ la gastiganta filtrilo, la malkapsuligita L2TP-paketo estas kongruata kiel UDP 1701; se la ordo estas inversa, la eksteraj havenoj estas tio, kion la regula aro vidas. Ambaŭ kondutoj ekzistas praktike, tial la sama regula aro ŝajnas funkcii sur unu platformo kaj fiaski sur alia.

Kontrolu la vojon laŭ ordo

Unue kaptu la eksteran interfacon kaj konfirmu, ke IKE kaj enkapsuligita ESP moviĝas en ambaŭ direktojn. Poste kontrolu la lokajn fajroŝirmilajn nombrilojn por la malkapsuligita trafiko. La ordo gravas, ĉar kapto montranta tute nenion signifas, ke la problemo troviĝas supre de la gastiganto.

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 kapto konfirmas la unuan duonon de la interŝanĝo kaj montras, ĉu la kunulo respondas. La regula listo montras, ĉu ekzistas regulo por 1701 kaj kie ĝi staras rilate al iu ajn forĵeta politiko. La inga listo konfirmas, ke la L2TP-demono estas ligita kaj aŭskultas, kio ekskludas servon, kiu neniam ekfunkciis. Legu ĉiujn tri antaŭ ol ŝanĝi regulon, ĉar mankanta aŭskultanto kaj filtrita haveno produktas identajn plendojn de la uzanto.

Kion havena skanado ne povas montri

Ekstera skanado de UDP 1701 kontraŭ ĝuste agordita servilo kutime raportas nenion, kaj tio estas la atendata rezulto. La haveno ne estas elmetita al la interreto; oni atingas ĝin nur post kiam IPsec aŭtentigis la kunulon. Trakti la fermitan rezulton kiel difekton kondukas al malfermo de haveno, kiu devus resti fermita. La skanado ne povas vidi enen de la tunelo pli ol ĝi povas vidi la aplikaĵan trafikon.

Anstataŭe testu per reala kliento kaj legu, kiun fazon ĝi atingas. Se la konekto intertraktas kaj poste haltas, la suspektindulo estas la L2TP-demono aŭ la loka filtrilo; se ĝi neniam intertraktas, la eksteraj havenoj estas. Tiu unu divido forigas la plej grandan parton de la divenado pri tio, kiun regulon aldoni, kaj la protokola tavoligo faras ĝin antaŭvidebla anstataŭ mistera.