WSL2 mistede DNS, efter VPN-forbindelsen kom op? To årsager

En forældet resolver-fil og en konkurrerende rutemetrik giver samme symptom inde i WSL2. Optag begge sider, og ret derefter den, der faktisk er i stykker.

Ping på adresse virker inde i distributionen, pakkeinstallationer og git-hentninger gør ikke, og fejlen dukkede op lige efter, at tunnelen kom op. Kun navne holdt op med at blive opløst, hvilket peger på DNS snarere end på forbindelse. Geninstallering af pakker er det mest populære forkerte første skridt her. WSL2 har to uafhængige måder at frembringe præcis det symptom på, og de kræver forskellige reparationer.

Hvorfor distributionen holder sin egen resolver

Windows' DNS-klient bruges ikke inde i distributionen. WSL2 bygger sin egen resolver-fil ved start, som peger på en stub-adresse, som Windows offentliggør på den virtuelle switch for hjælpe-VM'en.

Den ordning er stabil gennem almindelige netværksændringer, fordi den skrives én gang og genbruges. Ordningen holder op med at være korrekt, når en tunnelklient omskriver værtens adapterliste, efter at hjælpe-VM'en allerede er startet.

Intet inde i distributionen overvåger ændringen, så filen bliver ved med at pege på en adresse, der måske ikke længere er på vejen. Det næste opslag venter så, løber tør for tid eller får svar fra en server, der aldrig har hørt om den interne zone. Indefra holder resolveren simpelthen op med at svare, og alle navne fejler på én gang.

Indsaml først beviser på begge sider

Optag, hvad distributionen ser, og derefter hvad Windows ser, før du ændrer nogen af dem. Det er de to visninger sammen, der skelner fejlmåderne.

Inde i distributionen, udskriv resolver-filen, rutetabellen og et internt og et offentligt opslag:

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

På Windows, list DNS-serverne pr. adapter og IPv4-tabellen med metrikker. En VPN-klient installerer ofte en rute for WSL2-subnettet, og dens metrik afgør, om trafikken forlader gennem tunnelen eller bliver lokal.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

Rutemetrik eller forældet fil

Den første fejl er den forældede fil. Resolveren blev skrevet til adapterens tilstand ved start, og tunnelen ændrede den tilstand. Dens stub-adresse kan nu være uopnåelig, eller den kan navngive en server, der intet ved om den interne zone.

Den anden er et routingproblem. Når VPN'en tilføjer en rute, der dækker WSL2-subnettet med en metrik lavere end værtens linkrute, går pakker adresseret til hjælpe-VM'en ind i tunnelen. Så løber hver WSL2-tjeneste tør for tid, ikke kun DNS.

Den afgørende test koster én linje. Hvis en numerisk adresse som en offentlig resolver stadig svarer på ping, mens navne fejler, er vejen intakt, og DNS er problemet. Det er tilfældet, hvor en resolver-ændring er berettiget, og tilfældet, hvor den ikke er, bliver også tydeligt. Hvis den numeriske test også fejler, har hjælpe-VM'en mistet sin rute, og ingen resolver-fil retter det.

For routingtilfældet, fjern den automatiske metrik på tunneladapteren og giv den et tal over WSL2-linkruten:

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

Nedlukningen betyder noget. Ændring af metrikken omskriver ikke den kørende hjælpe-VM, så distributionen skal genopbygges, før ændringen bliver synlig.

Overtag filen, bevidst

Hvis routing er korrekt, og kun interne navne fejler, er resolveren skyldneren, og du kan stoppe generatoren. Det er en bevidst ændring med en vedligeholdelsesomkostning, ikke en midlertidig løsning, man lige smækker på.

Opret /etc/wsl.conf inde i distributionen med netværkssektionen, der deaktiverer generering, og skriv derefter resolver-filen selv, virksomhedsserver først og et offentligt reservevalg bagefter:

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

Rækkefølgen betyder noget. En offentlig resolver kan ikke svare på et internt navn, og reserven findes kun til internetopslag. Når filen først er din, regenererer intet den, så en virksomhedsserver, der flytter, bliver et nedbrud, du selv skal opdage.

Tjek navne, derefter pakker

Bekræft et internt og et offentligt navn med systemets resolver, og gentag derefter den handling, der fejlede. Pakkehåndteringer bruger nogle gange deres egen resolver, og derfor kan en fungerende getent sameksistere med en brudt installation.

Hvis du automatiserer omskrivningen, gør den idempotent: uden tunnel, behold den fil, der allerede findes, i stedet for at skrive en tom serverliste.

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

Et internt opslag, der virker, og et offentligt opslag, der virker, indefra distributionen, er resultatet, der er værd at notere. Et grønt VPN-ikon på værten beviser ingen af dem.

Relaterede artikler