OpenVPN кажа active (exited)? Знайдзіце асобнік, які вы запусцілі

Вы правяраеце тунель, запускаеце systemctl status openvpn і атрымліваеце active (exited) без Main PID і з пустым спісам працэсаў. Натуральнае чытанне такое: служба запусцілася і памерла, таму вы адкрываеце unit, знаходзіце /bin/true і робіце выснову, што пакет зламаны. У Debian-пакаванні гэты стан — гэта wrapper, які працуе як задумана, а тунель жыве ў адным з instance-unit, якія ён запускае. Агульны unit ніколі не скажа, які асобнік яго пабудаваў.

Што насамрэч значыць active (exited) у гэтым unit

Пакаваны unit — гэта аднаразовая задача: яго ExecStart — /bin/true, а RemainAfterExit=yes — тое, што ўтрымлівае завершаны unit у стане active (exited). Прыбярыце гэту дырэктыву, і тая ж паспяховая задача /bin/true скончыцца ў inactive (dead), што якраз і ёсць стан, які людзі чакаюць і няправільна чытаюць у адваротны бок. Каманда — гэта запоўніцель, і unit паведамляе пра працу, якую выконваюць іншыя unit. У гэтай схеме нічога не зламана, і замена /bin/true змяняе кантракт пакавання, а не тунель.

Wrapper дэлегуе. Ён запускае instance-unit, якія пастаўляе канфігурацыя пакета або яго systemd-генератар, таму пусты спіс працэсаў нічога не даказвае пра тунель. Калі не выбраны ніводзін асобнік, wrapper усё роўна паспяховы і ўсё роўна нічога не запускае. Стан адказвае, ці запусціўся wrapper, а не ці існуе тунель.

Чытайце тры радкі вываду status, а не слова ў дужках. Loaded называе файл unit, які прачытаў systemd, Active нясе адзнаку часу апошняга паспяховага запуску, а адсутнасць Main PID адпавядае завершанай аднаразовай задачы. Гэтыя тры радкі таксама дапамагаюць адрозніць гэты wrapper ад службы, якая ўпала праз секунду пасля запуску.

Пералічыце unit перад тым, як зноў чытаць status

Спытайце systemd, што існуе, перш чым пытаць, што працуе. Шаблон можа быць усталяваны, пакуль ніводзін асобнік не створаны, і толькі створаны unit нясе тунель. Пачніце з загружанага набору:

systemctl list-units 'openvpn*'

Гэты спіс — тое, што systemd загрузіў у гэты момант, і гэта найбліжэйшае да інвентара тунеляў. Усталяваныя файлы unit адказваюць на іншае пытанне, і гэты спіс усё яшчэ паказвае шаблон, калі нічога не створана:

systemctl list-unit-files 'openvpn*'

Чытайце абодва спісы разам, бо шаблон у другім і асобнік у першым — розныя адказы. Шаблон, які існуе, і асобнік, які працуе, — не адзін і той жа факт, і толькі другі азначае тунель. Макеты пакетаў таксама адрозніваюцца па дыстрыбутывах і версіях OpenVPN. Стары шаблон openvpn@, асобная пара client і server і wrapper дыстрыбутыва могуць быць законнымі ў сваіх уласных пакетах.

Падладжвайцеся пад сваю машыну, а не пад знойдзены падручнік. Імя асобніка ў чужым вывадзе можа быць office, а ў вас — home або work. Перадаецца метад, а не радок.

Ідзіце ад імя асобніка да файла, які ён чытае

У upstream-шаблоне client працоўны каталог unit — /etc/openvpn/client, і яго каманда бярэ адтуль %i.conf, таму openvpn-client@office чытае /etc/openvpn/client/office.conf. Пацвердзіце гэта адлюстраванне на ўсталяваным unit, а не давярайце прыкладу, бо ваш шаблон можа быць старэйшым або перапісаным дыстрыбутывам:

systemctl cat [email protected]

Чытайце drop-in, якія з'яўляюцца ўнізе гэтага вываду, бо файл у .d/ можа змяніць ExecStart, працоўны каталог або шлях канфігурацыі. Профіль, які вы спампавалі як office.ovpn, — гэта не файл, які адкрывае асобнік. Гэтая розніца — звычайная прычына таго, што памылка называе шлях, які вы ніколі не рэдагавалі.

Адносныя шляхі ўнутры профілю — наступная пастка. Перамяшчэнне галоўнага файла з пакіданнем адносных спасылак ca, cert і key мяняе памылку адсутнага файла на іншую памылку адсутнага файла. Другая ўказвае на файл, у існаванні якога вы былі ўпэўненыя, таму каталог профілю важнейшы за імя файла.

Запусціце яго, затым прачытайце журнал гэтага асобніка

Запусціце асобнік, які вы толькі што праверылі, бо журнал агульнага unit не будзе змяшчаць памылак тунеля. Затым прачытайце журнал для гэтай загрузкі і шукайце ў такім парадку памылку канфігурацыі, памылку доступу да файла і памылку злучэння, бо кожная з іх здараецца на рознай стадыі запуску.

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

Запуск і ўключэнне — розныя рашэнні: start запускае unit зараз, enable ладзіць наступную загрузку, а enable --now робіць адно і другое за адзін крок. daemon-reload перачытвае вызначэнні unit і не перазапускае працэс і не ўжывае адрэдагаваны профіль. Пасля змены профілю перазапусціце асобнік, бо менавіта гэта перачытвае файл.

Не стаўце другі менеджар на той жа тунель

NetworkManager і менеджары сеансаў OpenVPN 3 валодаюць сваім станам злучэння, а systemd-асобнік побач з адным з іх ставіць двух уладальнікаў на адзін тунель. Сімптом — тунель, які ўзнікае і праз секунды замяняецца, або той, які адмаўляецца заставацца спыненым. Выбірайце менеджар, які ваш дыстрыбутыў дакументуе для працоўнага стала, і свядома выкарыстоўвайце systemd на серверы.

Праверце наяўнага ўладальніка перад запускам асобніка. Калі applet працоўнага стала паказвае злучэнне, запушчаны вамі асобнік канкуруе з ім, а не дапаўняе яго. Адключыце менеджар, які вы не выкарыстоўваеце, замест таго каб запускаць абодва і спадзявацца на парадак. Гэты канфлікт таксама тлумачыць журналы, дзе тунель усталёўваецца, а затым разбураецца працэсам, які вы ніколі не запускалі.

Адказвайце на зыходнае пытанне імем асобніка, файлам, які ён прачытаў, і радком журнала, які праваліўся. Заўвагі OpenVPN пра інтэграцыю з systemd апісваюць макет шаблона і адлюстраванне файла, праз якое вырашаецца імя асобніка.