WSL2 no hereta la VPN corporativa, i aquest és l'error
WSL2 s'executa en la seva pròpia xarxa virtual i mai no hereta la pila VPN de l'amfitrió. Separeu les fallades de noms de les fallades de camí abans d'editar resolv.conf.
La wiki interna es carrega a Edge, i git clone dins de la distribució acaba en temps d'espera. Aquesta única observació normalment es llegeix com «la VPN bloqueja WSL2», i l'hora següent se'n va en editar /etc/resolv.conf. La lectura més útil és que WSL2 mai no va tenir el camí de xarxa de l'amfitrió: s'executa en una VM auxiliar amb el seu propi adaptador, les seves pròpies rutes i un fitxer de resolver que Windows genera per a ell. Tot el que segueix depèn de quin d'aquests tres és el que realment us falta.
La VM té la seva pròpia pila, mètrica i resolver
En el mode NAT predeterminat, la distribució se situa darrere d'un commutador virtual i arriba a internet a través de l'amfitrió, però no veu els adaptadors de l'amfitrió. ip addr mostra una interfície amb una adreça privada, ip route mostra una ruta predeterminada a través d'aquest commutador, i /etc/resolv.conf és un fitxer generat que apunta a un stub resolver que Windows va triar. Res d'això canvia pel fet que un client VPN s'hagi iniciat al costat de Windows.
Per això «el navegador funciona» demostra tan poc. El navegador fa servir la pila de l'amfitrió, el túnel i la política de resolver de l'amfitrió. La vostra shell fa servir una pila diferent que casualment comparteix una targeta de xarxa física. Coincideixen en el cas feliç i divergeixen exactament quan la VPN instal·la un filtre, reescriu la llista de DNS o afegeix una ruta per a la subxarxa del commutador virtual.
Dues proves decideixen en quin món sou, i s'han d'executar dins de la distribució:
getent hosts example.com
curl -sS -m 8 -o /dev/null -w "%{http_code}\n" 1.1.1.1
ip route
cat /etc/resolv.confQue els noms fallin mentre una adreça literal respon és un problema de resolver. Que els noms i les adreces fallin alhora és un problema de camí, i cap quantitat d'edició del resolver no hi tocarà. Les proves del costat de Windows vénen després: Get-NetAdapter | Get-DnsClientServerAddress i route print -4 mostren si el túnel s'ha quedat amb la subxarxa on viu la vostra VM.
Mite u: els servidors DNS corporatius ho arreglen
Editar el fitxer de resolver és el consell clàssic, i encerta aproximadament la meitat de les vegades. Quan encerta, és per un motiu concret: el fitxer generat apunta a un resolver que només coneix noms públics, així que una consulta per a intranet.example.internal torna com a inexistent encara que el camí estigui bé.
Fixar els servidors de la VPN vol dir aturar Windows perquè no regeneri el fitxer, perquè qualsevol fitxer que escriviu a mà es reemplaça al proper inici:
[network]
generateResolvConf = falseDeseu-ho com a /etc/wsl.conf, executeu wsl --shutdown des de Windows, després inicieu la distribució i escriviu /etc/resolv.conf amb els servidors del túnel primer i un resolver públic només com a alternativa. És un canvi durador amb un cost de manteniment: el fitxer ja no segueix l'amfitrió, així que quan canvien les adreces DNS corporatives la distribució continua preguntant les antigues. Algú ha de ser responsable d'aquest fitxer.
Tampoc no fa res quan la fallada és més àmplia. Si curl cap a 1.1.1.1 acaba en temps d'espera, el client del túnel està filtrant el commutador virtual o encaminant la subxarxa de la VM cap al túnel, i un resolver correcte només us dona noms que encara no es poden assolir.
Mite dos: el canvi de mètrica s'aguanta
Quan els noms es resolen però el trànsit surt per l'adaptador físic, la palanca són les mètriques d'interfície. Doneu un cost alt a l'adaptador de la VPN i un de baix al commutador WSL:
Get-NetAdapter | Where-Object InterfaceDescription -Match "AnyConnect" | Set-NetIPInterface -InterfaceMetric 4000
Get-NetIPInterface -InterfaceAlias "vEthernet (WSL)" | Set-NetIPInterface -InterfaceMetric 1Després recordeu que en moltes compilacions del client l'adaptador del túnel es recrea a cada connexió i la mètrica torna al seu valor predeterminat. Una ordre puntual és una correcció que caduca en silenci, normalment durant un cap de setmana, i el tiquet torna amb «la setmana passada funcionava». Una tasca programada activada per l'esdeveniment de la VPN, o un script que l'usuari executa després de connectar-se, és la versió honesta d'aquesta reparació.
La mateixa caducitat s'aplica a les rutes d'amfitrió afegides per a un prefix tossut. Valen la pena com a diagnòstic, perquè us diuen si el problema és una destinació o tot el camí, però no són una arquitectura.
Mite tres: una solució cobreix cada compilació de Windows
| Approach | What it actually does |
|---|---|
| Resolver pin | Fixes private names only; no effect on path failures |
| Sidecar distribution | Forwards traffic over a socket to a helper VM, so the switch's filter no longer matters |
| Mirrored networking | Gives the distribution the host's interface set; also enables DNS tunnelling |
wsl-vpnkit és el patró sidecar: una distribució petita posseeix el camí del costat de l'amfitrió i reenvia per a altres distribucions a través d'un socket virtual, de manera que el trànsit d'aplicacions deixa de dependre del commutador filtrat. Cal que el camí estàndard funcioni, cosa que vol dir treure les anul·lacions de networkingMode i dnsTunneling de %UserProfile%\.wslconfig, restaurar generateResolvConf = true a cada distribució que funcioni i iniciar el servei a l'inici de sessió.
El mode mirall és l'alternativa integrada a Windows 11 22H2 i posteriors, i és un paràmetre més un apagat:
[wsl2]
networkingMode=mirroredDins de la distribució ip addr aleshores llista els adaptadors de l'amfitrió, el túnel pot aparèixer entre ells, i el túnel de DNS reenvia les consultes a través del resolver de Windows fins i tot quan el client reescriu la llista de DNS. No és universal: alguns controladors de filtre encara descarten el camí mirall, i les regles del tallafoc d'Hyper-V poden necessitar un permís explícit. La guia de xarxes de WSL de Microsoft és la pàgina que cal contrastar amb la vostra compilació abans d'aplicar una recepta escrita per a una de més nova.
Proveu tres coses després de cada canvi
Trieu un mecanisme per màquina i escriviu-lo, perquè els dos es combinen malament. Un sidecar sobre el mode mirall duplica el reenviament, i un amfitrió mirall amb una entrada de sidecar obsoleta a .wslconfig tendeix a fallar després d'una actualització, no abans.
Tant se val què trieu, la prova d'acceptació són les mateixes tres peticions dins de la distribució: un nom intern, un nom públic i una adreça crua. Després repetiu-les després de desconnectar i tornar a connectar el túnel, i després de wsl --shutdown. Si només falla el nom intern, és política de resolver; si fallen alhora el nom intern i el públic amb una adreça que funciona, encara és política de resolver; si falla tot, és el camí.
Si falla un amfitrió intern mentre la resta funciona, deixeu de mirar el resolver i busqueu una ruta que falti per a aquest prefix. Si tot funciona fins a la propera reconnexió, heu trobat una correcció que depèn de l'estat en temps d'execució, i cal reaplicar-la automàticament o substituir-la per un dels dos mecanismes anteriors.