Kodėl L2TP/IPsec reikia UDP 1701 kartu su IPsec

Užkardos, kurios leidžia IKE ir ESP, bet ne UDP 1701, nutraukia L2TP ryšius taip, kad tai atrodo kaip prisijungimo duomenų problema. Priežastis ta, kad L2TP yra antrasis protokolas, keliaujantis pirmojo viduje. IPsec perneša ir autentifikuoja mainus, o L2TP paleidžia savo tunelį per UDP 1701, kurį vietinė dėklas vis tiek turi pristatyti. Žinojimas, kur atsiranda kiekviena antraštė, paaiškina, kuriam įrenginiui reikia kokios taisyklės.

Du protokolai, du prievadų rinkiniai

L2TP/IPsec ryšys naudoja IKE per UDP 500, NAT praėjimą per UDP 4500 ten, kur yra vertimas, ir ESP kaip IP protokolą 50 ten, kur jo nėra. Pats L2TP yra tunelio protokolas per UDP 1701 ir veikia po to, kai IPsec autentifikuoja partnerį. Dvi pusės nepavyksta skirtingai, o žurnalo eilutės, kurios apie jas praneša, ateina iš skirtingų komponentų. Taisyklių rinkinys, apimantis tik pirmą pusę, sukuria ryšį, kuris derasi ir tada miršta tunelio etape.

Prievadų numeriai apibūdina transporto galinius taškus, o ESP visai nėra prievadas. Todėl užkardos sąsaja, siūlanti tik TCP ir UDP taisykles, negali išreikšti visos IPsec politikos. Protokolas 50 turi būti leidžiamas kaip protokolas, o taisyklė, kuri mini tik UDP, niekada jo neatitiks.

Apvalkalas paaiškina prievadą

Tinyle L2TP/IPsec ryšys paprastai rodo IKE per 500 ir įvyniotą ESP per 4500. UDP 1701 antraštė yra apsaugotos naudingosios apkrovos viduje, todėl išorinės sąsajos fiksavimas jos nerodo. Vietinis mazgas vis tiek turi pristatyti tą datagramą L2TP tarnybai, o pristatymas vyksta po dekapsuliavimo. Todėl 1701 taisyklė priklauso paties galinio taško užkardai, net kai joks tarpinis įrenginys niekada nemato prievado.

Apdorojimo tvarka paaiškina didžiąją dalį painiavos. Jei dėklas taiko IPsec politiką prieš mazgo filtrą, dekapsuliuotas L2TP paketas sutapatinamas kaip UDP 1701; jei tvarka atvirkštinė, išoriniai prievadai yra tai, ką mato taisyklių rinkinys. Abi elgsenos egzistuoja praktiškai, todėl tas pats taisyklių rinkinys atrodo veikiantis vienoje platformoje ir nepavykstantis kitoje.

Patikrinkite kelią iš eilės

Pirmiausia užfiksuokite išorinę sąsają ir patvirtinkite, kad IKE ir įvyniotas ESP juda abiem kryptimis. Tada patikrinkite vietinės užkardos skaitiklius dekapsuliuotam srautui. Tvarka svarbi, nes fiksavimas, kuris nieko nerodo, reiškia, kad problema yra aukščiau mazgo.

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

Fiksavimas patvirtina pirmą mainų pusę ir parodo, ar partneris atsako. Taisyklių sąrašas parodo, ar yra 1701 taisyklė ir kur ji stovi bet kokios atmetimo politikos atžvilgiu. Lizdų sąrašas patvirtina, kad L2TP tarnyba yra susieta ir klausosi, o tai pašalina tarnybą, kuri niekada nebuvo paleista. Perskaitykite visus tris prieš keisdami taisyklę, nes trūkstamas klausytojas ir filtruojamas prievadas sukelia identiškus naudotojo nusiskundimus.

Ko prievadų skenavimas negali parodyti

Išorinis UDP 1701 skenavimas prieš teisingai sukonfigūruotą serverį paprastai nieko nepraneša, ir tai yra laukiamas rezultatas. Prievadas nėra atviras internetui; jį pasiekti galima tik po to, kai IPsec autentifikuoja partnerį. Uždarą rezultatą laikant gedimu, atidaromas prievadas, kuris turėtų likti uždarytas. Skenavimas negali matyti tunelio viduje taip pat, kaip negali matyti programos srauto.

Užuot tai darę, išbandykite su tikru klientu ir perskaitykite, į kurį etapą jis patenka. Jei ryšys derasi ir tada užstringa, įtariamasis yra L2TP tarnyba arba vietinis filtras; jei jis niekada nesidera, kalti išoriniai prievadai. Tas vienas atskyrimas pašalina didžiąją dalį spėliojimų, kurią taisyklę pridėti, o protokolų sluoksniavimas daro tai nuspėjama, o ne paslaptingu.