Zakaj zasebna imena DNS ne uspejo na odjemalcih VPN in kje preveriti

Odprete prenosnik v hotelski sobi, zaženete odjemalca, vtipkate ime notranjega strežnika datotek in ne dobite ničesar. Tunel poroča, da je povezan, in ping na naslov v istem podomrežju se še vedno odziva, torej je sam prenos v redu. Spodleti samo ime, in ta vrzel zoži težavo na dve mesti: kateri razreševalnik je odjemalec vprašal in ali lahko odgovor, ki ga je dobil, potuje nazaj skozi tunel. Popravite eno in drugo izpustite, pa se napaka preprosto premakne.

Preden uredite kateri koli profil, preverite, kaj odjemalec počne z imenom. V Linuxu resolvectl query files.corp.example pokaže, katera povezava in kateri razreševalnik sta ustvarila odgovor. V Windowsu Resolve-DnsName files.corp.example pokaže strežnik, ki je odgovoril, in naslov, ki ga je vrnil.

Preberite odgovor, preden karkoli spremenite

Če se ime vrne kot NXDOMAIN v nekaj milisekundah, poizvedba ni nikoli dosegla vaše cone in odgovoril je kak javni ali hotelski razreševalnik. Če se vrne po dolgem premoru, nekaj na poti zavrže vrata UDP 53 in odjemalec je nazadnje preklopil na rezervo. Če odgovori s pravilnim naslovom, a povezava še vedno obtiči, je iskanje v redu in vaša težava je v usmerjanju ali v sami storitvi.

Ta razdelitev na tri prihrani uro ugibanja. Pove vam tudi, ali se VPN sploh lotiti: ime, ki se razreši v pravilen zasebni naslov, je pot razreševalnika že dokazalo, zato je preostalo delo na podatkovni poti.

Razdelite razreševalnik od znotraj tunela

Odjemalci se delijo v dve skupini. Eni lahko strežnik med vzpostavljanjem povezave dodeli razreševalnik; druga hrani nastavitev v lokalni datoteki, ki je noben prehod ne more spremeniti na daljavo.

OpenVPN sodi v prvo skupino. Na strežniku push "dhcp-option DNS 10.8.0.53" in push "dhcp-option DOMAIN corp.example" potujeta po krmilnem kanalu, a le če ima konfiguracija odjemalca še vedno omogočen pull. Ročno urejen odjemalec z pull-filter ignore "dhcp-option" ju ne bo nikoli videl, in ta ena vrstica pojasni presenetljivo veliko primerov, ko »strežnik to potiska, moj prenosnik pa se ne strinja«.

WireGuard sodi v drugo skupino, ker protokol sploh nima pogajanj o možnostih. Razreševalnik in iskalna domena gresta v odjemalčev lastni blok [Interface] kot DNS = 10.8.0.53, corp.example. wg-quick to uveljavi prek resolvconf ali systemd-resolved, v Windowsu pa uradni odjemalec namesti pravila NRPT, ki obstajajo le, dokler je tunel pokonci: Get-DnsClientNrptPolicy jih našteje, zato je to hiter način, da vidite, ali je odjemalec kdaj uporabil vašo datoteko.

IPsec/IKEv2 je vmes. Vtičnik attr strongSwan lahko vrne strežnik DNS, vzet iz nabora, in odjemalec Windows ga običajno sprejme, a profil, ki si prisili lasten imenski strežnik, premaga vse, kar ponuja prehod. Na odjemalcu Linux je enakovredna ročna stopnja resolvectl dns wg0 10.8.0.53, ki ji sledi resolvectl domain wg0 '~corp.example'; oboje izgine z vmesnikom, kar je natanko to, kar želite pri nastavitvi, omejeni na tunel.

Omejite pripono, namesto da bi pogoltnili vsako poizvedbo

Usmeriti celoten seznam razreševalnikov odjemalca na svoj notranji strežnik je preprosto in običajno napačno. Tedaj se vsako javno ime razreši prek izhoda vašega podatkovnega središča, CDN-i vračajo oddaljene naslove in en izpad razreševalnika s seboj potegne brskanje uporabnika.

