Как завернуть dns трафик через vpn на mikrotik

При использовании VPN на маршрутизаторах Mikrotik часто возникает ситуация, когда основной пользовательский трафик уходит в туннель, а DNS-запросы продолжают отправляться напрямую через провайдера. Это приводит к утечке информации о доменных именах, даже если IP-трафик полностью инкапсулирован. Особенно заметно это при работе с публичными DNS-серверами или при использовании RouterOS в роли локального резолвера.

Заворачивание DNS трафика через VPN требует не только указания удалённого DNS-сервера, но и принудительного изменения маршрута для UDP и TCP пакетов на 53 порту. В RouterOS по умолчанию DNS-запросы, инициированные самим роутером, не подчиняются policy routing без дополнительной маркировки. Это означает, что даже при активном VPN интерфейсе DNS может игнорировать таблицу маршрутизации туннеля.

Практическая реализация строится на комбинации mangle-правил, отдельных routing table и корректной настройки параметра allow-remote-requests в DNS. Дополнительно требуется учитывать служебные запросы, кэширование, fallback-серверы и поведение DoH/DoT, если они используются. Без этих нюансов DNS либо перестаёт работать, либо частично выходит за пределы VPN.

В статье рассматривается прикладной подход к настройке Mikrotik, при котором все DNS-запросы клиентов и самого маршрутизатора стабильно передаются через VPN-туннель, без нарушения локальной сети и без зависимости от конкретного провайдера DNS.

Определение целей заворачивания DNS и выбор схемы маршрутизации

Перед настройкой маршрутизации DNS необходимо чётко определить, какой именно трафик должен уходить в VPN: запросы клиентов локальной сети, DNS-запросы самого Mikrotik или оба варианта одновременно. Эти сценарии требуют разных подходов. Клиентские запросы обычно проходят через цепочку forward и поддаются маркировке без ограничений, тогда как DNS, инициированный роутером, обрабатывается в output и по умолчанию использует основную таблицу маршрутов.

Если целью является скрытие доменных запросов пользователей, достаточно перенаправлять UDP и TCP трафик на порт 53 от LAN-интерфейсов в отдельную routing table, связанную с VPN. При этом Mikrotik может продолжать использовать провайдерский DNS для собственных нужд. Такой вариант снижает риск потери доступа к обновлениям RouterOS и облачным сервисам.

При задаче полного исключения провайдерского DNS требуется более жёсткая схема. В этом случае DNS-клиент RouterOS настраивается на удалённый адрес, доступный только через VPN, а все исходящие DNS-пакеты из цепочки output маркируются и направляются в таблицу маршрутизации туннеля. Без этого Mikrotik будет пытаться отправлять запросы напрямую, даже при наличии активного VPN-интерфейса.

Выбор между mark-routing и использованием отдельных routing table напрямую влияет на устойчивость схемы. Для постоянных VPN-подключений предпочтительно создавать отдельную таблицу с дефолтным маршрутом через туннель, а маркировку применять только к DNS-пакетам. Это снижает вероятность того, что при падении VPN DNS начнёт уходить в основной маршрут без контроля.

Дополнительно необходимо заранее решить, будут ли обрабатываться нестандартные варианты, такие как DNS over TCP, запросы к нестандартным портам или локальные резолверы на клиентах. Эти решения определяют набор firewall-правил и позволяют избежать частичных утечек DNS при нестабильной работе туннеля.

Подготовка VPN-интерфейса на Mikrotik для передачи DNS-запросов

VPN-интерфейс должен рассматриваться как полноценный выходной шлюз для DNS, а не как дополнительный маршрут. Это означает наличие стабильного IP-адреса, корректного MTU и подтверждённого доступа к удалённому DNS-серверу через сам туннель. До настройки маршрутизации необходимо убедиться, что с Mikrotik пингуется IP DNS-сервера при принудительном указании VPN-интерфейса.

Тип VPN напрямую влияет на обработку DNS-пакетов. При использовании WireGuard и IPsec IKEv2 маршрутизация строится через таблицы RouterOS, тогда как L2TP и SSTP чаще полагаются на динамически добавляемые маршруты. Для заворачивания DNS предпочтительны интерфейсы, где маршрут через туннель можно зафиксировать вручную и связать с отдельной routing table.

VPN-интерфейс не должен добавлять дефолтный маршрут в основную таблицу, если планируется выборочная маршрутизация. Параметры вроде add-default-route необходимо отключить, чтобы DNS не ушёл в туннель без контроля и не затронул остальной трафик. Управление маршрутом должно осуществляться только через явно заданные правила.

Важно заранее проверить прохождение UDP и TCP на 53 порту через VPN. Некоторые провайдеры туннелей блокируют или ограничивают UDP, что приводит к задержкам при резолвинге. В таких случаях DNS over TCP становится обязательным, и VPN-интерфейс должен корректно обрабатывать фрагментацию и MSS.

