Кратко: утечка DNS означает, что DNS‑запросы отправляются не по туннелю (VPN/прокси), а напрямую через ваш обычный сетевой интерфейс — и потому видны провайдеру/хостингу. Чтобы её устранить, нужно (1) заставить клиента использовать DNS-сервер, доступный через VPN/прокси, и (2) заблокировать любые DNS‑запросы вне туннеля. Ниже — практическое руководство с командами и проверками.
1) Диагностика — что именно «утекает»
- На клиенте: посмотреть текущие резолверы (Linux: cat /etc/resolv.conf или systemd-resolve --status; Windows: ipconfig /all).
- Тестировать: https://www.dnsleaktest.com, https://ipleak.net, команда dig @1.1.1.1 whoami.cloudflare или tcpdump -i <интерфейс> port 53 чтобы увидеть реальные пакеты.
- Уточните: какой у вас VPN/прокси (OpenVPN, WireGuard, SOCKS5, HTTP(S), Shadowsocks и т. п.), ОС клиента (Windows/macOS/Linux/Android/iOS), имя интерфейса туннеля (tun0/wg0/…) — тогда дам точные команды.
2) Настройте использование DNS через VPN/прокси
- OpenVPN (сервер/клиент)
- На сервере push'ните DNS: в серверном .conf добавьте:
push "dhcp-option DNS 10.8.0.1" (или другой DNS внутри VPN)
- На клиенте проверьте, чтобы опции принимались. В Windows OpenVPN(ovpn) можно использовать параметр block-outside-dns (только Windows OpenVPN 2.3.9+):
-- добавьте строку block-outside-dns в .ovpn.
- Включите полный маршрут: push "redirect-gateway def1 bypass-dhcp" чтобы весь трафик шёл через VPN.
- WireGuard
- В файле конфигурации клиента укажите:
DNS = 10.0.0.1
- Убедитесь, что в AllowedIPs прописано 0.0.0.0/0 (и ::/0, если нужно IPv6) — тогда весь трафик, включая DNS, идет через WG.
- На Linux клиенте /etc/resolv.conf/ systemd-resolved должен обновляться wg-quick (wg-quick автоматически пытается менять DNS при использовании wg-quick).
- SOCKS5 прокси / браузеры
- SOCKS5: в Firefox включите network.proxy.socks_remote_dns = true, чтобы DNS резолв делался через SOCKS прокси.
- HTTP-прокси не решает DNS за вас — браузер всё равно будет резолвить локально, используйте SOCKS или VPN полный туннель.
- Для приложений, которые не поддерживают удалённый DNS через SOCKS, рассмотрите локальный transparent proxy или туннелирование всего трафика.
- DoH/DoT/локальный резолвер
- Можно запустить локальный stub (dnscrypt-proxy, stubby, unbound) и настроить его отправлять DNS через TLS/HTTPS к выбранному провайдеру, но убедитесь, что DoH-запросы идут по VPN.
- Если DoH клиент делает запросы напрямую, он тоже может утекать — убедитесь, что маршрутизация/файрвол блокируют прямой доступ.
3) Блокировка DNS вне туннеля (firewall) — очень эффективно
- Основная идея: разрешить исходящие DNS (udp/tcp порт 53 и, если нужно, ТСL 853) только через интерфейс туннеля (tun0/wg0), всё остальное — DROP.
Примеры iptables (выполнить с привилегиями root; замените tun0 на имя вашего интерфейса туннеля):
iptables -I OUTPUT -o tun0 -p udp --dport 53 -j ACCEPT
iptables -I OUTPUT -o tun0 -p tcp --dport 53 -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -j DROP
iptables -A OUTPUT -p tcp --dport 53 -j DROP
Если хотите также блокировать DoT/DoH по порту 853/443 (будет сложнее, т.к. 443 — общий порт), можно блокировать UDP/TCP 53 и разрешить на конкретные IP/интерфейс.
Для nftables логика аналогична — разрешаем на интерфейс туннеля, затем drop для остальных.
Windows (если VPN клиент не содержит блокировки)
- Для OpenVPN: в .ovpn добавить block-outside-dns.
- Можно также настроить встроенный брандмауэр для блокировки исходящих UDP/TCP 53 на всех интерфейсах кроме VPN-интерфейса (сложнее в GUI).
macOS
- Используйте Tunnelblick или официальный клиент OpenVPN с опцией block-dns.
- Либо добавьте PF-правила для блокировки портов 53 вне туннеля.
4) Не забудьте об IPv6
- Часто DNS/IPv6-утечки происходят потому, что IPv6 не туннелируется. Либо настроьте поддержку IPv6 в VPN, либо отключите IPv6 на клиенте, либо заблокируйте IPv6 DNS-выходы (порты/трафик).
- Для WireGuard: добавить ::/0 в AllowedIPs, если сервер поддерживает IPv6.
5) Если ваш сервер выступает как прокси/VPN-сервер
- Сделайте так, чтобы сервер сам резолвил либо через локальный резолвер (unbound/dnsmasq), либо использовал публичные DNS, но клиент всё равно будет их видеть как «серверный». Важно: если прокси не форсирует удалённый резолвинг, клиент может резолвить локально.
- Настройте 3x-ui/3proxy (если вы его используете) так, чтобы прокси выполнял удалённый резолв (например, 3proxy имеет опции для проксирования DNS), или используйте on‑the‑server unbound и пробрасывайте DNS через VPN.
6) Проверка после исправления
- Выполните tcpdump/wireshark на физическом интерфейсе (eth0): tcpdump -n -i eth0 port 53 — если видите пакеты, утечка не устранена.
- Повторите тесты на dnsleaktest.com и ipleak.net.
- Проверяйте также IPv6 DNS и WebRTC (у браузеров есть WebRTC leaks).
7) Примеры типичных проблем и решений
- Проблема: OpenVPN пушит DNS, но Windows всё равно использует локальный. Решение: добавить block-outside-dns, или настроить метрики адаптеров и очистить кеш DNS (ipconfig /flushdns).
- Проблема: браузер использует DoH напрямую и обходит систему. Решение: отключить DoH или настроить DoH-провайдера через туннель/прокси.
- Проблема: прокси SOCKS настроен, но Chrome всё ещё резолвит локально. Решение: Chrome не всегда посылает DNS через SOCKS — используйте расширение или системный туннель, либо используйте Firefox с network.proxy.socks_remote_dns = true.
Если хотите, могу:
- составить точные iptables/nftables правила для вашего сервера (подскажите ОС/дистрибутив и имя интерфейса туннеля),
- подсказать точные настройки для OpenVPN/WireGuard/3x-ui и клиента (укажите какие вы используете),
- проанализировать вывод dnsleaktest (вставьте скрин/список показанных IP/серверов).
Напишите, какой у вас клиент и VPN/прокси, и пришлите результат теста (или скриншот) — дам точные команды.