Miért veszíti el a WSL a munka gazdagépnevét, amikor a VPN csatlakozik?
Ugyanaz a név működik Windows alatt, és elbukik a WSL-ben, amint feláll az alagút. Ellenőrizze a platform DNS-módját és az elavult felülírásokat, mielőtt feloldót adna hozzá.
A Windows minden panasz nélkül feloldja a belső gazdagépet, és ugyanaz a név a WSL-ben abban a pillanatban elbukik, amikor feláll az alagút. A szokásos javítás az, hogy nyilvános feloldót írunk a disztribúcióba, ami helyreállítja a szokásos böngészést, és a munka gazdagépnevét feloldhatatlanná teszi. Ez egy hibát cserél egy másikra, és elrejti azt a réteget, amely valójában elromlott. Mielőtt bármelyik feloldósort hozzáadja vagy eltávolítja, derítse ki, melyik a három réteg közül bukik el.
Először zárja ki az útválasztási hibát
Ugyanazt a teljesen minősített nevet kérdezze le mindkét oldalon, ne két hasonló nevet. Egy Windows alatti siker és egy WSL alatti kudarc ugyanarra a karakterláncra két feloldási útvonal jegye, és kevés más dolog állítja elő ezt a mintát ilyen tisztán. Ha a WSL az ismert numerikus címén sem éri el a szolgáltatást, akkor útválasztási vagy szűrési probléma is van. Ebben az esetben a DNS-munka nem tárja fel, és a délután a rossz rétegre megy.
Három tünet lefedi ezeknek a legtöbb esetét, és mindegyik máshova mutat. Olvassa el a megfelelő sort, mielőtt megnyit egy konfigurációs fájlt:
| Symptom inside WSL | Likely layer | Where to look |
|---|---|---|
| Private name fails while public browsing works | Resolver path | Tunneling mode and the Windows build |
| A name that worked yesterday fails today | Stale override | Generated resolver file, immutable flag, shell profile |
| The name resolves but the service does not | Routing or filtering | The resolved address and the path to it |
A középső sort szokták félreolvasni, mert az azt elrontó változtatás hetekkel korábban történt, és akkor sikeresnek tűnt. A harmadik sort szokták félrediagnosztizálni, mert a feloldódó név annak bizonyítékaként hat, hogy a hálózat egészséges. Mindkét sor más szakaszhoz küldi Önt lentebb.
A DNS-alagutazásnak van egy verzióalsó határa
A Microsoft dokumentál egy WSL-hálózati módot, amely virtualizációs csatornán keresztül alagutazza a DNS-kéréseket a Windows feloldójához. A támogatott Windows 11 build-eken alapértelmezés szerint engedélyezett, ezért viselkedik két gép másképp ugyanazon a vállalati hálózaton. A változó a build száma, nem a vállalati szabályzat.
A WSL hálózati útmutatója írja le ezt a módot és a támogató verziókat. A funkció azért számít, mert a vállalati DNS-szabályzat általában a Windows feloldójában él, és az a disztribúció, amely örökli a Windows útvonalát, örökli vele a szabályzatot is. A nyilvános feloldót kérdező disztribúciónak nincs útvonala privát névhez, bármilyen rendes is a saját konfigurációja. Ez a mechanizmus magyarázza az egész tünetet, és magyarázza, miért bukik el a nyilvános feloldós kerülőút.
Olvassa el a build számát, mielőtt bármit szerkeszt. Egy újabb telepítésből másolt beállítás nem bizonyíték arra, hogy egy régebbi megvalósítja. Jegyezze fel a build számát a változtatás mellé, mert két gép különbsége szinte mindig verzió, és nem szabályzat.
A régi felülírások túlélik a problémát, amelyet megoldottak
A régebbi receptek kikapcsolták a generált feloldófájlokat, neves kiszolgálót kódoltak bele, vagy zárolták a fájlt megváltoztathatatlan attribútummal. Ezek a változtatások jóval azután is a helyükön maradnak, hogy eltűnt a kapcsolódási probléma, amely kiváltotta őket, és általában ők az okai annak, hogy egy újabb beállítás úgy tűnik, mintha semmit nem tenne. Túlélik a disztribúció újratelepítését is egy shell-profil formájában, amely minden bejelentkezéskor újraírja a fájlt. Az utóbbit a legnehezebb megtalálni, mert láthatatlan abból a fájlból, amelyet mindenki vizsgál.
Keressen kézzel írt feloldófájlt, rajta megváltoztathatatlan attribútumot, és egy indítószkriptet, amely újraírja. Szerkesztés előtt ellenőrizze a megváltoztathatatlan jelzőt, mert a zárolt fájlba írás olyan módon bukik el, amely engedélyproblémaként olvasható. Utána ellenőrizze a shell-profilt, mert az ottani szkript másodperceken belül visszaállítja a régi tartalmat a javítása után.
A felülírás eltávolításának következményei vannak, ezért jegyezze fel, mit távolított el és miért. Az a disztribúció, amelynek valóban statikus feloldóra van szüksége más célra, elromlik, amikor a generált fájl visszatér.
Két fájl, két különböző szerep
A két konfigurációs fájl különböző helyeken él, és különböző dolgokat vezérel, és összekeverésük a rossz rétegre alkalmazott szerkesztéseket eredményez. A Windows oldali fájl a virtuális gép tulajdonságait állítja be, míg a disztribúció oldali fájl azt állítja be, hogyan építi fel ez a disztribúció a saját feloldókonfigurációját. Egyik sem írja felül a másikat, ezért mindkettőnek egyeznie kell.
Egy olyan telepítéshez, amely támogatja a funkciót, a Windows oldali töredék rövid. Ez az egész változtatás azon az oldalon:
[wsl2]
dnsTunneling=trueEz a töredék a Windows felhasználói profilba tartozik, és a virtuális gépre vonatkozik, nem egyetlen disztribúcióra. Az alagutazás azt is megköveteli, hogy a disztribúció ne kapcsolta ki a feloldógenerálást, ezért a disztribúció oldali fájlnak békén kell hagynia ezt a viselkedést. Változtassa meg az egyiket a másik nélkül, és a mód csendesen semmit nem tesz, ami a leggyakoribb módja annak, hogy ezt a javítást hibásként jelentik. Ugyanabban a munkamenetben ellenőrizze mindkét fájlt, mert két, hetekkel eltérő időpontban végzett szerkesztés két olyan szerkesztés, amelyet senki nem tud hozzárendelni.
Indítsa újra, majd kérdezzen mindkét oldalról
Ezeket a beállításokat a környezet indításakor olvassa be a rendszer, ezért egy futó disztribúció belsejében egy új shell nem tölti be újra őket. Kapcsolja ki a környezetet a shell újraindítása helyett, és előbb mentse el a futó munkát, mert minden disztribúció leáll vele. Önmagában ez a kihagyás magyarázza a legtöbb jelentést arról, hogy egy változtatásnak nincs hatása.
Aztán tegye fel ugyanazt a kérdést mindkét oldalról. A kimenet azt is megmutatja, melyik feloldóval maradt végül a disztribúció:
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'Az első parancs lezárja a környezetet, a második megmutatja, melyik feloldót használja most a disztribúció, az utolsó kettő pedig ugyanazt a kérdést teszi fel mindkét oldalnak. A válaszokat hasonlítsa össze, ne a beállítás állapotát. Az a lekérdezés, amely egy tiszta újraindítás után is elbukik, miközben mindkét fájl helyes, a vállalati feloldószabályzatra mutat, és annak a beszélgetésnek más a tulajdonosa.