WSL2 het DNS verloor nadat die VPN gekoppel het? Twee oorsake

Ping per adres werk binne die distribusie, pakketinstallasies en git-aftreksels nie, en die fout het reg nadat die tonnel opgekom het, verskyn. Net name het opgehou oplos, wat op DNS wys eerder as op verbinding. Om pakkette weer te installeer is die gewildste verkeerde eerste stap hier. WSL2 het twee onafhanklike maniere om presies daardie simptoom te veroorsaak, en hulle verg verskillende herstellings.

Waarom die distribusie sy eie resolver hou

Die Windows-DNS-kliënt word nie binne die distribusie gebruik nie. WSL2 bou met opstart sy eie resolver-lêer, wat na ’n stub-adres wys wat Windows op die virtuele skakelaar vir die nuts-VM publiseer.

Daardie reëling is stabiel oor gewone netwerkveranderinge, want dit word een keer geskryf en hergebruik. Die reëling hou op korrek wees wanneer ’n tonnelkliënt die gasheer se adapterlys herskryf nadat die nuts-VM reeds begin het.

Niks binne die distribusie hou die verandering dop nie, so die lêer bly wys na ’n adres wat dalk nie meer op die pad is nie. Die volgende opsoeking wag dan, wys uit, of kry ’n antwoord van ’n bediener wat nog nooit van die interne sone gehoor het nie. Van binne hou die resolver bloot op antwoord, en elke naam misluk gelyktydig.

Versamel eers bewyse aan albei kante

Teken op wat die distribusie sien, dan wat Windows sien, voordat jy enigeen verander. Die twee sienings saam is wat die foutmodusse onderskei.

Binne die distribusie, druk die resolver-lêer, die roetetabel en een interne en een publieke opsoeking:

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

Op Windows, lys die DNS-bediener per adapter en die IPv4-tabel met maatstawwe. ’n VPN-kliënt installeer gewoonlik ’n roete vir die WSL2-subnet, en sy maatstaf bepaal of daardie verkeer deur die tonnel verlaat of plaaslik bly.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

Roetemaatstaf of verouderde lêer

Die eerste fout is die verouderde lêer. Die resolver is vir die adaptertoestand by opstart geskryf, en die tonnel het daardie toestand verander. Sy stub-adres is dalk nou onbereikbaar, of dit noem ’n bediener wat niks van die interne sone weet nie.

Die tweede is ’n roeteprobleem. Wanneer die VPN ’n roete byvoeg wat die WSL2-subnet dek met ’n maatstaf laer as die gasheer se skakelroete, gaan pakkette wat aan die nuts-VM gerig is, in die tonnel in. Dan wys elke WSL2-diens uit, nie net DNS nie.

Die onderskeidende toets kos een reël. As ’n numeriese adres soos ’n publieke resolver nog op ping antwoord terwyl name misluk, is die pad ongeskonde en is DNS die probleem. Dit is die geval waar ’n resolver-verandering geregverdig is, en die geval waar dit nie is nie word ook duidelik. As die numeriese toets ook misluk, het die nuts-VM sy roete verloor en geen resolver-lêer sal dit regmaak nie.

Vir die roetegeval, laat vaar die outomatiese maatstaf op die tonneladapter en gee dit ’n getal bo die WSL2-skakelroete:

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

Die afskakeling maak saak. Om die maatstaf te verander herskryf nie die lopende nuts-VM nie, so die distribusie moet herbou word voordat die verandering sigbaar is.

Neem die lêer doelbewus oor

As roetering korrek is en net interne name misluk, is die resolver die skuld en jy kan die generator stop. Dit is ’n doelbewuste verandering met ’n onderhoudskoste, nie ’n workaround om sommer toe te pas nie.

Skep /etc/wsl.conf binne die distribusie met die netwerkafdeling wat generasie deaktiveer, en skryf die resolver-lêer dan self, korporatiewe bediener eerste en ’n publieke terugval tweede:

[network]
generateResolvConf = false

search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

Orde maak saak. ’n Publieke resolver kan nie ’n interne naam antwoord nie, en die terugval bestaan net vir internetopsoekings. Sodra die lêer joune is, regenereer niks dit nie, so ’n korporatiewe resolver wat skuif word ’n onderbreking wat jy self moet raaksien.

Kontroleer name, dan pakkette

Verifieer een interne en een publieke naam met die stelselresolver, en herhaal dan die bewerking wat misluk het. Pakketbestuurders gebruik soms ’n eie resolver, daarom kan ’n werkende getent saam met ’n stukkende installasie bestaan.

As jy die herskrywing outomatiseer, maak dit idempotent: sonder ’n tonnel, hou die lêer wat reeds bestaan eerder as om ’n leë bedienerlys te skryf.

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

’n Werkende interne opsoeking en ’n werkende publieke opsoeking, van binne die distribusie, is die resultaat wat werd is om op te teken. ’n Groen VPN-ikoon op die gasheer bewys nie een van die twee nie.