OpenVPN при загрузке Ubuntu: NetworkManager или systemd?

Большинство руководств подают этот выбор как косметический: либо позволить NetworkManager поднять туннель, либо включить экземпляр systemd и закончить. Эти два пути различаются в одном, что определяет результат на машине без экрана, и это не связано с тем, какой инструмент новее. NetworkManager разблокирует секреты через сеанс; у экземпляра systemd нет сеанса, который можно разблокировать. Выберите тот, чья работа с секретами соответствует машине перед вами.

Всё остальное, от установки маршрутов до поведения при переподключении, следует из этого первого решения.

Связка ключей — это разница, о которой никто не говорит

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

Экземпляр systemd избегает этой проблемы, читая файл учётных данных с диска, что делает файл тем, что вы защищаете. chmod 400 плюс владение root — это минимум, и файл должен оставаться вне резервных копий и шаблонов образов, которые вы не контролируете.

Привязка VPN к соединению не гарантирует загрузку

В nm-connection-editor выберите проводное или беспроводное соединение вместо VPN, откройте вкладку General, отметьте опцию автоматического подключения к VPN и назовите профиль. Затем NetworkManager активирует VPN как вторичное соединение, когда основное достигнет подключённого состояния. Это зависимость, а не правило межсетевого экрана. Пакеты всё ещё могут уходить в течение секунд до поднятия туннеля, а сохранённый секрет, который не разблокируется, оставляет машину в сети без него.

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

Экземпляру systemd нужно совпадающее имя файла

Положите профиль в клиентский каталог, которого ожидает пакет, например /etc/openvpn/client/office.conf, и укажите изнутри на файл учётных данных с помощью auth-user-pass office.cred. Имя экземпляра — это имя файла без суффикса, поэтому openvpn-client@office читает office.conf. Включите его с помощью sudo systemctl enable --now openvpn-client@office и подтвердите соответствие с помощью systemctl cat openvpn-client@office, а не доверяя примеру из блога.

Пути внутри профиля разрешаются относительно рабочего каталога юнита, а не самого профиля, поэтому относительная строка ca или auth-user-pass может не сработать при загрузке, хотя работает при ручной проверке. Используйте абсолютные пути для всего, что юнит должен найти. Затем прочитайте journalctl -u openvpn-client@office -b после реальной загрузки; юнит, который сообщает об активности без туннеля, обычно называет в этом журнале отсутствующий файл.

Более старые пакеты поставляют другое имя шаблона, поэтому systemctl list-unit-files 'openvpn*' решает, какое существует на этом хосте.

Поведение при переподключении — отдельное решение

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

Остановка столь же буквальна: sudo systemctl disable --now openvpn-client@office останавливает работающий экземпляр и удаляет ссылку автозапуска. Одно лишь отключение оставляет туннель работать до следующей перезагрузки, что удивляет каждого, кто проверяет отключением и видит, что интерфейс остаётся поднятым.

Перезагрузитесь, затем проверьте четыре вещи по порядку

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

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

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