DNS в микротике⁠⁠

"Мыши плакали, кололись, но продолжали жрать кактус" :)))

Как было бы проще - покажи ты конфиг.
Смотри, исходя из моей схемы:
R1 - роутер с головным DNS
R2 - роутер "филиала"
предполагаю, что могут быть еще роутеры филиалов R3/R4... с такими же примерно настройками.

На R1 ты поднимаешь службу DNS и разрешаешь remote request (лучше файерволом разрешить только с доверенных IP доступ на input 53 tcp/udp).

На R2...R100 делаешь DNS сервером R1:
ip dns set servers=10.0.0.1
обязательно убираешь dynamic-servers (в настройках DHCP-client галка use-peer-dns или в pppoe соединении - я ж хз что у тебя где). Но в /ip dns print не должно быть dynamic-servers.

Далее, на R2...R100 делаем netwatch:

/tool netwatch add comment="CHANGE DNS IF TUNNEL DOWN" down-script="/ip dns set servers=8.8.8.8" host=10.0.0.1 interval=10s up-script="/ip dns set servers=10.0.0.1"

То есть - когда есть пинг на 10.0.0.1 - туннель поднят - DNS запросы идут в R1, туннель упал - ставится 8.8.8.8 и у клиентов за R2 только интернет (все равно ж сервера за R1 недоступны - туннель лежит).

Если туннель туда-сюда постоянно дергается, есть смысл добавить еще и сброс DNS кеша при переключении, чтобы меньше было "залипаний" на недоступные IP. Тогда netwatch будет выглять так:

/tool netwatch add comment="CHANGE DNS IF TUNNEL DOWN" down-script="/ip dns set servers=8.8.8.8\r\n/ip dns cache flush" host=10.0.0.1 interval=10s up-script="/ip dns set serve

rs=10.0.0.1\r\n/ip dns cache flush

Всем клиентам за R2 отдаешь DNS-сервером 192.168.2.1.
В R2 соответственно, тоже должен быть разрешен remote-request для клиентов за ним. Всем остальным IP запрещаешь доступ на 53 порт tcp/udp.

И все, профит.

Эту тему выбрал в качестве "лички". Можем продолжить в основной. Проблемы с отвалом с ошибкой 99?

Ну ок, можешь описать проблемы? Я тоже заинтересован, потому что чем больше фактуры, тем быстрее разрабы Сбера шевелятся. Сам заметил, что от ОС на ПК зависит, на 10-11 виндах работает без сбоев, на 7 или хр нужен какой-то специальный драйвер, с несколькими крупными клиентами помогла переустановка инженером Сбера

Хз, кто такой Андрюха. Так а что не так с единым ДНС в сети? Что не работает?

Привет. Если у тебя, как у айтишника на аутсорсе, есть проблемы с интеграцией с козенами (биометрическими), напиши в тг @Livedorm
Есть выходы на сопровождение сбера

Как то неочевидно приложение информирует об ответе.

Если R2 имеет доступ в интернет и ВПН линк между R1 и R2 постоянен, а не поднимается по желанию - то и пусть все запросы в ДНС с R2 идут через R1. Это нормально, задержек видимых глазу быть не должно.

Но вообще, если это корпоративная сеть, то идеально поднятие единого DNS сервиса. Будь то на микротике, Windows Server или Linux Server машинах.

Играться с приоритетностью DNS можно, но это всегда костыли. И крайне не советую использовать layer7 филттрацию, как где-то тут в ответах писали. Это работает так: пакет полностью разбирается с 7 уровня до 2 и Мик анализирует есть там что-то или нет, что подходит под правило. И если такого трафика будет много (некоторые вообще весь трафик разбирают одним правилом) - проц погибает. Даже у относительно мощных железяк.

Поэтому мой совет: если надо рулить трафиком через ДНС ( что-то заворачивать в локалку, что-то банить) - единый ДНС сервер. Если ВПН падает часто - костыльное решение на его IP вешаем Netwatch и скриптом меняем ДНС на R2 на глобальный и потом обратно когда туннель встал. Но этого прям костыль, проще добиться стабильности Линка. Либо поднять ДНС в той точке, которая доступна всегда и всем.

Попробуйте отключить сторонник DNS в нижестоящих микротиках.

Даю совсем простой ответ на вопрос "Нафига тут конкретика из конфигов?" - потому что гладиолус.

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

Так и тут - ты приходишь в сообщество за бесплатным(!!!) советом и просишь поделиться мудростью и решить свою проблему. Но на все наводящие вопросы машешь рукой - типа сами додумайте, че я там накрутил.

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

По теме, из того, что я понял, собрал на коленке схему - у меня все работает. Скриншоты прилагаю и схемы и конфигураций - мне не жалко.

Извини, если читается как наезд, ничего личного. Ты не первый и, увы, не последний такой, устал...

Мда, не перестает народ пытаться тренировать телепатию.
Дайте для начала хотя бы результат команд
ip dns export
и
ip firewall filter export

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

а если пойти по прям простейшему варианту, в основной микрот поставить правило на 53 tcp/udp порт с ip адреса 2 микрота самым первым с пометкой лога и посмотреть, идут ли вообще пакеты на него

Если совсем просто то нужно проверить отдаёт ли этот микротик dns ответ компу за другим микротиком. Это проверено? Держу пари что нет

Запросы на 2 микротике - с самого микротика?
Если да, то возможно на микротиках закрыты порты dns в firewall 53 порт tcp/udp.

Или у пользователей?
Если у пользователей, то какие dns сервера отдает 2 микротик в dhcp server? Или идея, что первый обращается в интернет за dns, второй берет с первого и раздаёт уже с себя?

Может ты вообще запретил микротам запросы из вне, и сеть 2 микрота как локалку не обозначил.

В общем слишком много чего может быть. Нужна хоть какая-то информация о том, чего ты вообще хочешь и где затык, а именно нужны конфиги как ранее написали, firewall filter и dns.

На микроте 1 в днс-сервере прописываешь что тебе надо - я про твои сервисы, на остальных - в layer7 делаешь запись своего внутреннего домена, потом маркируешь все входящие на остальные микроты запросы днс по tcp/udp портам по layer7 , далее - dstnat этой маркировки на основной микрот. Я бы так наверное сделал.