Почему DNS перестаёт работать после подключения OpenVPN в Windows

Ping до офисного резолвера по-прежнему получает ответ после подключения "OpenVPN", и при этом каждый поиск имени срывается. Адрес доступен, а порт нет, сочетание, которое обретает смысл, когда известно, что Windows умеет фильтровать DNS по адаптеру. Если в профиле есть block-outside-dns, этот фильтр и есть первый подозреваемый, а таблица маршрутов — неверное место для поиска. Два теста ниже разделяют уровни за секунды.

Доступный адрес, мёртвый порт

Успешный ping доказывает, что хост работает и путь существует. О разрешении дойти до порта 53 он не говорит ничего, потому что рассматриваемый фильтр работает на другом уровне и привязан к адаптеру. Поэтому одна и та же машина может отвечать на ICMP и отклонять каждый запрос, отправленный на тот же адрес. Запустите оба теста в одной сессии, прежде чем менять любую конфигурацию.

ping <resolver-ip>
nslookup <name> <resolver-ip>

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

Этот параметр — правило платформы фильтрации

Документация OpenVPN описывает block-outside-dns как ограничение Windows Filtering Platform, которое не даёт приложениям достучаться до DNS на адаптерах вне туннеля. Оно охватывает TCP и UDP на порту 53. Поскольку фильтр живёт в WFP, а не в обычном списке правил брандмауэра, правило разрешения, добавленное в другом месте, не обязательно меняет результат. Поэтому обычный совет разрешить DNS продолжает не срабатывать.

Настройка может прийти из импортированного профиля или с сервера, а файл, который вы правили последним, "не доказывает, что загрузил клиент". Читайте действующую конфигурацию и журнал подключения вместе. Параметр ещё и специфичен для Windows, и отношение к нему как к переносимому даёт советы, которые не работают.

Ищите клиентский компонент, которому принадлежит ограничение, вместо того чтобы добавлять новые правила. Владелец — это то, что действительно может его убрать.

Фильтр — не резолвер

Блокировка трафика вне туннеля не устанавливает внутри него работающий резолвер. Параметр убирает путь и оставляет DNS-конфигурацию туннеля тому, кто настраивал профиль. У профиля, который никогда не передавал резолвер, теперь его нет вовсе.

Пройдите три проверки по порядку. Первая: какой резолвер на самом деле использует сбойное приложение. Вторая: применил ли клиент настройки DNS для VPN. Третья: какой интерфейс несёт трафик к этому резолверу.

1. Используемый резолвер: сравните Resolve-DnsName -Server <resolver-ip> <name> с DNS-серверами, которые перечисляет ipconfig /all.
2. DNS для VPN применён: проверьте записи DNS туннельного адаптера в том же выводе ipconfig /all.
3. Используемый интерфейс: Find-NetRoute -RemoteIPAddress <resolver-ip> указывает исходящий интерфейс для этого адресата.

LAN-резолвер по замыслу становится недоступным при такой политике, даже пока другой LAN-трафик работает. Это параметр выполняет свою работу. Если по замыслу нужен DNS через VPN, исправьте регистрацию резолвера и путь туннеля; если требуется split DNS с локальными исключениями, владелец конфигурации должен выразить эти исключения поддерживаемым способом.

Чего параметр не покрывает

Порт 53 — не всё разрешение имён. DNS over HTTPS и DNS over TLS используют другой транспорт, а некоторые приложения выполняют собственную логику резолвера независимо от системных настроек. Поэтому браузер может разрешать имена, а командная строка — нет.

Считайте это различие диагностикой, а не противоречием. Сравните оба варианта, прежде чем решать, что системный резолвер сломан.

Держите вывод узким, когда записываете его. Этот параметр ограничивает один транспорт на одной платформе, а остальная часть пути разрешения — отдельный вопрос проектирования со своим владельцем.

Проверьте состояние до и после отключения

Запустите тот же поиск во время подключения и снова после того, как клиент-владелец отключится. Первый должен срываться для внешнего резолвера, пока туннель поднят, а второй должен проходить после снятия фильтра. Если после отключения он всё ещё срывается, фильтр не был очищен.

ipconfig /displaydns
nslookup <name> <resolver-ip>

Перезапуск клиентской службы или машины обычно снимает устаревший фильтр. Это подтверждает диагноз, не доказывая постоянного исправления. Запишите увиденное, потому что фильтр, переживший отключение, сделает это снова, и именно запись обосновывает отчёт об ошибке.

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