Защита от DNS-утечек

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

Как происходят DNS-утечки

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

Without DNS proxy:
┌──────────────┐         ┌─────────────┐
│ Your device  │ ──────► │ ISP DNS     │ ← DNS leak!
│              │         └─────────────┘
│ ── VPN ────► │         ┌─────────────┐
└──────────────┘ ──────► │ VPN Server  │ ← Regular traffic
                        └─────────────┘

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

Как DNS-прокси rVPN предотвращает утечки

DNS-прокси rVPN работает локально на вашем устройстве. Он получает DNS-запросы и пересылает их через зашифрованный VPN-туннель к серверу, который их разрешает:

With DNS proxy enabled:
┌──────────────┐         ┌─────────────┐
│ Your device  │         │ ISP DNS     │ ← Not used
│              │         └─────────────┘
│ [DNS proxy]  │ ──────► │ VPN Server  │ ← Encrypted tunnel
└──────────────┘         └─────────────┘

Ваш провайдер не видит DNS-запросов. Всё DNS-разрешение происходит внутри зашифрованного туннеля.

Интеграция с раздельным туннелированием

DNS-прокси учитывает правила раздельного туннелирования:

Тип домена	Поведение
Домены обхода	Разрешаются локально (не через VPN)
Заблокированные домены (реклама/трекеры)	Сразу возвращают NXDOMAIN
Все остальные домены	Разрешаются через VPN-туннель

Это значит:

Внутренние стриминговые сайты, которые вы обходите, разрешаются локально (без накладных расходов VPN)
Блокировщик рекламы работает, не отправляя запросы к VPN-серверу
Все остальные домены — приватны

Настройка

macOS

1. Включите DNS-прокси в client.toml:

[dns_proxy]
enabled        = true
listen_address = "127.0.0.1:53"

2. Запустите клиент с правами root (нужно для занятия порта 53):

sudo rvpn -c ~/.config/rvpn/client.toml

3. Настройте системный DNS:

Системные настройки -> Сеть -> ваше подключение -> Подробности -> DNS

Добавьте 127.0.0.1 как основной DNS-сервер. Удалите остальные записи.

Или через командную строку:

sudo networksetup -setdnsservers Wi-Fi 127.0.0.1

Для проверки:

# Should show 127.0.0.1
networksetup -getdnsservers Wi-Fi

# Should return your VPN server's IP
dig @127.0.0.1 api.ipify.org

Чтобы восстановить исходный DNS:

sudo networksetup -setdnsservers Wi-Fi empty

Linux

Вариант 1: прямое редактирование resolv.conf

Запустите клиент под root:

sudo rvpn -c ~/.config/rvpn/client.toml

Отредактируйте /etc/resolv.conf:

nameserver 127.0.0.1

Вариант 2: systemd-resolved (рекомендуется)

Добавьте в /etc/systemd/resolved.conf:

[Resolve]
DNS=127.0.0.1

Затем перезапустите:

sudo systemctl restart systemd-resolved

Проверьте:

resolvectl status | grep DNS

Linux с NetworkManager

Редактировать соединение: nm-connection-editor
Параметры IPv4 -> Метод: Вручную
Добавьте DNS-сервер: 127.0.0.1
Сохраните и переподключитесь

Тестирование DNS-утечек

Посетите эти сайты с включённым VPN:

Показанные DNS-серверы должны быть DNS вашего VPN-сервера (или значениями dns_servers, настроенными в вашем server.toml), а не DNS вашего провайдера.

Как работает DNS-разрешение в TUN-режиме

В TUN-режиме клиент получает dns_servers от сервера через DHCP и автоматически их использует. DNS-прокси всё же рекомендуется в SOCKS5-режиме, поскольку TUN-режим имеет встроенную обработку DNS.

Конфигурация DNS на сервере

[server.network]
nat_enabled = true
dhcp_range   = "10.200.0.0/24"
dns_servers  = ["1.1.1.1", "8.8.8.8"]

