Локальне зв’язування OpenVPN не вдається під час завантаження: чекати чи повторювати

Для сервера OpenVPN, який не запускається під час завантаження, пропонують два рішення: дочекатися адреси або дозволити службі повторювати спроби, доки зв’язування не вдасться. Обидва усувають той самий симптом, але по-різному поводяться в разі збою. Очікування фіксує конкретну передумову й гучно падає, коли її немає; повторювання приховує передумову й продовжує спроби. Що з цього належить вашому юніту, залежить від того, чи є ця адреса запроєктованою залежністю, чи випадковістю таймінгу.

Обидва варіанти кращі за фіксований сон, який нічого не чекає і не повідомляє, чого саме чекав.

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

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

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

Очікування адреси проти повтору прив’язки

Очікування означає ExecStartPre, який опитує, доки адреса не з’явиться, з обмеженою кількістю спроб і ненульовим кодом виходу, коли час вичерпано. Повтор означає дозволити головному процесу впасти й попросити менеджер служб запустити його знову, наприклад Restart=on-failure з RestartSec=5. Перше повідомляє про відсутню передумову як про невдалий юніт, а друге — як про серію перезапусків, що зрештою припиняється; у журналі це гучніше, але переживає адресу, яка з’являється пізно з причин, яких не передбачити.

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

Чому network-online.target недостатньо

network-online.target обіцяє рівно те, що чинна реалізація мережі розуміє під online, і нічого більше. З systemd-networkd про досягнення цієї цілі вирішує systemd-networkd-wait-online, і його типове уявлення про online може бути задоволене ще до того, як ваша конкретна адреса з’явиться. Під NetworkManager служба wait-online застосовує власні правила. Упорядкування після цілі — це надійна база, а не гарантія, що одна адреса, відповідь DNS або віддалений peer готові.

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

Перевірте прив’язку після холодного завантаження

Перевіряйте справжнім холодним завантаженням, а не перезапуском служби, бо перезапуск успадковує адресу, яку мала створити послідовність завантаження. Після завантаження ss -lntp або ss -lunp показує локальну адресу, до якої насправді прив’язався кожен слухач, а journalctl -b -u openvpn-server@server показує, чи перша спроба не вдалася. Порівняйте прив’язану адресу з тією, що в профілі, а потім повторіть порівняння після повторного підключення мережі.

Якщо профіль ніколи не потребував фіксованої адреси, видалення local — законне спрощення, але зробіть це рішенням про безпеку, а не діагностичною звичкою.

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