L2TP/IPsec prin NAT: ce se rupe de fapt și de ce

Afirmația că NAT strică L2TP/IPsec este pe jumătate adevărată și, prin urmare, inutilă. Traducerea adreselor este normală, traversal NAT există exact ca să o supraviețuiască, și milioane de clienți se conectează zilnic din spatele unui router. Ce se rupe este o etapă anume a unui schimb anume: IKE nu primește niciodată răspuns, tunelul încapsulat este aruncat de o politică ce permite doar un protocol, sau maparea traducerii expiră în timp ce tunelul este inactiv. Odată ce știți în ce etapă sunteți, remedierea este de obicei o singură regulă sau un keepalive, nu un design nou de VPN.

Mitul este întrebarea greșită

Întrebarea utilă nu este „strică NAT asta”, ci „ce parte a schimbului este tradusă și ce face cu ea dispozitivul care traduce”. L2TP/IPsec este un protocol pe straturi: IKE negociază, ESP protejează, iar L2TP transportă PPP în interiorul acelei protecții. Traducerea adreselor interacționează diferit cu fiecare strat, iar semnăturile defecțiunii se pot distinge dacă priviți etapa de negociere și nu dialogul de eroare.

Un router care navighează pe web cu succes dovedește doar că TCP cu traducere de port sursă funcționează. Nu spune nimic despre UDP 500, UDP 4500 sau protocolul 50, și exact aceste trei lucruri sunt cele de care depinde acest deployment.

Etapa 1: IKE trebuie să primească măcar un răspuns

Primul schimb merge la responder pe UDP 500. Dacă nu se întoarce niciun răspuns, nimic altceva nu contează: cheia prepartajată, propunerea și credențialele rămân necitite. Urmăriți cererea și răspunsul în loc să deduceți din timeout-ul clientului:

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

O cerere fără răspuns înseamnă de obicei că un firewall sau operatorul de deasupra aruncă pachetul, nu că serverul l-a respins. Un răspuns cu o încărcătură de notificare care numește o propunere sau o problemă de certificat înseamnă că pachetele au ajuns și negocierea a eșuat pe conținut, ceea ce este o reparație complet diferită.

Când ambele părți sunt în spatele traducerii, inițiatorul trebuie doar să ajungă la responder, așa că majoritatea implementărilor de pe partea clientului funcționează din etapa 1. Găzduirea pe partea serverului este locul unde începe problema de intrare, și de aceea cele două situații nu ar trebui niciodată discutate ca una singură.

Etapa 2: încapsularea schimbă ce vede firewallul

ESP este un protocol IP, nu un port TCP sau UDP, iar traducerea obișnuită de adrese de porturi nu are niciun câmp de port de rescris. De aceea traversal NAT mută încărcătura protejată în UDP 4500: încapsularea îi dă dispozitivului care traduce ceva ce știe să traducă. Odată ce asta se întâmplă, o regulă de firewall scrisă doar pentru UDP 500 permite negocierea și aruncă tunelul, ceea ce produce rezultatul confuz în care jurnalul arată o fază 1 reușită și niciun trafic.

Schimbul IKE în sine poate trece și el pe UDP 4500 după detectarea unui NAT, ceea ce îi surprinde pe cei care au permis 500 și nimic altceva. Permiteți ambele porturi în ambele direcții pe cale, și țineți minte că un firewall cu stare ține fluxul doar cât timp vede trafic.

Protocolul 50 contează în continuare pe căi fără traducere, și pe căi unde un echipament intermediar este configurat să îl permită. Dacă diagnosticați prin eliminare, opriți ipoteza în loc să adăugați reguli în bloc: permiteți 500, 4500 și ESP, confirmați că tunelul urcă, apoi eliminați ce s-a dovedit inutil. O regulă pe care nimeni nu o poate explica este o regulă pe care nimeni nu o va elimina atunci când devine cauza următoarei căderi. Scrieți restrângerea în jurnalul de modificări împreună cu etapa pe care a corectat-o, ca următorul inginer să pornească de la dovezile dumneavoastră și nu de la aceeași regulă empirică.

Etapa 3: maparea expiră și tunelul moare

Un dispozitiv care traduce ține stare pentru fluxurile pe care le redirecționează, iar acea stare are o durată de viață. Un tunel L2TP/IPsec transportă puțin trafic când nimeni nu îl folosește, așa că un tunel inactiv poate supraviețui mapării sale și poate înceta să mai primească trafic de retur. Clientul rămâne convins că este conectat, serverul nu vede nimic, iar primul simptom este de obicei un timeout de aplicație și nu o eroare VPN.

Detectarea peerului mort și keepalive-urile NAT există pentru asta, iar ambele capete trebuie să fie dispuse să le trimită. Dacă serverul dumneavoastră este în spatele traducerii, cerința pe partea Windows este o setare de registru documentată care face serverul să presupună încapsulare UDP pentru propriile pachete de ieșire; fără ea, responderul trimite ESP pe care dispozitivul care traduce nu îl poate mapă înapoi. Este o problemă de configurare a serverului, nu a clientului.

O schimbare de adresă WAN produce același rezultat din altă direcție: maparea este reconstruită în jurul unei adrese noi, iar vechea asociere de securitate indică acum un tuplu care nu mai există. Comportamentul de reconectare aparține implementării clientului, și de aceea „reconectează-te după repornirea routerului” funcționează pe un client și pe altul necesită un comutator manual.

Găzduirea în spatele unui NAT de operator este o problemă diferită

Dacă vreți să găzduiți un server L2TP/IPsec acasă și să îl atingeți din exterior, cerința este accesibilitatea de intrare nesolicitată, iar asta nu este ceea ce oferă traversal NAT. Un NAT de operator în fața routerului dumneavoastră înseamnă că nu există niciun port pe care să îl puteți redirecționa și care să vă facă accesibil, pentru că adresa publică este partajată, iar maparea este doar de ieșire.

Nicio casetă IPsec pass-through nu schimbă asta, iar nicio configurație de client nu o compensează. Răspunsurile acceptate sunt o adresă chiar accesibilă, un punct final găzduit sau o arhitectură în care fiecare participant face o conexiune de ieșire. Specificația de încapsulare UDP rezolvă problema traducerii pentru fluxurile care există; ea nu creează o cale de intrare unde operatorul nu oferă una.

Deci comparați rețele în loc să ghiciți. Duceți același dispozitiv și profil într-o altă rețea permisă și vedeți care etapă eșuează acolo. Dacă funcționează altundeva, diferența este pe cale, iar asta restrânge căutarea la cele trei etape de mai sus în loc de întreaga configurație.