systemd zaustavlja VPN servis: uskladite Type= s klijentom
VPN unit pri podizanju sistema postaje neaktivan kada Type= ne odgovara životnom veku klijenta. Uskladite tip, popravite vlasništvo i poređajte servis posle tunela.
Unitovi mogu izgledati ispravno, systemctl start može prijaviti uspeh, a deset sekundi kasnije servis stoji neaktivan. Ili se restartuje svakih pola minuta dok ga ograničenje pokretanja ne zaustavi. Nijedno ponašanje nije mrežna greška: unit opisuje životni vek procesa koji ne odgovara onome što klijent zaista radi. Klijent može forkovati i izaći, ili konfigurisati sesiju i odmah izaći.
Zašto unit postaje neaktivan nekoliko sekundi nakon uspeš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 pre 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 forka pomoćni program pre 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 forka zadržava isti oblik, ali mu treba Type=forking kako bi systemd pratio dete. 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 poseduje proces u prvom planu, kao što sshd -D ostaje napred. Uklonite daemon zastavicu za nadzirane komande i prepustite pozadinski rad nadzorniku. Omotačke skripte koje se vrate pre 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 poseduje 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 trebalo da koriste sistemski unit ili NetworkManager profil koji se sam podiže. Korisnički unit ima smisla samo kada tunel treba da završi 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 poseduje 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 -lsPoređajte 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 poređanje, a ne petlja ponovnih pokušaja.
[Unit]
After=network.target [email protected]
Requires=sys-devices-virtual-net-wg0.deviceAfter= poređa 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 izmene i restartujte zavisni servis, pa pročitajte njegov dnevnik umesto da pretpostavite da je redosled delovao. Šaljite izlaz klijenta u dnevnik s StandardOutput=journal ili opcijom za log, jer nadzirani klijent koji piše u datoteku koju niko 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 proverena samo s systemctl start nije testirala redosled podizanja koji je trebalo popraviti.