NAT hairpin: de ce punctul final VPN eșuează din interior

Un server VPN care răspunde dintr-o rețea mobilă, dar eșuează de pe canapea, de obicei nu este o problemă de certificat. Clientul din interiorul LAN-ului cere routerului să traducă un pachet a cărui destinație este adresa publică proprie a routerului, ceea ce înseamnă că pachetul trebuie să iasă și să reintre imediat. Această manevră se numește hairpinning, și multe routere fie nu o implementează, fie o fac doar când o casetă este bifată. Tocmai succesul testului din exterior încurcă lucrurile, pentru că dovedește că listenerul și regula de redirecționare sunt în ordine.

Pachetul iese și reintră

Urmăriți pachetul. Clientul rezolvă numele public, se conectează la adresa publică, iar NAT-ul de destinație al routerului rescrie destinația către serverul intern. Răspunsul serverului este adresat adresei LAN a clientului, așa că se întoarce prin interfața LAN a routerului fără a trece vreodată prin regula NAT care ar fi retradus sursa.

Acum clientul primește un pachet de la o adresă căreia nu i-a trimis niciodată nimic și îl aruncă. Această asimetrie este toată defecțiunea.

RFC 4787 descrie comportamentul așteptat de la un NAT în acest caz, iar versiunea scurtă este că în practică este opțional chiar și acolo unde este specificat teoretic. Unele routere numesc setarea NAT loopback, altele o numesc hairpin NAT sau NAT reflection, iar unele nu expun nimic. Un router care nu o are nu este configurat greșit; face lucrul obișnuit, iar remedierea aparține altundeva. Nu concluzionați dintr-un test local eșuat că regula publică de redirecționare este greșită.

Verificarea 1: testați cele două căi separat

Din afara LAN-ului, conectați-vă cu același profil pe care l-ar folosi un utilizator real și confirmați că sesiunea se stabilește. Din interior, conectați-vă la adresa publică cu același profil și notați eroarea exactă și ora.

Un test local precis păstrează numele gazdă și înlocuiește doar adresa: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ trimite cererea către adresa publică prezentând în continuare numele corect al serverului. Asta separă o problemă de rezolvare a numelor de o problemă de traducere, ușor de confundat când același nume funcționează dintr-o cafenea. Observați dacă clientul eșuează la conectarea TCP sau mai târziu la TLS, pentru că prima indică traducerea, iar a doua identitatea.

Verificarea 2: citiți ce vede serverul

Cea mai utilă observație este viziunea serverului. Rulați o captură pe gazda VPN filtrată pe adresa LAN a clientului și pe adresa LAN a routerului, apoi repetați încercarea locală. Dacă nu sosește nimic, pachetul nu a supraviețuit traducerii.

Dacă o conexiune sosește de la adresa LAN a routerului în loc de cea a clientului, are loc hairpinning și sursa a fost rescrisă. Aceasta este o configurație funcțională, nu o defecțiune.

Verificarea 3: remediați fără a atinge calea externă

Există trei forme acceptate, în ordinea crescătoare a razei de impact. Cea mai îngustă este DNS-ul divizat: publicați o înregistrare internă astfel încât același nume de server să se rezolve la adresa internă pentru clienții din LAN, ceea ce ocolește complet calea publică. Următoarea este activarea opțiunii documentate de loopback sau reflection a routerului, dacă există, și aplicarea ei doar acestui serviciu. Cea mai largă este o regulă source-NAT pe router care rescrie traficul din LAN către server, astfel încât răspunsul să revină prin router; pe un router Linux este o regulă MASQUERADE în POSTROUTING care corespunde adresei și portului serverului. Toate trei lasă calea externă neatinsă, și aceasta este proprietatea care trebuie păstrată.

Nu extindeți redirecționarea de porturi fără legătură pentru ca calea locală să semene cu cea externă și nu mutați serviciul pe alt port pentru a ocoli problema. Ambele modificări schimbă ce poate atinge lumea exterioară pentru a repara ceva ce vede doar lumea interioară.

DNS-ul divizat are o capcană care merită numită. Înlocuirea unui nume de gazdă cu un IP arbitrar schimbă ce validează clientul, așa că înregistrarea internă trebuie să corespundă în continuare numelui din certificat.

Verificarea 4: verificați ambele căi după aceea

Repetați încercarea externă din afara LAN-ului, repetați încercarea internă cu același profil și confirmați că jurnalul serverului arată două sesiuni reușite distincte, nu un succes și o tăcere. Apoi verificați că ceilalți clienți ajung în continuare la listener și că rutele către resursele private nu s-au schimbat.

Țineți evidența scurtă: ce adresă a folosit fiecare client, ce a văzut serverul și care dintre cele trei remedieri a fost aplicată. Cerințele de hairpinning din RFC 4787 sunt referința pentru ce se așteaptă de la un NAT aici, și explică de ce un router fără această funcție se comportă normal. O defecțiune locală pe care lumea exterioară nu o poate reproduce este o chestiune de traducere până la proba contrarie, așa că testați-o ca atare.