Pourquoi un nom de serveur se résout en son adresse VPN après l’accès téléphonique

Un serveur de fichiers de bureau répond sur son adresse LAN toute la matinée, puis un utilisateur distant se connecte par téléphone et le nom commence à se résoudre en une adresse de tunnel à la place. Rien n’a été modifié dans le DNS à la main, et c’est l’indice : l’enregistrement a été publié par la machine elle-même. Trois conditions décident si vous réparez l’enregistreur, l’enregistrement ou la vue du client, et se tromper d’ordre signifie que l’enregistrement revient après la connexion suivante.

Deux adresses, un nom, trois conditions

Un serveur Windows multiréseau peut avoir une adresse LAN, une ou plusieurs adresses d’accès téléphonique et parfois une seconde carte réseau. Chaque interface peut enregistrer ses propres adresses dans le DNS si l’enregistrement dynamique lui est permis. Quand l’adaptateur PPP s’enregistre, le même nom d’hôte gagne une adresse que seul le pair du tunnel peut atteindre, et les clients du LAN la reçoivent comme une réponse valide.

Trois conditions décident de la réparation. Premièrement, l’adresse supplémentaire est-elle joignable depuis les clients qui la reçoivent ? Deuxièmement, un consommateur dépend-il encore de cet enregistrement ? Troisièmement, l’enregistrement est-il dynamique et donc susceptible de revenir, ou statique et donc une entrée délibérée ?

Répondez à cela avant de toucher à quoi que ce soit. Si l’adresse n’est pas joignable depuis le réseau qui interroge, aucun nettoyage du cache client ne le corrige durablement. Si quelque chose en dépend, comme un chemin de gestion utilisé par les pairs du tunnel eux-mêmes, le retirer casse ce chemin à la place. Et un enregistrement dynamique supprimé sans traiter son éditeur réapparaîtra au prochain événement d’enregistrement.

Lisez l’enregistrement avant de changer l’enregistreur

Interrogez le nom complet qualifié exact depuis le réseau qui signale le problème, et comparez les réponses avec les interfaces et les écouteurs réels du serveur. Un seul nom qui renvoie plusieurs adresses est normal ; la question est de savoir si chacune est utilisable par le client qui la reçoit.

dig +short files.corp.example A
dig @10.20.0.10 +short files.corp.example A
Resolve-DnsName files.corp.example -Server 10.20.0.10 -Type A

La première requête utilise le résolveur local, la deuxième interroge directement un serveur DNS précis et la troisième fait de même depuis PowerShell sous Windows. Les comparer sépare un cache client obsolète d’une réponse faisant autorité. Si la requête directe renvoie déjà l’adresse du tunnel, le problème vient des données publiées et non du cache local.

Notez l’horodatage de l’enregistrement et si la console DNS l’affiche comme dynamique. Ce seul attribut vous dit laquelle des trois conditions ci-dessus s’applique, et c’est la différence entre un nettoyage de cinq minutes et une réparation qui dure.

Réparez l’éditeur ou l’enregistrement, mais sachez lequel

Si l’enregistrement est dynamique et indésirable, la correction durable est d’empêcher cette interface de s’enregistrer. Windows expose des paramètres d’enregistrement par interface, et le service client DNS republie à la connexion ou au changement d’adresse suivant. Désactiver l’enregistrement pour l’adaptateur d’accès téléphonique laisse intact l’enregistrement de l’adaptateur LAN, ce qui est généralement ce que vous voulez.

Méfiez-vous des commutateurs qui concernent toute la machine. Un réglage global qui désactive la mise à jour dynamique affecte chaque interface de cet hôte, y compris celle dont l’enregistrement est utilisé par d’autres clients. Sur un contrôleur de domaine, la même prudence s’applique avec plus de force, car l’hôte peut aussi posséder des enregistrements d’emplacement de service dont les clients dépendent pour l’ouverture de session.

Si l’enregistrement est statique, il a été placé là volontairement et la conversation est avec celui qui l’a placé. Supprimer un enregistrement statique parce qu’il est gênant aujourd’hui retire la seule preuve de son existence. Dans les deux cas, ne supprimez la réponse obsolète qu’après avoir traité l’éditeur, et notez ce que vous avez changé pour que la personne suivante puisse distinguer une entrée délibérée d’un accident.

Vérifiez depuis le réseau client qui a échoué

La vérification appartient au réseau qui a signalé le symptôme, pas au serveur. Videz le cache du résolveur client par son mécanisme pris en charge, puis répétez la recherche d’origine et la connexion d’origine au service par nom.

ipconfig /flushdns
ipconfig /displaydns | findstr /i files.corp.example

La première commande vide le cache du résolveur Windows, et la seconde montre si le nom est de nouveau en cache et quelle adresse a été stockée. Une connexion réussie du serveur à lui-même ne prouve rien pour un client du LAN, et supprimer une route vers l’adresse indésirable ne corrige pas ce que publie le DNS.

Enfin, répétez l’événement qui introduisait auparavant l’adresse : reconnectez le client VPN ou renouvelez la session d’accès téléphonique. Vérifiez de nouveau le nom publié après ce changement de cycle de vie. Une réparation qui ne tient que jusqu’à la connexion suivante était un nettoyage, pas une réparation, et savoir laquelle des deux vous avez effectuée fait la différence entre fermer le ticket et le rouvrir la semaine prochaine.