systemd stopt de VPN-dienst: stem Type= af op de client
Een VPN-unit bij het opstarten wordt inactief wanneer Type= niet past bij de levensduur van de client. Stem het type af, herstel het eigendom en orden de dienst na de tunnel.
Units kunnen er correct uitzien, systemctl start kan succes melden, en tien seconden later staat de dienst inactief. Of hij herstart elke halve minuut tot de startlimiet hem stopt. Geen van beide gedragingen is een netwerkstoring: de unit beschrijft een proceslevensduur die niet past bij wat de client werkelijk doet. De client kan forken en afsluiten, of de sessie configureren en meteen afsluiten.
Waarom de unit seconden na een geslaagde start inactief wordt
systemd leidt de toestand af uit het proces dat het startte, dus Type= is een bewering over dat proces, geen documentatie. Met Type=simple geldt de unit als actief zolang de opdracht loopt en wordt hij inactief wanneer die terugkeert. Een client die de verbinding aan een helper overdraagt en afsluit, ziet er daardoor uit als een crash, zelfs wanneer de tunnel staat. Het journaal toont dan een start-stop-patroon dat leest als een defecte binary.
Lees het unittype naast het gedrag van de client voordat je de netwerkconfiguratie aanraakt.
Kies het type dat bij de client past
Twee patronen dekken de meeste leveranciers-CLI's: een opdracht die een sessie configureert en afsluit, en een opdracht die voor de terugkeer een helper forkt. Elk vraagt een andere unitvorm.
[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/bin/protonvpn-cli connect -f
ExecStop=/usr/bin/protonvpn-cli disconnectoneshot met RemainAfterExit=true houdt de unit actief nadat de opdracht terugkeert, wat past bij het patroon configureren en afsluiten, en de stopopdracht geeft de dienst een nette afsluiting. Een forkende client houdt dezelfde vorm maar heeft Type=forking nodig zodat systemd het kind volgt. Stel Restart=on-failure, RestartSec=30 en een eindige StartLimitBurst in, zodat een storing bij de provider geen herstartlus wordt die de fout begraaft.
Laat een bewaakte client nooit daemoniseren
Toezichthouders buiten systemd lopen tegen dezelfde muur. Een runit-runscript dat een gedaemoniseerde client start, keert meteen terug naar de toezichthouder, die die terugkeer als een crash leest en nog een kopie start. Elke toezichthouder verwacht het voorgrondproces te bezitten, zoals sshd -D vooraan blijft. Haal de daemonvlag weg bij bewaakte opdrachten en laat de toezichthouder het achtergrondwerk doen. Wrapperscripts die terugkeren voordat de tunnel bestaat, veroorzaken dezelfde verwarring.
Een proces dat zichzelf loskoppelt, is onzichtbaar voor alles wat erop had moeten letten.
De sessie eindigt en neemt de tunnel mee
Een desktopsessie bezit de client die hij start. Beëindig de login en de sessiebus verdwijnt en neemt de tunnel mee, wat verklaart waarom de verbinding van een grafische client vaak wegvalt wanneer het laatste venster sluit. Servers zouden een systeemunit of een NetworkManager-profiel moeten gebruiken dat vanzelf opkomt. Een gebruikersunit is alleen zinvol wanneer de tunnel met de login moet eindigen, dus bind hem aan het doel van de grafische sessie en zeg dat in de beschrijving.
De dienstgebruiker is de andere helft van hetzelfde probleem. Een sleutel in bezit van root met modus 0600 is onleesbaar voor een unit die onder een ander account draait, wat sudo in je shell ook heeft bereikt.
systemctl cat openvpn-server@work
sudo chown -R openvpn:network /etc/openvpn/server
sudo find /etc/openvpn -type f -perm /077 -lsOrden afhankelijke eenheden nadat het adres bestaat
Wanneer een daemon zich bindt aan een tunneladres dat nog niet is gemaakt, eindigt hij met Cannot assign requested address. De reparatie is expliciete ordening, geen herhaal-iteratie.
[Unit]
After=network.target [email protected]
Requires=sys-devices-virtual-net-wg0.deviceAfter= ordent de taken, terwijl Requires= op de apparaatunit de afhankelijke eenheid aan het bestaan van de interface bindt, wat sterker is dan alleen op het netwerkdoel wachten. Herlaad de manager na het bewerken en herstart de afhankelijke dienst, en lees daarna het journaal in plaats van aan te nemen dat de volgorde werkte. Stuur de uitvoer van de client naar het journaal met StandardOutput=journal of een logoptie, want een bewaakte client die schrijft naar een bestand dat niemand opent, ziet er identiek uit als een die nooit startte.
Herstart daarna één keer en bevestig dat de unit actief is nadat het tunnelapparaat verschijnt. Een reparatie die alleen met systemctl start is gecontroleerd, heeft de opstartvolgorde die hij moest repareren niet getest.