Déi intern Wiki luedt am Edge, awer git clone bannent der Distributioun leeft an en Timeout. Dee eenzege Beobachtung gëtt meeschtens als «de VPN blockéiert WSL2» gelies, an déi nächst Stonn geet an d'Ännere vun /etc/resolv.conf. Déi méi nëtzlech Lieszart ass, datt WSL2 ni de Netzwierkwee vum Host hat: en leeft an enger Hëllefs-VM mat hirem eegene Adapter, hire eegene Routen an enger Resolver-Datei, déi Windows fir si generéiert. Alles wat duerno kënnt, hänkt dovun of, wéi eng vun deenen dräi Dir wierklech verpasst.

D'VM huet hire eegene Stack, Metriken an e Resolver

Am Standard-NAT-Modus sëtzt d'Distributioun hannert engem virtuelle Switch a erreecht d'Internet iwwer den Host, awer si gesäit d'Adaptere vum Host net. ip addr weist eng Interface mat enger privater Adress, ip route weist eng Standardroute iwwer dee Switch, an /etc/resolv.conf ass eng generéiert Datei, déi op en Stub-Resolver weist, deen Windows ausgewielt huet. Nolues vun deem ännert sech, well en VPN-Client op der Windows-Säit gestart gouf.

Dofir beweist «de Browser schafft» esou wéineg. De Browser benotzt de Stack vum Host, den Tunnel an d'Resolver-Politik vum Host. Är Shell benotzt en aneren Stack, deen zoufälleg eng physesch Netzwierkkart deelt. Si stëmmen am gudde Fall iwwerenee a divergéieren genau dann, wann de VPN e Filter installéiert, d'DNS-Lëscht ëmschreift oder eng Route fir de Subnetz vum virtuelle Switch bäisetzt.

Zwou Tester entscheeden, an wéi enger Welt Dir sidd, a si mussen an der Distributioun lafen:

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

Wann Nimm versoen, awer eng wuertlech Adress äntwert, ass dat e Resolver-Problem. Wann Nimm an Adressen zesummen versoen, ass dat e Wee-Problem, an keng Resolver-Ännerung wäert et beréieren. Duerno kommen d'Beweiser vun der Windows-Säit: Get-NetAdapter | Get-DnsClientServerAddress an route print -4 weisen, ob den Tunnel de Subnetz geholl huet, an deem Är VM wunnt.

Éischt Mythos: d'Betribs-DNS-Server huelen dat af

D'Resolver-Datei z'änneren ass de klasseschen Rot, an en ass ongeféier d'Halschent vun der Zäit richteg. Wann en richteg ass, ass en aus engem spezifesche Grond richteg: déi generéiert Datei weist op e Resolver, deen nëmmen ëffentlech Nimm kennt, sou datt eng Ufro fir intranet.example.internal als net existent zréckkënnt, obwuel de Wee an der Rei ass.

D'Server vum VPN befestigen heescht Windows stoppen, d'Datei nei ze generéieren, well all Datei, déi Dir vun Hand schreift, beim nächsten Start ersat gëtt:

[network]
generateResolvConf = false

Späichert dat als /etc/wsl.conf, fuert wsl --shutdown vun Windows aus, start dann d'Distributioun a schreift /etc/resolv.conf mat den Tunnel-Server als éischt an engem ëffentlechen Resolver nëmmen als Reserve. Dat ass eng dauerhaft Ännerung mat Ënnerhaltskäschten: d'Datei follegt dem Host net méi, also wann d'Betribs-DNS-Adressen sech änneren, freet d'Distributioun weider déi al. Iergendeen muss déi Datei besëtzen.

Et mécht och näischt, wann de Feeler méi breet ass. Wann curl op 1.1.1.1 an en Timeout leeft, filtert den Tunnel-Client de virtuelle Switch oder routet de Subnetz vun der VM an den Tunnel, an e korrekte Resolver gëtt Iech just Nimm, déi nach ëmmer net erreechbar sinn.

Zweet Mythos: d'Metrikännerung hält

Wann Nimm sech opléisen, awer den Trafic iwwer den physeschen Adapter erausgeet, sinn Interface-Metriken de Hebel. Gitt dem VPN-Adapter héich Käschten an dem WSL-Switch niddereg:

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

