Prečo L2TP/IPsec potrebuje UDP 1701 popri IPsec
L2TP je druhý protokol, ktorý cestuje vnútri prvého, preto koncový bod musí po dekapsulácii aj tak doručiť UDP 1701, hoci ho žiadne medziľahlé zariadenie nevidí.
Firewally, ktoré povoľujú IKE a ESP, ale nie UDP 1701, lámu L2TP spojenia spôsobom, ktorý vyzerá ako problém s prihlasovacími údajmi. Dôvodom je, že L2TP je druhý protokol, ktorý cestuje vnútri prvého. IPsec prenáša a overuje výmenu a L2TP prevádzkuje svoj vlastný tunel cez UDP 1701, ktorý musí miestny zásobník aj tak doručiť. Vedieť, kde sa objavuje každá hlavička, vysvetľuje, ktoré zariadenie potrebuje ktoré pravidlo.
Dva protokoly, dve sady portov
Spojenie L2TP/IPsec používa IKE na UDP 500, prechod NAT na UDP 4500 tam, kde je preklad, a ESP ako IP protokol 50 tam, kde nie je. Samotné L2TP je tunelový protokol na UDP 1701 a beží po tom, čo IPsec overil partnera. Obe polovice zlyhávajú odlišne a riadky v logu, ktoré o nich informujú, pochádzajú z rôznych komponentov. Sada pravidiel pokrývajúca iba prvú polovicu vytvorí spojenie, ktoré vyjedná a potom zomrie v tunelovej fáze.
Čísla portov opisujú transportné koncové body a ESP vôbec nie je port. Preto rozhranie firewallu, ktoré ponúka iba pravidlá TCP a UDP, nemôže vyjadriť úplnú politiku IPsec. Protokol 50 musí byť povolený ako protokol a pravidlo, ktoré spomína iba UDP, sa s ním nikdy nezhoduje.
Obal vysvetľuje port
Na sieti spojenie L2TP/IPsec zvyčajne ukazuje IKE na 500 a zapuzdrené ESP na 4500. Hlavička UDP 1701 sa nachádza vnútri chráneného užitočného zaťaženia, preto ju odposluch na vonkajšom rozhraní neukáže. Miestny hostiteľ musí tento datagram aj tak doručiť démonovi L2TP a doručenie prebieha po dekapsulácii. Preto pravidlo 1701 patrí firewallu samotného koncového bodu, aj keď port nikdy nevidí žiadne medziľahlé zariadenie.
Poradie spracovania vysvetľuje väčšinu zmätku. Ak zásobník použije politiku IPsec pred filtrom hostiteľa, dekapsulovaný paket L2TP sa zhoduje ako UDP 1701; ak je poradie opačné, sada pravidiel vidí vonkajšie porty. Obe správania existujú v praxi, preto tá istá sada pravidiel vyzerá funkčná na jednej platforme a zlyháva na inej.
Skontrolujte cestu po poradí
Najprv zachyťte vonkajšie rozhranie a potvrďte, že IKE a zapuzdrené ESP prúdia oboma smermi. Potom skontrolujte miestne počítadlá firewallu pre dekapsulovanú prevádzku. Poradie je dôležité, pretože odposluch, ktorý neukazuje vôbec nič, znamená, že problém je vyššie proti prúdu od hostiteľa.
sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'
sudo nft list ruleset | grep -i -A2 1701
sudo ss -lunp | grep 1701
Odposluch potvrdzuje prvú polovicu výmeny a ukazuje, či partner odpovedá. Zoznam pravidiel ukazuje, či pravidlo 1701 existuje a kde stojí voči akejkoľvek politike zahadzovania. Zoznam socketov potvrdzuje, že démon L2TP je naviazaný a počúva, čo vylučuje službu, ktorá sa nikdy nespustila. Prečítajte si všetky tri pred zmenou pravidla, pretože chýbajúci poslucháč a filtrovaný port dávajú od používateľa rovnaké sťažnosti.
Čo skenovanie portov nemôže ukázať
Vonkajšie skenovanie UDP 1701 voči správne nakonfigurovanému serveru zvyčajne nič nehlási a to je očakávaný výsledok. Port nie je vystavený do internetu; dosiahne sa len po tom, čo IPsec overil partnera. Ak uzavretý výsledok považujete za poruchu, otvoríte port, ktorý by mal zostať zatvorený. Skenovanie nevidí dovnútra tunela rovnako, ako nevidí prevádzku aplikácie.
Namiesto toho testujte skutočným klientom a prečítajte, do ktorej fázy sa dostane. Ak sa spojenie vyjedná a potom zasekne, podozrivý je démon L2TP alebo miestny filter; ak sa nikdy nevyjedná, na vine sú vonkajšie porty. Toto jediné rozdelenie odstráni väčšinu hádania o tom, ktoré pravidlo pridať, a vrstvenie protokolov z toho robí predvídateľnú vec namiesto záhady.