Меню Рубрики

Установка двух контроллеров домена

Установка и настройка второго контроллера домена.

1. На первом контроллере домена открываем сетевые настройки первого сервера. Для этого в поле поиска набираем ncpa.cpl. Далее выбираем нужный сетевой интерфейс, правый клик — «Свойства — IP версии 4(TCP/IPv4). — Свойства». В поле альтернативный интерфейс, вписываем IP-адрес добавочного контроллера домена (в данном случае 192.168.100.6).

2. Затем переходим на второй сервер и задаём имя будущему серверу: «Этот компьютер — Свойства — Изменить параметры — Изменить». В поле «Имя компьютера» задаём имя серверу, далее «ОК». Потребуется перезагрузка компьютера, соглашаемся.

3. После перезагрузки переходим к настройке сетевого интерфейса. Для этого в поле поиск пишем ncpa.cpl. Выбираем нужный интерфейс, правый клик — «Свойства — IP версии 4(TCP/IPv4). — Свойства». В открывшемся окне заполняем поля:

  • IP-адрес: IP-адрес сервера (например, 192.168.100.6)
  • Маска подсети: например, 255.255.255.0 (маска 24 бит)
  • Основной шлюз: например, 192.168.100.1
  • Предпочитаемый DNS-сервер: IP-адрес первого сервера (например, 192.168.100.5)
  • Альтернативный DNS-сервер: IP-адрес второго сервера (например, 192.168.100.6)

4. Добавляем в домен новый сервер. Для этого выбираем «Этот компьютер — Свойства — Изменить параметры — Изменить». Ставим чекбокс «Является членом домена» и вписываем имя домена. Затем «ОК».

5. В диалоге «Изменение имени компьютера или домена» вводим имя пользователя домена с административными правами (пользователь должен иметь возможность добавлять компьютеры в домен), далее «ОК».

6. При успешной операции появится надпись «Добро пожаловать в домен. «. Нажимаем «ОК».

7. После перезагрузки компьютера в окне «Просмотр основных сведений о вашем компьютере» можно проверить напротив «Полное имя», что компьютер вошел в состав домена.

8. На этом подготовительный этап закончен, пора устанавливать необходимые роли на сервер. Для этого открываем «Диспетчер серверов» — «Добавить роли и компоненты». Необходимо установить DNS-сервер, Доменные службы Active Directory, DHCP-сервер.

9. Читаем информацию в окне «Перед началом работы», нажимаем «Далее». В следующем окне «Выбор типа установки» оставляем чекбокс «Установка ролей или компонентов» по умолчанию, снова «Далее». Выбираем наш сервер из пула серверов, затем «Далее».

10. В окне «Выбор ролей сервера» выбираем DNS-сервер, Доменные службы Active Directory, DHCP-сервер. При добавлении роли будет появляться предупреждение, например «Добавить компоненты, необходимые для DHCP-сервер». Нажимаем «Добавить компоненты». После выбора нужных ролей нажимаем «Далее».

11. В новом окне «Выбор компонентов» игнорируем «Выберите один или несколько компонентов для установки на этом сервере», нажимаем Далее. В следующем окне «DHCP-сервер» читаем на что обратить внимание при установке DHCP-сервера, затем «Далее». В новом окне «Подтверждение установки» проверяем выбранные роли, нажимаем «Установить».

12. Появится окно с ходом установки выбранных компонентов. Данное окно можно закрыть, оно на процесс установки уже не влияет.

13. После того, как установятся выбранные компоненты, в «Диспетчер серверов» нажимаем значок предупреждения в виде восклицательного знака, выбираем «Повысить роль этого сервера до уровня контроллера домена».

14. Появится «Мастер настройки доменных служб Active Directory». В окне «Конфигурация развертывания» оставляем по умолчанию чекбокс «Добавить контроллер домена в существующий домен», проверяем название домена в поле «Домен». Напротив поля (текущий пользователь) нажимаем кнопку «Изменить».

15. Вводим логин и пароль пользователя в домене с административными правами. Нажимаем «ОК». Затем «Далее».

16. В окне «Параметры контроллера домена» вводим парль для режима восстановления служб каталогов (DSRM), снова «Далее».

17. В окне «Параметры DNS» игнорируем предупреждение о том, что делегирование для этого DNS-сервера невозможно создать, поскольку полномочная родительская зона не найдена», просто жмем «Далее».

