Один профіль, два власники: NetworkManager чи systemd

З файлом .ovpn нічого не відбувається, доки ним щось не володіє. На робочому столі Pi ймовірні власники — NetworkManager, який зберігає імпортоване з'єднання у власному файлі ключів, і окремий сервісний юніт, що читає конфігурацію з каталогу. Це дві моделі роботи з різним зберіганням, різним поводженням з обліковими даними та різними правилами активації. Свідомо вибрати одну з них — усе завдання; копіювання файлу в обидва місця лише робить вибір випадковим.

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

Два способи володіти одним тунелем

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

Це не два погляди на одну річ. Редагування завантаженого файлу не змінює ні того, що зберіг NetworkManager, ні того, що читає юніт, і будь-який із них може бути тим, що побудував тунель, який ви щойно перевірили.

Ідіть за з'єднанням, яке робочий стіл справді використовує

Задокументована операція імпорту, nmcli connection import type openvpn file office.ovpn, створює з'єднання через плагін. Запишіть його UUID і використовуйте цей ідентифікатор далі, бо назви редагуються, а два з'єднання можуть мати одну мітку. nmcli connection show перелічує те, що існує, а читання власних властивостей з'єднання каже, з якого файлу воно прийшло і що зберігає. Якщо UUID, який ви редагуєте, не той, що активує робочий стіл, ваші правки — лише оздоблення.

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

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

Прочитайте шаблон юніта, перш ніж покладатися на нього

Там, де пакунок постачає клієнтський юніт у стилі upstream, екземпляр з іменем office відповідає файлу %i.conf у налаштованому каталозі юніта, який для шаблону 2.6 — це /etc/openvpn/client. Прочитайте встановлений юніт і будь-які додаткові файли, перш ніж довіряти прикладу з посібника, бо дистрибутиви переносять шляхи. Ручний запуск із термінала нічого не доводить про те, як служба бачить файли, секрети чи права. Вікно пароля на робочому столі також не є доказом, що неінтерактивний юніт має схвалений спосіб отримати той самий пароль.

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

Виведіть дублікат з ужитку, не втрачаючи доступу

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

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