Miért kell a L2TP/IPsec-nek UDP 1701 az IPsec mellett

A tűzfalak, amelyek engedélyezik az IKE-et és az ESP-t, de az UDP 1701-et nem, olyan módon törik meg az L2TP-kapcsolatokat, amely hitelesítő adatokkal kapcsolatos problémának tűnik. Az ok az, hogy a L2TP egy második protokoll, amely az elsőn belül utazik. Az IPsec szállítja és hitelesíti a cserét, a L2TP pedig a saját alagútját futtatja az UDP 1701 felett, amelyet a helyi veremnek még mindig át kell adnia. Annak ismerete, hogy hol jelenik meg az egyes fejlécek, megmagyarázza, melyik eszköznek melyik szabályra van szüksége.

Két protokoll, két portkészlet

Egy L2TP/IPsec-kapcsolat az IKE-et az UDP 500-on, a NAT-átjárást az UDP 4500-on használja ott, ahol van fordítás, az ESP-t pedig IP-protokollként 50-ként ott, ahol nincs. Maga a L2TP alagútprotokoll az UDP 1701-en, és azután fut, hogy az IPsec hitelesítette a partnert. A két fél különbözőképpen hibázik, és az ezekről beszámoló naplósorok különböző összetevőkből származnak. Egy csak az első felet lefedő szabálykészlet olyan kapcsolatot hoz létre, amely tárgyal, majd meghal az alagút szakaszában.

A portszámok szállítási végpontokat írnak le, az ESP pedig egyáltalán nem port. Ezért egy csak TCP- és UDP-szabályokat kínáló tűzfal-felület nem tud teljes IPsec-szabályzatot kifejezni. Az 50-es protokollt protokollként kell engedélyezni, és a csak UDP-t említő szabály soha nem fog rá illeszkedni.

A burkolat magyarázza a portot

A hálózaton egy L2TP/IPsec-kapcsolat általában az IKE-et 500-on és a beágyazott ESP-t 4500-on mutatja. Az UDP 1701 fejléc a védett hasznos terhelésen belül helyezkedik el, ezért a külső interfészen végzett rögzítés nem mutatja. A helyi gazdagépnek ezt a datagramot még mindig át kell adnia az L2TP-démonnak, és az átadás a dekapszulálás után történik. Ezért az 1701-es szabály a végpont saját tűzfalához tartozik, akkor is, ha egyetlen köztes eszköz sem látja soha a portot.

A feldolgozás sorrendje magyarázza a zavar nagy részét. Ha a verem az IPsec-szabályzatot a gazdagép szűrője előtt alkalmazza, a dekapszulált L2TP-csomag UDP 1701-ként illeszkedik; ha a sorrend fordított, a szabálykészlet a külső portokat látja. Mindkét viselkedés létezik a gyakorlatban, ezért tűnik úgy, hogy ugyanaz a szabálykészlet az egyik platformon működik, a másikon pedig meghibásodik.

Ellenőrizze az útvonalat sorrendben

Először rögzítse a külső interfészt, és erősítse meg, hogy az IKE és a beágyazott ESP mindkét irányban mozog. Ezután ellenőrizze a helyi tűzfal számlálóit a dekapszulált forgalomhoz. A sorrend számít, mert egy semmit sem mutató rögzítés azt jelenti, hogy a probléma a gazdagép felett van.

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

A rögzítés megerősíti a csere első felét, és megmutatja, válaszol-e a partner. A szabálylista megmutatja, létezik-e 1701-es szabály, és hol áll bármilyen eldobási szabályzathoz képest. A socketlista megerősíti, hogy az L2TP-démon kötve van és figyel, ami kizárja a soha el nem indult szolgáltatást. Mindhármat olvassa el a szabály módosítása előtt, mert a hiányzó figyelő és a szűrt port ugyanazt a panaszt eredményezi a felhasználónál.

Mit nem mutathat meg a portvizsgálat

Az UDP 1701 külső vizsgálata egy helyesen beállított kiszolgáló ellen általában semmit sem jelent, és ez a várt eredmény. A port nincs kitéve az internetnek; csak azután érhető el, hogy az IPsec hitelesítette a partnert. A zárt eredmény hibaként kezelése egy olyan port megnyitásához vezet, amelynek zárva kellene maradnia. A vizsgálat nem lát az alagút belsejébe, ahogy az alkalmazás forgalmát sem látja.

Ehelyett valódi klienssel teszteljen, és olvassa el, melyik szakaszig jut el. Ha a kapcsolat tárgyal, majd elakad, az L2TP-démon vagy a helyi szűrő a gyanús; ha soha nem tárgyal, akkor a külső portok a felelősek. Ez az egyetlen felosztás megszünteti a találgatás nagy részét arról, melyik szabályt kell hozzáadni, és a protokollrétegzés kiszámíthatóvá teszi a rejtélyes helyett.