WSL2 erft it bedriuws-VPN net, en dat is de flater

De ynterne wiki laden yn Edge, wylst git clone yn 'e distribúsje in time-out krijt. Dy iene observaasje wurdt meastentiids lêzen as «it VPN blokkearret WSL2», en it folgjende oere giet nei it bewurkjen fan /etc/resolv.conf. De brûkberder lêzing is dat WSL2 nea it netwurkpaad fan de host hie: it draait yn in help-VM mei syn eigen adapter, syn eigen rûtes en in resolver-bestân dat Windows foar him generearret. Alles wat folget hinget ôf fan hokker fan dy trije jo eins misse.

De VM hat syn eigen stapel, metriken en resolver

Yn 'e standert NAT-modus sit de distribúsje efter in firtuele switch en berikt it ynternet fia de host, mar it sjocht de adapters fan de host net. ip addr toant ien ynterface mei in privee adres, ip route toant in standertrûte fia dy switch, en /etc/resolv.conf is in generearre bestân dat wiist nei in stub-resolver dy't Windows keas. Neat dêrfan feroaret om't der in VPN-klant oan 'e Windows-kant opset is.

Dêrom bewiist «de browser wurket» sa weinig. De browser brûkt de stapel fan de host, de tunnel en it resolver-belied fan de host. Jo shell brûkt in oare stapel dy't tafallich in fysike netkaart dielt. Se komme oerien yn it lokkige gefal en ôfwike krekt as it VPN in filter ynstallearret, de DNS-list oerskriuwt of in rûte foar it subnet fan de firtuele switch taheakket.

Twa tests beslisse yn hokker wrâld jo binne, en se moatte yn 'e distribúsje rinne:

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

Nammen dy't mislearje wylst in letterlike adres antwurdet is in resolver-probleem. Nammen en adressen dy't tegearre mislearje is in paadprobleem, en gjin inkelde resolver-bewurking sil it reitsje. Bewiis fan 'e Windows-kant komt dêrnei: Get-NetAdapter | Get-DnsClientServerAddress en route print -4 litte sjen oft de tunnel it subnet hat opeasker dêr't jo VM wennet.

Myt ien: de korporative DNS-servers lossen it op

It bewurkjen fan it resolver-bestân is it klassike advys, en it is sawat de helte fan 'e tiid goed. As it goed is, is it om in spesifike reden goed: it generearre bestân wiist nei in resolver dy't allinne publike nammen ken, sadat in fraach foar intranet.example.internal weromkomt as net-besteand ek al is it paad goed.

De servers fan it VPN fêstsette betsjut Windows stopje om it bestân opnij te generearjen, want elk bestân dat jo mei de hân skriuwe wurdt by de folgjende start ferfongen:

[network]
generateResolvConf = false

Bewarje dat as /etc/wsl.conf, rin wsl --shutdown fanút Windows, start dan de distribúsje en skriuw /etc/resolv.conf mei de servers fan 'e tunnel earst en in publike resolver allinne as reserve. It is in duorjende feroaring mei in ûnderhâldskosten: it bestân folget de host net mear, dus as de bedriuws-DNS-adressen feroarje, bliuwt de distribúsje de âlde freegje. Immen moat dat bestân besitte.

It docht ek neat as de flater breder is. As curl nei 1.1.1.1 in time-out krijt, filtert de tunnelklant de firtuele switch of rûtelet it subnet fan 'e VM yn 'e tunnel, en in krekte resolver jout jo allinne nammen dy't noch net te berikken binne.

Myt twa: de metrykferoaring bliuwt steamjen

As nammen oplosse mar ferkear fia de fysike adapter fuortgiet, binne ynterfacemetriken de hefboom. Jou de VPN-adapter in hege kosten en de WSL-switch in lege:

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

Tink dan dat de tunneladapter yn in protte klantbuilds by elke ferbining opnij oanmakke wurdt en de metrika weromkomt nei syn standert. In ienmalige opdracht is in repaaraasje dy't stil ferrint, meastentiids oer in wykein, en it ticket komt werom mei «ferline wike wurke it». In plande taak dy't troch it VPN-evenemint aktivearre wurdt, of in skript dat de brûker nei ferbining rint, is de earlike ferzje fan dizze repaaraasje.

Deselde ferfaldatum jildt foar hostrûtes dy't foar ien koppige foarheaksel taheakke binne. Se binne de muoite wurdich as diagnostyk, om't se jo fertelle oft it probleem ien bestemming of it hiele paad is, mar se binne gjin arsjitektuer.

Myt trije: ien repaaraasje dekt elke Windows-build

wsl-vpnkit is it sidecar-patroan: in lytse distribúsje besit it paad oan 'e hostkant en stjoert foar oare distribúsjes oer in firtuele socket, sadat applikaasjeferkear ophâldt ôfhinklik te wêzen fan 'e filtere switch. It hat it standertpaad nedich om te wurkjen, wat betsjut de oerskriuwingen networkingMode en dnsTunneling út %UserProfile%\.wslconfig te ferwiderjen, generateResolvConf = true yn elke wurkjende distribúsje te herstellen en de tsjinst by oanmelding te starten.

Spegele modus is it ynboude alternatyf op Windows 11 22H2 en letter, en it is ien ynstelling plus in ôfsluten:

[wsl2]
networkingMode=mirrored

Yn 'e distribúsje listet ip addr dan de adapters fan 'e host, de tunnel kin der tusken ferskine, en DNS-tunnele stjoert fragen fia de Windows-resolver sels as de klant de DNS-list oerskriuwt. It is net universeel: guon filterstjoerders litte it spegele paad noch falle, en Hyper-V-firewallregels kinne in eksplisite tastimming nedich hawwe. Microsoft syn WSL-netwurkgids is de side om tsjin jo build te kontrolearjen foardat jo in resept tapasse dat foar in nijer ien skreaun is.

Test trije dingen nei elke feroaring

Kies ien meganisme per masine en skriuw it op, want de twa kombinearje min. In sidecar boppe op spegele modus ferdûbelet it trochstjoeren, en in spegele host mei in ferâldere sidecar-ynskriuwing yn .wslconfig hat de oanstriid om nei in upgrade te mislearjen, net dêrfoar.

Wat jo ek keazen hawwe, de akseptaasjetest is deselde trije oanfragen yn 'e distribúsje: in ynterne namme, in publike namme en in rau adres. Werhelje se dan nei it loskeppeljen en wer ferbinen fan 'e tunnel, en nei wsl --shutdown. Allinne de ynterne namme dy't mist is resolver-belied; ynterne en publike nammen dy't tegearre mislearje mei in wurkjend adres is noch altyd resolver-belied; alles mislearret is it paad.

As ien ynterne host mist wylst de rest wurket, stopje mei it sjen nei de resolver en sykje in ûntbrekkende rûte foar dat foarheaksel. As alles wurket oant de folgjende werferbining, hawwe jo in repaaraasje fûn dy't fan runtime-steat ôfhinklik is, en dy moat automatysk opnij tapast wurde of ferfongen wurde troch ien fan 'e twa meganismen hjirboppe.