OpenVPN, запущенный до появления сети, — это не сбой

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

Миф: запущенная служба означает работающий туннель

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

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

Читайте журнал экземпляра, а не состояние юнита. Строка причины находится в журнале, а не в метке состояния.

Миф: настройки повторов покрывают любой сбой

Разрешение имён и повторы транспорта — отдельные параметры с отдельными значениями по умолчанию. resolv-retry управляет повторными запросами удалённого имени хоста, и документированное значение по умолчанию пытается бесконечно. connect-retry задаёт интервал между попытками, а connect-retry-max может ограничить число попыток для каждой удалённой записи. Прежде чем что-то из этого менять, посмотрите, какой этап называет журнал.

Ничто из этого не относится к испорченному профилю, нечитаемому закрытому ключу или отклонённой учётной записи. Им нужна правка, и клиент, который продолжает их повторять, не продвигается.

Бесконечно повторять неутверждённый сертификат — не причина убирать проверку. Это причина прочитать ошибку.

Миф: одного средства запуска достаточно, добавьте второе

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

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

Владелец определяет и то, откуда берутся повторы и учётные данные, поэтому это решение идёт до любой настройки. Владение идёт первым именно по этой причине.

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

Порядок может ждать настроенного адреса, и это всё, что он гарантирует. network-online.target задерживает активацию, пока менеджер не сочтёт сеть поднятой, а определение поднятой сети зависит от менеджера. Он ничего не говорит о том, разрешается ли имя хоста VPN, отвечает ли слушатель и пропустил ли устройство портал с авторизацией.

Прочитайте установленный юнит и любые drop-in, прежде чем добавлять зависимости. Широкий After= на каждой сетевой службе задерживает загрузку, не устанавливая нужное вам подключение.

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

Что происходит после первого поднятия туннеля

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

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

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