Mista WSL2 DNS etter at VPN-en kopla til? To årsaker

Ping på adresse fungerer inne i distribusjonen, pakkeinstallasjonar og git-hentingar gjer det ikkje, og feilen dukka opp rett etter at tunnelen kom opp. Berre namn slutta å løysast, noko som peikar på DNS og ikkje på tilkopling. Å installere pakkar på nytt er det mest populære feil første steget her. WSL2 har to uavhengige måtar å produsere akkurat det symptomet på, og dei krev ulike reparasjonar.

Kvifor distribusjonen held sin eigen resolver

DNS-klienten i Windows vert ikkje brukt inne i distribusjonen. WSL2 byggjer si eiga resolver-fil ved oppstart, som peikar på ei stub-adresse som Windows publiserer på den virtuelle svitsjen for hjelpe-VM-en.

Den ordninga er stabil gjennom vanlege nettverksendringar fordi ho vert skriven éin gong og gjenbrukt. Ordninga sluttar å vere riktig når ein tunnelklient skriv om adapterlista til verten etter at hjelpe-VM-en allereie er starta.

Ingenting inne i distribusjonen overvakar endringa, så fila held fram med å peike på ei adresse som kanskje ikkje lenger er på vegen. Det neste oppslaget ventar då, går ut på tid eller får svar frå ein tenar som aldri har høyrt om den interne sona. Innanfrå sluttar resolveren rett og slett å svare, og alle namn feilar på éin gong.

Samle bevis på begge sider først

Registrer kva distribusjonen ser, deretter kva Windows ser, før du endrar nokon av dei. Det er dei to visingane saman som skil feilmodusane.

Inne i distribusjonen, skriv ut resolver-fila, rutetabellen og eitt internt og eitt offentleg oppslag:

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

På Windows, list DNS-tenarane per adapter og IPv4-tabellen med metrikkar. Ein VPN-klient installerer vanlegvis ei rute for WSL2-subnettet, og metrikken hennar avgjer om trafikken forlèt gjennom tunnelen eller vert lokal.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

Rutemetrikk eller utdatert fil

Den første feilen er den utdaterte fila. Resolveren vart skriven for adaptertilstanden ved oppstart, og tunnelen endra den tilstanden. Stub-adressa kan no vere utilgjengeleg, eller ho kan nemne ein tenar som ikkje veit noko om den interne sona.

Den andre er eit ruteproblem. Når VPN-en legg til ei rute som dekkjer WSL2-subnettet med ein metrikk lågare enn lenkjeruta til verten, går pakkar adresserte til hjelpe-VM-en inn i tunnelen. Då går kvar WSL2-teneste ut på tid, ikkje berre DNS.

Den avgjerande testen kostar éi line. Viss ei numerisk adresse som ein offentleg resolver framleis svarar på ping medan namn feilar, er vegen intakt og DNS er problemet. Det er tilfellet der ei resolver-endring er rettferdiggjord, og tilfellet der ho ikkje er det vert også tydeleg. Viss den numeriske testen også feilar, har hjelpe-VM-en mista ruta si, og inga resolver-fil vil rette det.

For rutetilfellet, fjern den automatiske metrikken på tunneladapteren og gje han eit tal over WSL2-lenkjeruta:

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

Nedstenginga betyr noko. Å endre metrikken skriv ikkje om den køyrande hjelpe-VM-en, så distribusjonen må byggjast på nytt før endringa vert synleg.

Tak over fila, medvite

Viss rutinga er riktig og berre interne namn feilar, er resolveren skuldaren, og du kan stoppe generatoren. Det er ei medviten endring med ein vedlikehaldskostnad, ikkje ei mellombels løysing ein slengjer på.

Opprett /etc/wsl.conf inne i distribusjonen med nettverksdelen som slår av generering, og skriv deretter resolver-fila sjølv, bedriftstenar først og ein offentleg reserve etterpå:

[network]
generateResolvConf = false

search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

Rekkjefølgja betyr noko. Ein offentleg resolver kan ikkje svare på eit internt namn, og reserven finst berre for internett-oppslag. Når fila først er di, regenererer ingenting ho, så ein bedriftstenar som flyttar vert eit avbrot du sjølv må leggje merke til.

Sjekk namn, deretter pakkar

Stadfest eitt internt og eitt offentleg namn med resolveren til systemet, og gjer deretter om att operasjonen som feila. Pakkehandsamarar brukar stundom sin eigen resolver, og difor kan ein fungerande getent sameksistere med ein øydelagd installasjon.

Viss du automatiserer omskrivinga, gjer ho idempotent: utan tunnel, hald på fila som allereie finst i staden for å skrive ei tom tenarliste.

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

Eit internt oppslag som verkar og eit offentleg oppslag som verkar, innanfrå distribusjonen, er resultatet som er verdt å registrere. Eit grønt VPN-ikon på verten beviser ingen av dei.