# OperaciónOperar el firewall en producción: drills de failover, revisión de logs, pruebas de fronteras, mantenimiento.

## 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](../../abusive-http-watch/configuration/)) 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](../../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/services/support/) es la ruta
de escalado.