Att stoppa tjänsten tar bort gränssnittet även med persist-tun satt. Det är alternativet som fungerar som dokumenterat, inte ett fel. Alternativet beskriver en omstartsväg inne i en körande process, och systemctl stop är inte den vägen.

Läs de två namnen tillsammans och designen blir tydlig. Den ena behåller en deskriptor, den andra behåller nyckelmaterial, och båda finns på grund av det som händer efter att privilegierna släpps.

De två resurserna och omstarten de hör till

OpenVPN signalerar sin egen omstart i två vanliga situationer. En explicit SIGUSR1 gör det, och en ping-restart som utlöses av en död peer gör samma sak. Båda håller processen vid liv och kör anslutningsuppsättningen igen, och det är där alternativen förtjänar sin plats.

EventTUN/TAP deviceKey and auth filesAddresses and routesup/down hooks
Soft reset, from SIGUSR1 or from a ping-restart the daemon sends itselfsurvives only with persist-tunsurvive only with persist-keysurvive with the device, otherwise rebuiltrun again only when restart hooks are enabled
Configuration reload, SIGHUPrecreatedre-read from diskrebuilt once the device returnsrun again
Service stoplostre-read at the next startremovedrun at the next start

Bara raden för mjuk omstart är det dessa två alternativ ändrar, och arbetet de hoppar över är den dyra delen på en upptagen länk. Att öppna en enhet igen river ner adresserna och rutterna som hänger på den, och att bygga upp dem igen kan tappa paket som var på väg när omstarten började. Ett stopp förstör samma objekt utan något alternativ att bevara dem.

Varför alternativen överhuvudtaget finns

En härdad OpenVPN-server startar vanligtvis som root, öppnar sina nycklar och sin enhet och går sedan över till en användare utan privilegier. Efter den övergången är vissa operationer helt enkelt borta. Att läsa en nyckelfil med läge 0600, skapa ett nätverksgränssnitt eller ändra rutter kan allt nekas.

Utan persist-alternativen skulle en peer som tiger tillräckligt länge för att utlösa ping-restart tvinga fram exakt dessa operationer. Återanslutningen skulle misslyckas även om inget i konfigurationen hade ändrats. Processen skulle se ut att dö utan anledning, och loggen skulle visa ett behörighetsfel i stället för ett nätverksfel.

Med dem återanvänder den mjuka omstarten det som den privilegierade fasen redan har fått. Ingen magi är inblandad och processen överlever ingenting. Anskaffning av resurser skjuts helt enkelt upp.

Läs det första felet, inte det sista

När en omstart misslyckas, läs det första felet i stället för det sista. En skyddad nyckel, en auth-fil, en gränssnitts-ioctl och en extern krok är fyra olika resurser. Att behålla en säger ingenting om åtkomsten till de andra. En krok som anropar ett brandväggsverktyg behöver fortfarande de privilegier som verktyget kräver.

Krokar har sin egen strömbrytare. OpenVPN-handboken parar persist-alternativen med up-restart, som avgör om up- och down-skripten körs igen efter en omstart. Ett gränssnitt som blev kvar uppe säger dig därför ingenting om huruvida din resolver-integration uppdaterades.

# 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 kommandon skiljer de två fellägena på sekunder. Ett gränssnitt som finns med saknade rutter är ett krok- eller ruttproblem. Ett gränssnitt som försvann betyder att processen faktiskt tog slut.

Ett bevarat gränssnitt är inte en kill switch

Om kravet är att trafik aldrig får lämna tunneln levererar inte en bevarad enhet det. Rutter för den andra adressfamiljen, en andra standardrutt och fallet där processen avslutas helt ligger alla utanför alternativets räckvidd.

Hantera de två kraven var för sig. Att behålla tunnelobjektet mellan återanslutningar är en bekvämlighet för daemonen. Att blockera utgående trafik när tunneln ligger nere är en brandväggspolicy med egna regler och ett eget test. Att blanda dem ger en konfiguration som ser defensiv ut och beter sig som en återanslutning efter bästa förmåga.

Namnge händelsen innan du diagnostiserar den. En mjuk omstart, ett misslyckat anslutningsförsök och ett tjänstestopp är tre händelser med tre beteenden, och bara den första är vad dessa alternativ beskriver.

Relaterade artiklar