resolv.conf ve WSL 2: DNS padne, když se připojí VPN

Prohlížení uvnitř distribuce funguje a první interní jméno hostitele selže ve chvíli, kdy se zvedne tunel. Reflex je přidat veřejný resolver, což obnoví internet a učiní firemní jméno nedostupným na zbytek dne. Ve WSL 2 je /etc/resolv.conf generovaný výstup, ne konfigurace, a právě tento mechanismus stojí za pochopení. Oprava není lepší resolver, ale vlastnictví souboru.

Soubor se generuje, nekonfiguruje

WSL 2 zapisuje soubor při startu z adaptérů Windows, které v tu chvíli vidí, a nahoře vytiskne komentář, který to říká. Když potom klient VPN přidá nebo přepíše adaptér, distribuce nemusí nic znovu vygenerovat a soubor dál popisuje síť, která už neexistuje.

Druhý režim selhání je tišší: WSL může kopírovat servery jen z některých adaptérů. Pokud má fyzický adaptér už resolver IPv6, servery IPv4, které dodává adaptér VPN, mohou být vyhozeny místo přidání, a soubor vypadá úplně, zatímco vynechává právě ten, který odpovídá na interní jména.

Porovnejte pohled z Windows s pohledem z Linuxu

Přečtěte obě strany před úpravou. Uvnitř distribuce se podívejte, co soubor obsahuje a zda je to běžný soubor nebo odkaz. Ve Windows vypište resolver pro každý adaptér, včetně toho, který vytvořila VPN:

ls -l /etc/resolv.conf
cat /etc/resolv.conf

Get-DnsClientServerAddress -AddressFamily IPv4
Get-NetAdapter | Where-Object Status -eq 'Up'

Když adaptér VPN ukazuje firemní servery a Linux něco jiného, rozpor je v generování, ne v dosažitelnosti. Porovnejte seznam adaptérů i adresy, protože chybějící adaptér vysvětluje chybějící server. Toto rozlišení rozhoduje, zda opravujete WSL, nebo firewall, a obojí nemá nic společného.

Vypněte generování a napište vlastní soubor

Jedno dokumentované nastavení brání WSL přepisovat soubor a nachází se v /etc/wsl.conf. Přidejte do toho souboru síťovou sekci:

[network]
generateResolvConf = false

Potom ukončete distribuci z Windows pomocí wsl --shutdown a znovu ji spusťte. Pokud je cesta symbolický odkaz a ne běžný soubor, odkaz před zápisem vlastního obsahu odstraňte, protože zápis přes odkaz může při příštím startu znovu vytvořit generovaný cíl. Od té chvíle je soubor váš a nic ho nepřepisuje.

nameserver 172.28.4.10
nameserver 172.28.4.11
search site.corp.example
options timeout:1 attempts:2 rotate

Bez vyhledávací domény se nekvalifikované jméno hostitele doplní veřejným kořenem a vrátí se jako žádná taková doména. timeout brání mrtvému prvnímu serveru zablokovat každé hledání, attempts omezuje, kolik pokusů hledání spotřebuje, a rotate rozprostírá opakování místo vždy začínat shora. Kompromis je, že soubor už nenásleduje VPN, jejíž adresa resolveru se mezi relacemi mění.

Vyřešte resolver, který se posouvá, a pak ověřte

Někteří klienti vydávají resolver specifický pro relaci, takže statický soubor se při dalším připojení rozbije. Dva postupy jsou obhajitelné. Zapisujte soubor z malého skriptu, kdykoli se adresa změní, nebo ponechte generování zapnuté a ujistěte se, že adaptér, ze kterého WSL kopíruje, nese firemní server. Druhý nepotřebuje háček a selhává, kdykoli generování adaptér VPN přeskočí; oba stále vyžadují nejprve vyřešit konflikt s IPv6.

Windows uplatňuje i vlastní zásady jmen, například seznam pro hledání přípon nebo zásadu překladu pro konkrétní domény, a kopírování adres adaptérů tato pravidla nereprodukuje. Pokud se jméno přeloží ve Windows a ne v distribuci se stejným serverem, porovnejte zpracování přípon, než obviníte tunel.

Testujte jménem, ne paketem: getent hosts sensor-access0.corp.example prochází zásobníkem resolveru, zatímco ping může uspět proti uložené nebo doslovné adrese. Potom to zopakujte po odpojení a opětovném připojení, protože nastavení, které funguje jednou a při obnovení se regeneruje, nebylo nikdy opraveno. Uložte předchozí obsah a poznamenejte, která komponenta cestu na tom stroji vlastní, aby příští změna začala s důkazy.