systemd zaustavlja VPN servis: uskladite Type= s klijentom
VPN unit koji se pokreće pri podizanju sistema prelazi u neaktivno stanje kada Type= ne odgovara životnom vijeku klijenta. Uskladite tip, popravite vlasništvo i poredajte servis nakon tunela.
Unitovi mogu izgledati ispravno, systemctl start može prijaviti uspjeh, a deset sekundi kasnije servis stoji neaktivan. Ili se restaruje svakih pola minute dok ga ograničenje pokretanja ne zaustavi. Ni jedno ponašanje nije mrežna greška: unit opisuje životni vijek procesa koji ne odgovara onome što klijent zaista radi. Klijent može forkati i izaći, ili konfigurisati sesiju i odmah izaći.
Zašto unit postaje neaktivan nekoliko sekundi nakon uspješnog pokretanja
systemd izvodi stanje iz procesa koji je pokrenuo, pa je Type= tvrdnja o tom procesu, a ne dokumentacija. Uz Type=simple unit se računa kao aktivan dok komanda radi i postaje neaktivan kada se vrati. Zato klijent koji preda vezu pomoćnom programu i izađe izgleda kao pad, čak i kada je tunel aktivan. Dnevnik tada pokazuje obrazac pokretanja i zaustavljanja koji se čita kao neispravna binarna datoteka.
Pročitajte tip unita uz ponašanje klijenta prije nego što dirnete mrežnu konfiguraciju.
Odaberite tip koji odgovara klijentu
Dva obrasca pokrivaju većinu CLI-jeva dobavljača: komanda koja konfiguriše sesiju i izađe, i komanda koja forkuje pomoćni program prije nego što se vrati. Svaki traži drugačiji oblik unita.
[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/bin/protonvpn-cli connect -f
ExecStop=/usr/bin/protonvpn-cli disconnectoneshot uz RemainAfterExit=true zadržava unit aktivnim nakon što se komanda vrati, što odgovara obrascu konfiguriši-i-izađi, a komanda za zaustavljanje daje servisu čisto gašenje. Klijent koji forkuje zadržava isti oblik, ali mu treba Type=forking kako bi systemd pratio dijete. Postavite Restart=on-failure, RestartSec=30 i konačan StartLimitBurst, da se ispad dobavljača ne pretvori u petlju restarta koja zakopava grešku.
Nikada ne dopustite da nadzirani klijent postane daemon
Nadzornici izvan systemd-a udaraju u isti zid. runit skripta koja pokreće daemonizirani klijent vraća se nadzorniku odmah, a on to vraćanje čita kao pad i pokreće još jednu kopiju. Svaki nadzornik očekuje da posjeduje proces u prvom planu, kao što sshd -D ostaje naprijed. Uklonite daemon zastavicu za nadzirane komande i prepustite pozadinski rad nadzorniku. Omotačke skripte koje se vrate prije nego tunel postoji izazivaju istu zbrku.
Proces koji se odvoji od sebe nevidljiv je svemu što je trebalo da ga nadzire.
Sesija završava i nosi tunel sa sobom
Desktop sesija posjeduje klijent koji pokrene. Završite prijavu i sabirnica sesije nestaje, noseći tunel sa sobom, što objašnjava zašto veza grafičkog klijenta često padne kada se zatvori zadnji prozor. Serveri bi trebali koristiti sistemski unit ili NetworkManager profil koji se sam podiže. Korisnički unit ima smisla samo kada tunel treba završiti s prijavom, pa ga vežite na cilj grafičke sesije i to navedite u opisu.
Korisnik servisa je druga polovina istog problema. Ključ koji posjeduje root s načinom 0600 nečitljiv je za unit koji radi pod drugim računom, bez obzira na to što je sudo postigao u vašoj ljusci.
systemctl cat openvpn-server@work
sudo chown -R openvpn:network /etc/openvpn/server
sudo find /etc/openvpn -type f -perm /077 -lsPoredajte zavisne nakon što adresa postoji
Kada se daemon veže na adresu tunela koja još nije stvorena, izlazi s Cannot assign requested address. Popravka je izričito poredanje, a ne petlja ponovnih pokušaja.
[Unit]
After=network.target [email protected]
Requires=sys-devices-virtual-net-wg0.deviceAfter= poreda poslove, dok Requires= na unit-u uređaja veže zavisni servis za postojanje interfejsa, što je jače od čekanja samo na mrežni cilj. Ponovo učitajte menadžer nakon izmjene i restarujte zavisni servis, pa pročitajte njegov dnevnik umjesto da pretpostavite da je redoslijed djelovao. Šaljite izlaz klijenta u dnevnik s StandardOutput=journal ili opcijom za log, jer nadzirani klijent koji piše u datoteku koju nitko ne otvara izgleda isto kao onaj koji nikada nije pokrenut.
Zatim jednom restartujte i potvrdite da je unit aktivan nakon što se uređaj tunela pojavi. Popravka provjerena samo s systemctl start nije testirala redoslijed podizanja koji je trebala popraviti.