WSL2 tappade DNS efter att VPN anslutits? Två orsaker

Ping på adress fungerar inuti distributionen, paketinstallationer och git-hämtningar gör det inte, och felet dök upp direkt efter att tunneln kom upp. Bara namn slutade lösas upp, vilket pekar på DNS och inte på anslutning. Att installera om paket är det populäraste felaktiga första steget här. WSL2 har två oberoende sätt att producera exakt det symptomet, och de kräver olika reparationer.

Varför distributionen håller en egen resolver

DNS-klienten i Windows används inte inuti distributionen. WSL2 bygger sin egen resolver-fil vid start, som pekar på en stub-adress som Windows publicerar på den virtuella switch som hjälp-VM:en använder.

Den ordningen är stabil vid vanliga nätverksändringar eftersom den skrivs en gång och återanvänds. Ordningen slutar vara korrekt när en tunnelklient skriver om värdens adapterlista efter att hjälp-VM:en redan har startat.

Ingenting inuti distributionen bevakar ändringen, så filen fortsätter peka på en adress som kanske inte längre ligger på vägen. Nästa uppslag väntar då, går ut på tid eller får svar från en server som aldrig hört talas om den interna zonen. Inifrån slutar resolvern helt enkelt svara, och alla namn misslyckas samtidigt.

Samla bevis på båda sidor först

Registrera vad distributionen ser, sedan vad Windows ser, innan du ändrar någon av dem. Det är de två vyerna tillsammans som skiljer felmoderna åt.

Inuti distributionen, skriv ut resolver-filen, rutttabellen och ett internt och ett offentligt uppslag:

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

I Windows, lista DNS-servrarna per adapter och IPv4-tabellen med metrik. En VPN-klient installerar oftast en rutt för WSL2-subnätet, och dess metrik avgör om trafiken lämnar via tunneln eller stannar lokalt.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

Rutmetrik eller inaktuell fil

Det första felet är den inaktuella filen. Resolvern skrevs för adapterns tillstånd vid start, och tunneln ändrade det tillståndet. Dess stub-adress kan nu vara oåtkomlig, eller den kan peka ut en server som inte vet något om den interna zonen.

Det andra är ett routingproblem. När VPN lägger till en rutt som täcker WSL2-subnätet med en metrik lägre än värdens länkrutt, går paket adresserade till hjälp-VM:en in i tunneln. Då går varje WSL2-tjänst ut på tid, inte bara DNS.

Det avgörande testet kostar en rad. Om en numerisk adress som en offentlig resolver fortfarande svarar på ping medan namn misslyckas, är vägen intakt och DNS är problemet. Det är fallet där en resolver-ändring är motiverad, och fallet där den inte är det blir också tydligt. Om det numeriska testet också misslyckas har hjälp-VM:en tappat sin rutt, och ingen resolver-fil rättar det.

För routingfallet, ta bort den automatiska metrik som tunneladaptern har och ge den ett tal över WSL2-länkrutten:

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

Avstängningen spelar roll. Att ändra metriken skriver inte om den körande hjälp-VM:en, så distributionen måste byggas om innan ändringen syns.

Ta över filen, medvetet

Om routingen är korrekt och bara interna namn misslyckas är resolvern skyldig och du kan stoppa generatorn. Det är en medveten ändring med underhållskostnad, inte en tillfällig lösning att bara slänga på.

Skapa /etc/wsl.conf inuti distributionen med nätverksavsnittet som stänger av genereringen, skriv sedan resolver-filen själv, företagsservern först och en offentlig reserv efteråt:

[network]
generateResolvConf = false

search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

Ordningen spelar roll. En offentlig resolver kan inte svara på ett internt namn, och reserven finns bara för internetuppslag. När filen väl är din regenererar ingenting den, så en företagsserver som flyttar blir ett avbrott du själv måste upptäcka.

Kontrollera namn, sedan paket

Verifiera ett internt och ett offentligt namn med systemets resolver, och upprepa sedan operationen som misslyckades. Pakethanterare använder ibland en egen resolver, och därför kan en fungerande getent samexistera med en trasig installation.

Om du automatiserar omskrivningen, gör den idempotent: utan tunnel, behåll filen som redan finns i stället för att skriva en tom serverlista.

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

Ett internt uppslag som fungerar och ett offentligt uppslag som fungerar, inifrån distributionen, är resultatet som är värt att registrera. En grön VPN-ikon på värden bevisar ingendera.