OpenVPN 3 Linux: прочетете грешката от 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. Таблицата с етапи по-долу отделя какво установява всяка стъпка от връзката от това какво оставя отворено, и решението за връщане на версия се опира точно на това различие. Прочетете реда, който отговаря на доказателството ви, и прочетете текста на грешката отново.

Извикването за свързване се връща преди тунелът да съществува

Извикването за свързване ви дава сесия за наблюдение и се връща, затова привидно успешно извикване, последвано от тишина, е нормално междинно състояние, а не противоречие. Интерфейсът все още трябва да следи промените в състоянието и да отговаря на всяка заявка за взаимодействие. Профил, който се нуждае от удостоверение и не получава отговор, чака в състояние, което изглежда точно като забила сървърна част. Това състояние на изчакване заслужава разпознаване, защото изпраща хората към грешния компонент.

Докато опитът тече, следете списъка със сесии и собствения дневник на интерфейса за този профил. Сесия, която никога не напуска началното си състояние, назовава компонента, който е спрял, и дневникът обикновено го назовава още в първите редове. Дръжте името на профила под ръка, тъй като командата за дневника приема профил, а не път на сесия, което е още една причина да прочетете списъка отново, вместо да използвате път повторно.

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 документира пътищата на обекти, предоставени за конфигурации и сесии, и точно тази част от архитектурата носи тази диагностика. Прочетете го веднъж и следващата грешка ще дойде с вече прикачен компонент.