WSL2 ne podeduje poslovnega VPN, in prav to je napaka

Notranji wiki se naloži v Edgeu, medtem ko git clone znotraj distribucije poteče. To eno opažanje se običajno bere kot «VPN blokira WSL2», in naslednja ura gre za urejanje /etc/resolv.conf. Bolj uporabno branje je, da WSL2 nikoli ni imel omrežne poti gostitelja: teče v pomožnem VM z lastnim adapterjem, lastnimi potmi in datoteko resolverja, ki jo Windows ustvari zanj. Vse nadaljnje je odvisno od tega, katera od teh treh vam dejansko manjka.

VM ima lasten sklad, meritve in resolver

V privzetem načinu NAT distribucija stoji za virtualnim stikalom in doseže internet prek gostitelja, vendar ne vidi njegovih adapterjev. ip addr prikaže en vmesnik z zasebnim naslovom, ip route prikaže privzeto pot skozi to stikalo, /etc/resolv.conf pa je ustvarjena datoteka, ki kaže na stub resolver, ki ga je izbral Windows. Nič od tega se ne spremeni, ker se je na strani Windows zagnal odjemalec VPN.

Zato «brskalnik deluje» dokaže tako malo. Brskalnik uporablja sklad gostitelja, tunel in resolver politiko gostitelja. Vaša lupina uporablja drug sklad, ki slučajno deli fizično omrežno kartico. Ujemata se v srečnem primeru in se razhajata točno takrat, ko VPN namesti filter, prepiše seznam DNS ali doda pot za podomrežje virtualnega stikala.

Dva testa odločita, v katerem svetu ste, in izvesti ju je treba znotraj distribucije:

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

Če imena spodletijo, medtem ko dobesedni naslov odgovori, je to težava resolverja. Če imena in naslovi spodletijo skupaj, je to težava poti in nobeno urejanje resolverja se je ne dotakne. Sledijo dokazi s strani Windows: Get-NetAdapter | Get-DnsClientServerAddress in route print -4 pokažeta, ali je tunel prevzel podomrežje, v katerem živi vaš VM.

Prvi mit: poslovni strežniki DNS to rešijo

Urejanje datoteke resolverja je klasičen nasvet in drži približno polovico časa. Ko drži, drži iz konkretnega razloga: ustvarjena datoteka kaže na resolver, ki pozna le javna imena, zato se poizvedba za intranet.example.internal vrne kot neobstoječa, čeprav je pot v redu.

Pripeti strežnike VPN pomeni ustaviti Windows pri ponovnem ustvarjanju datoteke, ker se vsaka ročno napisana datoteka ob naslednjem zagonu zamenja:

[network]
generateResolvConf = false

Shranite to kot /etc/wsl.conf, zaženite wsl --shutdown iz Windows, nato zaženite distribucijo in napišite /etc/resolv.conf s strežniki tunela najprej in javnim resolverjem le kot rezervo. To je trajna sprememba s stroškom vzdrževanja: datoteka ne sledi več gostitelju, zato ko se poslovni naslovi DNS spremenijo, distribucija še vedno sprašuje stare. Nekdo mora biti lastnik te datoteke.

Prav tako ne naredi ničesar, ko je napaka širša. Če curl do 1.1.1.1 poteče, odjemalec tunela filtrira virtualno stikalo ali usmerja podomrežje VM v tunel, in pravilen resolver vam da le imena, ki jim še vedno ni mogoče dostopati.

Drugi mit: sprememba meritve se obdrži

Ko se imena razrešijo, a promet odhaja skozi fizični adapter, so vzvod meritve vmesnika. Dajte adapterju VPN visoke stroške in stikalu WSL nizke:

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

Nato ne pozabite, da se v mnogih različicah odjemalca adapter tunela znova ustvari ob vsaki povezavi in meritev se vrne na privzeto. Enkratni ukaz je popravek, ki tiho poteče, običajno čez konec tedna, in zahtevek se vrne z «prejšnji teden je delovalo». Načrtovana opravila, ki jih sproži dogodek VPN, ali skript, ki ga uporabnik zažene po povezavi, je poštena različica tega popravka.

Enak rok velja za poti gostitelja, dodane za eno trmasto predpono. Vredne so kot diagnostika, ker povedo, ali je težava en cilj ali celotna pot, vendar niso arhitektura.

Tretji mit: en popravek pokrije vsako različico Windows

wsl-vpnkit je vzorec sidecar: majhna distribucija ima pot na strani gostitelja in posreduje za druge distribucije prek virtualnega vtiča, tako da promet aplikacij preneha biti odvisen od filtriranega stikala. Potrebuje delujočo standardno pot, kar pomeni odstraniti prepise networkingMode in dnsTunneling iz %UserProfile%\.wslconfig, obnoviti generateResolvConf = true v vsaki delujoči distribuciji in zagnati storitev ob prijavi.

Zrcalni način je vgrajena alternativa v Windows 11 22H2 in novejših, in je ena nastavitev plus izklop:

[wsl2]
networkingMode=mirrored

Znotraj distribucije ip addr nato našteje adapterje gostitelja, tunel se lahko pojavi med njimi, in DNS tuneliranje posreduje poizvedbe skozi resolver Windows tudi ko odjemalec prepiše seznam DNS. Ni univerzalno: nekateri filtrirni gonilniki še vedno zavržejo zrcalno pot, pravila požarnega zidu Hyper-V pa lahko zahtevajo izrecno dovoljenje. Vodnik po omrežjih WSL podjetja Microsoft je stran, ki jo je treba primerjati s svojo različico, preden uporabite recept, napisan za novejšo.

Po vsaki spremembi preizkusite tri stvari

Izberite en mehanizem na stroj in ga zapišite, ker se dva slabo kombinirata. Sidecar nad zrcalnim načinom podvoji posredovanje, zrcalni gostitelj z zastarelim vnosom sidecar v .wslconfig pa običajno odpove po nadgradnji, ne pred njo.

Karkoli izberete, sprejemni test so iste tri zahteve znotraj distribucije: notranje ime, javno ime in surov naslov. Nato jih ponovite po odklopu in ponovni priključitvi tunela ter po wsl --shutdown. Če odpove samo notranje ime, je to resolver politika; če hkrati odpovejo notranje in javno ime z delujočim naslovom, je to še vedno resolver politika; če odpove vse, je to pot.

Če en notranji gostitelj odpove, medtem ko drugi delujejo, prenehajte gledati resolver in poiščite manjkajočo pot za to predpono. Če vse deluje do naslednje ponovne povezave, ste našli popravek, ki je odvisen od stanja med izvajanjem, in treba ga je znova uporabiti samodejno ali nadomestiti z enim od dveh mehanizmov zgoraj.