Эти DNS-серверы передаются TUN-клиентам. Клиент использует их напрямую для DNS-разрешения.

Собственные DNS-серверы

Чтобы использовать конкретных DNS-провайдеров через VPN-туннель:

На стороне сервера (передаётся TUN-клиентам):

[server.tun]
dns_servers = ["1.1.1.1", "8.8.8.8"]   # Cloudflare + Google

Или ориентированный на приватность выбор:

[server.tun]
dns_servers = ["9.9.9.9", "149.112.112.112"]   # Quad9

dns_servers принимает только IP-литералы; имена хостов не пройдут парсинг.

На стороне клиента в SOCKS5-режиме:

DNS-прокси пересылает запросы серверу, который разрешает их через dns_servers. Чтобы использовать конкретный DNS через туннель, настройте его на сервере.

DNS-серверы для доменов обхода (локальный DNS-фолбэк)

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

Чтобы предотвратить это, rVPN отправляет сырые UDP DNS-запросы напрямую к публичным DNS-серверам для доменов обхода, полностью пропуская системный резолвер:

Настройка	По умолчанию	Назначение
`nameservers`	`["223.5.5.5:53", "1.1.1.1:53", "8.8.8.8:53"]`	Публичные DNS-серверы для разрешения доменов обхода

Настройте в client.toml:

[dns_proxy]
enabled     = true
nameservers = ["223.5.5.5:53", "119.29.29.29:53", "1.1.1.1:53"]

Пользователям из Китая: поставьте DNS в Китае первым (например, AliDNS 223.5.5.5 или DNSPod 119.29.29.29) для лучшей задержки на внутренних сайтах.
Всем остальным: порядок по умолчанию хорошо работает по всему миру.
Эти серверы используются только для доменов обхода. Туннельные домены по-прежнему разрешаются через зашифрованный VPN-туннель.

DNS-over-HTTPS и DNS-over-TLS

rVPN не проксирует сырые запросы DNS-over-HTTPS (DoH) или DNS-over-TLS (DoT) от клиентских приложений.

Локальный DNS-прокси перехватывает традиционные UDP DNS-запросы от операционной системы. Для доменов, которые должны идти через туннель, он пересылает их серверу через зашифрованный WebSocket-туннель rVPN, используя собственный DNS-протокол (не DoH и не DoT). Сервер разрешает их через свой стандартный системный DNS-резолвер. Настроек DoH/DoT на стороне сервера в настоящее время нет.

Устранение проблем с DNS

Домены не разрешаются

Проверьте, что DNS-прокси запущен: dig @127.0.0.1 example.com
Убедитесь, что listen_address в client.toml совпадает с системной настройкой DNS
Попробуйте другой DNS-сервер: dig @8.8.8.8 example.com

DNS-прокси не запускается

Порт 53 может быть занят: sudo lsof -i :53
Попробуйте порт 5353 (root не требуется)

Медленное DNS-разрешение

Попробуйте другие DNS-серверы (обычно Cloudflare 1.1.1.1 — самый быстрый)
Уменьшите dns_cache_ttl в client.toml для часто меняющихся доменов

DNS утекает, несмотря на прокси

Убедитесь, что в системных настройках нет других DNS-настроек
Проверьте настройки DNS браузера (Firefox может переопределять системный DNS)
Chrome (Desktop/Android): отключите Безопасный DNS в настройках Chrome: Настройки → Конфиденциальность и безопасность → Безопасность → Использовать безопасный DNS → выключить. Затем очистите DNS-кеш Chrome: перейдите на chrome://net-internals/#dns и нажмите Clear host cache.
iOS Chrome: если сайты не разрешаются, принудительно закройте приложение или очистите данные браузера, чтобы сбросить DNS-кеш.
Убедитесь, что не запущен DNS-резолвер без VPN (например, mDNSResponder)