Mappage de site AD ou épinglage d’un contrôleur de domaine pour les clients VPN

Les clients d’accès distant d’un pool VPN peuvent finir par parler à un contrôleur de domaine à l’autre bout du monde, et cela se corrige de deux façons : décrire le pool comme un sous-réseau Active Directory rattaché au site qui détient les bons contrôleurs, ou épingler le client ou l’application à un contrôleur précis. La première est une déclaration de topologie sur laquelle DC Locator peut agir. La seconde est une dérogation par application qui ignore entièrement la topologie. Elles coûtent des choses différentes, et se jeter aujourd hui sur la plus rapide est précisément comment une équipe annuaire finit par maintenir les deux.

Ce que chaque approche change réellement

Un objet de sous-réseau est un enregistrement d’annuaire qui indique à quel site appartient une plage d’adresses. Avec le module Active Directory et un site existant, l’opération est assez petite pour être prévisualisée :

New-ADReplicationSubnet -Name "10.90.0.0/24" -Site "Remote-Access-Hub" -WhatIf
Get-ADReplicationSubnet -Filter * | Select-Object Name,Site

-WhatIf prévisualise l’écriture dans l’annuaire. Il ne crée pas l’objet et ne vérifie pas si un client de cette plage peut atteindre quoi que ce soit, et c’est justement la partie que les gens attendent. DC Locator lit le modèle de sites lorsqu il résout les enregistrements de service, donc un objet de sous-réseau exact change ce qui est proposé au client.

L’épinglage agit à un autre niveau. Un nom de contrôleur figé dans la configuration d’une application, une chaîne LDAP contenant un hôte, ou une valeur de registre qui nomme un serveur préféré retirent tous la découverte du chemin. L’application parle à ce contrôleur jusqu’à ce que quelqu’un change le réglage, et le basculement est ce que cette application implémente.

Où le mappage de sous-réseau gagne

Mapper le pool décrit l’emplacement réseau une fois, pour chaque client qui utilise DC Locator. Quand le pool passe d’un /24 à trois, le modèle change dans deux ou trois objets au lieu d’un inventaire d’applications. C’est tout l’avantage, et il est grand quand la population de clients n’est pas sous votre contrôle.

Le piège est que l’objet doit correspondre à l’adresse que le contrôleur voit réellement. Si la passerelle VPN traduit chaque client vers une adresse de concentrateur, ajouter le pool non traduit décrit un emplacement réseau qu’aucun contrôleur n’observe jamais. Décidez tôt si la conception conserve l’adresse source du client, et sinon, mappez la plage traduite au lieu du pool configuré sur le serveur VPN.

Une seconde limite : le modèle de sites est une préférence et une déclaration de topologie. Il ne rend pas un contrôleur joignable et ne donne rien à un utilisateur. Les routes et la politique de pare-feu font la joignabilité ; la politique de comptes fait l’autorisation.

Où l’épinglage gagne

L’épinglage est la bonne réponse quand la découverte ne peut pas fonctionner : une application ancienne qui résout un contrôleur par un nom que vous ne pouvez pas changer, un filtre qui autorise exactement une adresse de contrôleur, ou un ensemble fixe de serveurs où le contrôleur fait partie de la conception de l’application. Dans ces cas, l’épingle est la documentation d’une contrainte réelle, pas un raccourci.

Son coût est l’inverse du mappage. Un nom épinglé ne suit pas le pool, ne bascule pas en cas d’échec sauf si l’application sait le faire, et ne survit pas au renommage ou au décommissionnement d’un contrôleur sans une revue d’inventaire. Il masque aussi les problèmes de topologie, car chaque client épinglé paraît sain pendant que le modèle de sites pourrit en silence.

Remplacer les enregistrements d’adresse ordinaires du domaine par un seul serveur préféré n’est pas une troisième option. Cela casse tout consommateur qui attend le jeu de découverte normal, et cela ne contrôle toujours pas comment un client conscient de l’annuaire choisit un site.

Choisir selon trois conditions

Posez-les dans cet ordre et la décision se prend souvent d’elle-même. D’abord, l’application utilise-t-elle DC Locator, ou porte-t-elle déjà une adresse de contrôleur ? Ensuite, le contrôleur voit-il l’adresse du pool, ou une adresse traduite ? Enfin, à quelle fréquence le pool change-t-il par rapport au nombre d’endroits qu’une épingle devrait mettre à jour ?

Des applications conscientes de l’annuaire, plus un routage qui préserve la source, plus un pool qui change : mappez le sous-réseau. Une application qui ne peut pas découvrir, ou un filtre qui admet une adresse : épinglez-la, et écrivez pourquoi. Tout le reste est un cas de réparation de la topologie plutôt que d’ajout d’une dérogation supplémentaire.

Vérifier depuis le client VPN et garder les contrats séparés

Testez depuis le chemin distant réel, pas depuis un poste LAN déjà installé sur le site. Seule compte la vue du client lui-même :

nltest /dsgetsite
nltest /dsgetdc:corp.example.com /force
echo %LOGONSERVER%

Si le site rapporté est celui que vous avez mappé, l’objet correspond. Si le client ne rapporte aucun site, l’adresse qu’il présente ne tombe dans aucun objet de sous-réseau, ce qui signifie généralement une traduction ou un préfixe obsolète. Vérifiez ensuite que le contrôleur choisi est bien celui que vous visiez avant de conclure que le mappage a échoué, car les clients mettent en cache les résultats de découverte et le basculement peut légitimement choisir un autre contrôleur.

Gardez les trois contrats dans un seul document : le pool et ses objets de sous-réseau, les contrôleurs joignables depuis le chemin VPN, et la politique qui décide ce qu’un utilisateur connecté peut faire. Un site n’est pas une règle de pare-feu et pas une frontière de confinement, et le prochain changement de pool détachera silencieusement les utilisateurs distants du modèle réseau de l’annuaire si le mappage, les routes et les alternatives documentées ne bougent pas ensemble.