Nawala ang DNS ng WSL2 pagkatapos kumonekta ang VPN? Dalawang sanhi

Gumagana ang ping sa pamamagitan ng address sa loob ng distribusyon, hindi gumagana ang pag-install ng pakete at paghila ng git, at lumitaw ang sira kaagad matapos bumangon ang tunnel. Ang mga pangalan lang ang tumigil sa pag-resolve, na tumutukoy sa DNS at hindi sa konektibidad. Ang muling pag-install ng mga pakete ang pinakasikat na maling unang hakbang dito. May dalawang malayang paraan ang WSL2 upang gumawa ng eksaktong sintomas na iyon, at nangangailangan sila ng magkaibang pagkukumpuni.

Bakit may sariling resolver ang distribusyon

Hindi ginagamit ang DNS client ng Windows sa loob ng distribusyon. Bumubuo ang WSL2 ng sarili nitong file ng resolver sa pagsisimula, na nakaturo sa isang stub address na inilalathala ng Windows sa virtual switch para sa katulong na virtual machine.

Matatag ang kaayusang iyon sa mga ordinaryong pagbabago ng network dahil isinusulat ito minsan at ginagamit muli. Tumitigil itong maging tama kapag muling isinulat ng client ng tunnel ang listahan ng adapter ng host matapos magsimula ang katulong na virtual machine.

Walang anuman sa loob ng distribusyon ang nagmamatyag sa pagbabago, kaya patuloy na nakaturo ang file sa isang address na maaaring wala na sa landas. Ang susunod na paghahanap ay maghihintay, mauubos ang oras, o makakakuha ng sagot mula sa server na hindi kailanman nakarinig tungkol sa panloob na sona. Mula sa loob, tumitigil na lang ang resolver sa pagsagot, at sabay na nabigo ang lahat ng pangalan.

Mangalap muna ng ebidensya sa dalawang panig

Itala kung ano ang nakikita ng distribusyon, pagkatapos kung ano ang nakikita ng Windows, bago baguhin ang alinman sa dalawa. Ang dalawang pananaw na magkasama ang nagtatangi sa mga paraan ng pagkasira.

Sa loob ng distribusyon, i-print ang file ng resolver, ang talahanayan ng ruta at isang panloob at isang pampublikong paghahanap:

ip -4 route
cat /etc/resolv.conf
getent hosts intranet.corp.example
getent hosts example.com

Sa Windows, ilista ang mga DNS server bawat adapter at ang talahanayan ng IPv4 kasama ang mga sukatan. Karaniwang nag-i-install ang client ng VPN ng ruta para sa subnet ng WSL2, at ang sukatan nito ang nagpapasya kung lalabas ang trapik na iyon sa tunnel o mananatiling lokal.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

Sukatan ng ruta o lumang file

Ang unang sira ay ang lumang file. Isinulat ang resolver para sa kalagayan ng adapter sa pagsisimula, at binago ng tunnel ang kalagayang iyon. Maaaring hindi na maabot ngayon ang stub address nito, o maaaring pangalanan nito ang server na walang alam tungkol sa panloob na sona.

Ang pangalawa ay problema sa ruta. Kapag nagdagdag ang VPN ng rutang sumasaklaw sa subnet ng WSL2 na may sukat na mas mababa kaysa ruta ng link ng host, pumapasok sa tunnel ang mga packet na nakadirekta sa katulong na virtual machine. Pagkatapos, nauubos ang oras ng bawat serbisyo ng WSL2, hindi lang ng DNS.

Ang pagsubok na nagtatangi ay isang linya lang. Kung ang numerikong address tulad ng pampublikong resolver ay sumasagot pa sa ping habang nabigo ang mga pangalan, buo ang landas at ang problema ay DNS. Ito ang kaso kung saan makatwiran ang pagbabago ng resolver, at ang kaso kung saan hindi ay nagiging malinaw din. Kung nabigo rin ang numerikong pagsubok, nawala na ng katulong na virtual machine ang ruta nito at wala nang file ng resolver ang makakaayos niyon.

Para sa kaso ng ruta, alisin ang awtomatikong sukatan sa adapter ng tunnel at bigyan ito ng numerong mas mataas kaysa ruta ng link ng WSL2:

Get-NetAdapter | Where-Object InterfaceDescription -Match VPN | Set-NetIPInterface -InterfaceMetric 5500
wsl.exe --shutdown

Mahalaga ang pagsasara. Ang pagbabago ng sukatan ay hindi nagsusulat muli ng tumatakbong katulong na virtual machine, kaya kailangang itayo muli ang distribusyon bago makita ang pagbabago.

Kunin ang file, nang sinasadya

Kung tama ang ruta at ang panloob na pangalan lang ang nabigo, ang resolver ang may kasalanan at maaari mong ihinto ang generator. Ito ay sinadyang pagbabago na may gastos sa pagpapanatili, hindi isang pansamantalang solusyon na basta ilalapat.

Gumawa ng /etc/wsl.conf sa loob ng distribusyon kasama ang seksyon ng network na nagpapahinto sa pagbuo, pagkatapos ay ikaw mismo ang magsulat ng file ng resolver, una ang server ng kumpanya at pagkatapos ang pampublikong reserba:

[network]
generateResolvConf = false

search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

Mahalaga ang pagkakasunod-sunod. Hindi masasagot ng pampublikong resolver ang panloob na pangalan, at ang reserba ay para lamang sa mga paghahanap sa internet. Kapag ang file ay sa iyo na, wala nang muling gumagawa nito, kaya ang lumilipat na resolver ng kumpanya ay nagiging pagkaantala na ikaw mismo ang dapat makapansin.

Suriin ang mga pangalan, pagkatapos ang mga pakete

Tiyakin ang isang panloob at isang pampublikong pangalan gamit ang resolver ng sistema, pagkatapos ay ulitin ang operasyong nabigo. Minsan gumagamit ang mga tagapamahala ng pakete ng sarili nilang resolver, kaya ang gumaganang getent ay maaaring mabuhay kasama ng sirang pag-install.

Kung awtomatiko mong gagawin ang muling pagsulat, gawin itong idempotent: kung walang tunnel, panatilihin ang file na mayroon na sa halip na magsulat ng walang laman na listahan ng server.

getent hosts intranet.corp.example
resolvectl status | head -20
getent hosts example.com

Ang gumaganang panloob na paghahanap at gumaganang pampublikong paghahanap, mula sa loob ng distribusyon, ang resulta na sulit itala. Ang berdeng icon ng VPN sa host ay hindi nagpapatunay sa alinman sa dalawa.