Trois sources peuvent publier l’adresse VPN d’un contrôleur de domaine dans le DNS

Trois composants différents d’un contrôleur de domaine multihébergé peuvent inscrire la même adresse VPN dans le DNS, et ils échouent indépendamment. Comparez ce que chacun publie au lieu de faire confiance à la case à cocher de la carte réseau, qui n’en contrôle qu’un seul. Le symptôme est identique dans tous les cas : un client résout le nom, reçoit l’adresse du tunnel et ne peut pas joindre le contrôleur de domaine. C’est l’auteur de la publication qui décide comment l’arrêter.

Un paramètre, un service et un rôle ; trois sources, trois interrupteurs.

Commencez par l’enregistrement, pas par la case à cocher

Interrogez le nom complet du serveur concerné via le serveur DNS que les clients utilisent réellement, et notez toutes les adresses renvoyées. Comparez chaque adresse renvoyée aux interfaces LAN et tunnel réelles du serveur, ainsi qu’aux réseaux où se trouvent les clients. Une adresse peut être parfaitement valide en local et injoignable pour les clients qui comptent. Les échecs d’authentification intermittents sont un symptôme courant, car les clients reçoivent ou choisissent des adresses différentes selon les tentatives.

Que la machine résolve correctement son propre nom ne prouve presque rien. Le test qui compte se fait depuis les réseaux des clients.

La carte réseau n’est qu’une source

Les propriétés TCP/IP de la carte réseau comportent une case pour enregistrer l’adresse de cette connexion, et la décocher réduit au silence exactement une source. Elle n’arrête pas les autres, ce qui explique pourquoi l’enregistrement peut réapparaître après un redémarrage. Si le contrôleur de domaine exécute aussi le service DNS, ce service a sa propre configuration d’écoute et ses propres enregistrements de serveur de noms. Les recommandations Microsoft pour les environnements multihébergés traitent le comportement de l’interface, le service DNS et Netlogon comme des sources distinctes et pertinentes.

Trois interrupteurs, trois responsables, et un seul d’entre eux se trouve sur la page de propriétés de la carte réseau.

Le service DNS a ses propres adresses

Un serveur DNS auquel on demande d’écouter sur une adresse VPN continue de la publier dans ses propres enregistrements, quoi qu’affirme la case à cocher de la carte réseau. Alignez les adresses d’écoute du service sur les interfaces prévues et vérifiez en même temps les entrées de serveur de noms de la zone. Changer les écoutes peut interrompre des clients qui utilisent en ce moment une adresse que vous retirez, alors établissez d’abord qui dépend de chacune. Supprimer une écoute simplement parce qu’il s’agit d’une adresse VPN peut couper les clients que vous vouliez aider.

Netlogon, et la découverte de contrôleurs de domaine en général, enregistrent aussi des adresses dans le cadre de leurs propres fonctions. Ne supprimez pas les enregistrements à l’échelle du domaine et ne copiez pas un ancien contournement d’enregistrement pour l’accès à distance sans vérifier qu’il s’applique à votre version et à votre rôle.

La propriété avant le nettoyage

Corrigez la source avant de retirer l’enregistrement, sinon le prochain événement d’enregistrement le remettra et l’exercice se répétera. Supprimez les entrées obsolètes via le processus du propriétaire du DNS et tenez compte du cache et du vieillissement. Vérifiez depuis les réseaux des clients, en couvrant la découverte du domaine et l’application qui a échoué au départ, puis déclenchez le même événement VPN qui a produit l’adresse la première fois.

Ce que vous voulez à la fin, c’est un ensemble connu d’adresses et d’écoutes publiées, l’enregistrement de domaine quotidien continuant de faire son travail. Une machine dont le nom se résout correctement juste après un nettoyage manuel n’est pas cela.

Notez quelle source était responsable, quels enregistrements ont changé et quels clients ont été testés. Le prochain serveur multihébergé aura les mêmes trois suspects.