Чому OpenVPN помирає після пробудження ноутбука?

Сон може вбити сеанс OpenVPN, залишивши tun0. Перевірте тунель, потім перезапустіть юніт із хука сну systemd, а не пристрій.

Переведіть машину в режим сну, розбудіть її і потім, перш ніж торкатися будь-якої конфігурації, перевірте три речі в цьому порядку: чи tun0 ще існує, чи маршрут до внутрішньої адреси ще обирає його і чи сервер ще перелічує цього піра. Пристрій, що пережив сон, коли маршрут вказує в інше місце, — це залишок, а не тунель. Коли маршрут правильний, а трафік усе одно вмирає, несправність лежить вище тунелю, і перезапуск клієнта цього не змінить. Автоматизувати перезапуск має сенс лише після того, як ручна перевірка показала, який із цих трьох випадків у вас.

ip -br address show tun0
ip route get 10.20.0.10
journalctl -u openvpn-client@office -b --no-pager | tail -30

Відтворіть пробудження, перш ніж автоматизувати його

Сон частіше завершує зашифрований сеанс, ніж видаляє пристрій. UDP-потік, що тримав тунель живим, зупиняється, сервер може скинути піра, і клієнт або помічає це й перепідключається, або зберігає інтерфейс, за яким нічого немає. Сама перевірка інтерфейсу доводить мало, бо застарілий пристрій виглядає точно як робочий доки пакетам не доведеться пройти крізь нього. Виконайте пошук маршруту і один реальний запит через тунель, потім прочитайте журнал навколо моменту пробудження.

Якщо клієнт повертається сам, хук додає метушню замість надійності. Якщо він ніколи не відновлюється, автоматизація — чесне рішення.

Де насправді живе хук сну systemd

Багато старих посібників вказують на /etc/pm/sleep.d, каталог, що належить pm-utils і до якого сон на базі systemd ніколи не звертається. systemd читає хуки з /usr/lib/systemd/system-sleep/ і /etc/systemd/system-sleep/, передаючи спершу фазу, а потім операцію, тож pre і post — єдині значення, на які хук розгалужується. Тримайте локальну копію в /etc замість редагування файлу з пакунка і пам'ятайте, що скрипт виконується як root посеред переходу, тому він має повертатися швидко.

#!/bin/sh
case "$1" in
  post)
    systemctl --no-block try-restart [email protected]
    ;;
esac
exit 0

try-restart торкається юніта лише тоді, коли він уже активний, тому тунель, який ви навмисно вимкнули, лишається вимкненим і під час пробудження. --no-block не дає хуку чекати, поки клієнт веде переговори, що важливо, коли мережа ще не піднялася. Разом два прапорці означають хук, який тихо збоїть, замість того щоб затримувати всю послідовність пробудження. Якщо юніт уже зупинено, не відбувається взагалі нічого, і це саме той результат, який там потрібен.

Відновіть службу, залиште tun0 у спокої

Якщо зняти tun0 вручну, демон продовжить наглядати за інтерфейсом, яким уже не володіє, а наступна зміна стану дасть заплутані помилки. Цільтеся в службу або її профіль з'єднання, а не в інтерфейс; спершу перевірте точне ім'я юніта, бо пакунки дистрибутивів, OpenVPN 3 і NetworkManager обирають різні. Профіль NetworkManager повертається, коли це з'єднання проганяють заново, тож юніт systemd там не ціль. Яким би не був механізм, це має бути та сама дія, яку ви перевірили вручну.

Перезапуск заново встановлює маршрути, які клієнт проштовхнув під час підключення. Більшості пробуджень це потрібно. Машині, куди ви додали власні маршрути, — ні, тому перевірте їх знову, а не припускайте, що відновлення їх повернуло, і запишіть їх там, де наступне пробудження зможе їх знайти.

Розберіться з таймінгом, який ви не контролюєте

Бездротова асоціація і DHCP часто завершуються вже після того, як хук відпрацював, тому перезапуск може не вдатися, поки шляху до сервера ще немає. Зачекайте трохи цю адресу, спробуйте ще раз і запишіть результат.

Розв'язання імен — окремі перегони, бо мережевий стек робочого столу може відновити DNS уже після того, як тунель піднято. Перевіряйте запити окремо з resolvectl query internal.example, а не виводьте їх із робочого маршруту. Тунель, який правильно маршрутизує і нічого не розв'язує, — це проблема DNS, а не проблема хука.

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

Схожі статті