Почему 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, а не проблема хука.

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

Похожие статьи