resolv.conf sous WSL 2 : le DNS meurt quand le VPN se connecte

La navigation dans la distribution fonctionne, et le premier nom d’hôte interne échoue à l’instant où le tunnel monte. Le réflexe est d’ajouter un résolveur public, ce qui rétablit Internet et rend le nom d’entreprise inaccessible pour le reste de la journée. Sous WSL 2, /etc/resolv.conf est une sortie générée et non une configuration, et c’est ce mécanisme qui mérite d’être compris. Le correctif n’est pas un meilleur résolveur, c’est la propriété du fichier.

Le fichier est généré, pas configuré

WSL 2 écrit le fichier au démarrage à partir des adaptateurs Windows qu’il voit à cet instant, et imprime en tête un commentaire qui le dit. Quand un client VPN ajoute ou réécrit ensuite un adaptateur, la distribution ne régénère pas forcément quoi que ce soit, et le fichier continue de décrire un réseau qui n’existe plus.

Un second mode de défaillance est plus discret : WSL peut ne copier les serveurs que de certains adaptateurs. Si l’adaptateur physique possède déjà un résolveur IPv6, les serveurs IPv4 fournis par l’adaptateur VPN peuvent être écartés au lieu d’être ajoutés, et le fichier paraît complet tout en omettant précisément celui qui répond aux noms internes.

Comparez la vue Windows et la vue Linux

Lisez les deux côtés avant de modifier. Dans la distribution, regardez ce que contient le fichier et s’il s’agit d’un fichier ordinaire ou d’un lien. Sous Windows, listez le résolveur de chaque adaptateur, y compris celui que le VPN a créé :

ls -l /etc/resolv.conf
cat /etc/resolv.conf

Get-DnsClientServerAddress -AddressFamily IPv4
Get-NetAdapter | Where-Object Status -eq 'Up'

Quand l’adaptateur VPN affiche les serveurs d’entreprise et que Linux affiche autre chose, le désaccord est dans la génération et non dans l’accessibilité. Comparez la liste des adaptateurs autant que les adresses, car un adaptateur manquant explique un serveur manquant. Cette distinction décide si vous réparez WSL ou un pare-feu, et les deux n’ont rien en commun.

Désactivez la génération et écrivez votre propre fichier

Un réglage documenté empêche WSL de réécrire le fichier, et il se trouve dans /etc/wsl.conf. Ajoutez une section réseau à ce fichier :

[network]
generateResolvConf = false

Puis arrêtez la distribution depuis Windows avec wsl --shutdown et redémarrez-la. Si le chemin est un lien symbolique et non un fichier ordinaire, supprimez le lien avant d’écrire votre propre contenu, car écrire à travers le lien peut recréer la cible générée au prochain démarrage. À partir de ce moment, le fichier vous appartient et rien ne le réécrit.

nameserver 172.28.4.10
nameserver 172.28.4.11
search site.corp.example
options timeout:1 attempts:2 rotate

Sans domaine de recherche, un nom d’hôte non qualifié est complété par la racine publique et revient comme aucun domaine de ce type. timeout empêche un premier serveur mort de bloquer chaque requête, attempts plafonne le nombre d’essais qu’une requête dépense, et rotate répartit les nouvelles tentatives au lieu de toujours commencer par le haut. Le compromis est que le fichier ne suit plus un VPN dont l’adresse de résolveur change entre les sessions.

Gérez un résolveur qui se déplace, puis vérifiez

Certains clients fournissent un résolveur propre à la session, si bien qu’un fichier statique casse à la connexion suivante. Deux approches sont défendables. Écrivez le fichier depuis un petit script chaque fois que l’adresse change, ou laissez la génération active et assurez-vous que l’adaptateur depuis lequel WSL copie porte le serveur d’entreprise. La seconde n’exige aucun crochet et échoue chaque fois que la génération saute l’adaptateur VPN ; les deux exigent encore de résoudre d’abord le conflit IPv6.

Windows applique aussi ses propres stratégies de noms, comme une liste de recherche de suffixes ou une stratégie de résolution pour des domaines précis, et copier les adresses des adaptateurs ne reproduit pas ces règles. Si un nom se résout sous Windows et non dans la distribution avec le même serveur, comparez le traitement des suffixes avant d’accuser le tunnel.

Testez avec un nom plutôt qu’avec un paquet : getent hosts sensor-access0.corp.example passe par la pile de résolution, alors qu’un ping peut réussir contre une adresse en cache ou littérale. Répétez ensuite après une déconnexion et une reconnexion, car un réglage qui fonctionne une fois et qui est régénéré à la reprise n’a jamais été corrigé. Sauvegardez le contenu précédent et notez quel composant possède le chemin sur cette machine, afin que le prochain changement commence avec des preuves.