WSL2 je izgubil DNS po povezavi z VPN? Dva vzroka

Ping po naslovu deluje v distribuciji, namestitve paketov in prenosi git ne, napaka pa se je pojavila takoj po dvigu tunela. Samo imena se niso več razreševala, kar kaže na DNS in ne na povezljivost. Ponovna namestitev paketov je tukaj najbolj priljubljen napačen prvi korak. WSL2 ima dva neodvisna načina, da ustvari točno ta simptom, in zahtevata različna popravila.

Zakaj distribucija hrani svoj resolver

Odjemalec DNS iz Windows se v distribuciji ne uporablja. WSL2 ob zagonu zgradi svojo datoteko resolverja, ki kaže na naslov stub, ki ga Windows objavi na virtualnem stikalu za pomožni virtualni stroj.

Ta ureditev je stabilna pri običajnih omrežnih spremembah, ker se zapiše enkrat in znova uporabi. Ureditev preneha biti pravilna, ko odjemalec tunela prepiše seznam adapterjev gostitelja, potem ko je pomožni virtualni stroj že zagnan.

Nič v distribuciji ne spremlja spremembe, zato datoteka še naprej kaže na naslov, ki ga morda ni več na poti. Naslednje iskanje potem čaka, poteče ali dobi odgovor strežnika, ki ni nikoli slišal za notranjo cono. Od znotraj resolver preprosto preneha odgovarjati in vsa imena odpovejo hkrati.

Najprej zberite dokaze na obeh straneh

Zabeležite, kaj vidi distribucija, nato kaj vidi Windows, preden karkoli spremenite. Prav oba pogleda skupaj ločita načina okvare.

V distribuciji izpišite datoteko resolverja, usmerjevalno tabelo ter eno notranje in eno javno iskanje:

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

V Windows naštete strežnike DNS po adapterju in tabelo IPv4 z metrikami. Odjemalec VPN običajno namesti pot za podomrežje WSL2, njegova metrika pa odloči, ali promet odide skozi tunel ali ostane lokalno.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

Metrika poti ali zastarela datoteka

Prva okvara je zastarela datoteka. Resolver je bil napisan za stanje adapterja ob zagonu, tunel pa je to stanje spremenil. Njegov naslov stub je zdaj morda nedosegljiv ali pa navaja strežnik, ki ne ve ničesar o notranji coni.

Druga je težava z usmerjanjem. Ko VPN doda pot, ki pokriva podomrežje WSL2, z metriko nižjo od poti povezave gostitelja, paketi, naslovljeni na pomožni virtualni stroj, vstopijo v tunel. Tedaj poteče vsaka storitev WSL2, ne le DNS.

Razlikovalni test stane eno vrstico. Če številčni naslov, na primer javni resolver, še vedno odgovarja na ping, medtem ko imena odpovedo, je pot nepoškodovana in težava je DNS. To je primer, ko je sprememba resolverja upravičena, primer, ko ni, pa prav tako postane očiten. Če tudi številčni test odpove, je pomožni virtualni stroj izgubil pot in nobena datoteka resolverja tega ne bo popravila.

Za primer usmerjanja odstranite samodejno metriko z adapterja tunela in mu dajte številko nad potjo povezave WSL2:

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

Izklop je pomemben. Sprememba metrike ne prepiše delujočega pomožnega virtualnega stroja, zato je treba distribucijo znova zgraditi, preden sprememba postane vidna.

Prevzemite datoteko, zavestno

Če je usmerjanje pravilno in odpovedo samo notranja imena, je kriv resolver in generator lahko ustavite. To je zavestna sprememba s stroškom vzdrževanja, ne obhod, ki bi ga uporabljali mimogrede.

Ustvarite /etc/wsl.conf v distribuciji z omrežnim razdelkom, ki izklopi ustvarjanje, in nato datoteko resolverja napišite sami, najprej podjetniški strežnik in nato javna rezerva:

[network]
generateResolvConf = false

search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

Vrstni red je pomemben. Javni resolver ne more odgovoriti na notranje ime, rezerva pa obstaja samo za internetna iskanja. Ko je datoteka vaša, je nič ne ustvari znova, zato podjetniški resolver, ki se preseli, postane izpad, ki ga morate opaziti sami.

Preverite imena, nato pakete

Preverite eno notranje in eno javno ime s sistemskim resolverjem, nato ponovite operacijo, ki je spodletela. Upravitelji paketov včasih uporabljajo svoj resolver, zato lahko delujoč getent obstaja ob pokvarjeni namestitvi.

Če prepisovanje avtomatizirate, naj bo idempotentno: brez tunela obdržite obstoječo datoteko, namesto da bi zapisali prazen seznam strežnikov.

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

Delujoče notranje iskanje in delujoče javno iskanje znotraj distribucije je rezultat, ki se ga splača zabeležiti. Zelena ikona VPN na gostitelju ne dokazuje nobenega od obeh.