La caída nunca fue lo que estaba depurando

Alrededor de la 01:45 el homelab se cayó — no fue solo un servicio, fueron todos. Este es el postmortem, incluyendo la parte donde mi primer intento de arreglo no funcionó y la razón por la que no lo hizo.

Lo que sospeché, en orden

Traefik. Todo pasa por ahí, así que que todo falle parece que el router falló. Estaba saludable.

CrowdSec. Un IPS al que recientemente le había puesto reglas más agresivas. Un baneo masivo se vería exactamente así. No había baneado nada relevante.

Authentik. Forward-auth está frente a la mayoría de los servicios internos, así que una caída de SSO también produce indisponibilidad total. También estaba saludable.

Tres causas plausibles, cada una de las cuales podría producir el síntoma observado, y las tres inocentes. Esa es la señal de que estás viendo la capa equivocada.

El workaround fallido

La resolución de nombres claramente estaba involucrada, así que intenté fijar DNS a un resolver conocido y funcional en vez de la IP virtual flotante. No funcionó.

La razón vale la pena documentarla: ejecuté el redirect sin root, así que el symlink del stub de systemd se mantuvo intacto y mi cambio fue silenciosamente un no-op. No marcó ningún error. El sistema simplemente siguió usando la ruta anterior. Pasé un buen rato re-verificando un arreglo que nunca se aplicó.

Segundo intento, ahora como root, fijó la resolución a la dirección real del host DNS primario y evitó por completo el VIP de keepalived. Eso restauró el servicio.

La causa raíz real

Un puerto de red se cayó a nivel de switch. No fue DNS, ni Traefik, ni CrowdSec, ni Authentik. El síntoma de DNS fue el más ruidoso porque la resolución de nombres falla rápido y todo lo demás falla detrás de eso.

Más tarde ese día confirmé que el VIP y el host DNS primario compartían la misma MAC, lo que probó que keepalived seguía siendo dueño de la dirección correctamente — la capa de HA había estado haciendo su trabajo todo el tiempo. No podía enrutar alrededor de un enlace físico muerto, que no es para lo que está hecho.

El seguimiento que dolió

Uno de los pendientes que me dejé fue: ¿el monitoreo alertó sobre esto en algún momento? Si no, agrega un check.

Tengo un dashboard, un monitor de uptime, un stack de métricas, un agregador de logs y un servicio de notificaciones push. Me enteré de una caída total intentando usar algo. Cubrir servicios no es cubrir la capa debajo de ellos.

Lo que me llevo de esto

• Lo que sospechas primero usualmente está aguas abajo de lo que realmente se rompió. Tres sospechosos saludables seguidos es información: deja de investigar y empieza a bajar de capa.
• Verifica que tu arreglo se haya aplicado antes de evaluar si funcionó. Un no-op silencioso cuesta más que un fallo ruidoso.
• El postmortem mantiene el intento fallido. Limpiar eso haría un documento más ordenado y uno menos útil.