Wat persist-tun en persist-key in OpenVPN werklik oorleef

Om die diens te stop verwyder die koppelvlak selfs met persist-tun gestel. Dit is die opsie wat werk soos gedokumenteer, nie 'n fout nie. Die opsie beskryf een herbeginpad binne 'n lopende proses, en systemctl stop is nie daardie pad nie.

Lees die twee name saam en die ontwerp word duidelik. Een hou 'n deskriptor, die ander hou sleutelmateriaal, en albei bestaan weens wat ná die verlies van voorregte gebeur.

Die twee hulpbronne en die herstel waaraan hulle behoort

OpenVPN sein sy eie herbegin in twee gewone situasies. 'n Eksplisiete SIGUSR1 doen dit, en 'n ping-restart wat deur 'n dooie eweknie veroorsaak word, doen dieselfde. Albei laat die proses lewendig en voer die verbindingsopstelling weer uit, en dit is waar die opsies hul plek verdien.

Net die sagte-herstel-ry is wat hierdie twee opsies verander, en die werk wat hulle oorslaan is die duur deel op 'n besige skakel. Om 'n toestel weer oop te maak, breek die adresse en roetes wat daaraan geheg is af, en om hulle te herbou kan pakkette laat val wat onderweg was toe die herstel begin het. 'n Stop vernietig dieselfde objekte sonder enige opsie om hulle te bewaar.

Waarom die opsies hoegenaamd bestaan

'n Geharde OpenVPN-bediener begin gewoonlik as root, maak sy sleutels en sy toestel oop en sak dan na 'n onbevoorregte gebruiker. Ná daardie oorgang is sommige bewerkings eenvoudig weg. Om 'n sleutellêer met modus 0600 te lees, 'n netwerkkoppelvlak te skep of roetes te verander, kan alles geweier word.

Sonder die persist-opsies sou 'n eweknie wat lank genoeg stil bly om ping-restart te veroorsaak, presies daardie bewerkings afdwing. Die herverbinding sou misluk selfs al het niks aan die konfigurasie verander nie. Die proses sou lyk of dit sonder rede sterf, en die log sou 'n toestemmingsfout wys eerder as 'n netwerktfout.

Daarmee hergebruik die sagte herstel wat die bevoorregte fase reeds verkry het. Geen towerkuns is betrokke nie en die proses oorleef niks. Die verkryging van hulpbronne word bloot uitgestel.

Lees die eerste fout, nie die laaste nie

Wanneer 'n herstel misluk, lees die eerste fout eerder as die laaste een. 'n Beskermde sleutel, 'n auth-lêer, 'n koppelvlak-ioctl en 'n eksterne haak is vier verskillende hulpbronne. Om een te behou sê niks oor toegang tot die ander nie. 'n Haak wat 'n firewall-instrument aanroep, het steeds die voorregte nodig wat daardie instrument vereis.

Hake het hul eie skakelaar. Die OpenVPN-handleiding pas die persist-opsies by up-restart, wat besluit of die up- en down-skripte weer ná 'n herbegin loop. 'n Koppelvlak wat opgebly het, sê dus niks daaroor of jou resolver-integrasie verfris het nie.

# 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 tun0

Daardie paar opdragte skei die twee mislukkingsmodusse in sekondes. 'n Koppelvlak wat teenwoordig is met ontbrekende roetes is 'n haak- of roeteprobleem. 'n Koppelvlak wat verdwyn het, beteken die proses het werklik geëindig.

'n Behoute koppelvlak is nie 'n noodskakelaar nie

As die vereiste is dat verkeer nooit buite die tonnel mag verlaat nie, lewer 'n volgehoue toestel dit nie. Roetes vir die ander adresfamilie, 'n tweede verstekroete en die geval waar die proses heeltemal eindig, bly alles buite die omvang van die opsie.

Behandel die twee vereistes afsonderlik. Om die tonnelobjek oor herverbindings te behou, is 'n gerief vir die daemon. Om uitgang te blokkeer wanneer die tonnel af is, is 'n firewallbeleid met sy eie reëls en sy eie toets. Om hulle te verwar, lewer 'n konfigurasie wat verdedigend lyk en soos beste-poging-herverbinding optree.

Noem die gebeurtenis voordat jy dit diagnoseer. 'n Sagte herstel, 'n mislukte verbindingspoging en 'n diensstop is drie gebeurtenisse met drie gedrag, en net die eerste is wat hierdie opsies beskryf.