WSL2 ztratil DNS po připojení VPN? Dvě příčiny

Zastaralý soubor resolveru a konkurenční metrika trasy dávají uvnitř WSL2 stejný příznak. Zaznamenejte obě strany a pak opravte tu, která je skutečně rozbitá.

Ping na adresu uvnitř distribuce funguje, instalace balíčků a stahování přes git ne, a porucha se objevila hned po zvednutí tunelu. Přestala se překládat jen jména, což ukazuje na DNS, ne na konektivitu. Přeinstalace balíčků je tady nejoblíbenější špatný první krok. WSL2 má dva nezávislé způsoby, jak přesně tenhle příznak vyvolat, a každý chce jinou opravu.

Proč si distribuce drží vlastní resolver

Klient DNS z Windows se uvnitř distribuce nepoužívá. WSL2 si při startu vytváří vlastní soubor resolveru, který míří na stub adresu, již Windows publikuje na virtuálním přepínači pro pomocný virtuální počítač.

Toto uspořádání je při běžných síťových změnách stabilní, protože se zapisuje jednou a znovu se používá. Přestává být správné ve chvíli, kdy klient tunelu přepíše seznam adaptérů hostitele poté, co pomocný virtuální počítač už běží.

Nic uvnitř distribuce změnu nesleduje, takže soubor dál míří na adresu, která už nemusí být na cestě. Další dotaz pak čeká, vyprší nebo dostane odpověď od serveru, který o interní zóně nikdy neslyšel. Zevnitř resolver prostě přestane odpovídat a všechna jména selžou naráz.

Nejprve seberte důkazy na obou stranách

Zaznamenejte, co vidí distribuce, a pak co vidí Windows, dřív než cokoli změníte. Právě oba pohledy dohromady rozlišují režimy poruchy.

Uvnitř distribuce vypište soubor resolveru, směrovací tabulku a jeden interní a jeden veřejný dotaz:

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

Ve Windows vypište servery DNS po adaptérech a tabulku IPv4 s metrikami. Klient VPN obvykle nainstaluje trasu pro podsíť WSL2 a její metrika rozhoduje, zda tento provoz odejde tunelem, nebo zůstane lokálně.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

Metrika trasy, nebo zastaralý soubor

První porucha je zastaralý soubor. Resolver byl zapsán pro stav adaptéru při startu a tunel ten stav změnil. Jeho stub adresa už může být nedostupná, nebo může ukazovat na server, který o interní zóně nic neví.

Druhá je problém směrování. Když VPN přidá trasu pokrývající podsíť WSL2 s metrikou nižší než trasa odkazu hostitele, pakety adresované pomocnému virtuálnímu počítači vstoupí do tunelu. Pak vyprší každá služba WSL2, ne jen DNS.

Rozlišovací test stojí jeden řádek. Pokud číselná adresa, třeba veřejný resolver, na ping stále odpovídá, zatímco jména selhávají, cesta je v pořádku a problém je v DNS. To je případ, kdy je změna resolveru oprávněná, a případ, kdy oprávněná není, se tím také vyjasní. Pokud selže i číselný test, pomocný virtuální počítač ztratil trasu a žádný soubor resolveru to nespraví.

Pro případ směrování zrušte automatickou metriku na adaptéru tunelu a dejte mu číslo nad trasou odkazu WSL2:

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

Vypnutí je důležité. Změna metriky nepřepíše běžící pomocný virtuální počítač, takže distribuci je nutné před zviditelněním změny znovu sestavit.

Převezměte soubor, vědomě

Pokud je směrování správné a selhávají jen interní jména, na vině je resolver a generátor můžete zastavit. To je vědomá změna s náklady na údržbu, ne obezlička k ledabylému použití.

Uvnitř distribuce vytvořte /etc/wsl.conf se síťovou sekcí, která vypne generování, a pak soubor resolveru napište sami, firemní server první a veřejnou zálohu druhou:

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

Na pořadí záleží. Veřejný resolver interní jméno nezodpoví a záloha existuje jen pro internetové dotazy. Jakmile je soubor váš, nic ho znovu nevygeneruje, takže firemní resolver, který se přestěhuje, se stane výpadkem, kterého si musíte všimnout sami.

Zkontrolujte jména, pak balíčky

Ověřte jedno interní a jedno veřejné jméno systémovým resolverem a pak zopakujte operaci, která selhala. Správci balíčků někdy používají vlastní resolver, proto může funkční getent existovat vedle rozbité instalace.

Pokud přepis automatizujete, udělejte ho idempotentní: bez tunelu ponechte soubor, který už existuje, místo zápisu prázdného seznamu serverů.

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

Funkční interní dotaz a funkční veřejný dotaz zevnitř distribuce je výsledek, který stojí za záznam. Zelená ikona VPN na hostiteli nedokazuje ani jedno.

Související články