La recàrrega del certificat de Nebula no va canviar la IP: vet aquí el motiu
Una recàrrega torna a llegir la credencial de l’amfitrió només quan l’adreça d’overlay es manté igual. Canviar l’adreça vol dir reiniciar i canviar la xarxa, no tornar-ho a provar.
Emeteu un certificat d’amfitrió nou amb una adreça d’overlay diferent, el copieu sobre el fitxer antic, envieu la recàrrega i l’amfitrió continua responent a l’adreça que tenia abans. El reflex és suposar que la recàrrega ha fallat o que s’ha llegit el fitxer equivocat. Normalment no ha passat cap de les dues coses: el procés en execució ha conservat deliberadament la identitat que ja tenia, perquè la substitució ha canviat una cosa que una recàrrega no pot aplicar.
El suport de recàrrega del PKI de Nebula està documentat amb aquesta frontera, i és fàcil passar-la per alt quan la mateixa documentació mostra que la recàrrega funciona per a altres canvis.
Què torna a llegir realment una recàrrega
Un certificat d’amfitrió no és només una credencial com ho és una clau SSH. Porta l’adreça d’overlay, el nom de l’amfitrió, les pertinences a grups i una finestra de validesa, i tot això està lligat per la signatura de la CA. El dimoni fa servir aquest contingut signat per decidir com es presenta i quines regles se li apliquen.
La recàrrega permet al procés agafar una credencial renovada sense deixar caure els seus túnels, cosa valuosa per a la rotació rutinària: mateixa adreça, mateix nom, mateixos grups, caducitat més tardana. La restricció és que la identitat ha de continuar igual. Canvieu l’adreça d’overlay i el camí de recàrrega no la pot aplicar, perquè l’adreça forma part d’allò a què la instància en execució ja es va comprometre.
Així, el comportament que heu vist és el límit documentat fent la seva feina, no un fracàs silenciós. El fitxer del disc és nou; la identitat en memòria és vella; el procés no té cap manera suportada de conciliar aquesta diferència sense reiniciar.
Adreça, nom i grups són una sola identitat
Ajuda pensar en el certificat com un sol registre i no com un conjunt de camps que es poden editar per separat. Moure l’adreça no és com canviar una preferència, perquè l’adreça apareix a les configuracions de parells d’altres amfitrions, a les vinculacions de serveis i a les polítiques escrites contra la identitat.
| 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 |
Els grups mereixen una línia pròpia perquè provoquen una versió més silenciosa de la mateixa confusió. Un amfitrió que conserva l’adreça però canvia de grups pot arribar a serveis diferents després de reiniciar, i una prova que només fa ping a l’adreça antiga semblarà del tot sana mentre les decisions d’accés han canviat per sota. Comproveu un servei sotmès a una regla, no només l’abast. Aquesta és la diferència entre confirmar el túnel i confirmar la política.
Compareu el certificat carregat amb la substitució
Abans de suposar que el dimoni ha ignorat el fitxer, llegiu tots dos. Imprimiu el certificat que voleu carregar i confirmeu els camps que creieu que heu canviat, i després confirmeu que la configuració en execució apunta a aquest camí i no a una còpia en un altre lloc.
nebula-cert print -path /etc/nebula/host.crt
systemctl status nebula
ps -o args= -p $(pgrep -f 'nebula -config' | head -1)Els arguments del procés importen més del que la gent espera. Una unitat que passa -config /etc/nebula/config.yml llegeix l’entrada pki.cert d’aquest fitxer, i un certificat instal·lat en un directori temporal no afecta res. Comproveu el camí a la línia d’ordres en execució, no el camí de la documentació que heu seguit. Si tots dos difereixen, heu trobat el problema sense tocar el certificat.
Si el certificat nou té una adreça diferent i el procés ha conservat la vella, ara teniu una explicació en lloc d’un misteri. Reinicieu-lo si és acceptable i tracteu el canvi d’adreça com un canvi de xarxa planificat i no accidental.
Un canvi d’adreça és un canvi de xarxa
Planifiqueu-ho com planificaríeu moure una màquina. Altres amfitrions poden haver fixat l’adreça antiga a la seva configuració, els serveis poden enllaçar-s’hi explícitament i les regles de tallafocs poden estar escrites contra ella. Canviar el certificat mou l’amfitrió, i moure l’amfitrió invalida supòsits en altres llocs.
Manteniu un segon camí de gestió disponible mentre ho feu, perquè la connexió d’overlay pot ser la que esteu interrompent. Fer-ho a través del túnel que esteu a punt de trencar és la manera clàssica de convertir un canvi de cinc minuts en una visita al lloc.
Si reiniciar és acceptable depèn del que fa l’amfitrió, i això és una qüestió de planificació, no tècnica. El que no és opcional és reconèixer el requisit de reinici en lloc d’enviar la recàrrega per cinquè cop.
Retireu la credencial vella per separat
Instal·lar una substitució en una sola màquina deixa cada parell confiant encara en la credencial que ja coneix. Si el motiu del canvi va ser un compromís, la identitat vella s’ha de retirar mitjançant el procediment de confiança o de llista de bloqueig perquè els parells la rebutgin de debò.
És un pas a part amb la seva pròpia verificació: confirmeu des d’un altre amfitrió que la identitat vella ja no funciona, en lloc de suposar que el fitxer nou ha fet la feina. La documentació de configuració del PKI de Nebula cobreix els paràmetres recarregables i la limitació d’adreça descrita aquí, i val la pena llegir-la sencera abans de rotar res productiu.