DNS при VPN без боли: как закрыть утечки, исправить резолвинг и настроить кэш

Что на самом деле происходит с DNS при VPN: простыми словами и без магии

Как меняется маршрут трафика, когда включается VPN

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

Представьте шоссе с платной ВИП-полосой. Большие машины в неё въехали. А маленькие, вроде DNS-запросов, иногда продолжают петлять по старым дорогам. Причина в политике резолвера: кто-то доверяет системному, кто-то использует встроенный DoH, а кто-то не дружит с туннелем. И всё же логика проста: если мы хотим приватности и стабильности, нам нужен единый, предсказуемый маршрут для DNS внутри VPN.

В 2026 году большинство клиентов WireGuard, OpenVPN и корпоративных SASE-агентов уже умеют пушить корректные DNS-настройки и блокировать «вылеты» наружу. Но чудес не бывает. Если на хосте включён отдельный резолвер с DoH, браузер может продолжить ходить к своему облачному провайдеру. Значит, правила должны быть согласованы: кто главный, кто подчинённый, и куда именно летят UDP-пакеты на 53 порт, TCP 853 для DoT и HTTPS-трафик для DoH.

Почему DNS — особенный трафик (и обычно проблемный)

DNS работает быстро, тихо и часто. Каждая страница — десятки запросов. Любой сбой или расхождение мгновенно чувствуется: сайт не открывается, контент подменяется, геолокация неожиданно меняется. Добавьте сюда кеширование на разных уровнях (браузер, ОС, VPN-клиент, локальный резолвер, провайдер) — и получите причудливую лесенку тайм-аутов и старых записей. Когда включён VPN, мы ещё и боремся за приватность: мы не хотим, чтобы провайдер видел, какие домены мы спрашиваем. А DNS leak делает именно это — сливает, причём часто незаметно.

Плюс, DNS — не только порт 53. Шифрованные варианты DoH и DoT — уже стандарт де-факто. Браузеры обожают DoH. Системные резолверы в Windows и Linux всё чаще шифруют запросы по умолчанию. iOS и Android включают Private DNS. Красота? Да. Но в контексте VPN появляется вопрос: кто хозяин положения — туннель или приложение? Без чёткой схемы легко попасть в лабиринт из столкновений политик, где одни правила перекрывают другие, а в итоговой конфигурации живут сразу три разных резолвера.

Симптомы: как понять, что DNS шалит именно из-за VPN

Медленно грузится, странные тайм-ауты, то открывается, то нет

Мы все это видели. Сайт открывается, но картинки не грузятся. Или наоборот: главная страница как пуля, а корзина зависает. Включаете VPN — лучше. Через пять минут — хуже. Классика DNS-парадокса. Почему так? Возможно, часть доменов уходит на системный резолвер, а часть — в туннельный DNS. Из-за кэша браузера ситуация «плавает». Иногда допомогает Ctrl+F5, иногда — нет. Раздражает? А как же.

Конкретный маркер: код ошибки DNS_PROBE_FINISHED_NXDOMAIN или SERVFAIL в диагностике. Или повторяющиеся задержки 1-2 секунды перед загрузкой домена, особенно при первом заходе. Когда туннель меняет MTU, крупные DNS-пакеты с EDNS могут фрагментироваться и теряться. В итоге один запрос работает, потому что маленький, а другой проваливается. Ещё один показатель — сайты с геозависимой раздачей. Если они внезапно отвечают не тем контентом, вероятно, часть запросов разрешается не там, где мы думаем.

Не игнорируйте дробные проблемы. Если всё ломается сразу — это заметно. Но куда противнее, когда ломается через раз. Тут как с люфтом в руле: машину ведёт, и вы привыкаете, а потом внезапно съезжаете на обочину. DNS с VPN ведёт себя так же.

Контент и геолокация «пляшут»: сервисы думают, что вы в другой стране

Вы включаете VPN с выходом, например, в Нидерландах, но видеосервис показывает библиотеку для России, Турции или вообще смешанную. Как так? Утечки DNS. Сайт определяет гео не только по IP, но и по тому, где резолвится доменное имя CDN. Если запрос ушёл к провайдерскому DNS вне туннеля, то CDN отдаст ближайшие к вашему провайдеру адреса. В итоге трафик идёт длинной дорогой, контент «не тот», да ещё и скорость скачет.

