Fuite DNS avec un VPN sous Windows : pourquoi la métrique l’emporte sur la route

Une requête quitte la machine et atteint le routeur du domicile alors que chaque paquet est tunnellisé. La conclusion naturelle est une route manquante, et la route est généralement correcte. Windows peut choisir quel résolveur d’interface interroger selon la métrique, et un adaptateur de tunnel perd souvent cette comparaison face à l’interface sans fil.

Deux explications pour une fuite

L’explication par les routes dit qu’une partie du trafic s’échappe du tunnel, donc la route par défaut ou la liste du tunnel partagé doit être fausse. Cette explication se teste avec une seule commande, et lorsque la route par défaut pointe dans le tunnel, l’affaire est close. Vérifiez-la d’abord parce que c’est peu coûteux, puis mettez-la de côté quand elle revient propre.

L’explication par le classement dit que le trafic est entièrement tunnellisé et que la requête part quand même vers un autre résolveur. Windows traite le choix du résolveur comme une propriété par interface avec un ordre, si bien qu’un adaptateur physique doté d’une meilleure métrique peut fournir le DNS d’un nom alors même que les paquets de l’adresse résolue passent par le tunnel. Les deux explications produisent le même symptôme sur une page de test de fuite, c’est pourquoi le test n’est pas le diagnostic. Une seule se répare en modifiant des routes.

Comparez métriques et résolveurs ensemble

Relevez les interfaces, leurs métriques et leurs serveurs configurés pendant que le tunnel est actif. Lisez-les comme un tableau et non comme deux listes séparées, car la question est de savoir quel résolveur arrive en premier, pas quels résolveurs existent.

Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Select-Object InterfaceIndex, InterfaceAlias, InterfaceMetric
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, ServerAddresses

Si l’adaptateur de tunnel porte un numéro plus élevé que l’adaptateur physique, son résolveur n’est pas préféré, et un nom interne ira vers ce que propose le côté physique. Ce routeur peut répondre depuis le cache, transmettre la requête ou la refuser, et aucune de ces issues n’est la conception que vous vouliez. Le classement est une préférence, il perd donc en silence au lieu de lever une erreur.

Un adaptateur de tunnel sans aucun résolveur configuré est une variante tout aussi courante. Le client monte l’interface sans pousser de DNS, donc la question du classement ne se pose même pas.

Remontez le tunnel et vérifiez à nouveau

Donnez à l’interface du tunnel la métrique la plus basse, ou augmentez la valeur de l’adaptateur physique, dans un shell élevé. Les deux sont des réglages par interface et les deux sont réversibles, ce qui compte quand vous modifiez une machine devant laquelle vous n’êtes peut-être pas.

Set-NetIPInterface -InterfaceIndex 27 -InterfaceMetric 1
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric

Le changement apparaît immédiatement, et le client DNS ainsi que les autres consommateurs mettent en cache le choix déjà fait. Reconnectez le tunnel, ou redémarrez, avant de tirer quoi que ce soit d’un résultat de requête. Un test lancé trop tôt reproduira l’ancien comportement et ressemblera à un correctif raté.

Interrogez ensuite un nom interne et un nom public et vérifiez quel serveur a répondu. La référence sur les métriques automatiques de Microsoft explique pourquoi la valeur la plus basse est préférée et comment l’attribution automatique est calculée.

Faites-le survivre à une reconnexion

Une métrique manuelle sur un adaptateur recréé à chaque connexion est un réglage qui disparaît. Si le client reconstruit l’interface, la substitution a besoin d’un script après connexion, d’une stratégie ou d’une configuration client qui possède le DNS pendant la connexion.

Les serveurs configurés statiquement sur l’adaptateur physique ont le même problème de durabilité à l’envers. Ils continuent de répondre pour cette interface jusqu’à leur suppression, et le DHCP les repeuplera au prochain bail, donc les supprimer est une mesure et non une conception. La conception durable est une stratégie de résolution de noms pour l’espace de noms interne, ou un client qui prend possession du DNS le temps de la connexion. Quoi qu’il en soit, relevez la liste des résolveurs avant et après une reconnexion, restaurez la métrique d’origine quand vous avez fini de tester et confirmez que le comportement antérieur est revenu.