Operación

Drill de failover trimestral#

El propósito completo de un setup HA dual-provider es que el failover funcione cuando el uplink primario cae de verdad. La única forma de confiar en eso es probarlo deliberadamente.

Cadencia sugerida: trimestral, durante una ventana de tráfico bajo, con el operador en la consola.

Procedimiento:

1. Anunciar el drill en el canal del equipo — el failover debe ser invisible, pero si algo va mal, quieres saberlo de inmediato.
2. Deshabilitar el uplink primario a nivel de interfaz (no en el módem del proveedor — eso simula el modo de fallo equivocado).
3. En menos de cinco segundos, el monitor de failover debería conmutar la ruta por defecto al uplink secundario.
4. Verificar alcanzabilidad externa: una petición desde una zona debería seguir resolviendo, descargando y volviendo.
5. Rehabilitar el uplink primario.
6. El monitor debería restaurar la ruta por defecto al primario dentro de su intervalo configurado.
7. Registrar el drill en un logbook: fecha, time-to-detect, time-to-recover, cualquier cosa inusual.

Si el failover lleva más tiempo del esperado, hay que ajustar el intervalo de chequeo o los umbrales del monitor. Si el failover no ocurre en absoluto, la configuración del monitor está rota — arréglala antes de irte a casa. Un monitor de failover no funcional es peor que ningún monitor; le da al operador falsa confianza.

Revisión de logs#

Tres flujos de logs importan:

• Eventos del firewall. Decisiones de drop, adiciones a la tabla, estado NAT. Ruidoso durante escaneos de reconocimiento, silencioso bajo carga normal.
• Eventos de offloading SSL. Errores de terminación, fallos de validación de certificados, veredictos del scanner. Picos aquí significan que algo cambió — una rotación de certificado río arriba, un cliente nuevo que no confía en la raíz CA interna o un patrón de malware que esquivó un filtro previo.
• Eventos del monitor de failover. Transiciones de enlace. Debería estar vacío la mayoría de semanas. Transiciones frecuentes apuntan a un uplink inestable — plantéalo con la operadora.

Hábito de operador sugerido: un scaneo semanal de quince minutos de estos tres flujos. Marcar lo inusual, abrir tickets de seguimiento para la próxima revisión trimestral.

Verificación de fronteras de zonas#

Las zonas se definen en el ruleset. El ruleset puede ser incorrecto. La forma de saber cuál es cierto es probar.

Cadencia sugerida: cada seis meses, o tras cualquier cambio significativo del ruleset.

Para cada par de zonas (Clientes ↔ DMZ, Clientes ↔ VPN, Anonimización ↔ todo lo demás, etc.):

1. Desde un host en la zona A, intentar alcanzar un servicio en la zona B que no se supone alcanzable.
2. Confirmar que la conexión falla — TCP RST, ICMP unreachable o timeout, según el tipo de regla.
3. Registrar el resultado en el mismo logbook.

Si cualquier ruta esperada como bloqueada es alcanzable, eso es un bug de regla. Corregir el mismo día.

Mantenimiento de la blocklist#

Las tablas de blocklist crecen con el tiempo. Dos modos de fallo comunes:

• Entradas obsoletas. Una IP que era abusiva hace seis meses hoy es una línea DSL residencial con nuevo propietario. La rotación periódica del fichero blocklist (ver docs configuración de Abusive HTTP Watch) acota esto.
• Drift de whitelist. Los rangos de IP de oficina y VPN cambian con el tiempo. Las entradas obsoletas de whitelist no causan incidentes directamente, pero reducen el valor de la whitelist como control. Revisar el fichero whitelist cada trimestre.

Rotación de certificados#

La capa de terminación TLS usa certificados emitidos por la Sovereign Certificate Authority. La rotación es automática vía ACME, pero:

• Confirmar la rotación al menos mensualmente — openssl s_client contra el gateway, verificar que el notAfter del certificado está en el futuro, verificar que la cadena sigue validando contra la raíz interna.
• Probar la confianza del cliente tras cualquier cambio del lado de la CA — elegir un cliente representativo de cada zona, navegar a un servicio HTTPS dentro de la red, confirmar que no aparece aviso de certificado.

Modo de fallo: una rotación tiene éxito del lado de la CA pero el firewall no recoge el certificado nuevo (recarga de config faltante, permisos de fichero incorrectos). El cert previo sigue válido un rato, enmascarando el bug. La verificación mensual lo detecta.

Mantenimiento rutinario#

• Parches OS. Aplicar parches relevantes para seguridad dentro de la ventana recomendada por el vendor. Reiniciar — el firewall no es una appliance estilo cattle, pero uptime más allá de nueve meses invita a problemas.
• Revisión de dependencias. Los daemons Tor, I2P, Squid y Privoxy tienen cada uno su ciclo de parcheo. Seguir releases upstream.
• Chequeo de capacidad. Llenado de la tabla de estado, CPU en pico, headroom de memoria. El firewall debería funcionar cómodamente por debajo de la mitad de su capacidad. Si no, planificar la próxima renovación de hardware.

Cuando algo se rompe#

El hábito de operador más útil: anotar lo que pasó.

Una nota corta por incidente — cuándo, qué viste, qué cambiaste, qué funcionó, qué no — convierte un evento en una mejora permanente. La próxima vez que aparezca el mismo patrón, o la misma persona o su sucesor lo resuelve en minutos en vez de horas.

Si el incidente excede la experiencia o tiempo disponible de tu equipo, el servicio Operación es la ruta de escalado.