Проверка простая: спросите у командной строки dig или nslookup заголовок из раздела Адрес сервера. Если там адрес провайдера, а не VPN-резолвера или выбранного DoH/DoT-сервера, у вас утечка. Бывает и наоборот: кажется, что всё шифруется, но браузер принудительно использует свой DoH с DDR (Discovery of Designated Resolvers). Тогда запрос вроде бы уходит к «правильному» провайдеру через HTTPS, но минует сам VPN-туннель, и гео получается странной смесью.

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

DNS leak: как обнаружить и перекрыть утечки без шаманства

Проверяем утечки: ручные команды, утилиты и «контрольные» домены

Начнём с простого. Включите VPN и выполните nslookup example.com или dig example.com. Посмотрите, какой сервер указан в строке Server или в секции SERVER. Это ваш целевой резолвер? Например, 10.14.0.1 для корпоративного DNS за туннелем, или публичный 1.1.1.1/9.9.9.9/8.8.8.8, но через туннель. Если видите адрес провайдера — утечка. Если видите DoH-адрес внутри браузера, но он выходит в интернет мимо VPN — тоже утечка, хоть и шифрованная.

Проверьте разные домены: обычные, с поддоменами, длинные (чтобы задействовать EDNS и крупные ответы). Сравните ответы с и без VPN. Если различия существенные — вероятно, часть запросов идёт не туда. Можно использовать контрольные адреса типа resolver-test или специальные несуществующие зоны, которые подсвечивают, кто именно резолвит (многие VPN-провайдеры предлагают такие внутренние домены, уточните в документации вашего сервиса или сервера).

Неплохой лайфхак: включите логирование на локальном резолвере (например, systemd-resolved или dnsmasq) и посмотрите, какие домены реально проходят через него. Если в логе пусто, а запросы резолвятся, значит, они уходят мимо. Для Windows пригодится встроенный pktmon или трассировка в PowerShell, на Linux — tcpdump с фильтром udp port 53 или портов 853/443 при DoT/DoH.

Как перекрыть утечки: политика клиента, правила ОС и настройки приложений

Сердцевина борьбы — единая политика. Для OpenVPN на клиенте Windows включите опции block-outside-dns и register-dns, на сервере используйте push «dhcp-option DNS X.X.X.X». Для WireGuard указывайте DNS = 10.14.0.1 (или нужный адрес) в профиле клиента и убедитесь, что AllowedIPs покрывают трафик к этому резолверу. Если применяете split tunneling, выделите резолвер в список маршрутизируемых через туннель сетей. И да, проверьте IPv6: утечки часто идут именно по нему, пока IPv4 закрыт наглухо.

Дальше — приложения. Браузер с включённым DoH может игнорировать системный резолвер. Тогда укажите внутри браузера DoH-резолвер, доступный через VPN (например, корпоративный DoH на 443 порту внутри туннеля), или отключите встроенный DoH, если ваша модель приватности полагается на туннель. На уровне ОС в Windows используйте системный DoH, связанный с адресом вашего резолвера, и включите Encrypted DNS только для того сервера, который достигается через VPN. На Linux с systemd-resolved задайте DNS и Domains для интерфейса wg0 или tun0, включите DNSSEC и при необходимости ограничьте fallback-регистры.

И не забывайте про блокировку исходящих UDP 53 наружу на время работы VPN. Это грубо, но эффективно. Пусть неприглашённые запросы даже не смогут уйти. Аналогично — для DoT и DoH, если ваша политика требует, чтобы всё шло через внутренний резолвер. Тонкая настройка — да, но зато без сюрпризов.

Resolution failures: когда домены не резолвятся вообще или через раз

Локальные причины: кэш, MTU, брандмауэр, приоритет интерфейсов

Самые частые провалы — локальные. Кэш держит старую запись A или AAAA, а реальность уже поменялась. В итоге вы видите NXDOMAIN, а другой компьютер всё открывает. Решение банально: очистите кэш браузера и системный кэш DNS. В Windows — ipconfig /flushdns, в macOS — dscacheutil -flushcache и killall mDNSResponder, в Linux с systemd — resolvectl flush-caches. Если используете локальный резолвер (dnsmasq, Unbound), перезапустите его. Не ленитесь, это две минуты времени, которые часто спасают час нервов.

