Itinakda mo ang DNS server sa adapter ng VPN, kumonekta muli, at ang pribadong pangalan ay galing pa rin sa resolver ng opisina na walang nag-configure sa laptop na ito. Ang resulta ay parang binalewala ang setting, at sa isang paraan ay ganoon nga, dahil ang listahan ng adapter ay isang hanay ng mga kandidato at hindi isang desisyon. Niresolba ng Windows ang mga pangalan sa pamamagitan ng patakaran sa namespace na maaaring magturo ng ibang server para sa isang partikular na suffix, at ang patakarang iyon ay inilalapat bago isaalang-alang ang setting ng adapter. Ang paghahanap ng tuntuning nanalo ay limang minutong trabaho kapag alam mo kung aling talahanayan ang babasahin.

Ano ang binago mo, at ano talaga ang nagpapasya

Sinasabi ng DNS address sa adapter sa kliyente kung saan maaaring magpadala ng mga query ang interface na iyon. Sinasabi ng talahanayan ng patakaran sa pagresolba ng pangalan sa kliyente kung saan dapat itong magpadala ng mga query para sa isang partikular na namespace, at sinusuri ito ayon sa pangalan, hindi ayon sa adapter. Kapag tumugma ang isang tuntunin sa suffix na tinaip mo, gagamitin ang mga server ng tuntuning iyon at hindi na mahalaga ang listahan ng adapter para sa paghahanap na iyon.

Ito ang dahilan kung bakit ang dalawang pangalan sa iisang laptop ay maaaring sumunod sa magkaibang landas sa iisang sandali. Ang host sa ilalim ng corporate suffix ay sumusunod sa sarili nitong tuntunin; ang pampublikong pangalan ay sumusunod sa default na landas, na karaniwang nangangahulugang ang adapter na unang sumagot.

Paano itinutugma ng talahanayan ang isang pangalan

Ang mga tuntunin ay naka-key ayon sa namespace, at ang pinakaspesipikong tugma ang nananalo. Ang tuntunin para sa corp.example ay nalalapat sa vpn.corp.example at hindi nalalapat sa example.net. Ang tuntuning may namespace na . ay sumasaklaw sa lahat ng hindi sinasaklaw ng ibang tuntunin, kaya ito ang pinakamapanganib na entry sa listahan at ang dapat suriin kapag ang isang walang kaugnayang site ay naresolba sa tunnel.

Ang isang tuntunin ay maaari ring magdala ng komento, patakarang nagpapahinto sa entry, at mga setting ng seguridad na walang kinalaman sa mga DNS address. Nananatiling nakikita sa configuration ang isang hintong tuntunin nang walang epekto, kaya ang isang entry na mukhang tama sa papel ay maaari pa ring hindi gumana pagkatapos ng pagbabago ng profile.

Basahin ang umiiral na talahanayan, hindi ang listahan ng hangarin

Ang mga naka-configure na tuntunin at ang umiiral na mga tuntunin ay dalawang magkaibang tanong. Inililista ng Get-DnsClientNrptRule kung ano ang nasa makina. Ipinapakita ng Get-DnsClientNrptPolicy -Effective kung ano ang aktwal na ilalapat ng kliyente, kasama ang mga halagang pinagsama mula sa patakaran at lokal na setting.

Ihambing ang suffix sa output na iyon sa pangalang sinusubukan mo, titik sa titik. Ang tuntunin para sa corp.example ay hindi humuhuli ng pangalang nagtatapos sa corp.example.com, at sapat na ang tuldok sa dulo sa isang lugar at wala sa isa pa para magbago ang tugma.

Kung walang tuntunin, nagtatanong ang Windows sa higit sa isang adapter

Kapag walang umaangkin ng pangalan sa talahanayan, maaaring ipadala ng kliyente ang query sa ilang interface at kunin ang unang sagot na dumating. Nakadepende sa oras ang resulta: ang parehong pangalan ay maaaring maresolba mula sa wired adapter noong Lunes at mula sa tunnel noong Martes, at wala sa configuration ng alinman sa mga adapter ang nagpapaliwanag ng pagkakaiba.

May dalawang paraan. Magdagdag ng tuntunin para sa namespace upang hindi na maging karera ang desisyon, o patayin ang paralelong pag-uugali sa pamamagitan ng patakaran ng kliyente ng DNS at tanggapin ang mas mabagal ngunit tiyak na resolusyon. Ang una ay karaniwang mas bagay sa VPN na may split tunnel, dahil idinodokumento nito ang layunin sa halip na umasa sa pagkakasunod-sunod.

Mga landas na lumalaktaw sa resolver nang buo

Ang browser na may naka-enable na secure DNS ay nagresolba nang mag-isa at ibinibigay lamang sa Windows ang address, kaya hindi kailanman nakikita ng talahanayan ng tuntunin ang pangalan. Ang mga kliyenteng itinayo sa mga runtime na may sariling resolver ay maaaring kumilos nang gayon din. Kapag naresolba ang isang pangalan sa isang application at nabigo sa isa pa sa parehong makina, ihambing ang dalawang landas ng resolusyon bago hawakan ang patakaran.

Suriin din kung kumokonekta ang app sa isang naka-cache na address mula sa nakaraang session. Ang Clear-DnsClientCache at pagkatapos ang parehong paghahanap ay nagbibigay ng mas malinaw na sagot kaysa sa paghinuha mula sa lumang resulta.

Subukan gamit ang pangalang nabigo

Resolbahin ang eksaktong hostname mula sa ulat, hindi isang pampublikong domain ng speed test, at itala kung aling server ang sumagot. Pagkatapos ay baguhin ang isang bagay: ang tuntunin, ang listahan ng adapter o ang pagtatalaga ng patakaran, at ulitin ang parehong paghahanap pagkatapos kumonekta muli upang mabuo muli ang inilapat na estado.

Kung naresolba ang pangalan at tumatanggi pa rin ang serbisyo, itigil ang pag-edit ng DNS. Ang susunod na kapaki-pakinabang na hakbang ay ang address at ang ruta patungo rito, dahil nagawa na ng resolusyon ng pangalan ang trabaho nito.

Kaugnay na mga artikulo