Vaš VPN potisne tri strežnike DNS: kateri odgovori?

Po povezavi odprite stran z nastavitvami in prikažejo se trije naslovi DNS; vprašanje revizije je, kateri je obdelal vašo zadnjo poizvedbo. Samo število ne odgovori na nič, ker potiskanje odjemalca, fizični vmesnik in pravilnik za domeno vsi pišejo v isti pogled. Ti vnosi nosijo različne obsege, in obseg, ne položaj, odloči, kdo odgovori. Začnite z ločevanjem virov, nato preizkusite tistega, ki ima ime, ki vam je pomembno.

Zakaj je seznam daljši od vašega profila

Odjemalec VPN potisne naslove razreševalnika za povezavo tunela, operacijski sistem pa jih hrani ob tem, kar je fizični vmesnik že imel. Usmerjevalnik, podjetniška najemna pogodba DHCP, drugi VPN in pravilnik za domeno prispevajo vsak svoj vnos. Zato lahko trije naslovi na strani pomenijo tri obsege, ne treh kandidatov za eno nalogo. Branje števila kot dokaza uhajanja je prva napaka te revizije.

Znotraj enega vmesnika odjemalec res poskuša svoje strežnike po vrsti, zato urejen seznam ni nesmiseln. Kar ni čakalna vrsta, je združen pogled, kjer vnosi iz profila, fizične povezave in pravil za domeno stojijo drug ob drugem brez enega samega razvrščanja. Ta razlika odloči, kaj preizkušate: vrstni red pojasni vedenje znotraj enega obsega, obseg pa pojasni vse ostalo.

Šifriran DNS razbije sliko od znotraj aplikacije. Brskalnik ali odjemalec za klepet z lastnim razreševalnikom DNS-over-HTTPS pošlje poizvedbe povsem mimo seznama operacijskega sistema, zato naslovi na strani z nastavitvami opisujejo promet, ki ga aplikacija ni nikoli ustvarila. Preverite lastno nastavitev razreševalnika aplikacije, preden krivite profil za napačno vrnjeno ime.

Kaj pove vsaka od treh preveritev

Vsak vir pusti sled na drugem mestu in noben posamezen ukaz ne pokaže vseh. To je preslikava, ki jo je vredno imeti ob strani z nastavitvami:

V sistemu z systemd-resolved je merodajna resolvectl status, ker poroča DNS za vsako povezavo skupaj z domenami usmerjanja. macOS odgovori prek scutil --dns, ki našteje razreševalnike z obsegom v vrstnem redu preizkušanja. Windows razdeli na dve polovici: Get-DnsClientServerAddress za strežnike po vmesniku in Get-DnsClientNrptPolicy za pravila pripon. Zaženite ukaz, ki pripada dejansko uporabljenemu razreševalniku, ker ima lahko stroj z okoljem za kontejnerje in namiznim razreševalnikom nameščenega več kot enega.

Rezervni razreševalnik, ki ne more odgovoriti za vašo cono

Drugi vnos običajno obstaja zaradi razpoložljivosti in razpoložljivost deluje le, če rezerva pozna imena. Vprašajte javni razreševalnik za interno ime gostitelja in vrne NXDOMAIN, ali nadomestni odgovor iz iskalne domene, ki nima nič skupnega z vami. Nepreverjen preklop v rezervo nato povzroči izpad točno v trenutku, ko je potreben.

Split DNS obstaja, da to prepreči: pripone podjetja gredo k razreševalniku, ki ima cono, javna imena pa ostanejo na privzeti poti. Zasnova je trdna in odvisna od tega, ali je seznam pripon popoln. Microsoft dokumentira pravilnik razreševalnika za vsako pripono, ki to vodi v Windows, in ista zamisel se pojavi kot domene usmerjanja v systemd-resolved in kot razreševalniki z obsegom v macOS.

Primerjajte cone, za katere sme rezerva odgovarjati, s priponami v pravilniku. Ta primerjava najde vrzel, preden uporabnik sporoči, da se je eno interno mesto po spremembi tunela prenehalo razreševati.

Sprašujte prek pravilnika, ne okoli njega

Sprašujte prek razreševalnika operacijskega sistema, ker neposredna poizvedba na strežnik obide pravilnik in poroča le, kaj bi ta strežnik rekel. Razlika med obema odgovoroma je ves smisel:

resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53

Če sistemska poizvedba vrne zasebni naslov, neposredna pa NXDOMAIN, pravilnik deluje in šibka točka je rezerva. Če oba vrneta enak javni odgovor, se ime razrešuje zunaj predvidenega obsega in seznam pripon je mesto, kam pogledati. Shranite oba izhoda, ker se spor o razreševalniku hitreje zaključi z dvema vrsticama kot s posnetkom zaslona strani z nastavitvami.

Nato vadite pot okvare, ker je rezerva, ki je nihče ni preizkusil, le predpostavka. Naredite iz prednostnega razreševalnika črno luknjo za eno poizvedbo in opazujte, kateri naslov se vrne:

ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32

Izbrišite to pot takoj po koncu poizvedbe, sicer naslednja oseba podeduje uganko. Če se notranja imena v tem oknu še razrešujejo, jim je odgovorilo nekaj zunaj predvidenega obsega. Če namesto tega potečejo, rezerva manjka ali je pravilno omejena, in lastni dnevnik razreševalnika vam pove, katera od obeh je bila.

Odločite: obdržati, omejiti ali odstraniti

Obdržite drugi razreševalnik, ko odgovarja na potreben imenski prostor in ostane dosegljiv pod profilom. Omejite ga, ko naj bi videl eno pripono in nič drugega, in ga odstranite, ko nima ne obsega ne dokumentiranega namena. Vnos brez dela je prihodnje uhajanje brez koristi, privzeta vrednost ponudnika pa ni namen.

Zapišite izid v štiri stolpce: pripona, razreševalnik, vmesnik in lastnik. Ta vrstica odgovori na naslednje revizijsko vprašanje hitreje kot kateri koli posnetek zaslona in preživi posodobitev odjemalca, ki seznam tiho prerazporedi.