WSL2 kaotas DNS-i pärast VPN-i ühendamist? Kaks põhjust

Aegunud resolver-fail ja konkureeriv marsruudimeetrika tekitavad WSL2 sees sama sümptomi. Salvestage mõlemad pooled ja parandage siis see, mis on tegelikult katki.

Ping aadressi järgi töötab distributsiooni sees, paketi paigaldused ja git-tõmbed mitte, ja rike ilmnes kohe pärast tunnelile tõusmist. Ainult nimede lahendamine lakkas, mis viitab DNS-ile, mitte ühenduvusele. Pakettide uuesti paigaldamine on siin kõige populaarsem vale esimene samm. WSL2-l on kaks sõltumatut viisi täpselt selle sümptomi tekitamiseks ja need nõuavad erinevat parandust.

Miks distributsioon hoiab oma resolverit

Windowsi DNS-klienti ei kasutata distributsiooni sees. WSL2 koostab käivitamisel oma resolver-faili, mis osutab stub-aadressile, mille Windows avaldab abivirtuaalmasina virtuaallülitis.

See korraldus on tavaliste võrgu muudatuste korral stabiilne, sest see kirjutatakse üks kord ja seda kasutatakse uuesti. Korraldus lakkab olemast õige, kui tunneliklient kirjutab hosti adapteriloendi uuesti pärast seda, kui abivirtuaalmasin on juba käivitunud.

Miski distributsiooni sees ei jälgi seda muudatust, nii et fail osutab endiselt aadressile, mis ei pruugi enam teel olla. Järgmine otsing siis ootab, aegub või saab vastuse serverilt, mis pole kunagi sisemisest tsoonist kuulnud. Seestpoolt lakkab resolver lihtsalt vastamast ja kõik nimed ebaõnnestuvad korraga.

Koguge esmalt tõendid mõlemalt poolt

Kirjutage üles, mida näeb distributsioon, ja siis, mida näeb Windows, enne kui kumbagi muudate. Just kaks vaadet koos eristavad rikkerežiime.

Distributsiooni sees printige resolver-fail, marsruutimistabel ja üks sisemine ja üks avalik otsing:

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

Windowsis loetlege DNS-serverid adapteri kaupa ja IPv4-tabel mõõdikutega. VPN-klient paigaldab tavaliselt marsruudi WSL2 alavõrgu jaoks ja selle mõõdik otsustab, kas see liiklus lahkub tunnelist või jääb kohalikuks.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

Marsruudimeetrika või aegunud fail

Esimene rike on aegunud fail. Resolver kirjutati käivitamisaegse adapteriseisundi jaoks ja tunnel muutis seda seisundit. Selle stub-aadress võib nüüd olla kättesaamatu või nimetada serverit, mis ei tea sisemisest tsoonist midagi.

Teine on marsruutimisprobleem. Kui VPN lisab marsruudi, mis katab WSL2 alavõrgu, mõõdikuga, mis on madalam kui hosti lingi marsruut, satuvad abivirtuaalmasinale adresseeritud paketid tunnelisse. Siis aegub iga WSL2 teenus, mitte ainult DNS.

Eristav test maksab ühe rea. Kui numbriline aadress, näiteks avalik resolver, vastab endiselt pingile, samal ajal kui nimed ebaõnnestuvad, on tee terve ja probleem on DNS-is. See on juhtum, kus resolveri muutmine on põhjendatud, ja juhtum, kus see pole, muutub samuti ilms eks. Kui ka numbriline test ebaõnnestub, on abivirtuaalmasin kaotanud oma marsruudi ja ükski resolver-fail ei paranda seda.

Marsruutimise juhtumi jaoks eemaldage tunneladapterilt automaatne mõõdik ja andke sellele number üle WSL2 lingi marsruudi:

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

Sulgemine loeb. Mõõdiku muutmine ei kirjuta jooksvat abivirtuaalmasinat uuesti, seega tuleb distributsioon enne muudatuse nähtavaks saamist uuesti üles ehitada.

Võtke fail üle, teadlikult

Kui marsruutimine on õige ja ebaõnnestuvad ainult sisemised nimed, on süüdi resolver ja võite generaatori peatada. See on teadlik muudatus hoolduskuluga, mitte ajutine lahendus, mida muretult rakendada.

Looge distributsiooni sees /etc/wsl.conf võrgujaotisega, mis keelab genereerimise, ja seejärel kirjutage resolver-fail ise, kõigepealt ettevõtte server ja teiseks avalik varuvariant:

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

Järjekord loeb. Avalik resolver ei saa sisemisele nimele vastata ja varuvariant on ainult internetiotsingute jaoks. Kui fail on teie oma, ei genereeri seda miski uuesti, nii et ümber koliv ettevõtte resolver muutub katkestuseks, mida peate ise märkama.

Kontrollige nimesid, seejärel pakette

Kontrollige süsteemi resolveriga üht sisemist ja üht avalikku nime, seejärel korrake toimingut, mis ebaõnnestus. Paketihaldurid kasutavad mõnikord oma resolverit, seepärast võib töötav getent eksisteerida katkise paigalduse kõrval.

Kui automatiseerite ümberkirjutamist, tehke see idempotentseks: kui tunnelit pole, jätke olemasolev fail alles, selle asemel et kirjutada tühi serverinimekiri.

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

Distributsiooni seest toimiv sisemine otsing ja toimiv avalik otsing on tulemus, mida tasub kirja panna. Roheline VPN-i ikoon hostil ei tõenda kumbagi.

Seotud artiklid