systemd pysäyttää VPN-palvelun: sovita Type= asiakkaaseen

Yksiköt voivat näyttää oikeilta, systemctl start voi ilmoittaa onnistumisesta ja kymmenen sekuntia myöhemmin palvelu istuu passiivisena. Tai se käynnistyy uudelleen puolen minuutin välein, kunnes käynnistysraja pysäyttää sen. Kumpikaan käytös ei ole verkkohäiriö: yksikkö kuvaa prosessin elinikää, joka ei vastaa sitä, mitä asiakas todella tekee. Asiakas voi haarautua ja poistua tai määrittää istunnon ja poistua heti.

Miksi yksikkö muuttuu passiiviseksi sekunteja onnistuneen käynnistyksen jälkeen

systemd päättelee tilan käynnistämästään prosessista, joten Type= on väite siitä prosessista, ei dokumentaatio. Type=simple-tyypillä yksikkö lasketaan aktiiviseksi, kun komento suoritetaan, ja muuttuu passiiviseksi, kun se palaa. Asiakas, joka luovuttaa yhteyden apuohjelmalle ja poistuu, näyttää siksi kaatumiselta, vaikka tunneli olisi pystyssä. Silloin loki näyttää käynnistys-pysäytys-kuvion, joka luetaan kuin viallinen binääri.

Lue yksikön tyyppi asiakkaan käytöksen vierestä ennen kuin kosket verkkokokoonpanoon.

Valitse tyyppi, joka vastaa asiakasta

Kaksi mallia kattaa useimmat toimittajien CLI:t: komento, joka määrittää istunnon ja poistuu, ja komento, joka haarauttaa apuohjelman ennen paluutaan. Kumpikin vaatii erilaisen yksikkömuodon.

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

oneshot yhdessä RemainAfterExit=true-asetuksen kanssa pitää yksikön aktiivisena, kun komento palaa, mikä vastaa määritä-ja-poistu-mallia, ja pysäytyskomento antaa palvelulle siistin sammutuksen. Haarautuva asiakas säilyttää saman muodon mutta tarvitsee Type=forking, jotta systemd seuraa lasta. Aseta Restart=on-failure, RestartSec=30 ja rajallinen StartLimitBurst, jotta palveluntarjoajan katkos ei muutu uudelleenkäynnistyssilmukaksi, joka hautaa virheen.

Älä koskaan anna valvotun asiakkaan daemonisoitua

systemd:n ulkopuoliset valvojat törmäävät samaan seinään. runit-ajoskripti, joka käynnistää daemonisoidun asiakkaan, palaa heti valvojalle, joka lukee paluun kaatumisena ja käynnistää toisen kopion. Jokainen valvoja odottaa omistavansa etualan prosessin, niin kuin sshd -D pysyy edessä. Poista daemon-lippu valvotuista komennoista ja jätä taustatyö valvojalle. Kääreskriptit, jotka palaavat ennen kuin tunneli on olemassa, aiheuttavat saman sekaannuksen.

Prosessi, joka irrottaa itsensä, on näkymätön kaikelle, jonka piti valvoa sitä.

Istunto päättyy ja vie tunnelin mukanaan

Työpöytäistunto omistaa käynnistämänsä asiakkaan. Lopeta kirjautuminen, niin istuntoväylä katoaa ja vie tunnelin mukanaan, mikä selittää, miksi graafisen asiakkaan yhteys usein katkeaa, kun viimeinen ikkuna sulkeutuu. Palvelimien tulisi käyttää järjestelmäyksikköä tai NetworkManager-profiilia, joka nousee itsestään. Käyttäjäyksikkö on järkevä vain silloin, kun tunnelin on tarkoitus päättyä kirjautumisen mukana, joten sido se graafisen istunnon kohteeseen ja mainitse se kuvauksessa.

Palvelun käyttäjä on saman ongelman toinen puoli. rootin omistama avain tilassa 0600 on lukukelvoton yksikölle, joka toimii toisella tilillä, riippumatta siitä, mitä sudo sai aikaan kuoressasi.

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

Järjestä riippuvaiset vasta kun osoite on olemassa

Kun daemon sitoutuu tunneliosoitteeseen, jota ei ole vielä luotu, se poistuu viestillä Cannot assign requested address. Korjaus on nimenomainen järjestys, ei uudelleenyrityssilmukka.

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

After= järjestää työt, kun taas laiteyksikön Requires= sitoo riippuvaisen rajapinnan olemassaoloon, mikä on vahvempaa kuin pelkän verkkokohteen odottaminen. Lataa hallinta uudelleen muokkauksen jälkeen ja käynnistä riippuvainen palvelu uudelleen, ja lue sitten sen loki sen sijaan, että olettaisit järjestyksen toimineen. Lähetä asiakkaan tuloste lokiin StandardOutput=journal-asetuksella tai lokivaihtoehdolla, koska valvottu asiakas, joka kirjoittaa tiedostoon, jota kukaan ei avaa, näyttää täsmälleen samalta kuin sellainen, joka ei koskaan käynnistynyt.

Käynnistä sitten kerran uudelleen ja varmista, että yksikkö on aktiivinen, kun tunnelilaite ilmestyy. Korjaus, joka on varmistettu vain systemctl start -komennolla, ei ole testannut käynnistysjärjestystä, joka sen oli tarkoitus korjata.