Zašto WSL izgubi naziv radnog hosta kada se VPN poveže?

Windows razrješava interni host bez ikakve žalbe, a isti naziv ne uspijeva unutar WSL-a u trenutku kada se tunel podigne. Uobičajeni popravak je upisati javni resolver u distribuciju, što vraća normalno pregledanje i čini naziv radnog hosta nerazrješivim. Time se jedna greška zamjenjuje drugom i skriva se sloj koji se stvarno pokvario. Prije dodavanja ili uklanjanja bilo kojeg retka resolvera, utvrdite koji od tri sloja ne uspijeva.

Najprije isključite grešku usmjeravanja

Upitajte isto potpuno kvalificirano ime na obje strane, a ne dva imena koja izgledaju slično. Uspjeh u Windowsu i neuspjeh u WSL-u za isti niz potpis je dva različita puta razrješavanja i malo što drugo daje taj uzorak tako čisto. Ako WSL ne može dosegnuti ni uslugu na njezinoj poznatoj numeričkoj adresi, prisutan je i problem usmjeravanja ili filtriranja. U tom slučaju rad na DNS-u to neće otkriti i poslijepodne odlazi na pogrešan sloj.

Tri simptoma pokrivaju većinu takvih slučajeva i svaki upućuje na drugo mjesto. Pročitajte red koji odgovara prije nego otvorite konfiguracijsku datoteku:

Srednji red ljudi najčešće pogrešno čitaju, jer je promjena koja ga je pokvarila napravljena sedmicama ranije i tada je izgledala uspješno. Treći red ljudi pogrešno dijagnosticiraju, jer ime koje se razrješava djeluje kao dokaz da je mreža zdrava. Oba reda vode vas u različit odjeljak ispod.

DNS tuneliranje ima donju granicu verzije

Microsoft dokumentira WSL mrežni režim koji tunelira DNS zahtjeve do Windows resolvera preko kanala za virtualizaciju. Na podržanim verzijama sustava Windows 11 uključen je prema zadanim postavkama i zato se dva računala na istoj korporativnoj mreži ponašaju različito. Varijabla je broj verzije, a ne korporativna politika.

WSL vodič za umrežavanje opisuje taj režim i verzije koje ga podržavaju. Značajka je važna jer korporativna DNS politika obično živi u Windows resolveru, a distribucija koja naslijedi Windows put naslijedi i politiku. Distribucija koja pita javni resolver nema put do privatnog imena, koliko god uredna izgledala njezina vlastita konfiguracija. Taj mehanizam objašnjava cijeli simptom i objašnjava zašto zaobilazno rješenje s javnim resolverom ne uspijeva.

Pročitajte broj verzije prije nego bilo što uredite. Postavka kopirana s novije instalacije nije dokaz da je starija provodi. Zabilježite broj verzije uz promjenu, jer je razlika između dva računala gotovo uvijek verzija, a ne politika.

Stara preklapanja nadžive problem koji su riješila

Stariji recepti isključivali su generirane resolver datoteke, tvrdo zadavali poslužitelj imena ili zaključavali datoteku atributom nepromjenjivosti. Te promjene ostaju na mjestu dugo nakon što problem s povezivanjem koji ih je potaknuo nestane i obično su razlog zašto se čini da novija postavka ne radi ništa. One također preživljavaju ponovnu instalaciju distribucije u obliku shell profila koji prepisuje datoteku pri svakoj prijavi. Posljednje je najteže pronaći, jer je nevidljivo iz datoteke koju svi pregledaju.

Potražite rukom pisanu resolver datoteku, atribut nepromjenjivosti na njoj i početnu skriptu koja je prepisuje. Provjerite zastavicu nepromjenjivosti prije uređivanja, jer pisanje u zaključanu datoteku ne uspijeva na način koji se čita kao problem s dopuštenjima. Zatim provjerite shell profil, jer skripta ondje vraća stari sadržaj u roku od nekoliko sekundi nakon vašeg popravka.

Uklanjanje preklapanja ima posljedice, pa zabilježite što ste uklonili i zašto. Distribucija kojoj statični resolver doista treba za drugu svrhu pokvarit će se kada se generirana datoteka vrati.

Dvije datoteke, dvije različite uloge

Dvije konfiguracijske datoteke žive na različitim mjestima i kontroliraju različite stvari, a njihovo miješanje dovodi do izmjena primijenjenih na pogrešan sloj. Datoteka na Windows strani postavlja svojstva virtualnog računala, dok datoteka na strani distribucije postavlja kako ta distribucija gradi vlastitu konfiguraciju resolvera. Nijedna ne preklapa drugu, zato se obje moraju slagati.

Za instalaciju koja podržava tu značajku, fragment na Windows strani je kratak. To je cijela promjena na toj strani:

[wsl2]
dnsTunneling=true

Taj fragment pripada korisničkom profilu sustava Windows i primjenjuje se na virtualno računalo, a ne na pojedinu distribuciju. Tuneliranje također zahtijeva da distribucija nije isključila generiranje resolvera, pa datoteka na strani distribucije mora pustiti to ponašanje na miru. Promijenite jedno bez drugoga i režim tiho ne radi ništa, što je najčešći način na koji se ovaj popravak prijavljuje kao pokvaren. Provjerite obje datoteke u istoj sesiji, jer dvije izmjene napravljene sedmicama jedna od druge dvije su izmjene koje nitko ne može pripisati.

Ponovno pokrenite, pa upitajte s obje strane

Te se postavke čitaju pri pokretanju okruženja, pa novi shell unutar pokrenute distribucije neće ih ponovno učitati. Isključite okruženje umjesto da ponovno pokrenete shell i najprije spremite rad koji je u tijeku, jer svaka distribucija staje s njim. Samo taj propust objašnjava većinu prijava da promjena nema učinka.

Zatim postavite isto pitanje s obje strane. Izlaz također pokazuje s kojim je resolverom distribucija stvarno završila:

wsl.exe --shutdown
wsl.exe -e sh -c 'cat /etc/resolv.conf'
wsl.exe -e sh -c 'getent hosts files.corp.example'
wsl.exe -e powershell -Command 'Resolve-DnsName files.corp.example'

Prva naredba završava okruženje, druga pokazuje koji resolver distribucija sada koristi, a posljednje dvije postavljaju isto pitanje svakoj strani. Usporedite odgovore, a ne stanje postavke. Upit koji i dalje ne uspijeva nakon čistog ponovnog pokretanja s obje ispravne datoteke upućuje na korporativnu politiku resolvera i taj razgovor ima drugog vlasnika.