L2TP/IPsec kroz NAT: šta zapravo puca i zašto

Tvrdnja da NAT kvari L2TP/IPsec napola je tačna i zato beskorisna. Prevođenje adresa je normalno, NAT traversal postoji upravo da bi ga preživio, i milioni klijenata se svakog dana povezuju iza rutera. Puca određena faza određenog razgovora: IKE nikad ne dobije odgovor, inkapsulirani tunel bude odbačen politikom koja dozvoljava samo jedan protokol, ili mapiranje prevođenja istekne dok tunel miruje. Kad znate u kojoj ste fazi, popravka je obično jedno pravilo ili keepalive, a ne novi dizajn VPN-a.

Mit je pogrešno pitanje

Korisno pitanje nije „kvari li NAT ovo“ nego „koji se dio razgovora prevodi i šta uređaj koji prevodi radi s njim“. L2TP/IPsec je slojeviti protokol: IKE pregovara, ESP štiti, a L2TP nosi PPP unutar te zaštite. Prevođenje adresa utječe na svaki sloj drugačije, a potpisi kvara se razlikuju ako gledate fazu pregovora, a ne dijalog greške.

Ruter koji uspješno pregledava web dokazuje samo da TCP s prevođenjem izvornog porta radi. Ne govori ništa o UDP 500, UDP 4500 ili protokolu 50, a o tome troje ovisi ovo postavljanje.

Faza 1: IKE uopće mora dobiti odgovor

Prvi razgovor ide prema strani koja odgovara na UDP 500. Ako odgovor ne dođe, ništa drugo nije važno: unaprijed dijeljeni ključ, prijedlog i vjerodajnice ostaju nepročitani. Pratite zahtjev i odgovor umjesto da zaključujete iz isteka vremena na klijentu:

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

Zahtjev bez odgovora obično znači da firewall ili operater uzvodno odbacuje paket, a ne da ga je server odbio. Odgovor s obavijesnim teretom koji navodi prijedlog ili problem sa certifikatom znači da su paketi stigli i da su pregovori propali zbog sadržaja, što je sasvim druga popravka.

Kad su obje strane iza prevođenja, inicijator treba samo doći do strane koja odgovara, pa većina postavljanja na strani klijenta radi od faze 1. Hosting na strani servera je mjesto gdje počinje problem s dolaznim prometom i zato se te dvije situacije nikad ne smiju raspravljati kao jedna.

Faza 2: inkapsulacija mijenja ono što firewall vidi

ESP je IP protokol, a ne TCP ili UDP port, i obično prevođenje adresa portova nema polje porta koje bi prepisalo. Zato NAT traversal prebacuje zaštićeni teret u UDP 4500: inkapsulacija daje uređaju koji prevodi nešto što zna prevesti. Kad se to dogodi, pravilo firewalla napisano samo za UDP 500 dozvoljava pregovore i odbacuje tunel, što daje zbunjujući rezultat u kojem zapisnik pokazuje uspješnu fazu 1 i nikakav promet.

Sam IKE razgovor također može prijeći na UDP 4500 nakon što se otkrije NAT, što iznenađuje ljude koji su dozvolili 500 i ništa drugo. Dozvolite oba porta u oba smjera na putu i zapamtite da stateful firewall može držati tok samo dok vidi promet.

Protokol 50 je još važan na putanjama bez prevođenja i na putanjama gdje je međuuređaj konfiguriran da ga dozvoli. Ako dijagnosticirate eliminacijom, isključite hipotezu umjesto da dodajete pravila u hrpi: dozvolite 500, 4500 i ESP, potvrdite da se tunel diže, zatim uklonite ono što se pokazalo nepotrebnim. Pravilo koje nitko ne može objasniti je pravilo koje nitko neće ukloniti kad postane uzrok sljedećeg prekida. Zapišite sužavanje u zapis o promjeni zajedno s fazom koju je popravilo, da sljedeći inženjer počne od vaših dokaza, a ne od istog pravila palca.

Faza 3: mapiranje istekne i tunel umre

Uređaj koji prevodi drži stanje za tokove koje prosljeđuje, a to stanje ima životni vijek. Tunel L2TP/IPsec nosi malo prometa kad ga nitko ne koristi, pa mirni tunel može nadživjeti svoje mapiranje i prestati primati povratni promet. Klijent ostaje uvjeren da je povezan, server ne vidi ništa, a prvi simptom je obično istek vremena aplikacije, a ne greška VPN-a.

Otkrivanje mrtvog partnera i NAT keepalive postoje zbog ovoga i oba kraja moraju biti voljna da ih šalju. Ako je vaš server iza prevođenja, zahtjev na strani Windowsa je dokumentirana postavka registra koja natjera server da pretpostavi UDP inkapsulaciju za vlastite odlazne pakete; bez nje strana koja odgovara šalje ESP koji uređaj za prevođenje ne može mapirati natrag. To je pitanje konfiguracije servera, ne klijenta.

Promjena WAN adrese daje isti ishod iz drugog smjera: mapiranje se obnavlja oko nove adrese, a stara sigurnosna asocijacija sad pokazuje na torku koja više ne postoji. Ponašanje pri ponovnom povezivanju pripada implementaciji klijenta i zato „poveži se ponovo nakon restarta rutera“ radi na jednom klijentu, a na drugom traži ručni prekidač.

Hosting iza NAT-a na razini operatera je drugačiji problem

Ako želite hostati L2TP/IPsec server kod kuće i doći do njega izvana, zahtjev je neželjena dolazna dostupnost, a to nije ono što NAT traversal pruža. NAT na razini operatera ispred vašeg rutera znači da nema porta koji možete proslijediti i učiniti se dostupnim, jer je javna adresa dijeljena, a mapiranje je samo odlazno.

Nijedna kućica za IPsec pass-through to ne mijenja i nikakva konfiguracija klijenta to ne nadoknađuje. Podržani odgovori su adresa koja je stvarno dostupna, hostana krajnja točka ili arhitektura u kojoj svaki sudionik ostvaruje odlaznu vezu. A specifikacija UDP inkapsulacije rješava problem prevođenja za tokove koji postoje; ne stvara dolazni put gdje ga operater ne nudi.

Zato uporedite mreže umjesto da nagađate. Odnesite isti uređaj i profil u drugu dozvoljenu mrežu i pogledajte koja faza tamo podbacuje. Ako radi drugdje, razlika je na putu i to sužava pretragu na tri faze gore umjesto na cijelu konfiguraciju.