3 votes

Contrôleurs de domaine sur un NAT

Mon organisation est en train de mettre en place un nouveau réseau chez un hébergeur pour un très grand projet d'application. Étant donné que l'ensemble du système utilise Active Directory, nous prévoyons d'utiliser une paire de contrôleurs de domaine sur place qui se répliquent vers notre siège social via VPN. Ces DC serviraient également de sauvegarde pour notre système existant. Ainsi, en cas de perte totale de connexion ou d'alimentation au siège, le système distant pourrait rester opérationnel et permettre aux utilisateurs de se connecter.

Notre fournisseur d'hébergement a configuré 10.180.87.0/24 comme notre sous-réseau à utiliser avec eux. Mais comme nos IP internes sont 192.168.1.0/24 et qu'ils les utilisent déjà, ils nous demandent de faire un NAT vers 192.168.50.0/24. Cette partie n'était pas un gros problème et a été facilement configurée avec notre appareil pare-feu Watchguard.

Le premier signe de problème a été lorsque j'ai placé les deux serveurs sur le domaine et qu'ils n'ont pas pu se connecter ou trouver le domaine du tout. J'ai fini par mettre une adresse post-NAT de DOMAIN.LAN dans le fichier hosts des deux serveurs. Ils ont alors été en mesure de localiser et de rejoindre le domaine.

En faire des contrôleurs de domaine a cependant été un problème. Ils arrivent jusqu'au bout de l'installation et échouent ensuite avec une erreur lorsqu'ils essaient de configurer la réplication avec "RPC server is not available". Je sais que le domaine est correctement préparé. La semaine dernière, j'ai effectué tous les travaux préparatoires pour promouvoir un nouveau serveur en DC afin de remplacer une machine plus ancienne, et tout s'est bien passé.

Je soupçonne que le NAT est le problème et que les serveurs essaient de se configurer avec des adresses pré-NAT. Notre fournisseur veut que nous remappions notre schéma IP pour l'adapter à son réseau et je ne suis pas vraiment emballé par cette idée. Une option que nous envisageons est de créer un serveur et un réseau sur 192.168.50.0/24 et d'utiliser la réplication intersite pour passer de 10.180.87.0/24 à 192.168.50.0/24 puis à 192.168.1.0/24 (bien que la configuration du réseau soit probablement compliquée à mettre en place). Une DMZ est une autre option, mais je dois l'étudier de plus près avant d'essayer de demander à notre fournisseur de la mettre en place.

Quelqu'un a-t-il l'expérience d'une configuration similaire ou d'alternatives pour obtenir la configuration du DC sur une connexion à distance ?

10voto

Evan Anderson Points 140581

Vous ne voulez pas faire cela à travers le NAT. Vous pouvez élaborer un scénario cauchemardesque dans lequel vous gérez les enregistrements DNS pour les DC et enregistrez manuellement les adresses NAT "extérieures" dans le DNS. Avec les bonnes redirections de port à travers le NAT, vous pourriez probablement faire en sorte que tout fonctionne.

Le mieux serait d'utiliser un VPN site à site pour permettre aux DC d'avoir une communication transparente et pour leur permettre d'enregistrer leurs adresses attribuées aux NIC dans le DNS. L'IPSEC sur les adresses IP publiques est également une possibilité.

Au-delà des problèmes de communication réseau, je pense que vous avez un problème d'architecture de sécurité.

Je dirais que vous avez besoin de deux forêts AD. La forêt AD de votre "back-office" doit vraiment être séparée de la forêt AD qui exécute votre application. Vous pouvez certainement disposer d'un DC réplique de la forêt d'application au sein de votre siège social physique, mais je vous mets fortement en garde contre une confiance bidirectionnelle entre les forêts. Je ne voudrais certainement pas que les deux domaines fassent partie de la même forêt AD.

1voto

Shial Points 1017

J'ai réussi à le faire fonctionner en raison du manque de temps, mais il s'agit d'un piratage complet et je travaille à la reconstruction de l'ensemble du réseau dans les prochains mois pour en éliminer le besoin. Il s'avère que la recherche du domaine se fait via l'IP du serveur, mais que la réplication se fait par la recherche du GUID. L'exécution de repadmin /fix /s:DC1 vous donne un rapport où vous pouvez voir le GUID auquel il tente de se connecter, il se trouve également dans le DNS sous Forward Lookup Zones, domain.loc, _msdcs.

J'ai ajouté au fichier Hosts (c : \windows\system32\drivers\etc\hosts ) sur les nouveaux DCs à la fois l'adresse post-NAT du serveur et le GUID et j'ai pu les faire répliquer avec succès. C'est ce que j'ai dû ajouter pour que cela fonctionne pour chaque DC qui était de l'autre côté de la NAT :

192.168.50.3   DC1.domain.loc
192.168.50.3   b48aa2d2-5b6a-8723-ab6c-239b8a76c782323a._msdcs.domain.loc

Je ne suggère VRAIMENT pas à quiconque d'essayer de faire cela dans un système de production à long terme. Je suis en train de le documenter et de travailler à la réingénierie du réseau dans le cadre de notre plan global pour nous débarrasser de ce problème.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X