VPN обрывается, когда экран гаснет: блокировка, гашение или сон?

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

Первая проверка: отделите блокировку от гашения и от сна

Блокировка меняет, кому разрешено пользоваться сессией; композитор продолжает рисовать, сетевой стек продолжает работать, а клиент VPN ничего не замечает. Гашение экрана выключает панель после периода бездействия и оставляет машину полностью бодрствующей. Сон останавливает процессоры, то есть ни один процесс в пространстве пользователя не планируется, поэтому никакое поддержание соединения не сработает, каким бы коротким вы ни задали интервал.

Именно эта таблица — причина, по которой «экран потемнел» не является диагнозом. Настольный компьютер, настроенный гаснуть через пять минут и уходить в сон через тридцать, покажет тёмный экран на шестой минуте при полностью здоровом туннеле. Сбой на тридцатой минуте — другое событие с другим решением, и оба выглядят одинаково с другого конца комнаты.

Вторая проверка: сведите события питания и сети на одну шкалу времени

Читайте журнал за ограниченное окно, а не за всю загрузку, и включите как менеджер входа, так и владельца соединения:

journalctl -b -u systemd-logind -u NetworkManager --since "45 minutes ago"
systemd-inhibit --list

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

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

Третья проверка: если машина уснула, решите, было ли это задумано

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

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

Четвёртая проверка: если машина осталась бодрствующей, посмотрите на сеть и клиент

У бодрствующей машины, потерявшей туннель, есть одна из трёх историй: сеть доступа отвалилась, клиент VPN остановился или перезапустился, либо сторона сервера дала ассоциации истечь, пока клиент продолжал считать, что соединён. Сравните отметки времени события звена с событием туннеля и будьте точны в том, какое было первым.

Затем проверьте путь восстановления отдельно от исходной сессии. Новый запрос через восстановленный туннель может пройти, пока долгоживущая сессия приложения, открытая до обрыва, остаётся сломанной, потому что приложение держит устаревший сокет или адрес из кэша. Это проблема приложения, а не доказательство того, что туннель не вернулся.

Что содержит полезный отчёт

Запишите последовательность с отметками времени и владельцами: когда сессия заблокировалась, когда экран потемнел, была ли зафиксирована заявка на сон, когда звено упало и вернулось, когда туннель сменил состояние и что на самом деле сделало приложение. У каждого пункта есть владелец, поэтому каждый пункт можно передать нужному человеку вместо того, чтобы он стал общей жалобой на Linux.

Если какой-то из этих строк нет, это следующее, что нужно измерить, а не следующее, что нужно изменить. Шкала времени с пробелом информативнее, чем изменение настроек, сделанное по наитию.