Proč L2TP/IPsec potřebuje UDP 1701 vedle IPsec

Firewally, které povolují IKE a ESP, ale ne UDP 1701, rozbíjejí L2TP spojení způsobem, který vypadá jako problém s přihlašovacími údaji. Důvodem je, že L2TP je druhý protokol, který jede uvnitř prvního. IPsec přenáší a ověřuje výměnu a L2TP provozuje svůj vlastní tunel přes UDP 1701, který musí místní stack stejně doručit. Vědět, kde se objevuje každá hlavička, vysvětluje, které zařízení potřebuje které pravidlo.

Dva protokoly, dvě sady portů

Spojení L2TP/IPsec používá IKE na UDP 500, průchod NAT na UDP 4500 tam, kde je překlad, a ESP jako IP protokol 50 tam, kde není. Samotné L2TP je tunelový protokol na UDP 1701 a běží poté, co IPsec ověřil protějšek. Obě poloviny selhávají různě a řádky protokolu, které o nich informují, pocházejí z různých komponent. Sada pravidel pokrývající jen první polovinu vytvoří spojení, které se dohodne a pak zemře ve fázi tunelu.

Čísla portů popisují transportní koncové body a ESP vůbec není port. Proto rozhraní firewallu, které nabízí jen pravidla TCP a UDP, nemůže vyjádřit úplnou politiku IPsec. Protokol 50 musí být povolen jako protokol a pravidlo, které zmiňuje jen UDP, s ním nikdy nesedne.

Obal vysvětluje port

Na síti spojení L2TP/IPsec obvykle ukazuje IKE na 500 a zapouzdřené ESP na 4500. Hlavička UDP 1701 sedí uvnitř chráněného užitečného zatížení, a proto ji odposlech na vnějším rozhraní neukáže. Místní hostitel musí tento datagram stejně doručit démonu L2TP a doručení proběhne po dekapsulaci. Pravidlo 1701 proto patří na firewall samotného koncového bodu, i když port nikdy nevidí žádné mezilehlé zařízení.

Pořadí zpracování vysvětluje většinu zmatku. Pokud stack použije politiku IPsec před filtrem hostitele, dekapsulovaný paket L2TP se shoduje jako UDP 1701; pokud je pořadí obrácené, sada pravidel vidí vnější porty. Oba způsoby chování v praxi existují, a proto stejná sada pravidel vypadá funkční na jedné platformě a selhává na jiné.

Zkontrolujte cestu popořadě

Nejprve zachyťte vnější rozhraní a potvrďte, že IKE a zapouzdřené ESP proudí oběma směry. Potom zkontrolujte místní čítače firewallu pro dekapsulovaný provoz. Pořadí je důležité, protože odposlech, který neukazuje vůbec nic, znamená, že problém je výš proti proudu od hostitele.

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

Odposlech potvrzuje první polovinu výměny a ukazuje, zda protějšek odpovídá. Výpis pravidel ukazuje, zda pravidlo 1701 existuje a kde stojí vůči jakékoli politice zahazování. Výpis socketů potvrzuje, že démon L2TP je navázán a naslouchá, což vylučuje službu, která se nikdy nespustila. Přečtěte si všechny tři údaje před změnou pravidla, protože chybějící posluchač a filtrovaný port dávají od uživatele totožné stížnosti.

Co skenování portů nemůže ukázat

Vnější skenování UDP 1701 proti správně nakonfigurovanému serveru obvykle nic nehlásí a to je očekávaný výsledek. Port není vystaven do internetu; dosáhne se ho jen poté, co IPsec ověřil protějšek. Pokud uzavřený výsledek považujete za závadu, otevřete port, který má zůstat zavřený. Skenování nevidí dovnitř tunelu stejně jako nevidí provoz aplikace.

Místo toho testujte skutečným klientem a přečtěte, do které fáze se dostane. Pokud se spojení dohodne a pak se zasekne, podezřelý je démon L2TP nebo místní filtr; pokud se nikdy nedohodne, jsou na vině vnější porty. Toto jediné rozdělení odstraní většinu hádání o tom, které pravidlo přidat, a vrstvení protokolů z toho dělá předvídatelnou věc místo záhady.