systemd спыняе службу VPN: прывядзіце Type= у адпаведнасць з кліентам

VPN-юніт, які запускаецца пры загрузцы, пераходзіць у неактыўны стан, калі Type= не адпавядае часу жыцця кліента. Падбярыце тып, выпраўце правы ўласнасці і ўпарадкуйце службу пасля тунеля.

Юніты могуць выглядаць правільна, systemctl start можа паведамляць пра поспех, а праз дзесяць секунд служба застаецца неактыўнай. Або яна перазапускаецца кожныя паўхвіліны, пакуль яе не спыніць ліміт запускаў. Ні адзін з гэтых паводзінаў не з’яўляецца збоем сеткі: юніт апісвае час жыцця працэсу, які не адпавядае таму, што кліент робіць насамрэч. Кліент можа адгалінавацца і выйсці або наладзіць сеанс і адразу выйсці.

Чаму юніт становіцца неактыўным праз некалькі секунд пасля паспяховага запуску

systemd выводзіць стан з працэсу, які ён запусціў, таму Type= — гэта сцвярджэнне пра гэты працэс, а не дакументацыя. З Type=simple юніт лічыцца актыўным, пакуль выконваецца каманда, і становіцца неактыўным, калі яна вяртаецца. Таму кліент, які перадае злучэнне дапаможнай праграме і выходзіць, выглядае як аварыя, нават калі тунель працуе. Пасля гэтага журнал паказвае схему запуску і прыпынку, якая чытаецца як збойны бінарнік.

Чытайце тып юніта побач з паводзінамі кліента, перш чым чапаць канфігурацыю сеткі.

Выберыце тып, які адпавядае кліенту

Дзве схемы ахопліваюць большасць CLI ад пастаўшчыкоў: каманда, якая наладжвае сеанс і выходзіць, і каманда, якая адгаліноўвае дапаможную праграму перад вяртаннем. Кожная патрабуе сваёй формы юніта.

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/bin/protonvpn-cli connect -f
ExecStop=/usr/bin/protonvpn-cli disconnect

oneshot разам з RemainAfterExit=true пакідае юніт актыўным пасля вяртання каманды, што адпавядае схеме «наладзь і выйдзі», а каманда спынення дае службе чыстае завяршэнне. Кліент, які адгаліноўваецца, захоўвае тую ж форму, але патрабуе Type=forking, каб systemd сачыў за даччыным працэсам. Задайце Restart=on-failure, RestartSec=30 і канечны StartLimitBurst, каб збой пастаўшчыка не ператварыўся ў цыкл перазапускаў, які хавае памылку.

Не дазваляйце кіраванаму кліенту дэманізавацца

Кіраўнікі па-за systemd натыкаюцца на тую ж сцяну. Скрипт runit, які запускае дэманізаваны кліент, адразу вяртаецца да кіраўніка, а той чытае вяртанне як аварыю і запускае чарговую копію. Кожны кіраўнік чакае, што валодае працэсам на пярэднім плане, гэтак жа як sshd -D застаецца наперадзе. Прыбярыце сцяг дэмана для кіраваных каманд і дайце кіраўніку рабіць фонавую працу. Абгорткі, якія вяртаюцца раней, чым існуе тунель, выклікаюць тую ж блытаніну.

Працэс, які аддзяляецца ад сябе, нябачны для ўсяго, што павінна было за ім сачыць.

Сеанс сканчаецца і забірае тунель з сабой

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

Карыстальнік службы — гэта другая палова той жа праблемы. Ключ, які належыць root з рэжымам 0600, нечытэльны для юніта, што працуе пад іншым уліковым запісам, незалежна ад таго, чаго дасягнуў sudo у вашай абалонцы.

systemctl cat openvpn-server@work
sudo chown -R openvpn:network /etc/openvpn/server
sudo find /etc/openvpn -type f -perm /077 -ls

Упарадкуйце залежныя службы пасля з’яўлення адраса

Калі дэман прывязваецца да адраса тунеля, які яшчэ не створаны, ён выходзіць з паведамленнем Cannot assign requested address. Выпраўленне — гэта яўнае ўпарадкаванне, а не цыкл паўтораў.

[Unit]
After=network.target [email protected]
Requires=sys-devices-virtual-net-wg0.device

After= упарадкоўвае заданні, а Requires= на юніце прылады прывязвае залежную службу да існавання інтэрфейсу, што мацней за чаканне адной толькі сеткавай мэты. Перазагрузіце мэнэджар пасля рэдагавання і перазапусціце залежную службу, затым прачытайце яе журнал, а не лічыце, што парадак ужо дзейнічае. Накіроўвайце вывад кліента ў журнал праз StandardOutput=journal або опцыю лагавання, бо кіраваны кліент, які піша ў файл, якога ніхто не адкрывае, выглядае гэтак жа, як той, што не запускаўся.

Затым адзін раз перазагрузіцеся і пераканайцеся, што юніт актыўны пасля з’яўлення прылады тунеля. Выпраўленне, праверанае толькі праз systemctl start, не праверыла парадак загрузкі, які мусіла выправіць.

Падобныя артыкулы