DNS OpenVPN остаётся после SIGKILL: сначала проверьте владельца

DNS перестаёт разрешать имена после того, как клиент OpenVPN убит, и первый порыв — переписать /etc/resolv.conf. Это изменение может сломать работающий резолвер, тогда как настоящее устаревшее состояние находится в другом месте. Первый вопрос, который нужно решить, — кто владеет настройками DNS, установленными туннелем, и имел ли значение выход, пропустивший очистку.

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

Определите, какой вид завершения произошёл

В издании Community OpenVPN и SIGINT, и SIGTERM — это запросы корректного завершения. SIGKILL нельзя перехватить: его нельзя ни заблокировать, ни обработать, поэтому никакая процедура завершения не получает шанса выполниться. Обычный Ctrl+C в терминале на переднем плане порождает SIGINT, а супервизор, переставший ждать, обычно переходит к SIGKILL. Разница важна, потому что только второй случай гарантирует, что хуки были пропущены.

Запуск внутри screen или tmux не меняет того, какой сигнал посылает Ctrl+C. Проверьте, что процесс действительно получил, а не то, что обычно делает терминал.

Когда туннель запускает служба или менеджер соединений, останавливайте это одно соединение через его владельца, а не убивайте pid. Менеджер может снова поднять процесс, оставив вам новый туннель и запутанное состояние резолвера. Отдельный процесс нуждается лишь в обычном запросе на завершение, чтобы очистка выполнилась.

Определите, кто владеет резолвером

systemd-resolved, скрипт в стиле resolvconf и простая перезапись файла — это три разных владельца. Первый держит настройки для интерфейса в памяти и сбрасывает их, когда интерфейс исчезает. Второй держит записи, которые сохраняются, пока что-то их не удалит. Третий пишет файл и оставляет восстановление тому, кто его написал.

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

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

Что down-хук может и чего не может

Скрипт down запускается один раз после закрытия устройства TUN/TAP. Добавление down-pre меняет этот порядок и запускает скрипт, пока устройство ещё существует, что требуется помощникам, которым нужно живое соединение.

Ни одна из директив не заставляет хук запуститься после SIGKILL. Привилегии также не восстанавливаются с помощью down-pre: если демон опускается до user или group или входит в chroot, хук работает с тем доступом, который это ему оставляет. Вызванный хук всё равно может не суметь обновить резолвер. Справочник OpenVPN описывает сигналы и жизненный цикл обратного вызова.

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

Проверьте состояние, которое действительно осталось

В системе с systemd-resolved resolvectl status показывает, какое соединение всё ещё несёт DNS-серверы VPN или домены маршрутизации. Это соединение может принадлежать исчезнувшему подключению или другому ещё поднятому туннелю.

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

Восстановите, не украв другое соединение

Когда настройки для соединения находятся в вашем ведении, resolvectl revert принимает имя соединения и очищает конфигурацию DNS времени выполнения для этого интерфейса. Это действие времени выполнения, а не правка профиля, поэтому постоянная конфигурация подключения остаётся нетронутой. Назовёте не то соединение — сотрёте DNS работающего туннеля, поэтому имя берётся из вывода статуса.

Прежде чем редактировать, убедитесь, что /etc/resolv.conf — управляемая символическая ссылка, затем ещё раз обычно остановите клиент и снова посмотрите на DNS. Если вторая остановка всё очищает, прежняя проблема была в принудительном завершении, а не в конфигурации.