L2TP/IPsec přes NAT: co se skutečně láme a proč

Tvrzení, že NAT láme L2TP/IPsec, je z poloviny pravdivé, a proto nepoužitelné. Překlad adres je normální, NAT traversal existuje právě proto, aby ho přežil, a miliony klientů se každý den připojují zpoza routeru. Láme se konkrétní fáze konkrétní výměny: IKE nikdy nedostane odpověď, zapouzdřený tunel zahodí politika, která povoluje jen jeden protokol, nebo překladový záznam vyprší, zatímco tunel nečinně stojí. Jakmile víte, v které fázi jste, oprava je obvykle jediné pravidlo nebo keepalive, nikoli nový návrh VPN.

Mýtus je špatná otázka

Užitečná otázka není „láme to NAT“, ale „která část výměny se překládá a co s ní dělá zařízení, které překlad provádí“. L2TP/IPsec je vrstvený protokol: IKE vyjednává, ESP chrání a L2TP nese PPP uvnitř této ochrany. Překlad adres působí na každou vrstvu jinak a podpisy selhání lze rozlišit, když se díváte na fázi vyjednávání, nikoli na dialog chyby.

Router, který úspěšně prohlíží web, dokazuje jen to, že TCP s překladem zdrojového portu funguje. Nic neříká o UDP 500, UDP 4500 ani protokolu 50, a na těchto třech věcech toto nasazení závisí.

Fáze 1: IKE musí vůbec dostat odpověď

První výměna jde k odpovídající straně na UDP 500. Pokud se nevrátí odpověď, nic dalšího nezáleží: předem sdílený klíč, návrh i přihlašovací údaje zůstanou nepřečtené. Sledujte požadavek a odpověď, místo abyste usuzovali z vypršení časového limitu klienta:

sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas

Požadavek bez odpovědi obvykle znamená, že firewall nebo operátor výše na cestě paket zahazuje, ne že ho server odmítl. Odpověď s oznamovacím užitečným zatížením, které uvádí návrh nebo problém s certifikátem, znamená, že pakety dorazily a vyjednávání selhalo na obsahu, což je zcela jiná oprava.

Když jsou obě strany za překladem, iniciátor musí jen dosáhnout odpovídající strany, takže většina nasazení na straně klienta funguje od fáze 1. Hostování na straně serveru je místo, kde začíná problém s příchozím provozem, a proto by se tyto dvě situace nikdy neměly probírat jako jedna.

Fáze 2: zapouzdření mění to, co firewall vidí

ESP je IP protokol, ne TCP nebo UDP port, a běžný překlad adres portů nemá pole portu, které by přepsal. Proto NAT traversal přesouvá chráněný obsah do UDP 4500: zapouzdření dává překládajícímu zařízení něco, co umí přeložit. Jakmile se to stane, pravidlo firewallu napsané jen pro UDP 500 povolí vyjednávání a zahodí tunel, což dává matoucí výsledek, kdy log ukazuje úspěšnou fázi 1 a žádný provoz.

Samotná výměna IKE se také může přesunout na UDP 4500 poté, co je zjištěn NAT, což překvapuje lidi, kteří povolili 500 a nic jiného. Povolte oba porty v obou směrech na cestě a pamatujte, že stavový firewall může tok držet jen dokud vidí provoz.

Protokol 50 je stále důležitý na cestách bez překladu a na cestách, kde je mezilehlé zařízení nakonfigurováno, aby ho povolilo. Pokud diagnostikujete vylučováním, vypněte hypotézu, místo abyste přidávali pravidla hromadně: povolte 500, 4500 a ESP, potvrďte, že tunel naskočí, a pak odstraňte to, co se ukázalo jako zbytečné. Pravidlo, které nikdo nedokáže vysvětlit, je pravidlo, které nikdo neodstraní, když se stane příčinou dalšího výpadku. Zapište zúžení do záznamu o změně spolu s fází, kterou opravilo, aby další inženýr začal od vašich důkazů, ne od stejného pravidla palce.

Fáze 3: překlad vyprší a tunel umře

Překládající zařízení drží stav pro toky, které předává, a tento stav má životnost. Tunel L2TP/IPsec přenáší málo provozu, když ho nikdo nepoužívá, takže nečinný tunel může přežít svůj překlad a přestat přijímat návratový provoz. Klient zůstává přesvědčen, že je připojen, server nic nevidí a prvním příznakem je obvykle vypršení aplikace, nikoli chyba VPN.

Detekce mrtvého protějšku a NAT keepalive existují právě pro to a obě strany je musí být ochotny posílat. Pokud je váš server za překladem, požadavek na straně Windows je dokumentované nastavení registru, které přiměje server předpokládat UDP zapouzdření pro jeho vlastní odchozí pakety; bez něj odpovídající strana posílá ESP, které překládající zařízení nedokáže namapovat zpět. To je otázka konfigurace serveru, ne klienta.

Změna adresy WAN dává stejný výsledek z jiného směru: překlad se znovu postaví kolem nové adresy a stará bezpečnostní asociace nyní ukazuje na dvojici, která už neexistuje. Chování při opětovném připojení patří implementaci klienta, a proto „připojit znovu po restartu routeru“ funguje u jednoho klienta a u jiného vyžaduje ruční přepínač.

Hostování za operátorským NAT je jiný problém

Pokud chcete hostovat server L2TP/IPsec doma a dosáhnout na něj zvenčí, požadavkem je nevyžádaná příchozí dosažitelnost, a to není to, co NAT traversal poskytuje. Operátorský NAT před vaším routerem znamená, že neexistuje port, který byste mohli přesměrovat a být dosažitelní, protože veřejná adresa je sdílená a překlad je pouze odchozí.

Žádné zaškrtávací políčko IPsec pass-through to nezmění a žádná konfigurace klienta to nevykompenzuje. Podporované odpovědi jsou adresa, která je skutečně dosažitelná, hostovaný koncový bod nebo architektura, v níž každý účastník vytváří odchozí spojení. A specifikace UDP zapouzdření řeší problém překladu pro toky, které existují; nevytváří příchozí cestu tam, kde ji operátor nenabízí.

Proto porovnávejte sítě, místo abyste hádali. Vezměte stejné zařízení a profil do jiné povolené sítě a sledujte, která fáze tam selže. Pokud to jinde funguje, rozdíl je na cestě, a to zúží hledání na tři fáze výše místo celé konfigurace.