Recargar el certificado de Nebula no cambió la IP: esta es la razón
Una recarga vuelve a leer la credencial del host solo cuando la dirección de overlay sigue igual. Cambiar la dirección implica reiniciar y cambiar la red, no reintentar.
Emites un certificado de host nuevo con otra dirección de overlay, lo copias sobre el archivo antiguo, envías la recarga y el host sigue respondiendo en la dirección que tenía antes. El reflejo es suponer que la recarga falló o que se leyó el archivo equivocado. Normalmente no ocurrió ninguna de las dos cosas: el proceso en ejecución conservó deliberadamente la identidad que ya tenía, porque el reemplazo cambió algo que una recarga no puede aplicar.
El soporte de recarga del PKI de Nebula está documentado con esa frontera, y es fácil pasarla por alto cuando la misma documentación muestra que la recarga funciona para otros cambios.
Qué vuelve a leer realmente una recarga
Un certificado de host no es solo una credencial como lo es una clave SSH. Lleva la dirección de overlay, el nombre del host, las pertenencias a grupos y una ventana de validez, y todo eso está unido por la firma de la CA. El demonio usa ese contenido firmado para decidir cómo se presenta y qué reglas se le aplican.
La recarga permite al proceso tomar una credencial renovada sin soltar sus túneles, lo que es valioso para la rotación rutinaria: misma dirección, mismo nombre, mismos grupos, caducidad posterior. La restricción es que la identidad debe seguir igual. Cambia la dirección de overlay y la ruta de recarga no puede aplicarla, porque la dirección forma parte de aquello a lo que la instancia en ejecución ya se comprometió.
Así que el comportamiento que viste es el límite documentado haciendo su trabajo, no un fallo silencioso. El archivo en disco es nuevo; la identidad en memoria es antigua; el proceso no tiene forma soportada de conciliar esa diferencia sin reiniciar.
Dirección, nombre y grupos son una sola identidad
Ayuda pensar en el certificado como un único registro y no como un conjunto de campos que se pueden editar por separado. Mover la dirección no es como cambiar una preferencia, porque la dirección aparece en las configuraciones de pares de otros hosts, en las vinculaciones de servicios y en políticas escritas contra la identidad.
| 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 |
Los grupos merecen su propia línea porque provocan una versión más silenciosa de la misma confusión. Un host que conserva su dirección pero cambia de grupos puede llegar a servicios distintos tras reiniciar, y una prueba que solo hace ping a la dirección antigua parecerá completamente sana mientras las decisiones de acceso han cambiado por debajo. Comprueba un servicio sujeto a una regla, no solo el alcance. Esa es la diferencia entre confirmar el túnel y confirmar la política.
Compara el certificado cargado con el reemplazo
Antes de suponer que el demonio ignoró el archivo, lee ambos. Imprime el certificado que pretendes cargar y confirma los campos que crees que cambiaste, luego confirma que la configuración en ejecución apunta a esa ruta y no a una copia en otro lugar.
nebula-cert print -path /etc/nebula/host.crt
systemctl status nebula
ps -o args= -p $(pgrep -f 'nebula -config' | head -1)Los argumentos del proceso importan más de lo que la gente espera. Una unidad que pasa -config /etc/nebula/config.yml lee la entrada pki.cert de ese archivo, y un certificado instalado en un directorio temporal no afecta a nada. Comprueba la ruta en la línea de comandos en ejecución, no la ruta de la documentación que seguiste. Si ambas difieren, has encontrado el problema sin tocar el certificado.
Si el certificado nuevo tiene una dirección distinta y el proceso conservó la antigua, ahora tienes una explicación en lugar de un misterio. Reinícialo si es aceptable y trata el cambio de dirección como un cambio de red planificado y no accidental.
Un cambio de dirección es un cambio de red
Planifícalo como planificarías mover una máquina. Otros hosts pueden haber fijado la dirección antigua en su configuración, los servicios pueden enlazarse explícitamente a ella y las reglas de cortafuegos pueden estar escritas contra ella. Cambiar el certificado mueve el host, y mover el host invalida supuestos en otros lugares.
Mantén disponible una segunda ruta de gestión mientras lo haces, porque la conexión de overlay puede ser justo la que estás interrumpiendo. Hacerlo a través del túnel que estás a punto de romper es la forma clásica de convertir un cambio de cinco minutos en una visita al sitio.
Que reiniciar sea aceptable depende de lo que haga el host, y eso es una cuestión de planificación, no técnica. Lo que no es opcional es reconocer el requisito de reinicio en lugar de enviar la recarga por quinta vez.
Retira la credencial antigua por separado
Instalar un reemplazo en una sola máquina deja a cada par confiando todavía en la credencial que ya conoce. Si el motivo del cambio fue un compromiso, la identidad antigua debe retirarse mediante el procedimiento de confianza o de lista de bloqueo para que los pares la rechacen de verdad.
Es un paso aparte con su propia verificación: confirma desde otro host que la identidad antigua ya no funciona, en lugar de suponer que el archivo nuevo hizo el trabajo. La documentación de configuración del PKI de Nebula cubre los ajustes recargables y la limitación de dirección descrita aquí, y vale la pena leerla entera antes de rotar nada productivo.