Hairpin NAT: zakaj končna točka VPN ne deluje od znotraj

Strežnik VPN, ki odgovarja iz mobilnega omrežja, a na kavču ne deluje, običajno ni težava s potrdilom. Odjemalec znotraj LAN-a prosi usmerjevalnik, naj prevede paket, katerega cilj je lastni javni naslov usmerjevalnika, kar pomeni, da mora paket oditi in se takoj vrniti. Ta manever se imenuje hairpinning, in mnogi usmerjevalniki ga bodisi ne izvajajo bodisi le ob potrjenem potrditvenem polju. Prav uspešen test od zunaj zmede, ker dokazuje, da sta poslušalec in pravilo posredovanja v redu.

Paket odide in se vrne

Sledite paketu. Odjemalec razreši javno ime, se poveže z javnim naslovom, in ciljni NAT usmerjevalnika prepiše cilj na notranji strežnik. Odgovor strežnika je naslovljen na LAN naslov odjemalca, zato se vrne skozi LAN vmesnik usmerjevalnika, ne da bi kdaj šel skozi pravilo NAT, ki bi vrnilo vir.

Zdaj odjemalec prejme paket z naslova, na katerega ni nikoli nič poslal, in ga zavrže. Ta asimetrija je vsa okvara.

RFC 4787 opisuje vedenje, ki se od NAT pričakuje v tem primeru, in kratka različica je, da je v praksi neobvezno tudi tam, kjer je teoretično določeno. Nekateri usmerjevalniki nastavitev imenujejo NAT loopback, drugi hairpin NAT ali NAT reflection, nekateri pa ne pokažejo ničesar. Usmerjevalnik brez tega ni napačno konfiguriran; dela običajno stvar, popravek pa spada drugam. Iz neuspešnega lokalnega testa ne sklepajte, da je javno pravilo posredovanja napačno.

Preverjanje 1: preizkusite obe poti ločeno

Od zunaj LAN-a se povežite z istim profilom, kot bi ga uporabil resničen uporabnik, in potrdite, da se seja vzpostavi. Od znotraj se povežite na javni naslov z istim profilom in zapišite natančno napako ter čas.

Natančen lokalni test ohrani ime gostitelja in zamenja le naslov: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ pošlje zahtevo na javni naslov, pri tem pa še vedno predstavi pravilno ime strežnika. To loči težavo razreševanja imen od težave prevajanja, ki ju je zlahka zamenjati, ko isto ime deluje iz kavarne. Zabeležite, ali odjemalec odpove pri povezavi TCP ali pozneje pri TLS, ker prvo kaže na prevajanje, drugo pa na identiteto.

Preverjanje 2: preberite, kaj vidi strežnik

Najbolj koristno opažanje je pogled strežnika. Zaženite zajem na gostitelju VPN, filtriran na LAN naslov odjemalca in na LAN naslov usmerjevalnika, nato ponovite lokalni poskus. Če nič ne prispe, paket ni preživel prevajanja.

Če povezava prispe z LAN naslova usmerjevalnika namesto odjemalca, se izvaja hairpinning in vir je bil prepisan. To je delujoča konfiguracija, ne okvara.

Preverjanje 3: popravite, ne da bi se dotaknili zunanje poti

Obstajajo tri podprte oblike v naraščajočem obsegu vpliva. Najožja je razdeljeni DNS: objavite notranji zapis, da se isto ime strežnika razreši na notranji naslov za odjemalce v LAN-u, kar se povsem izogne javni poti. Naslednja je omogočitev dokumentirane možnosti loopback ali reflection na usmerjevalniku, če jo ima, in njena uporaba samo za to storitev. Najširša je pravilo source-NAT na usmerjevalniku, ki prepiše promet iz LAN-a na strežnik, da se odgovor vrne skozi usmerjevalnik; na usmerjevalniku Linux je to pravilo MASQUERADE v POSTROUTING, ki ustreza naslovu in vratom strežnika. Vse tri pustijo zunanjo pot nedotaknjeno in to je lastnost, ki jo je treba ohraniti.

Ne širite nepovezanega posredovanja vrat, da bi lokalna pot postala podobna zunanji, in ne prestavljajte storitve na druga vrata, da bi se izognili težavi. Obe spremembi spreminjata, kaj lahko doseže zunanji svet, da bi popravili nekaj, kar vidi le notranji.

Razdeljeni DNS ima eno past, ki jo velja imenovati. Zamenjava imena gostitelja s poljubnim IP spremeni, kaj odjemalec preverja, zato se mora notranji zapis še vedno ujemati z imenom v potrdilu.

Preverjanje 4: nato preverite obe poti

Ponovite zunanji poskus od zunaj LAN-a, ponovite notranji poskus z istim profilom in potrdite, da dnevnik strežnika kaže dve ločeni uspešni seji, ne en uspeh in eno tišino. Nato preverite, da drugi odjemalci še vedno dosežejo poslušalca in da se poti do zasebnih virov niso spremenile.

Vodite kratek zapis: kateri naslov je uporabil kateri odjemalec, kaj je videl strežnik in katera od treh popravkov je bila uporabljena. Zahteve za hairpinning iz RFC 4787 so referenca za to, kaj se tu pričakuje od NAT, in pojasnjujejo, zakaj se usmerjevalnik brez te funkcije obnaša običajno. Lokalna okvara, ki je zunanji svet ne more ponoviti, je vprašanje prevajanja, dokler ni dokazano nasprotno, zato jo tako tudi preizkusite.