Paglabas ng DNS sa VPN ng Windows: bakit tinatalo ng metriko ang ruta

Lumalabas ang isang query sa makina at nakarating sa router ng bahay habang ang bawat packet ay dumadaan sa tunnel. Ang likas na konklusyon ay kulang na ruta, at ang ruta ay karaniwang maayos. Maaaring piliin ng Windows kung kaninong resolver ng interface tatanungin ayon sa metriko ng interface, at madalas na natatalo ng tunnel adapter ang paghahambing na iyon sa wireless.

Dalawang paliwanag para sa isang paglabas

Sinasabi ng paliwanag sa ruta na may bahagi ng trapiko na tumatakas sa tunnel, kaya mali ang default na ruta o ang listahan ng split tunnel. Masusubok ang paliwanag na iyon sa isang utos, at kapag ang default na ruta ay tumuturo sa loob ng tunnel, tapos na ang usapin. Suriin muna ito dahil mura, at pagkatapos ay itabi kapag malinis na bumabalik.

Sinasabi ng paliwanag sa ranggo na ang trapiko ay buo sa tunnel at ang lookup ay ipinapadala pa rin sa ibang resolver. Itinuturing ng Windows ang pagpili ng resolver na katangian ng bawat interface na may pagkakasunod-sunod, kaya ang pisikal na adapter na may mas mabuting metriko ay makapagbibigay ng DNS para sa isang pangalan kahit na ang mga packet para sa naresolbang address ay dumadaan sa tunnel. Pareho ang sintomas ng dalawang paliwanag sa pahina ng pagsubok sa paglabas, kaya hindi ang pagsubok ang diagnosis. Isa lamang sa kanila ang naaayos sa pamamagitan ng pag-edit ng ruta.

Paghambingin ang metriko at resolver nang sabay

Itala ang mga interface, ang kanilang metriko at ang mga naka-configure na server habang nakaupo ang tunnel. Basahin ang mga ito bilang talahanayan at hindi bilang dalawang hiwalay na listahan, dahil ang tanong ay alin ang resolver na nauuna, hindi kung aling mga resolver ang umiiral.

Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Select-Object InterfaceIndex, InterfaceAlias, InterfaceMetric
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, ServerAddresses

Kung mas mataas ang bilang ng tunnel adapter kaysa sa pisikal na adapter, hindi pinapaboran ang resolver nito, at ang panloob na pangalan ay pupunta sa anumang iniaalok ng pisikal na panig. Maaaring sumagot ang router na iyon mula sa cache, ipasa ang query, o tanggihan ito, at wala sa mga kinalabasang iyon ang disenyong inaasahan mo. Kagustuhan lamang ang ranggo, kaya tahimik itong natatalo sa halip na magbuga ng error.

Ang tunnel adapter na walang anumang naka-configure na resolver ay kasing karaniwang variant. Itinataas ng client ang interface nang hindi nagtutulak ng DNS, kaya hindi man lang lumilitaw ang tanong sa ranggo.

Itaas ang tunnel at muling suriin

Bigyan ang tunnel interface ng pinakamababang metriko, o itaas ang halaga ng pisikal na adapter, sa isang elevated na shell. Pareho silang setting sa bawat interface at parehong maibabalik, na mahalaga kapag binabago mo ang makinang maaaring hindi mo kinauupuan.

Set-NetIPInterface -InterfaceIndex 27 -InterfaceMetric 1
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric

Agad nakikita ang pagbabago, at ang DNS client at iba pang consumer ay nagcache ng napili na nila. Ikonekta muli ang tunnel, o i-restart, bago magbasa ng anuman mula sa resulta ng query. Ang pagsubok na masyadong maaga ay mag-uulit ng lumang gawi at magmumukhang bigong pag-aayos.

Pagkatapos, magtanong ng isang panloob at isang pampublikong pangalan at tingnan kung aling server ang sumagot. Ipinapaliwanag ng sanggunian tungkol sa awtomatikong metriko ng Microsoft kung bakit pinapaboran ang pinakamababang halaga at kung paano hinango ang awtomatikong paglalaan.

Gawin itong matibay sa muling pagkonekta

Ang manu-manong metriko sa adapter na muling ginagawa sa bawat koneksyon ay setting na naglalaho. Kung muling itatayo ng client ang interface, kailangan ng override na ito ng script pagkatapos ng koneksyon, patakaran, o configuration ng client na may-ari ng DNS habang nakakonekta.

Ang mga server na naka-configure nang static sa pisikal na adapter ay may parehong problema sa tibay sa kabaligtaran. Patuloy silang sumasagot para sa interface na iyon hanggang maalis, at pupunuin silang muli ng DHCP mula sa susunod na lease, kaya ang pag-alis sa kanila ay pagsukat at hindi disenyo. Ang matibay na disenyo ay patakaran sa paglutas ng pangalan para sa panloob na namespace, o isang client na kumukuha ng DNS sa buong tagal ng koneksyon. Alinman sa dalawa, itala ang listahan ng resolver bago at pagkatapos ng muling pagkonekta, ibalik ang orihinal na metriko kapag tapos ka nang subukan, at kumpirmahin na bumalik ang dating gawi.