Pourquoi WSL perd-il le nom d’hôte de travail lorsque le VPN se connecte ?

Windows résout l’hôte interne sans se plaindre, et le même nom échoue dans WSL à l’instant où le tunnel monte. La réparation habituelle consiste à écrire un résolveur public dans la distribution, ce qui rétablit la navigation ordinaire et rend le nom d’hôte de travail impossible à résoudre. Cela échange une panne contre une autre et masque la couche qui a réellement cassé. Avant d’ajouter ou de supprimer une ligne de résolveur, déterminez laquelle des trois couches échoue.

Écartez d’abord une panne de routage

Interrogez le même nom pleinement qualifié des deux côtés, pas deux noms qui se ressemblent. Un succès sous Windows et un échec dans WSL pour la même chaîne est la signature de deux chemins de résolution, et peu d’autres choses produisent ce schéma aussi proprement. Si WSL ne peut pas non plus joindre le service à son adresse numérique connue, un problème de routage ou de filtrage est également présent. Dans ce cas, le travail sur DNS ne le révélera pas, et l’après-midi part dans la mauvaise couche.

Trois symptômes couvrent la plupart de ces cas, et chacun pointe ailleurs. Lisez la ligne correspondante avant d’ouvrir un fichier de configuration :

La ligne du milieu est celle que les gens lisent mal, parce que le changement qui l’a cassée a été fait des semaines plus tôt et semblait réussi à l’époque. La troisième ligne est celle que les gens diagnostiquent mal, parce qu’un nom qui se résout ressemble à la preuve que le réseau est sain. Les deux lignes vous renvoient vers une section différente ci-dessous.

Le tunnel DNS a un plancher de version

Microsoft documente un mode réseau de WSL qui tunnelise les requêtes DNS vers le résolveur Windows via un canal de virtualisation. Sur les builds Windows 11 pris en charge, il est activé par défaut, ce qui explique que deux machines du même réseau d’entreprise se comportent différemment. La variable est le numéro de build, pas la politique d’entreprise.

Le guide réseau de WSL décrit ce mode et les versions qui le prennent en charge. La fonction compte parce que la politique DNS d’entreprise vit généralement dans le résolveur Windows, et une distribution qui hérite du chemin Windows hérite de la politique avec lui. Une distribution qui interroge un résolveur public n’a aucune route vers un nom privé, si soignée que paraisse sa propre configuration. Ce mécanisme explique tout le symptôme et explique pourquoi le contournement par résolveur public échoue.

Lisez le numéro de build avant de modifier quoi que ce soit. Un réglage copié d’une installation plus récente ne prouve pas qu’une plus ancienne l’implémente. Notez le numéro de build à côté du changement, car la différence entre deux machines est presque toujours une version et non une politique.

Les anciens écrasements survivent au problème qu’ils ont résolu

Les recettes plus anciennes désactivaient les fichiers de résolveur générés, codaient en dur un serveur de noms ou verrouillaient le fichier avec un attribut immuable. Ces changements restent en place longtemps après la disparition du problème de connectivité qui les a motivés, et c’est généralement pour cela qu’un réglage plus récent semble ne rien faire. Ils survivent aussi à une réinstallation de la distribution sous la forme d’un profil de shell qui réécrit le fichier à chaque connexion. Ce dernier est le plus difficile à trouver, car il est invisible depuis le fichier que tout le monde inspecte.

Cherchez un fichier de résolveur écrit à la main, un attribut immuable dessus et un script de démarrage qui le réécrit. Vérifiez l’indicateur immuable avant de modifier, car une écriture dans un fichier verrouillé échoue d’une manière qui se lit comme un problème de permissions. Vérifiez ensuite le profil de shell, car un script y restaure l’ancien contenu en quelques secondes après votre correction.

Supprimer un écrasement a des conséquences, alors notez ce que vous avez supprimé et pourquoi. Une distribution qui a réellement besoin d’un résolveur statique pour un autre usage cassera lorsque le fichier généré reviendra.

Deux fichiers, deux rôles différents

Les deux fichiers de configuration vivent à des endroits différents et contrôlent des choses différentes, et les confondre produit des modifications appliquées à la mauvaise couche. Le fichier côté Windows définit des propriétés de la machine virtuelle, tandis que le fichier côté distribution définit comment cette distribution construit sa propre configuration de résolveur. Aucun ne remplace l’autre, c’est pourquoi les deux doivent s’accorder.

Pour une installation qui prend en charge la fonction, le fragment côté Windows est court. C’est tout le changement de ce côté :

[wsl2]
dnsTunneling=true

Ce fragment va dans le profil utilisateur Windows et s’applique à la machine virtuelle plutôt qu’à une seule distribution. Le tunnel exige aussi que la distribution n’ait pas désactivé la génération de résolveur, donc le fichier côté distribution doit laisser ce comportement tranquille. Changez l’un sans l’autre et le mode ne fait rien en silence, ce qui est la façon la plus courante dont cette réparation est signalée comme cassée. Vérifiez les deux fichiers dans la même session, car deux modifications faites à des semaines d’intervalle sont deux modifications que personne ne peut attribuer.

Redémarrez, puis interrogez des deux côtés

Ces réglages sont lus au démarrage de l’environnement, donc un nouveau shell dans une distribution en cours d’exécution ne les rechargera pas. Arrêtez l’environnement au lieu de redémarrer le shell, et enregistrez d’abord tout travail en cours car chaque distribution s’arrête avec lui. Cette seule omission explique la plupart des rapports de changement sans effet.

Posez ensuite la même question des deux côtés. La sortie indique aussi sur quel résolveur la distribution a réellement abouti :

wsl.exe --shutdown
wsl.exe -e sh -c 'cat /etc/resolv.conf'
wsl.exe -e sh -c 'getent hosts files.corp.example'
wsl.exe -e powershell -Command 'Resolve-DnsName files.corp.example'

La première commande termine l’environnement, la deuxième montre quel résolveur la distribution utilise maintenant, et les deux dernières posent la même question à chaque côté. Comparez les réponses plutôt que l’état du réglage. Une requête qui échoue encore après un redémarrage propre avec les deux fichiers corrects pointe vers la politique de résolveur d’entreprise, et cette conversation a un autre propriétaire.