OpenVPN, запущений до появи мережі, — це не збій

Ви запускаєте клієнт під час завантаження, юніт повідомляє, що активний, а тунелю немає. Природний висновок — служба не запустилася, природне виправлення — запустити її знову. І те, і те помилкове достатньо часто, щоб заслужити правило: робочий клієнт, який повторює спроби, зовні виглядає точно як зламаний. Різниця в тому, що робить процес, а не в стані юніта.

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

Активний юніт доводить, що процес запущено і він не завершився. Він не доводить, що профіль завантажився, сертифікат прийнято або дальня сторона відповіла. Пакувальний клієнт може хвилинами сидіти в циклі повторів, поки systemd не повідомляє нічого, крім успіху. Ця прірва між станом і поведінкою і є вся суть.

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

Читайте журнал екземпляра, а не стан юніта. Рядок причини міститься в журналі, а не в мітці стану.

Міф: налаштування повторів покривають будь-який збій

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

Ніщо з цього не стосується пошкодженого профілю, нечитабельного закритого ключа або відхиленого облікового запису. їм потрібне виправлення, і клієнт, який продовжує їх повторювати, не просувається.

Повторювати не схвалений сертифікат вічно — не причина прибирати перевірку. Це причина прочитати помилку.

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

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

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

Власник визначає й те, звідки беруться повтори та облікові дані, тому це рішення йде перед будь-яким налаштуванням. Володіння йде першим саме з цієї причини.

Що насправді потребує порядку

Порядок може чекати на налаштовану адресу, і це все, що він гарантує. network-online.target затримує активацію, доки менеджер не вважатиме мережу піднятою, а визначення піднятої залежить від менеджера. Він нічого не каже про те, чи розв'язується ім'я хоста VPN, чи відповідає слухач і чи пропустив пристрій портал з авторизацією.

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

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

Що відбувається після першого підняття тунелю

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

Інтерактивна автентифікація обмежує відновлення без нагляду. Фоновий юніт не розблоковує зв'язку ключів робочого столу і не відповідає на запит MFA, тож дотримуйтеся схваленої схеми облікових даних для контексту служби.

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