VPN перехватил DNS и сломал локальные имена: исправьте список

Туннель поднимается, интранет загружается, а имя принтера перестаёт разрешаться. Или наоборот: локальные имена ещё работают, тогда как всё внутри корпоративной сети уходит в тайм-аут. Оба симптома приходят из одного места — списка резолверов, который клиент VPN перезаписал при подключении.

Исправьте список осознанно, а затем займитесь механизмом push отдельно. Маршруты — третья тема, и не она здесь исправляется.

Какой список приложения действительно используют

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

Вопрос в том, какие серверы оказались впереди и пришли ли они как статические записи или как аренда DHCP. Оба факта определяют, какое исправление вам доступно.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

Прочитайте вывод для адаптера туннеля и для физического адаптера и запишите каждый адрес на каждом из них. Статическую запись можно удалить политикой или скриптом; запись, полученная по DHCP, привязана к аренде и вернётся, что меняет выбор исправления. Имена в удалённой сети разрешает объявленный резолвер, имена в локальной LAN — физический адаптер, а запрос уходит к тому списку, который просматривается первым.

Удалите протолкнутые серверы или поставьте их ниже

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

netsh interface ipv4 delete dnsservers name="Corp VPN" address=all validate=no
netsh interface ipv4 add dnsservers name="Corp VPN" address=172.16.20.1 index=1 validate=no

Индекс 1 просматривается первым, поэтому протолкнутые адреса остаются доступными, но перестают быть ответом по умолчанию на каждый запрос. Флаг validate=no пропускает проверку доступности, которая часто не проходит, пока туннель ещё стабилизируется, поэтому подтвердите результат командой show, а не доверяйте коду выхода.

Прежде чем на это полагаться, стоит знать два ограничения. Windows не удалит серверы, пришедшие по DHCP через netsh, и эти значения сохраняются как DhcpNameServer под ключом реестра интерфейса, поэтому правка реестра — последнее средство, которое нужно перепроверить после следующей аренды. Порядок привязки адаптеров тоже не является надёжным механизмом ранжирования, потому что клиент VPN может вставить свою запись в начало списка.

Где можно отфильтровать push

Лучшее исправление убирает опцию до того, как она применится. Клиент Community OpenVPN умеет фильтровать протолкнутую директиву по имени, и это оставляет конфигурацию сервера нетронутой.

pull-filter ignore "dhcp-option DNS "

Завершающий пробел относится к совпадению, и фильтр называет опцию, а не адрес сервера. Если в профиле есть ещё директива block-outside-dns, её удаление меняет защиту от утечек, а не разрешение имён, поэтому решайте это отдельно, а не объединяйте две правки.

Для одного упрямого имени хоста одна строка в файле hosts Windows устойчивее, чем переупорядочивание резолверов для всей машины. Она к тому же невидима для следующего человека, поэтому запишите её там, где документируется конфигурация машины.

Сделайте исправление устойчивым к переподключению

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

Resolve-DnsName intranet.corp.example -Server 172.16.20.1
Resolve-DnsName printer.lan

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

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