Утечки DNS и как их избежать

Утечка DNS возникает, когда DNS-запросы уходят вне вашего зашифрованного туннеля. Это позволяет вашему провайдеру (ISP) или другим участникам на пути видеть запрашиваемые домены, даже если сам трафик проксируется или зашифрован VPN.

В рамках этого руководства «без утечки DNS» означает, что ваши DNS-запросы не уходят напрямую через линк вашего провайдера. Они должны проходить через ваш туннель (например, к VPS) или иной контролируемый вами путь.

Проверка на утечки

Воспользуйтесь любым из сервисов:

• browserscan.net
• dnsleaktest.com
• browserleaks.com
• controld.com
• nordvpn.com
• surfshark.com
• atrill.com

Решение: добавьте отдельный DNS-входящий интерфейс (inbound), который явно дозванивается до резолвера и отправляет запросы через ваш исходящий туннель.

Как возникает утечка и как её закрыть

На схеме ниже — путь DNS-запроса до и после настройки выделенного DNS-inbound.

Красные ветки — сценарии утечки: запросы уходят по линку провайдера напрямую. Зелёная ветка — корректный путь: DNS-inbound перехватывает запросы, маршрутизирующее правило направляет их в proxy outbound, и они выходят в публичный резолвер уже со стороны VPS. Блокировка QUIC не относится непосредственно к DNS, но закрывает параллельный канал, через который браузер может отправить IP-адрес в обход прокси.

Настройка в XRAYUI

Ваш основной inbound (например, dokodemo-door с включённым Follow redirect) предназначен для прозрачного перехвата (TPROXY) и пересылает трафик на исходный адрес назначения. Когда DNS-форвардер роутера (dnsmasq) обращается к 127.0.0.1, «исходного назначения» нет — это может вызывать зацикленность и нестабильную отправку DNS вверх по цепочке.

Создание выделенного DNS-inbound

Добавьте новый inbound типа DOKODEMO:

• Порт: локальный порт для DNS-inbound (например, 55100)
• Следовать перенаправлению: ВЫКЛ
• Адрес назначения: публичный резолвер (например, 8.8.8.8, 1.1.1.1, AdGuard) или ваш собственный DNS на VPS
• Порт назначения: 53
• Сеть: udp,tcp
• Сохраните.

Настройка транспорта (tproxy) и dialer

Откройте Трансопрт для этого DNS-inbound → Прозрачный прокси (tproxy) → настроить:

• Включите tproxy для inbound.
• Закройте окно и нажмите применить в основной форме.

Правила маршрутизации DNS запросов

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

• Создаем новое правило (желательно ближе к началу списка)
• Выбираем только наш днс inbound в качестве входящего соединения
• Выбираем наш прокси в качестве исходящего соединения
• Сохраняем правило. Больше ничего в нем настраивать не нужно.

Таким образом мы настроили маршрутизацию так, что все, что приходит в днс-инбаунд будет уходить в наш прокси аутбаунд.

Включение «Предотвращение утечек DNS»

Перейдите в Общие настройки → DNS и включите Предотвращение утечек DNS.

При включении XRAYUI делает две вещи:

1. Блокировка dnsmasq — в конфиг добавляется no-resolv, а строка servers-file= (резолверы, полученные от WAN) комментируется. dnsmasq пересылает запросы только в выделенный DNS-inbound Xray.
2. Защитная сетка на firewall — цепочка XRAYUI_DNS_LOCK подключается к filter:OUTPUT и filter:FORWARD и отбрасывает каждый UDP/TCP-пакет, идущий на порт 53. DNS-inbound слушает на другом порту (например, 55100), поэтому не попадает под эти правила; легитимный DNS уходит с роутера уже в виде проксированного протокола (например, TCP/443), а не UDP/53. Это перехватывает:
   • Ошибки конфигурации dnsmasq и другие локальные процессы роутера, пытающиеся обратиться к upstream напрямую.
   • LAN-клиентов, которые жёстко прописали 8.8.8.8 / 1.1.1.1 и обходят TPROXY.

Диагностика

• После включения опции перестаёт работать резолвинг имён — проверьте, что выделенный DNS-inbound действительно слушает (netstat -lun | grep <порт>) и что правило маршрутизации направляет dns-inbound в proxy outbound. Выключите опцию, поправьте конфигурацию и включите снова.
• Конкретное устройство всё ещё течёт — firewall-блокировка перехватывает только UDP/TCP 53. Устройства, использующие DoH (HTTPS, порт 443) или DoT (TCP 853), обходят её. Блокировка QUIC закрывает путь UDP/443; для TCP/443 DoH сейчас нужно блокировать конкретные IP резолверов на firewall или через правила маршрутизации.
• Сам роутер не может разрешить имена — dnsmasq должен пересылать запросы в inbound. Проверьте в /etc/dnsmasq.conf наличие строки server=<ip>#<port>, которую генерирует XRAYUI; если её нет — jq-фильтр обнаружения inbound не сработал (убедитесь, что у inbound settings.port равен 53).

Блокировка QUIC

QUIC — это протокол, использующий UDP порт 443. В некоторых случаях QUIC-трафик может обойти прозрачный прокси, что приводит к утечке вашего реального IP-адреса — особенно через IPv6.

Перейдите в Общие настройки → DNS и включите Блокировать QUIC. Это заблокирует весь QUIC-трафик (UDP 443) на уровне файрвола, заставляя браузер и приложения использовать обычный TCP HTTPS, который корректно проксируется через Xray.

Тестирование

Для тестирования нам необходимо будет создать дополнительное правило - проксирование трафика через наш прокси и укажем сервисы выше в нем (для примера возьмем browserleaks.com)

browserleaks.com
browserleaks.org
browserleaks.net

Заходим на browserleaks.com и убеждаемся, что все источники идут через ваш VPS.