Maling DNS server sa Windows VPN: metric, binding order o suffix
Tatlong mekanismo ng Windows ang pumipili ng DNS resolver, at nagkakamali sila sa magkaibang paraan. Magpasya ayon sa saklaw ng namespace, pandaigdigang order o kung nakakaligtas ang pagbabago pagkatapos ng muling pagkonekta.
Ang isang Windows client ay maaaring may gumaganang tunnel, may dalang corporate resolver at nagpapadala pa rin ng mga panloob na pangalan sa home router. Tatlong magkakaibang mekanismo ang nagpapasya kung aling server ang sasagot, at nagkakamali sila sa magkaibang paraan. Hindi kailangang ayusin ang tatlo: sinasabi ng sintomas kung alin ang nasa laro. Ang decision tree sa ibaba ay tumatagal ng ilang minuto at pumipigil sa karaniwang kinalabasan, kung saan dumarating nang sabay ang pagbabago ng metric, muling pag-aayos ng registry at panuntunan ng NRPT at walang nakakaalam kung alin ang may ginawa.
Tatlong mekanismo ang nagpapasya, at kadalasan isa ang mali
Ang metric ng interface ay nag-aayos ng mga adapter para sa isang partikular na pamilya ng address. Ang binding order sa ilalim ng Tcpip\Linkage ay isang listahan sa antas ng makina ng mga identifier ng interface na tinitingnan pa rin ng mas lumang mga code path. Ang Name Resolution Policy Table (NRPT) ay nag-uugnay ng namespace sa mga partikular na server, at ang suffix list ay nagpapasya kung ang maikling pangalan ay palalawakin. Independent sila, kaya natatalo ng tamang resolver sa VPN adapter ang isang lumang kagustuhan sa ibang lugar.
| What you see | Mechanism to check | First command |
|---|---|---|
| Every name is slow, public names sometimes wrong | Global adapter order: metric, then Linkage | Get-NetIPInterface |
| Internal names resolve to a public address | The query left through the home resolver, not the tunnel | Resolve-DnsName intranet.corp.example -Type A, then the same query with -Server 10.20.0.10 |
| Only corp.example names fail, public names fine | Namespace binding: NRPT or suffix | Get-DnsClientNrptRule |
| Short name fails, fully qualified name works | Suffix list on the adapter, with the corporate suffix ahead of other entries, or pushed by the server | Get-DnsClientGlobalSetting |
| Works, then breaks after a reconnect | Runtime setting that was never persisted | Get-VpnConnection for the stored profile, then Get-NetIPInterface again after a reconnect |
Wala sa mga mekanismong ito ang kabilang dulo ng tunnel. Kung ang server na itinutulak ng VPN ay hindi maresolba ang pangalan, lahat ng setting sa panig ng client ay palamuti lamang, kaya ang unang desisyon ay kung ang resolver mismo ay makasagot kapag direktang tinanong.
Desisyon isa: makasagot ba ang itinulak na resolver?
Tananan ang server nang tahasan at ihambing sa ordinaryong paghahanap. Ang agwat sa pagitan ng mga sagot ay naghihiwalay ng problema sa pagpili mula sa problema sa maabot, at ito ang pinakamabilis na sanga dito:
Resolve-DnsName intranet.corp.example -Server 10.20.0.10 -Type A
Resolve-DnsName intranet.corp.example -Type AKung ang una ay matagumpay at ang pangalawa ay nabigo, ang resolver ay maabot at mali ang pinipili ng Windows; pumunta sa mga desisyon sa namespace at order sa ibaba. Kung ang una ay nabigo rin, walang makakatulong sa client: tingnan kung ang UDP at TCP 53 ay nakakaabot sa server sa pamamagitan ng tunnel, kung walang host firewall sa server ang nagtatapon ng pool, at kung malusog ang sariling forwarder ng server.
Huminto sa sangang ito. Ang paglalapat ng panuntunan ng NRPT sa isang resolver na hindi mo maabot ay nagdudulot ng parehong kabiguan na may mas maraming configuration na babawiin, at itinatago nito ang tunay na depekto sa likod ng panuntunang mukhang may awtoridad.
Desisyon dalawa: isang namespace o bawat query?
Ang saklaw ang nagpapasya ng kasangkapan. Kapag nabigo lamang ang mga pangalan ng kumpanya, iugnay ang namespace sa halip na muling ayusin ang makina: ipinapadala ng panuntunan ng NRPT ang suffix na iyon sa resolver ng tunnel at hinahayaang tahimik ang lahat ng iba. Kapag apektado ang bawat paghahanap, ang problema ay pandaigdigang kagustuhan ng adapter, at ang metric ang lugar na simulang tingnan dahil wala itong binabagong setting ng server.
Itakda ang metric sa bawat pamilya ng address, sa parehong interface, at pagkatapos ay tiyakin ang order:
Get-NetIPInterface | Select-Object ifIndex, InterfaceAlias, AddressFamily, InterfaceMetric
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv4
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv6Palitan ang 11 ng ifIndex ng tunnel adapter mula sa linyang nasa itaas; kung ang 11 ay ang LAN adapter, ibinababa ng parehong command ang maling landas. Ang pagtaas sa LAN adapter sa halip ay umabot sa parehong order mula sa kabilang panig: netsh int ip set interface interface="Ethernet" metric=15, at netsh int ipv6 set interface interface="Ethernet" metric=15 para sa pangalawang pamilya, dahil ang int ip ay humahawak lamang sa IPv4.
Ang binding order ay ang huling paraan at hindi ang unang hakbang. Ang HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage ay may listahan ng Bind ng mga identifier ng device, at ang paglipat ng identifier ng tunnel sa unahan ay talagang nagbabago kung aling adapter ang unang tatanungin, ngunit ito ay halaga ng registry sa antas ng makina na walang saklaw sa bawat namespace. I-export ito bago mag-edit at pagkatapos ay ikonekta muli ang tunnel, upang ang order ay umiral sa kalagayang inaasahan ng client.
Para sa isang namespace, piliin ang mas makitid na kasangkapan:
Add-DnsClientNrptRule -Namespace ".corp.example" -NameServers 10.20.0.10
Get-DnsClientNrptRule | Select-Object Namespace, NameServersDesisyon tatlo: nakakaligtas ba ang pagbabago pagkatapos ng muling pagkonekta?
Ang metric na gumagana hanggang sa susunod na dial-up na pagkonekta ay hindi kailanman na-save. Ang L2TP/IPsec at iba pang profile ng koneksyon ay muling ginagawa kapag nagsisimula ang koneksyon, kaya ang naka-save na halaga ay nabubuhay sa entry ng phone book bilang IpInterfaceMetric, hindi lamang sa live na interface. Ang ilang kapaligiran ay nagsu-script ng field na iyon dahil dito; ang iba ay nagtutulak ng kagustuhan mula sa patakaran ng pamamahala at hinahayaang tahimik ang endpoint.
Ang cache at pagpaparehistro ay hiwalay na antas. Ang pagpapatakbo ng mga ito pagkatapos umangat ang tunnel ay nag-aayos ng mga lumang entry at muling nagpaparehistro ng client, ngunit wala sa kanila ang muling nag-aayos ng adapter:
ipconfig /registerdns
ipconfig /flushdnsMay switch ng pag-off sa parehong antas. Ang pag-disable ng dynamic na pagpaparehistro sa pisikal na adapter ay pumipigil sa client na ipahayag ang address nito sa panig ng VPN sa ilalim ng maling pangalan, at ibang pagkukumpuni iyon kaysa sa refresh sa itaas.
Ang IPv6 ay karapat-dapat sa sariling linya sa desisyon. Kung ang pisikal na adapter ay may pandaigdigang address na IPv6 habang ang tunnel ay nagdadala lamang ng IPv4, maaaring piliin ng Windows ang landas na walang tunnel para sa paglutas ng pangalan. Suriin ang pamilyang iyon nang hiwalay, dahil ang metric na itinakda para sa IPv4 ay walang sinasabi tungkol dito:
Get-NetIPInterface -AddressFamily IPv6 | Select-Object ifIndex, InterfaceAlias, InterfaceMetricAng pag-disable ng IPv6 sa LAN adapter ay nag-aalis ng landas na iyon at ng protocol kasama nito; ang pagbabago ng metric sa IPv6 interface, o panuntunan ng NRPT para sa corporate namespace, ay nagpapanatili ng pamilya at nag-aayos ng kagustuhan. Piliin ang mas makitid, maliban kung napagpasyahan mong hindi dapat magkaroon ng IPv6 ang link na iyon.
Tiyakin gamit ang pinangalanang source, at panatilihin ang isang may-ari
Tiyakin gamit ang mga tool na nag-uulat kung aling source ang may bisa, hindi lamang kung naglo-load ang isang pahina:
ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type APagkatapos ay ihiwalay ang pag-filter sa pagpili, dahil mula sa loob ng isang application ay magkamukha sila. Ang block-outside-dns ng OpenVPN ay humaharang sa port 53 sa ibang mga adapter; hindi ito pumipili ng resolver. Kung ngayon ay nabigo ang bawat query, maaaring hinaharang ng filter ang tanging server na maabot; kung ang naka-configure na resolver ay binabalewala, mali ang order o ang panuntunan ng namespace. Ang pagbabago sa dalawa nang sabay ay ginagawang hindi makilala ang isang harang na query at isang binabalewalang query.
Panatilihin ang isang may-ari ng patakaran ng DNS: ang profile ng VPN, patakaran ng pamamahala o panuntunan ng NRPT, hindi dalawa sa kanila. Bago isara:
- Sumasagot ang itinulak na resolver kapag tahasang pinangalanan, at ginagamit ito ng ordinaryong paghahanap.
- Sakop ng binago mong panuntunan o metric ang pamilya ng address na tunay na nagdadala ng mga query.
- Nakakaligtas ang setting pagkatapos ng pagputol at muling pagkonekta, o inilipat mo ito sa naka-save na profile.
- Eksaktong isang mekanismo ang may awtoridad, at ang iba ay iniwan kung ano sila.
Ituring ang order bilang kalagayan ng kapaligiran at hindi bilang isang bagay na tinatapos. Suriin itong muli pagkatapos ng muling pagkonekta at pagkatapos ng update ng Windows na humahawak sa stack ng network, dahil maaaring ibalik ng alinman sa dalawa ang pisikal na adapter sa unahan.