Lista de bloqueo de Nebula: distribúyela, el faro no lo hará

La aplicación de la lista de bloqueo es una propiedad del host que hace la comprobación, no del certificado que se comprueba. Una máquina que nunca cargó la entrada sigue aceptando la identidad, y nada en el saludo inicial le advierte de que dos pares no están de acuerdo. La solución barata y la solución cara para una credencial expuesta difieren en alcance y en reversibilidad, así que elija a conciencia. Las secciones siguientes cubren qué hace la entrada, dónde hay que entregarla, cuándo la rotación es la mejor respuesta y cómo demostrar que cualquiera de las dos funcionó.

Qué hace realmente una entrada de la lista de bloqueo

La configuración de PKI enumera huellas que un host debe rechazar aunque el certificado esté firmado válidamente y no haya caducado. La aplicación ocurre localmente, contra la lista que ese host cargó al iniciarse el servicio. Nada de la entrada viaja dentro del certificado, así que un par no puede aprender la decisión de la credencial que se le muestra. Por eso un faro no desempeña ningún papel aquí: los faros ayudan a los pares a encontrarse y a retransmitir tráfico donde falla una ruta directa. Son una capa de descubrimiento y retransmisión, no un canal de distribución de configuración.

Actualizar una máquina cambia las decisiones de esa máquina y deja a cada otro par exactamente como estaba. Un par que confía en la autoridad de firma y nunca vio la entrada no tiene motivo para rechazar nada. Por tanto, probar la revocación observando el faro no demuestra nada, porque al componente que observa nunca se le pidió aplicar la lista.

Identifique el certificado, no el dispositivo

Use la huella de la credencial que pretende rechazar, porque un nombre de host, una etiqueta de dispositivo o una dirección actual identifican una máquina hoy y otra cosa el mes que viene. Ninguna de esas cadenas aparece en la lista de bloqueo, y ninguna sobrevive a una reinstalación. Imprima el certificado, lea la huella y compruebe que pertenece a la credencial que se retira y no a su reemplazo. Leer ambos archivos importa cuando ya se emitió un reemplazo, ya que el certificado viejo y el nuevo pueden compartir nombre y diferir en todos los demás campos.

Registre qué huella se bloqueó y cuándo, para que una auditoría posterior separe un cambio completado de uno previsto. Fíjese también en lo que la entrada no hace: no invalida la autoridad de firma y no impide que se acepte un certificado futuro de esa autoridad. Bloquear el certificado de un host y reemplazar una autoridad comprometida son operaciones distintas con consecuencias distintas.

nebula-cert print -path /etc/nebula/host.crt
pki:
  blocklist:
    - "a1b2c3d4e5f6"

Distribúyela como cualquier otra configuración

Trate la lista como configuración con un mecanismo de entrega y no como un archivo que alguien edita cuando se acuerda. Empuje la lista completa en lugar de un delta, para que un host que se perdió una actualización anterior converja en vez de acumular huecos. La documentación de Nebula PKI recomienda exactamente eso, y vale la pena seguir el consejo al pie de la letra en lugar de convertirlo en un proceso manual.

Confirme que el servicio en ejecución recargó el contenido, no solo que el archivo del disco cambió. Siga qué máquinas aplicaron el cambio y mantenga visible la lista pendiente hasta que quede vacía. Un portátil cerrado una semana es un par que nunca aprendió la decisión, y puede reconectarse desde una red que nadie esperaba. Registre el método de entrega junto a la huella, porque la siguiente revocación lo reutiliza y es en la primera donde se depura el proceso.

Lista de bloqueo o rotación de la autoridad

Una entrada de la lista de bloqueo es estrecha: una identidad deja de funcionar y todo lo demás continúa. Rotar la autoridad de firma es amplio: cada certificado que emitió deja de ser de confianza, y cada host necesita una credencial nueva y un ancla de confianza nueva. La primera es una revocación dirigida y la segunda es una migración, así que necesitan aprobaciones distintas y ventanas de mantenimiento distintas. La tabla pone las dos lado a lado en alcance, esfuerzo y reversibilidad.

Un portátil perdido pide la lista de bloqueo, porque el radio de impacto es una identidad y el cambio es reversible si bloqueó la huella equivocada. Una clave de autoridad filtrada pide rotación, porque la lista de bloqueo no puede ayudar con certificados que aún no se emitieron. Entre esos extremos, pregunte si la credencial expuesta podría haber firmado algo más, ya que una autoridad es más de un host.

Escriba la decisión antes de un incidente, porque elegir bajo presión tiende a producir por defecto la opción amplia. Sea cual sea el camino que tome, el elemento de trabajo restante es idéntico: demostrar que la aplicación ocurrió en los hosts que importan. Registrar la huella y la fecha en ese momento es lo que hace posible la prueba más adelante.

Verifique el rechazo y el resto

Conéctese desde la identidad bloqueada y confirme el fallo, luego conéctese desde un par autorizado y confirme que sigue alcanzando lo que necesita. Un cambio que rompe a todos no es una revocación exitosa. Haga ambas cosas desde sesiones nuevas, porque el estado en caché puede ocultar el resultado.

Compruebe si una sesión establecida termina después del cambio, y anote el comportamiento para su versión y configuración en lugar de suponer que editar un archivo termina algo. La opción disconnect_invalid cubre a los clientes cuyos certificados han caducado o son inválidos, así que confirme cómo se aplica a su caso antes de confiar en ella. Si la terminación inmediata es un requisito, pruébelo específicamente y anote lo que observó. Luego repita la prueba después de un reinicio, porque un host que solo aplica la lista hasta su próximo arranque tiene un problema de entrega que la primera prueba ocultó. Un faro sano le dice que el descubrimiento funciona, no que algún par haya aplicado una política.