OpenVPN 3 Linux: прочитайте помилку D-Bus, перш ніж відкочувати версію
П'ять служб, один інтерфейс. Зіставте помилку D-Bus із компонентом, який відмовив, перевірте, чи існує сеанс, і лише потім виправляйте на цій межі.
Збої в OpenVPN 3 Linux надходять як помилка методу D-Bus із незнайомим іменем, і спокуса — відкотити пакет і сподіватися. Клієнт не є однією програмою: інтерфейс командного рядка спілкується через шину зі службами, яким належать профілі, сеанси, рушій VPN і привілейовані зміни мережі. Визначити, яка з цих п'яти володіє невдалим викликом, — більша частина діагностики, і це коштує однієї команди замість відкату. Далі йде саме це рішення, у тому порядку, у якому збої зазвичай з'являються.
П'ять власників за однією командою
Важливі п'ять процесів, і кожен має власне ім'я на шині: інтерфейс, що приймає вашу команду, менеджер конфігурації, який зберігає профілі та політику доступу до них, менеджер сеансів, якому належить час життя сеансу, серверна частина, що веде з'єднання через OpenVPN 3 Core Engine, і служба налаштування мережі, яка встановлює інтерфейс, маршрути та параметри DNS. Помилка, що називає об'єкт конфігурації, тому не є помилкою серверної частини, а серверна частина, яка не запускається, не є збоєм автентифікації. Віднести повідомлення до одного з цих рядків потрібно до того, як щось буде змінено, бо кожен наступний крок залежить від того, який рядок істинний. Вгадування рядка — це шлях, на якому коротке виправлення перетворюється на цілий день роботи з пакетами.
Запитайте системну шину, які служби присутні, перш ніж питати будь-що інше, а потім підтвердьте, що встановлені частини згодні щодо версії. OpenVPN 3 Linux реєструє ці служби як системні юніти, тому опитувати треба системну шину, запит версії потребує адміністративних прав, а список, зроблений з --user, читає ваш сеанс входу, де юніти ніколи не з'являються. Служби активуються за потреби, а деякі завершуються в простої, тому служба, відсутня до вашого першого запиту, просто ще ні про що не запитувалася. Три команди нижче відповідають про наявність, версію та стан юніта, не відкриваючи сеанс VPN.
sudo busctl list | grep -i openvpn
sudo openvpn3-admin version --services
systemctl list-units 'openvpn3*'Що насправді доводить кожен список
Власні подання клієнта — найдешевший доступний доказ, і кожне з них доводить менше, ніж здається. Профіль у списку конфігурації показує, що профіль імпортовано, і нічого про те, чи дозволено комусь підключатися з ним. Сеанс у списку сеансів показує, що об'єкт сеансу існує, і нічого про те, чи завершилася віддалена автентифікація.
openvpn3 configs-list
openvpn3 sessions-listШляхи об'єктів у цих виводах позначають керовані об'єкти на шині, а не файли, тому їх не можна редагувати, і шлях, записаний раніше, стає застарілим у ту мить, коли цей сеанс від'єднується. Повторне використання шляху з ваших нотаток дає помилки "no such object", які не мають нічого спільного з VPN. Таблиця етапів нижче відокремлює те, що встановлює кожен крок з'єднання, від того, що залишається відкритим, і рішення про відкат спирається саме на цю різницю. Прочитайте рядок, що відповідає вашим доказам, і перечитайте текст помилки ще раз.
| Stage | What exists | What proves it | What it does not prove |
|---|---|---|---|
| Profile imported | A configuration object held by the configuration manager | The profile is listed by the client | That the profile owner permits a connection |
| Session requested | A session object held by the session manager | The session appears in the session list | That the remote side accepted the credentials |
| Connect dispatched | An asynchronous attempt on the VPN backend | Status changes arrive for that session | That an interface was configured |
| Tunnel configured | An interface, routes and DNS settings | The network service reports success and routes appear | That traffic reaches the peer |
Виклик з'єднання повертається раніше, ніж існує тунель
Виклик з'єднання передає вам сеанс для спостереження і повертається, тому зовні успішний виклик, за яким настає тиша, — це нормальний проміжний стан, а не суперечність. Інтерфейс усе одно має відстежувати зміни стану й відповідати на будь-який запит взаємодії. Профіль, якому потрібні облікові дані й який не отримує відповіді, чекає в стані, що виглядає точно як зависла серверна частина. Цей стан очікування вартий упізнавання, бо він відправляє людей до не того компонента.
Поки спроба виконується, стежте за списком сеансів і власним журналом інтерфейсу для цього профілю. Сеанс, який так і не виходить із початкового стану, називає компонент, що зупинився, і журнал зазвичай називає його вже в перших рядках. Тримайте ім'я профілю під рукою, оскільки команда журналу приймає профіль, а не шлях сеансу, що є ще однією причиною перечитати список замість повторного використання шляху.
openvpn3 sessions-list
openvpn3 log --config <profile> --level 6Читання журналу одного компонента без відкриття сеансу
Коли інтерфейс не повідомляє нічого корисного, перейдіть до компонента, який записав збій у журнал, замість того щоб починати нове з'єднання. За налаштованого журналізатора systemd-journald обмежений перегляд журналу адміністратором читає події одного компонента, не торкаючись політики шини й не відкриваючи сеанс, і це важливо, бо діагностика, що змінює вимірювану систему, доводить дуже мало. Фільтруйте за юнітом, а не за тегом syslog: окремі службові юніти не гарантують спільного ідентифікатора, тому запит за тегом може повернути порожню сторінку, тоді як сам юніт записав збій.
Запишіть чотири поля, перш ніж просити в когось допомоги: повне ім'я помилки, задіяні службу та об'єкт, позначку часу й версії встановлених пакетів. Саме це потрібно супровіднику, і жодне з них не вимагає вставляти профіль або облікові дані в заявку. Розширення політики доступу до шини, щоб приглушити помилку, — не діагностика, воно стирає межу, яка називала компонент за вас. Приватний вміст профілів залишається поза спільними звітами з тієї ж причини, що й облікові дані.
journalctl -u 'openvpn3-service-*' -n 50 --no-pager
openvpn3-admin journal --service <name>Виправлення межі, яка відмовила
Кожен рядок карти має власне виправлення, і рядки не замінюють один одного. Відмовлена операція над профілем — це питання політики та володіння, тоді як серверна частина, що не активується, — питання служб і пакування. Сервер, що відкидає автентифікацію, не є ні тим ні іншим, тому повторні зміни пароля не можуть виправити локальну проблему активації. Вибір неправильного виправлення — це шлях, на якому проблема політики перетворюється на перевстановлення.
Після зміни пакетів перевірте узгоджене підтримуване встановлення, а не копіюйте старий двійковий файл на його місце. Контрольований відкат — законна відповідь на підтверджену регресію за умови, що пакети залишаються сумісними і що існує шлях назад до підтримуваного супроводу. Установіть цей шлях до того, як служба перестане запускатися, а не після.
Інша платформа може використовувати ту саму базову бібліотеку VPN, не поділяючи шинні служби Linux, тому схожий збій у Windows нічого не говорить про цей. Огляд D-Bus описує шляхи об'єктів, надані для конфігурацій і сеансів, і саме на цій частині архітектури тримається ця діагностика. Прочитайте його один раз, і наступна помилка прийде з уже прив'язаним до неї компонентом.