systemd ја запира VPN услугата: усогласете Type= со клиентот

VPN единица при подигање станува неактивна кога Type= не одговара на животниот век на клиентот. Усогласете го типот, поправете го сопствеништвото и подредете ја услугата по тунелот.

Единиците можат да изгледаат исправни, systemctl start може да пријави успех, а десет секунди подоцна услугата стои неактивна. Или пак се рестартира на секоја пола минута додека границата за стартување не ја запре. Ниту едното однесување не е мрежен дефект: единицата опишува животен век на процес што не одговара на она што клиентот навистина го прави. Клиентот може да fork-ира и да излезе, или да ја конфигурира сесијата и веднаш да излезе.

Зошто единицата станува неактивна секунди по успешно стартување

systemd ја изведува состојбата од процесот што самиот го стартувал, па Type= е тврдење за тој процес, а не документација. Со Type=simple единицата се смета за активна додека командата работи и станува неактивна кога таа ќе се врати. Затоа клиентот што ја предава врската на помошна програма и излегува изгледа како пад, дури и кога тунелот е активен. Тогаш журналот покажува шема на стартување и запирање што се чита како расипана бинарна датотека.

Прочитајте го типот на единицата до однесувањето на клиентот пред да ја чепнете мрежната конфигурација.

Изберете го типот што одговара на клиентот

Две шеми покриваат повеќето CLI-а од добавувачи: команда што конфигурира сесија и излегува, и команда што fork-ира помошна програма пред да се врати. Секоја бара различен облик на единица.

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

oneshot со RemainAfterExit=true ја држи единицата активна откако командата ќе се врати, што одговара на шемата конфигурирај-и-излези, а командата за запирање ѝ дава на услугата чисто затворање. Клиентот што fork-ира го задржува истиот облик, но му треба 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 не го тестирала редоследот при подигање што требало да го поправи.

Поврзани статии