Ĉu la VPN ŝanĝis mian DNS? Komparu antaŭe kaj poste

Vi konektas la tunelon, malfermas privatan panelon, kaj la nomo solviĝas al adreso, kiun vi neniam vidis. Aŭ okazas la malo: la retumilo daŭre funkcias dum komandlinia ilo subite solvas nenion. Ambaŭ rezultoj venas de la sama ŝanĝo, kaj homoj kutime klarigas ĝin per unu frazo pri la VPN, kiu "uzas sian propran DNS", kio ne estas sufiĉe preciza por sencimigi aŭ kontroli. Du demandoj kaŝiĝas en tiu frazo: kiujn serĉojn ĉi tiu profilo devus transpreni, kaj ĉu via maŝino vere sendis ilin al la solvanto, kiun ĝi ricevis? Teni ilin apartaj estas la tuta metodo, ĉar testo, kiu miksas ilin, donas memfidan malĝustan respondon en ambaŭ direktoj.

Kial profilo entute provizas solvanton

Ene de tunelo, nomoj malantaŭ la malproksima fino kutime solviĝas al adresoj, kiuj ekzistas nur en tiu reto. Privata zono kiel corp.internal ne havas publikan delegacion, do la solvanto, kiu respondecas pri ĝi, devas esti atingebla de interne de la tunelo. La sama mekanismo servas duan celon: kiam serĉoj alie elirus tra via provizanto, solvanto ĉe la malproksima flanko tenas la peton ene de la ĉifrita vojo. Tial la adreso de la DNS-servilo venas kiel parto de la politiko de la konekto, ne kiel tutmonda agordo, kiun vi elektis unufoje por la maŝino.

La adreso sola decidas nenion. Solvanto povas respondi nur se ekzistas vojo al ĝi, kaj la plej ofta fiasko estas solvanto atingebla nur dum la tunelo estas supre. Kiam la tunelo falas kaj la politiko restas, serĉoj iras al adreso sen vojo, kaj la simptomo estas tempolimo, ne pura eraro. Tiu diferenco gravas, kiam vi legas la sekvan testrezulton, ĉar tempolimo sendas homojn en transportajn agordojn, kiuj neniam estis implikitaj.

Komparu la du dezajnojn antaŭ ol kompari respondojn

Plena tunelo kaj dividita DNS produktas kontraŭajn atendojn, kaj nek unu estas misfunkcio. Sub plena tunelo ĉiu serĉo povas translokiĝi al la provizanto aŭ al la entreprena solvanto, do publikaj nomoj respondantaj alie post konekto estas atendeblaj. Sub dividita DNS nur listigitaj domajnoj iras al la privata solvanto dum ĉio alia restas loka; en Windows la domajna listo loĝas en la Name Resolution Policy Table, en macOS en la kongruaj domajnoj de la DNS-agordoj, kaj sur systemd-resolved gastiganto en la enkursigaj domajnoj por ĉiu ligilo.

Tiu estas la komparo farenda unue, ĉar ĝi decidas, kio validas kiel cimo. Kun dividita DNS, publika nomo respondanta el nova solvanto estas la afero inda je esploro, dum interna nomo respondanta ĝuste estas la sistemo faranta sian taskon. Kun plena tunelo, la anomalio estas publika nomo, kiu ankoraŭ respondas el la solvanto de via provizanto. La dokumentaro de Microsoft pri VPN-nomsolvado priskribas la Windows-ordigon de tiuj reguloj, inkluzive kiel kongrua politika ero konsultiĝas antaŭ la propraj serviloj de la adaptilo.

Estas tria solvanto en la ĉambro, kiun oni facile forgesas. La sekura DNS de la retumilo mem solvas nomojn kaj povas daŭre respondi post kiam la tunelo ŝanĝis la politikon de la operaciumo, do paĝo, kiu ŝargiĝas, pruvas ke la solvanto de la retumilo funkciis, ne ke la profilo aplikiĝis. Se vi komparas nur tion, kion montras la retumilo, vi duonon de la tempo testas la malĝustan tavolon.

Registru bazlinion kun nur unu variablo

Ŝanĝu la tunelon. Ne ŝanĝu ankaŭ la nomon, la ilon aŭ la serĉan sufikson en la sama paŝo. Elektu nomon, pri kiu vi rajtas fari petojn, notu kiun aplikaĵon vi uzis, kaj skribu aŭ la adreson, kiu revenis, aŭ la ekzaktan eraron. En Windows Get-DnsClientServerAddress -AddressFamily IPv4 presas la servilojn por ĉiu adaptilo kaj Get-DnsClientNrptPolicy presas la politikajn erojn; en Linux kun systemd-resolved resolvectl status montras DNS-servilojn kaj enkursigajn domajnojn por ĉiu ligilo; en macOS scutil --dns presas la solvantan ordon, kiun la sistemo fakte sekvos.

