Ce que persist-tun et persist-key survivent réellement dans OpenVPN
Les deux options couvrent un redémarrage logiciel au sein d’un processus vivant. Elles ne conservent pas l’interface après un arrêt et ne constituent pas une politique de blocage du trafic.
Arrêter le service supprime l’interface même avec persist-tun défini. C’est l’option qui fonctionne comme documenté, pas une panne. L’option décrit un chemin de redémarrage au sein d’un processus en cours, et systemctl stop n’est pas ce chemin.
Lisez les deux noms ensemble et la conception devient claire. L’un conserve un descripteur, l’autre conserve le matériel de clé, et les deux existent à cause de ce qui se passe après l’abandon des privilèges.
Les deux ressources et le redémarrage auquel elles appartiennent
OpenVPN signale son propre redémarrage dans deux situations ordinaires. Un SIGUSR1 explicite le fait, et un ping-restart déclenché par un pair mort fait de même. Les deux laissent le processus vivant et réexécutent la configuration de la connexion, et c’est là que les options gagnent leur place.
| 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 |
Seule la ligne du redémarrage logiciel est ce que ces deux options changent, et le travail qu’elles évitent est la partie coûteuse sur un lien chargé. Rouvrir un périphérique démonte les adresses et les routes qui y sont attachées, et les reconstruire peut perdre des paquets qui étaient en vol au début du redémarrage. Un arrêt détruit les mêmes objets sans aucune option pour les préserver.
Pourquoi ces options existent-elles
Un serveur OpenVPN durci démarre généralement en root, ouvre ses clés et son périphérique, puis passe à un utilisateur non privilégié. Après ce passage, certaines opérations ont tout simplement disparu. Lire un fichier de clé en mode 0600, créer une interface réseau ou modifier des routes peuvent tous être refusés.
Sans les options persist, un pair qui reste silencieux assez longtemps pour déclencher ping-restart forcerait exactement ces opérations. La reconnexion échouerait alors même que rien dans la configuration n’avait changé. Le processus semblerait mourir sans raison, et le journal afficherait une erreur de permission plutôt qu’une erreur réseau.
Avec elles, le redémarrage logiciel réutilise ce que la phase privilégiée a déjà obtenu. Aucune magie n’est en jeu et le processus ne survit à rien. L’acquisition des ressources est simplement différée.
Lisez la première erreur, pas la dernière
Quand un redémarrage échoue, lisez la première erreur plutôt que la dernière. Une clé protégée, un fichier auth, un ioctl d’interface et un hook externe sont quatre ressources différentes. En conserver une ne dit rien sur l’accès aux autres. Un hook qui appelle un outil de pare-feu a toujours besoin des privilèges que cet outil exige.
Les hooks ont leur propre interrupteur. Le manuel d’OpenVPN associe les options persist à up-restart, qui décide si les scripts up et down sont réexécutés après un redémarrage. Une interface restée active ne vous dit donc rien sur le rafraîchissement de votre intégration de résolution.
# 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 tun0Cette paire de commandes sépare les deux modes de défaillance en quelques secondes. Une interface présente avec des routes manquantes est un problème de hook ou de route. Une interface qui a disparu signifie que le processus a réellement pris fin.
Une interface conservée n’est pas un kill switch
Si l’exigence est que le trafic ne quitte jamais le tunnel, un périphérique conservé ne le fournit pas. Les routes de l’autre famille d’adresses, une seconde route par défaut et le cas où le processus se termine complètement restent tous hors du champ de l’option.
Traitez les deux exigences séparément. Conserver l’objet tunnel à travers les reconnexions est une commodité pour le démon. Bloquer la sortie lorsque le tunnel est en panne est une politique de pare-feu avec ses propres règles et son propre test. Les confondre produit une configuration qui semble défensive et se comporte comme une reconnexion au mieux.
Nommez l’événement avant de le diagnostiquer. Un redémarrage logiciel, une tentative de connexion échouée et un arrêt de service sont trois événements avec trois comportements, et seul le premier est ce que ces options décrivent.