Przeładowanie certyfikatu Nebula nie zmieniło IP: oto dlaczego
Przeładowanie ponownie odczytuje dane uwierzytelniające hosta tylko wtedy, gdy adres overlay pozostaje ten sam. Zmiana adresu oznacza restart i zmianę sieci, a nie ponowną próbę.
Wystawiasz nowy certyfikat hosta z innym adresem overlay, kopiujesz go na stary plik, wysyłasz przeładowanie, a host nadal odpowiada na adresie, który miał wcześniej. Odruchem jest założenie, że przeładowanie się nie powiodło albo odczytano niewłaściwy plik. Zwykle nie stało się ani jedno, ani drugie: działający proces celowo zachował tożsamość, którą już miał, ponieważ zamiennik zmienił coś, czego przeładowanie nie może zastosować.
Obsługa przeładowania PKI w Nebuli jest udokumentowana właśnie z tą granicą, i łatwo ją przeoczyć, gdy ta sama dokumentacja pokazuje, że przeładowanie działa dla innych zmian.
Co przeładowanie naprawdę odczytuje ponownie
Certyfikat hosta nie jest tylko danymi uwierzytelniającymi tak, jak klucz SSH. Niesie adres overlay, nazwę hosta, przynależność do grup i okno ważności, a wszystko to jest powiązane podpisem CA. Demon używa tej podpisanej treści, aby zdecydować, jak się prezentuje i jakie reguły go dotyczą.
Przeładowanie pozwala procesowi przejąć odnowione dane uwierzytelniające bez zrywania tuneli, co jest cenne przy rutynowej rotacji: ten sam adres, ta sama nazwa, te same grupy, późniejsze wygaśnięcie. Ograniczenie polega na tym, że tożsamość musi pozostać taka sama. Zmień adres overlay, a ścieżka przeładowania nie może go zastosować, ponieważ adres jest częścią tego, do czego działająca instancja już się zobowiązała.
Zatem zaobserwowane zachowanie to udokumentowana granica wykonująca swoją pracę, a nie cicha awaria. Plik na dysku jest nowy; tożsamość w pamięci jest stara; proces nie ma obsługiwanego sposobu pogodzenia tej różnicy bez restartu.
Adres, nazwa i grupy to jedna tożsamość
Pomaga myśleć o certyfikacie jako o jednym rekordzie, a nie o zestawie pól, które można edytować niezależnie. Przenoszenie adresu nie jest jak zmiana preferencji, ponieważ adres pojawia się w konfiguracjach równorzędnych innych hostów, w powiązaniach usług i w politykach pisanych przeciw tożsamości.
| Field | What changes when you replace it |
|---|---|
| Overlay address | Peers that pinned the old address, service bindings, and any rule written against it |
| Host name | Name-based policy and the identities other hosts expect to see |
| Groups | Which access rules match, even if the address stays identical |
| Validity window | Nothing structural, which is why renewal reloads cleanly |
Grupy zasługują na własną linię, ponieważ powodują cichszą wersję tego samego zamieszania. Host, który zachowuje adres, ale zmienia grupy, po restarcie może dotrzeć do innych usług, a test, który tylko pinguje stary adres, będzie wyglądał całkowicie zdrowo, podczas gdy decyzje o dostępie zmieniły się pod nim. Sprawdź jedną usługę objętą regułą, nie tylko osiągalność. To różnica między potwierdzeniem tunelu a potwierdzeniem polityki.
Porównaj wczytany certyfikat z zamiennikiem
Zanim uznasz, że demon zignorował plik, przeczytaj oba. Wydrukuj certyfikat, który zamierzasz wczytać, i potwierdź pola, które według ciebie zmieniłeś, a następnie potwierdź, że działająca konfiguracja wskazuje tę ścieżkę, a nie kopię gdzie indziej.
nebula-cert print -path /etc/nebula/host.crt
systemctl status nebula
ps -o args= -p $(pgrep -f 'nebula -config' | head -1)Argumenty procesu mają większe znaczenie, niż ludzie oczekują. Jednostka przekazująca -config /etc/nebula/config.yml czyta wpis pki.cert tego pliku, a certyfikat zainstalowany w katalogu tymczasowym niczego nie zmienia. Sprawdź ścieżkę w działającym wierszu poleceń, a nie ścieżkę w dokumentacji, którą się kierowałeś. Jeśli obie się różnią, znalazłeś problem, nie dotykając certyfikatu.
Jeśli nowy certyfikat ma inny adres, a proces zachował stary, masz teraz wyjaśnienie zamiast zagadki. Zrestartuj go, jeśli to akceptowalne, i traktuj zmianę adresu jako planowaną zmianę sieci, a nie przypadkową.
Zmiana adresu to zmiana sieci
Zaplanuj to tak, jak planowałbyś przeniesienie maszyny. Inne hosty mogły przypiąć stary adres w swojej konfiguracji, usługi mogą się do niego wyraźnie wiązać, a reguły zapory mogą być pisane przeciw niemu. Zmiana certyfikatu przenosi hosta, a przeniesienie hosta unieważnia założenia gdzie indziej.
Podczas tej operacji utrzymuj dostępną drugą ścieżkę zarządzania, ponieważ połączenie overlay może być właśnie tym, które przerywasz. Robienie tego przez tunel, który zaraz zerwiesz, to klasyczny sposób zamiany pięciominutowej zmiany w wizytę na miejscu.
Czy restart jest akceptowalny, zależy od tego, co robi host, i jest to kwestia planowania, a nie techniczna. Nie jest opcjonalne uznanie wymogu restartu zamiast wysyłania przeładowania po raz piąty.
Wycofaj stare dane uwierzytelniające osobno
Zainstalowanie zamiennika na jednej maszynie sprawia, że każdy peer nadal ufa danym uwierzytelniającym, które już zna. Jeśli powodem zmiany było naruszenie, starą tożsamość trzeba wycofać procedurą zaufania lub listy blokad, aby peerzy naprawdę ją odrzucili.
To osobny krok z własną weryfikacją: potwierdź z innego hosta, że stara tożsamość już nie działa, zamiast zakładać, że nowy plik załatwił sprawę. Dokumentacja konfiguracji PKI w Nebuli omawia ustawienia przeładowywalne oraz opisane tutaj ograniczenie adresu, i warto ją przeczytać w całości, zanim zaczniesz rotować cokolwiek produkcyjnego.