WSL2 erf nie die korporatiewe VPN nie, en dit is die fout

Die interne wiki laai in Edge, en git clone binne die verspreiding hou aan tyd uit. Daardie enkele waarneming word gewoonlik gelees as “die VPN blokkeer WSL2”, en die volgende uur gaan in die wysiging van /etc/resolv.conf. Die nuttiger lesing is dat WSL2 nooit die gasheer se netwerkpad gehad het nie: dit loop in 'n nuts-VM met sy eie adapter, sy eie roetes en 'n resolver-lêer wat Windows vir hom genereer. Alles wat volg hang daarvan af watter van daardie drie jy werklik mis.

Die VM het sy eie stapel, metrieke en resolver

In die verstek NAT-modus sit die verspreiding agter 'n virtuele skakelaar en bereik die internet deur die gasheer, maar dit sien nie die gasheer se adapters nie. ip addr wys een koppelvlak met 'n private adres, ip route wys 'n verstekroete deur daardie skakelaar, en /etc/resolv.conf is 'n gegenereerde lêer wat na 'n stub-resolver wys wat Windows gekies het. Niks daarvan verander omdat 'n VPN-kliënt aan die Windows-kant opgekom het nie.

Dit is hoekom “die blaaier werk” so min bewys. Die blaaier gebruik die gasheer se stapel, die tonnel en die gasheer se resolver-beleid. Jou dop gebruik 'n ander stapel wat toevallig 'n fisiese netwerkkaart deel. Hulle stem saam in die gelukkige geval en wyk presies uiteen wanneer die VPN 'n filter installeer, die DNS-lys herskryf of 'n roete vir die virtuele skakelaar se subnet byvoeg.

Twee toetse beslis in watter wêreld jy is, en hulle moet binne die verspreiding loop:

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

Name wat misluk terwyl 'n letterlike adres antwoord, is 'n resolver-probleem. Name en adresse wat saam misluk, is 'n padprobleem, en geen hoeveelheid resolver-redigering sal dit raak nie. Windows-kant bewyse kom volgende: Get-NetAdapter | Get-DnsClientServerAddress en route print -4 wys of die tonnel die subnet geëis het waarop jou VM woon.

Mite een: die korporatiewe DNS-bedieners maak dit reg

Die wysiging van die resolver-lêer is die klassieke raad, en dit is omtrent die helfte van die tyd reg. Wanneer dit reg is, is dit reg om 'n spesifieke rede: die gegenereerde lêer wys na 'n resolver wat net publieke name ken, so 'n navraag vir intranet.example.internal kom terug as nie-bestaande selfs al is die pad in orde.

Om die VPN se bedieners vas te pen beteken om Windows te stop om die lêer te regenereer, want enige lêer wat jy met die hand skryf, word by die volgende begin vervang:

[network]
generateResolvConf = false

Stoor dit as /etc/wsl.conf, hardloop wsl --shutdown vanaf Windows, begin dan die verspreiding en skryf /etc/resolv.conf met die tonnel se bedieners eerste en 'n publieke resolver net as 'n terugval. Dit is 'n duursame verandering met 'n onderhoudskoste: die lêer volg nie meer die gasheer nie, so wanneer die korporatiewe DNS-adresse verander, hou die verspreiding aan om die oues te vra. Iemand moet daardie lêer besit.

Dit doen ook niks wanneer die fout wyer is nie. As curl na 1.1.1.1 tyd uit, filter die tonnelkliënt die virtuele skakelaar of stuur die VM se subnet in die tonnel in, en 'n korrekte resolver gee jou net name wat steeds nie bereik kan word nie.

Mite twee: die metrieke verandering hou

Wanneer name oplos maar verkeer verlaat deur die fisiese adapter, is koppelvlakmetrieke die hefboom. Gee die VPN-adapter 'n hoë koste en die WSL-skakelaar 'n lae een:

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

Onthou dan dat op baie kliëntboue die tonneladapter by elke verbinding herskep word en die metrieke na sy verstek terugkeer. 'n Eenmalige opdrag is 'n regstelling wat stilweg verstryk, gewoonlik oor 'n naweek, en die kaartjie kom terug met “dit het verlede week gewerk”. 'n Geskeduleerde taak wat deur die VPN-gebeurtenis geaktiveer word, of 'n script wat die gebruiker ná verbinding loop, is die eerlike weergawe van hierdie herstel.

Dieselfde verstryking geld vir gasheerroetes wat vir 'n enkele hardnekkige voorvoegsel bygevoeg is. Hulle is die moeite werd as 'n diagnostiek, want hulle sê vir jou of die probleem een bestemming of die hele pad is, maar hulle is nie 'n argitektuur nie.

Mite drie: een regstelling dek elke Windows-bou

wsl-vpnkit is die sidecar-patroon: 'n klein verspreiding besit die pad aan die gasheerkant en stuur vir ander verspreidings oor 'n virtuele socket, so toepassingsverkeer hou op om van die gefiltreerde skakelaar af te hang. Dit benodig die standaardpad om te werk, wat beteken om networkingMode en dnsTunneling oorheersings uit %UserProfile%\.wslconfig te verwyder, generateResolvConf = true in elke werkende verspreiding te herstel, en die diens by aanmelding te begin.

Geweerspiegelde modus is die ingeboude alternatief op Windows 11 22H2 en later, en dit is een instelling plus 'n afskakeling:

[wsl2]
networkingMode=mirrored

Binne die verspreiding lys ip addr dan die gasheer se adapters, die tonnel kan onder hulle verskyn, en DNS-tonnelering stuur opsoeke deur die Windows-resolver selfs wanneer die kliënt die DNS-lys herskryf. Dit is nie universeel nie: sommige filterbestuurders laat steeds die gespiegelde pad val, en Hyper-V-firewallreëls mag 'n eksplisiete toelating nodig hê. Microsoft se WSL-netwerkgerus is die bladsy om teen jou bou te kontroleer voordat jy 'n resep toepas wat vir 'n nuwer een geskryf is.

Toets drie dinge ná elke verandering

Kies een meganisme per masjien en skryf dit neer, want die twee kombineer sleg. 'n Sidecar bo-op geweerspiegelde modus verdubbel die aanstuur, en 'n geweerspiegelde gasheer met 'n verouderde sidecar-inskrywing in .wslconfig is geneig om ná 'n opgradering te faal eerder as voor dit.

Wat jy ook al gekies het, die aanvaardingstoets is dieselfde drie versoeke binne die verspreiding: 'n interne naam, 'n publieke naam en 'n rou adres. Herhaal hulle dan nadat jy die tonnel ontkoppel en weer gekoppel het, en ná wsl --shutdown. Interne naam wat alleen misluk beteken resolver-beleid; interne en publieke name wat saam misluk met 'n werkende adres beteken steeds resolver-beleid; alles wat misluk beteken die pad.

As een interne gasheer misluk terwyl die res werk, hou op om na die resolver te kyk en soek na 'n ontbrekende roete vir daardie voorvoegsel. As alles werk tot die volgende herverbinding, het jy 'n regstelling gevind wat van looptydtoestand afhang, en dit moet outomaties weer toegepas word of vervang word met een van die twee meganismes hierbo.