Отдельное внимание следует уделить NAT. Если удалённая сторона ожидает трафик от одного адреса, требуется правило src-nat или masquerade именно для VPN-интерфейса. Отсутствие NAT часто проявляется в виде тайм-аутов DNS, несмотря на доступность самого туннеля.

Настройка локального DNS-клиента RouterOS для работы через VPN

DNS-клиент RouterOS используется самим маршрутизатором для обновлений, разрешения имён в скриптах и обслуживания клиентов при включённом локальном резолвере. Для его работы через VPN необходимо вручную задать DNS-серверы, доступные исключительно по туннелю, и отказаться от автоматического получения адресов от провайдера.

В разделе IP → DNS следует отключить использование DNS, полученных по DHCP или PPP, иначе RouterOS будет периодически отправлять запросы в обход VPN. Адреса серверов рекомендуется указывать в виде IP, а не доменных имён, чтобы исключить начальный запрос вне туннеля при старте системы.

Параметр allow-remote-requests должен включаться только в том случае, если Mikrotik выступает в роли DNS для локальной сети. При этом необходимо учитывать, что все клиентские запросы будут сначала обрабатываться самим роутером, а уже затем передаваться через VPN, что повышает нагрузку на CPU при большом количестве клиентов.

Для исключения обходных путей следует явно задать режим работы с UDP и TCP. Если удалённый DNS стабильно принимает TCP-запросы, имеет смысл принудительно разрешить этот режим, чтобы избежать проблем с потерей UDP-пакетов внутри туннеля. Это особенно актуально при использовании IPsec и мобильных VPN.

Кэширование DNS в RouterOS должно быть включено, но размер кэша стоит ограничивать. Большой кэш снижает число запросов, уходящих через VPN, но усложняет диагностику маршрутизации и может скрывать ошибки в правилах mangle на этапе проверки корректности заворачивания.

Создание policy routing для принудительного направления DNS трафика

Первым шагом создаётся отдельная routing table, связанная с VPN-шлюзом. В неё добавляется дефолтный маршрут через VPN-интерфейс без влияния на основную таблицу. Это позволяет изолировать DNS-маршрутизацию от остального трафика и управлять ею независимо.

Далее настраивается маркировка пакетов в firewall mangle. Для DNS необходимо учитывать оба протокола и обе цепочки обработки:

• UDP и TCP на порт 53 для клиентских запросов в цепочке forward
• UDP и TCP на порт 53 для запросов самого роутера в цепочке output

Маркировка должна применяться с использованием mark-routing, а не mark-connection, чтобы маршрутизация выполнялась для каждого пакета независимо от состояния соединения. Это критично для DNS, где часть запросов может быть однократной.

После маркировки необходимо явно связать routing-mark с ранее созданной таблицей. RouterOS не делает этого автоматически, и отсутствие соответствия приводит к тому, что пакеты с меткой продолжают использовать main routing table.

При настройке важно соблюдать порядок правил:

1. Исключения для локальных адресов и служебных подсетей
2. Маркировка DNS-пакетов
3. Общие правила маршрутизации остального трафика

Неправильный порядок приводит к частичной обработке DNS или к ситуации, когда запросы клиентов заворачиваются, а DNS самого Mikrotik продолжает уходить напрямую. После применения policy routing необходимо проверить таблицу соединений и routing decisions для подтверждения фактического пути пакетов.

Маркировка DNS пакетов с помощью mangle в firewall

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

Для клиентских устройств используются правила в цепочке forward. Они применяются к пакетам, проходящим через маршрутизатор транзитом:

• protocol=udp, dst-port=53
• protocol=tcp, dst-port=53

Для DNS-запросов, инициированных самим Mikrotik, обязательна отдельная обработка в цепочке output. Без неё локальный DNS-клиент RouterOS всегда будет использовать основную таблицу маршрутов, игнорируя VPN.

Перед применением маркировки необходимо исключить локальные адреса и служебные подсети, чтобы DNS-запросы к внутренним серверам не попадали под policy routing. Эти правила должны располагаться выше в списке mangle и завершаться действием accept.

Тип действия следует выбирать mark-routing с уникальным именем метки. Использование mark-connection не даёт предсказуемого результата для DNS, так как UDP-запросы часто не формируют устойчивых соединений.

Критично соблюдать порядок правил:

1. Исключения для локальных и служебных DNS
2. Маркировка DNS в output
3. Маркировка DNS в forward

После настройки необходимо проверить счётчики правил mangle. Рост значений подтверждает, что DNS-пакеты действительно попадают под маркировку. Отсутствие счётчиков почти всегда указывает на неправильную цепочку, порт или протокол.

