openvpn3 session-start ігнорує ваш файл облікових даних

Клієнт 3.x приймає облікові дані на початку сеансу і не читає збережений файл. Використовуйте запит або шлях autoload і знайте, що зберігає кожен із них.

Підключіться клієнтом 2.x, і профіль працює; передайте той самий файл клієнту 3.x, і він зупиняється на запиті пароля. Передайте --auth-user-pass creds.txt до openvpn3 session-start, і результат той самий, бо в новішого клієнта немає етапу, який читає файл. Відмова навмисна: облікові дані належать сеансу, а сеанс створює служба, а не процес у вашому терміналі. Виберіть між інтерактивним запитом і помічником autoload і знайте, що зберігає кожен із них.

Чому збереженому файлу нікуди подітися

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

Старий шаблон варто назвати, щоб від нього було легше відвикнути: профіль посилається на файл облікових даних, а демон читає його під час запуску тунелю. У новій моделі облікові дані належать сеансу і подаються, коли цей сеанс починається. openvpn3 session-start --config work.ovpn запитує їх, а --auth-user-pass creds.txt відхиляється, бо ніщо на цьому шляху не відкрило б файл. Кожен знайдений вами рецепт для 2.x припускає етап, якого більше немає.

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

Шлях запиту й сеанс, який він залишає

Подати пароль на старті сеансу — це і є задуманий робочий процес. Клієнт запитує один раз, передає облікові дані бекенду сеансу й продовжує:

openvpn3 session-start --config work.ovpn
openvpn3 sessions-list

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

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

Автоматизація без людини за клавіатурою

Там, де машині треба підключитися без людини, проєкт постачає openvpn3-autoload. Він читає каталог профілів і відповідний дескриптор для кожного профілю, а дескриптор подає облікові дані відкритим текстом. Помічник — це окремий двійковий файл, зазвичай у /usr/sbin/openvpn3-autoload, а не прапорець session-start. Його налаштування означає створення каталогу, копіювання профілю під іменем, якого чекає дескриптор, і запис дескриптора.

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

mkdir -m700 -p ~/.openvpn3/autoload
cp work.ovpn ~/.openvpn3/autoload/client.conf
$EDITOR ~/.openvpn3/autoload/client.autoload

Дескриптор називає облікові дані й просить автоматичний запуск. Тримайте значення пароля поза системою контролю версій:

{
  "autostart": true,
  "user-auth": {
    "autologin": true,
    "username": "svc-vpn",
    "password": "change-this-value"
  }
}

Потім викличте помічник один раз і переконайтеся, що сеанс з'явився. Друга команда — це перевірка, а не ще один крок налаштування:

/usr/sbin/openvpn3-autoload --directory ~/.openvpn3/autoload
openvpn3 sessions-list

Під час завантаження пакетований модуль із назвою openvpn3-autoload.service використовує загальносистемний каталог /etc/openvpn3/autoload, а не каталог для окремого користувача. Цьому місцю потрібні права root і суворіший режим, а дескриптор досі тримає пароль відкритим текстом. Компроміс очевидний: пароль тепер лежить на диску, тож ставтеся до цього каталогу як до секрету, виключіть його з резервних копій поза хостом і вибирайте інтерактивний шлях щоразу, коли є людина.

Відмови шини, що виглядають як відмови пароля

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

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

systemctl status openvpn3-service-client
journalctl -b -u openvpn3-service-client --no-pager | tail -20

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

Коли старий клієнт ще використовується

Клієнт 2.x досі приймає файл облікових даних, а зв'язка ключів може відповісти на його запит, жодного разу не допустивши секрет на диск. Обгортка розв'язує запис, тож файл називає пошук, а не пароль. Ця схема залежить від розблокованої зв'язки ключів, яку не може надати контейнер без сеансу входу або модуль, що запускається до чийогось входу. Тоді інструмент пошуку повідомляє про колекцію, до якої не може писати, і помилка виглядає як відмова облікових даних, хоча це відмова зв'язки ключів.

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

Схожі статті