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 или удалённый партнёр готовы.

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

Проверьте привязку после холодной загрузки

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

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

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