WSL2 ei päri ettevõtte VPN-i ja just see ongi viga

Sisemine viki laadib Edges, samal ajal kui git clone distrotsioonis lõpeb aegumisega. Seda üksikut tähelepanekut loetakse tavaliselt kui «VPN blokeerib WSL2», ja järgmine tund läheb /etc/resolv.conf muutmisele. Kasulikum lugemine on see, et WSL2-l ei olnudki hosti võrguteed: see töötab abi-VM-is oma adapteri, oma marsruutide ja Windowsi loodud resolver-failiga. Kõik järgnev sõltub sellest, millist neist kolmest teil tegelikult puudu on.

VM-il on oma pinu, mõõdikud ja resolver

Vaikimisi NAT-režiimis seisab distrotsioon virtuaalse lüliti taga ja pääseb internetti hosti kaudu, kuid ei näe hosti adaptereid. ip addr näitab üht liidest privaatse aadressiga, ip route näitab vaikimisi marsruuti selle lüliti kaudu ja /etc/resolv.conf on genereeritud fail, mis osutab stub-resolverile, mille Windows valis. Miski sellest ei muutu seepärast, et Windowsi poolel käivitus VPN-klient.

Seepärast tõestab «brauser töötab» nii vähe. Brauser kasutab hosti pinu, tunnelit ja hosti resolver-poliitikat. Teie kest kasutab teist pinu, mis juhtumisi jagab füüsilist võrgukaarti. Need langevad kokku õnnelikul juhul ja lahknevad täpselt siis, kui VPN paigaldab filtri, kirjutab DNS-loendi ümber või lisab virtuaalse lüliti alavõrgule marsruudi.

Kaks testi otsustavad, millises maailmas te olete, ja need tuleb käivitada distrotsiooni sees:

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

Kui nimed ebaõnnestuvad, aga sõnasõnaline aadress vastab, on see resolveri probleem. Kui nimed ja aadressid ebaõnnestuvad koos, on see tee probleem, ja ükski resolveri muutmine seda ei puuduta. Järgmisena tulevad tõendid Windowsi poolelt: Get-NetAdapter | Get-DnsClientServerAddress ja route print -4 näitavad, kas tunnel hõivas alavõrgu, kus teie VM elab.

Müüt üks: ettevõtte DNS-serverid teevad selle korda

Resolver-faili muutmine on klassikaline nõuanne ja see on õige umbes pooltel juhtudel. Kui see on õige, on see õige konkreetsel põhjusel: genereeritud fail osutab resolverile, mis teab ainult avalikke nimesid, nii et päring intranet.example.internal kohta tuleb tagasi olematuna, kuigi tee on korras.

VPN-i serverite kinnitamine tähendab Windowsi peatamist faili uuesti genereerimast, sest iga käsitsi kirjutatud fail asendatakse järgmisel käivitamisel:

[network]
generateResolvConf = false

Salvestage see kui /etc/wsl.conf, käivitage Windowsist wsl --shutdown, seejärel käivitage distrotsioon ja kirjutage /etc/resolv.conf, kus tunneliserverid on esimesed ja avalik resolver ainult varuvariant. See on püsiv muudatus hoolduskuluga: fail ei järgi enam hosti, nii et kui ettevõtte DNS-aadressid muutuvad, küsib distrotsioon endiselt vanu. Keegi peab selle faili omanik olema.

See ei tee midagi ka siis, kui viga on laiem. Kui curl aadressile 1.1.1.1 lõpeb aegumisega, filtreerib tunneliklient virtuaalset lülitit või suunab VM-i alavõrgu tunnelisse, ja korrektne resolver annab teile ainult nimed, milleni ikka veel ei pääse.

Müüt kaks: mõõdiku muutus jääb püsima

Kui nimed lahenevad, aga liiklus väljub füüsilise adapteri kaudu, on hoovaks liidese mõõdikud. Andke VPN-adapterile kõrge kulu ja WSL-lülitile madal:

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

Seejärel pidage meeles, et paljudes kliendiversioonides luuakse tunnelil adapter iga ühenduse ajal uuesti ja mõõdik naaseb vaikeväärtusele. Ühekordne käsk on parandus, mis aegub vaikselt, tavaliselt nädalavahetuse jooksul, ja pilet tuleb tagasi sõnadega «eelmisel nädalal töötas». VPN-sündmusel käivituv ajastatud ülesanne või skript, mille kasutaja pärast ühendamist käivitab, on selle paranduse aus versioon.

Sama aegumine kehtib hosti marsruutide kohta, mis lisati ühe kangekaelse prefiksi jaoks. Need on diagnostikana väärtuslikud, sest ütlevad, kas probleem on üks sihtkoht või kogu tee, kuid need ei ole arhitektuur.

Müüt kolm: üks parandus katab iga Windowsi versiooni

wsl-vpnkit on sidecar-muster: väike distrotsioon omab hostipoolset teed ja edastab teiste distrotsioonide liiklust virtuaalse soketi kaudu, nii et rakenduste liiklus lakkab sõltumast filtreeritud lülitist. See vajab töötavat tavalist teed, mis tähendab ülekirjutuste networkingMode ja dnsTunneling eemaldamist failist %UserProfile%\.wslconfig, generateResolvConf = true taastamist igas töötavas distrotsioonis ja teenuse käivitamist sisselogimisel.

Peegelrežiim on sissehitatud alternatiiv Windows 11 22H2 ja uuemates ning see on üks säte pluss väljalülitamine:

[wsl2]
networkingMode=mirrored

Distrotsiooni sees loetleb ip addr seejärel hosti adapterid, tunnel võib nende hulgas ilmuda, ja DNS-tunnelamine edastab päringud Windowsi resolveri kaudu isegi siis, kui klient kirjutab DNS-loendi ümber. See ei ole universaalne: mõned filtriliidesed viskavad peegelteed endiselt kõrvale ja Hyper-V tulemüürireeglid võivad vajada selgesõnalist luba. Microsofti WSL-i võrgu juhend on leht, mida tuleks enne uuematele mõeldud retsepti rakendamist oma versiooniga võrrelda.

Testige pärast iga muudatust kolme asja

Valige üks mehhanism masina kohta ja kirjutage see üles, sest need kaks kombineeruvad halvasti. Sidecar peegelrežiimi kohal kahekordistab edastamise, ja peegeldatud host, millel on .wslconfig failis vananenud sidecar-kirje, kipub pärast uuendust ebaõnnestuma, mitte enne seda.

Mida iganes valisite, vastuvõtutest on samad kolm päringut distrotsiooni sees: sisemine nimi, avalik nimi ja toores aadress. Seejärel korrake neid pärast tunneli lahtiühendamist ja uuesti ühendamist ning pärast wsl --shutdown. Kui ainult sisemine nimi ebaõnnestub, on see resolver-poliitika; kui sisemine ja avalik nimi ebaõnnestuvad koos töötava aadressiga, on see endiselt resolver-poliitika; kui kõik ebaõnnestub, on see tee.

Kui üks sisemine host ebaõnnestub, samal ajal kui ülejäänud töötavad, lõpetage resolveri vaatamine ja otsige selle prefiksi jaoks puuduvat marsruuti. Kui kõik töötab kuni järgmise taasühenduseni, olete leidnud paranduse, mis sõltub käitusaegsest olekust, ja seda tuleb automaatselt uuesti rakendada või asendada ühega kahest ülaltoodud mehhanismist.