18. В окне «Дополнительные параметры» источник репликации оставляем «Любой контроллер домена», снова «Далее».

19. Расположение базы данных AD DS, файлов журналов и папки SYSVOL оставляем по умолчанию, нажимаем «Далее».

20. Просматриваем параметры, настроенные в «Мастер настройки доменных служб Active Directory», затем «Далее».

21. В окне «Проверка предварительных требований» проверяем, что появился зеленый чекбокс. Таким образом все проверки готовности к установке выполнены успешно. Нажимаем «Установить».

22. В следующем окне читаем, что «Этот сервер успешно настроен как контроллер домена». Читаем предупреждения, нажимаем «Закрыть».

23. Пришло время проверить работоспособность Доменных служб Active Directory и DNS-сервера. Для этого открываем «Диспетчер серверов».

24. Выбираем «Средства» — «Пользователи и компьютеры Active Directory».

25. Открываем наш домен и раскрываем подразделение «Domain Controllers». В окне напротив проверяем наличие второго сервера как контроллера домена.

26. Далее в «Диспетчер серверов» выбираем «Средства» — «DNS».

27. Проверяем наличие IP-адреса второго сервера в зоне прямого и в зоне обратного просмотра.

28. Затем выбираем «Active Directory — сайты и службы».

29. Раскрываем дерево «Active Directory — сайты». Проверяем наличие второго контроллера домена напротив «Servers».

30. Пришло время настроить DHCP-сервер. Для этого на втором сервере выбираем в «Диспетчер серверов» — «Средства» — «DHCP».

31. Выбираем добавочный сервер, правой клавишей мыши — «Добавить или удалить привязки».

32. Проверяем настройку сетевого интерфейса, через который будут обслуживать DHCP-клиенты на втором сервере.

33. Объединяем два DHCP-сервера. Конфигурация высокой доступности, режим балансировка высокой нагрузки. Распределяем нагрузку на сервера 50×50. Для настройки на первом сервере, где установлен и настроен DHCP-сервер, выбираем «Диспетчер серверов» — «Средства» — «DHCP».

34. Правый клик на созданную в DHCP-сервере область, далее «Настройка отработки отказа. «.

35. Появится мастер «Настройка отработки отказа», затем «Далее».

36. Указываем сервер-партнер для отработки отказа. Для этого в поле «Сервер партнер» с помощью кнопки «Добавить сервер» добавляем второй (дополнительный) сервер, на котором развернута роль DHCP-сервер. Затем нажимаем «Далее».

37. В поле «Общий секрет» вписываем пароль. Остальные настройки можно оставить по умолчанию, в том числе процент распределения нагрузки Локальный сервер — Сервер партнер — 50% на 50%. Снова «Далее».

38. Проверяем параметры настройки отработки отказа между первым сервером и дополнительным сервером. Нажимаем «Готово».

39. Смотрим в ходе настройки отработки отказа, чтобы все было «Успешно» и закрываем мастер.

40. Открываем второй сервер. «Диспетчер серверов» — «Средства» — «Авторизовать».

41. Проверяем «Пул адресов». Будет произведена синхронизация DHCP-серверов.

На этом процесс установки и настройки Active Directory, DHCP, DNS закончен. Посмотреть, что и как делать, можно здесь:

источник

Настройка контроллеров домена в разных подсетях

У меня возникла необходимость развернуть службу Active Directory в территориально разделенных местах, сети которых объединены с помощью vpn. На первый взгляд задача кажется простой, но лично я раньше подобными вещами не занимался и при беглом поиске не смог найти какую-то единую картину или план действий в таком случае. Пришлось собирать информацию из разных источников и самому разбираться с настройками.

Из этой статьи вы узнаете:

Планирование установки Active Directory в разных подсетях

Итак, у нас имеется две подсети 10.1.3.0/24 и 10.1.4.0/24, в каждой из которых некоторое количество компьютеров и сетевых шар. Нужно объединить все это в один домен. Сети соединены между собой vpn тоннелем, компьютеры пингуют друг друга в обе стороны, проблем с сетевым доступом нет.

