Il ricaricamento del certificato Nebula non ha cambiato l’IP: ecco perché

Emetti un nuovo certificato host con un indirizzo di overlay diverso, lo copi sopra il file vecchio, invii il ricaricamento, e l’host continua a rispondere sull’indirizzo che aveva prima. Il riflesso è supporre che il ricaricamento sia fallito o che sia stato letto il file sbagliato. Di solito non è accaduto né l’uno né l’altro: il processo in esecuzione ha mantenuto deliberatamente l’identità che aveva già, perché la sostituzione ha cambiato qualcosa che un ricaricamento non può applicare.

Il supporto al ricaricamento del PKI di Nebula è documentato con questo limite, ed è facile trascurarlo quando la stessa documentazione mostra che il ricaricamento funziona per altre modifiche.

Che cosa rilegge davvero un ricaricamento

Un certificato host non è solo una credenziale come lo è una chiave SSH. Porta l’indirizzo di overlay, il nome host, le appartenenze ai gruppi e una finestra di validità, e tutto questo è legato dalla firma della CA. Il demone usa quel contenuto firmato per decidere come si presenta e quali regole gli si applicano.

Il ricaricamento consente al processo di prendere credenziali rinnovate senza perdere i suoi tunnel, il che è prezioso per la rotazione ordinaria: stesso indirizzo, stesso nome, stessi gruppi, scadenza più tarda. Il vincolo è che l’identità deve restare la stessa. Cambia l’indirizzo di overlay e il percorso di ricaricamento non può applicarlo, perché l’indirizzo fa parte di ciò a cui l’istanza in esecuzione si è già impegnata.

Quindi il comportamento che hai visto è il limite documentato che fa il suo lavoro, non un guasto silenzioso. Il file su disco è nuovo; l’identità in memoria è vecchia; il processo non ha un modo supportato per conciliare quella differenza senza riavvio.

Indirizzo, nome e gruppi sono un’unica identità

Aiuta pensare al certificato come a un singolo record e non come a un insieme di campi modificabili separatamente. Spostare l’indirizzo non è come cambiare una preferenza, perché l’indirizzo compare nelle configurazioni dei peer di altri host, nei binding dei servizi e in policy scritte contro l’identità.

I gruppi meritano una riga propria perché provocano una versione più silenziosa della stessa confusione. Un host che conserva l’indirizzo ma cambia gruppi può raggiungere servizi diversi dopo un riavvio, e un test che fa ping solo al vecchio indirizzo sembrerà del tutto sano mentre le decisioni di accesso sono cambiate sotto. Verifica un servizio soggetto a una regola, non solo la raggiungibilità. È la differenza tra confermare il tunnel e confermare la policy.

Confronta il certificato caricato con il sostituto

Prima di supporre che il demone abbia ignorato il file, leggi entrambi. Stampa il certificato che intendi caricare e conferma i campi che pensi di aver cambiato, poi conferma che la configurazione in esecuzione punti a quel percorso e non a una copia altrove.

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

Gli argomenti del processo contano più di quanto la gente si aspetti. Un’unità che passa -config /etc/nebula/config.yml legge la voce pki.cert di quel file, e un certificato installato in una directory temporanea non influisce su nulla. Controlla il percorso nella riga di comando in esecuzione, non il percorso nella documentazione che hai seguito. Se i due differiscono, hai trovato il problema senza toccare il certificato.

Se il nuovo certificato ha un indirizzo diverso e il processo ha mantenuto quello vecchio, ora hai una spiegazione invece di un mistero. Riavvialo se è accettabile, e tratta il cambio di indirizzo come una modifica di rete pianificata e non accidentale.

Un cambio di indirizzo è un cambio di rete

Pianificalo come pianificheresti lo spostamento di una macchina. Altri host potrebbero aver fissato il vecchio indirizzo nella loro configurazione, i servizi potrebbero legarsi esplicitamente ad esso, e le regole del firewall potrebbero essere scritte contro di esso. Cambiare il certificato sposta l’host, e spostare l’host invalida assunzioni altrove.

Tieni disponibile un secondo percorso di gestione mentre lo fai, perché la connessione overlay potrebbe essere proprio quella che stai interrompendo. Farlo attraverso il tunnel che stai per rompere è il modo classico di trasformare una modifica di cinque minuti in una visita in sede.

Se il riavvio sia accettabile dipende da cosa fa l’host, ed è una questione di pianificazione, non tecnica. Ciò che non è opzionale è riconoscere il requisito di riavvio invece di inviare il ricaricamento per la quinta volta.

Ritira l’identità vecchia separatamente

Installare un sostituto su una sola macchina lascia ogni peer ancora fiducioso della credenziale che già conosce. Se il motivo del cambiamento è stato una compromissione, l’identità vecchia deve essere ritirata tramite la procedura di fiducia o di blocklist perché i peer la rifiutino davvero.

È un passo separato con la sua verifica: conferma da un altro host che l’identità vecchia non funziona più, invece di supporre che il nuovo file abbia fatto il lavoro. La documentazione di configurazione del PKI di Nebula copre le impostazioni ricaricabili e il limite di indirizzo descritto qui, e vale la pena leggerla per intero prima di ruotare qualsiasi cosa in produzione.