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

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

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

Если у вас есть желание научиться работать с роутерами микротик и стать специалистом в этой области, рекомендую по программе, основанной на информации из официального курса MikroTik Certified Network Associate. Курс стоящий, все подробности читайте по ссылке. Есть бесплатные курсы.

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

Планирование установки 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:

Контроллер домена dns

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

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

10.1.4.6   xm-winsrv

В xm-winsrv добавляем:

10.1.3.4   xs-winsrv

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

active-directory2

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

Пинг контроллера домена

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

Active-Directory - сайты и службы

После этого сервер 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 сайты и службы

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

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

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

Онлайн курс Основы сетевых технологий

Теоретический курс с самыми базовыми знаниями по сетям. Курс подходит и начинающим, и людям с опытом. Практикующим системным администраторам курс поможет упорядочить знания и восполнить пробелы. А те, кто только входит в профессию, получат на курсе базовые знания и навыки, без воды и избыточной теории. После обучения вы сможете ответить на вопросы:
  • На каком уровне модели OSI могут работать коммутаторы;
  • Как лучше организовать работу сети организации с множеством отделов;
  • Для чего и как использовать технологию VLAN;
  • Для чего сервера стоит выносить в DMZ;
  • Как организовать объединение филиалов и удаленный доступ сотрудников по vpn;
  • и многое другое.
Уже знаете ответы на вопросы выше? Или сомневаетесь? Попробуйте пройти тест по основам сетевых технологий. Всего 53 вопроса, в один цикл теста входит 10 вопросов в случайном порядке. Поэтому тест можно проходить несколько раз без потери интереса. Бесплатно и без регистрации. Все подробности на странице .

Помогла статья? Подписывайся на telegram канал автора

Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.

Автор Zerox

Zerox
Владимир, системный администратор, автор сайта. Люблю настраивать сервера, изучать что-то новое, делиться знаниями, писать интересные и полезные статьи. Открыт к диалогу и сотрудничеству. Если вам интересно узнать обо мне побольше, то можете послушать интервью. Запись на моем канале - https://t.me/srv_admin/425 или на сайте в контактах.

