Запрос на новую функцию: переадресация по доменам в DNS

Я тоже с этим согласен, это не должно быть так сложно реализовать.

Я поддерживаю Вакко, это была бы отличная функция для удаленных сайтов, использующих VPN для доступа к серверам... Они бы не теряли разрешение DNS, когда VPN выходит из строя. В настоящее время мы используем обходное решение brainsucker для небольших сайтов, но за ним несколько трудно следить.

Эмм, ты действительно думаешь, что стоило поднимать этот старый тред спустя шесть лет? И как именно эта информация должна его завершить? Это все тот же старый и непривлекательный (хотя и довольно умный, в этом нет сомнений) L7 хак, который обходит DNS кэш роутера, не работает с tcp, не может быть использован с IPv6, и совершенно не пригоден для администраторов. В качестве бонуса, ваш regexp совершенно неточный: он совпадает с office.local, но также и с notoffice.local, office-local.com и так далее. Ваш единственный аргумент в том, что любое упоминание об этой недостающей функции - это уже хорошо.

Нет, потому что когда происходит сопоставление с вашим фильтром L7, соединение уже установлено и не может быть перенаправлено куда-то еще. К счастью, клиенты, похоже, не используют TCP (но такое тоже может случиться). Это должно быть правильное регулярное выражение, безусловно. Но DNS-пакеты не содержат точек. Вместо этого они имеют одиночные байты, содержащие длину следующей части имени. Для ваших индивидуальных доменов это: \x05intra\x08mydomain\x03net \x03168\x03192\x07in-addr\x04arpa \x017\x0210\x07in-addr\x04arpa Чтобы помочь с ложными срабатываниями, вы также можете добавить это в конец: .\x01, где “.” соответствует типу записи (за исключением некоторых редких с кодом > 255), а \x01 — это класс запроса, который всегда равен 1 (для нормального использования). Это не так уж важно для достаточно сложных доменов, как ваш. Без этого вы получите ложное срабатывание, например, для intra.mydomain.net.someotherdomain.com, но маловероятно, что когда-либо будет запрос на такое имя.

Я голосую за эту функцию. Легко реализовать — но всё ещё не реализовано.

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

У меня была такая же проблема, но я нашел, по крайней мере, временное решение. Копирую и вставляю из своего блога: http://brainsuckerna.blogspot.com/2010/02/mikrotik-routeros-and-domain-active.html Я использую роутер Mikrotik дома, с RB150, который постоянно обрабатывает соединение с провайдером (PPPoE) и с моим офисом (VPN через интернет). Однако так как роутер использует DNS провайдера, невозможно работать с общими папками или выполнять любые другие задачи домена (в то время как офисные IP-адреса легко доступны). Все, что связано с Active Directory, будет проваливаться, так как любой компьютер в доме не сможет разрешить контроллеры домена. Как это исправить: добавил layer7 матч для \x06\x5Fmsdcs\x08mydomain\x03com (вам нужно заменить mydomain.com на адрес вашего домена). Каждая часть домена предшествуется \x и числом символов в шестнадцатеричном формате, \x5F — это символ _. Когда компьютер пытается найти серверы Active Directory, он запрашивает несколько DNS-записей, все заканчивающиеся на _msdcs.yourdomain.com. /ip firewall layer7-protocol add comment=“” name=activedirectory regexp= “\x06\x5Fmsdcs\x06itsoft\x02by” добавил mangling для маркировки пакетов DNS-запросов, соответствующих нашему правилу layer7 и нашему DNS-серверу как защищенной /ip firewall mangle add action=mark-packet chain=prerouting comment=“” disabled=no dst-address= 192.168.0.200 dst-port=53 layer7-protocol=activedirectory new-packet-mark=activedirectory passthrough=yes protocol=udp добавил правило dst-nat для маршрутизации специфических запросов Active Directory к реальному серверу домена /ip firewall nat add action=dst-nat chain=dstnat comment= “перенаправить DNS-запросы Active Directory” disabled=no dst-port=53 packet-mark=activedirectory protocol=udp to-addresses=10.10.0.201 to-ports=53 вот и все. Это работает, по крайней мере, в моей конкретной конфигурации. Возможно, есть более простые решения, но я не смог найти ни одного.

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