WSL2 ferlear DNS nei't de VPN ferbûn wie? Twa oarsaken

In ferâldere resolver-bestân en in konkurrearjende rûtemetryk jouwe itselde symptoom yn WSL2. Lês beide kanten út en reparearje dan dy't echt stikken is.

Ping op adres wurket binnen de distribúsje, pakketynstallaasjes en git-hels net, en de flater kaam krekt nei't de tunnel oan gie. Allinnich nammen holden op mei oplossen, wat op DNS wiist en net op ferbining. Pakketten opnij ynstallearje is hjir de populêrste ferkearde earste stap. WSL2 hat twa ûnôfhinklike manieren om krekt dat symptoom te meitsjen, en se freegje ferskillende reparaasjes.

Wêrom't de distribúsje syn eigen resolver hâldt

De DNS-klant fan Windows wurdt net binnen de distribúsje brûkt. WSL2 bout by it starten syn eigen resolver-bestân, dat wiist nei in stub-adres dat Windows op de firtuele skeakel foar de helpfirtuele masine publisearret.

Dy oanpak is stabyl by gewoane netwurkferoarings, want hy wurdt ien kear skreaun en wer brûkt. De oanpak is net mear goed as in tunnelklant de adapterlist fan de host opnij skriuwt nei't de helpfirtuele masine al starten is.

Neat binnen de distribúsje hâldt dy feroaring by, dus it bestân wiist troch nei in adres dat miskien net mear op it paad is. De folgjende opfrege wachtet dan, rint ôf of krijt in antwurd fan in tsjinner dy't nea fan de ynterne sône heard hat. Fan binnenwei hâldt de resolver gewoan op mei antwurdzjen, en alle nammen mislearje tagelyk.

Sammeletearje earst bewiis fan beide kanten

Lês ôf wat de distribúsje sjocht, en dan wat Windows sjocht, foardat jo ien fan beide feroarje. De beide bylden tegearre binne wat de flatermodi ûnderskiedt.

Binnen de distribúsje, printsje it resolver-bestân, de rûte-tabel en ien ynterne en ien publike opfrege:

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

Op Windows, lis de DNS-tsjinners per adapter op en de IPv4-tabel mei metryk. In VPN-klant ynstallearret faak in rûte foar it WSL2-subnet, en syn metryk beslút oft dat ferkear troch de tunnel fuortgiet of lokaal bliuwt.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

Rûtemetryk of ferâldere bestân

De earste flater is it ferâldere bestân. De resolver waard skreaun foar de adapterstân by it starten, en de tunnel feroare dy stân. Syn stub-adres is no miskien net mear berikber, of it neamt in tsjinner dy't neat fan de ynterne sône wit.

De twadde is in rûteprobleem. As de VPN in rûte tafoeget dy't it WSL2-subnet dekt mei in metryk leger as de linkrûte fan de host, geane pakketten nei de helpfirtuele masine de tunnel yn. Dan rint elke WSL2-tsjinst ôf, net allinnich DNS.

De ûnderskiedende test kostet ien rigel. As in numerysk adres lykas in publike resolver noch op ping antwurdet wylst nammen mislearje, is it paad yntakt en is DNS it probleem. Dat is it gefal wêryn't in resolver-feroaring rjochtfeardige is, en it gefal wêryn't dat net sa is wurdt ek dúdlik. As de numeryske test ek mislearret, hat de helpfirtuele masine syn rûte ferlern en gjin resolver-bestân sil dat meitsje.

Foar it rûtegefal, smyt de automatyske metryk op de tunneladapter fuort en jou him in getal boppe de WSL2-linkrûte:

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

It ôfsluten makket út. It feroarjen fan de metryk skriuwt de rinnende helpfirtuele masine net opnij, dus de distribúsje moat opnij boud wurde foardat de feroaring te sjen is.

Nim it bestân oer, bewust

As rûtering goed is en allinnich ynterne nammen mislearje, is de resolver de skuld en kinne jo de generator stopje. Dat is in bewuste feroaring mei ûnderhâldskosten, net in provisoarium om samar ta te passen.

Meitsje /etc/wsl.conf binnen de distribúsje mei de netwurkseksje dy't de generaasje útskeakelet, en skriuw dan it resolver-bestân sels, bedriuwstsjinner earst en in publike efterfal dêrnei:

[network]
generateResolvConf = false
search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

De folchoarder makket út. In publike resolver kin in ynterne namme net beantwurdzje, en de efterfal bestiet allinnich foar ynternetopfregen. As it bestân ienris fan jo is, regenearret neat it, dus in bedriuwstsjinner dy't ferhúzet wurdt in ûnderbrekking dy't jo sels fernimme moatte.

Kontrolearje nammen, dan pakketten

Kontrolearje ien ynterne en ien publike namme mei de systeemresolver, en werhelje dan de bewurking dy't mislearre. Pakketbehearders brûke soms har eigen resolver, dêrom kin in wurkjende getent njonken in stikken ynstallaasje bestean.

As jo it opnij skriuwen automatisearje, meitsje it idempotint: sûnder tunnel, hâld it bestân dat al bestiet yn stee fan in lege tsjinnerlist te skriuwen.

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

In wurkjende ynterne opfrege en in wurkjende publike opfrege, fan binnen de distribúsje, is it resultaat dat it fêstlizzen wurdich is. In grien VPN-ikoan op de host bewiist gjin fan beide.

Relatearre artikelen