vpn.persistent продолжает пытаться, но не удерживает подключение

NetworkManager предоставляет одно свойство, vpn.persistent, и люди просят его одновременно отвечать на четыре разных вопроса. Его документация вышестоящего уровня осторожна: устойчивость действует, когда служба VPN её поддерживает и профиль её включает, и тогда соединение просят пережить изменения канала и сбои вплоть до явного отключения. Та же документация показывает, что значение по умолчанию — false, а это не то, что предполагает большинство планов восстановления. Читайте это как просьбу о попытке, а не как обещание результата.

К чему настройка действительно обязывает

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

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

Отношение к свойству как к попытке задаёт и правильное ожидание от тестирования. Вы проверяете не то, установлен ли флаг; вы проверяете, случилось ли что-нибудь, когда канал упал. Это разные эксперименты, и только один из них стоит потраченного дня.

Четыре вопроса, слитые в один

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

Восстановление спрашивает, что происходит, когда канал меняется или исчезает, и это тот узкий вопрос, который решает vpn.persistent. Живучесть спрашивает, может ли клиент понять, что дальняя сторона перестала отвечать, и вместо неё на это отвечает поведение keepalive или перезапуска OpenVPN; два механизма часто описывают одним и тем же словом и реализуют в разных местах. Тестируйте их отдельно, разными инструментами, иначе припишете одно поведение другому.

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

Контрольный список, который их разделяет

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

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

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

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

Аутентификация — часть восстановления

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

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

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

Устойчивость — не kill switch

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

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

Запишите обе половины в заметках о восстановлении: что пытался сделать VPN и какой трафик приложений был разрешён, пока шла попытка.