WSL2 humbi DNS pas lidhjes së VPN? Dy shkaqe

Ping sipas adresës funksionon brenda distribucionit, instalimet e paketave dhe shkarkimet git nuk funksionojnë, dhe dështimi u shfaq menjëherë pasi tuneli u ngrit. Vetëm emrat ndaluan së zgjidhuri, gjë që tregon DNS dhe jo lidhshmëri. Riinstalimi i paketave është hapi i parë i gabuar më popullor këtu. WSL2 ka dy mënyra të pavarura për të prodhuar pikërisht atë simptom, dhe ato kërkojnë riparime të ndryshme.

Pse distribucioni mban resolverin e vet

Klienti DNS i Windows nuk përdoret brenda distribucionit. WSL2 ndërton skedarin e vet të resolverit në nisje, duke treguar një adresë stub që Windows publikon në ndërprerësin virtual për makinën virtuale ndihmëse.

Ky rregullim është i qëndrueshëm gjatë ndryshimeve të zakonshme të rrjetit sepse shkruhet një herë dhe ripërdoret. Rregullimi nuk është më i saktë kur një klient tuneli rishkruan listën e përshtatësve të hostit pasi makina virtuale ndihmëse ka nisur tashmë.

Asgjë brenda distribucionit nuk e ndjek ndryshimin, kështu që skedari vazhdon të tregojë një adresë që mund të mos jetë më në rrugë. Kërkimi tjetër pastaj pret, skadon ose merr përgjigje nga një server që nuk ka dëgjuar kurrë për zonën e brendshme. Nga brenda, resolveri thjesht ndalon së përgjigjuri, dhe të gjithë emrat dështojnë njëherësh.

Së pari mblidhni prova në të dyja palët

Regjistroni çfarë sheh distribucioni, pastaj çfarë sheh Windows, përpara se të ndryshoni cilindo. Janë të dyja pamjet bashkë ato që i dallojnë mënyrat e dështimit.

Brenda distribucionit, shtypni skedarin e resolverit, tabelën e rrugëzimit dhe një kërkim të brendshëm e një publik:

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

Në Windows, listoni serverët DNS për çdo përshtatës dhe tabelën IPv4 me metrika. Një klient VPN zakonisht instalon një rrugë për nënrrjetin WSL2, dhe metrika e saj vendos nëse ai trafik del përmes tunelit ose mbetet lokal.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

Metrikë rruge apo skedar i vjetruar

Dështimi i parë është skedari i vjetruar. Resolveri ishte shkruar për gjendjen e përshtatësit në nisje, dhe tuneli e ndryshoi atë gjendje. Adresa e tij stub tani mund të jetë e paarritshme, ose mund të emërojë një server që nuk di asgjë për zonën e brendshme.

I dyti është një problem rrugëzimi. Kur VPN shton një rrugë që mbulon nënrrjetin WSL2 me një metrikë më të ulët se rruga e lidhjes së hostit, paketat e adresuara makinës virtuale ndihmëse hyjnë në tunel. Atëherë skadon çdo shërbim i WSL2, jo vetëm DNS.

Testi dallues kushton një rresht. Nëse një adresë numerike si një resolver publik ende përgjigjet ndaj ping ndërsa emrat dështojnë, rruga është e paprekur dhe problemi është DNS. Ky është rasti kur një ndryshim resolver justifikohet, dhe rasti kur nuk justifikohet bëhet gjithashtu i qartë. Nëse edhe testi numerik dështon, makina virtuale ndihmëse ka humbur rrugën e saj dhe asnjë skedar resolver nuk do ta rregullojë atë.

Për rastin e rrugëzimit, hiqni metrikën automatike nga përshtatësi i tunelit dhe jepini një numër mbi rrugën e lidhjes WSL2:

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

Fikja ka rëndësi. Ndryshimi i metrikës nuk e rishkruan makinën virtuale ndihmëse që punon, prandaj distribucioni duhet të rindërtohet përpara se ndryshimi të jetë i dukshëm.

Merrni skedarin, me qëllim

Nëse rrugëzimi është i saktë dhe dështojnë vetëm emrat e brendshëm, resolveri është fajtori dhe mund të ndaloni gjeneratorin. Ky është një ndryshim i qëllimshëm me kosto mirëmbajtjeje, jo një zgjidhje e përkohshme për t’u aplikuar pa kujdes.

Krijoni /etc/wsl.conf brenda distribucionit me seksionin e rrjetit që çaktivizon gjenerimin, pastaj shkruani vetë skedarin e resolverit, serveri korporativ i pari dhe një publik rezervë i dyti:

[network]
generateResolvConf = false

search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

Rendi ka rëndësi. Një resolver publik nuk mund t’i përgjigjet një emri të brendshëm, dhe rezerva ekziston vetëm për kërkime interneti. Pasi skedari është i juaji, asgjë nuk e rigjeneron, kështu që një resolver korporativ që zhvendoset bëhet një ndërprerje që ju duhet ta vini re vetë.

Kontrolloni emrat, pastaj paketat

Verifikoni një emër të brendshëm dhe një publik me resolverin e sistemit, pastaj përsëritni veprimin që dështoi. Menaxherët e paketave ndonjëherë përdorin resolverin e tyre, prandaj një getent që punon mund të bashkëjetojë me një instalim të prishur.

Nëse e automatizoni rishkrimin, bëjeni idempotent: pa tunel, mbani skedarin që ekziston tashmë në vend që të shkruani një listë bosh serverësh.

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

Një kërkim i brendshëm që punon dhe një kërkim publik që punon, nga brenda distribucionit, është rezultati që ia vlen të regjistrohet. Një ikonë e gjelbër VPN në host nuk dëshmon asnjërën prej tyre.