Server Admin Авторский блог системного администратора
У меня возникла необходимость развернуть службу Active Directory в территориально разделенных местах, сети которых объединены с помощью vpn. На первый взгляд задача кажется простой, но лично я раньше подобными вещами не занимался и при беглом поиске не смог найти какую-то единую картину или план действий в таком случае. Пришлось собирать информацию из разных источников и самому разбираться с настройками.
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.
Из этой статьи вы узнаете:
Планирование установки 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 добавляем строку:
10.1.4.6 xm-winsrv
В xm-winsrv добавляем:
10.1.3.4 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 у меня нет. Если у кого-то есть замечания по содержанию статьи, напишите об этом в комментариях. Всю информацию я собрал в основном по форумам, где задавали вопросы или решали проблемы по схожей тематике работы домена в разных подсетях.
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.
Здравствуйте, скажите а как настроить работу 2-х сетей (vpn), с условием что все DC находятся в 1-ой. из подсетей ? Нужна маленькая подсеть (на 4-5 клиентских компов), которая по VPN будет использовать сервисы предприятия.
клиент1 ______10.10.2.0/24-----инет _________ _________инет-----10.10.0.0/24______DC1,DNS
клиент2______/ \_____DC2,DNS
\_____FS, SQL и пр.
достаточно ли будет прописать 2-ю сеть на DC (сайты и службы) и настроить днс (указать, что для 10.10.2.0 глава всея днс это, к примеру DC1) ?
клиент1 ______10.10.2.0/24-----инет _________ _________инет-----10.10.0.0/24______DC1,DNS
клиент2______/****************************************************** \_____DC2,DNS
********************************************************************\_____FS, SQL и пр.
извините поправил схему (пробелы удалились).
Если сайтов раньше не было настроено, то просто делаете с новой сетью маршрутизацию и добавляете компьютеры в домен, указав им в DNS контроллеры из главной сети. Хотя конечно лучше бы им свой контроллер с днс в отдельный сайт.
Зашел полистать по теме, в конце чтения комментариев ржал в голос.
Вопрос ребят, у меня 3 ДК, два в одной сети, и один в другой, так вот все новые сервера когда поднимаю , прописываю в ДНСах АД который в этой сети и при входе на сервер после рестарта Очень долго думает и после входит, я протестировал такую фигню, пока не дам доступ к тем другим АДшкам, сервера видут себя таким образом, что делать не знаю, почему новые сервера обращаются к другим АДшка когда я ему указываю АД в своей сети?
Приветствую!
В АД в свойствах учетки есть опция требовать смену пароля при следующем входе. И если поставить галочку то это правило зацикливается - т.е. постоянно теперь запрашивает сменить пароль.
Как настроить АД что бы была возможность сменить пароль при первом входе ( !!!не при следующем входе!!! )
Здравствуйте!
Вссе настроил, работает, спасибо за статью.
Возникают ошибки на втором DC в DNS:
1. 4004 -The DNS server was unable to complete directory service enumeration of zone _msdcs.test.local. This DNS server is configured to use information obtained from Active Directory for this zone and is unable to load the zone without it. Check that the Active Directory is functioning properly and repeat enumeration of the zone. The extended error debug information (which may be empty) is "". The event data contains the error.
2. 4015- The DNS server has encountered a critical error from the Active Directory. Check that the Active Directory is functioning properly. The extended error debug information (which may be empty) is "". The event data contains the error.
Эти две ошибки вылазят каждые пол часа, бывает не появляются по пол дня, а потом опять. На функционал это не влияет, но хотелось бы понять где причина и что исправить. Статьи по этим ошибкам уже пересмотрел, но фиксы не работают. Возможно сталкивались с таким и можете подсказать куда смотреть?
Добрый день. А у Вас не возникало проблемы с репликацией DNS зон между сайтами? Я создал зону обратного просмотра на сайте "А" и завел сервер в домен. Записи (прямые и обратные) на DNS-сервере "А" появились, но на сервере "B" из Default-Site двое суток тишина об этом члене домена. Репликация через "сайты и службы" проходит. В событиях есть ошибки о мертвых GPO, которые невозможно синхронизировать, но по части DNS ошибок в журнале нет. Сейчас вижу, что он даже в компьютерах на DC "B" не появился.
Вот спросил и нашел кое что. В NTDS Settings нет указания реплицировать "B" с "A", только наоборот. Посмотрим, что будет если добавить подключение.
Здравствуйте!
Имеем ОДИН домен, который состоит из одного сайта: Site-A (подсеть 192.168.1.0/24)
Когда добавлял второй контроллер домена (подсеть 192.168.100.0/24), забыл добавить второй сайт и подвязать к нему подсеть.
После установки второй контроллер автоматически был добавлен в сайт А.
На данный момент создал Site-B и подвязал к нему подсеть 192.168.100.0/24.
Возник вопрос как переместить второй контроллер домена из Site-A в Site-B?
@Zerox Помогите, пожалуйста. У меня аналогичная задача. Есть локальный DC и хочу настроить репликацию с удаленным сервером. IP тунель поднят, пинги ходят, но dns не резолвится. Файл host заполнил двух сторон, по имени нача пинговать, но DNS не видет все равно, nslookup - DNS request timed out и в домен, соответственно, добавить не выйдет. На этом я стопорнулся и уже несколько дней не нахожу решения.
А чем тут помочь? Раз dns не работает, надо решать с ним проблему, почему не отвечает. В таком случае использовать hosts не вариант. Я то его использовал просто как подстраховку при работающем dns, а не в качестве замены.
На основном сайте DNS поднят давно, все работают, машины добавлены в домен. Какие есть возможно варианты в настройке основного DNS? Что я мог пропустить?
Рекомендую в чате спросить. Так трудно что-то советовать в рамках ответа на комментарии. Надо смотреть настройки как dns сервера, так и vpn, связность сети и т.д.
Добрый вечер, в случае падения контроллера домена в отдельном сайте, пользователь сможет произвести аутентификацию на контроллере из другого сайта?
Не уверен. Чаще всего вместе с контроллером домена стоит служба DNS, которая приляжет вместе с ним. То есть как минимум, нужно будет отдельно решать вопрос с dns, чтобы компьютеры имели представление, где находятся оставшиеся контроллеры домена.
С этим допустим нет проблем, по dhcp они будут получать несколько поднятых днс в домене. Значит в теории полезут на ближайший контроллер?
а чем грозит перенос уже существующего КД с обслуживаемым доменом из 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 не связана вообще никак. Не понял, зачем вы о ней заводите речь.
Zerox
Хмммм.....ну ладно.....объясню на пальцах....
Вы не горячитесь. ОК ? Вам же ясно написано что используйте файлы hosts на Ваше здоровье. Но это не удобно. Да и зачем ? Когда есть DNS.
Вы говорите что Вы подстраховываетесь от падения DNS. Тогда у Вас не будет работать тот контроллер домена где упал днс, потому что вся работа AD завязана на днс и прописывание в эти файлы Вам никак не поможет. Вот на этой случай я и говорю что в настройках сетевой карты контроллеров доменов надо прописать первым DNS IP самого себя, а альтернативным DNS прописать IP адрес DNS другой подсетки. Тогда если падает DNS в одной из подсеток все будет работать за счет контроллера и DNS из другой подсетки, при условии что правильно настроена маршрутизация между филиалами, чтобы все реплицировалось правильно. Не будет работать ничего только в случае падения обоих DNS в обоих подсетях одновременно.
Да Вам маршрутизация нужна для того чтобы DNS развернуьый в одной подсетке правильно разрешил имя Вашего сервера во второй подсетке в его IP. А это будет в том случае если Вы сервер из второй подсетке прежде чем повышать его роль до Контроллера домена, введете в домен как обычный сервер. При этом в DNS будет сделана соответствующая запись. Причем как в прямой так и в обратной зонах.
Ну а раз есть запись в DNS и правильно настроена маршрутизация между подсетками что помешает DNS разрешить имя в IP адрес ? А запись в обратной зоне позволит и по IP найти сервер. Зачем нужны в этом случае записи в файлы hosts ? Более того без правильной настройки маршрутизации Вы не сможете правильно ввести сервер из второй подсетки в домен.
Маршрутизация, как я уже сказал, к вопросам DNS, к коим относится настройка dns сервера или файла hosts не относится вообще никак. Из задачи изначально понятно, что маршрутизация настроена и работает как надо, иначе две сети не будут видеть друг друга, что с доменом, что без.
Ну ладно, это все пустой разговор.
Zerox
Хммм.....на пальцах снова объясню.....
А кто говорил что настройка маршрутизации и настройка DNS это один тот же сервис ?
Без правильной настройки маршрутизации даже правильная настройка DNS и тем более прописывание в файлы hosts пустое занятие. Ничего работать не будет. На каком уровне работает маршрутизация ? И на каком уровне работает DNS ? Когда ответите себе на этот вопрос у Вас все встанет на свои места. Также попутно замечу что использовать VPN для соединения двух филиалов без правильной настройки маршрутизации между двумя подсетями (филиалами) не правильно. Я уже говорил об этом. VPN это виртуальная структура и работает на 4 уровне....и никакой реальной правильно настроенной маршрутизации не будет.....
Чтобы это не был пустой разговор поправьте статью чтобы не вводить народ в заблуждение...заранее спасибо
И последнее
Еще раз повторяю. В контексте статьи проблем с маршрутизацией нет вообще. И не было. При чем тут вообще маршрутизация, зачем о ней говорить? Если бы были проблемы с маршрутизацией, то статьи бы не было вообще.
В комментариях подняли только один вопрос - не надо править файл hosts, так как это плохая практика. Я понял, что эта практика в основном в головах людей, так как никакой реальной проблемы не будет из-за того, что ты подстрахуешь работу dns записью в файле hosts. И говорить о том, что это непременно надо убрать, не приходится. Ничего не случится, если кто-то сделает так же.
Статья писалась более 5-ти лет назад. У меня нет желания поднимать тестовый стенд, чтобы ее переделывать. Это была моя последняя установка и настройка КД, которая, к слову, успешно эксплуатируется по сей день.
Zerox
Да пофиг ваши записи в файлы 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 адреса. Догадаетесь откуда ?
Это подразумевалось изначально, когда было сказано, что сети настроены между собой и пинги проходят.
Читайте внимательно что я написал выше. Ничего там не подразумевалось кроме того что Вы написали. Естати, люди так и делают, как у Вас написано.....и получают что ?
У вас фундаментальные пробелы в терминологии. Я вижу, что мы общаемся на разных языках. Не вижу смысла для себя продолжать эту беседу. Я дал точное определении маршрутизации, из которого следует, что она у меня уже настроена, так как КД из разных локальных сетей видят друг друга и обмениваются пакетами. Наводящие вопросы тут ни к чему.
Zerox
Обиделись ? А зря....Ничего обидного в моих словах нет. А есть опыт.....Терминология тут не при чем, когда нет понимания отличия между маршрутизацией и 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 я не использовал в этой ситуации. Так что оставляю вас с этой азбукой, пакетами переменной длины и своими фантазиями наедине. Остальное комментировать не вижу смысла.
Zerox
Тока в качестве ремарки.....зря обижаетесь.....тут собственно обижаться не на что...но это Ваше дело.....Правильно, что там комментировать нечего потому что там написаны прописные истины......
Вот тут чувак и обкакался, маршрутизаторщик великий
Здравствуйте. Как на виндовс сервер добать два шлюза (вот например когда заходим на DCHP там чтоб показывало два IP) спасибо
Проблема в том, что имея работоспособную службу доменных имен, которая разрешит вам хоть короткое имя сервера, хоть FQDN, вы сделали какие-то адские, лютые костыли. Представьте только, сколько будет потрачено времени на выискивание таких вот не очевидных вещей. Вы уж простите, но я еще раз повторю, если у вас есть DNS на контроллерах, то имена у вас разрешаются прекрасно. Хотите еще себе дополнительное имя- так добавьте его в DNS, но не в hosts же.
>>Я знаю, что при настройке hyper-v мне тоже приходилось добавлять вручную сервер в файл hosts, чтобы оснастки нормально подключались к гипервизору и позволяли им управлять.
А зачем? Машина ваша не в домене была, с которой управляли? Хотелось по короткому имени работать? Ну, есть тайное знание как прописывание суффикса дополнительного на сетевом адаптере, если нужно разрешение имен, или просто добавление его для рабочей станции.
" Теперь делаем несколько важных шагов, без которых добавить второй сервер в домен не получится. Оба сервера должны по имени пинговать друг друга. Для этого в файлы C:\Windows\System32\drivers\etc\host добавляем записи друг о друге."
Но черт возьми, Холмс!
Зааачееем?
У вас второй сервер прекрасно найдет первый, используя DNS. Какие hosts файлы, зачем? DNS, у нас появился со времен 2000й винды, и хостс нужен максимум создать для теста на машине девелопера потестить что-то или заспуфить временно. Ужас просто пишете, а люди потом не включая голову повторят все тоже.
Не понял, а в чем проблема? Я сейчас не могу точно вспомнить, зачем я это делал, но раз делал, значит было нужно. Возможно пинг по имени сервера не проходил по какой-то причине. Я знаю, что при настройке 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. Если контроллеров больше двух, то лукап идет последним, а перед ним все другие (ну или минимально необходимое для отказоустойчивости).
Привет !
Прочитайте мой предыдущий комментарий для Васи, и все ваши BOGON-ы отпадут сами собой.....
Привет !
Дмитрий цитата из вашего сообщения "А ещё вы путаете порядок DNS в настройках КД. По фэншую первым идет IP другого контроллера, а вторым 127.0.0.1. Если контроллеров больше двух, то лукап идет последним, а перед ним все другие (ну или минимально необходимое для отказоустойчивости)."
Дмитрий отдохните и не пудрите тут голову чесному народу...можете это сделать как вы и говорите и по фэншую (если знаете что это такое, лично я не знаю и знать не хочу)...перед тем как ввести сервер в домен вы должны ему в качестве основного ДНС прописать IP адрес того сервера (если контроллеров домена у вас несколько) который содержит роли
Хозяин схемы
Хозяин именования доменов
Эмулятор PDC
Иначе вы не сможете ввести ваш сервер в домен...следовательно не сможете повысить его роль до уровня контроллера домена.....После того как введете ваш сервер в домен и повысите его роль до уровня контроллера домена...надо в качестве основного ДНС прописать ему его собственный IP адрес, а в качестве альтернативного прописать адрес того контроллера домена который содержит выше перечисленные мною роли....никаких 127.0.0.1 быть нигде не должно...
Володя, ты втираешь нам какую-то дичь. Если у тебя 2 сетки, одна в Морокко, а вторая на Гаваях, то как ты написал "прямую маршрутизацию" ты сможешь устроить только если сам возьмешь кабель на горб и пойдешь его тянуть от одного офиса до другого. Только в этом случае не возникнет никаких VPNов, потомучто нахрен они в таком случае нужны? А вот если твой горб не настолько силен чтобы проложить столько кабеля, ты поднимаешь VPN между роутерами. А шобы сетки друг друга видели, ты говоришь одному роутеру пихать пакеты с адресами из второй подсети в VPNтунель и второму, с адресами из первой, пихать тудаже. Это и будет вся "настройка маршрутизации" между филиалами. И да, если впн упадет то ниче работать не будет, но сорян, либо VPN, либо кабель на горб и прокладывай.
Привет !
Только в качестве ремарки....Вы можете тянуть на себе всЁ что угодно в том числе и воздух (а VPN это и есть виртуальная, то есть не существующая сеть). А раз она виртуальная, то она ДОЛЖНА на чем-то базироваться. Ну не полетят же пакеты сами по себе по воздуху, то есть по несуществующей сети. Верно ? И еще. Виртуальные вещи (интерфейсы, сети и т.п.) базируются на основе реальных. Верно ? А что в случае с VPN является реальной сетью ?
Ну правильно, физический канал, который получается как ?...Посредством маршрутизации, то есть прокладывается маршрут от источника к приемнику. Так ? Кто будет прокладывать этот маршрут ? VPN ? Вы понесете воздух на себе ?
Этот маршрут будут прокладывать маршрутизаторы. Так ? И как этот процесс называется ? Настройка VPN ? Настройка воздуха ? А вот когда Вы настроите маршрутизацию, причем верно настроите, Вы можете поверх этого канала пустить вашу VPN, бдаго там ничего уже и не требуется, кроме подмены адресов, так как всю работу уже выполнила маршрутизация. Кстати, для справки маршрутизация это один из двух китов на которых базируется Интернет. Разговоры про то что куда и кто пихает опускаю...на детский лепет и клоунаду нет времени...
Окей, коли ты настолько не понял про что я тут. В твоей ведомости есть только 2 девайса, все что ты можешь настроить ограниченно ими. Остальная маршрутизация на совести кучи провайдеров и их оборудования, на них ты повлиять не можешь никак. Вся маршрутизация которую ты можешь настроить ограничена двумя роутерами, которым ты говоришь что пакеты с адресом впна идут в туннель.
Привет !
Вася отдохните и не забивайте тут людям голову разным детским лепетом....а попросту говоря не ипи людям мозги......Что делает ваш провайдер и последующие провайдеры вас не должно не волновать никак от слова совсем....это не ваша зона ответственности....Для справки замечу, у всех провайдеров уже настроена маршрутизация....а чтобы защитить свои сети от разных атак в том числе и связанных с ложными сетями, провайдеры и помещают свои сети в туннели или как вы говорите впихивают....чтобы их сети стали защищенными....но это никак не отменяет того факта что сначала надо настроить маршрутизацию....без настройки маршрутизации никакая VPN не возможна по определению...потому что пакеты не летают по воздуху, а бегают по физическому каналу....и ваша задача (зона ответственности) настроить правильно маршрутизацию между всеми вашими подсетями а также между вами и вашим провайдером (или провайдерами если их несколько)...и если провайдер требует от вас чтобы ваше соединение с ним было еще "завернуто" в VPN то это никак не отменяет настройку маршрутизации для вас...это ваш провайдер таки образом страхуется от того чтобы вместо вас там не появился кто-то другой и плюс вся ваша информация была защищена от перехвата...
Милейший, заканчивайте уже позориться и смешить публику. Вы за два года умудрились не уяснить элементарную терминологию и базовые принципы построения сетей.
А администрации следовало бы забанить этого пациента. Просто потому, что неопытный человек может прочитать его ахинею и принять её за чистую монету.
Клоуны повылазили ? Навроде сегодня не 1 апреля. В игнор детвору...
Володя, ты забыл выпить таблетки
Бугага. Очень жаль. Значит мы так и не узнаем, какие-такие маршруты надо прописывать на контроллерах домена в филиалах, сети которых объединены туннелем.