Для нормальной работы службы Active Directory установим в каждой подсети по контроллеру домена и настроим репликацию между ними. Использовать будем Windows Server 2012R2. Последовательность действий следующая:

  • Устанавливаем контроллер домена в одной подсети, поднимаем на нем новый домен в новом лесу
  • Устанавливаем контроллер домена во второй подсети и добавляем его в домен
  • Настраиваем между доменами репликацию

Первый контроллер домена будет называться xs-winsrv с адресом 10.1.3.4, второй — xm-winsrv 10.1.4.6. Домен, который мы будем создавать будет называться xs.local

Настройка контроллеров домена для работы в разных подсетях

Первым делом устанавливаем контроллер домена в новом лесу на первом сервере xs-winsrv. Подробно останавливаться на этом я не буду, в интернете много обучалок и инструкций на эту тему. Все делаем стандартно, ставим AD, DHCP и DNS службы. В качестве первого DNS сервера указываем локальный ip адрес, в качестве второго 127.0.0.1:

Дальше устанавливаем Windows Server 2012R2 на второй сервер xm-winsrv. Теперь делаем несколько важных шагов, без которых добавить второй сервер в домен не получится. Оба сервера должны по имени пинговать друг друга. Для этого в файлы C:\Windows\System32\drivers\etc\host добавляем записи друг о друге.

Читайте также:  Установка передних колодок киа сид

В xs-winsrv добавляем строку:

Теперь второй важный момент. На сервере xm-winsrv указываем в качестве первого DNS сервера первый контроллер домена 10.1.3.4:

Теперь оба сервера резолвят друг друга. Проверим это в первую очередь на сервере xm-winsrv, который мы будем добавлять в домен:

Дальше нам нужно на первом контроллере домена в оснастке Active-Directory — сайты и службы создать 2 подсети и 2 сайта, привязать к каждому сайту соответствующую ему подсеть:

После этого сервер xs-winsrv нужно перенести из сайта Default-First-Site-Name в новый созданный для него сайт. Теперь все готово для добавления второго сервера в домен.

Добавление второго контроллера домена из другой подсети

Идем на второй сервер xm-winsrv, запускаем мастер добавления ролей и добавляем так же как и на первом сервере 3 роли — AD, DNS, DHCP. Когда будет запущен Мастер настройки доменных служб Active Directory, выбираем там первый пункт — Добавить контроллер домена в существующий домен, указываем наш домен xs.local:

На следующем шаге в параметрах контроллера домена указываем имя сайта, к которому мы присоединим контроллер:

Напомню, что это должен быть сайт, к которому привязана подсеть 10.1.4.0/24. Первый и второй контроллеры оказываются в разных сайтах. Не забываем поставить галочку Глобальный каталог (GC). Дальше все настройки оставляем по-умолчанию.

После перезагрузки сервера, он окажется в домене xs.local. Зайти под локальным администратором не получится, нужно использовать доменную учетную запись. Заходим, проверяем прошла ли репликация с основным контроллером домена, синхронизировались ли записи DNS. У меня все это прошло благополучно, всех пользователей и записи DNS второй контроллер домена забрал с первого. На обоих серверах в оснастке Active-Directory — сайты и службы отображаются оба контроллера, каждый в своем сайте:

На этом все. Можно добавлять компьютеры в обоих офисах в домен.

Добавлю еще один важный момент для тех, кто будет все это настраивать на виртуальных машинах. Нужно обязательно на гостевых системах отключить синхронизацию времени с гипервизором. Если этого не сделать, то в какой-то момент контроллерам домена может стать плохо.

Надеюсь, что я все сделал правильно. Глубоких знаний в репликации Active Directory у меня нет. Если у кого-то есть замечания по содержанию статьи, напишите об этом в комментариях. Всю информацию я собрал в основном по форумам, где задавали вопросы или решали проблемы по схожей тематике работы домена в разных подсетях.

Онлайн курс по Linux

Помогла статья? Есть возможность отблагодарить автора

Автор Zerox

28 комментариев

а чем грозит перенос уже существующего КД с обслуживаемым доменом из Default-First-Site-Name во вновь созданный сайт и надо ли это вообще делать? спасибо

Доброго времени суток. есть решения без поднятия сервера в удаленной подсети(кажется это лишнее). к примеру с пробросом портов по vpn к серверу AD?

