MikroTik DNS VPN: как завернуть DNS-трафик в туннель и устранить утечки

Зачем заворачивать DNS-трафик через VPN на MikroTik

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

Заворачивание DNS-трафика через VPN решает несколько задач:

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

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

Выбор схемы: какие DNS-запросы должны идти через VPN

Перед настройкой необходимо определить, какой именно DNS-трафик должен уходить в туннель. Существует три основных сценария:

1. Только клиентские запросы: DNS-запросы от устройств в локальной сети (компьютеры, смартфоны) направляются через VPN, а сам MikroTik продолжает использовать провайдерский DNS для своих нужд (обновления, облачные сервисы). Это снижает риск потери доступа к служебным ресурсам.

1. Только запросы роутера: DNS-клиент RouterOS настраивается на удалённый сервер, доступный через VPN, но клиентские запросы обрабатываются локально. Такой вариант редко используется, так как обычно требуется скрыть запросы всех устройств.

1. Полное заворачивание: и клиентские, и роутерные DNS-запросы направляются через VPN. Это наиболее безопасный вариант, но требует более жёсткой настройки и учёта служебных запросов.

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

Рекомендуется начинать с первого сценария (только клиентские запросы), а затем, убедившись в стабильности, расширять на роутерные запросы.

Подготовка VPN-интерфейса и базовые настройки

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

/ping 1.1.1.1 interface=wg0 count=4

Замените wg0 на ваш VPN-интерфейс (например, l2tp-out1, sstp-out1). Если пинг не проходит, проверьте настройки VPN, NAT и firewall.

Важные моменты:

• Отключите автоматическое добавление маршрута по умолчанию для VPN-интерфейса, если планируется выборочная маршрутизация. В противном случае весь трафик уйдёт в туннель, что может быть нежелательно. Для WireGuard параметр add-default-route должен быть no.
• Проверьте MTU: для WireGuard рекомендуется MTU 1420, для L2TP/IPsec — 1400 или меньше. Неправильный MTU может вызывать фрагментацию и потерю DNS-пакетов.
• Убедитесь, что удалённый DNS-сервер доступен по UDP и TCP порту 53. Некоторые VPN-провайдеры блокируют UDP, поэтому может потребоваться DNS over TCP.
• Настройте NAT для VPN-интерфейса, если удалённая сторона ожидает трафик от одного адреса. Обычно используется masquerade для подсети VPN-клиентов.

Пример настройки NAT для WireGuard:

/ip firewall nat add chain=srcnat src-address=10.10.10.0/24 action=masquerade out-interface=ether1 comment="NAT for WireGuard"

Замените ether1 на ваш WAN-интерфейс.

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

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

1. Указать DNS-серверы вручную в разделе /ip dns set servers=1.1.1.1,8.8.8.8. Используйте IP-адреса, а не доменные имена, чтобы избежать начального запроса вне туннеля.
2. Отключить автоматическое получение DNS от провайдера по DHCP/PPP: в настройках DHCP-клиента установите use-peer-dns=no.
3. Включить allow-remote-requests=yes, если MikroTik выступает DNS-сервером для локальной сети. Это позволит клиентам использовать роутер как резолвер, а роутер будет передавать запросы через VPN.
4. Ограничить размер кэша DNS (например, cache-size=2048), чтобы не скрывать ошибки маршрутизации при диагностике.

Пример настройки:

/ip dns set servers=1.1.1.1 allow-remote-requests=yes cache-size=2048

Если вы планируете использовать DNS over TCP, убедитесь, что удалённый сервер поддерживает TCP-запросы. В RouterOS нет прямой настройки для принудительного TCP, но можно использовать mangle для изменения протокола, хотя это сложно. Обычно достаточно UDP.

Создание отдельной таблицы маршрутизации для DNS

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

В RouterOS 7 таблицы создаются командой:

/routing table add name=DNS fib

Затем добавьте в эту таблицу маршрут по умолчанию через VPN-интерфейс:

/ip route add dst-address=0.0.0.0/0 gateway=wg0 routing-table=DNS distance=1

Замените wg0 на ваш VPN-интерфейс. Важно, чтобы этот маршрут не влиял на основную таблицу маршрутизации. Для этого не добавляйте его в main.

Если вы используете несколько VPN-интерфейсов или хотите иметь запасной маршрут, можно добавить несколько записей с разными distance.

Проверить таблицу можно командой:

/ip route print where routing-table=DNS

Убедитесь, что маршрут активен (флаг A).

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

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

Для клиентских запросов (цепочка forward) добавьте правила:

/ip firewall mangle add chain=forward protocol=udp dst-port=53 action=mark-routing new-routing-mark=DNS passthrough=no
/ip firewall mangle add chain=forward protocol=tcp dst-port=53 action=mark-routing new-routing-mark=DNS passthrough=no

Для запросов самого роутера (цепочка output) добавьте аналогичные правила:

/ip firewall mangle add chain=output protocol=udp dst-port=53 action=mark-routing new-routing-mark=DNS passthrough=no
/ip firewall mangle add chain=output protocol=tcp dst-port=53 action=mark-routing new-routing-mark=DNS passthrough=no

Важно использовать passthrough=no, чтобы пакет не обрабатывался дальнейшими правилами mangle. Это ускоряет обработку и предотвращает случайную перемаркировку.

Порядок правил имеет значение: сначала должны идти исключения для локальных адресов, затем маркировка DNS. Если исключения расположены ниже, они не сработают.

Проверить счётчики правил можно командой:

/ip firewall mangle print stats

