Hairpin-NAT: waarom die VPN-eindpunt van binne af misluk

'n VPN-bediener wat vanaf 'n mobiele netwerk antwoord maar van die bank af misluk, is gewoonlik nie 'n sertifikaatprobleem nie. Die kliënt binne die LAN vra die router om 'n pakkie te vertaal waarvan die bestemming die router se eie publieke adres is, wat beteken die pakkie moet uitgaan en dadelik terugkom. Daardie maneuver is hairpinning, en baie routers implementeer dit óf glad nie óf net wanneer 'n merkblokkie geaktiveer is. Dit is die feit dat die toets van buite slaag wat dit verwarrend maak, want dit bewys dat die luisteraar en die doorstuur-reël reg is.

Die pakkie gaan uit en kom terug in

Volg die pakkie. Die kliënt los die publieke naam op, konnekteer na die publieke adres, en die router se bestemmings-NAT herskryf die bestemming na die interne bediener. Die antwoord van die bediener is aan die kliënt se LAN-adres geadresseer, so dit gaan terug deur die router se LAN-koppelvlak sonder om ooit die NAT-reël te deurkruis wat die bron sou om-vertaal het.

Nou ontvang die kliënt 'n pakkie van 'n adres waarna hy nooit iets gestuur het nie, en laat val dit. Daardie asimmetrie is die hele fout.

RFC 4787 beskryf die gedrag wat 'n NAT in hierdie geval behoort te hê, en die kort weergawe is dat dit in die praktyk opsioneel is selfs waar dit in teorie gespesifiseer is. Sommige routers noem die instelling NAT-loopback, ander noem dit hairpin-NAT of NAT-weerkaatsing, en sommige bied niks daarvan nie. 'n Router wat dit nie het nie, is nie verkeerd opgestel nie; dit doen die gewone ding, en die regstelling hoort elders. Moenie uit 'n mislukte plaaslike toets aflei dat die publieke doorstuur-reël verkeerd is nie.

Toets 1: toets die twee roetes afsonderlik

Van buite die LAN, konnekteer met dieselfde profiel wat 'n regte gebruiker sou gebruik en bevestig dat die sessie tot stand kom. Van binne, konnekteer na die publieke adres met dieselfde profiel en teken die presiese fout en die tyd aan.

'n Presiese plaaslike toets hou die hostnaam en oorskryf net die adres: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ stuur die versoek na die publieke adres terwyl dit steeds die korrekte bedienernaam voorhou. Dit skei 'n naamoplossingsprobleem van 'n vertaalprobleem, wat maklik verwar word wanneer dieselfde naam van 'n koffiewinkel af werk. Let op of die kliënt by TCP-konneksie misluk of later by TLS, want die eerste dui op vertaling en die tweede op identiteit.

Toets 2: lees wat die bediener sien

Die nuttigste waarneming is die bediener se siening. Hardloop 'n opname op die VPN-gasheer wat gefiltreer is op die kliënt se LAN-adres en op die router se LAN-adres, en herhaal dan die plaaslike poging. As niks aankom nie, het die pakkie nooit die vertaling oorleef nie.

As 'n verbinding van die router se LAN-adres eerder as van die kliënt se adres af aankom, gebeur hairpinning en is die bron herskryf. Dit is 'n werkende opset, nie 'n fout nie.

Toets 3: maak dit reg sonder om aan die buitenste roete te raak

Daar bestaan drie ondersteunde vorms, in toenemende orde van impak. Die nouste is gesplete DNS: publiseer 'n interne rekord sodat dieselfde bedienernaam vir kliënte op die LAN na die interne adres oplos, wat die publieke roete heeltemal vermy. Die volgende is om die router se gedokumenteerde loopback- of weerkaatsingsopsie te aktiveer, as dit een het, en dit net op hierdie diens toe te pas. Die breedste is 'n bron-NAT-reël op die router wat LAN-afkomstige verkeer na die bediener herskryf sodat die antwoord deur die router terugkeer; op 'n Linux-router is dit 'n MASQUERADE reël in POSTROUTING wat by die bediener se adres en poort pas. Al drie laat die eksterne roete ongeraak, en dit is die eienskap wat behoue moet bly.

Moenie onverwante poortdoorstuur verbreed om die plaaslike roete soos die eksterne een te laat lyk nie, en moenie die diens na 'n ander poort skuif om die probleem te ontduik nie. Albei veranderinge verander wat die buitenste wêreld kan bereik om iets reg te maak wat net die binnewêreld sien.

Gesplete DNS het een lokval wat die moeite werd is om te noem. Om 'n hostnaam met 'n willekeurige IP te vervang, verander wat die kliënt valideer, so die interne rekord moet steeds by die sertifikaat se naam pas.

Toets 4: verifieer albei roetes daarna

Herhaal die eksterne poging van buite die LAN, herhaal die interne poging met dieselfde profiel, en bevestig dat die bedienerlog twee afsonderlike suksesvolle sessies wys eerder as een sukses en een stilte. Kyk dan of ander kliënte steeds die luisteraar bereik en of die roetes na private hulpbronne onveranderd is.

Hou die rekord kort: watter adres elke kliënt gebruik het, wat die bediener gesien het, en watter van die drie regstellings toegepas is. Die RFC 4787 hairpin-vereistes is die verwysing vir wat 'n NAT hier behoort te doen, en hulle verduidelik waarom 'n router sonder die funksie normaal optree. 'n Plaaslike mislukking wat die buitenste wêreld nie kan reproduceer nie, is 'n vertaalvraag tot die teendeel bewys word, so toets dit as een.