Systemd проти NetworkManager: хто запускає VPN під час завантаження?

Дві машини Ubuntu з одного образу, один профіль VPN, протилежні результати під час входу: на одній тунель уже піднятий до появи робочого столу, на іншій він не піднімається ніколи. Профіль тут не змінна. Різниця в тому, якому з трьох компонентів доручено його запускати, і ці три не ділять один перемикач.

Порівняти їх поряд швидше, ніж гадати. Кожен із них відмовляє впізнаваним чином, і саме тому порівняння варте зусиль.

Три засоби запуску з трьома різними тригерами

Пакетна служба openvpn — найстаріший шлях. Її init-скрипт читає список автозапуску з /etc/default/openvpn. Якщо цей список закоментовано або залишено порожнім, скрипт запускає кожну конфігурацію, знайдену в цьому каталозі, а не ту єдину, яку ви додали. Один файл, доданий для одного тунелю, може тихо підняти кілька.

Другий рядок — той, який налаштовують неправильно. NetworkManager тримає імпортований профіль і запустить його, але лише як вторинний до іншого з’єднання, тобто тригер належить мережевій ланці, а не VPN.

Порівняйте вартість налаштування й охоплення

Шлях через init-скрипт коштує одного рядка й покриває кожну конфігурацію на машині. Це годиться для маршрутизатора і не годиться для ноутбука, який підключається до різних мереж. Шлях через NetworkManager коштує пошуку UUID і прив’язує тунель до одного базового з’єднання. Він піднімається в робочій мережі й залишається вимкненим у готельній.

Написаний вручну unit коштує найдорожче й дає найбільше контролю, включно з порядком щодо інших служб. Вирішальний чинник — охоплення. Якщо в машини одна мережа й один тунель, пакетна служба чесна й передбачувана. Якщо тунель має йти за конкретною мережею Wi-Fi, вторинний — єдиний із трьох, хто виражає цю умову без додаткових скриптів.

Виберіть одного власника й приберіть інших

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

# who is configured to start something?
grep -v '^#' /etc/default/openvpn
systemctl list-units 'openvpn*'
nmcli -g connection.secondaries connection show 'Work Wi-Fi'

# NetworkManager: attach the tunnel to the base link by UUID
TUNNEL=$(nmcli -g UUID connection show 'Corp Tunnel')
nmcli connection modify 'Work Wi-Fi' +connection.secondaries "$TUNNEL"

Якщо виводиться саме пакетний шлях, робіть це в правильному порядку: встановіть AUTOSTART у none, виконайте systemctl daemon-reload, щоб згенеровані unit-и підхопили новий список, і потім вимкніть шаблонний екземпляр, який більше не потрібен. Пропуск перезавантаження залишає старі unit-и активними, і здається, ніби зміна ні на що не вплинула.

Зависання під час зупинки — окрема проблема з обмеженою відповіддю. TimeoutStopSec задає, скільки systemd чекає перед надсиланням SIGKILL. Правильне місце задати це — drop-in, бо редагування пакетного unit-а втрачає зміну під час наступного оновлення.

Перевірте, що саме запустилося

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

systemctl is-enabled openvpn-client@office
systemctl status openvpn-client@office --no-pager
nmcli -f GENERAL.STATE,connection.secondaries connection show 'Work Wi-Fi'
ip -brief link show tun0

Тут доречна ще одна перевірка: переконайтеся, що ExecStart unit-а вказує на той бінарник, про який ви думаєте. Клієнт, зібраний локально, або пакет snap часто потребує явного шляху чи обгортки snap run, бо systemd не успадковує порядок пошуку вашої оболонки. Порівняння command -v openvpn із файлом unit-а вирішує це за секунди.

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