Proč WSL ztratí název pracovního hostitele, když se připojí VPN?

Windows přeloží interního hostitele bez jakékoli stížnosti a stejný název uvnitř WSL selže v okamžiku, kdy se tunel zvedne. Obvyklá oprava spočívá v zapsání veřejného resolveru do distribuce, což obnoví běžné prohlížení a udělá název pracovního hostitele nepřeložitelným. Tím se jedna porucha vymění za druhou a skryje se vrstva, která se skutečně rozbila. Než přidáte nebo odeberete jakýkoli řádek resolveru, zjistěte, která ze tří vrstev selhává.

Nejprve vylučte poruchu směrování

Dotazujte se na stejný plně kvalifikovaný název na obou stranách, ne na dva názvy, které vypadají podobně. Úspěch ve Windows a selhání ve WSL pro stejný řetězec je podpis dvou cest překladu a máloco jiného vytváří tento vzorec tak čistě. Pokud se WSL nedostane ani na službu na její známé číselné adrese, je přítomen i problém směrování nebo filtrování. V takovém případě to práce na DNS neodhalí a odpoledne jde na špatnou vrstvu.

Tři příznaky pokrývají většinu těchto případů a každý ukazuje jinam. Přečtěte si odpovídající řádek, než otevřete konfigurační soubor:

Prostřední řádek lidé čtou špatně, protože změna, která ho rozbila, byla provedena před týdny a tehdy vypadala úspěšně. Třetí řádek lidé špatně diagnostikují, protože název, který se přeloží, působí jako důkaz, že je síť zdravá. Oba řádky vás posílají do jiné části níže.

Tunelování DNS má spodní hranici verze

Microsoft dokumentuje síťový režim WSL, který tuneluje požadavky DNS do resolveru Windows přes kanál virtualizace. Na podporovaných sestaveních Windows 11 je ve výchozím nastavení zapnutý, a proto se dva počítače ve stejné podnikové síti chovají odlišně. Proměnnou je číslo sestavení, ne podniková politika.

Průvodce sítěmi WSL popisuje tento režim a verze, které jej podporují. Funkce je důležitá, protože podniková politika DNS obvykle žije v resolveru Windows, a distribuce, která zdědí cestu Windows, zdědí i politiku. Distribuce dotazující se veřejného resolveru nemá cestu k soukromému názvu, ať už její vlastní konfigurace vypadá sebeúhledněji. Tento mechanismus vysvětluje celý příznak a vysvětluje, proč obchvat s veřejným resolverem selhává.

Přečtěte si číslo sestavení, než cokoli upravíte. Nastavení zkopírované z novější instalace není důkazem, že ho starší implementuje. Zapište číslo sestavení vedle změny, protože rozdíl mezi dvěma počítači je téměř vždy verze, nikoli politika.

Stará přepsání přežijí problém, který vyřešila

Starší postupy vypínaly generované soubory resolveru, natvrdo nastavovaly server názvů nebo soubor zamkly atributem neměnnosti. Tyto změny zůstávají na místě dlouho poté, co problém s připojením, který je vyvolal, zmizel, a obvykle jsou důvodem, proč se zdá, že novější nastavení nic nedělá. Přežijí také přeinstalaci distribuce v podobě profilu shellu, který soubor přepisuje při každém přihlášení. Poslední z nich se hledá nejhůř, protože je neviditelný ze souboru, který všichni kontrolují.

Hledejte ručně psaný soubor resolveru, atribut neměnnosti na něm a spouštěcí skript, který jej přepisuje. Před úpravou zkontrolujte příznak neměnnosti, protože zápis do zamčeného souboru selže způsobem, který se čte jako problém s oprávněním. Poté zkontrolujte profil shellu, protože skript tam obnoví starý obsah během několika sekund po vaší opravě.

Odebrání přepsání má důsledky, tak si zapište, co jste odebrali a proč. Distribuce, která statický resolver skutečně potřebuje pro jiný účel, se rozbije, až se generovaný soubor vrátí.

Dva soubory, dvě různé role

Oba konfigurační soubory žijí na různých místech a řídí různé věci, a jejich záměna vede k úpravám aplikovaným na špatnou vrstvu. Soubor na straně Windows nastavuje vlastnosti virtuálního počítače, zatímco soubor na straně distribuce nastavuje, jak tato distribuce sestavuje vlastní konfiguraci resolveru. Ani jeden nepřepisuje druhý, a proto se oba musí shodovat.

Pro instalaci, která tuto funkci podporuje, je fragment na straně Windows krátký. To je celá změna na této straně:

[wsl2]
dnsTunneling=true

Tento fragment patří do uživatelského profilu Windows a platí pro virtuální počítač, nikoli pro jednu distribuci. Tunelování také vyžaduje, aby distribuce nevypnula generování resolveru, takže soubor na straně distribuce musí toto chování nechat na pokoji. Změňte jedno bez druhého a režim tiše nic nedělá, což je nejčastější způsob, jak se tato oprava hlásí jako rozbitá. Zkontrolujte oba soubory v téže relaci, protože dvě úpravy provedené týdny od sebe jsou dvě úpravy, které nikdo nemůže připsat.

Restartujte a potom se dotazujte z obou stran

Tato nastavení se čtou při spuštění prostředí, takže nový shell uvnitř běžící distribuce je znovu nenačte. Prostředí vypněte, místo abyste restartovali shell, a nejprve uložte běžící práci, protože každá distribuce se s ním zastaví. Jen toto opomenutí vysvětluje většinu hlášení o změně bez účinku.

Potom položte stejnou otázku z obou stran. Výstup také ukazuje, se kterým resolverem distribuce skutečně skonč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'

První příkaz ukončí prostředí, druhý ukazuje, který resolver distribuce nyní používá, a poslední dva kladou stejnou otázku každé straně. Porovnávejte odpovědi, ne stav nastavení. Dotaz, který po čistém restartu při správných obou souborech stále selhává, ukazuje na podnikovou politiku resolveru a ten rozhovor má jiného vlastníka.