Deux VPN, un seul résolveur : le dernier à écrire gagne

Deux clients VPN sont connectés, l’un pour le travail et l’autre pour un réseau de laboratoire, et les noms internes ne se résolvent que pour le client qui s’est connecté en dernier. Ce schéma ressemble à un bug dans l’un des clients. C’est généralement le résultat prévisible de deux programmes qui écrivent la même configuration de résolveur sans accord sur qui possède quel nom.

Le mythe : le VPN le plus récent possède le DNS

Il n’existe aucune règle générale selon laquelle la connexion la plus récente gagne. Ce qui se passe dépend du mécanisme de la plateforme et de la manière dont chaque client l’écrit. Un client qui remplace un fichier de résolveur produit un résultat ; un client qui ajoute un domaine par lien en produit un autre ; un client qui ne fait rien laisse l’état précédent intact.

Le comportement observé est donc une propriété des deux implémentations, et non une priorité documentée. Raisonner à partir du seul ordre de lancement sera parfois juste et parfois faux, d’une manière difficile à reproduire. Écrivez plutôt la correspondance. Une conception qui vit dans deux clients n’est pas une conception.

Associez les espaces de noms aux résolveurs

Listez les suffixes privés et le résolveur exigé par chaque réseau, puis décidez où doivent aller les noms publics. Cette liste est la conception. Sans elle, les clients décident par accident.

Une plateforme qui prend en charge le DNS par lien ou les domaines de routage peut exprimer la séparation délibérément : un domaine va vers un lien, un autre domaine vers l’autre, et tout le reste suit une valeur par défaut explicite. Deux scripts simples qui écrasent le même fichier ne peuvent pas préserver cette conception, car chacun croit posséder toute la configuration.

Sous Windows, la table de stratégie de résolution de noms peut diriger des suffixes vers des serveurs précis, et un client VPN peut y installer des règles. Vérifiez la stratégie plutôt que la liste des adaptateurs, car ce n’est pas la liste des adaptateurs qui résout le nom.

Gardez un chemin d’amorçage

Chaque client doit localiser son propre point de terminaison avant de pouvoir utiliser le service que ce point fournit. Si le nom d’hôte du point de terminaison ne peut être résolu que par le tunnel, et que le tunnel a besoin du nom d’hôte résolu, vous avez une dépendance circulaire qui apparaît comme un délai d’expiration de connexion. Gardez un chemin d’amorçage hors des deux tunnels. Il ne coûte rien jusqu’au jour où il sauve la connexion.

Regardez le chemin vers chaque résolveur, pas seulement le nom configuré pour lui. Un résolveur joignable uniquement par l’autre tunnel se comporte comme un résolveur absent, et le symptôme est un délai d’expiration plutôt qu’une erreur de routage.

Les adresses qui se chevauchent ne sont pas un problème de DNS

Deux réseaux privés qui utilisent la même plage d’adresses ne se corrigent pas avec l’ordre DNS. Si les deux tunnels revendiquent 10.0.0.0/8, un nom qui se résout correctement pointe toujours vers une adresse que l’hôte ne peut pas router vers le bon tunnel. Cela exige une solution au niveau de l’adresse, comme des plages distinctes, un espace de noms ou de la traduction, et non un autre réglage de résolveur. Décider cela tôt évite un long détour par une configuration DNS qui n’aurait jamais fonctionné.

Comparez les attributions d’adresses des deux tunnels avant d’accuser la résolution de noms. Lorsque les deux pairs poussent le même préfixe, l’hôte ne conserve qu’une route pour celui-ci, et un nom résolu par le second tunnel aboutit quand même sur une adresse que possède le premier tunnel. Des plages distinctes, un espace de noms par réseau ou de la traduction sont les correctifs ; après la connexion de chaque client, confirmez que la table de routage montre le chemin voulu.

Prouvez-le avec de vraies applications

Choisissez deux hôtes qui n’existent que dans leur propre espace de noms et un nom public, puis résolvez chacun via le client qui devrait le posséder. Une réponse correcte du résolveur attendu ne prouve pas que l’application atteint l’hôte, car la route vers cette adresse peut encore échouer. Faites suivre chaque recherche d’un test de connexion depuis le programme que l’utilisateur exécutera réellement.

Un client doté de sa propre option DNS chiffré peut contourner la stratégie que vous venez de vérifier, alors contrôlez ce réglage dans le cadre de la revue. Reconnectez ensuite les deux clients dans l’ordre pris en charge par le fournisseur et répétez les recherches ; si les réponses s’inversent lorsque l’ordre change, un écrivain concurrent possède encore une partie de la configuration. Déterminez quel composant installe la règle - le client, le profil du système d’exploitation ou un agent de gestion - avant de modifier quoi que ce soit. Notez l’ordre et les propriétaires pour que la personne suivante n’ait pas à les redécouvrir.