Kva persist-tun og persist-key faktisk overlever i OpenVPN

Stopp av tenesta fjernar grensesnittet sjølv med persist-tun sett. Det er valet som verkar som dokumentert, ikkje ein feil. Valet skildrar éin omstartveg inne i ein køyrande prosess, og systemctl stop er ikkje den vegen.

Les dei to namna saman, og designet blir klart. Det eine held på ein deskriptor, det andre held på nøkkelmateriale, og begge finst på grunn av det som skjer etter at privilegia blir sleppte.

Dei to ressursane og omstarten dei høyrer til

OpenVPN signaliserer sin eigen omstart i to vanlege situasjonar. Ein eksplisitt SIGUSR1 gjer det, og ein ping-restart utløyst av ein død peer gjer det same. Begge held prosessen i live og køyrer tilkoplingsoppsettet på nytt, og det er der vala fortener plassen sin.

Berre rada for mjuk omstart er det desse to vala endrar, og arbeidet dei hoppar over er den dyre delen på ei travel lenkje. Å opne ein eining på nytt riv ned adressene og rutene som heng på henne, og å byggje dei opp att kan miste pakkar som var undervegs då omstarten byrja. Ein stopp øydelegg dei same objekta utan noko val for å ta vare på dei.

Kvifor vala i det heile finst

Ein herda OpenVPN-server startar vanlegvis som root, opnar nøklane og eininga si og går deretter over til ein brukar utan privilegium. Etter den overgangen er nokre operasjonar rett og slett borte. Lesing av ei nøkkelfil med modus 0600, oppretting av eit nettverksgrensesnitt eller endring av ruter kan alt bli avviste.

Utan persist-vala ville ein peer som teier lenge nok til å utløyse ping-restart tvinge nøyaktig desse operasjonane. Attilkoplinga ville mislykkast sjølv om ingenting i konfigurasjonen hadde endra seg. Prosessen ville sjå ut som han døydde utan grunn, og loggen ville vise ein løyvefeil i staden for ein nettverksfeil.

Med dei brukar den mjuke omstarten på nytt det den privilegerte fasen allereie har fått. Det er inga magi i spel, og prosessen overlever ingenting. Anskaffing av ressursar blir berre utsett.

Les den første feilen, ikkje den siste

Når ein omstart mislykkast, les den første feilen i staden for den siste. Ein verna nøkkel, ei auth-fil, ein grensesnitt-ioctl og ein ekstern krok er fire ulike ressursar. Å halde på éin seier ingenting om tilgangen til dei andre. Ein krok som kallar eit brannmurverktøy treng framleis privilegia som verktøyet krev.

Krokar har sin eigen brytar. OpenVPN-handboka parar persist-vala med up-restart, som avgjer om up- og down-skripta køyrer igjen etter ein omstart. Eit grensesnitt som vart ståande oppe fortel deg difor ingenting om kvidan resolver-integreringa di vart oppdatert.

# 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

Det paret med kommandoar skil dei to feilmodusane på sekund. Eit grensesnitt som er til stades med manglande ruter er eit krok- eller ruteproblem. Eit grensesnitt som forsvann betyr at prosessen faktisk tok slutt.

Eit bevart grensesnitt er ikkje ein kill switch

Viss kravet er at trafikk aldri skal forlate tunnelen, leverer ikkje ei bevart eining det. Ruter for den andre adressefamilien, ei andre standardrute og tilfellet der prosessen avsluttar heilt, ligg alle utanfor rekkevidda til valet.

Handter dei to krava kvar for seg. Å halde på tunnelobjektet gjennom attilkoplingar er ei lettvintheit for daemonen. Å blokkere utgang når tunnelen er nede er ein brannmurpolicy med eigne reglar og eigen test. Å blande dei gir ein konfigurasjon som ser defensiv ut og oppfører seg som attilkopling etter beste evne.

Namngi hendinga før du diagnostiserer henne. Ein mjuk omstart, eit mislukka tilkoplingforsøk og ein tenestestopp er tre hendingar med tre åtferder, og berre den første er det desse vala skildrar.