Bakit nawawala ng WSL ang pangalan ng work host kapag kumokonekta ang VPN?

Nireresolba ng Windows ang panloob na host nang walang reklamo, at ang parehong pangalan ay nabigo sa loob ng WSL sa sandaling bumangon ang tunnel. Ang karaniwang pag-aayos ay magsulat ng pampublikong resolver sa distribusyon, na nagbabalik ng ordinaryong pagba-browse at ginagawang imposibleng maresolba ang pangalan ng work host. Ipinagpapalit nito ang isang pagkabigo sa iba pa, at itinatago ang layer na talagang nasira. Bago magdagdag o mag-alis ng anumang linya ng resolver, alamin kung alin sa tatlong layer ang nabigo.

Ibukod muna ang pagkabigo sa routing

Itanong ang parehong ganap na kwalipikadong pangalan sa magkabilang panig, hindi dalawang pangalang magkahawig. Ang tagumpay sa Windows at pagkabigo sa WSL para sa parehong string ay ang pirma ng dalawang landas ng resolusyon, at kakaunti ang ibang bagay na gumagawa ng ganoong pattern nang napakalinis. Kung hindi rin maabot ng WSL ang serbisyo sa kilalang numerikong address nito, may problema rin sa routing o pag-filter. Sa ganoong kaso hindi ito ibubunyag ng gawain sa DNS, at mapupunta ang hapon sa maling layer.

Tatlong sintomas ang sumasaklaw sa karamihan ng mga kasong ito, at bawat isa ay tumuturo sa ibang lugar. Basahin ang row na tumutugma bago magbukas ng configuration file:

Ang gitnang row ang maling binabasa ng mga tao, dahil ang pagbabagong sumira nito ay ginawa ilang linggo bago at mukhang matagumpay noon. Ang ikatlong row ang maling dinadiagnose ng mga tao, dahil ang pangalang naresolba ay parang patunay na malusog ang network. Ipinapadala ka ng dalawang row sa ibang seksyon sa ibaba.

Ang DNS tunneling ay may pinakamababang bersyon

Idinodokumento ng Microsoft ang isang WSL networking mode na nagtu-tunnel ng mga DNS request sa resolver ng Windows sa pamamagitan ng virtualization channel. Sa mga sinusuportahang build ng Windows 11 ito ay naka-enable bilang default, kaya iba ang kilos ng dalawang makina sa parehong corporate network. Ang variable ay ang build number, hindi ang corporate policy.

Ang gabay sa networking ng WSL ay naglalarawan ng mode na iyon at ng mga bersyong sumusuporta rito. Mahalaga ang feature dahil ang corporate DNS policy ay karaniwang naninirahan sa resolver ng Windows, at ang distribusyong nagmamana ng landas ng Windows ay nagmamana rin ng policy. Ang distribusyong nagtatanong sa pampublikong resolver ay walang landas sa pribadong pangalan, gaano man kaayos ang sarili nitong configuration. Ang mekanismong iyon ang nagpapaliwanag sa buong sintomas, at nagpapaliwanag kung bakit nabigo ang solusyong pampublikong resolver.

Basahin ang build bago magbago ng anuman. Ang setting na kinopya mula sa mas bagong installation ay hindi patunay na ipinapatupad ito ng mas luma. Itala ang build number sa tabi ng pagbabago, dahil ang pagkakaiba ng dalawang makina ay halos palaging bersyon, hindi policy.

Ang lumang override ay nabubuhay nang mas matagal kaysa sa problemang nilutas nito

Ang mas lumang recipe ay nagpapawalang-bisa sa mga nabuong resolver file, nagha-hardcode ng nameserver o nagla-lock ng file gamit ang hindi nagbabagong attribute. Ang mga pagbabagong iyon ay nananatili sa puwesto matagal pagkatapos mawala ang problemang konektibidad na nagdulot ng mga ito, at kadalasan ang mga ito ang dahilan kung bakit ang mas bagong setting ay parang walang ginagawa. Nakakaligtas din ang mga ito sa muling pag-install ng distribusyon sa anyo ng shell profile na nagsusulat muli ng file sa bawat login. Ang huli ang pinakamahirap hanapin, dahil hindi ito nakikita mula sa file na sinisiyasat ng lahat.

