WSL2 nedědí firemní VPN, a právě v tom je chyba

Interní wiki se v Edge načte, ale git clone uvnitř distribuce vyprší. Toto jediné pozorování se obvykle čte jako «VPN blokuje WSL2» a následující hodina padne na úpravu /etc/resolv.conf. Užitečnější čtení je, že WSL2 nikdy neměl síťovou cestu hostitele: běží v pomocném VM s vlastním adaptérem, vlastními trasami a souborem resolveru, který pro něj Windows generuje. Všechno další závisí na tom, které z těch tří vám skutečně chybí.

VM má vlastní stack, metriky i resolver

Ve výchozím režimu NAT stojí distribuce za virtuálním přepínačem a na internet se dostane přes hostitele, ale adaptéry hostitele nevidí. ip addr ukazuje jedno rozhraní s privátní adresou, ip route ukazuje výchozí trasu tímto přepínačem a /etc/resolv.conf je generovaný soubor ukazující na stub resolver, který Windows vybral. Nic z toho se nemění tím, že se na straně Windows spustil klient VPN.

Proto «prohlížeč funguje» dokazuje tak málo. Prohlížeč používá stack hostitele, tunel a resolver politiku hostitele. Vaše shell používá jiný stack, který náhodou sdílí fyzickou síťovou kartu. Ve šťastném případě se shodují a rozejdou se přesně tehdy, když VPN nainstaluje filtr, přepíše seznam DNS nebo přidá trasu pro podsíť virtuálního přepínače.

Dva testy rozhodnou, ve kterém světě jste, a musí se spustit uvnitř distribuce:

getent hosts example.com
curl -sS -m 8 -o /dev/null -w "%{http_code}\n" 1.1.1.1
ip route
cat /etc/resolv.conf

Když jména selhávají, ale doslovná adresa odpovídá, je to problém resolveru. Když jména i adresy selhávají společně, je to problém cesty a žádné úpravy resolveru se ho nedotknou. Následují důkazy ze strany Windows: Get-NetAdapter | Get-DnsClientServerAddress a route print -4 ukážou, zda tunel zabral podsíť, ve které žije váš VM.

Mýtus první: firemní DNS servery to spraví

Úprava souboru resolveru je klasická rada a je správná asi v polovině případů. Když je správná, je správná z konkrétního důvodu: generovaný soubor ukazuje na resolver, který zná jen veřejná jména, takže dotaz na intranet.example.internal se vrátí jako neexistující, i když je cesta v pořádku.

Připnout servery VPN znamená zastavit Windows v regeneraci souboru, protože každý ručně napsaný soubor se při dalším startu nahradí:

[network]
generateResolvConf = false

Uložte to jako /etc/wsl.conf, spusťte wsl --shutdown z Windows, potom nastartujte distribuci a napište /etc/resolv.conf se servery tunelu prvními a veřejným resolverem jen jako zálohou. Je to trvalá změna s náklady na údržbu: soubor už nenásleduje hostitele, takže když se firemní adresy DNS změní, distribuce se dál ptá na staré. Někdo musí ten soubor vlastnit.

Nic nedělá ani tehdy, když je selhání širší. Pokud curl na 1.1.1.1 vyprší, klient tunelu filtruje virtuální přepínač nebo směruje podsíť VM do tunelu a správný resolver vám dá jen jména, na která se stále nedá dosáhnout.

Mýtus druhý: změna metriky vydrží

Když se jména překládají, ale provoz odchází přes fyzický adaptér, pákou jsou metriky rozhraní. Dejte adaptéru VPN vysokou cenu a přepínači WSL nízkou:

Get-NetAdapter | Where-Object InterfaceDescription -Match "AnyConnect" | Set-NetIPInterface -InterfaceMetric 4000
Get-NetIPInterface -InterfaceAlias "vEthernet (WSL)" | Set-NetIPInterface -InterfaceMetric 1

Pak si pamatujte, že v mnoha sestaveních klienta se adaptér tunelu znovu vytváří při každém připojení a metrika se vrací k výchozí hodnotě. Jednorázový příkaz je oprava, která tiše vyprší, obvykle přes víkend, a tiket se vrátí s «minulý týden to fungovalo». Naplánovaná úloha spouštěná událostí VPN nebo skript, který uživatel pustí po připojení, je poctivá verze této opravy.

Stejná expirace platí pro trasy hostitele přidané pro jeden tvrdošíjný prefix. Jako diagnostika mají cenu, protože řeknou, zda je problém jedna destinace nebo celá cesta, ale nejsou architektura.

Mýtus třetí: jedna oprava pokryje každé sestavení Windows

wsl-vpnkit je vzor sidecar: malá distribuce vlastní cestu na straně hostitele a přeposílá za jiné distribuce přes virtuální socket, takže provoz aplikací přestane záviset na filtrovaném přepínači. Potřebuje funkční standardní cestu, což znamená odstranit přepisy networkingMode a dnsTunneling z %UserProfile%\.wslconfig, obnovit generateResolvConf = true v každé funkční distribuci a spustit službu při přihlášení.

Zrcadlový režim je vestavěná alternativa ve Windows 11 22H2 a novějších a je to jedno nastavení plus vypnutí:

[wsl2]
networkingMode=mirrored

Uvnitř distribuce pak ip addr vypíše adaptéry hostitele, tunel se mezi nimi může objevit a DNS tunelování přeposílá dotazy přes resolver Windows, i když klient přepíše seznam DNS. Není univerzální: některé filtrační ovladače zrcadlovou cestu stále zahazují a pravidla firewallu Hyper-V mohou vyžadovat výslovné povolení. Průvodce sítěmi WSL od Microsoftu je stránka, kterou je třeba porovnat se svým sestavením, než použijete recept napsaný pro novější.

Po každé změně otestujte tři věci

Vyberte jeden mechanismus na stroj a zapište ho, protože dva se kombinují špatně. Sidecar nad zrcadlovým režimem zdvojnásobuje přeposílání a zrcadlový hostitel se zastaralým záznamem sidecar v .wslconfig obvykle selže po upgradu, ne před ním.

Ať vyberete cokoli, akceptační test jsou stejné tři požadavky uvnitř distribuce: interní jméno, veřejné jméno a surová adresa. Pak je zopakujte po odpojení a opětovném připojení tunelu a po wsl --shutdown. Selhává-li jen interní jméno, je to resolver politika; selhávají-li interní i veřejné jméno společně s fungující adresou, je to stále resolver politika; selhává-li vše, je to cesta.

Když jeden interní hostitel selže a ostatní fungují, přestaňte se dívat na resolver a hledejte chybějící trasu pro ten prefix. Když vše funguje až do dalšího připojení, našli jste opravu závislou na stavu za běhu a musí se znovu aplikovat automaticky nebo nahradit jedním ze dvou mechanismů výše.