Исключение локальных и служебных DNS запросов из VPN маршрута

При заворачивании DNS через VPN критично заранее определить категории запросов, которые не должны покидать локальную сеть. К ним относятся обращения к внутренним DNS-серверам, резолвинг имён оборудования, а также служебные запросы, обеспечивающие работу самой инфраструктуры.

В первую очередь исключаются DNS-запросы к приватным IP-диапазонам. Для этого в mangle создаются правила с действием accept для адресов RFC1918 и локальных подсетей. Эти правила должны располагаться выше маркировки, иначе DNS к внутренним серверам будет ошибочно направляться в VPN и приводить к задержкам или тайм-аутам.

Отдельного внимания требуют служебные запросы самого Mikrotik. Обновления RouterOS, синхронизация времени, облачные сервисы и CAPsMAN могут использовать DNS вне пользовательского трафика. Если эти запросы отправляются через VPN, при его недоступности возможна потеря управления маршрутизатором. В таких случаях целесообразно исключать DNS-запросы от системных процессов по source-address или по интерфейсу.

Если в сети используется локальный DNS-резолвер или Active Directory, необходимо явно разрешить прямой доступ к нему, минуя policy routing. Это достигается исключением по IP-адресу сервера и предотвращает зацикливание запросов через VPN.

После настройки исключений важно проверить, что счётчики правил маркировки не увеличиваются при обращении к локальным именам. Отсутствие роста подтверждает, что служебные DNS остаются в основной таблице маршрутов и не затрагиваются VPN-политикой.

Проверка фактического маршрута DNS трафика и диагностика утечек

После настройки policy routing и mangle нельзя полагаться на конфигурацию как на доказательство корректной работы. Проверка должна опираться на наблюдение реального пути DNS-пакетов. В RouterOS это делается через встроенные средства мониторинга, а не через внешние тесты на стороне клиента.

Первым шагом анализируется таблица соединений. При выполнении DNS-запроса необходимо убедиться, что UDP или TCP с портом 53 имеет routing-mark, связанный с VPN-таблицей. Отсутствие метки указывает на ошибку в правилах mangle или неправильную цепочку обработки.

Дополнительно используется torch на физическом WAN-интерфейсе. Если при резолвинге доменных имён наблюдается DNS-трафик на внешнем интерфейсе провайдера, это прямой признак утечки. В корректной схеме такие пакеты должны появляться только на VPN-интерфейсе.

Для диагностики DNS самого маршрутизатора применяются ping и traceroute с принудительным указанием routing table. Это позволяет проверить, через какой шлюз RouterOS пытается достучаться до заданного DNS-сервера и не происходит ли автоматического fallback в основную таблицу.

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

Типовые ошибки при заворачивании DNS и способы их устранения

Отдельной ошибкой является указание DNS-серверов по доменному имени. В этом случае первый запрос всегда выполняется без VPN, что создаёт утечку ещё до применения policy routing. Для DNS в подобных схемах допустимы только IP-адреса.

После исправлений необходимо сбросить существующие соединения и очистить DNS-кэш. Без этого RouterOS может продолжать использовать ранее установленные маршруты, создавая ложное ощущение, что изменения не применились.

Вопрос-ответ:

Почему DNS-запросы продолжают уходить через провайдера, хотя весь трафик направлен в VPN?

В Mikrotik VPN не перехватывает DNS автоматически. Пользовательский IP-трафик может идти через туннель, а DNS, особенно инициированный самим роутером, обрабатывается через основную таблицу маршрутов. Если отсутствуют mangle-правила в цепочке output и отдельная routing table для DNS, запросы на порт 53 продолжают отправляться напрямую.

Нужно ли заворачивать DNS самого Mikrotik или достаточно клиентских запросов?

Это зависит от задачи. Если цель — скрыть активность клиентов, достаточно обработки цепочки forward. Если же требуется исключить любые обращения к провайдерскому DNS, включая обновления RouterOS, скрипты и облачные сервисы, тогда необходимо маркировать DNS в output и проверять маршрут запросов самого роутера.

Почему после настройки DNS через VPN периодически появляются тайм-ауты?

Чаще всего причина связана с потерей UDP-пакетов внутри туннеля или с некорректным MTU. Некоторые VPN-сервисы ограничивают UDP на 53 порту. В таких случаях помогает разрешение DNS over TCP и корректировка MSS для VPN-интерфейса.

Как убедиться, что DNS не выходит в интернет при падении VPN?

Необходимо проверить поведение при отключённом туннеле. Если DNS продолжает работать, значит маршрутизация переключается на основной шлюз. Для предотвращения этого добавляются filter-правила, блокирующие DNS-пакеты без нужной routing-mark, либо используется логика отслеживания состояния VPN-интерфейса.