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, а не на сам тунель.

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