MTU и фрагментация тоже коварны. В VPN-туннелях MTU обычно ниже, чем в физической сети. Крупные DNS-ответы с EDNS (например, при DNSSEC) могут не пролезать без фрагментации и в итоге теряться на неправильном маршрутизаторе. Вы видите тайм-ауты или SERVFAIL. Попробуйте снизить MTU на туннеле (например, до 1280-1380 для WireGuard) или отключить EDNS-тюнинг временно для диагностики. Банально? Но работает — и в домашних сетях, и в филиалах.

Приоритет интерфейсов определяет, какой DNS резолвер берётся первым. Если виртуальный интерфейс VPN не поднял метрики выше, система может продолжать использовать Wi-Fi интерфейс со старым DNS. Проверьте список адаптеров, их метрики и порядок. На Windows — в дополнительных параметрах адаптеров или через PowerShell, на Linux — через routing table и настройки resolved. Брандмауэр? Иногда локальные правила срезают UDP 53 для новых интерфейсов. Зайдите и проверьте явно.

Сетевые и протокольные причины: DoH, DoT, IPv6, DNSSEC и EDNS

Протокольная часть тоньше. Если вы принудительно используете DoT к внешнему резолверу, а VPN туннель блокирует TCP 853 или требует проксирование внутри, запросы не проходят. DoH — аналогично: HTTPS к облачному резолверу может идти мимо туннеля, если приложение не унаследовало маршруты. В 2026 году многие клиенты уже корректно привязывают DoH к интерфейсу VPN, но не все. Проверьте на практике: включите только туннель, отключите выход наружу и убедитесь, что DoH всё ещё получает ответы.

IPv6 — отдельная песня. Вы думаете об IPv4, а система тихо резолвит и ходит по v6. Если ваш VPN не маршрутизирует IPv6 или не даёт резолвер v6-адреса, часть запросов будет терпеть фиаско. Решений два: либо отключать IPv6 на время диагностики, либо полноценно настраивать v6 в туннеле, включая резолвер и префиксы. Учитывайте DNSSEC: при неправильной передаче фрагментов в туннеле и неверной MTU валидация может ломаться. А с EDNS иногда приходится снижать bufsize или включать механизмы, избегающие фрагментации, чтобы ответы доходили без потерь.

А ещё есть ECH: шифрование ClientHello в TLS, которое скрывает SNI. Прямо на DNS это не влияет, но в связке с DoH и политиками перехвата может менять маршрутизацию HTTPS-запросов резолвера. Вывод: проверяйте весь путь — от системного резолвера до туннельного интерфейса. Тогда сюрпризов станет меньше.

Кэш DNS: в чём ловушка и как его приручить

Где вообще живёт кэш: браузер, ОС, локальный резолвер, VPN-клиент

Кэш многослоен. Браузер кэширует записи отдельно. ОС держит свой кэш. Локальный резолвер (dnsmasq, Unbound, systemd-resolved) — ещё слой. И сам VPN-клиент иногда кэширует ответы, особенно корпоративные агенты Zero Trust. В итоге вы чистите один кэш, а «неправильный» ответ живёт в другом. Смешно и грустно одновременно. Поэтому подходите системно: чистим по порядку и сверяем время TTL.

Обратите внимание на TTL. Если резолвер отдаёт огромный TTL, устаревшая запись может жить часами. В 2026-м нередко встречаются политики с агрессивным кэшированием для экономии трафика, особенно на мобильных устройствах. В таких сценариях полезно иметь локальный резолвер с возможностью временно игнорировать TTL для проблемных доменов (например, принудительно снижать до короткого значения на время отладки). Это спасает при миграциях CDN.

Ещё момент: split DNS. Часть доменов (внутренних) резолвится в одну сторону, часть — наружу. Кэш на локальном резолвере должен знать доменные суффиксы и не смешивать ответы. Иначе вчерашний внешний IP внезапно «подменит» внутренний сервис. Тщательно настройте search domains и routes в вашем VPN-профиле.

