Hairpin-NAT: kvifor VPN-endepunktet svikt innanfrå

Ein VPN-tenar som svarar frå eit mobilnett og sviktar frå sofaen, er som regel ikkje eit sertifikatproblem. Klienten inne i LAN-et ber rutaren omsetje ein pakke der destinasjonen er rutaren si eiga offentlege adresse, noko som tyder at pakken må gå ut og kome rett inn att. Den manøveren blir kalla hairpinning, og mange rutarar implementerer han anten ikkje i det heile eller berre når ein avkryssingsboks er slått på. Det er den beståtte testen utanfrå som gjer det forvirrande, fordi han beviser at lyttaren og videresendingsregelen er i orden.

Pakken går ut og kjem inn att

Fylg pakken. Klienten slår opp det offentlege namnet, koplar til den offentlege adressa, og destinasjons-NAT-en til rutaren skriv om destinasjonen til den interne tenaren. Svaret frå tenaren er adressert til LAN-adressa til klienten, så det går tilbake gjennom LAN-grensesnittet til rutaren utan nokon gong å passere NAT-regelen som ville ha omsett kjelda tilbake.

No mottar klienten ein pakke frå ei adresse han aldri har sendt noko til, og forkastar han. Den asymmetrien er heile feilen.

RFC 4787 skildrar åtferda ein NAT blir forventa å ha i dette tilfellet, og kortversjonen er at ho i praksis er valfri, sjølv der ho er spesifisert i teorien. Nokre rutarar kallar innstillinga NAT loopback, andre kallar ho hairpin NAT eller NAT reflection, og nokre viser ingenting i det heile. Ein rutar som manglar ho er ikkje feilkonfigurert; han gjer det vanlege, og rettinga høyrer heime ein annan stad. Ikkje konkluder frå ein mislukka lokal test at den offentlege videresendingsregelen er feil.

Kontroll 1: test dei to vegane kvar for seg

Utanfrå LAN-et koplar du til med same profil som ein ekte brukar ville bruke, og stadfestar at økta blir oppretta. Innanfrå koplar du til den offentlege adressa med same profil og noterer den nøyaktige feilen og tidspunktet.

Ein presis lokal test held på vertsnamnet og overstyrer berre adressa: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ sender førespurnaden til den offentlege adressa medan han framleis presenterer rett tenarnamn. Det skil eit namneoppslagsproblem frå eit omsetjingsproblem, som er lette å forveksle når det same namnet verkar frå ein kafé. Legg merke til om klienten sviktar ved TCP-tilkoplinga eller seinare ved TLS, fordi det første peikar på omsetjing og det andre på identitet.

Kontroll 2: les kva tenaren ser

Den mest nyttige observasjonen er synet til tenaren. Køyr eit opptak på VPN-vertsmaskinen filtrert på LAN-adressa til klienten og på LAN-adressa til rutaren, og gjer så det lokale forsøket på nytt. Viss ingenting kjem fram, overlevde ikkje pakken omsetjinga.

Viss ei tilkopling kjem frå LAN-adressa til rutaren i staden for klienten si, skjer hairpinning, og kjelda vart skriven om. Det er ein fungerande konfigurasjon, ikkje ein feil.

Kontroll 3: rett det utan å røre den ytre vegen

Det finst tre støtta former, i stigande rekkjefylgje etter omfang. Den snevraste er delt DNS: publiser ein intern post slik at det same tenarnamnet blir løyst til den interne adressa for klientar på LAN-et, noko som heilt unngår den offentlege vegen. Den neste er å slå på det dokumenterte loopback- eller reflection-alternativet til rutaren, viss han har eit, og berre bruke det på denne tenesta. Den breiaste er ein source-NAT-regel på rutaren som skriv om LAN-trafikk til tenaren slik at svaret kjem tilbake gjennom rutaren; på ein Linux-rutar er det ein MASQUERADE-regel i POSTROUTING, som passar til adressa og porten til tenaren. Alle tre held den eksterne vegen urørt, og det er eigenskapen som skal haldast.

Ikkje utvid urelatert portvideresending for å få den lokale vegen til å likne den eksterne, og ikkje flytt tenesta til ein annan port for å omgå problemet. Båe endringane endrar kva omverda kan nå, for å rette noko berre den indre verda ser.

Delt DNS har ei felle som er verd å nemne. Å byta ut eit vertsnamn med ein vilkårleg IP endrar kva klienten validerer, så den interne posten må framleis passe til namnet i sertifikatet.

Kontroll 4: stadfest båe vegane etterpå

Gjer det eksterne forsøket på nytt utanfrå LAN-et, gjer det interne forsøket på nytt med same profil, og stadfest at tenarloggen viser to åtskilde vellukka økter i staden for éin suksess og éi stille. Sjekk deretter at andre klientar framleis når lyttaren, og at rutene til private ressursar er uendra.

Hald notatet kort: kva adresse kvar klient brukte, kva tenaren såg, og kva av dei tre rettingane som vart brukt. Hairpinning-krava i RFC 4787 er referansen for kva ein NAT blir forventa å gjere her, og dei forklarer kvifor ein rutar utan funksjonen oppfører seg normalt. Ein lokal feil som omverda ikkje kan gjenskape, er eit omsetjingsspørsmål til det motsette er bevist, så test han som slik.