Pošiljajte navznoter samo zasebno pripono. V systemd-resolved je domena, ki se začne z ~, namenjena samo usmerjanju, zato ~corp.example pomeni, da poizvedbe pod to pripono gredo na strežnike te povezave, medtem ko vse drugo še naprej uporablja fizično omrežje. Windows naredi isto s pravili NRPT, omejenimi na imenski prostor, macOS pa z dodatno datoteko razreševalnika pod /etc/resolver/.

Multicastna imena si zaslužijo svoj odgovor. Imena .local so po zasnovi link-local (RFC 6762) in vmesnik tun od točke do točke ne prenaša te multicastne skupine, zato jih dodaten javni razreševalnik ne bo objavil in če zanje vprašate notranji unicasni razreševalnik, vrne NXDOMAIN. Odsevnik, kot je avahi v načinu odsevanja, lahko poveže dva segmenta, a to je odločitev na strani strežnika, ki je noben odjemalec ne more zahtevati. Če mora biti tiskalnik ali NAS dosegljiv po imenu, mu raje dodelite zapis A v svoji coni.

Dokažite, da lahko odgovor potuje nazaj

Pravilen odgovor, ki kaže na nedosegljiv naslov, je videti natanko kot težava razreševalnika, dokler ne preverite poti. Vprašajte jedro, kam bi odgovor šel: ip route get 10.20.5.20 poimenuje vmesnik in, kar je bolj uporabno, izvorni naslov, ki bi ga uporabilo.

Opazujte naslov razreševalnika samega. Odjemalec z DNS = 10.8.0.53 ob AllowedIPs = 10.20.0.0/16 pošilja svoje poizvedbe skozi fizično kartico, kjer tiho umrejo, ker razreševalnik ni znotraj nobenega predpone, ki ga tunel zahteva. To neskladje je najpogostejša enovzročna napaka na celem tem področju in ostane nevidno, razen če primerjate nastavitev DNS z dovoljenimi predponami vrstico za vrstico.

Prekrivajoča se območja povzročijo nasprotno napako. Odgovor je pravilen, pot obstaja in kaže na napačnega gostitelja, ker je 192.168.0.0/24 doma bolj natančen kot pot tunela v isto območje. Preštevilčite eno stran ali potisnite ožjo pot, nato potrdite požarni zid in povratno pot gostitelja storitve; opombe strongSwan o posredovanju pokrivajo stran sysctl te poti.

Potrdila so ločeno preverjanje identitete, ki ga ljudje pripisujejo DNS-u. Če brskalnik sporoči neujemanje imena namesto napake razreševanja, je iskanje že delovalo in popraviti je treba SAN v potrdilu. Preizkusite HTTPS na ime, nikoli na goli IP.

Znova preizkusite z odjemalca, ne s prehoda

Preizkusite znotraj aplikacije, na katero se uporabnik pritožuje, ker iskanje v ukazni vrstici ne dokazuje, da brskalnik ubira isto pot. Varni DNS Chroma in network.trr.mode v Firefoxu lahko popolnoma obideta sistemski razreševalnik, in ko to storita, zasebno ime bodisi spodleti bodisi uhaja javnemu razreševalniku. Primerjava resolvectl query z ročno zagnanim dig @10.8.0.53 files.corp.example vam pove, kateri od obeh se je zgodil.

Nato se odklopite in znova povežite, preden to razglasite za popravljeno. Nastavitve, ki jih ročno vnesete na vmesnik, izginejo z vmesnikom, in profil, ki je bil videti pravilen le zaradi pozabljene lokalne spremembe, bo ob naslednjem zagonu odpovedal.

Kratek kontrolni seznam za naslednji stroj: ime se razreši prek tunelskega razreševalnika, pripona je omejena in ne globalna, naslov razreševalnika je znotraj dovoljenih predpon, gostitelj iz odgovora se odziva na vratih storitve in potrdilo pokriva ime, ki ga je vpisal uporabnik.