OpenVPN отправил DNS-сервер, но Linux его игнорирует

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

Проверка первая: как начинается соединение

Владелец соединения определяет, кто может применить настройки резолвера. Прямая команда openvpn из оболочки не владеет ничем, кроме своего процесса, тогда как у юнита systemd, NetworkManager или клиента производителя есть собственный способ публиковать DNS. Прочитайте список процессов и имя юнита, прежде чем предполагать что-то из этого.

Процесс из командной строки не обязательно является соединением NetworkManager, а соединение NetworkManager не обязательно то, что записало resolv.conf. Эти два предположения объясняют большую часть потерянных часов в этом расследовании. Спросите, какой компонент опубликовал бы DNS для интерфейса, который вы действительно видите.

Запишите владельца, прежде чем продолжить. Каждая следующая проверка зависит от него.

Проверка вторая: что на самом деле содержит привязка резолвера

На хосте с systemd-resolved resolvectl status перечисляет каждую привязку с её DNS-серверами и доменами. Найдите привязку туннеля и прочитайте её записи, и не предполагайте, что интерфейс называется tun0, потому что нумерация идёт в порядке создания. Если отправленного адреса в привязке нет, то не состоялась передача, а не запрос.

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

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

Проверка третья: выбирает ли пространство имён эту привязку

Резолвер может содержать правильный сервер и всё равно не опрашиваться. Домен на привязку решает, какие запросы идут к какой привязке, а без домена маршрутизации частное пространство имён возвращается к тому, что говорит привязка по умолчанию. Поэтому resolvectl query для внутреннего имени может сработать, тогда как приложение всё ещё терпит неудачу. Возможно, приложение использует совершенно другой путь резолвера.

Проверьте назначение домена, а не только адрес сервера. Домен, записанный как ~corp.example, является доменом маршрутизации, и тильда меняет способ сопоставления имени.

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

Проверка четвёртая: один владелец, а не два

Если NetworkManager уже управляет VPN и состоянием резолвера, добавление несвязанного hook-скрипта создаёт конкурирующих писателей. Hook, который пакет предоставляет для systemd-resolved, — это поддерживаемая интеграция, и он ожидает определённого жизненного цикла: script-security 2, путь up, up-restart, путь down и down-pre. Эти параметры заставляют регистрацию и удаление происходить в нужные моменты, а не только при первом соединении.

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

Правка скрипта резолвера дистрибутива ради изменения его выходной цели фиксирует обход для одного хоста. Это не общее исправление.

Проверка пятая: тот же результат после переподключения

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

Только когда все пять проверок проходят при переподключении, можно сказать, что отправленные настройки используются. Всё, что раньше, — снимок удачного момента.