WSL2 erft het bedrijfs-VPN niet, en dat is de bug

De interne wiki laadt in Edge, terwijl git clone in de distributie een time-out krijgt. Die ene observatie wordt meestal gelezen als «de VPN blokkeert WSL2», en het volgende uur gaat naar het aanpassen van /etc/resolv.conf. De nuttiger lezing is dat WSL2 nooit het netwerkpad van de host had: het draait in een hulp-VM met een eigen adapter, eigen routes en een resolverbestand dat Windows ervoor genereert. Alles wat volgt hangt af van welke van die drie je echt mist.

De VM heeft zijn eigen stack, metrieken en resolver

In de standaard NAT-modus zit de distributie achter een virtuele switch en bereikt het internet via de host, maar ziet de adapters van de host niet. ip addr toont één interface met een privéadres, ip route toont een standaardroute via die switch, en /etc/resolv.conf is een gegenereerd bestand dat wijst naar een stub-resolver die Windows koos. Niets daarvan verandert omdat er aan de Windows-kant een VPN-client is gestart.

Daarom bewijst «de browser werkt» zo weinig. De browser gebruikt de stack van de host, de tunnel en het resolverbeleid van de host. Jouw shell gebruikt een andere stack die toevallig een fysieke netwerkkaart deelt. Ze komen overeen in het gelukkige geval en divergeren precies wanneer de VPN een filter installeert, de DNS-lijst herschrijft of een route toevoegt voor het subnet van de virtuele switch.

Twee tests bepalen in welke wereld je zit, en ze moeten in de distributie draaien:

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

Dat namen falen terwijl een letterlijk adres antwoordt, is een resolverprobleem. Dat namen en adressen samen falen, is een padprobleem, en geen enkele resolverbewerking raakt het aan. Bewijs van de Windows-kant komt daarna: Get-NetAdapter | Get-DnsClientServerAddress en route print -4 laten zien of de tunnel het subnet heeft opgeëist waarin je VM woont.

Mythe één: de bedrijfs-DNS-servers lossen het op

Het resolverbestand aanpassen is het klassieke advies, en het klopt ongeveer de helft van de tijd. Als het klopt, klopt het om een specifieke reden: het gegenereerde bestand wijst naar een resolver die alleen openbare namen kent, dus een query voor intranet.example.internal komt terug als niet-bestaand ook al is het pad in orde.

De servers van de VPN vastzetten betekent Windows stoppen met het bestand opnieuw genereren, want elk bestand dat je met de hand schrijft wordt bij de volgende start vervangen:

[network]
generateResolvConf = false

Sla dat op als /etc/wsl.conf, voer wsl --shutdown uit vanuit Windows, start dan de distributie en schrijf /etc/resolv.conf met de servers van de tunnel eerst en een openbare resolver alleen als terugval. Dit is een blijvende wijziging met onderhoudskosten: het bestand volgt de host niet meer, dus wanneer de bedrijfs-DNS-adressen veranderen blijft de distributie de oude vragen. Iemand moet dat bestand bezitten.

Het doet ook niets wanneer de storing breder is. Als curl naar 1.1.1.1 een time-out krijgt, filtert de tunnelclient de virtuele switch of routeert het subnet van de VM de tunnel in, en een correcte resolver geeft je alleen namen die nog steeds niet bereikbaar zijn.

Mythe twee: de metriekwijziging blijft staan

Wanneer namen oplossen maar verkeer via de fysieke adapter vertrekt, zijn interfacemetrieken de hefboom. Geef de VPN-adapter een hoge kosten en de WSL-switch een lage:

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

Bedenk dan dat in veel clientbuilds de tunneladapter bij elke verbinding opnieuw wordt aangemaakt en de metriek terugkeert naar de standaard. Een eenmalig commando is een reparatie die stil verloopt, meestal in een weekend, en het ticket komt terug met «vorige week werkte het». Een geplande taak die door de VPN-gebeurtenis wordt gestart, of een script dat de gebruiker na het verbinden uitvoert, is de eerlijke versie van deze reparatie.

Dezelfde vervaldatum geldt voor hostroutes die zijn toegevoegd voor één koppig prefix. Ze zijn de moeite waard als diagnostiek, omdat ze zeggen of het probleem één bestemming of het hele pad is, maar ze zijn geen architectuur.

Mythe drie: één reparatie dekt elke Windows-build

wsl-vpnkit is het sidecar-patroon: een kleine distributie bezit het pad aan de hostkant en stuurt door voor andere distributies via een virtuele socket, zodat applicatieverkeer niet meer afhankelijk is van de gefilterde switch. Het vereist dat het standaardpad werkt, wat betekent de overschrijvingen networkingMode en dnsTunneling uit %UserProfile%\.wslconfig verwijderen, generateResolvConf = true herstellen in elke werkende distributie en de dienst bij het inloggen starten.

Spiegelmodus is het ingebouwde alternatief op Windows 11 22H2 en later, en het is één instelling plus een afsluiting:

[wsl2]
networkingMode=mirrored

Binnen de distributie somt ip addr dan de adapters van de host op, de tunnel kan ertussen verschijnen, en DNS-tunneling stuurt opzoekingen door de Windows-resolver zelfs wanneer de client de DNS-lijst herschrijft. Het is niet universeel: sommige filterdrivers laten het spiegelpad nog steeds vallen, en Hyper-V-firewallregels kunnen een expliciete toestemming nodig hebben. Microsofts WSL-netwerkgids is de pagina die je tegen je build moet controleren voordat je een recept toepast dat voor een nieuwere is geschreven.

Test drie dingen na elke wijziging

Kies één mechanisme per machine en schrijf het op, want de twee combineren slecht. Een sidecar bovenop spiegelmodus verdubbelt het doorsturen, en een gespiegelde host met een verouderde sidecar-regel in .wslconfig faalt meestal na een upgrade, niet ervoor.

Wat je ook koos, de acceptatietest zijn dezelfde drie verzoeken in de distributie: een interne naam, een openbare naam en een ruw adres. Herhaal ze daarna na het loskoppelen en opnieuw verbinden van de tunnel, en na wsl --shutdown. Alleen de interne naam die faalt betekent resolverbeleid; interne en openbare namen die samen falen met een werkend adres betekent nog steeds resolverbeleid; alles faalt betekent het pad.

Als één interne host faalt terwijl de rest werkt, stop met naar de resolver kijken en zoek een ontbrekende route voor dat prefix. Als alles werkt tot de volgende herverbinding, heb je een reparatie gevonden die van runtimetoestand afhangt, en die moet automatisch opnieuw worden toegepast of vervangen door een van de twee mechanismen hierboven.