Hairpin NAT: kodėl VPN galinis taškas neveikia iš vidaus

VPN serveris, kuris atsako iš mobiliojo tinklo, bet neveikia nuo sofos, paprastai nėra sertifikato problema. Klientas LAN viduje prašo maršrutizatoriaus išversti paketą, kurio paskirties vieta yra paties maršrutizatoriaus viešasis adresas, o tai reiškia, kad paketas turi išeiti ir iš karto grįžti atgal. Šis manevras vadinamas hairpinning, ir daugelis maršrutizatorių jo arba visai neįgyvendina, arba atlieka tik tada, kai pažymėtas langelis. Būtent sėkmingas testas iš išorės ir klaidina, nes jis įrodo, kad klausytojas ir persiuntimo taisyklė yra tvarkingi.

Paketas išeina ir grįžta atgal

Sekite paketą. Klientas išsprendžia viešąjį vardą, prisijungia prie viešojo adreso, o maršrutizatoriaus paskirties NAT perrašo paskirties vietą į vidinį serverį. Serverio atsakymas adresuotas kliento LAN adresui, todėl jis grįžta per maršrutizatoriaus LAN sąsają niekada neperėjęs per tą NAT taisyklę, kuri būtų grąžinusi šaltinį.

Dabar klientas gauna paketą iš adreso, kuriam niekada nieko nesiuntė, ir jį išmeta. Ši asimetrija ir yra visas gedimas.

RFC 4787 aprašo elgseną, kurios tikimasi iš NAT šiuo atveju, ir trumpoji versija yra ta, kad praktiškai ji yra neprivaloma net ten, kur teoriškai nustatyta. Kai kurie maršrutizatoriai šį nustatymą vadina NAT loopback, kiti – hairpin NAT arba NAT reflection, o kai kurie nieko nerodo. Maršrutizatorius, kuris to neturi, nėra neteisingai sukonfigūruotas; jis daro įprastą dalyką, o pataisymas priklauso kitur. Nedarykite iš nepavykusio vietinio testo išvados, kad viešoji persiuntimo taisyklė yra neteisinga.

Patikra 1: išbandykite abu kelius atskirai

Iš LAN išorės prisijunkite tuo pačiu profiliu, kurį naudotų tikras vartotojas, ir patvirtinkite, kad sesija užmezgama. Iš vidaus prisijunkite prie viešojo adreso tuo pačiu profiliu ir užrašykite tikslią klaidą bei laiką.

Tikslus vietinis testas išlaiko pagrindinio kompiuterio vardą ir pakeičia tik adresą: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ siunčia užklausą viešuoju adresu, vis tiek pateikdamas teisingą serverio vardą. Tai atskiria vardų sprendimo problemą nuo vertimo problemos, kurias lengva supainioti, kai tas pats vardas veikia iš kavinės. Atkreipkite dėmesį, ar klientas nepavyksta TCP prisijungimo metu, ar vėliau TLS, nes pirmasis rodo vertimą, o antrasis – tapatybę.

Patikra 2: perskaitykite, ką mato serveris

Naudingiausias stebėjimas yra serverio požiūris. Paleiskite įrašymą VPN pagrindiniame kompiuteryje, filtruotą pagal kliento LAN adresą ir maršrutizatoriaus LAN adresą, tada pakartokite vietinį bandymą. Jei niekas neateina, paketas vertimo neišgyveno.

Jei ryšys ateina iš maršrutizatoriaus LAN adreso, o ne iš kliento, vyksta hairpinning ir šaltinis buvo perrašytas. Tai veikianti konfigūracija, o ne gedimas.

Patikra 3: pataisykite neliesdami išorinio kelio

Yra trys palaikomos formos, didėjančio poveikio spindulio tvarka. Siauriausia yra skaidytas DNS: paskelbkite vidinį įrašą, kad tas pats serverio vardas LAN klientams būtų sprendžiamas į vidinį adresą, o tai visiškai apeina viešąjį kelią. Kita – įjungti dokumentuotą maršrutizatoriaus loopback arba reflection parinktį, jei ji yra, ir taikyti ją tik šiai paslaugai. Plačiausia – source-NAT taisyklė maršrutizatoriuje, kuri perrašo iš LAN ateinantį srautą į serverį, kad atsakymas grįžtų per maršrutizatorių; Linux maršrutizatoriuje tai yra MASQUERADE taisyklė POSTROUTING grandinėje, atitinkanti serverio adresą ir prievadą. Visos trys palieka išorinį kelią nepaliestą, ir tai yra savybė, kurią reikia išsaugoti.

Neplėskite nesusijusio prievadų persiuntimo, kad vietinis kelias atrodytų kaip išorinis, ir nekelkite paslaugos į kitą prievadą, kad išvengtumėte problemos. Abu pakeitimai keičia, ką gali pasiekti išorinis pasaulis, kad būtų sutaisyta tai, ką mato tik vidinis.

Skaidytas DNS turi vienus spąstus, kuriuos verta įvardyti. Pakeitus pagrindinio kompiuterio vardą savavališku IP, pasikeičia tai, ką klientas tikrina, todėl vidinis įrašas vis tiek turi atitikti sertifikato vardą.

Patikra 4: po to patikrinkite abu kelius

Pakartokite išorinį bandymą iš LAN išorės, pakartokite vidinį bandymą tuo pačiu profiliu ir patvirtinkite, kad serverio žurnalas rodo dvi atskiras sėkmingas sesijas, o ne vieną sėkmę ir vieną tylą. Tada patikrinkite, ar kiti klientai vis dar pasiekia klausytoją ir ar maršrutai į privačius išteklius nepakitę.

Laikykite įrašą trumpą: kokį adresą naudojo kiekvienas klientas, ką matė serveris ir kuri iš trijų pataisų buvo pritaikyta. RFC 4787 hairpinning reikalavimai yra nuoroda, ko čia tikimasi iš NAT, ir paaiškina, kodėl maršrutizatorius be šios funkcijos elgiasi normaliai. Vietinė nesėkmė, kurios išorinis pasaulis negali atkartoti, yra vertimo klausimas, kol neįrodyta priešingai, todėl testuokite ją kaip tokią.