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

Повезани чланци