Je VPN spremenil moj DNS? Primerjajte pred in po
Profil lahko namerno premakne vaša poizvedovanja. Primerjajte politiko razreševalnika in dejanski odgovor pred povezavo VPN in po njej, pri čemer ohranite eno spremenljivko.
Povežete tunel, odprete zasebno nadzorno ploščo in ime se razreši v naslov, ki ga še nikoli niste videli. Ali pa se zgodi nasprotno: brskalnik še naprej deluje, medtem ko orodje ukazne vrstice nenadoma ne razreši ničesar. Oba izida izhajata iz iste spremembe, in ljudje to običajno razložijo z enim stavkom o VPN, ki »uporablja svoj DNS«, kar ni dovolj natančno za odpravljanje napak ali preverjanje. V tem stavku se skrivata dve vprašanji: katera poizvedovanja naj prevzame ta profil in ali je vaš stroj res poslal ta poizvedovanja razreševalniku, ki mu je bil dodeljen? Ločevanje obeh je celotna metoda, kajti test, ki ju zmeša, daje v obe smeri samozavesten napačen odgovor.
Zakaj profil sploh zagotovi razreševalnik
Znotraj tunela se imena za oddaljenim koncem običajno razrešijo v naslove, ki obstajajo samo v tem omrežju. Zasebna cona, kot je corp.internal, nima javne delegacije, zato mora biti razreševalnik, ki jo streže, dosegljiv od znotraj tunela. Isti mehanizem služi še drugemu namenu: ko bi poizvedovanja sicer šla ven prek vašega ponudnika, razreševalnik na oddaljeni strani zadrži poizvedbo znotraj šifrirane poti. Zato naslov strežnika DNS pride kot del politike povezave in ne kot globalna nastavitev, ki ste jo enkrat izbrali za stroj.
Naslov sam po sebi ne odloči ničesar. Razreševalnik lahko odgovori le, če do njega obstaja pot, in najpogostejša okvara je razreševalnik, dosegljiv le, dokler je tunel pokonci. Ko tunel pade in politika ostane, poizvedovanja gredo na naslov brez poti, simptom pa je potekla časovna omejitev in ne čista napaka. Ta razlika je pomembna, ko berete naslednji rezultat preskusa, kajti potekla omejitev pošlje ljudi v nastavitve prenosa, ki nikoli niso bile vpletene.
Primerjajte oba načrta, preden primerjate odgovore
Polni tunel in razdeljeni DNS dajeta nasprotna pričakovanja in nobeno od tega ni okvara. Pod polnim tunelom se lahko vsaka poizvedba premakne k ponudniku ali k podjetniškemu razreševalniku, zato je drugačen odgovor javnih imen po povezavi pričakovan. Pod razdeljenim DNS gredo k zasebnemu razreševalniku le navedene domene, vse ostalo pa ostane lokalno; v Windowsu seznam domen živi v Name Resolution Policy Table, v macOS v ustreznih domenah nastavitev DNS, na gostitelju s systemd-resolved pa v usmerjevalnih domenah za vsako povezavo.
Prav to primerjavo je treba narediti prvo, ker odloča, kaj šteje za okvaro. Pri razdeljenem DNS je javno ime, ki odgovarja z novega razreševalnika, tisto, kar je vredno preiskati, medtem ko je notranje ime, ki odgovarja pravilno, sistem, ki opravlja svoje delo. Pri polnem tunelu je anomalija javno ime, ki še vedno odgovarja z razreševalnika vašega ponudnika. Dokumentacija Microsofta o razreševanju imen VPN opisuje vrstni red Windows teh pravil, vključno s tem, kako se ustrezni vnos politike pregleda pred lastnimi strežniki adapterja.
V sobi je tudi tretji razreševalnik, ki ga je zlahka pozabiti. Varni DNS brskalnika sam razrešuje imena in lahko še naprej odgovarja, potem ko je tunel spremenil politiko operacijskega sistema, zato naložena stran dokazuje, da je razreševalnik brskalnika deloval, ne da je bil profil uporabljen. Če primerjate le to, kar prikazuje brskalnik, polovico časa preizkušate napačno plast.
Zabeležite osnovno črto z eno samo spremenljivko
Spremenite tunel. V istem koraku ne spreminjajte tudi imena, orodja ali iskalne pripone. Izberite ime, za katero smete poizvedovati, zabeležite, katero aplikacijo ste uporabili, in zapišite bodisi vrnjeni naslov bodisi natančno napako. V Windowsu Get-DnsClientServerAddress -AddressFamily IPv4 izpiše strežnike za posamezne adapterje, Get-DnsClientNrptPolicy pa vnose politike; v Linuxu s systemd-resolved resolvectl status prikaže strežnike DNS in usmerjevalne domene za posamezne povezave; v macOS scutil --dns izpiše vrstni red razreševalnikov, ki se ga bo sistem dejansko držal.
Nato se povežite z običajnimi kontrolniki odjemalca in ponovite točno iste ukaze. Shranite prvi izpis namesto spomina nanj, kajti primerjava je ves smisel in drugo branje po izpraznitvi predpomnilnika je že druga meritev. Če je bila osnovna črta zajeta z brskalnikom spredaj in se izvajanje po povezavi zgodi v terminalu, primerjate dva razreševalnika, ne dveh stanj enega razreševalnika.
Izrecna poizvedba in iskanje aplikacije sta različna preskusa
Vprašati enega določenega strežnika, z nslookup name 10.20.0.1 ali dig @10.20.0.1 name, dokaže eno stvar: da strežnik, ki ste ga navedli, odgovori, ko ga lahko dosežete. Popolnoma obide logiko izbire, zato ne more povedati, ali bi sistem izbral ta strežnik za to ime. Uporabite ga za preverjanje dosegljivosti dodeljenega razreševalnika in ne za preverjanje politike.
Iskanje prek lokalnega razreševalnika res izvaja izbiro. resolvectl query name prehodi ista pravila usmerjevalnih domen in poroča, kateri protokol je odgovoril, Resolve-DnsName v Windowsu gre skozi tabelo politike in predpomnilnik odjemalca, scutil --dns pa pokaže vrstni red, ki bi mu iskanje sledilo. Zaženite obe vrsti in ju imejte v ločenih stolpcih svojih zapiskov. Uspešna izrecna poizvedba ob neuspešnem iskanju aplikacije je težava usmerjanja ali izbire, ne razreševalnik, ki noče delovati.
Predpomnilnik stoji med vami in odgovorom. Operacijski sistem, lokalni stub razreševalnik, brskalnik in negativni predpomnilnik vsi hranijo rezultate, zato lahko iskanje uspe, ne da bi en sam paket zapustil stroj. Zabeležite rezultat, preden karkoli izpraznite: ipconfig /flushdns, resolvectl flush-caches ali sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder v macOS. Široko ponastavitev omrežja na tej stopnji izpustite, ker uniči dokaze, ki jih še zbirate.
Kaj razlika pomeni
Primerjajte dve zabeleženi vrstici in razvrstite spremembo, preden se dotaknete ene same nastavitve.
| Observation after connect | Most likely cause | Next step |
|---|---|---|
| Answer moves to a private address range | Expected under split DNS or a private zone | Confirm the suffix is in the effective policy, then test the service |
| Lookup times out while connected, works after disconnect | The assigned resolver has no route from this machine | Probe it with an explicit query, then re-read the policy |
| Internal name fails, public names work | Wrong namespace or a suffix missing from the policy | Query the fully qualified name and check the domain list per platform |
| Internal name returns a public address | Split DNS not applied; a public resolver answered | Check browser secure DNS first, then the per-link domain list |
Ena vrstica si zasluži poudarek. Ime, ki se razreši, ni delujoča storitev, in uspeh DNS pove le, da je bil najden naslov. Ne pove ničesar o posredovanju, pravilih požarnega zidu ali o tem, ali vaš račun storitev sploh sme uporabljati, zato končajte s preizkušanjem dejanske aplikacije, namesto da bi domnevali, da se je okvara sama umaknila.
Obnovite osnovno črto in jo preverite
Odklopite se z lastnimi kontrolniki odjemalca, namesto da bi ubili proces, in nato znova preberite iste tri ukaze. Strežniki za posamezne povezave, vnosi politike in odgovor za vaše testno ime bi se morali vrniti na osnovno črto, ki ste jo zapisali prej. Preostali vnos politike po čistem odklopu je resnična napaka, ki si zasluži zapis, in prav zato so ročni posegi v ustvarjeno datoteko razreševalnika slaba navada: datoteka se prepiše in poseg izgine, ali poseg preživi in pripne razreševalnik, ki nima več poti.
Pojdite skozi ta seznam enkrat, po vrsti. Odločite, kateri načrt profil izvaja, preden presodite kateri koli rezultat. Držite ime, orodje in pripono nespremenjene v obeh zagonih. Ločite izrecno poizvedbo od iskanja aplikacije. Berite veljavno politiko, ne le odgovora. Predpomnilnike izpraznite nazadnje, ko je primerjava zapisana. Preverite z dejansko aplikacijo, nato enkrat znova zaženite in potrdite, da je odklopljeno stanje še vedno čisto.