A WSL2 nem örökli a vállalati VPN-t, és éppen ez a hiba

A belső wiki betöltődik az Edge-ben, miközben a git clone a disztribúción belül időtúllépésbe fut. Ezt az egyetlen megfigyelést általában úgy olvassák, hogy «a VPN blokkolja a WSL2-t», és a következő óra a /etc/resolv.conf szerkesztésével telik. A hasznosabb olvasat az, hogy a WSL2-nek soha nem is volt meg a gazdagép hálózati útvonala: egy segéd-VM-ben fut saját adapterrel, saját útvonalakkal és egy resolver-fájllal, amelyet a Windows generál neki. Minden további attól függ, hogy melyik hiányzik valójában a háromból.

A VM-nek saját stackje, metrikái és resolverje van

Az alapértelmezett NAT-módban a disztribúció egy virtuális kapcsoló mögött ül, és a gazdagépen keresztül éri el az internetet, de nem látja a gazdagép adaptereit. A ip addr egy privát című interfészt mutat, a ip route egy alapértelmezett útvonalat mutat azon a kapcsolón keresztül, a /etc/resolv.conf pedig egy generált fájl, amely egy Windows által választott stub resolverre mutat. Ezen semmi sem változik attól, hogy a Windows oldalán elindult egy VPN-kliens.

Ezért bizonyít olyan keveset az, hogy «a böngésző működik». A böngésző a gazdagép stackjét, az alagutat és a gazdagép resolver-szabályzatát használja. A héja más stacket használ, amely véletlenül osztozik egy fizikai hálózati kártyán. A jó esetben egyetértenek, és pontosan akkor válnak el, amikor a VPN szűrőt telepít, átírja a DNS-listát vagy útvonalat ad a virtuális kapcsoló alhálózatához.

Két teszt dönti el, melyik világban van, és ezeket a disztribúción belül kell futtatni:

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

Ha a nevek meghiúsulnak, miközben egy literális cím válaszol, az resolver-probléma. Ha a nevek és a címek együtt hiúsulnak meg, az útvonalprobléma, és semmilyen resolver-szerkesztés nem fogja érinteni. Ezután jönnek a Windows oldali bizonyítékok: a Get-NetAdapter | Get-DnsClientServerAddress és a route print -4 megmutatja, hogy az alagút megszerezte-e azt az alhálózatot, amelyben a VM él.

Első mítosz: a vállalati DNS-kiszolgálók megoldják

A resolver-fájl szerkesztése a klasszikus tanács, és az esetek körülbelül felében helyes. Amikor helyes, azért helyes, mert a generált fájl olyan resolverre mutat, amely csak nyilvános neveket ismer, így a intranet.example.internal iránti lekérdezés nem létezőként tér vissza, még ha az útvonal rendben is van.

A VPN kiszolgálóinak rögzítése azt jelenti, hogy megakadályozzuk a Windows-t a fájl újragenerálásában, mert bármely kézzel írt fájl a következő indításkor lecserélődik:

[network]
generateResolvConf = false

Mentse el /etc/wsl.conf néven, futtassa a wsl --shutdown parancsot Windowsból, majd indítsa el a disztribúciót, és írja meg a /etc/resolv.conf fájlt úgy, hogy az alagút kiszolgálói legyenek elöl, egy nyilvános resolver pedig csak tartalékként. Ez tartós változás karbantartási költséggel: a fájl már nem követi a gazdagépet, így amikor a vállalati DNS-címek megváltoznak, a disztribúció továbbra is a régi címeket kérdezi. Valakinek felelnie kell a fájlért.

Akkor sem tesz semmit, amikor a hiba szélesebb. Ha a curl a 1.1.1.1 felé időtúllépésbe fut, az alagút-kliens szűri a virtuális kapcsolót, vagy a VM alhálózatát az alagútba irányítja, és egy helyes resolver csak olyan neveket ad, amelyek még mindig nem érhetők el.

Második mítosz: a metrika változása megmarad

Amikor a nevek feloldódnak, de a forgalom a fizikai adapteren keresztül távozik, az interfész-metrikák a kar. Adjon magas költséget a VPN-adapternek és alacsonyat a WSL-kapcsolónak:

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

Ezután ne feledje, hogy sok kliens-buildben az alagútadapter minden kapcsolatnál újra létrejön, és a metrika visszatér az alapértékére. Az egyszeri parancs olyan javítás, amely csendesen lejár, általában egy hétvége alatt, és a jegy «múlt héten működött» szöveggel tér vissza. A VPN-esemény által indított ütemezett feladat vagy a felhasználó által csatlakozás után futtatott szkript a javítás őszinte változata.

Ugyanez a lejárat vonatkozik az egyetlen makacs előtaghoz hozzáadott gazdagép-útvonalakra. Diagnosztikaként megérnek valamit, mert megmondják, hogy a probléma egy cél vagy a teljes útvonal, de nem architektúra.

Harmadik mítosz: egy javítás minden Windows-buildet lefed

A wsl-vpnkit a sidecar-minta: egy kis disztribúció birtokolja a gazdagép oldali útvonalat, és virtuális socketen keresztül továbbít más disztribúciók számára, így az alkalmazásforgalom megszűnik a szűrt kapcsolótól függeni. Kell hozzá a szabványos útvonal működése, ami azt jelenti, hogy el kell távolítani a networkingMode és dnsTunneling felülírásokat a %UserProfile%\.wslconfig fájlból, vissza kell állítani a generateResolvConf = true beállítást minden működő disztribúcióban, és bejelentkezéskor el kell indítani a szolgáltatást.

A tükrözött mód a beépített alternatíva a Windows 11 22H2-ben és újabbakban, és ez egy beállítás plusz egy leállítás:

[wsl2]
networkingMode=mirrored

A disztribúción belül a ip addr ekkor felsorolja a gazdagép adaptereit, az alagút megjelenhet közöttük, és a DNS-alagutazás a Windows resolverén keresztül továbbítja a lekérdezéseket akkor is, amikor a kliens átírja a DNS-listát. Ez nem univerzális: egyes szűrőillesztők továbbra is eldobják a tükrözött útvonalat, és a Hyper-V tűzfal szabályai kifejezett engedélyt igényelhetnek. A Microsoft WSL hálózati útmutatója az az oldal, amelyet össze kell vetni a saját builddel, mielőtt egy újabbhoz írt receptet alkalmazna.

Minden változtatás után teszteljen három dolgot

Válasszon gépenként egy mechanizmust, és írja le, mert a kettő rosszul kombinálódik. A tükrözött mód fölötti sidecar megduplázza a továbbítást, a .wslconfig fájlban elavult sidecar-bejegyzéssel rendelkező tükrözött gazdagép pedig általában frissítés után hibázik, nem előtte.

Bármit is választott, az átvételi teszt ugyanaz a három kérés a disztribúción belül: egy belső név, egy nyilvános név és egy nyers cím. Ezután ismételje meg őket az alagút leválasztása és újracsatlakoztatása után, valamint a wsl --shutdown után. Ha csak a belső név hibázik, az resolver-szabályzat; ha a belső és a nyilvános név együtt hibázik egy működő címmel, az még mindig resolver-szabályzat; ha minden hibázik, az az útvonal.

Ha egy belső gazdagép hibázik, miközben a többi működik, hagyja abba a resolver nézését, és keressen hiányzó útvonalat ahhoz az előtaghoz. Ha minden működik a következő újracsatlakozásig, olyan javítást talált, amely a futásidejű állapottól függ, és automatikusan újra kell alkalmazni, vagy le kell cserélni a fenti két mechanizmus egyikével.