WSL2 n'hérite pas du VPN d'entreprise, et c'est là le bug

Le wiki interne se charge dans Edge, tandis que git clone dans la distribution expire. Cette seule observation se lit généralement comme « le VPN bloque WSL2 », et l'heure suivante passe à modifier /etc/resolv.conf. La lecture plus utile est que WSL2 n'a jamais eu le chemin réseau de l'hôte : il s'exécute dans une VM utilitaire avec son propre adaptateur, ses propres routes et un fichier de resolver que Windows génère pour lui. Tout ce qui suit dépend de lequel de ces trois vous manque réellement.

La VM a sa propre pile, sa métrique et son resolver

En mode NAT par défaut, la distribution se trouve derrière un commutateur virtuel et atteint Internet via l'hôte, mais elle ne voit pas les adaptateurs de l'hôte. ip addr montre une interface avec une adresse privée, ip route montre une route par défaut via ce commutateur, et /etc/resolv.conf est un fichier généré qui pointe vers un stub resolver choisi par Windows. Rien de tout cela ne change parce qu'un client VPN s'est lancé côté Windows.

C'est pourquoi « le navigateur fonctionne » prouve si peu. Le navigateur utilise la pile de l'hôte, le tunnel et la politique de resolver de l'hôte. Votre shell utilise une autre pile qui partage par hasard une carte réseau physique. Elles concordent dans le cas heureux et divergent exactement quand le VPN installe un filtre, réécrit la liste DNS ou ajoute une route pour le sous-réseau du commutateur virtuel.

Deux tests décident dans quel monde vous êtes, et ils doivent s'exécuter dans la distribution :

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

Que les noms échouent alors qu'une adresse littérale répond est un problème de resolver. Que les noms et les adresses échouent ensemble est un problème de chemin, et aucune modification du resolver n'y touchera. Les preuves côté Windows viennent ensuite : Get-NetAdapter | Get-DnsClientServerAddress et route print -4 montrent si le tunnel a revendiqué le sous-réseau où vit votre VM.

Mythe un : les serveurs DNS d'entreprise règlent le problème

Modifier le fichier de resolver est le conseil classique, et il est juste environ la moitié du temps. Quand il est juste, c'est pour une raison précise : le fichier généré pointe vers un resolver qui ne connaît que les noms publics, donc une requête pour intranet.example.internal revient comme inexistante alors que le chemin est bon.

Épingler les serveurs du VPN signifie empêcher Windows de régénérer le fichier, car tout fichier écrit à la main est remplacé au démarrage suivant :

[network]
generateResolvConf = false

Enregistrez cela comme /etc/wsl.conf, exécutez wsl --shutdown depuis Windows, puis démarrez la distribution et écrivez /etc/resolv.conf avec les serveurs du tunnel en premier et un resolver public seulement en secours. C'est un changement durable avec un coût de maintenance : le fichier ne suit plus l'hôte, donc quand les adresses DNS d'entreprise changent, la distribution continue d'interroger les anciennes. Quelqu'un doit être responsable de ce fichier.

Cela ne fait rien non plus quand la panne est plus large. Si curl vers 1.1.1.1 expire, le client du tunnel filtre le commutateur virtuel ou achemine le sous-réseau de la VM dans le tunnel, et un resolver correct ne vous donne que des noms toujours inaccessibles.

Mythe deux : le changement de métrique tient

Quand les noms se résolvent mais que le trafic sort par l'adaptateur physique, le levier est constitué par les métriques d'interface. Donnez un coût élevé à l'adaptateur VPN et un coût faible au commutateur WSL :

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

Rappelez-vous ensuite que, dans de nombreuses versions du client, l'adaptateur du tunnel est recréé à chaque connexion et la métrique revient à sa valeur par défaut. Une commande unique est une correction qui expire en silence, généralement le temps d'un week-end, et le ticket revient avec « ça marchait la semaine dernière ». Une tâche planifiée déclenchée par l'événement VPN, ou un script que l'utilisateur exécute après connexion, est la version honnête de cette réparation.

La même expiration s'applique aux routes d'hôte ajoutées pour un préfixe récalcitrant. Elles valent comme diagnostic, car elles indiquent si le problème est une destination ou tout le chemin, mais elles ne sont pas une architecture.

Mythe trois : une correction couvre chaque version de Windows

wsl-vpnkit est le modèle sidecar : une petite distribution possède le chemin côté hôte et transfère pour les autres distributions via une socket virtuelle, de sorte que le trafic applicatif cesse de dépendre du commutateur filtré. Il faut que le chemin standard fonctionne, ce qui suppose de retirer les surcharges networkingMode et dnsTunneling de %UserProfile%\.wslconfig, de restaurer generateResolvConf = true dans chaque distribution fonctionnelle et de démarrer le service à l'ouverture de session.

Le mode miroir est l'alternative intégrée sous Windows 11 22H2 et ultérieur, et c'est un réglage plus un arrêt :

[wsl2]
networkingMode=mirrored

Dans la distribution, ip addr liste alors les adaptateurs de l'hôte, le tunnel peut apparaître parmi eux, et le tunnel DNS transfère les requêtes via le resolver de Windows même lorsque le client réécrit la liste DNS. Ce n'est pas universel : certains pilotes de filtre rejettent encore le chemin miroir, et les règles de pare-feu Hyper-V peuvent nécessiter une autorisation explicite. Le guide réseau WSL de Microsoft est la page à comparer avec votre version avant d'appliquer une recette écrite pour une plus récente.

Testez trois choses après chaque changement

Choisissez un mécanisme par machine et notez-le, car les deux se combinent mal. Un sidecar par-dessus le mode miroir double le transfert, et un hôte miroir avec une entrée sidecar obsolète dans .wslconfig a tendance à échouer après une mise à niveau, pas avant.

Quel que soit votre choix, le test d'acceptation est constitué des mêmes trois requêtes dans la distribution : un nom interne, un nom public et une adresse brute. Répétez-les ensuite après avoir déconnecté et reconnecté le tunnel, puis après wsl --shutdown. Si seul le nom interne échoue, c'est la politique de resolver ; si le nom interne et le nom public échouent ensemble avec une adresse qui fonctionne, c'est toujours la politique de resolver ; si tout échoue, c'est le chemin.

Si un hôte interne échoue alors que le reste fonctionne, cessez de regarder le resolver et cherchez une route manquante pour ce préfixe. Si tout fonctionne jusqu'à la reconnexion suivante, vous avez trouvé une correction qui dépend de l'état d'exécution, et elle doit être réappliquée automatiquement ou remplacée par l'un des deux mécanismes ci-dessus.