L2TP/IPsec cez NAT: čo sa naozaj láme a prečo

Tvrdenie, že NAT láme L2TP/IPsec, je spolovice pravdivé, a preto nepoužiteľné. Preklad adries je normálny, NAT traversal existuje práve preto, aby ho prežil, a milióny klientov sa každý deň pripájajú spoza routera. Láme sa konkrétna fáza konkrétnej výmeny: IKE nikdy nedostane odpoveď, zapuzdrený tunel zahodí politika, ktorá povoľuje len jeden protokol, alebo mapovanie prekladu vyprší, kým je tunel nečinný. Keď viete, v ktorej fáze ste, oprava je zvyčajne jedno pravidlo alebo keepalive, nie nový návrh VPN.

Mýtus je nesprávna otázka

Užitočná otázka nie je „láme to NAT“, ale „ktorá časť výmeny sa prekladá a čo s ňou robí zariadenie, ktoré prekladá“. L2TP/IPsec je vrstvený protokol: IKE vyjednáva, ESP chráni a L2TP nesie PPP vnútri tejto ochrany. Preklad adries pôsobí na každú vrstvu inak, a podpisy zlyhania sa dajú rozlíšiť, ak sa pozeráte na fázu vyjednávania a nie na dialóg chyby.

Router, ktorý úspešne prehliada web, dokazuje len to, že TCP s prekladom zdrojového portu funguje. Nič nehovorí o UDP 500, UDP 4500 ani protokole 50, a práve na týchto troch veciach závisí toto nasadenie.

Fáza 1: IKE musí vôbec dostať odpoveď

Prvá výmena ide k odpovedajúcej strane na UDP 500. Ak sa nevráti odpoveď, nič ďalšie nie je dôležité: predzdieľaný kľúč, návrh aj prihlasovacie údaje zostanú neprečítané. Sledujte požiadavku a odpoveď, namiesto toho, aby ste usudzovali z časového limitu klienta:

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

Požiadavka bez odpovede zvyčajne znamená, že firewall alebo operátor vyššie na ceste paket zahadzuje, nie že ho server odmietol. Odpoveď s oznamovacím užitočným zaťažením, ktorá uvádza návrh alebo problém s certifikátom, znamená, že pakety dorazili a vyjednávanie zlyhalo na obsahu, čo je úplne iná oprava.

Keď sú obe strany za prekladom, iniciátor musí len dosiahnuť odpovedajúcu stranu, takže väčšina nasadení na strane klienta funguje od fázy 1. Hosting na strane servera je miesto, kde začína problém s prichádzajúcou prevádzkou, a preto by sa tieto dve situácie nikdy nemali rozoberať ako jedna.

Fáza 2: zapuzdrenie mení to, čo firewall vidí

ESP je IP protokol, nie TCP alebo UDP port, a bežný preklad adries portov nemá pole portu, ktoré by prepísal. Preto NAT traversal presúva chránený obsah do UDP 4500: zapuzdrenie dáva prekladajúcemu zariadeniu niečo, čo vie preložiť. Keď sa to stane, pravidlo firewallu napísané len pre UDP 500 povolí vyjednávanie a zahodí tunel, čo dáva mätúci výsledok, keď log ukazuje úspešnú fázu 1 a žiadnu prevádzku.

Samotná výmena IKE sa tiež môže presunúť na UDP 4500 po zistení NAT, čo prekvapí ľudí, ktorí povolili 500 a nič iné. Povoľte oba porty v oboch smeroch na ceste a pamätajte, že stavový firewall drží tok len dovtedy, kým vidí prevádzku.

Protokol 50 je stále dôležitý na cestách bez prekladu a na cestách, kde je medziľahlé zariadenie nakonfigurované, aby ho povoľovalo. Ak diagnostikujete vylučovaním, vypnite hypotézu, namiesto pridávania pravidiel hromadne: povoľte 500, 4500 a ESP, potvrďte, že tunel naskočí, a potom odstráňte to, čo sa ukázalo ako zbytočné. Pravidlo, ktoré nikto nevie vysvetliť, je pravidlo, ktoré nikto neodstráni, keď sa stane príčinou ďalšieho výpadku. Zapíšte zúženie do záznamu o zmene spolu s fázou, ktorú opravilo, aby ďalší inženier začal od vašich dôkazov, nie od rovnakého pravidla palca.

Fáza 3: mapovanie vyprší a tunel zomrie

Prekladajúce zariadenie drží stav pre toky, ktoré preposiela, a tento stav má životnosť. Tunel L2TP/IPsec prenáša málo prevádzky, keď ho nikto nepoužíva, takže nečinný tunel môže prežiť svoje mapovanie a prestať prijímať návratovú prevádzku. Klient zostáva presvedčený, že je pripojený, server nič nevidí, a prvým príznakom je zvyčajne časový limit aplikácie, nie chyba VPN.

Detekcia mŕtveho partnera a NAT keepalive existujú práve preto a obe strany ich musia byť ochotné posielať. Ak je váš server za prekladom, požiadavka na strane Windows je dokumentované nastavenie registra, ktoré prinúti server predpokladať UDP zapuzdrenie pre jeho vlastné odchádzajúce pakety; bez neho odpovedajúca strana posiela ESP, ktoré prekladajúce zariadenie nedokáže namapovať späť. Je to otázka konfigurácie servera, nie klienta.

Zmena adresy WAN dáva rovnaký výsledok z iného smeru: mapovanie sa znova postaví okolo novej adresy a stará bezpečnostná asociácia teraz ukazuje na dvojicu, ktorá už neexistuje. Správanie pri opätovnom pripojení patrí implementácii klienta, a preto „pripoj sa znova po reštarte routera“ funguje na jednom klientovi a na druhom vyžaduje ručný prepínač.

Hosting za operátorským NAT je iný problém

Ak chcete hostovať server L2TP/IPsec doma a dosiahnuť naň zvonku, požiadavkou je nevyžiadaná príchodzia dostupnosť, a to NAT traversal neposkytuje. Operátorský NAT pred vaším routerom znamená, že neexistuje port, ktorý by ste mohli presmerovať a stať sa dostupnými, pretože verejná adresa je zdieľaná a mapovanie je len odchádzajúce.

Žiadne zaškrtávacie políčko IPsec pass-through to nezmení a žiadna konfigurácia klienta to nevykompenzuje. Podporované odpovede sú adresa, ktorá je skutočne dostupná, hostovaný koncový bod alebo architektúra, v ktorej každý účastník vytvára odchádzajúce spojenie. Špecifikácia UDP zapuzdrenia rieši problém prekladu pre toky, ktoré existujú; nevytvára príchodziu cestu tam, kde ju operátor neponúka.

Preto porovnávajte siete, namiesto hádania. Vezmite rovnaké zariadenie a profil do inej povolenej siete a pozrite, ktorá fáza tam zlyhá. Ak to funguje inde, rozdiel je na ceste, a to zúži hľadanie na tri fázy vyššie namiesto celej konfigurácie.