Kaj persist-tun in persist-key v OpenVPN v resnici preživita
Obe možnosti pokrivata mehki ponovni zagon znotraj živega procesa. Po zaustavitvi ne ohranita vmesnika in nista politika blokiranja prometa.
Zaustavitev storitve odstrani vmesnik tudi z nastavljenim persist-tun. To je možnost, ki deluje, kot je dokumentirano, ne okvara. Možnost opisuje eno pot ponovnega zagona znotraj delujočega procesa, in systemctl stop ni ta pot.
Preberite obe imeni skupaj in zasnova postane jasna. Eno drži deskriptor, drugo drži ključni material, in obe obstajata zaradi tega, kar se zgodi po odpovedi privilegijev.
Dva vira in ponovni zagon, ki jima pripadata
OpenVPN naznani svoj ponovni zagon v dveh običajnih situacijah. Izrecni SIGUSR1 to stori, in ping-restart, ki ga sproži mrtvi partner, stori isto. Oba pustita proces živ in znova izvedeta nastavitev povezave, in prav tam si možnosti prislužita svoje mesto.
| Event | TUN/TAP device | Key and auth files | Addresses and routes | up/down hooks |
|---|---|---|---|---|
Soft reset, from SIGUSR1 or from a ping-restart the daemon sends itself | survives only with persist-tun | survive only with persist-key | survive with the device, otherwise rebuilt | run again only when restart hooks are enabled |
Configuration reload, SIGHUP | recreated | re-read from disk | rebuilt once the device returns | run again |
| Service stop | lost | re-read at the next start | removed | run at the next start |
Samo vrstica mehkega ponovnega zagona je tisto, kar ti dve možnosti spremenita, in delo, ki ga preskočita, je drag del na zasedeni povezavi. Ponovno odpiranje naprave podre naslove in poti, pritrjene nanjo, in njihova obnova lahko spusti pakete, ki so bili na poti, ko se je ponovni zagon začel. Zaustavitev uniči iste objekte brez kakršne koli možnosti, da bi jih ohranila.
Zakaj te možnosti sploh obstajajo
Utrjen strežnik OpenVPN se običajno zažene kot root, odpre svoje ključe in svojo napravo, nato pa preide na uporabnika brez privilegijev. Po tem prehodu nekatere operacije preprosto izginejo. Branje ključne datoteke z načinom 0600, ustvarjanje omrežnega vmesnika ali spreminjanje poti so lahko zavrnjeni.
Brez možnosti persist bi partner, ki molči dovolj dolgo, da sproži ping-restart, vsilil prav te operacije. Ponovna povezava bi spodletela, čeprav se v konfiguraciji ni nič spremenilo. Proces bi bil videti, kot da umira brez razloga, dnevnik pa bi pokazal napako dovoljenj namesto omrežne napake.
Z njima mehki ponovni zagon znova uporabi tisto, kar je privilegirana faza že pridobila. Nobene magije ni in proces ničesar ne preživi. Pridobivanje virov je preprosto odloženo.
Preberite prvo napako, ne zadnje
Ko ponovni zagon spodleti, preberite prvo napako namesto zadnje. Zaščiten ključ, datoteka auth, vmesniški ioctl in zunanja kljuka so štirje različni viri. Ohranitev enega ne pove ničesar o dostopu do drugih. Kljuka, ki pokliče orodje požarnega zidu, še vedno potrebuje privilegije, ki jih to orodje zahteva.
Kljuke imajo svoje stikalo. Priročnik OpenVPN poveže možnosti persist s up-restart, ki odloči, ali se skripti up in down po ponovnem zagonu znova zaženeta. Vmesnik, ki je ostal pokonci, vam torej ne pove ničesar o tem, ali se je vaša integracija resolverja osvežila.
# which restart path just happened?
journalctl -u openvpn-client@office --since '10 min ago' | grep -E 'SIGUSR1|ping-restart|Restart pause|NOTE:'
# did the interface survive, and do its routes still exist?
ip -brief link show tun0
ip route show dev tun0Ta par ukazov loči dva načina odpovedi v nekaj sekundah. Vmesnik, ki obstaja, a mu manjkajo poti, je težava kljuke ali poti. Vmesnik, ki je izginil, pomeni, da se je proces res končal.
Ohranjen vmesnik ni kill switch
Če je zahteva, da promet nikoli ne zapusti tunela, ohranjena naprava tega ne zagotovi. Poti za drugo družino naslovov, druga privzeta pot in primer, ko proces povsem izstopi, ostanejo zunaj obsega možnosti.
Obravnavajte zahtevi ločeno. Ohranjanje predmeta tunela med ponovnimi povezavami je udobje za demona. Blokiranje izhoda, ko tunel ne deluje, je politika požarnega zidu z lastnimi pravili in lastnim testom. Če ju zmešate, dobite konfiguracijo, ki je videti obrambna in se obnaša kot ponovna povezava po najboljših močeh.
Poimenujte dogodek, preden ga diagnosticirate. Mehki ponovni zagon, neuspešen poskus povezave in zaustavitev storitve so trije dogodki s tremi vedenji, in samo prvi je tisto, kar opisujeta ti možnosti.