Hairpin NAT: zašto VPN odredište ne radi iznutra

VPN server koji odgovara iz mobilne mreže, a ne radi s kauča, obično nije problem sa certifikatom. Klijent unutar LAN-a traži od rutera da prevede paket čije je odredište javna adresa samog rutera, što znači da paket mora izaći i odmah se vratiti. Taj manevar se zove hairpinning, i mnogi ruteri ga ili ne implementiraju ili ga uključuju samo uz označeno polje. Upravo uspješan vanjski test stvara zabunu, jer dokazuje da su slušalac i pravilo prosljeđivanja ispravni.

Paket izlazi i vraća se

Pratite paket. Klijent razrješava javno ime, spaja se na javnu adresu, a odredišni NAT rutera prepisuje odredište na interni server. Odgovor servera adresiran je na LAN adresu klijenta, pa se vraća kroz LAN interfejs rutera, a da nikada ne prođe kroz NAT pravilo koje bi vratilo izvor.

Sada klijent prima paket sa adrese kojoj nikada ništa nije poslao i odbacuje ga. Ta asimetrija je cijeli kvar.

RFC 4787 opisuje ponašanje koje se očekuje od NAT-a u ovom slučaju, a kratka verzija je da je ono u praksi opcionalno čak i tamo gdje je teoretski propisano. Neki ruteri postavku nazivaju NAT loopback, drugi hairpin NAT ili NAT reflection, a neki ne prikazuju ništa. Ruter koji to nema nije pogrešno konfigurisan; on radi uobičajenu stvar, a ispravka pripada negdje drugdje. Ne zaključujte iz neuspjelog lokalnog testa da je javno pravilo prosljeđivanja pogrešno.

Provjera 1: testirajte dvije putanje odvojeno

Izvan LAN-a se povežite s istim profilom koji bi koristio stvarni korisnik i potvrdite da se sesija uspostavlja. Iznutra se povežite na javnu adresu s istim profilom i zabilježite tačnu grešku i vrijeme.

Precizan lokalni test zadržava ime hosta i mijenja samo adresu: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ šalje zahtjev na javnu adresu, a pritom predstavlja ispravno ime servera. To odvaja problem razrješavanja imena od problema prevođenja, koje je lako pobrkati kada isto ime radi iz kafića. Zabilježite da li klijent pada na TCP povezivanju ili kasnije na TLS-u, jer prvo upućuje na prevođenje, a drugo na identitet.

Provjera 2: pročitajte šta server vidi

Najkorisnije zapažanje je pogled servera. Pokrenite snimanje na VPN hostu filtrirano na LAN adresu klijenta i na LAN adresu rutera, pa ponovite lokalni pokušaj. Ako ništa ne stigne, paket nije preživio prevođenje.

Ako veza stiže sa LAN adrese rutera, a ne klijenta, hairpinning se dešava i izvor je prepisan. To je radna konfiguracija, a ne kvar.

Provjera 3: popravite bez diranja vanjske putanje

Postoje tri podržana oblika, u rastućem redu polumjera djelovanja. Najbliži je podijeljeni DNS: objavite interni zapis tako da se isto ime servera razrješava na internu adresu za klijente u LAN-u, što u potpunosti izbjegava javnu putanju. Sljedeći je uključivanje dokumentovane opcije loopback ili reflection na ruteru, ako je ima, i primjena samo na ovu uslugu. Najširi je source-NAT pravilo na ruteru koje prepisuje saobraćaj iz LAN-a prema serveru, tako da se odgovor vraća kroz ruter; na Linux ruteru to je pravilo MASQUERADE u POSTROUTING sa podudaranjem adrese i porta servera. Sva tri ostavljaju vanjsku putanju netaknutom, a to je svojstvo koje treba sačuvati.

Ne širite nepovezano prosljeđivanje portova da bi lokalna putanja ličila na vanjsku i ne premještajte uslugu na drugi port da biste izbjegli problem. Obje promjene mijenjaju šta vanjski svijet može dosegnuti da bi popravile nešto što vidi samo unutrašnji.

Podijeljeni DNS ima jednu zamku koju treba imenovati. Zamjena imena hosta proizvoljnim IP-om mijenja ono što klijent provjerava, pa interni zapis i dalje mora odgovarati imenu u certifikatu.

Provjera 4: nakon toga provjerite obje putanje

Ponovite vanjski pokušaj izvan LAN-a, ponovite unutrašnji pokušaj s istim profilom i potvrdite da dnevnik servera pokazuje dvije odvojene uspješne sesije, a ne jedan uspjeh i jednu tišinu. Zatim provjerite da drugi klijenti i dalje dosegnu slušaoca i da rute do privatnih resursa nisu promijenjene.

Neka zapis bude kratak: koju je adresu koristio koji klijent, šta je server vidio i koja od tri ispravke je primijenjena. Zahtjevi za hairpinning iz RFC 4787 referenca su za ono što se od NAT-a ovdje očekuje i objašnjavaju zašto se ruter bez te funkcije ponaša normalno. Lokalni neuspjeh koji vanjski svijet ne može reproducirati pitanje je prevođenja dok se ne dokaže suprotno, pa ga tako i testirajte.