systemd zatrzymuje usługę VPN: dopasuj Type= do klienta

Jednostka VPN uruchamiana przy starcie staje się nieaktywna, gdy Type= nie pasuje do czasu życia klienta. Dopasuj typ, popraw własność i ustaw usługę po tunelu.

Jednostki mogą wyglądać poprawnie, systemctl start może zgłosić sukces, a dziesięć sekund później usługa stoi nieaktywna. Albo restartuje się co pół minuty, aż zatrzyma ją limit startów. Żadne z tych zachowań nie jest awarią sieci: jednostka opisuje czas życia procesu, który nie pasuje do tego, co klient rzeczywiście robi. Klient może forknąć i wyjść albo skonfigurować sesję i wyjść natychmiast.

Dlaczego jednostka staje się nieaktywna kilka sekund po udanym starcie

systemd wnioskuje stan z procesu, który uruchomił, więc Type= jest twierdzeniem o tym procesie, a nie dokumentacją. Z Type=simple jednostka liczy się jako aktywna, dopóki polecenie działa, i staje się nieaktywna, gdy ono wraca. Klient, który przekazuje połączenie pomocnikowi i kończy pracę, wygląda więc jak awaria, nawet gdy tunel działa. Wtedy dziennik pokazuje wzorzec start-stop, który czyta się jak uszkodzony plik binarny.

Przeczytaj typ jednostki obok zachowania klienta, zanim tkniesz konfigurację sieci.

Wybierz typ, który pasuje do klienta

Dwa wzorce obejmują większość CLI dostawców: polecenie, które konfiguruje sesję i kończy pracę, oraz polecenie, które przed powrotem forka pomocnika. Każdy wymaga innego kształtu jednostki.

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

oneshot z RemainAfterExit=true utrzymuje jednostkę aktywną po powrocie polecenia, co pasuje do wzorca skonfiguruj i wyjdź, a polecenie zatrzymania daje usłudze czyste zamknięcie. Forkujący klient zachowuje ten sam kształt, ale potrzebuje Type=forking, aby systemd śledził potomka. Ustaw Restart=on-failure, RestartSec=30 i skończony StartLimitBurst, żeby awaria dostawcy nie zamieniła się w pętlę restartów, która zakopuje błąd.

Nigdy nie pozwól nadzorowanemu klientowi daemonizować się

Nadzorcy poza systemd trafiają na tę samą ścianę. Skrypt runit, który uruchamia zdaemonizowanego klienta, wraca do nadzorcy natychmiast, a ten czyta powrót jako awarię i uruchamia kolejną kopię. Każdy nadzorca oczekuje, że posiada proces pierwszoplanowy, tak jak sshd -D zostaje z przodu. Usuń flagę demona dla nadzorowanych poleceń i pozwól nadzorcy zająć się tłem. Skrypty opakowujące, które wracają, zanim tunel istnieje, powodują to samo zamieszanie.

Proces, który odłącza się od siebie, jest niewidoczny dla wszystkiego, co miało go pilnować.

Sesja się kończy i zabiera tunel ze sobą

Sesja pulpitu posiada klienta, którego uruchamia. Zakończ logowanie, a magistrala sesji znika i zabiera tunel, co wyjaśnia, dlaczego połączenie klienta graficznego często pada, gdy zamyka się ostatnie okno. Serwery powinny używać jednostki systemowej lub profilu NetworkManager, który podnosi się sam. Jednostka użytkownika ma sens tylko wtedy, gdy tunel ma się kończyć wraz z logowaniem, więc przypnij ją do celu sesji graficznej i napisz to w opisie.

Użytkownik usługi to druga połowa tego samego problemu. Klucz należący do roota z trybem 0600 jest nieczytelny dla jednostki działającej na innym koncie, niezależnie od tego, co sudo osiągnął w twojej powłoce.

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

Ustaw zależne dopiero gdy adres istnieje

Gdy demon wiąże się z adresem tunelu, który jeszcze nie powstał, kończy się komunikatem Cannot assign requested address. Naprawą jest jawna kolejność, a nie pętla ponowień.

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

After= porządkuje zadania, a Requires= w jednostce urządzenia wiąże zależnego z istnieniem interfejsu, co jest silniejsze niż czekanie tylko na cel sieciowy. Przeładuj menedżer po edycji i zrestartuj zależną usługę, a potem przeczytaj jej dziennik, zamiast zakładać, że kolejność zadziałała. Wysyłaj wyjście klienta do dziennika przez StandardOutput=journal lub opcję logowania, bo nadzorowany klient piszący do pliku, którego nikt nie otwiera, wygląda identycznie jak ten, który nigdy nie wystartował.

Potem zrestartuj raz i potwierdź, że jednostka jest aktywna po pojawieniu się urządzenia tunelu. Poprawka sprawdzona tylko przez systemctl start nie przetestowała kolejności startu, którą miała naprawić.

Powiązane artykuły