Я когда-то давно пробовал так сделать, но возникает множество нюансов с работой домена в удаленной подсети. Простого проброса портов будет недостаточно. Но ничего конкретного посоветовать не могу. Когда я искал информацию в интернете на эту тему, я не смог найти внятной и целостной статьи про то, как это сделать. Может сейчас что-то изменилось. Если найдете информацию, прошу поделиться.

прописал днс сервера в конфиге сетевой карте сервера AD

Здравствуйте.
Я тоже не понял, зачем трогать hosts. Поднимаем xs-winsrv , повышаем до КД и настраиваем на нем DNS. На сервере xm-winsrv в качестве первичного DNS указываем IP первого и после этого повышаем его КД. xm-winsrv прекрасно находит домен и там регистрируется. При этом Windows должен сам в качестве вторичного DNS прописать 127.0.0.1. Такая настройка DNS должна быть на обоих серверах, первичный DNS IP второго КД, вторичный 127.0.0.1. Это нужно что бы при старте сервера, когда еще на запустилась служба DNS, домен был доступен.
Оба КД будут размещается на одном сайте(Default-First-Site-Mane). После этого идем в Сайты и службы, создаем второй сайт, создаем Subnet и привязываем их сайтам. Перемещаем (меню по правой кнопке мыши -переместить) xm-winsrv на второй сайт. При желании Default-First-Site-Mane можно переименовать.
Нужно помнить , что репликация AD в пределах одного сайта, происходит каждые 10-15 минут, а между сайтами , где то раз в 2-3 часа.
Это нужно учитывать , на пример при заведении нового пользователя. Что бы он смог сразу войти его нужно заводить на соответствующем КД. На компьютерах пользователей , в качестве первичного DNS должен быть указан КД того сайта , где он регистрируется, вторичный DNS , соответственно , другой КД.
Я наступил на эти грабли (переименовал КД и не дождался окончания репликации AD) AD «встал раком». Для того , что бы понять в чем проблема потратил целый день лазанья по форумам. Окончание репликации можно отслеживать через отчеты DFS.
И дополнительно я бы хотел сказать зачем это нужно. В принципе все будет работать если ода КД будут в одном сайте но есть как минимум две причины сделать так. Первая, пользователи второй площадки не смогут зарегистрироваться если упадет VPN, и вторая регистрация будет проходить значительно быстрее.
С наилучшими Пожеланиями!

Цитата «Я тоже не понял, зачем трогать hosts. Поднимаем xs-winsrv , повышаем до КД и настраиваем на нем DNS. На сервере xm-winsrv в качестве первичного DNS указываем IP первого и после этого повышаем его КД. xm-winsrv прекрасно находит домен и там регистрируется. При этом Windows должен сам в качестве вторичного DNS прописать 127.0.0.1. Такая настройка DNS должна быть на обоих серверах, первичный DNS IP второго КД, вторичный 127.0.0.1. Это нужно что бы при старте сервера, когда еще на запустилась служба DNS, домен был доступен.»

Я тоже не понял зачем трогать файл hosts ? Наверно у аффтара осталась привычка с Windows 3.11

Не понял зачем в качестве сервера DNS указывать адрес 127.0.0.1 ?
Надо просто правильно настроить маршрутизацию между подсетями перед настройкой контроллеров домена в разных сайтах (читай подсетях). Тогда просто в первой подсети прописываешь в качестве альтернативного DNS адрес DNS сервера из второй подсетки (сайта). А для второй подсетки наоборот в качестве альтернативного прописываешь адрес DNS первой подсетки.

Цатата «И дополнительно я бы хотел сказать зачем это нужно. В принципе все будет работать если ода КД будут в одном сайте но есть как минимум две причины сделать так. Первая, пользователи второй площадки не смогут зарегистрироваться если упадет VPN, и вторая регистрация будет проходить значительно быстрее.»

Да будут работать два КД в одном расположенные в одном сайте. Но тогда у вас в пользователи в обоих филиалах будут из одной подсетки. Но как только вы хотите иметь пользователей в разных подседках (сайтах) то Микрософт рекомендует устанавливать в каждый сайт(подсетку) контроллер домена. Да и здравый смысл говорит что так надо делать, потому что легче управлять информационной структурой. И так надежнее. Но при этом Вам никуда не деться от того чтобы правильно настроить маршрутизацию между филиалами.

