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. Якщо друге зупинення все очищає, попередня проблема була в примусовому завершенні, а не в конфігурації.