L2TP/IPsec skozi NAT: kaj se v resnici zlomi in zakaj

Trditev, da NAT zlomi L2TP/IPsec, je napol resnična in zato neuporabna. Prevajanje naslovov je običajno, NAT traversal obstaja prav zato, da ga preživi, in milijoni odjemalcev se vsak dan povežejo izza usmerjevalnika. Zlomi se določena stopnja določene izmenjave: IKE nikoli ne dobi odgovora, zapakirani tunel se zavrže s pravilom, ki dovoljuje samo en protokol, ali preslikava prevajanja poteče, medtem ko tunel miruje. Ko veste, na kateri stopnji ste, je popravek običajno eno pravilo ali keepalive, ne nova zasnova VPN.

Mit je napačno vprašanje

Uporabno vprašanje ni „ali NAT to zlomi“, ampak „kateri del izmenjave se prevaja in kaj z njim počne naprava, ki prevaja“. L2TP/IPsec je večplastni protokol: IKE se pogaja, ESP ščiti, in L2TP prenaša PPP znotraj te zaščite. Prevajanje naslovov vpliva na vsak sloj drugače, in podpise napak je mogoče razlikovati, če gledate stopnjo pogajanj in ne pogovorno okno z napako.

Usmerjevalnik, ki uspešno brska po spletu, dokazuje le, da TCP s prevajanjem izvornih vrat deluje. Ne pove ničesar o UDP 500, UDP 4500 ali protokolu 50, in prav od teh treh stvari je odvisna ta postavitev.

Stopnja 1: IKE mora sploh dobiti odgovor

Prva izmenjava gre k odgovarjajoči strani na UDP 500. Če se ne vrne noben odgovor, nič drugega ni pomembno: vnaprej deljeni ključ, predlog in poverilnice ostanejo neprebrani. Spremljajte zahtevo in odgovor, namesto da sklepate iz časovne omejitve odjemalca:

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

Zahteva brez odgovora običajno pomeni, da požarni zid ali operater višje na poti zavrže paket, ne da ga je strežnik zavrnil. Odgovor z obvestilno obremenitvijo, ki navaja predlog ali težavo s potrdilom, pomeni, da so paketi prispeli in da so pogajanja propadla zaradi vsebine, kar je povsem drugačna popravka.

Ko sta obe strani za prevajanjem, mora pobudnik le doseči odgovarjajočo stran, zato večina postavitev na strani odjemalca deluje od stopnje 1. Gostovanje na strani strežnika je mesto, kjer se začne težava z dohodnim prometom, in zato teh dveh položajev nikoli ne bi smeli obravnavati kot enega.

Stopnja 2: zapakiranje spremeni, kaj vidi požarni zid

ESP je protokol IP, ne vrata TCP ali UDP, in običajno prevajanje naslovov vrat nima polja za vrata, ki bi ga prepisalo. Zato NAT traversal premakne zaščiteno obremenitev v UDP 4500: zapakiranje da napravi, ki prevaja, nekaj, kar zna prevesti. Ko se to zgodi, bo pravilo požarnega zidu, napisano samo za UDP 500, dovolilo pogajanja in zavrglo tunel, kar da zmeden rezultat, kjer dnevnik kaže uspešno fazo 1 in nobenega prometa.

Sama izmenjava IKE se lahko po zaznavi NAT premakne na UDP 4500, kar preseneti tiste, ki so dovolili 500 in nič drugega. Dovolite obe vrati v obe smeri na poti in ne pozabite, da požarni zid s stanjem zadrži tok le toliko časa, dokler vidi promet.

Protokol 50 je še vedno pomemben na poteh brez prevajanja in na poteh, kjer je vmesna naprava nastavljena, da ga dovoli. Če diagnosticirate z izločanjem, izklopite hipotezo, namesto da dodajate pravila v paketih: dovolite 500, 4500 in ESP, potrdite, da se tunel dvigne, nato odstranite, kar se je izkazalo za nepotrebno. Pravilo, ki ga nihče ne zna razložiti, je pravilo, ki ga nihče ne bo odstranil, ko postane vzrok naslednje prekinitve. Zapišite zožitev v dnevnik sprememb skupaj s stopnjo, ki jo je popravila, da bo naslednji inženir začel z vašimi dokazi in ne z istim pravilom palca.

Stopnja 3: preslikava poteče in tunel umre

Naprava, ki prevaja, hrani stanje za tokove, ki jih posreduje, in to stanje ima življenjsko dobo. Tunel L2TP/IPsec prenaša malo prometa, ko ga nihče ne uporablja, zato lahko nedejaven tunel preživi svojo preslikavo in preneha prejemati povratni promet. Odjemalec ostane prepričan, da je povezan, strežnik ne vidi ničesar, in prvi simptom je običajno časovna omejitev aplikacije, ne napaka VPN.

Zaznavanje mrtvega partnerja in keepalive NAT obstajata prav za to, in oba konca morata biti pripravljena, da ju pošiljata. Če je vaš strežnik za prevajanjem, je zahteva na strani Windows dokumentirana nastavitev registra, zaradi katere strežnik domneva zapakiranje UDP za svoje lastne odhodne pakete; brez nje odgovarjajoča stran pošilja ESP, ki ga naprava, ki prevaja, ne more preslikati nazaj. To je vprašanje konfiguracije strežnika, ne odjemalca.

Sprememba naslova WAN da enak izid z druge strani: preslikava se znova zgradi okoli novega naslova, in stara varnostna povezava zdaj kaže na dvojico, ki ne obstaja več. Vedenje pri ponovnem povezovanju spada k izvedbi odjemalca, in zato „ponovno se poveži po ponovnem zagonu usmerjevalnika“ deluje pri enem odjemalcu, pri drugem pa zahteva ročno stikalo.

Gostovanje za operaterjevim NAT je druga težava

Če želite doma gostiti strežnik L2TP/IPsec in ga doseči od zunaj, je zahteva nezahtevana dohodna dosegljivost, in tega NAT traversal ne ponuja. Operaterjev NAT pred vašim usmerjevalnikom pomeni, da ni vrat, ki bi jih lahko posredovali in postali dosegljivi, ker je javni naslov deljen in je preslikava samo odhodna.

Nobeno potrditveno polje IPsec pass-through tega ne spremeni in nobena konfiguracija odjemalca tega ne nadomesti. Podprti odgovori so naslov, ki je res dosegljiv, gostovana končna točka ali arhitektura, v kateri vsak udeleženec vzpostavi odhodno povezavo. Specifikacija zapakiranja UDP reši težavo prevajanja za tokove, ki obstajajo; ne ustvari dohodne poti tam, kjer je operater ne ponuja.

Zato primerjajte omrežja, namesto da ugibate. Odnesite isto napravo in profil v drugo dovoljeno omrežje in poglejte, katera stopnja tam odpove. Če deluje drugje, je razlika na poti, in to zoži iskanje na tri stopnje zgoraj namesto na celotno konfiguracijo.