Не понял, а в чем конкретно проблема с hosts? Настроенная таким образом сеть с КД работает до сих пор, проблем с ней нет. Имена и IP адреса контроллеров домена не меняют. В чем проблема прибить их железно через hosts? Это рабочий инструмент.

К примеру, кластер kubernetes, установленный через kubespray из коробки использует файлы hosts на всех узлах кластера, чтобы настроить связность между ними. И никого это не смущает. Но почему-то в винде меня уже заклеймили за эту настройку. При этом не привели никаких существенных аргументов, почему так делать не надо. Самый популярный аргумент — потом забудешь про это или кто-то другой не разберется. Считаю это надуманная причина. Забыть можно все, что угодно.

Zerox,
Да в Unix системах в файл hosts активно используется. Без него там никуда. Особенно при разворачивании и настройках различных сервисов, таких как контейнеры и прочее…..Это первое
Вам никто не запрещает использовать файлы hosts и в Windows. Вы можете настроить сетевое окружение используя эти файлы. Все будет работать. Только Вам придется побегать по всем рабочим станциям чтобы прописать все в эти файлы. Так и было в Windows 3.11 Чтобы организовать сеть для группы пользователей приходилось все прописывать в этих файлах. И если что-то менялось в сети надо было бежать снова по рабочим станциям и перепрописывать эти изменения. Это удобно ?
А для того чтобы не бегать по рабочим станция и перепрописывать все вновь сделанные изменения лучше ими управлять централизованно. Это удобней. Так ? Кто там что-то забудет где-то это отдельный разговор… Это второе.
Третье. Записи в эти файлы Вам никак не помогут, пока вы не настроите правильно маршрутизацию между подсетями (филиалами). Только не путайте настройку маршрутизации с настройкой VPN. Это разные сервисы. А когда Вы правильно настроите маршрутизацию у Вас все прекрасно заработает и без прописывания в файлы hosts, когда Вы заведете сервер из другой подсетки в развернутый домен на первой подсетке. А после этого повысите роль этого сервера до контроллера домена, расположив его в другом сайте того же домена, предварительно создав этот сайт в домене. Более того Микрософт не запрещает размещать контроллеры одного домена в разных сайтах(подсетях) при одно требовании сиязь между подсетями должна быть постоянной и «жесткой». А такую связь Вам обеспечивает именно настройка маршрутизации (не путать с настройкой VPN, которая является виртуальной структурой). Иначе все будет работать криво, более того Вы можете в какой-то момент получить эффект фантомного домена который разнесет Вашу информационную структуру.

Читайте также:  Установка плинтуса из бамбука

Речь про пользовательские компьютеры не было, можно было об этом не упоминать. Я связал лишь контроллеры домена между собой как наиболее критические объекты инфраструктуры. Они смогут найти себя всегда, даже если с dns будут какие-то проблемы и резолв поломается. Вероятность этого не нулевая. Я наблюдал падения dns серверов, которые парализуют работу сети полностью. В чем проблема подстраховаться таким способом?

В unix и windows файлы hosts работают одинаково. Если это удобно в одной системе, значит может быть удобно и в другой.

Маршрутизация с dns не связана вообще никак. Не понял, зачем вы о ней заводите речь.

Хмммм…..ну ладно…..объясню на пальцах….
Вы не горячитесь. ОК ? Вам же ясно написано что используйте файлы hosts на Ваше здоровье. Но это не удобно. Да и зачем ? Когда есть DNS.
Вы говорите что Вы подстраховываетесь от падения DNS. Тогда у Вас не будет работать тот контроллер домена где упал днс, потому что вся работа AD завязана на днс и прописывание в эти файлы Вам никак не поможет. Вот на этой случай я и говорю что в настройках сетевой карты контроллеров доменов надо прописать первым DNS IP самого себя, а альтернативным DNS прописать IP адрес DNS другой подсетки. Тогда если падает DNS в одной из подсеток все будет работать за счет контроллера и DNS из другой подсетки, при условии что правильно настроена маршрутизация между филиалами, чтобы все реплицировалось правильно. Не будет работать ничего только в случае падения обоих DNS в обоих подсетях одновременно.
Да Вам маршрутизация нужна для того чтобы DNS развернуьый в одной подсетке правильно разрешил имя Вашего сервера во второй подсетке в его IP. А это будет в том случае если Вы сервер из второй подсетке прежде чем повышать его роль до Контроллера домена, введете в домен как обычный сервер. При этом в DNS будет сделана соответствующая запись. Причем как в прямой так и в обратной зонах.
Ну а раз есть запись в DNS и правильно настроена маршрутизация между подсетками что помешает DNS разрешить имя в IP адрес ? А запись в обратной зоне позволит и по IP найти сервер. Зачем нужны в этом случае записи в файлы hosts ? Более того без правильной настройки маршрутизации Вы не сможете правильно ввести сервер из второй подсетки в домен.

