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

Stopp av tjenesten fjerner grensesnittet selv med persist-tun satt. Det er valget som virker som dokumentert, ikke en feil. Valget beskriver én omstartvei inne i en kjørende prosess, og systemctl stop er ikke den veien.

Les de to navnene sammen, og designet blir klart. Det ene beholder en deskriptor, det andre beholder nøkkelmateriale, og begge finnes på grunn av det som skjer etter at privilegiene slippes.

De to ressursene og omstarten de hører til

OpenVPN signaliserer sin egen omstart i to vanlige situasjoner. En eksplisitt SIGUSR1 gjør det, og en ping-restart utløst av en død peer gjør det samme. Begge holder prosessen i live og kjører tilkoblingsoppsettet på nytt, og det er der valgene fortjener plassen sin.

Bare raden for myk omstart er det disse to valgene endrer, og arbeidet de hopper over er den dyre delen på en travel lenke. Å åpne en enhet på nytt river ned adressene og rutene som henger på den, og å bygge dem opp igjen kan miste pakker som var underveis da omstarten begynte. En stopp ødelegger de samme objektene uten noe valg for å bevare dem.

Hvorfor valgene i det hele tatt finnes

En herdet OpenVPN-server starter vanligvis som root, åpner nøklene og enheten sin og går deretter over til en bruker uten privilegier. Etter den overgangen er noen operasjoner rett og slett borte. Lesing av en nøkkelfil med modus 0600, oppretting av et nettverksgrensesnitt eller endring av ruter kan alt bli avvist.

Uten persist-valgene ville en peer som tier lenge nok til å utløse ping-restart tvinge nøyaktig disse operasjonene. Gjenoppkoblingen ville mislykkes selv om ingenting i konfigurasjonen hadde endret seg. Prosessen ville se ut som den døde uten grunn, og loggen ville vise en tillatelsesfeil i stedet for en nettverksfeil.

Med dem gjenbruker den myke omstarten det den privilegerte fasen allerede har fått. Det er ingen magi involvert, og prosessen overlever ingenting. Anskaffelse av ressurser blir bare utsatt.

Les den første feilen, ikke den siste

Når en omstart mislykkes, les den første feilen i stedet for den siste. En beskyttet nøkkel, en auth-fil, en grensesnitt-ioctl og en ekstern krok er fire forskjellige ressurser. Å beholde én sier ingenting om tilgangen til de andre. En krok som kaller et brannmurverktøy trenger fortsatt privilegiene som verktøyet krever.

Kroker har sin egen bryter. OpenVPN-håndboken parer persist-valgene med up-restart, som avgjør om up- og down-skriptene kjører igjen etter en omstart. Et grensesnitt som ble stående oppe forteller deg derfor ingenting om hvorvidt resolver-integrasjonen din ble 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 kommandoer skiller de to feilmodusene på sekunder. Et grensesnitt som er til stede med manglende ruter er et krok- eller ruteproblem. Et grensesnitt som forsvant betyr at prosessen faktisk tok slutt.

Et bevart grensesnitt er ikke en kill switch

Hvis kravet er at trafikk aldri skal forlate tunnelen, leverer ikke en bevart enhet det. Ruter for den andre adressefamilien, en andre standardrute og tilfellet der prosessen avsluttes helt, ligger alle utenfor valgets rekkevidde.

Håndter de to kravene hver for seg. Å beholde tunnelobjektet gjennom gjenoppkoblinger er en bekvemmelighet for daemonen. Å blokkere utgang når tunnelen er nede er en brannmurpolicy med egne regler og egen test. Å blande dem gir en konfigurasjon som ser defensiv ut og oppfører seg som gjenoppkobling etter beste evne.

Navngi hendelsen før du diagnostiserer den. En myk omstart, et mislykket tilkoblingsforsøk og en tjenestestopp er tre hendelser med tre atferder, og bare den første er det disse valgene beskriver.