Une mise à jour OPNsense réussit lorsque les services nécessaires fonctionnent correctement après l’intervention et que la modification reste traçable. Un nouveau numéro de version ne suffit pas à l’établir. Notes de version, sauvegarde de configuration et courte liste de tests métier doivent donc être associés.
Lire les changements avant le créneau
Les archives officielles documentent les changements par série de versions. La série 26.7 apporte par exemple des modifications à la gestion des règles, du NAT et des passerelles. Cela montre pourquoi un changement de version peut dépasser le renouvellement du noyau. Le jour de la maintenance, les notes des versions de départ et d’arrivée réellement retenues sont relues.
Les extensions installées et les fonctions dépendant des composants modifiés sont recensées. Une restriction importante pour le système peut figurer dans une rubrique peu visible. Une référence générale à la dernière version ne remplace donc pas la liste des fonctions utilisées dans l’entreprise.
Une sauvegarde doit aussi être exploitable
Avant l’intervention, une sauvegarde actuelle de la configuration est conservée hors du pare-feu. Mots de passe et clés nécessaires sont placés dans le stockage sécurisé prévu et accessibles aux personnes autorisées. Les informations ou fichiers non couverts par ce type précis de sauvegarde sont également identifiés.
La préparation d’urgence inclut l’installation, une plateforme adaptée et un accès d’administration disponible. Un retour arrière n’est pas assimilé à n’importe quelle rétrogradation. La possibilité et la méthode de restauration d’une configuration dans la version prévue doivent correspondre à la séquence de versions concrète et au temps disponible.
Valider avec de vrais processus
Les mêmes opérations sélectionnées sont vérifiées avant et après le changement. Il peut s’agir de l’accès Internet, de la résolution interne des noms, d’un poste VPN et d’une liaison intersites. Pour un tunnel, le chemin des données compte davantage que le seul handshake : l’application prévue doit atteindre sa destination par le bon chemin.
L’exemple officiel WireGuard montre l’articulation entre adresses de tunnel, réseaux autorisés et règles du pare-feu. Dans l’entreprise, les autorisations sont limitées au périmètre nécessaire. Un modèle repris avec des réseaux largement ouverts ne constitue pas une conception individualisée des droits d’accès achevée.
Consigner le résultat et la maintenance suivante
Le compte rendu inclut l’état initial, l’état cible, l’emplacement de sauvegarde sans secrets, les résultats des tests et les actions ouvertes. Toute modification de règle ou de service reçoit sa justification. Une personne qui reprend ensuite la responsabilité peut ainsi comprendre les raisons de l’état actuel.
DAXS planifie la maintenance OPNsense dans le contexte des commutateurs, du Wi-Fi, des connexions opérateur, des services serveurs et des applications réellement utilisées. Un plan de recette limité et reproductible réduit l’effort de la maintenance suivante. La version cible concrète, la compatibilité des extensions et les problèmes connus sont revérifiés pour chaque intervention.
Exploitation informatique au quotidien · Sauvegarde et restauration · Convenir d’une maintenance
Sources : OPNsense : archives des versions (lien externe) · OPNsense : changements de la série 26.7 (lien externe) · OPNsense : liaison WireGuard intersites (lien externe)