Маршрутизация, как я уже сказал, к вопросам DNS, к коим относится настройка dns сервера или файла hosts не относится вообще никак. Из задачи изначально понятно, что маршрутизация настроена и работает как надо, иначе две сети не будут видеть друг друга, что с доменом, что без.

Ну ладно, это все пустой разговор.

Хммм…..на пальцах снова объясню…..
А кто говорил что настройка маршрутизации и настройка DNS это один тот же сервис ?
Без правильной настройки маршрутизации даже правильная настройка DNS и тем более прописывание в файлы hosts пустое занятие. Ничего работать не будет. На каком уровне работает маршрутизация ? И на каком уровне работает DNS ? Когда ответите себе на этот вопрос у Вас все встанет на свои места. Также попутно замечу что использовать VPN для соединения двух филиалов без правильной настройки маршрутизации между двумя подсетями (филиалами) не правильно. Я уже говорил об этом. VPN это виртуальная структура и работает на 4 уровне….и никакой реальной правильно настроенной маршрутизации не будет…..
Чтобы это не был пустой разговор поправьте статью чтобы не вводить народ в заблуждение…заранее спасибо
И последнее

Еще раз повторяю. В контексте статьи проблем с маршрутизацией нет вообще. И не было. При чем тут вообще маршрутизация, зачем о ней говорить? Если бы были проблемы с маршрутизацией, то статьи бы не было вообще.

В комментариях подняли только один вопрос — не надо править файл hosts, так как это плохая практика. Я понял, что эта практика в основном в головах людей, так как никакой реальной проблемы не будет из-за того, что ты подстрахуешь работу dns записью в файле hosts. И говорить о том, что это непременно надо убрать, не приходится. Ничего не случится, если кто-то сделает так же.

Статья писалась более 5-ти лет назад. У меня нет желания поднимать тестовый стенд, чтобы ее переделывать. Это была моя последняя установка и настройка КД, которая, к слову, успешно эксплуатируется по сей день.

Да пофиг ваши записи в файлы hosts. Я уже об этом сказал и не раз. Ваша статья изобилует массой неточностей или домыслов, как кому угодно. Но надо сказать и другой стороне. Что на безрыбье и раком свиснешь……то бишь это кое-что….. Сразу отвечаю про неточности
1. Не упомянуто что должна быть обязательно настроена маршрутизация между подсетками.
2. Зачем танцы с бубном с файлами hosts ?
3. Зачем танцы с бубном про назначение IP адресов DNS ? Когда Вам достаточно в настройках сетевой карты контроллеров доменов надо прописать первым DNS IP самого себя, а альтернативным DNS прописать IP адрес DNS другой подсетки.
4. Мне всегда было интересно как это люди так лихо разворачивают дополнительный контроллер домена не вводя прежде этот сервер в домен ? Неужели сервер не отфутболил ?
И последнее. цитата из статьи
«Сети соединены между собой vpn тоннелем, компьютеры пингуют друг друга в обе стороны, проблем с сетевым доступом нет.»
Но это не означат что маршрутизация настроена между подсетками. Так ? И VPN лучше не поднимать, пока не развернута доменная структура. Так ? Тогда должно быть упоминание что маршрутизация между подсетками настроена.
Так ?

«Но это не означат что маршрутизация настроена между подсетками. Так ?»
Нет, не так. Маршрутизация — процесс определения лучшего пути, по которому пакет может быть доставлен получателю. Если пинги успешно проходят, значит пакеты ходят в нужных направлениях, маршруты настроены верно.

«И VPN лучше не поднимать, пока не развернута доменная структура. Так ?»
Нет, не так. VPN с доменом не связан никак.

«Тогда должно быть упоминание что маршрутизация между подсетками настроена. Так ?»
Это подразумевалось изначально, когда было сказано, что сети настроены между собой и пинги проходят.

