A recarga do certificado de Nebula non cambiou o IP: velaquí por que
Unha recarga volve ler a credencial do host só cando o enderezo de overlay segue igual. Cambiar o enderezo implica reiniciar e cambiar a rede, non reintentar.
Emites un certificado de host novo con outro enderezo de overlay, cópialo sobre o ficheiro antigo, envías a recarga e o host segue respondendo no enderezo que tiña antes. O reflexo é supor que a recarga fallou ou que se leu o ficheiro equivocado. Normalmente non ocorreu ningunha das dúas cousas: o proceso en execución conservou deliberadamente a identidade que xa tiña, porque o substituto cambiou algo que unha recarga non pode aplicar.
O soporte de recarga do PKI de Nebula está documentado con esa fronteira, e é doado pasala por alto cando a mesma documentación mostra que a recarga funciona para outros cambios.
Que volve ler realmente unha recarga
Un certificado de host non é só unha credencial como o é unha clave SSH. Leva o enderezo de overlay, o nome do host, as pertenzas a grupos e unha xanela de validez, e todo iso está unido pola sinatura da CA. O daemon usa ese contido asinado para decidir como se presenta e que regras se lle aplican.
A recarga permite ao proceso coller unha credencial renovada sen soltar os seus túneles, o que é valioso para a rotación rutineira: mesmo enderezo, mesmo nome, mesmos grupos, caducidade posterior. A restrición é que a identidade debe seguir igual. Cambia o enderezo de overlay e a ruta de recarga non pode aplicalo, porque o enderezo forma parte daquilo ao que a instancia en execución xa se comprometeu.
Así que o comportamento que viches é o límite documentado facendo o seu traballo, non un fallo silencioso. O ficheiro no disco é novo; a identidade na memoria é vella; o proceso non ten forma admitida de conciliar esa diferenza sen reiniciar.
Enderezo, nome e grupos son unha soa identidade
Axuda pensar no certificado como un único rexistro e non como un conxunto de campos que se poden editar por separado. Mover o enderezo non é como cambiar unha preferencia, porque o enderezo aparece nas configuracións de pares doutros hosts, nas vinculacións de servizos e en políticas escritas contra a identidade.
| 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 |
Os grupos merecen a súa propia liña porque provocan unha versión máis silenciosa da mesma confusión. Un host que conserva o enderezo pero cambia de grupos pode chegar a servizos distintos tras reiniciar, e unha proba que só fai ping ao enderezo antigo parecerá completamente san mentres as decisións de acceso cambiaron por debaixo. Comproba un servizo suxeito a unha regra, non só a accesibilidade. Esa é a diferenza entre confirmar o túnel e confirmar a política.
Compara o certificado cargado co substituto
Antes de supor que o daemon ignorou o ficheiro, le ambos. Imprime o certificado que pensas cargar e confirma os campos que cres que cambiaches, despois confirma que a configuración en execución apunta a esa ruta e non a unha copia noutro lugar.
nebula-cert print -path /etc/nebula/host.crt
systemctl status nebula
ps -o args= -p $(pgrep -f 'nebula -config' | head -1)Os argumentos do proceso importan máis do que a xente espera. Unha unidade que pasa -config /etc/nebula/config.yml le a entrada pki.cert dese ficheiro, e un certificado instalado nun directorio temporal non afecta nada. Comproba a ruta na liña de ordes en execución, non a ruta da documentación que seguiches. Se ambas difiren, atopaches o problema sen tocar o certificado.
Se o certificado novo ten un enderezo distinto e o proceso conservou o antigo, agora tes unha explicación en lugar dun misterio. Reiníciao se é aceptable e trata o cambio de enderezo como un cambio de rede planificado e non accidental.
Un cambio de enderezo é un cambio de rede
Planifícao como planificarías mover unha máquina. Outros hosts poden ter fixado o enderezo antigo na súa configuración, os servizos poden enlazarse explicitamente a el e as regras de cortafuegos poden estar escritas contra el. Cambiar o certificado move o host, e mover o host invalida suposicións noutros lugares.
Mantén dispoñible unha segunda ruta de xestión mentres o fas, porque a conexión de overlay pode ser xusto a que estás interrompendo. Facelo a través do túnel que estás a piques de romper é a forma clásica de converter un cambio de cinco minutos nunha visita ao sitio.
Que reiniciar sexa aceptable depende do que faga o host, e iso é unha cuestión de planificación, non técnica. O que non é opcional é recoñecer o requisito de reinicio en lugar de enviar a recarga por quinta vez.
Retira a credencial antiga por separado
Instalar un substituto nunha soa máquina deixa cada par confiando aínda na credencial que xa coñece. Se o motivo do cambio foi un compromiso, a identidade antiga debe retirarse mediante o procedemento de confianza ou de lista de bloqueo para que os pares a rexeiten de verdade.
É un paso aparte coa súa propia verificación: confirma desde outro host que a identidade antiga xa non funciona, en lugar de supor que o ficheiro novo fixo o traballo. A documentación de configuración do PKI de Nebula cobre os axustes recargables e a limitación de enderezo descrita aquí, e paga a pena lela enteira antes de rotar algo produtivo.