VPN отключается при выключении экрана: какой жизненный цикл?

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

Три сбоя, которые выглядят одинаково

Ограниченный фоновый процесс перестаёт отправлять keepalive, и противоположная сторона в конце концов объявляет туннель мёртвым. Неактивное сопоставление на пути может истечь, пока устройство спит, поэтому обратный трафик так и не доходит до клиента, который всё ещё полностью жив. Приложение может потерять собственное соединение, пока туннель остаётся поднятым, что даёт диалог ошибки со здоровым значком VPN позади. С точки зрения пользователя все три читаются как отключение VPN при выключении экрана.

Различие важно, потому что способы лечения на практике противоречат друг другу. Исключение клиента из ограничений энергосбережения исправляет первый случай и ничего не делает для истёкшего сопоставления. Продление keepalive исправляет второй и тратит батарею в третьем, где изначально ничего сетевого не было неправильно.

Сравните активное и неактивное состояние в контролируемых условиях

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

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

Прочитайте фоновую политику платформы

В Android жизненный цикл службы VPN является частью платформы, а always-on и block-without-VPN — отдельные переключатели с отдельными эффектами. Клиент, который не always-on, может быть остановлен, когда система забирает ресурсы, и никакая настройка в приложении этого не меняет. iOS применяет свои собственные фоновые ограничения к поставщику туннеля, и документированное поведение отличается от демона рабочего стола, который просто продолжает работать. Читайте документацию платформы для соответствующего компонента, а не общее руководство по оптимизации батареи.

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

Что делает устройство после пробуждения

Автоматическое переподключение — не то же самое, что блокировка трафика во время промежутка. Проверьте оба: возвращается ли туннель и вышло ли незащищённым приложение, которое пыталось отправить данные во время промежутка. Клиент, который переподключается за две секунды, но в первую утекает DNS-запрос, имеет неверную политику отказов для рабочего устройства. Тестируйте безвредными запросами и контролируемым вами назначением.

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