Les mises à jour non surveillées du serveur VPN exigent un chemin de récupération testé

Les mises à jour non surveillées sont une politique raisonnable pour un serveur auquel vous accédez par son propre VPN, et elles sont en même temps un point de défaillance unique que vous vous infligez. L’opération du paquet redémarre le service, le tunnel tombe, et le chemin d’administration que vous utilisiez disparaît avec lui. Il existe deux modèles de récupération, et le choix entre eux dépend d’une condition : si vous disposez d’une voie d’accès qui ne passe pas par ce qui est mis à jour.

Deux modèles de récupération, une condition décisive

Le premier modèle fait confiance à la mise à jour et suppose que vous pourrez vous reconnecter ensuite. Il fonctionne quand le VPN est l’un des plusieurs moyens d’atteindre l’hôte et quand la défaillance du tunnel ne vous retire pas la capacité de le diagnostiquer. Le second modèle place à l’avance un chemin indépendant, généralement la console de l’hébergeur, et traite le tunnel comme ce que la maintenance cassera le plus probablement. Les deux modèles sont défendables, et un seul exige du travail en amont.

La condition décisive est facile à énoncer et facile à omettre. Si chaque chemin d’administration vers la machine passe par le service mis à jour, vous n’avez aucun modèle de récupération, seulement une attente. Dites-le à voix haute lors de la revue du changement.

Tester cette condition prend dix minutes et doit avoir lieu avant la première mise à jour non surveillée, pas pendant l’incident. Ouvrez la console pendant que tout fonctionne, confirmez que les identifiants sont à jour, puis refermez-la. Confirmez que la console s’ouvre sur l’hôte que vous croyez. Confirmez ensuite que la connexion que vous utiliseriez réellement à 3 heures du matin fonctionne encore.

Cette dernière partie compte plus qu’elle n’en a l’air. Un compte de console dont le mot de passe a été changé il y a six mois et jamais vérifié n’est pas un chemin de récupération ; c’est un document qui en décrit un.

Ce qu’une sauvegarde ne restaure pas

Une archive de configuration est un relevé de fichiers, et une mise à jour change plus que des fichiers. L’état des paquets, les modules du noyau, les liens d’unités activés et les règles de pare-feu appliquées par un outil séparé vivent tous hors du répertoire de configuration, et une restauration qui les ignore produit une machine qui semble configurée et ne transmet pas.

L’autorisation mérite sa propre ligne. Une sauvegarde prise avant le retrait d’un appareil compromis restaurera volontiers l’accès de cet appareil. Y revenir pendant une panne est la façon dont un incident devient deux, et la décision de restaurer devrait être prise au sujet des pairs aussi explicitement qu’au sujet des fichiers.

Le mécanisme du retour en arrière compte aussi. Copier un exécutable plus ancien par-dessus un exécutable géré par le paquet n’est pas l’annulation prise en charge d’un changement de paquet, et cela laisse la base de paquets décrire un état auquel le système de fichiers ne correspond pas. Utilisez le chemin de rétrogradation du gestionnaire de paquets lui-même ou l’instantané proposé par l’hébergeur. Une rétrogradation que la base de paquets enregistre est une rétrogradation que vous pouvez répéter.

Rien de tout cela n’argumente contre les sauvegardes. Cela argumente pour savoir quelle couche chaque artefact couvre, parce que le mode de défaillance d’une restauration partielle est plus déroutant que la panne d’origine. Écrivez la couche à côté de chaque sauvegarde dans le runbook.

Point de contrôle, mise à jour, puis vérification depuis l’extérieur

Enregistrez l’état avant le changement sous une forme que vous pourrez comparer ensuite : les versions installées, les unités de service concernées, les sockets en écoute et la liste actuelle des pairs. Quatre commandes couvrent l’essentiel sur un hôte Linux.

systemctl list-units --type=service | grep -E 'openvpn|wg-quick'
ss -lunp | grep -E ':51820|:1194'
journalctl -u wg-quick@wg0 --since '-10 min'

La première montre quelles unités existent et si elles tournent, la deuxième confirme que l’écouteur est réellement lié, et la troisième vous donne le récit du service lui-même sur les dernières minutes. Aucune ne prouve qu’un client peut se connecter, c’est pourquoi l’étape suivante se fait hors de l’hôte. Gardez ces relevés comme base de comparaison.

Vérifiez depuis un réseau qui n’utilise pas le tunnel : authentifiez un client autorisé, résolvez un nom et atteignez une application prévue. Une ligne d’état locale disant que l’interface est montée est une affirmation sur l’interface, pas sur le routage, les clés ou la politique qui admet un pair.

Testez ensuite délibérément le chemin de reconnexion. Redémarrez le service une fois et confirmez que le tunnel revient sans intervention manuelle, car un service qui ne démarre correctement qu’au boot est un service qui vous surprendra au pire moment.

Quand cela échoue, utilisez le chemin que vous avez testé

La séquence de récupération n’a rien de glamour et elle fonctionne : atteignez l’hôte par le chemin indépendant, lisez les journaux du service lui-même et restaurez le point de contrôle précis qui correspond à la défaillance. Ne changez qu’une chose par tentative pour que la prochaine lecture de journal signifie quelque chose.

Résistez à l’envie de faire plusieurs changements non consignés pour retrouver la connectivité. Une machine réparée par cinq modifications simultanées ne peut pas être expliquée ensuite, et la prochaine mise à jour réintroduira celle qui portait réellement la charge.

Décidez ensuite la politique permanente avec des preuves. Si la mise à jour a révélé une dépendance que personne n’avait documentée, le correctif est de la documentation et un test, pas la désactivation des mises à jour. Si elle a révélé un service qui ne peut pas redémarrer proprement, le correctif est dans l’unité, pas dans le calendrier.

La comparaison se résout proprement dès que la condition est nommée. Un chemin indépendant fait des mises à jour non surveillées un risque gérable. Son absence fait de la même politique une panne programmée au délai de récupération inconnu, et aucune quantité d’automatisation ne change cette arithmétique.