Hairpin-NAT: hvorfor VPN-endepunktet svikter innenfra

En VPN-server som svarer fra et mobilnett og svikter fra sofaen, er som regel ikke et sertifikatproblem. Klienten inne i LAN-et ber ruteren oversette en pakke hvis destinasjon er ruterens egen offentlige adresse, som betyr at pakken må gå ut og komme rett inn igjen. Den manøveren kalles hairpinning, og mange rutere implementerer den enten ikke i det hele tatt eller bare når en avkrysningsboks er slått på. Det er den beståtte testen utenfra som gjør det forvirrende, fordi den beviser at lytteren og videresendingsregelen er i orden.

Pakken går ut og kommer inn igjen

Følg pakken. Klienten slår opp det offentlige navnet, kobler til den offentlige adressen, og ruterens destinasjons-NAT skriver om destinasjonen til den interne serveren. Svaret fra serveren er adressert til klientens LAN-adresse, så det går tilbake gjennom ruterens LAN-grensesnitt uten noen gang å passere NAT-regelen som ville ha oversatt kilden tilbake.

Nå mottar klienten en pakke fra en adresse den aldri har sendt noe til, og forkaster den. Den asymmetrien er hele feilen.

RFC 4787 beskriver oppførselen en NAT forventes å ha i dette tilfellet, og kortversjonen er at den i praksis er valgfri, selv der den er spesifisert i teorien. Noen rutere kaller innstillingen NAT loopback, andre kaller den hairpin NAT eller NAT reflection, og noen viser ingenting i det hele tatt. En ruter som mangler den, er ikke feilkonfigurert; den gjør det vanlige, og rettelsen hører hjemme et annet sted. Ikke konkluder fra en mislykket lokal test at den offentlige videresendingsregelen er feil.

Kontroll 1: test de to veiene hver for seg

Utenfra LAN-et kobler du til med samme profil som en ekte bruker ville brukt, og bekrefter at økten etableres. Innenfra kobler du til den offentlige adressen med samme profil og noterer den nøyaktige feilen og tidspunktet.

En presis lokal test beholder vertsnavnet og overstyrer bare adressen: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ sender forespørselen til den offentlige adressen mens den fortsatt presenterer riktig servernavn. Det skiller et navneoppslagsproblem fra et oversettelsesproblem, som er lette å forveksle når det samme navnet virker fra en kafé. Legg merke til om klienten feiler ved TCP-tilkoblingen eller senere ved TLS, fordi det første peker på oversettelse og det andre på identitet.

Kontroll 2: les hva serveren ser

Den mest nyttige observasjonen er serverens syn. Kjør en opptak på VPN-vertsmaskinen filtrert på klientens LAN-adresse og på ruterens LAN-adresse, og gjenta deretter det lokale forsøket. Hvis ingenting kommer frem, overlevde ikke pakken oversettelsen.

Hvis en tilkobling kommer fra ruterens LAN-adresse i stedet for klientens, skjer hairpinning, og kilden ble skrevet om. Det er en fungerende konfigurasjon, ikke en feil.

Kontroll 3: rett det uten å røre den ytre veien

Det finnes tre støttede former, i stigende rekkefølge etter omfang. Den snevreste er delt DNS: publiser en intern post slik at det samme servernavnet løses til den interne adressen for klienter på LAN-et, noe som helt unngår den offentlige veien. Den neste er å aktivere ruterens dokumenterte loopback- eller reflection-alternativ, hvis den har et, og bare bruke det på denne tjenesten. Den bredeste er en source-NAT-regel på ruteren som skriver om LAN-trafikk til serveren slik at svaret kommer tilbake gjennom ruteren; på en Linux-ruter er det en MASQUERADE-regel i POSTROUTING, som passer til serverens adresse og port. Alle tre holder den eksterne veien urørt, og det er egenskapen som skal bevares.

Ikke utvid urelatert portvideresending for å få den lokale veien til å ligne den eksterne, og ikke flytt tjenesten til en annen port for å omgå problemet. Begge endringene endrer hva omverdenen kan nå, for å rette noe bare den indre verdenen ser.

Delt DNS har én felle som er verdt å nevne. Å erstatte et vertsnavn med en vilkårlig IP endrer hva klienten validerer, så den interne posten må fortsatt passe til navnet i sertifikatet.

Kontroll 4: verifiser begge veiene etterpå

Gjenta det eksterne forsøket utenfra LAN-et, gjenta det interne forsøket med samme profil, og bekreft at serverloggen viser to atskilte vellykkede økter i stedet for én suksess og én stillhet. Sjekk deretter at andre klienter fortsatt når lytteren, og at rutene til private ressurser er uendret.

Hold notatet kort: hvilken adresse hver klient brukte, hva serveren så, og hvilken av de tre rettelsene som ble brukt. Hairpinning-kravene i RFC 4787 er referansen for hva en NAT forventes å gjøre her, og de forklarer hvorfor en ruter uten funksjonen oppfører seg normalt. En lokal feil som omverdenen ikke kan gjenskape, er et oversettelsesspørsmål til det motsatte er bevist, så test det som sådan.