OpenVPN показва active (exited)? Намерете инстанцията, която сте стартирали

Проверявате тунела, изпълнявате systemctl status openvpn и получавате active (exited) без Main PID и с празен списък на процесите. Естественото четене е, че услугата е стартирала и е умряла, затова отваряте unit файла, намирате /bin/true и заключавате, че пакетът е счупен. В Debian пакета това състояние е wrapper, който работи както е проектиран, а тунелът живее в една от instance единиците, които той стартира. Общата единица никога няма да ви каже коя инстанция я е създала.

Какво всъщност означава active (exited) в тази единица

Пакетираната единица е еднократна задача: нейният ExecStart е /bin/true, а RemainAfterExit=yes е това, което държи завършена единица в състояние active (exited). Махнете тази директива и същата успешна задача /bin/true завършва в inactive (dead), което е точно състоянието, което хората очакват и разчитат погрешно в обратната посока. Командата е запълващ елемент и единицата докладва за работа, която извършват други единици. Нищо в тази подредба не е счупено и замяната на /bin/true променя договора на пакета, а не тунела.

Wrapper делегира. Той стартира instance единиците, които конфигурацията на пакета или неговият systemd генератор предоставя, затова празният списък на процесите не доказва нищо за тунела. Когато не е избрана инстанция, wrapper пак успява и пак не стартира нищо. Състоянието отговаря дали wrapper е работил, а не дали има тунел.

Четете трите реда от изхода на status, а не думата в скоби. Loaded посочва unit файла, който systemd е прочел, Active носи времевия печат на последното успешно изпълнение, а липсващият Main PID подхожда на завършена еднократна задача. Тези три реда са и начинът да различите този wrapper от услуга, която е паднала секунда след стартиране.

Избройте единиците, преди да прочетете status отново

Питайте systemd какво съществува, преди да питате какво работи. Шаблон може да е инсталиран, без да е създадена инстанция, и само създадена единица носи тунел. Започнете с заредения набор:

systemctl list-units 'openvpn*'

Този списък е това, което systemd е заредил в този момент, и е най-близкото до инвентар на тунелите. Инсталираните unit файлове отговарят на друг въпрос и този списък все още показва шаблон, когато нищо не е създадено:

systemctl list-unit-files 'openvpn*'

Четете двата списъка заедно, защото шаблон във втория и инстанция в първия са различни отговори. Шаблон, който съществува, и инстанция, която работи, не са един и същ факт и само второто означава тунел. Оформленията на пакетите се различават и между дистрибуциите и версиите на OpenVPN. По-стар шаблон openvpn@, разделена двойка client и server и wrapper на дистрибуция могат да бъдат законни в собствения си пакет.

Съобразявайте се с вашата машина, а не с ръководството, което сте намерили. Името на инстанцията в нечий чужд изход може да е office, докато вашето е home или work. Преноси се методът, а не низът.

Следвайте името на инстанцията до файла, който тя чете

В upstream шаблона за client работната директория на единицата е /etc/openvpn/client и командата ѝ взема %i.conf оттам, затова openvpn-client@office чете /etc/openvpn/client/office.conf. Потвърдете това съответствие върху инсталираната единица, вместо да вярвате на примера, защото шаблонът, който имате, може да е по-стар или пренаписан от дистрибуцията:

systemctl cat [email protected]

Четете drop-in файловете в долната част на този изход, защото файл под .d/ може да промени ExecStart, работната директория или пътя до конфигурацията. Профил, който сте изтеглили като office.ovpn, не е файлът, който инстанцията отваря. Тази разлика е обичайната причина грешка да посочва път, който никога не сте редактирали.

Относителните пътища в профила са следващият капан. Преместването на главния файл, докато препратките ca, cert и key остават относителни, заменя грешка за липсващ файл с друга грешка за липсващ файл. Втората сочи файл, в чието съществуване сте били сигурни, затова директорията на профила е по-важна от името на файла.

Стартирайте я, после прочетете журнала на тази инстанция

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

sudo systemctl start [email protected]
journalctl -u [email protected] -b

Стартирането и включването са различни решения: start изпълнява единицата сега, enable урежда следващото зареждане, а enable --now прави и двете с една стъпка. daemon-reload препрочита дефинициите на единиците и не рестартира работещ процес и не прилага редактиран профил. След като промените профила, рестартирайте инстанцията, защото това препрочита файла.

Не слагайте втори мениджър на същия тунел

NetworkManager и мениджърите на сесии OpenVPN 3 имат собствено състояние на връзката и systemd инстанция до един от тях поставя двама собственици на един тунел. Симптомът е тунел, който се вдига и секунди по-късно се заменя, или такъв, който отказва да остане спрян. Изберете мениджъра, който дистрибуцията ви документира за десктопа, и използвайте systemd съзнателно на сървър.

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

Отговорете на първоначалния въпрос с името на инстанцията, файла, който е прочела, и реда от журнала, който се е провалил. Бележките на OpenVPN за интеграцията със systemd описват оформлението на шаблона и съответствието на файла, през което се разрешава името на инстанцията.