Рост счётчиков при DNS-запросах подтверждает корректность маркировки.

Исключения для локальных и служебных DNS-запросов

Не все DNS-запросы должны уходить через VPN. Запросы к внутренним DNS-серверам, локальным ресурсам и служебным службам должны обрабатываться напрямую, иначе они будут недоступны или вызовут задержки.

Создайте правила mangle с действием accept для следующих случаев:

• Приватные IP-диапазоны (RFC1918): 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16. Это исключит запросы к локальным DNS-серверам (например, 192.168.1.1).
• Локальные адреса роутера: 127.0.0.0/8, а также адрес самого роутера в LAN (например, 192.168.88.1).
• Служебные DNS-запросы: если у вас есть внутренний DNS-резолвер (Active Directory, Pi-hole), добавьте его IP в исключения.

Пример правил исключений (разместите их выше маркировки):

/ip firewall mangle add chain=forward dst-address=192.168.0.0/16 action=accept
/ip firewall mangle add chain=forward dst-address=10.0.0.0/8 action=accept
/ip firewall mangle add chain=output dst-address=192.168.0.0/16 action=accept
/ip firewall mangle add chain=output dst-address=10.0.0.0/8 action=accept

Также стоит исключить DNS-запросы к адресам, которые используются для обновлений RouterOS и облачных сервисов MikroTik. Обычно это домены *.mikrotik.com, но их IP могут меняться. Проще разрешить все запросы к не-приватным адресам, кроме тех, что должны идти через VPN, но это сложнее.

Проверьте, что после добавления исключений счётчики маркировки не растут при обращении к локальным именам.

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

После настройки необходимо убедиться, что DNS-запросы действительно идут через VPN. Существует несколько способов проверки:

1. Просмотр таблицы маршрутизации: выполните ip route print where routing-table=DNS и убедитесь, что маршрут активен.
2. Использование инструмента fetch: с роутера выполните fetch url=http://example.com — если DNS работает через VPN, запрос будет успешным. Но это не покажет путь.
3. Проверка счётчиков mangle: выполните ip firewall mangle print stats и посмотрите, увеличиваются ли счётчики правил маркировки при DNS-запросах.
4. Использование внешних сервисов: с компьютера в локальной сети откройте сайт типа dnsleaktest.com — он покажет, какие DNS-серверы видны извне. Если там отображается IP вашего VPN-сервера, значит DNS завёрнут корректно.
5. Анализ трафика на WAN-интерфейсе: с помощью torch или sniffer можно увидеть, уходят ли пакеты на порт 53 напрямую. Если на WAN-интерфейсе нет DNS-пакетов, значит они идут через VPN.

Пример команды для просмотра DNS-пакетов на WAN:

/tool sniffer quick interface=ether1 port=53

Если вы видите DNS-пакеты на WAN, значит есть утечка. Проверьте правила mangle и маршрутизацию.

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

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

• DNS не работает после настройки: проверьте, доступен ли удалённый DNS-сервер через VPN. Возможно, он блокирует запросы с IP вашего VPN-сервера. Попробуйте использовать другой DNS (например, 1.1.1.1 вместо 8.8.8.8).
• Сайты не открываются, хотя пинг проходит: это указывает на то, что DNS-запросы не доходят до сервера. Проверьте правила mangle для цепочки forward и output, убедитесь, что маршрут в таблице DNS активен.
• Частичные утечки: если часть запросов уходит напрямую, проверьте порядок правил mangle. Исключения должны быть выше маркировки. Также убедитесь, что вы не используете mark-connection вместо mark-routing.
• Проблемы с MTU: если DNS-ответы большие (например, при DNSSEC), может происходить фрагментация. Уменьшите MTU на VPN-интерфейсе (например, до 1400) и добавьте правило change-mss.
• Конфликт с другими правилами маршрутизации: если у вас уже есть policy routing для другого трафика, убедитесь, что правила не пересекаются. Используйте разные routing-mark.
• Служебные запросы роутера не работают: если вы завернули DNS роутера, но обновления RouterOS перестали работать, добавьте исключения для доменов MikroTik или используйте отдельный DNS-сервер для служебных нужд.

Если проблема не решается, временно отключите маркировку и проверьте, работает ли DNS напрямую. Затем постепенно добавляйте правила, проверяя после каждого шага.

Дополнительные соображения: DoH, DoT и IPv6

Современные DNS-серверы поддерживают шифрование DNS через HTTPS (DoH) или TLS (DoT). RouterOS 7 поддерживает DoH в настройках DNS, но это не решает проблему маршрутизации — запросы всё равно могут уходить напрямую, если не настроен policy routing.

Если вы используете DoH на роутере, убедитесь, что трафик к DoH-серверу (например, 1.1.1.1:443) также маркируется и направляется через VPN. Для этого добавьте правила mangle для порта 443 и IP-адреса DoH-сервера.

Что касается IPv6, если у вас включён IPv6, DNS-запросы могут идти по IPv6 в обход VPN. Рекомендуется отключить IPv6 на роутере, если он не используется, или настроить аналогичную маркировку для IPv6-трафика.

Также учитывайте, что при использовании локального DNS-резолвера (например, Pi-hole) на отдельном устройстве, его запросы будут идти через VPN только если настроена маршрутизация для этого устройства. В противном случае они будут уходить напрямую.

Наконец, помните о кэшировании: если DNS-кэш роутера содержит записи, полученные до настройки VPN, они могут быть использованы. Очистите кэш командой /ip dns cache flush после изменения конфигурации.

Вопросы и ответы