Maghanap ng resolver file na isinulat sa kamay, hindi nagbabagong attribute sa ibabaw nito, at startup script na nagsusulat muli nito. Suriin ang hindi nagbabagong flag bago mag-edit, dahil ang pagsulat sa naka-lock na file ay nabibigo sa paraang mababasa na parang problema sa pahintulot. Pagkatapos ay suriin ang shell profile, dahil ang script doon ay nagbabalik ng lumang nilalaman sa loob ng ilang segundo pagkatapos ng iyong pagwawasto.

Ang pag-alis ng override ay may mga kahihinatnan, kaya itala kung ano ang inalis mo at bakit. Ang distribusyong talagang nangangailangan ng static na resolver para sa ibang layunin ay masisira kapag bumalik ang nabuong file.

Dalawang file, dalawang magkaibang papel

Ang dalawang configuration file ay naninirahan sa magkaibang lugar at kumokontrol ng magkaibang bagay, at ang pagkalito sa mga ito ay gumagawa ng mga edit na inilalapat sa maling layer. Ang file sa panig ng Windows ay nagtatakda ng mga property ng virtual machine, samantalang ang file sa panig ng distribusyon ay nagtatakda kung paano itinatayo ng distribusyong iyon ang sarili nitong resolver configuration. Wala sa kanila ang pumapalit sa isa, kaya dapat magkasundo ang dalawa.

Para sa installation na sumusuporta sa feature, ang fragment sa panig ng Windows ay maikli. Iyon ang buong pagbabago sa panig na iyon:

[wsl2]
dnsTunneling=true

Ang fragment na iyon ay kabilang sa user profile ng Windows at nalalapat sa virtual machine, hindi sa isang distribusyon. Ang tunneling ay nangangailangan din na hindi idinisable ng distribusyon ang pagbuo ng resolver, kaya ang file sa panig ng distribusyon ay dapat iwanan ang pag-uugaling iyon. Palitan ang isa nang wala ang isa at tahimik na walang ginagawa ang mode, at ito ang pinakakaraniwang paraan na iniuulat ang pag-aayos na ito bilang sira. Suriin ang parehong file sa parehong session, dahil ang dalawang edit na ginawa nang linggo ang layo ay dalawang edit na walang makaka-attribute.

I-restart, pagkatapos ay itanong mula sa magkabilang panig

Ang mga setting na ito ay binabasa kapag nagsisimula ang environment, kaya ang bagong shell sa loob ng tumatakbong distribusyon ay hindi maglo-load muli sa mga ito. Isara ang environment sa halip na i-restart ang shell, at i-save muna ang anumang tumatakbong trabaho dahil tumitigil ang bawat distribusyon kasama nito. Ang pagliban na iyon lamang ang nagpapaliwanag sa karamihan ng ulat na walang epekto ang isang pagbabago.

Pagkatapos ay itanong ang parehong tanong mula sa magkabilang panig. Ipinapakita rin ng output kung aling resolver ang huling nakuha ng distribusyon:

wsl.exe --shutdown
wsl.exe -e sh -c 'cat /etc/resolv.conf'
wsl.exe -e sh -c 'getent hosts files.corp.example'
wsl.exe -e powershell -Command 'Resolve-DnsName files.corp.example'

Ang unang command ay nagtatapos sa environment, ang pangalawa ay nagpapakita kung aling resolver ang ginagamit ng distribusyon ngayon, at ang huling dalawa ay nagtatanong ng parehong tanong sa bawat panig. Ihambing ang mga sagot, hindi ang kalagayan ng setting. Ang query na nabibigo pa rin pagkatapos ng malinis na restart na tama ang dalawang file ay tumuturo sa corporate resolver policy, at ang usapang iyon ay may ibang may-ari.