Hindi minamana ng WSL2 ang corporate VPN, at iyon ang bug
Tumatakbo ang WSL2 sa sarili nitong virtual network at hindi kailanman minamana ang VPN stack ng host. Paghiwalayin ang mga pagkabigo ng pangalan mula sa mga pagkabigo ng landas bago pa i-edit ang resolv.conf.
Naglo-load ang internal na wiki sa Edge, habang ang git clone sa loob ng distribution ay nag-time out. Ang nag-iisang obserbasyong iyon ay karaniwang binabasa bilang «hinaharangan ng VPN ang WSL2», at ang susunod na oras ay napupunta sa pag-edit ng /etc/resolv.conf. Ang mas kapaki-pakinabang na pagbasa ay hindi kailanman nagkaroon ang WSL2 ng network path ng host: tumatakbo ito sa isang utility VM na may sariling adapter, sariling ruta at file ng resolver na ginagawa ng Windows para dito. Lahat ng sumusunod ay nakasalalay sa kung alin sa tatlong iyon ang talagang kulang sa iyo.
May sariling stack, metric at resolver ang VM
Sa default na NAT mode, nakaupo ang distribution sa likod ng virtual switch at naaabot ang internet sa pamamagitan ng host, ngunit hindi nito nakikita ang mga adapter ng host. ip addr ay nagpapakita ng isang interface na may pribadong address, ip route ay nagpapakita ng default na ruta sa pamamagitan ng switch na iyon, at /etc/resolv.conf ay isang generated na file na tumuturo sa stub resolver na pinili ng Windows. Wala sa mga ito ang nagbabago dahil may VPN client na nagsimula sa panig ng Windows.
Kaya napakakaunting pinatutunayan ng «gumagana ang browser». Ginagamit ng browser ang stack ng host, ang tunnel at ang resolver policy ng host. Gumagamit ang shell mo ng ibang stack na nagkataong nagbabahagi ng pisikal na network card. Nagkakasundo sila sa mabuting kaso at naghihiwalay nang eksakto kapag nag-install ang VPN ng filter, nagsusulat muli ng listahan ng DNS o nagdadagdag ng ruta para sa subnet ng virtual switch.
Dalawang pagsubok ang nagpapasya kung aling mundo ka, at dapat silang tumakbo sa loob ng distribution:
getent hosts example.com
curl -sS -m 8 -o /dev/null -w "%{http_code}\n" 1.1.1.1
ip route
cat /etc/resolv.confAng pagpalya ng mga pangalan habang sumasagot ang literal na address ay problema sa resolver. Ang sabay na pagpalya ng mga pangalan at address ay problema sa landas, at walang pag-edit ng resolver ang makakaabot doon. Sumusunod ang ebidensya mula sa panig ng Windows: Get-NetAdapter | Get-DnsClientServerAddress at route print -4 ay nagpapakita kung nakuha ng tunnel ang subnet kung saan nakatira ang iyong VM.
Unang mito: inaayos ito ng mga corporate DNS server
Ang pag-edit ng resolver file ay ang klasikong payo, at tama ito mga kalahati ng oras. Kapag tama, may tiyak na dahilan: ang generated na file ay tumuturo sa resolver na alam lamang ang mga pampublikong pangalan, kaya ang query para sa intranet.example.internal ay bumabalik na parang wala kahit maayos ang landas.
Ang pag-pin ng mga server ng VPN ay nangangahulugang paghinto sa Windows sa pagbuo muli ng file, dahil anumang file na isinusulat mo sa kamay ay pinapalitan sa susunod na pagsisimula:
[network]
generateResolvConf = falseI-save iyon bilang /etc/wsl.conf, patakbuhin ang wsl --shutdown mula sa Windows, pagkatapos simulan ang distribution at isulat ang /etc/resolv.conf na ang mga server ng tunnel ay nauuna at isang pampublikong resolver bilang backup lamang. Ito ay isang pangmatagalang pagbabago na may gastos sa pagpapanatili: hindi na sinusundan ng file ang host, kaya kapag nagbago ang mga corporate DNS address ay patuloy na tinatanong ng distribution ang mga luma. Kailangang may magmay-ari ng file na iyon.
Wala rin itong ginagawa kapag mas malawak ang pagkabigo. Kung ang curl patungo sa 1.1.1.1 ay nag-time out, sinusuri ng tunnel client ang virtual switch o itinatanong ang subnet ng VM sa tunnel, at ang tamang resolver ay nagbibigay lamang ng mga pangalang hindi pa rin maabot.
Ikalawang mito: nananatili ang pagbabago sa metric
Kapag nalutas ang mga pangalan ngunit lumalabas ang trapiko sa pisikal na adapter, ang mga sukatan ng interface ang lever. Bigyan ang VPN adapter ng mataas na gastos at ang WSL switch ng mababa:
Get-NetAdapter | Where-Object InterfaceDescription -Match "AnyConnect" | Set-NetIPInterface -InterfaceMetric 4000
Get-NetIPInterface -InterfaceAlias "vEthernet (WSL)" | Set-NetIPInterface -InterfaceMetric 1Pagkatapos tandaan na sa maraming build ng client ang tunnel adapter ay muling ginagawa sa bawat koneksyon at bumabalik ang sukatan sa default nito. Ang isang beses na utos ay isang pag-aayos na tahimik na nag-expire, kadalasan sa isang weekend, at bumabalik ang ticket na may «gumana ito noong nakaraang linggo». Ang naka-iskedyul na gawain na pinapagana ng kaganapan ng VPN, o isang script na pinapatakbo ng user pagkatapos kumonekta, ay ang tapat na bersyon ng pag-aayos na ito.
Ang parehong pag-expire ay nalalapat sa mga ruta ng host na idinagdag para sa isang matigas na prefix. Sulit sila bilang diagnostiko, dahil sinasabi nila kung isang destinasyon o ang buong landas ang problema, ngunit hindi sila arkitektura.
Ikatlong mito: saklaw ng isang pag-aayos ang bawat Windows build
| Approach | What it actually does |
|---|---|
| Resolver pin | Fixes private names only; no effect on path failures |
| Sidecar distribution | Forwards traffic over a socket to a helper VM, so the switch's filter no longer matters |
| Mirrored networking | Gives the distribution the host's interface set; also enables DNS tunnelling |
wsl-vpnkit ay ang sidecar pattern: ang isang maliit na distribution ay nagmamay-ari ng landas sa panig ng host at nagpapasa para sa iba pang distribution sa pamamagitan ng virtual socket, kaya tumitigil ang trapiko ng application sa pagdepende sa na-filter na switch. Kailangan nitong gumana ang stock na landas, ibig sabihin alisin ang mga override na networkingMode at dnsTunneling mula sa %UserProfile%\.wslconfig, ibalik ang generateResolvConf = true sa bawat gumaganang distribution at simulan ang serbisyo sa pag-login.
Ang mirrored mode ay ang built-in na alternatibo sa Windows 11 22H2 at mas bago, at ito ay isang setting at isang shutdown:
[wsl2]
networkingMode=mirroredSa loob ng distribution, ililista ng ip addr ang mga adapter ng host, maaaring lumitaw ang tunnel sa gitna nila, at ang DNS tunnelling ay nagpapasa ng mga lookup sa resolver ng Windows kahit na isulat muli ng client ang listahan ng DNS. Hindi ito pangkalahatan: ang ilang filter driver ay nagtatapon pa rin ng mirrored path, at ang mga patakaran ng firewall ng Hyper-V ay maaaring mangailangan ng tahasang pahintulot. Ang gabay sa networking ng WSL ng Microsoft ang pahinang dapat ihambing sa iyong build bago maglapat ng recipe na isinulat para sa mas bago.
Subukan ang tatlong bagay pagkatapos ng bawat pagbabago
Pumili ng isang mekanismo bawat makina at isulat ito, dahil hindi maganda ang pagsasama ng dalawa. Ang sidecar sa ibabaw ng mirrored mode ay nagdodoble ng pagpapasa, at ang mirrored host na may lumang sidecar entry sa .wslconfig ay may tendensiyang mabigo pagkatapos ng upgrade, hindi bago ito.
Anuman ang pinili mo, ang acceptance test ay ang parehong tatlong kahilingan sa loob ng distribution: isang panloob na pangalan, isang pampublikong pangalan at isang hilaw na address. Pagkatapos ulitin ang mga ito pagkatapos idiskonekta at ikonekta muli ang tunnel, at pagkatapos ng wsl --shutdown. Tanging ang panloob na pangalan ang nabigo ay policy ng resolver; ang panloob at pampublikong pangalan na sabay nabigo habang gumagana ang address ay policy pa rin ng resolver; lahat nabigo ay ang landas.
Kung isang panloob na host ang nabigo habang gumagana ang iba, huminto sa pagtingin sa resolver at maghanap ng nawawalang ruta para sa prefix na iyon. Kung gumagana ang lahat hanggang sa susunod na muling pagkonekta, nakahanap ka ng pag-aayos na nakadepende sa runtime state, at kailangan itong muling ilapat nang awtomatiko o palitan ng isa sa dalawang mekanismo sa itaas.