В версии 6.47 RouterOS Mikrotik наконец добавил возможность заводить в DNS разные типы записей — CNAME, FWD, MX, NS, NSDOMAIN, SRV и TXT (раньше были только А- и АААА-записи). А это значит, что теперь роутер можно использовать в качестве DNS для домена Active Directory с возможностью переноса на него и DHCP-сервера тоже.
Если открыть на доменном контроллере панель управления dns и посмотреть настройки зоны домена — вы увидите несколько десятков SRV-записей, указывающих на доменный контроллер. Клиентские машины обращаются за ними к dns-серверу в попытке выяснить, какой сервер является доменным контроллером для указанном на них домене: запрашивая SRV-записи с разными значениями, в ответ они получают FQDN-имя доменного контроллера, которое резолвится в ip через запись типа А.
Я не ставил себе задачу разбирать смысл каждой записи в рамках этого поста, но (при желании) это всё можно нагуглить. В этой заметке я приведу набор SRV-записей, которого достаточно для стабильной работы домена с перенесенными на Mikrotik DNS и DHCP.
Итак, на вашем роутере уже настроены DNS- и DHCP-серверы (отдельно на этом пункте останавливаться нет смысла, вокруг полно статей на эту тему). В примерах ниже — на микротике настроен ip 10.0.0.1/24 (который является для клиентов и шлюзом, и dns-сервером), а доменный контроллер имеет имя controller.koobik.lan и ip 10.0.0.2. Сначала добавим А-запись для контроллера:
/ip dns static add address=10.0.0.2 name=controller.koobik.lan type=A
Теперь добавим SRV-записи для Active Directory:
/ip dns static
add name=domains._msdcs.koobik.lan srv-port=389 srv-priority=0 srv-target=controller.koobik.lan srv-weight=100 type=SRV
add name=_ldap._tcp.koobik.lan srv-port=389 srv-priority=0 srv-target=controller.koobik.lan srv-weight=100 type=SRV
add name=_ldap._tcp.dc._msdcs.koobik.lan srv-port=389 srv-priority=0 srv-target=controller.koobik.lan srv-weight=100 type=SRV
add name=_ldap._tcp.default-first-site-name._sites.gc._msdcs.koobik.lan srv-port=3268 srv-priority=0 srv-target=controller.koobik.lan srv-weight=100 type=SRV
add name=_ldap._tcp.default-first-site-name._sites.dc._msdcs.koobik.lan srv-port=389 srv-priority=0 srv-target=controller.koobik.lan srv-weight=100 type=SRV
add name=_ldap._tcp.Default-First-Site-Name._sites.controller.koobik.lan srv-port=389 srv-priority=0 srv-target=controller.koobik.lan srv-weight=100 type=SRV
add name=_ldap._tcp.controller._msdcs.koobik.lan srv-port=389 srv-priority=0 srv-target=controller.koobik.lan srv-weight=100 type=SRV
add name=_ldap._tcp.default-first-site-name._sites.koobik.lan srv-port=389 srv-priority=0 srv-target=controller.koobik.lan srv-weight=100 type=SRV
add name=_ldap._tcp.controller.koobik.lan srv-port=389 srv-priority=0 srv-target=controller.koobik.lan srv-weight=100 type=SRV
add name=_ldap._tcp.gc._msdcs.koobik.lan srv-port=3268 srv-priority=0 srv-target=controller.koobik.lan srv-weight=100 type=SRV
add name=_kerberos._tcp.koobik.lan srv-port=88 srv-priority=0 srv-target=controller.koobik.lan srv-weight=100 type=SRV
add name=_kerberos._tcp.default-first-site-name._sites.koobik.lan srv-port=88 srv-priority=0 srv-target=controller.koobik.lan srv-weight=100 type=SRV
add name=_kerberos._tcp.default-first-site-name._sites.dc._msdcs.koobik.lan srv-port=3268 srv-priority=0 srv-target=controller.koobik.lan srv-weight=100 type=SRV
add name=_kerberos._tcp.dc._msdcs.koobik.lan srv-port=88 srv-priority=0 srv-target=controller.koobik.lan srv-weight=100 type=SRV
add name=_kerberos._udp.koobik.lan srv-port=88 srv-priority=0 srv-target=controller.koobik.lan srv-weight=100 type=SRV
add name=_kpasswd._tcp.koobik.lan srv-port=464 srv-priority=0 srv-target=controller.koobik.lan srv-weight=100 type=SRV
add name=_kpasswd._udp.koobik.lan srv-port=464 srv-priority=0 srv-target=controller.koobik.lan srv-weight=100 type=SRV
add name=_tcp.Default-First-Site-Name._sites.dc._msdcs.koobik.lan srv-port=389 srv-priority=0 srv-target=controller.koobik.lan srv-weight=100 type=SRV
add name=_tcp.Default-First-Site-Name._sites.koobik.lan srv-port=389 srv-priority=0 srv-target=controller.koobik.lan srv-weight=100 type=SRV
add name=_tcp.default-first-site-name._sites.gc._msdcs.koobik.lan srv-port=3268 srv-priority=0 srv-target=controller.koobik.lan srv-weight=100 type=SRV
add name=_tcp.gc._msdcs.koobik.lan srv-port=3268 srv-priority=0 srv-target=controller.koobik.lan srv-weight=100 type=SRV
add name=default-first-site-name._sites.gc._msdcs.koobik.lan srv-port=3268 srv-priority=0 srv-target=controller.koobik.lan srv-weight=100 type=SRV
add name=gc._msdcs.koobik.lan srv-port=3268 srv-priority=0 srv-target=controller.koobik.lan srv-weight=100 type=SRV
add name=_gc._tcp.koobik.lan srv-port=3268 srv-priority=0 srv-target=controller.koobik.lan srv-weight=100 type=SRV
add name=_gc._tcp.default-first-site-name._sites.koobik.lan srv-port=3268 srv-priority=0 srv-target=controller.koobik.lan srv-weight=100 type=SRV
add name=_sites.gc._msdcs.koobik.lan srv-port=3268 srv-priority=0 srv-target=controller.koobik.lan srv-weight=100 type=SRV
add name=_vlmcs._tcp.koobik.lan srv-port=1688 srv-priority=0 srv-target=controller.koobik.lan srv-weight=100 type=SRV
Теперь клиентские машины домена могут без проблем найти в сети доменный контроллер. Однако, помимо имени, контроллер создаёт несколько уникальных ID домена и в классическом варианте так же помещает их в dns. Отловить их можно в IP — DNS — Cache после авторизации клиентской машины в Active Directory, у них будет статус unknown; их достаточно создать вручную с параметрами srv-port=389 srv-priority=0 srv-target=controller.koobik.lan srv-weight=100 type=SRV. Они имеют такой вид:
/ip dns static
add name=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee.domains._msdcs.koobik.lan srv-port=389 srv-priority=0 srv-target=controller.koobik.lan srv-weight=100 type=SRV
add name=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee._msdcs.koobik.lan srv-port=389 srv-priority=0 srv-target=controller.koobik.lan srv-weight=100 type=SRV
add name=_ldap._tcp.aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee.domains._msdcs.koobik.lan srv-port=389 srv-priority=0 srv-target=controller.koobik.lan srv-weight=100 type=SRV
add name=_tcp.aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee.domains._msdcs.koobik.lan srv-port=389 srv-priority=0 srv-target=controller.koobik.lan srv-weight=100 type=SRV
Эта схема позволяет добавить в dns любое количество доменов и контроллеров в рамках одной сети — достаточно для каждого из них создать А-запись контроллера и пачку SRV-записей из образца выше; количество ограничено только вашей фантазией и объемом памяти mikrotik; это удобно, если вам достался зоопарк систем и нужно быстрое решение по их совместной работе с централизованным управлением сетью через роутер.
Усложним задачу. У нас есть распределенная сеть с двумя доменами (koobik.lan и koobik.local), на роутерах настроена маршрутизация, клиентские машины видят друг друга по серым ip и привязаны к разным доменам, при этом клиенты могут физически перемещаться между подсетями.
Тут два варианта:
- Выбираем один из микротиков (например, 10.0.0.1) головным DNS и выдаём его ip клиентам во всех сетях, а данные о dhcp-клиентах со всех микротиков записываем в его статические записи.
- Каждый из микротиков является dns для своих клиентов, в этом случае во всех dns создаём статические записи для dhcp-клиентов со всех микротиков.
Я разберу первый вариант, т.к. второй является его производным. Для этих целей у себя я задействовал виртуалку с ubuntu, но можно использовать и внутренние скрипты микротика.
Сначала разрешаем ssh на всех микротиках:
/ip service set ssh disabled=no
В целях безопасности создадим правило, разрешающее ssh-соединения только с конкретного ip (в примере — с ip 10.0.0.10).
/ip firewall raw add action=drop chain=prerouting dst-port=22 in-interface=ether1 protocol=tcp src-address=!10.0.0.10
На виртуалке делаем SSH авторизацию без пароля на микротиках, чтобы она могла самостоятельно обращаться к ним по расписанию.
Создаём скрипты, один будет собирать со всех микротиков данные об арендованных адресах и хостнеймах клиентов (export_dhcp.sh), а затем генерировать команды для создания статических записей в dns головного микротика и помещать их во второй файл (add_dns.sh).
$ touch /root/mikrotik/export_dhcp.sh
$ chmod +x /root/mikrotik/export_dhcp.sh
$ touch /root/mikrotik/add_dns.sh
$ chmod +x /root/mikrotik/add_dns.sh
Второй файл (add_dns.sh) будет наполняться и очищаться командами из первого и никаких действий с ним не требуется. Открываем на редактирование export_dhcp.sh и копипастим туда код (скорректировав ip и учётки на свои).
#!/bin/bash
echo 'Очищаю файл от старых данных.'
:> /root/mikrotik/add_dns.sh;
echo '#!/bin/bash' >> /root/mikrotik/add_dns.sh;
echo 'Получаю данные с 10.0.2.1...'
ssh admin@10.0.2.1 'ip dhcp-server lease print terse where status=bound' | grep host-name | sed 's/.*active-address=//' | sed '1,$ s/active.*name=//g' | awk '{print "ssh admin@10.0.0.1 '\''ip dns static remove [find name="$2".koobik.local]'\'' \n ssh admin@10.0.0.1 '\''ip dns static remove [find name="$2".koobik.lan]'\'' \n ssh admin@10.0.0.1 '\''ip dns static add name="$2".koobik.local address="$1" ttl=4h'\'' \n ssh admin@10.0.0.1 '\''ip dns static add name="$2".koobik.lan address="$1" ttl=4h'\''"}' >> /root/mikrotik/add_dns.sh
echo 'Получаю данные с 10.0.1.1...'
ssh admin@10.0.1.1 'ip dhcp-server lease print terse where status=bound' | grep host-name | sed 's/.*active-address=//' | sed '1,$ s/active.*name=//g' | awk '{print "ssh admin@10.0.0.1 '\''ip dns static remove [find name="$2".koobik.local]'\'' \n ssh admin@10.0.0.1 '\''ip dns static remove [find name="$2".koobik.lan]'\'' \n ssh admin@10.0.0.1 '\''ip dns static add name="$2".koobik.local address="$1" ttl=4h'\'' \n ssh admin@10.0.0.1 '\''ip dns static add name="$2".koobik.lan address="$1" ttl=4h'\''"}' >> /root/mikrotik/add_dns.sh
echo 'Загружаю данные с 10.0.0.1...'
ssh admin@10.0.0.1 'ip dhcp-server lease print terse where status=bound' | grep host-name | sed 's/.*active-address=//' | sed '1,$ s/active.*name=//g' | awk '{print "ssh admin@10.0.0.1 '\''ip dns static remove [find name="$2".koobik.local]'\'' \n ssh admin@10.0.0.1 '\''ip dns static remove [find name="$2".koobik.lan]'\'' \n ssh admin@10.0.0.1 '\''ip dns static add name="$2".koobik.local address="$1" ttl=4h'\'' \n ssh admin@10.0.0.1 '\''ip dns static add name="$2".koobik.lan address="$1" ttl=4h'\''"}' >> /root/mikrotik/add_dns.sh
echo 'Передаю данные на 10.0.0.1...'
sh /root/mikrotik/add_dns.sh;
echo 'Готово.'
Что делает скрипт:
- Чистит /root/mikrotik/add_dns.sh от команд предыдущей итерации (мы же будем по крону его использовать)
- Поочередно обращается к трём микротикам, получая от них список активных dhcp-клиентов
- Генерит по каждому клиенту по четыре команды:
- — поиск удаление из статических записей для имя_хоста.koobik.local
- — поиск удаление из статических записей для имя_хоста.koobik.lan
- — создание статической записи для имя_хоста.koobik.local
- — создание статической записи для имя_хоста.koobik.lan
Удаление нужно из-за того, что микротик допускает существование двух одинаковых А-записей с разными ip.
Создание двух записей с разными dns-суффиксами нужно для обращения с одного клиента на другой по имени хоста. Дело в том, что если клиент относится к какому-либо домену, то при любом обращении по имени без суффикса он автоматически подставляет суффикс своего домена. А т.к. у нас два разных домена — клиенты могут быть в любом из них.
Разберём по частям одну из команд:
ssh admin@10.0.0.1 'ip dhcp-server lease print terse where status=bound' | grep host-name | sed 's/.*active-address=//' | sed '1,$ s/active.*name=//g' | awk '{print "ssh admin@10.0.0.1 '\''ip dns static remove [find name="$2".koobik.local]'\'' \n ssh admin@10.0.0.1 '\''ip dns static remove [find name="$2".koobik.lan]'\'' \n ssh admin@10.0.0.1 '\''ip dns static add name="$2".koobik.local address="$1" ttl=4h'\'' \n ssh admin@10.0.0.1 '\''ip dns static add name="$2".koobik.lan address="$1" ttl=4h'\''"}'
>> /root/mikrotik/add_dns.sh
ssh admin@10.0.0.1 ‘ip dhcp-server lease print terse where status=bound’
По ssh-ключу с логином admin подключаемся к микротику 10.0.0.1 и выполняем на нём команду ip dhcp-server lease print terse where status=bound.
grep host-name
Оставляем только те строки, в которых есть имя хоста.
0 address=10.0.0.14 mac-address=00:0C:29:D9:89:0C client-id=ff:9f:6e:85:24:0:2:0:0:ab:11:31:f2:a1:5a:46:98:8:43 address-lists=»» server=dhcp1 dhcp-option=»» status=bound expires-after=8m9s last-seen=1m51s active-address=10.255.0.14 active-mac-address=00:0C:29:D9:89:0C active-client-id=ff:9f:6e:85:24:0:2:0:0:ab:11:31:f2:a1:5a:46:98:8:43 active-server=dhcp1 host-name=client1
Пример выдачи — получаем список с активными арендами.
sed ‘s/.active-address=//’ | sed ‘1,$ s/active.name=//g’
Вытаскиваем из выдачи значения active-address и host-name с помощью обрезки через sed
Далее команда awk обрабатывает два оставшихся значения (ip и имя хоста) и генерит четыре команды с использованием двух переменных: $1 — первое слово в строке (ip), $2 — второе слово в строке (имя хоста). Для указанного примера будет сгенерировано следующее:
ssh admin@10.0.0.1 'ip dns static remove [find name=client1.koobik.local]'
ssh admin@10.0.0.1 'ip dns static remove [find name=client1.koobik.lan]'
ssh admin@10.0.0.1 'ip dns static add name=client1.koobik.local address=10.0.0.14 ttl=4h'
ssh admin@10.0.0.1 'ip dns static add name=client1.koobik.lan address=10.0.0.14 ttl=4h'
>> /root/mikrotik/add_dns.sh
Эти команды будут дописаны в конец файла add_dns.sh
Ну и, конечно, не забываем добавить в crontab задачу на выполнение скрипта /root/mikrotik/export_dhcp.sh с нужным интервалом.
Годная статья.
Хочу дополнить уточнение.
Нужно добавить две записи типа А:
/ip dns static add address=10.0.0.2 name=controller.koobik.lan type=A
/ip dns static add address=10.0.0.2 name=koobik.lan type=A
Почему-то у меня по-другому не взлетело.
А ещё хотелось бы уточнить. Возможно ли как-то узнать ID домена, типа: aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee.domains._msdcs.koobik.lan
Без обязательной установки роли DNS на контроллере домена?
Данные идентификаторы храняться в файле: %systemroot%\System32\Config\Netlogon.dns
но я не знаю, генерируется этот файл на каком этапе?
За статью респектище!!!
Александр, добавление второй А-записи для двух контроллеров в сети подразумевается, хотя явно в статье не указано, это верно.
Что касается выяснения ID-записей dns без кэша dns на микротике — не довелось выяснять, однако — если если их нет в кэше со статусом unknown, значит к ним не было обращений от хостов клиентских машин, а значит и делать для них записи смысла нет.
Ооох, а мне досталось «наследство» от предыдущего эникея. Контроллер домена на winserver 2003, к нему же прикручен TMG древний дырявый. И самое ужасное, что имя домена состоит из одного слова без каких-либо точек. Это очень усложняет работу, особенно когда пытался перенести всё на новый домен. Пытаюсь вот выкинуть из этой задачи хотя бы TMG и заменить его Микротиком RB4011. Но кругом одни подставы, оставленные предыдущим недоадмином…
Уточните пожалуйста,
в записи
add name=_ldap._tcp.controller._msdcs.koobik.lan srv-port=389 srv-priority=0 srv-target=controller.koobik.lan srv-weight=100 type=SRV
под первым встречным controller подразумевается имя контроллера домена, или же данная часть записи должна быть неизменна?
например вот так:
add name=_ldap._tcp.controller._msdcs.vashdomen.lan srv-port=389 srv-priority=0 srv-target=dc1.vashdomen.lan srv-weight=100 type=SRV
В указанной записи srv-target — это dns-имя домена, которое через А-запись резолвится в IP. В самом начале поста, первая консольная команда (в примере):
/ip dns static add address=10.0.0.2 name=controller.koobik.lan type=A
Для Вашего примера это будет А-запись:
/ip dns static add address=Х.Х.Х.Х name=dc1.vashdomen.lan type=A
Соответственно, во всех остальных SRV-записях это имя будет неизменно в рамках SRV-записей одного домена dc1.vashdomen.lan. Если доменнов (и доменных контроллеров) несколько — тогда для каждого блока SRV-записей своё А-имя для доменного контроллера.
Вы правы, это понятно и очевидно из вашей статьи, и я спросил несколько о другом.
_ldap._tcp.controller._msdcs.koobik.lan немного не похоже на запись controller.koobik.lan
поскольку между именами сервера и домена присутствует _msdcs — только это и смутило.
Но вы развеяли мои опасения и я с честным видом экспроприировал ваш пример, большое спасибо,
и у меня в 7-й записи вашего примера srv-target значится как _ldap._tcp.dc1._msdcs.vashdomen.lan
Прошу великодушно простить и за второй вопрос..
SRV записи типа: aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee … вот если с сервера ubuntu (это там где всякие samba, bind9, kerberos-ы живут), оттуда как-то извлечь можно?
Я почему спрашиваю.. нашёл я в /var/log/samba/log.wb-dc1 что-то типа..
«sam_sid_to_name: possible deadlock — trying to lookup SID S-1-5-aa-bbbbbbbbbb-cccccccccc-dddddddddd-eee»
(и таких три штуки разных цифирно в окончании eee), но оно, кажется, не похоже на искомое.
Не проверял, но уверен, что в интерфейсе Mikrotik (IP — DNS — Cache) эти хосты будут со статусом unknown.
Либо по аналогии выловить wireshark`ом.
Увлекательнейшее занятие, я вам доложу, не имея точного знания о инструменте, приёмах, области и объекте поиска,
пользоваться wireshark`ом. Столько нового и интересного узнал о своей сети. Должен сразу поблагодарить за совет.
Приятно и с пользой провёл вечер — это вовсе не сарказм. Спасибо.
Пусть не сразу, но отловил явное обращение к адресу искомого вида в пакетах адресованных «куда.то.там.255»
Как я понял, система вошедшая в домен, таки получила этот ID у контроллера и попыталась поискать нужные адресочки
broadcast-запросом.
Только однажды и больше нигде (в mikrotik-е тоже нет) .
Если позволите, задам вопрос третий.
Как вы понимаете, истинный Anykey Allworkhere простых путей не ищет — это не есть путь джедая!
Всё дело в том, что задача-то предо мной стоит такая:
Научить routeros dns-сервер И ubuntu/ms windows server «ad ds» — dns-сервер работать в паре.
По сути нужны «костыли» реализующие рекурсивный обмен dns-записями сообразно простой логике:
dns и dhcp при шлюзе(ах) — главные для клиентов сети, но управляемые контроллером(ами) домена(ов),
dns и dhcp контроллера(ов) — главные для клиентов сети, когда оборудование шлюза(ов) недоступно,
аварийное/штатное/тестовое отключение-включение-добавление оборудования шлюза(ов)/контоллера(ов)
на работоспособность локальной сети не влияет.
Мне кажется, просто добавить десяток другой статичных записей dns на статично расположенный контроллер
в оборудование шлюза — видимо маловато.
Как на счёт автоматизации предложенных вами ювелирной точности процессов из инструкции?
Но чтоб брать их с контроллера.. ну там скрипт какой.. «Эй_контроллер_отзовись.ssh где.ты.там.есть»
Чтоб давать что-то контроллеру.. «Даёшь_добро_постучавшемуся.ssh где.он.там.был»
Или придётся копать radius?
Да, идея перенести скрипт на Микротик есть, руки никак не дойдут. Это было бы правильно и с точки зрения избавления от дополнительного узкого места (виртуалка со скриптом) и с точки зрения постоянного поддержания таблицы dns в актуальном состоянии.
В процессе тестирования связки Mikrotik+MS Windows Server 2019 обнаружилась следующая странность
всплыли в кэше NDS записи с флагом negative
_ldap._tcp.pdc._msdcs.vashdomen.lan и dc1.localdomain
если привести в соответствие вашей инструкции, видимо должно быть что-то такое
add name=_ldap._tcp.pdc._msdcs.koobik.lan srv-port=389 srv-priority=0 srv-target=d-srv-1.koobik.lan srv-weight=100 type=SRV
add address=10.0.0.2 name=controller.localdomain type=A
Правильно ли я понял, что эти записи нужно добавлять?
В документации (https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/c1987d42-1847-4cc9-acf7-aab2136d6952) по поводу этой SRV-записи указано следующее:
If the DC is also holds the PDC Emulator FSMO role for its default NC, then it registers SRV records with Service.Proto.Name equal to the following.
_ldap._tcp.pdc._msdcs.X
Так что да, в Вашем случае эту запись следует добавить.
Благодарю.
Тут ещё приплыли DNS-записи в Mikrotik-кеш с тем же флагом negative.
_ldap._tcp.default-first-site-name._sites.domaindnszones.vashdomen.lan
_ldap._tcp.default-first-site-name._sites.forestdnszones.vashdomen.lan
_ldap._tcp.domaindnszones.vashdomen.lan
_ldap._tcp.forestdnszones.vashdomen.lan
domaindnszones.vashdomen.lan
forestdnszones.vashdomen.lan
Но я не увидел явного соответствия в диспетчере DNS, а значения выдумывать — видимо не стоит.
Помогите разобраться.
Это для случаев распределённой доменной структуры, когда используется «лес».
Если роль DNS оставить на контроллере домена (Майкрасофт не рекомендует удалять эту роль, ЕМНИП), то достаточно просто добавить форвард на микротик:
/ip dns static
add forward-to=192.168.xxx.yyy regexp=».*\\.domain\\.local» type=FWD
И все будет работать, если DHCP на микротиках и DNS, раздаваемый по dhcp так же указывает только на микротик
Насколько мне не изменяет память данная реализация ровно противоположна рекомендациям Майкрософт. В их идеологии роутер должен заниматься только трафиком и ничем иным. Никаких DNS, DHCP на роутере быть не должно. Все запросы DNS, DHCP роутер должен пересылать Windows и не более того.
А можно рассмотреть еще один вариант?
Есть производство с офисом, плюс 2 удаленных офиса бухгалтерии, и удаленная площадка с серверами. Итого 4 разных точки, которые собираются в один L2tp сервер, тоже на удаленной площадке.
1 — сеть к ad01
2 — бухи
3 — бухи
4 — сервер терминалов 1с + ad02
5 — мой домашний микротик для связки их всех. по L2TP
Вопрос: на всех микротиках, участвующих в туннелях надо указать эти настройки в вашей статье?
Сервер терминалов 1с то и дело тупит и не дает быстро подключиться по RDP, контроллер ad02 выручил в ситуации, но по неизвестной причине перестали идти репликации и сейчас вот сижу мучаюсь, он не заходит в домен, ну никак… Хотя ранее работал… но правда 2 дня..
Я уже и винду на нем переустановил, но он просто не хочет заходить в домен.
То ли в MTU где то проблема, то ли в настройках, указанных в вашей статье.
> на всех микротиках, участвующих в туннелях надо указать эти настройки в вашей статье?
Только на тех, которые выступают в качестве dns для клиентских машин.
При проблеме с MTU пакеты просто перестают ходить. А разобраться, где затык в репликации поможет анализ пакетов (например, wireshark`ом).