Das Neuladen des Nebula-Zertifikats änderte die IP nicht: das ist der Grund

Sie stellen ein neues Host-Zertifikat mit einer anderen Overlay-Adresse aus, kopieren es über die alte Datei, senden das Neuladen, und der Host antwortet weiterhin auf der Adresse, die er zuvor hatte. Der Reflex ist anzunehmen, das Neuladen sei fehlgeschlagen oder die falsche Datei sei gelesen worden. Meist ist keines von beidem passiert: Der laufende Prozess hat die Identität, die er bereits hatte, bewusst behalten, weil der Ersatz etwas geändert hat, was ein Neuladen nicht anwenden kann.

Die PKI-Neuladeunterstützung von Nebula ist mit dieser Grenze dokumentiert, und das übersieht man leicht, wenn dieselbe Dokumentation zeigt, dass Neuladen bei anderen Änderungen funktioniert.

Was ein Neuladen tatsächlich neu liest

Ein Host-Zertifikat ist nicht einfach ein Berechtigungsnachweis wie ein SSH-Schlüssel. Es trägt die Overlay-Adresse, den Hostnamen, Gruppenmitgliedschaften und ein Gültigkeitsfenster, und all das ist durch die Signatur der CA miteinander verbunden. Der Daemon nutzt diesen signierten Inhalt, um zu entscheiden, wie er sich darstellt und welche Regeln für ihn gelten.

Neuladen erlaubt dem Prozess, erneuerte Anmeldedaten zu übernehmen, ohne seine Tunnel fallen zu lassen, was bei der Routine-Rotation wertvoll ist: gleiche Adresse, gleicher Name, gleiche Gruppen, späteres Ablaufdatum. Die Einschränkung ist, dass die Identität gleich bleiben muss. Ändern Sie die Overlay-Adresse, und der Neuladepfad kann sie nicht anwenden, weil die Adresse Teil dessen ist, worauf sich die laufende Instanz bereits festgelegt hat.

Das beobachtete Verhalten ist also die dokumentierte Grenze bei der Arbeit, kein stiller Fehlschlag. Die Datei auf der Platte ist neu; die Identität im Speicher ist alt; der Prozess hat keinen unterstützten Weg, diesen Unterschied ohne Neustart auszugleichen.

Adresse, Name und Gruppen sind eine Identität

Es hilft, das Zertifikat als einen einzigen Datensatz zu betrachten und nicht als einen Satz unabhängig bearbeitbarer Felder. Die Adresse zu verschieben ist nicht wie das Ändern einer Einstellung, weil die Adresse in Peer-Konfigurationen anderer Hosts, in Dienstbindungen und in gegen die Identität geschriebenen Richtlinien auftaucht.

Gruppen verdienen eine eigene Zeile, weil sie eine leisere Variante derselben Verwirrung verursachen. Ein Host, der seine Adresse behält, aber die Gruppen wechselt, kann nach einem Neustart andere Dienste erreichen, und ein Test, der nur die alte Adresse pingt, wirkt völlig gesund, während sich die Zugriffsentscheidungen darunter geändert haben. Prüfen Sie einen durch eine Regel abgedeckten Dienst, nicht nur die Erreichbarkeit. Das ist der Unterschied zwischen Tunnel bestätigen und Richtlinie bestätigen.

Vergleichen Sie das geladene Zertifikat mit dem Ersatz

Bevor Sie annehmen, der Daemon habe die Datei ignoriert, lesen Sie beide. Drucken Sie das Zertifikat, das Sie laden wollen, und bestätigen Sie die Felder, die Sie geändert zu haben glauben, und bestätigen Sie dann, dass die laufende Konfiguration auf diesen Pfad zeigt und nicht auf eine Kopie anderswo.

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

Die Prozessargumente sind wichtiger, als man erwartet. Eine Unit, die -config /etc/nebula/config.yml übergibt, liest den Eintrag pki.cert dieser Datei, und ein in einem Zwischenverzeichnis installiertes Zertifikat bewirkt nichts. Prüfen Sie den Pfad in der laufenden Befehlszeile, nicht den Pfad in der Dokumentation, der Sie gefolgt sind. Unterscheiden sich beide, haben Sie das Problem gefunden, ohne das Zertifikat überhaupt anzufassen.

Hat das neue Zertifikat eine andere Adresse und der Prozess die alte behalten, haben Sie jetzt eine Erklärung statt eines Rätsels. Starten Sie ihn neu, wenn das akzeptabel ist, und behandeln Sie die Adressänderung als geplante Netzänderung statt als versehentliche.

Eine Adressänderung ist eine Netzänderung

Planen Sie es wie das Verschieben einer Maschine. Andere Hosts haben die alte Adresse vielleicht in ihrer Konfiguration festgeschrieben, Dienste binden sich vielleicht ausdrücklich daran, und Firewall-Regeln sind vielleicht dagegen geschrieben. Das Zertifikat zu ändern verschiebt den Host, und den Host zu verschieben entwertet Annahmen anderswo.

Halten Sie währenddessen einen zweiten Verwaltungsweg bereit, denn die Overlay-Verbindung ist womöglich genau die, die Sie unterbrechen. Das über den Tunnel zu tun, den Sie gleich brechen, ist der klassische Weg, aus einer fünfminütigen Änderung einen Besuch vor Ort zu machen.

Ob ein Neustart akzeptabel ist, hängt davon ab, was der Host tut, und das ist eine Planungsfrage, keine technische. Was nicht optional ist, ist das Eingeständnis der Neustart-Anforderung, statt das Neuladen ein fünftes Mal zu senden.

Ziehen Sie die alten Anmeldedaten getrennt zurück

Eine Ersatzdatei auf einer einzigen Maschine zu installieren lässt jeden Peer weiterhin den Anmeldedaten vertrauen, die er bereits kennt. War der Grund für die Änderung eine Kompromittierung, muss die alte Identität über das Vertrauens- oder Sperrlistenverfahren zurückgezogen werden, damit Peers sie tatsächlich ablehnen.

Das ist ein eigener Schritt mit eigener Prüfung: Bestätigen Sie von einem anderen Host aus, dass die alte Identität nicht mehr funktioniert, statt anzunehmen, die neue Datei habe die Aufgabe erledigt. Die Nebula-Dokumentation zur PKI-Konfiguration behandelt die neu ladbaren Einstellungen und die hier beschriebene Adressbeschränkung, und es lohnt sich, sie vollständig zu lesen, bevor Sie irgendetwas Produktives rotieren.