Reîncărcarea certificatului Nebula nu a schimbat IP-ul: iată de ce

Emiteți un certificat nou de gazdă cu altă adresă overlay, îl copiați peste fișierul vechi, trimiteți reîncărcarea, iar gazda continuă să răspundă pe adresa pe care o avea înainte. Reflexul este să presupuneți că reîncărcarea a eșuat sau că a fost citit fișierul greșit. De obicei nu s-a întâmplat nici una, nici alta: procesul care rulează a păstrat intenționat identitatea pe care o avea deja, pentru că înlocuirea a schimbat ceva ce o reîncărcare nu poate aplica.

Suportul de reîncărcare a PKI din Nebula este documentat cu această limită, și e ușor de ratat atunci când aceeași documentație arată că reîncărcarea funcționează pentru alte modificări.

Ce recitește de fapt o reîncărcare

Un certificat de gazdă nu este doar o acreditare în felul în care este o cheie SSH. El poartă adresa overlay, numele gazdei, apartenențele la grupuri și o fereastră de valabilitate, iar toate acestea sunt legate de semnătura CA. Demonul folosește acel conținut semnat pentru a decide cum se prezintă și ce reguli i se aplică.

Reîncărcarea permite procesului să preia acreditări reînnoite fără a-și pierde tunelurile, ceea ce este valoros pentru rotația de rutină: aceeași adresă, același nume, aceleași grupuri, expirare mai târzie. Constrângerea este că identitatea trebuie să rămână aceeași. Schimbați adresa overlay și calea de reîncărcare nu o poate aplica, pentru că adresa face parte din ceea ce instanța care rulează s-a angajat deja.

Așadar comportamentul pe care l-ați văzut este limita documentată făcându-și treaba, nu o eșuare silențioasă. Fișierul de pe disc este nou; identitatea din memorie este veche; procesul nu are o modalitate acceptată de a reconcilia această diferență fără repornire.

Adresă, nume și grupuri sunt o singură identitate

Ajută să gândiți certificatul ca pe o singură înregistrare și nu ca pe un set de câmpuri editabile independent. Mutarea adresei nu este ca schimbarea unei preferințe, pentru că adresa apare în configurațiile de parteneri ale altor gazde, în legăturile serviciilor și în politici scrise împotriva identității.

Grupurile merită rândul lor pentru că provoacă o versiune mai tăcută a aceleiași confuzii. O gazdă care își păstrează adresa dar schimbă grupurile poate ajunge la servicii diferite după o repornire, iar un test care doar face ping la adresa veche va părea complet sănătos în timp ce deciziile de acces s-au schimbat dedesubt. Verificați un singur serviciu supus unei reguli, nu doar accesibilitatea. Aceasta este diferența dintre a confirma tunelul și a confirma politica.

Comparați certificatul încărcat cu înlocuitorul

Înainte de a presupune că demonul a ignorat fișierul, citiți-le pe amândouă. Tipăriți certificatul pe care intenționați să îl încărcați și confirmați câmpurile pe care credeți că le-ați schimbat, apoi confirmați că configurația care rulează indică acea cale și nu o copie în altă parte.

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

Argumentele procesului contează mai mult decât se așteaptă lumea. O unitate care transmite -config /etc/nebula/config.yml citește intrarea pki.cert a acelui fișier, iar un certificat instalat într-un director temporar nu afectează nimic. Verificați calea din linia de comandă care rulează, nu calea din documentația pe care ați urmat-o. Dacă cele două diferă, ați găsit problema fără să atingeți deloc certificatul.

Dacă certificatul nou are altă adresă și procesul a păstrat-o pe cea veche, acum aveți o explicație în loc de un mister. Reporniți-l dacă este acceptabil și tratați schimbarea adresei ca o modificare de rețea planificată și nu accidentală.

O schimbare de adresă este o schimbare de rețea

Planificați-o așa cum ați planifica mutarea unei mașini. Alte gazde pot fi fixat adresa veche în configurația lor, serviciile se pot lega explicit de ea, iar regulile de firewall pot fi scrise împotriva ei. Schimbarea certificatului mută gazda, iar mutarea gazdei invalidează presupuneri în alte locuri.

Păstrați o a doua cale de administrare disponibilă în timp ce faceți acest lucru, pentru că legătura overlay poate fi exact cea pe care o întrerupeți. A face asta prin tunelul pe care sunteți pe punctul de a-l rupe este modul clasic de a transforma o modificare de cinci minute într-o vizită la fața locului.

Dacă repornirea este acceptabilă depinde de ce face gazda, iar aceasta este o problemă de planificare, nu tehnică. Ceea ce nu este opțional este să recunoașteți cerința de repornire în loc să trimiteți reîncărcarea a cincea oară.

Retrageți acreditările vechi separat

Instalarea unui înlocuitor pe o singură mașină lasă fiecare partener să aibă încredere în continuare în acreditarea pe care o știe deja. Dacă motivul schimbării a fost o compromitere, identitatea veche trebuie retrasă prin procedura de încredere sau de listă de blocare, astfel încât partenerii să o respingă cu adevărat.

Acesta este un pas separat cu propria verificare: confirmați de pe altă gazdă că identitatea veche nu mai funcționează, în loc să presupuneți că noul fișier și-a făcut treaba. Documentația de configurare PKI a Nebula acoperă setările reîncărcabile și limitarea de adresă descrisă aici, și merită citită în întregime înainte de a roti ceva de producție.