41 комментарий

  1. Аватар
    Сергей

    Добрый день. А у Вас не возникало проблемы с репликацией DNS зон между сайтами? Я создал зону обратного просмотра на сайте "А" и завел сервер в домен. Записи (прямые и обратные) на DNS-сервере "А" появились, но на сервере "B" из Default-Site двое суток тишина об этом члене домена. Репликация через "сайты и службы" проходит. В событиях есть ошибки о мертвых GPO, которые невозможно синхронизировать, но по части DNS ошибок в журнале нет. Сейчас вижу, что он даже в компьютерах на DC "B" не появился.

    • Аватар
      Сергей

      Вот спросил и нашел кое что. В NTDS Settings нет указания реплицировать "B" с "A", только наоборот. Посмотрим, что будет если добавить подключение.

  2. Аватар

    Здравствуйте!
    Имеем ОДИН домен, который состоит из одного сайта: Site-A (подсеть 192.168.1.0/24)
    Когда добавлял второй контроллер домена (подсеть 192.168.100.0/24), забыл добавить второй сайт и подвязать к нему подсеть.
    После установки второй контроллер автоматически был добавлен в сайт А.
    На данный момент создал Site-B и подвязал к нему подсеть 192.168.100.0/24.
    Возник вопрос как переместить второй контроллер домена из Site-A в Site-B?

  3. Аватар

    @Zerox Помогите, пожалуйста. У меня аналогичная задача. Есть локальный DC и хочу настроить репликацию с удаленным сервером. IP тунель поднят, пинги ходят, но dns не резолвится. Файл host заполнил двух сторон, по имени нача пинговать, но DNS не видет все равно, nslookup - DNS request timed out и в домен, соответственно, добавить не выйдет. На этом я стопорнулся и уже несколько дней не нахожу решения.

    • Zerox

      А чем тут помочь? Раз dns не работает, надо решать с ним проблему, почему не отвечает. В таком случае использовать hosts не вариант. Я то его использовал просто как подстраховку при работающем dns, а не в качестве замены.

      • Аватар

        На основном сайте DNS поднят давно, все работают, машины добавлены в домен. Какие есть возможно варианты в настройке основного DNS? Что я мог пропустить?

        • Zerox

          Рекомендую в чате спросить. Так трудно что-то советовать в рамках ответа на комментарии. Надо смотреть настройки как dns сервера, так и vpn, связность сети и т.д.

  4. Аватар

    Добрый вечер, в случае падения контроллера домена в отдельном сайте, пользователь сможет произвести аутентификацию на контроллере из другого сайта?

    • Zerox

      Не уверен. Чаще всего вместе с контроллером домена стоит служба DNS, которая приляжет вместе с ним. То есть как минимум, нужно будет отдельно решать вопрос с dns, чтобы компьютеры имели представление, где находятся оставшиеся контроллеры домена.

      • Аватар

        С этим допустим нет проблем, по dhcp они будут получать несколько поднятых днс в домене. Значит в теории полезут на ближайший контроллер?

  5. Аватар
    Сергей

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

  6. Аватар

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

    • Zerox

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

  7. Аватар
    Евгений

    Здравствуйте.
    Я тоже не понял, зачем трогать 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, и вторая регистрация будет проходить значительно быстрее."

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

      • Zerox

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

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

        • Аватар

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

          • Zerox

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

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

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

            • Аватар

              Zerox

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

              • Zerox

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

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

                • Аватар

                  Zerox

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

                  • Zerox

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

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

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

                    • Аватар

                      Zerox

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

          • Zerox

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

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

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

            • Аватар

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

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

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

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

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

              • Zerox

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

                • Аватар

                  Zerox

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

                  • Zerox

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

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

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

                    • Аватар

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

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

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

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

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

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

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

                  • Zerox

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

                    • Аватар

                      Zerox

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

  8. Аватар

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

  9. Аватар

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

    • Zerox

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

    • Аватар

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

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

      • Аватар
        Виталий

        Если не сложно, не могли бы вы "на пальцах" объяснить разницу между маршрутизацией и ВПН. Всегда полагал, что ВПН является частью процесса маршрутизации. Вы настаиваете на обязательном прямом канале между филиалами?

        • Аватар
          Володя

          Виталий, И правильно полагали что VPN является частью маршрутизации, только в той части что НЕ НАСТРОИВ СНАЧАЛА ПРАВИЛЬНО МАРШРУТИЗАЦИЮ ВЫ НЕ СМОЖЕТЕ НАСТРОИТЬ ВАШ VPN туннель !!!
          ВСЕ !!! И никак иначе.
          Что касается маршрутизации и ВПН. На пальцах, чтобы не залезать в дебри.
          Как работает маршрутизация и как работает ВПН ? Это две разных технологии. Так ?
          Пусть для примера будут две разных подсетки соединенные каждая с Интернет через маршрутизаторы.
          Надо переслать пакет из одной подсетки в другую, а потом обратно. Пусть для простоты понимания обе подсетки имеют белые адреса, хотя это не меняет сути когда адреса подсеток серые. Ибо подменой адресов занимается сервис NAT а не маршрутизаторы. Как это сделать ? Правильно надо сначала сделать так чтобы подсетки увидели друг друга. Так ? Что будете сначала настраивать ? Настраивать маршрутизацию между подсетками. Так ? И что будете делать для этого ? Прописывать на маршрутизаторах пути как из одной подсетки достичь второй подсетки и наоборот из второй подсетки достичь первой. Так ? И где Вы тут видите подмену адресов ? Нигде. Так ? Маршрутизаторы не занимаются подменой адресов. Так ? Маршрутизаторам для правильной работы нужны подсетки и маски. Так ? И когда к ним приходит пакет то что делает маршрутизатор ? Он из его содержимого и его IP адреса выделяют подсетку куда дальше направить данный пакет, просматривая свою таблицу маршрутизации. Так ? И в конце концов у какого-то из маршрутизаторов будет прописан путь как достичь маршрутизатора второй подсетки. Так ? И таким образом будет построена вся цепь прохождения пакета, то бишь построен маршрут. Если у Вас уже зашифрована информация, например как при репликации контроллеров домена, то Вам ВПН и не нужно настраивать. Все будет работать и без него корректно.
          А как работает ВПН и зачем он нужен ? Нужен для того чтобы передавать не зашифрованные данные через Интернет по защищенному каналу. Так ? Так если данные исходно зашифрованы зачем еще их передавать и по защищенному каналу ? Чтобы еще больше грузить процессор системы, так ? И как работает VPN ? Очень просто, строится третья виртуальная сеть, путем подмены адресов из первой и второй подсеток в адреса третьей виртуальной подсетки. И где Вы тут видите маршрутизацию ? Нигде. И будет ли данная виртуальная сеть работать без правильно настроенной маршрутизации ? Ответ очевиден. НЕТ !

          • Аватар
            Дмитрий

            Вы же путаете людей в конец.
            Как в географически разнесенных филиалах вы настроете маршрут без VPN? Вы отдадите провайдеру пакет с BOGON-адресом вашей удалённой подсети, и провайдер этот пакет убьет.
            Снача вы поднимаете site-to-site туннель, а потом уже говорите маршрутизатору, что такую-то сеть ему надо искать в таком-то туннеле. И не важно, на каком протоколе будет туннель.
            А файл hosts и правда лишний. Просто прописать в DNS адрес другого контроллера и можно вводить систему в домен.
            А ещё вы путаете порядок DNS в настройках КД. По фэншую первым идет IP другого контроллера, а вторым 127.0.0.1. Если контроллеров больше двух, то лукап идет последним, а перед ним все другие (ну или минимально необходимое для отказоустойчивости).

Добавить комментарий

Ваш адрес email не будет опубликован.

Нажимая кнопку "Отправить комментарий" Я даю согласие на обработку персональных данных.