systemd stoppar VPN-tjänsten: anpassa Type= efter klienten

Enheter kan se korrekta ut, systemctl start kan rapportera framgång, och tio sekunder senare står tjänsten inaktiv. Eller så startar den om varje halvminut tills startgränsen stoppar den. Ingen av beteendena är ett nätverksfel: enheten beskriver en processlivslängd som inte matchar vad klienten faktiskt gör. Klienten kan forka och avsluta, eller konfigurera sessionen och avsluta direkt.

Varför enheten blir inaktiv sekunder efter en lyckad start

systemd härleder tillståndet från processen den startade, så Type= är ett påstående om den processen, inte dokumentation. Med Type=simple räknas enheten som aktiv medan kommandot kör och blir inaktiv när det återvänder. En klient som lämnar anslutningen till en hjälpare och avslutar ser därför ut som en krasch, även när tunneln är uppe. Journalen visar då ett start-stopp-mönster som läses som en felande binär.

Läs enhetstypen bredvid klientens beteende innan du rör nätverkskonfigurationen.

Välj den typ som matchar klienten

Två mönster täcker de flesta leverantörs-CLI:er: ett kommando som konfigurerar en session och avslutar, och ett kommando som forkar en hjälpare innan det återvänder. Var och en kräver en annan enhetsform.

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

oneshot med RemainAfterExit=true håller enheten aktiv efter att kommandot återvänt, vilket matchar mönstret konfigurera och avsluta, och stoppkommandot ger tjänsten en ren avstängning. En forkande klient behåller samma form men behöver Type=forking så att systemd följer barnet. Sätt Restart=on-failure, RestartSec=30 och ett ändligt StartLimitBurst, så att ett avbrott hos leverantören inte blir en omstartsloop som begraver felet.

Låt aldrig en övervakad klient dämonisera sig

Övervakare utanför systemd slår i samma vägg. Ett runit-körskript som startar en dämoniserad klient återvänder direkt till övervakaren, som läser returen som en krasch och startar ännu en kopia. Varje övervakare förväntar sig att äga förgrundsprocessen, så som sshd -D stannar framme. Ta bort dämonflaggan för övervakade kommandon och låt övervakaren sköta bakgrunden. Omslagsskript som återvänder innan tunneln finns orsakar samma förvirring.

En process som kopplar loss sig själv är osynlig för allt som skulle hålla koll på den.

Sessionen avslutas och tar tunneln med sig

En skrivbordssession äger klienten den startar. Avsluta inloggningen och sessionsbussen försvinner och tar tunneln med sig, vilket förklarar varför en grafisk klients anslutning ofta faller när det sista fönstret stängs. Servrar bör använda en systemenhet eller en NetworkManager-profil som kommer upp av sig själv. En användarenhet är bara meningsfull när tunneln ska sluta med inloggningen, så bind den till den grafiska sessionens mål och säg det i beskrivningen.

Tjänsteanvändaren är den andra halvan av samma problem. En nyckel som ägs av root med läget 0600 är oläsbar för en enhet som körs som ett annat konto, vad sudo än åstadkom i ditt skal.

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

Ordna beroende efter att adressen finns

När en dämon binder till en tunneladress som ännu inte skapats avslutar den med Cannot assign requested address. Rättelsen är explicit ordning, inte en försöksloop.

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

After= ordnar jobben, medan Requires= på enhetsenheten binder den beroende till gränssnittets existens, vilket är starkare än att bara vänta på nätverksmålet. Läs in hanteraren igen efter redigering och starta om den beroende tjänsten, och läs sedan dess journal i stället för att anta att ordningen tog effekt. Skicka klientens utdata till journalen med StandardOutput=journal eller ett loggalternativ, eftersom en övervakad klient som skriver till en fil ingen öppnar ser identisk ut med en som aldrig startade.

Starta sedan om en gång och bekräfta att enheten är aktiv när tunnelenheten dyker upp. En rättelse som bara verifierats med systemctl start har inte testat den startordning den skulle rätta.