WSL2 mistet DNS etter at VPN-en koblet til? To årsaker

Ping på adresse fungerer inne i distribusjonen, pakkeinstallasjoner og git-hentinger gjør det ikke, og feilen dukket opp rett etter at tunnelen kom opp. Bare navn sluttet å løses, noe som peker på DNS og ikke på tilkobling. Å installere pakker på nytt er det mest populære feil første steget her. WSL2 har to uavhengige måter å produsere akkurat det symptomet på, og de krever forskjellige reparasjoner.

Hvorfor distribusjonen holder sin egen resolver

DNS-klienten i Windows brukes ikke inne i distribusjonen. WSL2 bygger sin egen resolver-fil ved oppstart, som peker på en stub-adresse som Windows publiserer på den virtuelle svitsjen for hjelpe-VM-en.

Den ordningen er stabil gjennom vanlige nettverksendringer fordi den skrives én gang og gjenbrukes. Ordningen slutter å være riktig når en tunnelklient skriver om vertens adapterliste etter at hjelpe-VM-en allerede er startet.

Ingenting inne i distribusjonen overvåker endringen, så filen fortsetter å peke på en adresse som kanskje ikke lenger er på veien. Det neste oppslaget venter da, går ut på tid eller får svar fra en server som aldri har hørt om den interne sonen. Innenfra slutter resolveren rett og slett å svare, og alle navn feiler på én gang.

Samle bevis på begge sider først

Registrer hva distribusjonen ser, deretter hva Windows ser, før du endrer noen av dem. Det er de to visningene sammen som skiller feilmodusene.

Inne i distribusjonen, skriv ut resolver-filen, rutetabellen og ett internt og ett offentlig oppslag:

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

På Windows, list DNS-serverne per adapter og IPv4-tabellen med metrikker. En VPN-klient installerer vanligvis en rute for WSL2-subnettet, og metrikken dens avgjør om trafikken forlater gjennom tunnelen eller blir lokal.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

Rutemetrikk eller utdatert fil

Den første feilen er den utdaterte filen. Resolveren ble skrevet for adaptertilstanden ved oppstart, og tunnelen endret den tilstanden. Stub-adressen kan nå være utilgjengelig, eller den kan nevne en server som ikke vet noe om den interne sonen.

Den andre er et ruteproblem. Når VPN-en legger til en rute som dekker WSL2-subnettet med en metrikk lavere enn vertens lenkerute, går pakker adressert til hjelpe-VM-en inn i tunnelen. Da går hver WSL2-tjeneste ut på tid, ikke bare DNS.

Den avgjørende testen koster én linje. Hvis en numerisk adresse som en offentlig resolver fortsatt svarer på ping mens navn feiler, er veien intakt og DNS er problemet. Det er tilfellet der en resolver-endring er berettiget, og tilfellet der den ikke er blir også tydelig. Hvis den numeriske testen også feiler, har hjelpe-VM-en mistet ruten sin, og ingen resolver-fil vil rette det.

For rutetilfellet, fjern den automatiske metrikken på tunneladapteren og gi den et tall over WSL2-lenkeruten:

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

Nedstengningen betyr noe. Å endre metrikken skriver ikke om den kjørende hjelpe-VM-en, så distribusjonen må bygges på nytt før endringen blir synlig.

Overta filen, bevisst

Hvis rutingen er riktig og bare interne navn feiler, er resolveren skyldneren, og du kan stoppe generatoren. Det er en bevisst endring med en vedlikeholdskostnad, ikke en midlertidig løsning man slenger på.

Opprett /etc/wsl.conf inne i distribusjonen med nettverksdelen som slår av generering, og skriv deretter resolver-filen selv, bedriftsserver først og en offentlig reserve etterpå:

[network]
generateResolvConf = false

search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

Rekkefølgen betyr noe. En offentlig resolver kan ikke svare på et internt navn, og reserven finnes bare for internett-oppslag. Når filen først er din, regenererer ingenting den, så en bedriftsserver som flytter blir et avbrudd du selv må legge merke til.

Sjekk navn, deretter pakker

Bekreft ett internt og ett offentlig navn med systemets resolver, og gjenta deretter operasjonen som feilet. Pakkebehandlere bruker noen ganger sin egen resolver, og derfor kan en fungerende getent sameksistere med en ødelagt installasjon.

Hvis du automatiserer omskrivingen, gjør den idempotent: uten tunnel, behold filen som allerede finnes i stedet for å skrive en tom serverliste.

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

Et internt oppslag som virker og et offentlig oppslag som virker, innenfra distribusjonen, er resultatet som er verdt å registrere. Et grønt VPN-ikon på verten beviser ingen av dem.