WSL2 a perdu le DNS après la connexion VPN ? Deux causes

Le ping par adresse fonctionne dans la distribution, les installations de paquets et les récupérations git non, et la panne est apparue juste après l’établissement du tunnel. Seuls les noms ont cessé d’être résolus, ce qui pointe vers le DNS plutôt que vers la connectivité. Réinstaller les paquets est le premier geste erroné le plus populaire ici. WSL2 a deux manières indépendantes de produire exactement ce symptôme, et elles demandent des réparations différentes.

Pourquoi la distribution garde son propre résolveur

Le client DNS de Windows n’est pas utilisé dans la distribution. WSL2 construit son propre fichier de résolveur au démarrage, pointant vers une adresse stub que Windows publie sur le commutateur virtuel pour la machine virtuelle utilitaire.

Cet agencement est stable lors des changements de réseau ordinaires parce qu’il est écrit une fois et réutilisé. L’agencement cesse d’être correct quand un client de tunnel réécrit la liste des adaptateurs de l’hôte après que la machine virtuelle utilitaire a déjà démarré.

Rien dans la distribution ne surveille le changement, donc le fichier continue de pointer vers une adresse qui n’est peut-être plus sur le chemin. La résolution suivante attend alors, expire ou reçoit une réponse d’un serveur qui n’a jamais entendu parler de la zone interne. De l’intérieur, le résolveur cesse simplement de répondre, et tous les noms échouent d’un coup.

Recueillez d’abord des preuves des deux côtés

Notez ce que voit la distribution, puis ce que voit Windows, avant de modifier l’un ou l’autre. Les deux vues ensemble sont ce qui distingue les modes de panne.

Dans la distribution, affichez le fichier de résolveur, la table de routage et une résolution interne et une publique :

ip -4 route
cat /etc/resolv.conf
getent hosts intranet.corp.example
getent hosts example.com

Sous Windows, listez les serveurs DNS par adaptateur et la table IPv4 avec les métriques. Un client VPN installe souvent une route pour le sous-réseau WSL2, et sa métrique décide si ce trafic sort par le tunnel ou reste local.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

Métrique de route ou fichier périmé

La première panne est le fichier périmé. Le résolveur a été écrit pour l’état de l’adaptateur au démarrage, et le tunnel a changé cet état. Son adresse stub est peut-être désormais injoignable, ou elle nomme un serveur qui ignore tout de la zone interne.

La seconde est un problème de routage. Quand le VPN ajoute une route couvrant le sous-réseau WSL2 avec une métrique inférieure à celle de la route de lien de l’hôte, les paquets adressés à la machine virtuelle utilitaire entrent dans le tunnel. Alors chaque service WSL2 expire, pas seulement le DNS.

Le test qui les distingue coûte une ligne. Si une adresse numérique comme un résolveur public répond encore au ping alors que les noms échouent, le chemin est intact et le DNS est le problème. C’est le cas où un changement de résolveur est justifié, et le cas où il ne l’est pas devient évident aussi. Si le test numérique échoue également, la machine virtuelle utilitaire a perdu sa route et aucun fichier de résolveur ne réparera cela.

Pour le cas de routage, retirez la métrique automatique de l’adaptateur du tunnel et donnez-lui un nombre au-dessus de la route de lien WSL2 :

Get-NetAdapter | Where-Object InterfaceDescription -Match VPN | Set-NetIPInterface -InterfaceMetric 5500
wsl.exe --shutdown

L’arrêt compte. Changer la métrique ne réécrit pas la machine virtuelle utilitaire en cours d’exécution, donc la distribution doit être reconstruite avant que le changement soit visible.

Prenez le fichier en main, délibérément

Si le routage est correct et que seuls les noms internes échouent, le résolveur est en cause et vous pouvez arrêter le générateur. C’est un changement délibéré avec un coût de maintenance, pas un contournement à appliquer à la légère.

Créez /etc/wsl.conf dans la distribution avec la section réseau qui désactive la génération, puis écrivez vous-même le fichier de résolveur, serveur d’entreprise d’abord et un serveur public de secours ensuite :

[network]
generateResolvConf = false

search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

L’ordre compte. Un résolveur public ne peut pas répondre à un nom interne, et le secours n’existe que pour les résolutions Internet. Une fois le fichier à vous, rien ne le régénère, donc un résolveur d’entreprise qui déménage devient une panne que vous devez remarquer vous-même.

Vérifiez les noms, puis les paquets

Vérifiez un nom interne et un nom public avec le résolveur du système, puis répétez l’opération qui a échoué. Les gestionnaires de paquets utilisent parfois leur propre résolveur, c’est pourquoi un getent qui fonctionne peut coexister avec une installation cassée.

Si vous automatisez la réécriture, rendez-la idempotente : sans tunnel, conservez le fichier existant au lieu d’écrire une liste de serveurs vide.

getent hosts intranet.corp.example
resolvectl status | head -20
getent hosts example.com

Une résolution interne qui fonctionne et une résolution publique qui fonctionne, depuis l’intérieur de la distribution, voilà le résultat qui mérite d’être noté. Une icône VPN verte sur l’hôte ne prouve ni l’une ni l’autre.