DNS знает о вас больше, чем кажется на первый взгляд. Неправильная настройка или конфликт между локальными и внешними DNS-серверами приводит к утечкам, которые подрывают приватность и нарушают доступ к внутренним ресурсам.
В этой статье я подробно разберу, что такое split DNS, почему возникают утечки через DNS, как их обнаружить и какие конкретные шаги помогут исправить проблему в разных средах — от домашнего роутера до корпоративной сети.
Что такое split DNS и зачем он нужен
Split DNS, его ещё называют split-horizon или split-view, представляет собой схему, когда один домен разрешается разными DNS-серверами в зависимости от точки запроса. То есть внутренние пользователи видят «внутреннюю» версию домена, а внешние — публичную.
Эта модель удобна для организаций: она позволяет хранить внутренние IP-адреса и сервисы недоступными извне и при этом обслуживать публичную часть домена общему интернет-аудитории.
Типичные сценарии применения
Например, корпоративный портал portal.example.com может разрешаться на внутренний IP 10.0.10.5 для сотрудников в офисе, а для внешних пользователей — на балансировщик с публичным адресом. Так достигается безопасность и изоляция внутренних сервисов.
Split DNS часто используется вместе с VPN: при подключении сотрудника к корпоративной сети он должен обращаться к внутренним DNS-серверам для разрешения служебных имен, а обычный веб-трафик может идти через публичные DNS-сервисы.
Почему возникают утечки через DNS
Утечка DNS происходит, когда запросы разрешения имён отправляются не через ожидаемый защищённый канал (например, через туннель VPN), а идут напрямую через интерфейс провайдера. В результате наблюдатель видит, какие домены вы запрашивали.
Причины утечек разнообразны: несовпадение настроек клиента и сервера VPN, работа IPv6 параллельно IPv4, вмешательство локального резолвера типа systemd-resolved, браузерные механизмы вроде WebRTC, и вмешательство ISP через перенаправление портов.
Основные источники проблем
OS и менеджеры сети. NetworkManager, systemd-resolved, dnsmasq и прочие могут перехватывать DNS и посылать туда, куда им удобно, игнорируя настройки VPN-клиента.
Маршрутизация и политика. Если VPN не настраивает политику для DNS-трафика или не перенаправляет весь трафик через туннель, запросы к 53 порту могут идти напрямую в интернет.
IPv6. Часто туннель покрывает только IPv4. При этом IPv6-запросы и запросы к IPv6-DNS отправляются по «внешнему» интерфейсу и становятся очевидны наблюдателю.
Как проверять: быстрые проверки и глубокий анализ
Первый шаг — внешняя проверка через публичные сервисы. Сайты типа ipleak.net, dnsleaktest.com и whoer.net показывают список DNS-серверов, с которых видны ваши запросы.
Такие сервисы удобны для быстрой «дыхательной проверки», но они не заменяют локальный анализ трафика. Для диагностики требуется запись и анализ сетевых пакетов.
Онлайн-инструменты для проверки
Проверка через веб—сервисы даёт представление о том, какие DNS-серверы видны извне. Если после подключения по VPN вы видите DNS-провайдера вашего ISP, это явный сигнал о dns утечка vpn.
Нужно иметь в виду, что некоторые сервисы могут кэшировать результаты или показывать резолверы CDN. Повторите тест с нескольких сайтов, чтобы составить полную картину.
Локальные инструменты и команды
Для детального анализа на Linux полезны команды: dig, tcpdump, ss, ip, и systemd-resolve или resolvectl. С их помощью можно отследить, куда именно уходит DNS-трафик.
Примеры команд:
- dig @8.8.8.8 example.com — запрос к конкретному резолверу;
- tcpdump -n -i any port 53 — перехват DNS-пакетов;
- resolvectl status — состояние systemd-resolved;
- ip route show table main — проверка маршрутов.
Примеры команд для Windows и macOS
Windows: PowerShell команда Resolve-DnsName example.com покажет, какой резолвер отвечает. Запуск netsh interface ip show dns покажет конфигурацию интерфейсов.
macOS: scutil —dns отобразит набор DNS-серверов и порядок их использования. Для перехвата трафика подойдет tcpdump аналогично Linux.
Как диагностировать DNS-утечку шаг за шагом
План диагностики должен быть прост и воспроизводим. Сначала выключите VPN и проверьте базовое состояние DNS, затем подключитесь к VPN и повторите те же тесты.
Если публичные сервисы показывают разные резолверы до и после подключения, это первый индикатор. Если же локальный tcpdump фиксирует пакеты на порт 53 по внешнему интерфейсу, значит запросы действительно утекли.
Пошаговый сценарий
1. Выполните онлайн-проверку на ipleak.net и dnsleaktest.com до подключения VPN. Запишите список резолверов.
2. Подключитесь к VPN, снова выполните те же онлайн-тесты и сравните результаты. Если обнаружена dns утечка vpn, сервисы покажут резолверы вашего провайдера.
3. Локально запустите tcpdump -n -i any port 53 и наблюдайте за интерфейсами, по которым уходят пакеты. Это быстрый способ подтвердить направление трафика.
Встроенные механизмы VPN и их роль
Разные VPN-клиенты по-разному обращаются с DNS. OpenVPN позволяет в конфигурации явно задавать параметры с помощью dhcp-option DNS, а также push-опций на сервере.
WireGuard оставляет управление DNS стороне клиента; в файле конфигурации wg-quick можно прописать параметр DNS = 10.0.0.1, который будет применяться резолверу при активации интерфейса.
Настройки OpenVPN
На сервере OpenVPN можно отправлять клиентам резолверы через push «dhcp-option DNS x.x.x.x». Клиентская часть должна поддерживать эти опции и корректно их применять.
Для Windows-клиента OpenVPN есть опция block-outside-dns, которая блокирует DNS-запросы вне туннеля. Но она работает только при запуске от администратора и может конфликтовать с systemd-resolved или NetworkManager на других ОС.
WireGuard и DNS
WireGuard не управляет транзитом DNS по умолчанию. В конфигурации клиентского интерфейса указывайте нужный DNS, и при использовании wg-quick он будет аплицироваться в системные настройки.
Если вы используете фирменные GUI-клиенты, проверьте, действительно ли они меняют резолвер и блокируют внешний доступ к 53 порту.
Как исправить: практические шаги по платформам
Исправление утечек — это последовательность действий: определить источник, настроить резолверы, корректно применить маршруты и при необходимости заблокировать нежелательный трафик на уровне фаервола.
Ниже приведены конкретные рекомендации для популярных ОС и оборудования. Следуйте им по очереди, проверяя после каждого шага.
Windows
Проверьте настройки адаптеров: ipconfig /all покажет, какие DNS назначены каждому интерфейсу. Если VPN-клиент не меняет DNS, можно вручную прописать нужный сервер на VPN-адаптере.
Используйте опцию block-outside-dns в OpenVPN, если доступна. Также отключите IPv6, если ваш VPN не поддерживает его и утечки происходят по IPv6.
Linux
На системах с systemd-resolved используйте resolvectl или systemd-resolve —status, чтобы увидеть, какие интерфейсы контролируют резолвер. Частая проблема — NetworkManager привязывает DNS к активному сетевому интерфейсу.
Решения: настроить NetworkManager для применения DNS от VPN-подключения, добавить explicit DNS в конфигурацию wg-quick или OpenVPN-клиента, либо настроить iptables для блокировки исходящих пакетов на порт 53 через внешний интерфейс.
macOS
macOS использует порядок сервисов сети для выбора DNS. При подключении VPN необходимо убедиться, что виртуальный интерфейс ставится выше в приоритете. Если это не происходит, вручную измените порядок в System Preferences.
Для тонкой настройки можно использовать scutil и добавить нужные резолверы для конкретных доменов, реализуя условное (split) разрешение имен.
Android и iOS
Мобильные ОС по-разному работают с VPN и DNS. На iOS встроенные VPN-профили часто корректно меняют DNS. На Android многое зависит от клиента и версии системы.
Решение для мобильных: использовать официальный клиент VPN с поддержкой автоматической замены DNS, включить DNS-over-TLS/HTTPS, либо применять профиль, который явно задает DNS при подключении.
Использование брандмауэра и маршрутизации для предотвращения утечек
Надежный способ — запретить любые исходящие DNS-запросы на внешний интерфейс. Тогда даже при неправильной настройке приложений запросы будут блокироваться и не покинут устройство.
На уровне роутера можно настроить фильтрацию портов и перенаправление DNS-запросов через внутренний сервер, что защитит всю сеть целиком.
Пример iptables для блокировки внешних DNS
Чтобы запретить исходящие UDP/TCP 53 на внешнем интерфейсе eth0, можно использовать правила:
iptables -A OUTPUT -o eth0 -p udp --dport 53 -j REJECT iptables -A OUTPUT -o eth0 -p tcp --dport 53 -j REJECT
После этого все DNS-запросы должны идти только через интерфейс туннеля. Помните: такие правила нужно тестировать, чтобы не нарушить работу локальных сервисов.
Перенаправление DNS на роутере
На домашнем роутере можно принудительно перенаправлять все DNS-запросы на внутренний резолвер, например, с помощью iptables nat PREROUTING или правил в прошивке OpenWrt.
Это удобно для сети, где вы хотите гарантировать, что устройства не будут использовать публичные резолверы провайдера вне VPN.
Настройка split DNS в корпоративной среде
В организациях split DNS часто реализуют через условную пересылку доменов (conditional forwarding) в Active Directory, Windows DNS или через bind/named с view. Важно, чтобы клиенты получали корректные резолверы при подключении по VPN.
Типичная ошибка — отправлять клиенту только маршруты, но не информацию о локальных DNS. В результате внутренние имена не разрешаются или начинают разрешаться публичными резолверами.
Рекомендации для корпоративной архитектуры
1. На VPN-сервере явно укажите внутренние DNS и поисковые домены, и убедитесь, что клиенты получают эти параметры при подключении.
2. Реализуйте split DNS на уровне DNS-серверов, не смешивая внутренние зоны с публичными.
3. Мониторьте логи и настраивайте оповещения на несанкционированные обращения к внешним резолверам с корпоративных адресов.
DNS-over-TLS и DNS-over-HTTPS: как они влияют на утечки
Защищённые протоколы для DNS уменьшают риск перехвата запросов посторонними, но если клиент использует DoT или DoH вне VPN, это может скрыть факт утечки от простых внешних тестов.
Важно: DoH/DoT защищают от прослушивания, но не от того, что резолвер принадлежит провайдеру или третьей стороне. Для конфиденциальности нужно убедиться, что защищённый резолвер находится в зоне доверия и доступен через VPN, либо что всё DNS разрешается внутри сети.
Таблица: причины утечки и быстрые способы устранения
| Причина | Проявление | Быстрое решение |
|---|---|---|
| Клиент не применяет DNS от VPN | Онлайн-тесты показывают резолвер провайдера | Настроить клиент, задать DNS вручную или использовать опцию push на сервере |
| IPv6 не туннелируется | Утечки по IPv6 | Отключить IPv6 или настроить туннелирование/маршруты |
| systemd-resolved/NetworkManager перехватывают DNS | Нестабильное применение резолверов | Перенастроить менеджер сети, интегрировать VPN с systemd-resolved |
| Transparent DNS proxy у провайдера | Перенаправление портов 53 | Использовать TLS/HTTPS для DNS или настроить блокировку 53 на роутере |
Проверка после исправлений: контроль качества
После внесения изменений всегда повторяйте проверку. Используйте и онлайн-инструменты, и локальные захваты пакетов. Тщательно проверьте работу с IPv6 и WebRTC, если это актуально для вашей среды.
Организовывая удалённую поддержку, попросите пользователей прислать выводы команд и скриншоты с сайтов проверки, чтобы убедиться, что исправления действительно работают на их устройствах.
Автоматизация мониторинга
Для сети с множеством пользователей имеет смысл настроить периодическую проверку DNS-резолверов. Простая cron-задача с curl к API сайта проверки или собственный скрипт с dig и анализом исходящих интерфейсов позволит выявлять проблемы на ранних стадиях.
Логи фаервола и NetFlow/PCAP-аналитика помогают понять, если утечки происходят выборочно — например, для определённых подсетей или типов устройств.
Типичные ошибки при попытке «починить» DNS
Часто встречается желание просто отключить systemd-resolved или сбросить NetworkManager, не понимая зависимостей. Это может привести к ухудшению работы сети или потере автоконфигурации.
Ещё ошибка — полагаться только на онлайн-тесты. Они покажут результат, но не объяснят, почему утечка произошла и как её воспроизвести локально.
Как избежать новых проблем
Планируйте изменения, делайте резервные копии конфигураций и тестируйте на контрольной машине до развёртывания. В случае фаервол-правил записывайте старые состояния, чтобы быстро откатиться.
Не применяйте радикальные блокировки без учёта IPv6, так как это может нарушить работу мобильных приложений и систем, полагающихся на IPv6.
Мой опыт: несколько практических примеров
В одном из проектов при переходе на WireGuard у части сотрудников начались проблемы с доступом к внутренним сервисам. Внешние DNS показывали провайдера, а tcpdump подтверждал исходящие пакеты на eth0.
Выяснилось, что wg-quick не применял DNS к контейнерам Docker, работающим на хосте. Решение было двустрочным: прописать DNS в /etc/resolv.conf через systemd-resolved для контейнерной сети и добавить правило iptables, блокирующее 53 порт извне. После этого проблема исчезла.
В другом случае корпоративный VPN отправлял только маршруты, но не DNS-параметры. Пользователи видели внутренние домены, но резолвинг происходил через публичные сервера. Мы добавили push-опцию на OpenVPN-сервере и настроили клиентские профили — вопрос решился на уровне конфигурации сервера.
Полезные контрольные команды и сценарии
Ниже собраны команды, которые удобно использовать при проверке и исправлении проблем. Выполняйте их по порядку, чтобы понять состояние системы.
- dig +short @127.0.0.1 example.com — проверить локальный резолвер;
- tcpdump -n -i any port 53 and not src 10.0.0.0/8 — отфильтровать внешние запросы;
- resolvectl status — статус systemd-resolved;
- ip route get 8.8.8.8 — увидеть, какой интерфейс используется;
- wg showconf wg0 — проверить DNS в конфигурации WireGuard;
- netsh interface ip show dns — DNS в Windows.
Часто задаваемые вопросы и короткие ответы
Нужно ли отключать IPv6, чтобы избежать утечек? Не всегда. Если VPN поддерживает IPv6, лучше настраивать туннель для обеих стеков. Если поддержки нет, временное отключение IPv6 уменьшит риски.
Помогут ли DoH и DoT? Они защитят содержимое запросов, но не решат проблему, если резолвер для них находится вне VPN или принадлежит третьей стороне. Оптимально — использовать защищённый резолвер внутри сети или через туннель.
Итоги
Split DNS позволяет гибко обслуживать внутренние и внешние версии одного и того же домена, но при этом требует точной настройки взаимодействия с VPN и сетевыми менеджерами. DNS-утечка vpn — частая проблема, которую можно диагностировать и устранить системными методами.
Проверка dns leak должна сочетать внешние тесты и локальный анализ трафика. Поменяйте настройки клиента и сервера, настройте фильтрацию на уровне фаервола и не забывайте про IPv6. Такие меры помогут сохранить приватность и корректно разрешать внутренние имена в сети.