Как чистить кэш правильно и не ломать всё остальное

Сценарий быстрый. Сначала — браузер: очистите DNS-кэш в его настройках или перезапустите, если так быстрее. Затем — ОС. Windows: ipconfig /flushdns, иногда помогает netsh winsock reset для «набитых» стеков. macOS: dscacheutil -flushcache и killall mDNSResponder (да, сейчас это снова классика). Linux: resolvectl flush-caches или перезапуск локального резолвера. Если есть dnsmasq, сделайте service dnsmasq restart. Если используете AdGuard Home или Pi-hole, очистите кэш через их интерфейс или командой.

После очистки повторите тесты с dig и nslookup и посмотрите, изменились ли адреса и скорость резолвинга. И да, не забывайте про кэш в самом VPN-клиенте: корпоративные агенты иногда требуют ручного сброса через встроенную консоль. Это редкость, но такое встречается. Главное — не сносить всё подряд. Пошаговый подход экономит время: чистим слой за слоем, проверяем, фиксируем наблюдения.

Правильная архитектура DNS с VPN в 2026: от домашней сети до офиса

Split DNS и Split Tunneling: как сделать, чтобы работало, а не ломалось

Split Tunneling экономит трафик и снижает задержки. Но с DNS он превращается в минное поле, если не задать чёткие правила. Правило первое: доменные суффиксы внутренних зон должны резолвиться только через туннельный резолвер. Настройте в профиле VPN domains или search domains, а также route-only для нужных подсетей. Правило второе: для публичных доменов решите, где именно резолвить — внутри туннеля или снаружи — и закрепите это. Простой вариант: системный резолвер один, и он всегда доступен через туннель. Тогда утечек меньше.

Для WireGuard: в клиентском конфиге укажите DNS и включите AllowedIPs для адресов вашего резолвера. Для OpenVPN: используйте push «dhcp-option DOMAIN-SEARCH corp.local» и push «dhcp-option DNS 10.14.0.1». На Windows — включите block-outside-dns, чтобы никто не сбивал приоритеты. В корпоративных SASE и Zero Trust решениях назначайте политики по группам пользователей и устройствам, фиксируя, какие домены должны резолвиться где. Добавьте мониторинг — без него split-схемы превращаются в лотерею.

И помните о fallback. Если основной резолвер недоступен, система любит незаметно переключаться на запасной. Опасный момент: так появляются скрытые утечки. Лучше явный отказ, чем тихий «подменённый» маршрут. В 2026 году многие клиенты уже поддерживают «жёсткий» режим, когда без доступности туннельного DNS запрос просто не уйдёт.

Шифрование по умолчанию: DoH, DoT, ECH, ODoH и DDR без лишних сюрпризов

Шифрование DNS давно перестало быть экзотикой. DoH (DNS over HTTPS) и DoT (DNS over TLS) входят в стандартные панели настройки в Windows, Android и современных браузерах. DDR (Discovery of Designated Resolvers) автоматизирует привязку шифрованного резолвера к известному нешифрованному. Звучит круто, но в мире VPN это нужно держать под контролем: кто решает, какой резолвер назначать, приложение или политика туннеля?

Оптимальная схема: единый источник истины. Если у вас корпоративный резолвер с DoH на внутреннем адресе, пропишите его в клиентах и заблокируйте внешние DoH/DoT на время работы VPN. Если вы частный пользователь — выберите доверенный резолвер (например, 1.1.1.1, 9.9.9.9, 8.8.8.8 или NextDNS) и убедитесь, что маршрут к нему идёт через туннель. Для ECH важно лишь, чтобы HTTPS-трафик резолвера проходил стабильно. ODoH (Oblivious DoH) добавляет приватность за счёт разделения запроса и транспорта, но и увеличивает задержки — применяйте по задаче.

Итог простой: шифруйте DNS, но не плодите источники правды. Один резолвер, одна политика, чёткие маршруты. Тогда VPN будет не противником, а союзником. Кстати, в 2026 стандартные клиенты уже нормально логируют DoH/DoT-состояние. Проверьте, включены ли эти логи у вас — иногда именно там спрятана подсказка, почему «вчера работало».

Пошаговые настройки: Windows, macOS, Linux, iOS и Android

