WSL2 prarado DNS po VPN prisijungimo? Dvi priežastys

Pasenęs resolver failas ir konkuruojanti maršruto metrika sukelia tą patį simptomą WSL2 viduje. Užfiksuokite abi puses, tada sutaisykite tą, kuri tikrai sugedusi.

Ping pagal adresą veikia distribucijos viduje, paketų diegimas ir git parsisiuntimai ne, o gedimas pasirodė iškart po tunelio pakilimo. Tik vardai nustojo sprendžiami, o tai rodo DNS, o ne ryšį. Paketų perdiegimas čia yra populiariausias neteisingas pirmas žingsnis. WSL2 turi du nepriklausomus būdus sukelti būtent šį simptomą, ir jiems reikia skirtingo remonto.

Kodėl distribucija laiko savo resolver

Windows DNS klientas nenaudojamas distribucijos viduje. WSL2 paleidimo metu sukuria savo resolver failą, nukreiptą į stub adresą, kurį Windows paskelbia virtualiame komutatoriuje pagalbiniam virtualiam kompiuteriui.

Ši tvarka stabili įprastų tinklo pakeitimų metu, nes ji rašoma vieną kartą ir naudojama pakartotinai. Tvarka nustoja būti teisinga, kai tunelio klientas perrašo pagrindinio kompiuterio adapterių sąrašą po to, kai pagalbinis virtualus kompiuteris jau paleistas.

Niekas distribucijos viduje nestebi pakeitimo, todėl failas toliau rodo į adresą, kurio gali nebelikti kelyje. Kitas ieškojimas tada laukia, baigiasi laikas arba gaunamas atsakymas iš serverio, kuris niekada negirdėjo apie vidinę zoną. Iš vidaus resolver tiesiog nustoja atsakinėti, ir visi vardai nepavyksta vienu metu.

Pirmiausia surinkite įrodymus iš abiejų pusių

Užfiksuokite, ką mato distribucija, o paskui ką mato Windows, prieš ką nors keisdami. Būtent abu vaizdai kartu išskiria gedimo režimus.

Distribucijos viduje atspausdinkite resolver failą, maršrutų lentelę ir vieną vidinį bei vieną viešą ieškojimą:

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

Windows sistemoje išvardykite DNS serverius pagal adapterį ir IPv4 lentelę su metrikomis. VPN klientas paprastai įdiegia maršrutą WSL2 potinkliui, o jo metrika nusprendžia, ar šis srautas išeis per tunelį, ar liks vietinis.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

Maršruto metrika ar pasenęs failas

Pirmas gedimas yra pasenęs failas. Resolver buvo parašytas paleidimo metu adapterio būsenai, o tunelis tą būseną pakeitė. Jo stub adresas dabar gali būti nepasiekiamas arba nurodyti serverį, kuris nieko nežino apie vidinę zoną.

Antrasis yra maršrutizavimo problema. Kai VPN prideda maršrutą, apimantį WSL2 potinklį, su metrika mažesne už pagrindinio kompiuterio nuorodos maršrutą, paketai, adresuoti pagalbiniam virtualiam kompiuteriui, patenka į tunelį. Tada baigiasi kiekvienos WSL2 paslaugos laikas, ne tik DNS.

Atskyrimo testas kainuoja vieną eilutę. Jei skaitmeninis adresas, pavyzdžiui, viešas resolver, vis dar atsako į ping, kol vardai nepavyksta, kelias yra sveikas ir problema yra DNS. Tai atvejis, kai resolver keitimas yra pateisinamas, o atvejis, kai ne, taip pat paaiškėja. Jei skaitmeninis testas irgi nepavyksta, pagalbinis virtualus kompiuteris prarado savo maršrutą ir joks resolver failas to nesutaisys.

Maršrutizavimo atveju pašalinkite automatinę metriką nuo tunelio adapterio ir duokite jam skaičių virš WSL2 nuorodos maršruto:

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

Išjungimas svarbus. Metrikos keitimas neperrašo veikiančio pagalbinio virtualaus kompiuterio, todėl distribuciją reikia perstatyti, kad pakeitimas taptų matomas.

Paimkite failą, sąmoningai

Jei maršrutizavimas teisingas ir nepavyksta tik vidiniai vardai, kaltas resolver, ir galite sustabdyti generatorių. Tai sąmoningas pakeitimas su priežiūros sąnaudomis, o ne aplinkinis sprendimas, taikomas lengvabūdiškai.

Distribucijos viduje sukurkite /etc/wsl.conf su tinklo sekcija, kuri išjungia generavimą, tada patys parašykite resolver failą, pirmiausia įmonės serveris, paskui viešas atsarginis:

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

Tvarka svarbi. Viešas resolver negali atsakyti į vidinį vardą, o atsarginis egzistuoja tik interneto ieškojimams. Kai failas yra jūsų, niekas jo nepergeneruoja, todėl persikeliantis įmonės resolver tampa sutrikimu, kurį turite pastebėti patys.

Patikrinkite vardus, paskui paketus

Patikrinkite vieną vidinį ir vieną viešą vardą sistemos resolveriu, tada pakartokite nepavykusią operaciją. Paketų tvarkyklės kartais naudoja savo resolverį, todėl veikiantis getent gali egzistuoti šalia sugadintos diegimo.

Jei automatizuojate perrašymą, padarykite jį idempotentišką: be tunelio palikite jau esantį failą, o ne rašykite tuščią serverių sąrašą.

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

Dirbantis vidinis ieškojimas ir dirbantis viešas ieškojimas, iš distribucijos vidaus, yra rezultatas, kurį verta užfiksuoti. Žalia VPN piktograma pagrindiniame kompiuteryje neįrodo nė vieno.

Susiję straipsniai