Zerox
«Но это не означат что маршрутизация настроена между подсетками. Так ?»
Нет, не так. Маршрутизация — процесс определения лучшего пути, по которому пакет может быть доставлен получателю. Если пинги успешно проходят, значит пакеты ходят в нужных направлениях, маршруты настроены верно.

Читайте также:  Установка двойного натяжного потолка

С какой стати ? VPN у Вас настроен между Вашими маршрутизаторами Так ? И Ваш маршрутизатор может ничего не знать о другой подсети вашего филиала. Так ? Кто ему скажет о подсетке филиала ? VPN ? Так он имеет отличный от нее адрес. Так ?
То есть маршрутизация настроена между VPN и вашими подсетями. Так ? Но при этом прямой маршрутизации между вашими подсетями настроенной на ваших маршрутизаторах нет. Так ? То есть маршрутизация настроена виртуально. Так ? И что будет если она упадет ? Или кто-то заблокирует GRE пакеты ? Как будут реплицироваться контроллеры вашего домена в разных подсетях в этом случае ?

Нет, не так. VPN с доменом не связан никак.
Почитайте внимательно что я написал выше. Попутно замечу что когда вы таким образом станете вводить сервер из другой подсетки в домен и затем повысите его роль до контроллера домена то этому вашему новому контроллеру домена в DNS сервере будет прописано два IP адреса. Догадаетесь откуда ?

Это подразумевалось изначально, когда было сказано, что сети настроены между собой и пинги проходят.

Читайте внимательно что я написал выше. Ничего там не подразумевалось кроме того что Вы написали. Естати, люди так и делают, как у Вас написано…..и получают что ?

У вас фундаментальные пробелы в терминологии. Я вижу, что мы общаемся на разных языках. Не вижу смысла для себя продолжать эту беседу. Я дал точное определении маршрутизации, из которого следует, что она у меня уже настроена, так как КД из разных локальных сетей видят друг друга и обмениваются пакетами. Наводящие вопросы тут ни к чему.

Обиделись ? А зря….Ничего обидного в моих словах нет. А есть опыт…..Терминология тут не при чем, когда нет понимания отличия между маршрутизацией и VPN….разные сервисы…маршрутизация работает на третьем уровне, а VPN на четвертом…..и когда настраивается VPN, то он настраивается для того чтобы только защитить информацию передаваемую между филиалами (подсетями), то есть доступ к разным шарам и тому подобноное…..Но VPN не заменяет настройку прямой маршрутизации между подсетями….азбука….
И чтобы закончить этот разговор….замечу…что когда не настроена прямая(а не через VPN) маршрутизация между подсетками филиалов при разворачивании контроллеров домена в разных подсетях и получают криво настроенную репликацию между сайтами…что в конечном итоге может привести к появлению фантомного домена с последующим разносом всей инфраструктуры….

Никакой обиды нет. На что обижаться? Теминология как раз при чем, это основа. Без нее невозможно двигаться вперед. Вы оперируете терминами направо и налево, без привязки к контексту. Вот несколько примеров:

1. «VPN настраивается для того, чтобы только защитить информацию.» Это неверно.
2. Вы пишите про прямую маршрутизацию, когда у меня в самом начале статьи написано, что физические сети разные, удалены друг от друга, объединены с помощью vpn. При чем тут прямая маршрутизация? Она невозможна в этом случае в принципе.
3. Вы упоминаете зачем-то gre пакеты, но я протокол gre вообще не использовал. И т.д. В общем, какая-то мешанина всего и вся.

Я же сразу сказал, что маршрутизация уже настроена, она работает корректно, она проверена. После этого начинается настройка КД. К теме данной статьи маршрутизация вообще не имеет отношения, так как в самом начале задачи подразумевается и проверяется фактически, что с маршрутизацией все в порядке.

Zerox,
>Никакой обиды нет. На что обижаться?
Как раз Вы и обиделись…ну да ладно…
>Теминология как раз при чем, это основа. Без >нее невозможно двигаться вперед. Вы >оперируете терминами направо и налево, без >привязки к контексту. Вот несколько примеров:

Хммм…..удивлен…..но дальше прочитаю….
>1. «VPN настраивается для того, чтобы только >защитить информацию.» Это неверно.