Windows 11/10: системный резолвер, OpenVPN и WireGuard

Начнём с Windows. Шаг 1: проверьте список интерфейсов и их метрики. Включите приоритет VPN-адаптера. Шаг 2: если используете OpenVPN, добавьте в профиль клиента параметры block-outside-dns и register-dns. На сервере задайте push «dhcp-option DNS 10.14.0.1» и при необходимости push «redirect-gateway def1». Шаг 3: для WireGuard в клиентском конфиге укажите DNS = 10.14.0.1 и убедитесь, что AllowedIPs включают маршрут к резолверу. Если используете split, добавьте нужные домены в список поиска.

Шаг 4: включите системный Encrypted DNS для выбранного резолвера, но только если он доступен через туннель. Пропишите DoH-шаблон и проверьте статус в настройках сети. Шаг 5: сбросьте кэш — ipconfig /flushdns. Если были странности с Winsock, netsh winsock reset и перезагрузка. Шаг 6: проверьте утечки. nslookup example.com и убедитесь, что сервер — туннельный. При необходимости временно запретите исходящий UDP 53 наружу через брандмауэр на время работы VPN.

Дополнительно: в Windows 11 полезно проверить, не включён ли у браузера свой DoH, который обходит системный. Если политика — «всё через туннель», синхронизируйте настройки браузера с системным резолвером или укажите внутри браузера DoH-резолвер, доступный через VPN. Не забудьте про IPv6: либо настраивайте через туннель, либо отключайте для диагностики.

macOS и iOS: профили, Resolver и mDNSResponder

В macOS многое завязано на профили и порядок сервисов. Шаг 1: убедитесь, что VPN-сервис в списке сетей имеет более высокий приоритет. Шаг 2: если используете корпоративные профили, добавьте DNS сервера и доменные суффиксы внутрь профиля VPN. Шаг 3: при проблемах с резолвингом очистите кэш через dscacheutil -flushcache и перезапустите mDNSResponder командой killall mDNSResponder. Работает надёжно и быстро.

Для iOS ключ — профили и политика приложения. Многие клиенты умеют назначать внутренний резолвер при подключении и принудительно закрывать исходящий DNS. Проверьте опцию, запрещающую обход туннеля для DNS в приложении VPN. Если используете Private Relay параллельно с VPN, возможны конфликты маршрутов и DoH-регистраций в браузере. На время диагностики отключите Private Relay, оставьте только VPN и системный DNS.

Во всех случаях проверьте, как резолвится набор контрольных доменов, и сравните с ожидаемым поведением. В macOS удобно смотреть scutil --dns, чтобы понять, какой резолвер и для каких доменов используется. Если split DNS, обязательно задайте Domains для интерфейса VPN, чтобы внутренние зоны не улетали наружу.

Linux и Android: systemd-resolved, dnsmasq и Private DNS

На Linux в 2026 году systemd-resolved — частый «дирижёр» DNS. Шаг 1: свяжите интерфейс туннеля (wg0/tun0) с нужным резолвером: укажите DNS и Domains для этого интерфейса. Шаг 2: проверьте resolvectl status и убедитесь, что приоритет интерфейса и порядок поиска корректен. Шаг 3: при наличии dnsmasq или Unbound настройте форвардинг и split DNS, чтобы внутренние зоны не пытались резолвиться наружу. Шаг 4: проверьте IPv6-маршруты и MTU, при необходимости снизьте MTU на туннеле.

На Android откройте настройки Сеть и Интернет и включите Private DNS к выбранному резолверу, если ваша политика подразумевает шифрование на устройстве. Но важный нюанс: этот трафик тоже должен идти через VPN. Если приложение-вариант VPN не перехватывает DoH/DoT трафик, получите частичные утечки. Многие клиенты сейчас умеют фиксировать это, предоставляя режим Перехват DNS. Включите, проверьте и протестируйте с несколькими доменами.

И Linux, и Android любят кэшировать. Не забывайте про резолвectl flush-caches на Linux и про перезапуск приложения на Android при смене профилей. В сложных сценариях полезно завести локальный резолвер на роутере (например, dnsmasq на OpenWrt) и прокидывать всё через туннель. Такая архитектура часто оказывается стабильнее и предсказуемее.

