Что означает в Mikrotik параметр «Allow Remote Requests»?

Окей, извиняюсь за повтор, но в общем я включил «allow remote requests» и добавил публичный IP-адрес этого роутера MikroTik как DNS-сервер для внешнего компьютера, и он не может разрешить DNS… У меня используется RouterOS v6.40.8. Я даже сделал правило в фаерволе: chain - dstnat, protocol - udp, dst.port - 53, action - redirect, to ports - 53… Что я упускаю? Почему я не могу использовать роутер как внешний DNS и использовать в нём статические маршруты?

Пробовал с этими правилами файрвола (думал, если не задашь это правило, он автоматически всё пропустит!?). Дело в том, что я вписал публичный IP прямо в DNS TCP/IP настройки внешнего компьютера моего роутера, но он всё равно ничего не разрешает... хотя я вижу, что с твоим первым правилом файрвола принимается около 285 UDP пакетов. Не понимаю, что я делаю не так... думал, достаточно просто включить «Разрешить удалённые запросы» — и дело с концом (конечно, с публичным IP на интерфейсе WAN).

Процесс DNS на маршрутизаторе всегда обрабатывает запросы от других процессов маршрутизатора по преобразованию FQDN в IP-адрес (например, когда вы вводите ping mikrotik.com в командной строке маршрутизатора, процесс DNS переводит mikrotik.com в IP-адрес). У процесса есть два источника информации — локальные статические DNS-записи, которые вы настраиваете, и внешние DNS-серверы. Адреса внешних серверов можно задавать вручную и/или получать через протоколы динамической настройки, такие как DHCP или различные альтернативы, встроенные в PPP-подобные протоколы. Процесс кэширует ответы от внешних серверов.

allow-remote-requests=yes разрешает процессу DNS слушать входящие запросы на UDP-порту 53 и обрабатывать их. Самому процессу DNS безразличен исходный адрес этих запросов. Так что обслуживание конкретного клиента зависит от настроек фаервола. Обычно фаервол игнорирует любые пакеты с WAN-интерфейса, кроме тех, которые он распознаёт (благодаря отслеживанию соединений) как ответы на ранее отправленные с WAN интерфейса пакеты.

Порядок правил фаервола имеет значение, поэтому правило action=accept chain=input protocol=udp dst-port=53 должно стоять на правильном месте в списке, чтобы работать так, как вы ожидаете.

Однако открывать локальный DNS-сервер для запросов с любого места из интернета — плохая идея, так как DNS — это UDP-служба, и очень просто сделать так, чтобы ваше устройство участвовало в DDoS-атаке, если оно настроено отправлять ответный пакет на исходный адрес входящего пакета. Если я хочу атаковать UDP-порт X на адресе x.x.x.x, достаточно отправить на ваш UDP-порт 53 DNS-запрос с исходным адресом x.x.x.x и исходным портом X; ваше устройство отправит ответ на этот адрес и порт, а мой настоящий адрес останется невидимым для цели — с точки зрения цели, атаку ведёте именно вы.

Ты уверен, что твой интернет-провайдер не фильтрует DNS-запросы, адресованные клиентам? Воспользуйся инструментом torch и проверь, не идут ли на твой публичный IP пакеты на TCP/UDP порт 53 на WAN-интерфейс... Ладно, вижу, ты упомянул, что счётчики фильтров растут. Но это не исключает фильтрацию IPS. Недавно на этом форуме была ситуация, когда провайдер фильтровал не входящие пакеты, а ответы. Когда пользователь спросил про это провайдера, тот прекратил такую практику (по крайней мере для этого конкретного пользователя).

Если torch не показывает ответы, то нет смысла звонить провайдеру — если бы он блокировал их, то ответы были бы видны в torch, но не доходили бы по сети провайдера до вашего компьютера. Так что следуйте инструкциям из моей автоматической подписи, скорее всего, проблема в настройках вашего файрвола.

Если бы провайдер блокировал запросы, ты бы их не увидел в torch. Раз ты их видишь, значит провайдер не блокирует. Если бы в torch были ответы, но клиент их не получал, тогда провайдер блокировал бы ответы. Но поскольку ответов в torch не видно, нельзя точно сказать, блокирует ли провайдер ответы или нет, зато видно, что либо DNS-сервер не отвечает на запросы (в это я сомневаюсь), либо маршрутизация у тебя отправляет их через другой порт, а не через WAN, по которому пришли запросы, либо их блокирует файрвол. Для torch условия должны выглядеть так, кроме имени интерфейса: src-address=0.0.0.0/0 dst-address=0.0.0.0/0 ip-protocol=udp port=53 Не обращай внимание, что src и dst иногда меняются местами — torch иногда странно себя ведёт. Если видишь пакеты в обе стороны (где-то 53 — это src-port, а где-то — dst-port), значит провайдер фильтрует ответы. Если 53 виден только как dst-port, но никогда как src-port — внутри твоего Tik что-то не так. И ещё важный момент — если клиент использует TCP для запросов к Mikrotik, всё понятно: DNS-сервер Mikrotik не поддерживает TCP-запросы.

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