OpenVPN передаёт DNS, но ваш резолвер может его так и не увидеть

Журнал клиента показывает переданный DNS-сервер, туннель подключён, а внутреннее имя всё равно не разрешается. В самой передаче ничего не сломано. Параметр пришёл, но резолвер операционной системы так и не использовал его, потому что в большинстве Unix-клиентов OpenVPN передаёт значение и оставляет применение платформе.

Симптом: журнал показывает DNS, а имена всё ещё не работают

OpenVPN dhcp-option несёт информацию о DNS и домене, а клиент записывает то, что получил. В одних реализациях клиент применяет эти настройки внутри; в других экспортирует их для скрипта интеграции или сетевой службы. Строка журнала описывает только первую половину истории. Вторая половина происходит там, где клиент не управляет. Именно там обычно и живёт сбой.

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

Получено — не значит применено

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

Проверьте поддерживаемую интеграцию реализации, а не предполагайте, что каждый Unix-клиент переписывает один и тот же файл. Именно это предположение заставляет людей редактировать конфигурацию резолвера, которую никто не читает.

Найдите владельца резолвера для каждой платформы

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

Читайте фактическое состояние инструментом, который действительно отвечает на запросы: resolvectl query internal.example.net на хосте с systemd-resolved или эквивалентом платформы. Затем сравните этот ответ с DNS-сервером, который, по словам журнала клиента, был передан.

Не запускайте несколько служб, которые без согласования перезаписывают настройки резолвера. Два владельца дают результат, который выглядит прерывистым, и каждое переподключение будто случайно исправляет или ломает его.

Скрипты и foreign_option

OpenVPN экспортирует переданные параметры в скрипты через переменные с именем foreign_option_N, и скрипт может перевести их в команды резолвера. Такая схема — поддерживаемая интеграция, а не автоматическое поведение, и её нужно установить и вызвать на клиенте.

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

Проверяйте имя, а не журнал

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

Если имя разрешается, но служба отказывает, переходите к маршрутизации и доступу приложений, а не меняйте DNS снова. Руководство OpenVPN описывает dhcp-option и среду скриптов; используйте его, чтобы подтвердить, что должен применять ваш клиент, прежде чем редактировать очередной файл резолвера.