systemd oprește serviciul VPN: potrivește Type= cu clientul

Unitățile pot părea corecte, systemctl start poate raporta succes, iar zece secunde mai târziu serviciul stă inactiv. Sau repornește la fiecare jumătate de minut până când limita de pornire îl oprește. Niciuna dintre comportări nu este o defecțiune de rețea: unitatea descrie o durată de viață a procesului care nu se potrivește cu ce face clientul de fapt. Clientul poate face fork și poate ieși, sau poate configura sesiunea și poate ieși imediat.

De ce unitatea devine inactivă la câteva secunde după o pornire reușită

systemd deduce starea din procesul pe care l-a pornit, deci Type= este o afirmație despre acel proces, nu documentație. Cu Type=simple unitatea este considerată activă cât timp comanda rulează și devine inactivă când aceasta revine. Un client care predă conexiunea unui ajutor și iese arată astfel ca un crash, chiar și când tunelul este activ. Atunci jurnalul arată un model pornire și oprire care se citește ca un binar defect.

Citește tipul unității lângă comportamentul clientului înainte de a atinge configurația de rețea.

Alege tipul care se potrivește clientului

Două modele acoperă majoritatea CLI-urilor furnizorilor: o comandă care configurează o sesiune și iese, și o comandă care face fork unui ajutor înainte de a reveni. Fiecare cere o altă formă de unitate.

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

oneshot împreună cu RemainAfterExit=true ține unitatea activă după ce comanda revine, ceea ce se potrivește modelului configurează și ieși, iar comanda de oprire oferă serviciului o închidere curată. Un client care face fork păstrează aceeași formă, dar are nevoie de Type=forking pentru ca systemd să urmărească procesul copil. Setează Restart=on-failure, RestartSec=30 și un StartLimitBurst finit, ca o cădere a furnizorului să nu devină o buclă de reporniri care îngroapă eroarea.

Nu lăsa niciodată un client supravegheat să se demonizeze

Supraveghetorii din afara systemd lovesc același zid. Un script runit care lansează un client demonizat revine imediat la supraveghetor, care citește revenirea ca un crash și pornește încă o copie. Fiecare supraveghetor se așteaptă să dețină procesul din prim-plan, așa cum sshd -D rămâne în față. Scoate indicatorul de demon pentru comenzile supravegheate și lasă lucrul de fundal supraveghetorului. Scripturile înveliș care revin înainte ca tunelul să existe provoacă aceeași confuzie.

Un proces care se desprinde de el însuși este invizibil pentru tot ce ar fi trebuit să-l supravegheze.

Sesiunea se termină și ia tunelul cu ea

O sesiune de desktop deține clientul pe care îl lansează. Termină autentificarea și magistrala sesiunii dispare, luând tunelul cu ea, ceea ce explică de ce conexiunea unui client grafic cade des când se închide ultima fereastră. Serverele ar trebui să folosească o unitate de sistem sau un profil NetworkManager care urcă singur. O unitate de utilizator are sens doar când tunelul trebuie să se termine odată cu autentificarea, așa că leagă-o de ținta sesiunii grafice și spune asta în descriere.

Utilizatorul serviciului este cealaltă jumătate a aceleiași probleme. O cheie deținută de root cu modul 0600 este ilizibilă pentru o unitate care rulează sub alt cont, orice ar fi obținut sudo în shell-ul tău.

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

Ordonează dependenții după ce adresa există

Când un demon se leagă de o adresă de tunel care nu a fost încă creată, iese cu Cannot assign requested address. Reparația este o ordonare explicită, nu o buclă de reîncercări.

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

After= ordonează sarcinile, în timp ce Requires= pe unitatea dispozitivului leagă dependentul de existența interfeței, ceea ce este mai puternic decât să aștepți doar ținta de rețea. Reîncarcă managerul după editare și repornește serviciul dependent, apoi citește jurnalul lui în loc să presupui că ordinea a funcționat. Trimite ieșirea clientului în jurnal cu StandardOutput=journal sau cu o opțiune de log, pentru că un client supravegheat care scrie într-un fișier pe care nimeni nu îl deschide arată identic cu unul care nu a pornit niciodată.

Apoi repornește o dată și confirmă că unitatea este activă după ce dispozitivul tunelului apare. O corecție verificată doar cu systemctl start nu a testat ordinea de pornire pe care trebuia să o repare.