Моя организация находится в процессе создания новой сети у хостинг-провайдера для очень большого прикладного проекта. Поскольку вся система использует Active Directory, мы планируем использовать там пару контроллеров домена, которые будут реплицироваться в нашу штаб-квартиру через VPN. Эти контроллеры домена также будут служить в качестве резервной копии для нашей существующей системы, чтобы мы могли полностью потерять соединение или питание в нашей штаб-квартире, а удаленная система могла оставаться в рабочем состоянии и по-прежнему позволять людям входить в систему.
Наш хостинг-провайдер настроил 10.180.87.0/24 в качестве нашей подсети для использования с ними. Но поскольку наши внутренние IP-адреса 192.168.1.0/24, и они уже используются, они требуют от нас NAT на 192.168.50.0/24. Это не было большой проблемой, и ее легко настроить с помощью нашего брандмауэра Watchguard.
Первым признаком проблемы было то, что я поместил два сервера в домен, и они вообще не смогли подключиться или найти домен. В итоге я поместил адрес DOMAIN.LAN после NAT в файл hosts на обоих серверах. Затем они смогли найти домен и присоединиться к нему.
Однако сделать их контроллерами домена было проблемой. Они проходят весь процесс настройки и затем терпят неудачу с ошибкой, когда пытаются настроить всю репликацию с «RPC-сервер недоступен». Я знаю, что домен подготовлен правильно. На прошлой неделе я провел всю подготовительную работу по продвижению нового сервера в DC, чтобы заменить старую машину, которая прошла нормально.
Я подозреваю, что проблема в NAT, и серверы пытаются настроить себя с адресами до NAT. Наш провайдер хочет, чтобы мы изменили схему IP, чтобы она соответствовала его сети, и я не в восторге от этой идеи. Один из вариантов, который мы рассматриваем, - это создание сервера и сети на 192.168.50.0/24 и использование межсайтовой репликации для перехода с 10.180.87.0/24 на 192.168.50.0/24 на 192.168.1.0/24 (хотя, вероятно, это будет беспорядочная сеть. по конфигурации, чтобы выяснить.) Но я не совсем уверен, решит ли это проблему. Демилитаризованная зона - еще один вариант, но я должен изучить его подробнее, прежде чем я попытаюсь убедить нашего провайдера установить это.
Был ли у кого-нибудь опыт работы с подобной настройкой или альтернативами для настройки DC при удаленном подключении?
Вы не хотите делать это через NAT. Вы можете создать кошмарный сценарий, в котором вы управляете записями DNS для контроллеров домена и вручную регистрируете «внешние» адреса NAT в DNS. С правильным перенаправлением портов через NAT вы, вероятно, сможете заставить все это работать.
Лучше всего вам подойдет VPN типа "сеть-сеть", чтобы позволить контроллерам домена иметь прозрачную связь и позволить им регистрировать свои адреса, назначенные сетевым адаптерам, в DNS. IPSEC на общедоступных IP-адресах также возможен.
Однако, помимо проблем с сетевой связью, я думаю, у вас есть проблема с архитектурой безопасности.
Я бы сказал, что вам нужно два леса AD. Лес AD «бэк-офиса» действительно должен быть отделен от леса AD, в котором работает ваше приложение. Конечно, вы можете иметь реплику контроллера домена из леса приложений в физическом месте расположения штаб-квартиры, но я бы настоятельно предостерегал от двустороннего доверия между лесами. Я бы точно не хотел, чтобы оба домена входили в один лес AD.
Я заставил его работать из-за нехватки времени, но это полный взлом, и я работаю над восстановлением всей сети в следующие несколько месяцев, чтобы устранить необходимость в этом. Как оказалось, поиск домена осуществляется через IP-адрес сервера, а репликация - путем поиска GUID. Запуск repadmin / fix / s: DC1 дает вам отчет, в котором вы можете увидеть GUID, к которому он пытается подключиться, он также находится в DNS в разделе Forward Lookup Zones, domain.loc, _msdcs.
Я добавил в файл Hosts (c: \ windows \ system32 \ drivers \ etc \ hosts) на новых контроллерах домена как адрес сервера после NAT, так и GUID, и мне удалось добиться их успешной репликации. Вот что мне пришлось добавить, чтобы он работал для каждого DC, находящегося по другую сторону NAT:
192.168.50.3 DC1.domain.loc
192.168.50.3 b48aa2d2-5b6a-8723-ab6c-239b8a76c782323a._msdcs.domain.loc
Я ДЕЙСТВИТЕЛЬНО не предлагаю никому еще пытаться делать это в производственной системе в долгосрочной перспективе. Я документирую это и работаю над реинжинирингом сети в рамках нашего общего плана по избавлению от этого.