Во-во. Поэтому все и настраивают вместо маршрутизации VPN. Особенно провайдеры.
Мне было бы это смешно, но почему-то грустно…..
>2. Вы пишите про прямую маршрутизацию, >когда у меня в самом начале статьи написано, >что физические сети разные, удалены друг от >друга, объединены с помощью vpn. При чем >тут прямая маршрутизация? Она невозможна >в этом случае в принципе.

Да ну ? Объясните мне пожалуйста почему ?

>3. Вы упоминаете зачем-то gre пакеты, но я >протокол gre вообще не использовал. И т.д. В >общем, какая-то мешанина всего и вся.

У Вас настроен VPN. Так ? Какой он использует протокол ? PPTP ? L2TP ? И там и там используются пакеты GRE….азбука…А это пакеты переменной длинны….которые не очень любят операторы предоставляющие интернет услуги….Догадаетесь почему ?
Никакой мешанины у меня нет, просто у Вас нет понятия основ сети. Это первое. И второе у Вас нет понятие построения информационной структуры не только в доменах но и в принципе вообще….если резко…извините….
>Я же сразу сказал, что маршрутизация уже >настроена, она работает корректно, она >проверена.
У Вас маршрутизация настроена через «НОГУ» через VPN, то есть виртуально Что не верно при разворачивании информационной структуры…..
>После этого начинается настройка КД. К теме >данной статьи маршрутизация вообще не >имеет отношения, так как в самом начале >задачи подразумевается и проверяется >фактически, что с маршрутизацией все в >порядке.

Настройка маршрутизации между подсетями это основа. Это более низкий уровень, чем разворачивание контроллеров домена, потому что это логический уровень, И у Вас логический уровень должен соответствовать вашему сетевому уровню….иначе все будет настроено криво….

Как я уже сказал, ни gre, ни pptp и l2tp я не использовал в этой ситуации. Так что оставляю вас с этой азбукой, пакетами переменной длины и своими фантазиями наедине. Остальное комментировать не вижу смысла.

Тока в качестве ремарки…..зря обижаетесь…..тут собственно обижаться не на что…но это Ваше дело…..Правильно, что там комментировать нечего потому что там написаны прописные истины……

Проблема в том, что имея работоспособную службу доменных имен, которая разрешит вам хоть короткое имя сервера, хоть FQDN, вы сделали какие-то адские, лютые костыли. Представьте только, сколько будет потрачено времени на выискивание таких вот не очевидных вещей. Вы уж простите, но я еще раз повторю, если у вас есть DNS на контроллерах, то имена у вас разрешаются прекрасно. Хотите еще себе дополнительное имя- так добавьте его в DNS, но не в hosts же.
>>Я знаю, что при настройке hyper-v мне тоже приходилось добавлять вручную сервер в файл hosts, чтобы оснастки нормально подключались к гипервизору и позволяли им управлять.
А зачем? Машина ваша не в домене была, с которой управляли? Хотелось по короткому имени работать? Ну, есть тайное знание как прописывание суффикса дополнительного на сетевом адаптере, если нужно разрешение имен, или просто добавление его для рабочей станции.

» Теперь делаем несколько важных шагов, без которых добавить второй сервер в домен не получится. Оба сервера должны по имени пинговать друг друга. Для этого в файлы C:\Windows\System32\drivers\etc\host добавляем записи друг о друге.»
Но черт возьми, Холмс!
Зааачееем?
У вас второй сервер прекрасно найдет первый, используя DNS. Какие hosts файлы, зачем? DNS, у нас появился со времен 2000й винды, и хостс нужен максимум создать для теста на машине девелопера потестить что-то или заспуфить временно. Ужас просто пишете, а люди потом не включая голову повторят все тоже.

Не понял, а в чем проблема? Я сейчас не могу точно вспомнить, зачем я это делал, но раз делал, значит было нужно. Возможно пинг по имени сервера не проходил по какой-то причине. Я знаю, что при настройке hyper-v мне тоже приходилось добавлять вручную сервер в файл hosts, чтобы оснастки нормально подключались к гипервизору и позволяли им управлять.

Второй сервер прекрасно найдет первый с помощью DNS первого сервера при следующих условиях

1. Правильно настроена маршрутизация между подсетками. (не путать с настройкой VPN)
2. Сервер из второй подседки перед повышением его роли до КД был введен в домен.

источник