Binago ba ng VPN ang DNS ko? Ikumpara bago at pagkatapos
Maaaring sadyang ilipat ng profile ang iyong mga paghahanap. Ikumpara ang patakaran ng resolver at ang aktwal na sagot bago at pagkatapos kumonekta ang VPN, habang pinapanatiling isa ang variable.
Kinokonekta mo ang tunnel, binubuksan ang pribadong dashboard, at nareresolba ang pangalan sa isang address na hindi mo pa nakita. O ang kabaligtaran ang nangyayari: patuloy na gumagana ang browser habang ang tool sa command line ay biglang walang nareresolba. Ang dalawang resulta ay nagmumula sa iisang pagbabago, at karaniwang ipinapaliwanag ito ng mga tao sa isang pangungusap tungkol sa VPN na "gumagamit ng sarili nitong DNS", na hindi sapat na tumpak para mag-debug o mag-verify. May dalawang tanong na nakatago sa pangungusap na iyon: aling mga paghahanap ang dapat sakupin ng profile na ito, at ipinadala ba talaga ng iyong makina ang mga iyon sa resolver na ibinigay dito? Ang paghihiwalay sa kanila ang buong pamamaraan, dahil ang pagsubok na naghahalo sa kanila ay nagbibigay ng mali at tiwala sa sarili na sagot sa parehong direksyon.
Bakit nagbibigay ng resolver ang isang profile
Sa loob ng tunnel, ang mga pangalan sa likod ng malayong dulo ay karaniwang nareresolba sa mga address na umiiral lamang sa network na iyon. Ang pribadong sona tulad ng corp.internal ay walang pampublikong delegasyon, kaya ang resolver na nagseserbisyo nito ay dapat maabot mula sa loob ng tunnel. Ang parehong mekanismo ay nagsisilbi sa ikalawang layunin: kapag ang mga paghahanap ay lalabas sa provider mo, pinapanatili ng resolver sa malayong bahagi ang query sa loob ng naka-encrypt na landas. Kaya dumarating ang address ng DNS server bilang bahagi ng patakaran ng koneksyon at hindi bilang pandaigdigang setting na pinili mo nang isang beses para sa makina.
Ang address lamang ay walang ipinapasya. Ang resolver ay makakasagot lamang kung may ruta papunta roon, at ang pinakakaraniwang sira ay resolver na maabot lamang habang nakataas ang tunnel. Kapag bumagsak ang tunnel at nanatili ang patakaran, ang mga paghahanap ay pumupunta sa address na walang landas, at ang sintomas ay timeout at hindi malinis na error. Mahalaga ang pagkakaibang iyon kapag binabasa mo ang susunod na resulta ng pagsubok, dahil ang timeout ay nagpapadala ng mga tao sa mga setting ng transport na hindi kailanman nasangkot.
Ikumpara ang dalawang disenyo bago ikumpara ang mga sagot
Ang buong tunnel at ang hinatiang DNS ay nagbubunga ng magkasalungat na inaasahan, at wala sa kanila ang sira. Sa ilalim ng buong tunnel, maaaring lumipat ang bawat paghahanap sa provider o sa corporate resolver, kaya inaasahan na ang mga pampublikong pangalan ay sasagot nang iba pagkatapos kumonekta. Sa ilalim ng hinatiang DNS, ang mga nakalistang domain lamang ang pumupunta sa pribadong resolver habang ang lahat ng iba ay nananatiling lokal; sa Windows ang listahan ng domain ay nasa Name Resolution Policy Table, sa macOS sa tumutugmang mga domain ng mga setting ng DNS, at sa host na may systemd-resolved sa mga routing domain bawat link.
Ito ang paghahambing na dapat gawin muna, dahil ito ang nagpapasya kung ano ang ituturing na depekto. Sa hinatiang DNS, ang pampublikong pangalan na sumasagot mula sa bagong resolver ang dapat siyasatin, habang ang panloob na pangalan na wastong sumasagot ay ang sistemang gumagawa ng trabaho nito. Sa buong tunnel, ang anomalya ay pampublikong pangalan na sumasagot pa rin mula sa resolver ng provider mo. Inilalarawan ng dokumentasyon ng Microsoft tungkol sa resolusyon ng pangalan ng VPN ang pagkakasunod-sunod sa Windows ng mga patakarang ito, kabilang kung paano isinasaalang-alang ang tumutugmang entry ng patakaran bago ang sariling mga server ng adapter.
May ikatlong resolver sa silid na madaling makalimutan. Ang secure na DNS ng browser ay nagreresolba ng mga pangalan nang mag-isa at maaaring magpatuloy sa pagsagot pagkatapos baguhin ng tunnel ang patakaran ng operating system, kaya ang pahinang naglo-load ay nagpapatunay na gumana ang resolver ng browser, hindi na inilapat ang profile. Kung ang ihinahambing mo lamang ay ang ipinapakita ng browser, kalahati ng oras ay maling layer ang sinusubok mo.
Itala ang baseline gamit lamang ang isang variable
Baguhin ang tunnel. Huwag baguhin din ang pangalan, tool, o suffix ng paghahanap sa parehong hakbang. Pumili ng pangalang pinapayagan kang itanong, itala kung aling application ang ginamit mo, at isulat ang address na bumalik o ang eksaktong error. Sa Windows, ipinapakita ng Get-DnsClientServerAddress -AddressFamily IPv4 ang mga server bawat adapter at ipinapakita ng Get-DnsClientNrptPolicy ang mga entry ng patakaran; sa Linux na may systemd-resolved, ipinapakita ng resolvectl status ang mga DNS server at routing domain bawat link; sa macOS, ipinapakita ng scutil --dns ang pagkakasunod-sunod ng resolver na aktwal na susundin ng system.
Pagkatapos kumonekta sa pamamagitan ng karaniwang mga kontrol ng client at ulitin ang eksaktong parehong mga command. Itago ang unang output sa halip na alalahanin ito, dahil ang paghahambing ang buong punto at ang ikalawang pagbasa na kinuha pagkatapos i-clear ang cache ay isa nang ibang pagsukat. Kung ang baseline ay kinuha nang nasa harap ang browser at ang pagtakbo pagkatapos kumonekta ay nangyayari sa terminal, naghahambing ka ng dalawang resolver, hindi dalawang estado ng isang resolver.
Ang tahasang query at ang paghahanap ng application ay magkaibang pagsubok
Ang pagtatanong sa isang partikular na server, gamit ang nslookup name 10.20.0.1 o dig @10.20.0.1 name, ay nagpapatunay ng isang bagay: na ang server na pinangalanan mo ay sumasagot kapag naabot mo ito. Nilalampasan nito nang buo ang lohika ng pagpili, kaya hindi nito masasabi kung pipiliin ng system ang server na iyon para sa pangalang ito. Gamitin ito upang subukan kung naaabot ang itinalagang resolver, at huwag gamitin ito upang subukan ang patakaran.
Ang paghahanap sa pamamagitan ng lokal na resolver ay talagang gumagamit ng pagpili. Dinaraanan ng resolvectl query name ang parehong mga patakaran ng routing domain at iniuulat kung aling protocol ang sumagot, dinaraanan ng Resolve-DnsName sa Windows ang talahanayan ng patakaran at cache ng client, at ipinapakita ng scutil --dns ang pagkakasunod-sunod na susundin ng paghahanap. Patakbuhin ang parehong uri at itago ang mga ito sa magkahiwalay na column ng iyong mga tala. Ang matagumpay na tahasang query sa tabi ng bigong paghahanap ng application ay problema sa routing o pagpili, hindi resolver na tumatangging gumana.
Ang cache ay nakatayo sa pagitan mo at ng sagot. Ang operating system, lokal na stub resolver, browser, at negatibong cache ay may hawak na resulta, kaya maaaring magtagumpay ang paghahanap nang walang kahit isang packet na lumabas sa makina. Itala ang resulta bago i-clear ang anuman: ipconfig /flushdns, resolvectl flush-caches, o sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder sa macOS. Laktawan ang malawak na pag-reset ng network sa yugtong ito, dahil sinisira nito ang ebidensiyang kinokolekta mo pa.
Ano ang ibig sabihin ng pagkakaiba
Ikumpara ang dalawang naitalang hilera at uriin ang pagbabago bago hawakan ang kahit isang setting.
| 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 |
Ang isang hilera ay karapat-dapat bigyang-diin. Ang pangalang nareresolba ay hindi serbisyong gumagana, at ang tagumpay ng DNS ay nagsasabi lamang na may nahanap na address. Wala itong sinasabi tungkol sa pagpapasa, mga patakaran ng firewall, o kung maaaring gamitin ng iyong account ang serbisyo, kaya tapusin sa pamamagitan ng pagsubok sa aktwal na application sa halip na ipagpalagay na umalis nang mag-isa ang sira.
Ibalik ang baseline at i-verify
Dumiskonekta sa pamamagitan ng sariling mga kontrol ng client sa halip na patayin ang proseso, pagkatapos basahin muli ang parehong tatlong command. Ang mga server bawat link, mga entry ng patakaran, at ang sagot para sa iyong pangalan ng pagsubok ay dapat bumalik sa baseline na isinulat mo kanina. Ang natirang entry ng patakaran pagkatapos ng malinis na pagkadiskonekta ay tunay na depekto na dapat itala, at iyon din ang dahilan kung bakit ang manu-manong pag-edit ng nabuong resolver file ay masamang ugali: muling isinusulat ang file at nawawala ang edit, o nananatili ang edit at ipinipit ang resolver na wala nang ruta.
Daanan ang listahang ito nang isang beses, ayon sa pagkakasunod-sunod. Magpasya kung aling disenyo ang ipinapatupad ng profile bago hatulan ang anumang resulta. Panatilihing nakatakda ang pangalan, tool, at suffix sa parehong pagtakbo. Ihiwalay ang tahasang query sa paghahanap ng application. Basahin ang epektibong patakaran, hindi lamang ang sagot. I-clear ang mga cache sa huli, pagkatapos maisulat ang paghahambing. I-verify gamit ang tunay na application, pagkatapos i-restart nang isang beses at kumpirmahin na malinis pa rin ang nadiskonektang estado.