A systemd leállítja a VPN-szolgáltatást: igazítsa a Type= értéket az ügyfélhez
Egy indításkor futó VPN-egység inaktívvá válik, ha a Type= nem illik az ügyfél élettartamához. Igazítsa a típust, javítsa a tulajdonjogot, és sorolja a szolgáltatást az alagút után.
Az egységek helyesnek tűnhetnek, a systemctl start sikert jelenthet, és tíz másodperccel később a szolgáltatás inaktívan áll. Vagy félpercenként újraindul, amíg az indítási korlát meg nem állítja. Egyik viselkedés sem hálózati hiba: az egység olyan folyamatélettartamot ír le, amely nem illik ahhoz, amit az ügyfél valóban tesz. Az ügyfél fork-olhat és kiléphet, vagy beállíthatja a munkamenetet és azonnal kiléphet.
Miért válik inaktívvá az egység másodpercekkel egy sikeres indítás után
A systemd az általa indított folyamatból következteti az állapotot, tehát a Type= állítás erről a folyamatról, nem dokumentáció. A Type=simple esetén az egység addig számít aktívnak, amíg a parancs fut, és inaktívvá válik, amikor visszatér. Az az ügyfél, amely átadja a kapcsolatot egy segédprogramnak és kilép, ezért összeomlásnak látszik, akkor is, ha az alagút él. A napló ekkor olyan indítás-leállítás mintát mutat, amely hibás binárisként olvasható.
Olvassa el az egység típusát az ügyfél viselkedése mellett, mielőtt hozzányúl a hálózati beállításokhoz.
Válassza azt a típust, amely illik az ügyfélhez
Két minta lefedi a legtöbb gyártói CLI-t: egy parancs, amely beállít egy munkamenetet és kilép, és egy parancs, amely visszatérés előtt fork-ol egy segédprogramot. Mindegyik más egységformát igényel.
[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/bin/protonvpn-cli connect -f
ExecStop=/usr/bin/protonvpn-cli disconnectA oneshot a RemainAfterExit=true beállítással együtt aktívan tartja az egységet a parancs visszatérése után, ami illik a beállít-és-kilép mintához, a leállító parancs pedig tiszta leállítást ad a szolgáltatásnak. A fork-oló ügyfél megtartja ugyanazt a formát, de Type=forking kell neki, hogy a systemd kövesse a gyermeket. Állítsa be a Restart=on-failure, a RestartSec=30 és egy véges StartLimitBurst értéket, hogy a szolgáltató kiesése ne váljon a hibát eltemető újraindítási hurokká.
Soha ne engedje, hogy egy felügyelt ügyfél démonizálódjon
A systemd-n kívüli felügyelők ugyanabba a falba ütköznek. Egy runit futtatószkript, amely démonizált ügyfelet indít, azonnal visszatér a felügyelőhöz, az pedig a visszatérést összeomlásként olvassa, és új példányt indít. Minden felügyelő arra számít, hogy az előtér-folyamat az övé, ahogy a sshd -D is elöl marad. Vegye le a démon kapcsolót a felügyelt parancsokról, és hagyja a felügyelőre a háttérmunkát. A burkolószkriptek, amelyek az alagút léte előtt visszatérnek, ugyanezt a zavart okozzák.
A folyamat, amely leválik önmagáról, láthatatlan mindannak, aminek figyelnie kellett volna.
A munkamenet véget ér, és magával viszi az alagutat
Az asztali munkamenet birtokolja az általa indított ügyfelet. Fejezze be a bejelentkezést, és a munkamenet-busz eltűnik, magával viszi az alagutat, ami megmagyarázza, miért szakad meg gyakran egy grafikus ügyfél kapcsolata, amikor az utolsó ablak bezárul. A szervereknek rendszeregységet vagy magától feljövő NetworkManager-profilt kellene használniuk. A felhasználói egység csak akkor indokolt, ha az alagútnak a bejelentkezéssel együtt kell véget érnie, ezért kösse a grafikus munkamenet céljához, és ezt írja le a leírásában.
A szolgáltatás felhasználója ugyanannak a problémának a másik fele. A root tulajdonában lévő, 0600 módú kulcs olvashatatlan egy másik fiók alatt futó egység számára, bármit is ért el a sudo a héjában.
systemctl cat openvpn-server@work
sudo chown -R openvpn:network /etc/openvpn/server
sudo find /etc/openvpn -type f -perm /077 -lsA függőket a cím létezése után sorolja
Amikor egy démon olyan alagútcímhez kötődik, amely még nem jött létre, Cannot assign requested address üzenettel lép ki. A javítás a kifejezett sorrendezés, nem az újrapróbálkozó hurok.
[Unit]
After=network.target [email protected]
Requires=sys-devices-virtual-net-wg0.deviceA After= sorrendezi a feladatokat, míg az eszközegységen a Requires= a függőt a csatoló létezéséhez köti, ami erősebb, mint csupán a hálózati célra várni. Szerkesztés után töltse újra a kezelőt, és indítsa újra a függő szolgáltatást, majd olvassa a naplóját, ahelyett hogy feltételezné, hogy a sorrend érvényesült. Küldje az ügyfél kimenetét a naplóba a StandardOutput=journal beállítással vagy egy naplózási opcióval, mert egy felügyelt ügyfél, amely olyan fájlba ír, amelyet senki nem nyit meg, pontosan úgy néz ki, mint amelyik soha nem indult el.
Utána indítsa újra egyszer, és erősítse meg, hogy az egység aktív, miután az alagúteszköz megjelenik. Az a javítás, amelyet csak systemctl start-tal ellenőriztek, nem tesztelte azt az indítási sorrendet, amelyet javítania kellett.