Palvelun uudelleenkäynnistys OpenVPN up:ssa: koukut voittavat tun0.device-yksikön
Laiteyksikkö seuraa rajapintaa, ei yhteyttä. Valitse up tai route-up palvelun tarvitsemalle ehdolle ja lähetä sitten uudelleenkäynnistys, joka ei estä.
Riippuvan palvelun kytkeminen tun0.device-yksikköön näyttää tunnelin tilaamiselta, eikä se ole sitä. Laiteyksikkö kuvastaa rajapinnan olemassaoloa, mikä voi pysyä totena epäonnistuneen yhteyden ja sitä seuraavan uudelleenyhdistämisen läpi. Silloin palvelu toimii väärällä hetkellä tai ei koskaan, riippuen siitä, katosiko rajapinta siltä väliltä. Koukku, joka kuvaa tapahtuman, josta todella välität, on se, jonka OpenVPN kutsuu, ei se, jonka systemd päättelee.
Päätä, mitä ehtoa palvelu tarvitsee, ennen kuin valitset laukaisimen, koska kolme ehdokasta eivät ole vaihdettavissa.
Mitä laiteyksikkö oikeastaan seuraa
systemd luo laiteyksikön ytimen näkemyksestä verkkorajapintaan, joten tun0.device tulee aktiiviseksi, kun rajapinta ilmestyy, ja ei-aktiiviseksi, kun se poistetaan. persist-tun-asetuksella pehmeä uudelleenkäynnistys pitää rajapinnan paikallaan, joten yksikkö ei koskaan värähdä eikä mikään siihen sidottu laukea. Ilman pysyvyyttäkin yksikkö ei kerro mitään reiteistä, DNS:stä tai siitä, vastaako kaukopää.
Se tekee siitä huonon sijaisen sille, että 'VPN on valmis'. Vain paikallisen osoitteen tarvitseva kuuntelija voi tyytyä rajapinnan olemassaoloon, kun taas kaukoverkossa sovellusta kutsuva palvelu tarvitsee reitit ja tavoitettavuuden, joita laiteyksikkö ei voi ilmaista.
up, route-up ja up-restart tarkoittavat eri asioita
up suoritetaan sen jälkeen, kun TUN/TAP-laite on avattu ja rajapinta määritetty, mikä on oikea hetki kuuntelijalle, joka sitoo määritetyn osoitteen. route-up suoritetaan sen jälkeen, kun reitit on asennettu, minkä tahansa määritetyn reitiviiveen alaisena, ja sopii työhön, joka tarvitsee reittivaiheen valmiiksi. Kumpikaan ei todista, että etäsovellus vastaa. Niiden välillä valitseminen on kysymys siitä, mitä palvelu tarvitsee, ei siitä, mikä koukku kuulostaa valmiimmalta.
persist-tun-asetuksella uudelleenkäynnistykset käyttävät laitetta uudelleen, joten up ei suoriteta uudelleen, ellei up-restart ole asetettu. Tämä valinta mahdollistaa up-skriptin dokumentoidulle uudelleenkäynnistyksen elinkaarelle, ja sen ympäristö on supistettu ensimmäiseen käynnistykseen verrattuna. Skripti, joka olettaa täyden ympäristön, toimii ensimmäisellä yhteydellä ja epäonnistuu seuraavalla.
Lähetä toiminto odottamatta sitä
Koukku, joka kutsuu systemctl restart synkronisesti, voi lukkiutua yksikköä vastaan, jonka järjestys odottaa tunnelia. systemctl --no-block try-restart vpn-dependent.service asettaa työn jonoon ja palaa, mikä estää koukkua estämästä yhteyttä, johon se reagoi. try-restart vaikuttaa vain käynnissä olevaan yksikköön, kun taas restart käynnistää myös ei-aktiivisen; valitse tarkoituksella, ei tottumuksesta.
Jonoon asettaminen ei ole vahvistamista. Koukku palauttaa onnistumisen heti, kun työ on hyväksytty, joten tarkistus on tehtävä kohdeyksikön lokissa tai sen todellisessa kuuntelijatilassa.
Uudelleenkäynnistyskäytäntö asuu yksikössä, ei koukussa
oneshot-yksikkö RemainAfterExit=yes-asetuksella pysyy aktiivisena, kun sen komento päättyy, ja toinen käynnistyspyyntö ei tee mitään, koska systemd pitää sitä jo käynnistettynä. Se on ominaisuus, jonka ympärille suunnitellaan, ei vika, joka kierretään toistuvilla käynnistyskutsuilla. Jos toiminnon on suorituttava joka yhteydellä, yksikkö tarvitsee muodon, joka sallii sen.
After= järjestää yksiköitä ja BindsTo= sitoo elinikä, mutta kumpikaan ei tarkoita 'käynnistä tämä uudelleen aina, kun VPN yhdistyy uudelleen'. Tunneliin sidottu yksikkö pysähtyy, kun tunneli pysähtyy; se ei käynnistä itseään uudelleen, kun tunneli palaa, ellei jokin käynnistä sitä uudelleen.
Testaa kolme uudelleenyhdistämistä, älä yhtä
Kylmäkäynnistys, asiakkaan täysi uudelleenkäynnistys ja pehmeä uudelleenyhdistäminen harjoittavat kukin eri polkua. Pehmeä uudelleenyhdistäminen on se, joka paljastaa puuttuvan up-restart-asetuksen, supistetun ympäristön tai laiteyksikön, joka ei koskaan tullut ei-aktiiviseksi. Aja kaikki kolme ja vahvista molemmat suunnat: palvelu toimii, kun tunneli nousee, eikä se käynnisty uudelleen liittymän muutoksista, kuten Wi-Fi-verkkovierailusta.
Pidä riippumaton palautumispolku, kun riippuva palvelu kantaa oman hallintayhteytesi. Koukku, joka käynnistää uudelleen sen, mitä kautta olet yhteydessä, on muutos, joka voi lukita sinut ulos.