Отладка и мониторинг: инструменты и сценарии, которые реально помогают

dig, nslookup, resolvectl, pktmon, tcpdump: что, где и когда

Нет волшебной кнопки, зато есть правильные вопросы. Кто отвечает на DNS? Куда идут пакеты? Можно ли увидеть тайм-аут? На Windows начните с nslookup и pktmon. Командой pktmon start --etw -p можно собрать базовую трассировку, а затем посмотреть, не уходят ли пакеты на неожиданный интерфейс. На Linux tcpdump -i wg0 udp port 53 показывает, видите ли вы DNS трафик внутри туннеля. Если тишина, а резолвинг идёт — значит, кто-то резолвит снаружи или через DoH.

dig полезен своими ключами. Попробуйте dig +tcp для проверки DoT-сценариев и крупного ответа. Посмотрите секцию SERVER и AUTHORITY. Сравните ответы при разном MTU. В systemd-resolved resolvectl query домен покажет, какой из конфигурированных серверов ответил и с каким временем. На macOS scutil --dns визуализирует порядки резолверов и домены. Не забывайте брандмауэр: порой он молча режет UDP 53 или TCP 853 для интерфейса туннеля.

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

Логи, метрики и алерты: домашняя сеть и офис без сюрпризов

Дома достаточно лёгких метрик: время первой резолюции домена, доля NXDOMAIN/SERVFAIL, размер кэша, TTL. Это может делать ваш локальный резолвер или роутер. Настройте простую панель: если доля ошибок резко растёт после включения VPN, реагируйте сразу. В офисе добавьте synthetic checks: робот каждые 60 секунд резолвит список ключевых доменов через VPN и без него. Любая разница — сигнал.

Не стесняйтесь включать алерты на MTU и фрагментацию, если оборудование позволяет. Раз в полгода проводите ревизию: кто у нас главный резолвер, где форвард, что с DoH/DoT политиками, где возможный fallback. Мелкие правки раз в квартал поддерживают стабильность лучше, чем один большой «капремонт» раз в три года. И банальность на закуску: пишите документацию. Когда через год вы спросите себя, почему здесь стоит 1280, а не 1420, правильно оформленный changelog украдёт у хаоса его козыри.

Практические кейсы: живые ситуации и рабочие решения

Кейс 1: утечка DoH из браузера при корпоративном VPN

Исходные: сотрудник жалуется, что часть сервисов видит его «как дома», а часть — «как в офисе». VPN подключён, доступ к внутренним системам есть. Диагностика: tcpdump на туннеле не показывает DNS, но резолвинг идёт. В логах браузера включён DoH к облачному резолверу. Он шифрованный, но идёт мимо туннеля. Решение: в политике VPN включили перехват DoH и назначили внутренний DoH, доступный по 443 внутри туннеля. В браузере отключили авто-DDR на время. Результат: гео стабилизировалось, утечки исчезли.

Вывод: шифрование без маршрутизации не равно приватность. Важно, где именно идёт трафик, а не только как он шифруется.

Кейс 2: нестабильный резолвинг из-за MTU и EDNS

Исходные: сайты открываются, но иногда падают с SERVFAIL. Особенно те, где включён DNSSEC. Повторный запрос через секунду — норм. С VPN хуже, без VPN лучше. Диагностика: крупные ответы фрагментируются и не доходят. На туннеле MTU 1420, на маршруте есть устройство, режущее фрагменты. Решение: снизили MTU до 1280 на туннеле, включили ограничение bufsize в локальном резолвере, чтобы уменьшить ответы. Результат: стабильность выросла, тайм-ауты ушли.

Вывод: EDNS прекрасен, пока сеть дружелюбна. Если нет — подстраивайтесь.

Кейс 3: split DNS и «зависшие» кэши

Исходные: внутренний домен иногда резолвится во внешний IP, сервис недоступен. Через 10 минут всё чинится само. Диагностика: локальный резолвер кэширует внешний ответ, потому что пропустил суффикс внутренней зоны при split-настройке. Браузер кэширует это сверху. Решение: настроили Domains для туннельного интерфейса, добавили жёсткое правило форварда для corp.local, сбросили кэши в связке — браузер, ОС, резолвер. Результат: повторений нет.