Poste konektu per la kutimaj regiloj de la kliento kaj ripetu ekzakte la samajn komandojn. Konservu la unuan eligon anstataŭ memoron pri ĝi, ĉar la komparo estas la tuta celo kaj dua legado farita post malplenigo de la kaŝmemoro jam estas alia mezurado. Se la bazlinio estis prenita kun la retumilo antaŭe kaj la rulo post konekto okazas en terminalo, vi komparas du solvantojn, ne du statojn de unu solvanto.

Rekta peto kaj aplikaĵa serĉo estas malsamaj testoj

Peti unu specifan servilon, per nslookup name 10.20.0.1 aŭ dig @10.20.0.1 name, pruvas unu aferon: ke la servilo, kiun vi nomis, respondas kiam vi povas atingi ĝin. Ĝi tute preterpasas la elektaĵan logikon, do ĝi ne povas diri al vi, ĉu la sistemo elektus tiun servilon por ĉi tiu nomo. Uzu ĝin por testi, ĉu la asignita solvanto estas atingebla, kaj ne uzu ĝin por testi politikon.

Serĉo tra la loka solvanto ja praktikas elekton. resolvectl query name trapasas la samajn enkursigajn domajnajn regulojn kaj raportas, kiu protokolo respondis, Resolve-DnsName en Windows trapasas la politikan tabelon kaj la klientan kaŝmemoron, kaj scutil --dns montras la ordon, kiun serĉo sekvus. Rulu ambaŭ specojn kaj tenu ilin en apartaj kolumnoj de viaj notoj. Sukcesa rekta peto apud malsukcesa aplikaĵa serĉo estas enkursiga aŭ elekta problemo, ne solvanto, kiu rifuzas labori.

Kaŝmemoro staras inter vi kaj la respondo. La operaciumo, la loka stub-solvanto, la retumilo kaj negativa kaŝmemoro ĉiuj tenas rezultojn, do serĉo povas sukcesi sen ke unu sola pako forlasu la maŝinon. Registru la rezulton antaŭ ol malplenigi ion ajn: ipconfig /flushdns, resolvectl flush-caches aŭ sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder en macOS. Preterlasu la vastan retan restarigon en ĉi tiu stadio, ĉar ĝi detruas la pruvojn, kiujn vi ankoraŭ kolektas.

Kion signifas la diferenco

Komparu la du vicojn, kiujn vi registris, kaj klasifiku la ŝanĝon antaŭ ol tuŝi eĉ unu agordon.

Unu vico meritas emfazon. Nomo, kiu solviĝas, ne estas servo, kiu funkcias, kaj DNS-sukceso diras nur, ke adreso estis trovita. Ĝi diras nenion pri plusendado, fajroŝirmilaj reguloj aŭ ĉu via konto rajtas entute uzi la servon, do finu per testado de la reala aplikaĵo anstataŭ supozi, ke la fiasko foriris mem.

Restarigu la bazlinion kaj kontrolu ĝin

Malkonektu per la propraj regiloj de la kliento anstataŭ mortigi la procezon, poste relegu la samajn tri komandojn. La serviloj por ĉiu ligilo, la politikaj eroj kaj la respondo por via testa nomo devus reveni al la bazlinio, kiun vi antaŭe skribis. Restinta politika ero post pura malkonekto estas reala difekto inda je registro, kaj ĝuste tial manaj redaktoj de generita solvanta dosiero estas malbona kutimo: la dosiero estas reskribata kaj la redakto malaperas, aŭ la redakto postvivas kaj fiksas solvanton, kiu jam ne havas vojon.

Trairu ĉi tiun liston unufoje, laŭorde. Decidu, kiun dezajnon la profilo efektivigas, antaŭ ol juĝi iun ajn rezulton. Tenu nomon, ilon kaj sufikson fiksaj en ambaŭ ruloj. Apartigu la rektan peton de la aplikaĵa serĉo. Legu la efikan politikon, ne nur la respondon. Malplenigu kaŝmemorojn laste, post kiam la komparo estas skribita. Kontrolu per la reala aplikaĵo, poste restartigu unufoje kaj konfirmu, ke la malkonektita stato ankoraŭ estas pura.