Le rechargement du certificat Nebula n’a pas changé l’IP : voici pourquoi

Vous émettez un nouveau certificat d’hôte avec une autre adresse d’overlay, vous le copiez par-dessus l’ancien fichier, vous envoyez le rechargement, et l’hôte continue de répondre sur l’adresse qu’il avait auparavant. Le réflexe est de supposer que le rechargement a échoué ou que le mauvais fichier a été lu. En général, ni l’un ni l’autre ne s’est produit : le processus en cours a délibérément conservé l’identité qu’il avait déjà, parce que le remplacement a modifié quelque chose qu’un rechargement ne peut pas appliquer.

La prise en charge du rechargement PKI de Nebula est documentée avec cette limite, et il est facile de la manquer lorsque la même documentation montre que le rechargement fonctionne pour d’autres changements.

Ce qu’un rechargement relit réellement

Un certificat d’hôte n’est pas qu’un identifiant comme peut l’être une clé SSH. Il porte l’adresse d’overlay, le nom d’hôte, les appartenances aux groupes et une fenêtre de validité, et tout cela est lié par la signature de l’AC. Le démon utilise ce contenu signé pour décider comment il se présente et quelles règles s’y appliquent.

Le rechargement permet au processus de récupérer des identifiants renouvelés sans perdre ses tunnels, ce qui est précieux pour une rotation de routine : même adresse, même nom, mêmes groupes, expiration plus lointaine. La contrainte est que l’identité doit rester identique. Changez l’adresse d’overlay et le chemin de rechargement ne peut pas l’appliquer, car l’adresse fait partie de ce à quoi l’instance en cours s’est déjà engagée.

Le comportement que vous avez observé est donc la limite documentée qui fait son travail, pas un échec silencieux. Le fichier sur le disque est nouveau ; l’identité en mémoire est ancienne ; le processus n’a aucun moyen pris en charge de réconcilier cette différence sans redémarrage.

Adresse, nom et groupes forment une seule identité

Il est utile de voir le certificat comme un enregistrement unique plutôt que comme un ensemble de champs modifiables indépendamment. Déplacer l’adresse n’est pas comme changer une préférence, car l’adresse apparaît dans les configurations de pairs d’autres hôtes, dans les liaisons de services et dans des politiques écrites contre l’identité.

Les groupes méritent leur propre ligne, car ils provoquent une version plus discrète de la même confusion. Un hôte qui conserve son adresse mais change de groupes peut atteindre d’autres services après un redémarrage, et un test qui ne fait que pinguer l’ancienne adresse semblera parfaitement sain alors que les décisions d’accès ont changé en dessous. Vérifiez un service soumis à une règle, pas seulement l’accessibilité. C’est la différence entre confirmer le tunnel et confirmer la politique.

Comparez le certificat chargé avec le remplacement

Avant de supposer que le démon a ignoré le fichier, lisez les deux. Affichez le certificat que vous comptez charger et confirmez les champs que vous pensez avoir modifiés, puis confirmez que la configuration en cours pointe vers ce chemin et non vers une copie ailleurs.

nebula-cert print -path /etc/nebula/host.crt
systemctl status nebula
ps -o args= -p $(pgrep -f 'nebula -config' | head -1)

Les arguments du processus comptent plus qu’on ne l’imagine. Une unité qui transmet -config /etc/nebula/config.yml lit l’entrée pki.cert de ce fichier, et un certificat installé dans un répertoire temporaire n’affecte rien. Vérifiez le chemin dans la ligne de commande en cours, pas le chemin de la documentation que vous avez suivie. Si les deux diffèrent, vous avez trouvé le problème sans même toucher au certificat.

Si le nouveau certificat a une adresse différente et que le processus a gardé l’ancienne, vous avez désormais une explication plutôt qu’un mystère. Redémarrez-le si cela est acceptable, et traitez le changement d’adresse comme un changement de réseau planifié et non accidentel.

Un changement d’adresse est un changement de réseau

Planifiez-le comme vous planifieriez le déplacement d’une machine. D’autres hôtes ont peut-être épinglé l’ancienne adresse dans leur configuration, des services peuvent s’y lier explicitement, et des règles de pare-feu peuvent être écrites contre elle. Changer le certificat déplace l’hôte, et déplacer l’hôte invalide des hypothèses ailleurs.

Gardez un second chemin d’administration disponible pendant l’opération, car la connexion overlay est peut-être celle que vous interrompez. Faire cela par le tunnel que vous êtes sur le point de casser est la façon classique de transformer un changement de cinq minutes en visite sur site.

Qu’un redémarrage soit acceptable dépend de ce que fait l’hôte, et c’est une question de planification plutôt que technique. Ce qui n’est pas optionnel, c’est de reconnaître l’exigence de redémarrage au lieu d’envoyer le rechargement une cinquième fois.

Retirez l’ancien identifiant séparément

Installer un remplacement sur une seule machine laisse chaque pair continuer à faire confiance à l’identifiant qu’il connaît déjà. Si la raison du changement était une compromission, l’ancienne identité doit être retirée via la procédure de confiance ou de liste de blocage pour que les pairs la rejettent réellement.

C’est une étape distincte avec sa propre vérification : confirmez depuis un autre hôte que l’ancienne identité ne fonctionne plus, au lieu de supposer que le nouveau fichier a fait le travail. La documentation de configuration PKI de Nebula couvre les paramètres rechargeables et la limitation d’adresse décrite ici, et il vaut la peine de la lire en entier avant de faire tourner quoi que ce soit en production.