Вывод: split DNS требует педантичности. Один неправильный суффикс — и час отладки в корзину.

Чек-лист на каждый день: кратко и по делу

Минимум действий, максимум эффекта

- Проверяем, кто резолвит: nslookup или dig, смотрим SERVER. - Убеждаемся, что VPN-резолвер в маршруте и в приоритете. - Чистим кэши слоями: браузер, ОС, локальный резолвер. - Закрываем наружный UDP 53 и, при необходимости, сторонний DoH/DoT. - Согласовываем политику шифрования: один резолвер — одна правда. - Тестируем IPv6 отдельно: либо настраиваем, либо временно выключаем. - Проверяем MTU, EDNS и DNSSEC на крупных ответах.

Этот список банален, а работает отлично. За привычку спасибо скажут и нервы, и клиенты.

Что делать, если «всё уже сделал, а проблема осталась»

Разделите задачу. 1) Резолвится ли домен внутри туннеля с локального резолвера, если вручную задать сервер? 2) Приходит ли ответ в пределах ожидаемого времени? 3) Меняется ли ситуация при отключении встроенного DoH в приложении? 4) Есть ли разница при снижении MTU до 1280? 5) Что показывает tcpdump на интерфейсе туннеля? Если на каждом шаге есть «да/нет», вы быстрее вычислите корень.

И не стесняйтесь временно всё упростить до унылой, но надёжной схемы: один туннель, один резолвер, полная маршрутизация, без сплита и без внешних DoH. Если в таком режиме стабильно — раскладывайте обратно по слоям, пока не обнаружите точку излома.

FAQ: коротко о главном

Быстрые ответы

Почему с VPN сайты иногда грузятся дольше именно на первом заходе?

Потому что свежий DNS-запрос может идти новым маршрутом, а кэша ещё нет. Плюс, если браузер использует свой DoH, он поднимает отдельное TLS-соединение к резолверу. На всё это уходит 100-300 мс сверху. После прогрева кэша и установления сессий задержка почти пропадает. Если же задержка не уходит, проверьте MTU и неслучайные тайм-ауты на крупных ответах.

Чем хуже утечка DNS, если трафик всё равно шифруется через VPN?

Утечка DNS раскрывает, какие домены вы посещаете. Даже если содержимое шифруется, сам факт обращения виден провайдеру или третьей стороне, если запросы уходят мимо туннеля. Плюс геолокация контента может ломаться, и маршруты становятся длиннее. Итог — меньше приватности, больше проблем с доступом и скоростью.

Нужно ли всегда включать DoH или DoT вместе с VPN?

Не обязательно, но это разумно, когда шифрованный резолвер доступен через туннель и его политика вам подходит. Ключевое — единая точка правды. Если вы включили DoH в браузере, а VPN направляет «официальный» DNS в другую сторону, получите конфликт. Выберите один подход и закрепите маршруты, чтобы не было расхождений.

Сложные случаи

С VPN пропадают только некоторые домены с DNSSEC. Что делать?

Проверьте MTU и фрагментацию. Крупные ответы с DNSSEC часто не доходят, если в туннеле резка фрагментов. Снизьте MTU до 1280-1380, настройте локальный резолвер уменьшать размер ответов (EDNS bufsize), и заново проверьте. Если проблема уйдёт — вы были на верном следе.

Можно ли объединить split tunneling и шифрованный системный DoH без утечек?

Да, если маршрутизировать трафик DoH строго через туннель и запретить обходные пути. Укажите в системе конкретный DoH-резолвер, доступный только по адресу внутри VPN, и заблокируйте наружный DoH/DoT на время подключения. Тогда публичные домены будут шифроваться и идти по предсказуемому пути, а внутренние — по split DNS через корпоративный резолвер.

Стоит ли отключать IPv6 ради простоты?

Временно — да, как диагностическую меру, если подозреваете утечки или нестабильные маршруты. Постоянно — не советуем. В 2026 году всё больше сервисов и резолверов используют v6. Лучше корректно настроить IPv6 в туннеле, чем жить на костылях. Но для быстрых проверок выключение IPv6 часто ускоряет поиск проблемы.