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 описују распоред шаблона и мапирање датотеке кроз које се име инстанце разрешава.