Denkt dann drun, datt a ville Client-Builds den Tunnel-Adapter bei all Verbindung nei erstallt gëtt an d'Metrik op hire Standard zréckkënnt. En eenzegaartege Befehl ass eng Reparatur, déi sech stëll verbraucht, meeschtens iwwer e Week-end, an den Ticket kënnt mat «lescht Woch huet et geschafft» zréck. Eng geplangte Aufgab, déi vum VPN-Evenement ausgeléist gëtt, oder e Skript, deen de Benotzer no der Verbindung lafe léisst, ass déi éierlech Versioun vun dëser Reparatur.

Déiselwecht Verfallsdatum gëllt fir Host-Routen, déi fir ee stierege Prefix bäigesat goufen. Si si wäertvoll als Diagnostik, well si soen, ob de Problem een Zil oder de ganze Wee ass, awer si sinn keng Architektur.

Drëtt Mythos: eng Reparatur deckt all Windows-Build of

ApproachWhat it actually does
Resolver pinFixes private names only; no effect on path failures
Sidecar distributionForwards traffic over a socket to a helper VM, so the switch's filter no longer matters
Mirrored networkingGives the distribution the host's interface set; also enables DNS tunnelling

wsl-vpnkit ass de Sidecar-Muster: eng kleng Distributioun besëtzt de Wee op der Host-Säit a leet fir aner Distributiounen iwwer e virtuelle Socket weider, sou datt den Applikatiounstrafic ophält, vum gefilterte Switch ofhängeg ze sinn. Et brauch de Standardwee, wat heescht, d'Iwwerschreiwungen networkingMode an dnsTunneling aus %UserProfile%\.wslconfig ze läschen, generateResolvConf = true an all funktionéierender Distributioun ze restauréieren an den Déngscht beim Login ze starten.

De Spigelmodus ass déi agebaut Alternativ op Windows 11 22H2 an déi méi nei, an et ass eng Astellung plus en Auschalten:

[wsl2]
networkingMode=mirrored

Bannent der Distributioun zielt ip addr dann d'Adaptere vum Host op, den Tunnel kann tëscht hinnen erschéngen, an DNS-Tunneling leet Ufroen iwwer de Windows-Resolver weider och wann de Client d'DNS-Lëscht ëmschreift. Et ass net universell: verschidden Filterdriver verwerfen de Spigelwee nach ëmmer, a Hyper-V-Firewallregele kënnen eng explizit Erlaabnis brauchen. Dem Microsoft seng WSL-Netzwierk-Guide ass d'Säit, déi Dir géint Äre Build kontrolléiere sollt, ier Dir eng Rezept uwent, déi fir eng méi nei geschriwwe gouf.

Test no all Ännerung dräi Saachen

Wielt ee Mechanismus pro Maschinn a schreift en op, well déi zwee sech schlecht kombinéieren. E Sidecar iwwer dem Spigelmodus verduebelt d'Weiderleedung, an en gespigelte Host mat engem veralterte Sidecar-Entrag an .wslconfig tendéiert no engem Upgrade ze versoen, net virdrun.

Wat Dir och gewielt hutt, den Akzeptanztest sinn déiselwecht dräi Ufroen an der Distributioun: en internen Numm, en ëffentlechen Numm an eng ro Adress. Widderhuelt se dann no dem Trennen an erneiem Verbannen vum Tunnel, an no wsl --shutdown. Nëmmen den internen Numm, dee versoe geet, heescht Resolver-Politik; internen an ëffentlechen Numm, déi zesumme mat enger funktionéierender Adress versoen, heescht nach ëmmer Resolver-Politik; alles versoe geet heescht de Wee.

Wann een internen Host versoe geet, während de Rescht schafft, hält op de Resolver ze kucken a sicht eng feelend Route fir dee Prefix. Wann alles bis zur nächster Reconnectioun schafft, hutt Dir eng Reparatur fonnt, déi vum Runtime-Zoustand ofhänkt, an si muss automatesch erëm ugewannt oder duerch ee vun den zwéi Mechanismen uewen ersat ginn.

Ähnlech Artikelen