Un par de WAF en doble máquina falla de dos formas muy distintas: el registro del sistema advierte de un heartbeat VRRP que en realidad es una discrepancia de configuración, no un par caído -- y un solo sitio protegido se apaga mientras todos los demás sitios del mismo par siguen funcionando bien. Aquí se explica cómo interpretar correctamente ambos, la lista de verificación de HA que los previene, y la corrección exacta para cada uno.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
Una parece un problema de red y no lo es; la otra parece aislada a un sitio y en realidad es un conflicto de direccionamiento que abarca varios.
El hot standby en doble máquina en un WAF se supone que debe ser aburrido -- un nodo activo, uno en espera, una IP virtual a la que no le importa qué caja física responde. En la práctica, dos fallas explican la mayoría de los casos: una entrada de registro del sistema que indica que el heartbeat VRRP entre el par es anormal, que se lee como un problema de red o cableado pero casi siempre es una discrepancia de configuración de sitio protegido; y un solo sitio de proxy inverso que se vuelve inaccesible mientras sus vecinos en el mismo par están bien, lo que se remonta a una superposición de dirección de enlace en lugar de algo mal en el HA en sí.
A continuación, cómo interpretar correctamente cada una, la lista de verificación de configuración de HA que vale la pena ejecutar antes de que aparezca cualquiera de las dos, los problemas que explican la mayor parte de lo que realmente está mal, y respuestas de preguntas frecuentes extraídas de casos de campo.
El HA de proxy transparente y el HA de proxy inverso ni siquiera negocian por la misma interfaz -- confundirlos desperdicia los primeros diez minutos de cualquier investigación.
Ambos modos de despliegue comparten una IP virtual y un rol activo/en espera, pero la ruta de heartbeat subyacente es diferente: los pares de proxy transparente negocian a través de un puerto HA directamente conectado en el panel, mientras que los pares de proxy inverso negocian en cambio a través del puerto de gestión -- que debe estar en la misma subred que su par y ser enrutable. Aclarar esto primero indica qué interfaz realmente vale la pena investigar.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
La segunda falla se sitúa completamente por debajo de la capa de HA: los sitios protegidos de proxy inverso llevan cada uno sus propias direcciones de enlace de front-end y back-end, y cuando la dirección de enlace de un nuevo sitio colisiona con la de otro sitio -- o con la dirección de difusión de su propia subred -- el sitio afectado se apaga mientras el propio par de HA no reporta nada anormal, porque la relación de espera en realidad no se rompió.
Síntoma diferente, lugar diferente a revisar -- el mensaje del registro y el alcance afectado lo orientan de inmediato hacia el correcto.
En modo de proxy inverso, esta línea de registro específica no es una alarma de red -- es el WAF diciéndole que las configuraciones de sitio protegido de los dos nodos no coinciden.
System log (reverse-proxy mode):
VRRP peer heartbeat abnormal
// this line fires when "Apply Changes" finds a protected-site mismatch
// with the peer -- it is a config-diff alarm, not a link-down alarm
Fix:
Configuration > Configuration Sync > Sync Config File
(run from the node with the complete / correct site configuration)Cuando solo un sitio protegido se ve afectado, es un conflicto de direccionamiento en el enlace de ese sitio, no un problema de HA o de regla de reenvío.
Config check: Configuration > Protected Sites
Site A front-end link: 10.10.0.11 back-end link: 10.10.1.11
Site B front-end link: 10.10.0.12 back-end link: 10.10.1.11 // <- collides with Site A
// overlapping back-end link address -> Site B silently unreachable, Site A unaffected
Packet capture interfaces:
Lo -> server-side address
site front-end interface -> link address (front-end)
site back-end interface -> link address (back-end)Una vez que sabe cuál de las dos fallas está viendo, estas explican la mayor parte de lo que realmente está mal.
SÍNTOMARegistro del sistema: heartbeat VRRP anormal, en modo de proxy inverso, con el enlace de HA aparentemente bien.
CAUSALas configuraciones de sitio protegido de los dos nodos no coinciden. Hacer clic en Aplicar cambios en un nodo desencadena una verificación contra la configuración del par, y cualquier diferencia registra exactamente esta línea -- es un detector de diferencias de configuración, no una comprobación de actividad del par.
SOLUCIÓNSincronice la configuración completa desde el nodo correcto mediante Configuración > Sincronización de configuración > Sincronizar archivo de configuración, y adquiera el hábito de editar sitios solo en un nodo.
SÍNTOMAUn sitio protegido específico de proxy inverso es inaccesible; todos los demás sitios en el mismo par funcionan normalmente.
CAUSALas direcciones de enlace de proxy inverso (front-end y back-end) deben ser únicas en todos los sitios protegidos del equipo. Que la dirección de enlace de un sitio nuevo colisione con la de uno existente -- o caiga en la propia dirección de difusión de la subred -- causa un desvío silencioso sin ningún error en la capa de HA.
SOLUCIÓNAudite Configuración > Sitios protegidos comparando las direcciones de enlace del sitio afectado con las de todos los demás sitios y su dirección de difusión de subred, antes de mirar en otro lado.
Site A back-end link: 10.10.1.11
Site B back-end link: 10.10.1.11 // duplicate -> Site B silently unreachableSÍNTOMALa negociación de HA de proxy inverso reporta anormal aunque las configuraciones de los dos nodos “se ven iguales”.
CAUSAEl doble máquina de proxy inverso requiere una configuración de sitio protegido idéntica en ambos nodos, excepto el rol VRRP. El campo que realmente rompe las cosas es el ID de ruta virtual, que debe ser idéntico entre el par para el mismo sitio mientras que el rol activo/respaldo difiere -- un ID de ruta virtual duplicado entre distintos sitios en el mismo dispositivo es un modo de falla separado y silencioso.
SOLUCIÓNConfirme que cada sitio protegido tiene VRRP habilitado, que el rol activo/respaldo de cada dispositivo es consistente en todos sus sitios, y que ningún par de sitios en el mismo dispositivo comparte un ID de ruta virtual.
SÍNTOMANegociación de HA anormal, y la interfaz que se está revisando no coincide con el modo de despliegue.
CAUSAEl heartbeat del doble máquina en proxy transparente negocia a través del puerto HA directamente conectado en el panel. El heartbeat del doble máquina en proxy inverso negocia en cambio a través del puerto de gestión, que además debe estar en la misma subred que la del par y ser enrutable -- resolver el equivocado de estos dos desperdicia tiempo en cableado o enrutamiento que nunca fue el problema.
SOLUCIÓNConfirme primero el modo de despliegue, luego verifique la interfaz correspondiente: puerto HA para proxy transparente, alcanzabilidad del puerto de gestión para proxy inverso.
SÍNTOMANegociación de HA de proxy transparente anormal, con ambos equipos configurados individualmente y aparentemente bien.
CAUSAUn dispositivo está configurado en modo dual-active mientras que el otro todavía espera una relación primario/respaldo -- o los campos de IP local e IP del par de la configuración de HA se han introducido al revés en un lado.
SOLUCIÓNConfirme que ambos dispositivos seleccionan el mismo modo (ambos dual-active, o uno primario más uno de respaldo), y vuelva a comprobar la asignación de IP local frente a IP del par en la página de Configuración de HA en ambos nodos.
Extraídas de casos de campo -- las que vale la pena tener respondidas de antemano.
El doble máquina de proxy transparente negocia su heartbeat a través de un puerto HA directamente conectado en el panel del dispositivo. El doble máquina de proxy inverso negocia en cambio a través del puerto de gestión, y ese puerto de gestión además debe estar en la misma subred que la del par y ser realmente enrutable -- no es intercambiable con el puerto HA usado en modo transparente.
Generalmente no. En modo de proxy inverso, este mensaje específico se dispara cuando el nodo en el que aplicó cambios verifica su configuración de sitio protegido contra la del par y encuentra una discrepancia -- es una alarma de diferencia de configuración disfrazada de advertencia de heartbeat. Sincronice la configuración desde el nodo correcto mediante Sincronización de configuración antes de suponer que hay un problema de cableado o enrutamiento.
Casi nunca -- verifique si la dirección de enlace front-end o back-end del nuevo sitio se superpone con la de un sitio existente, o con la dirección de difusión de su subred. Esa colisión causa exactamente este patrón: un sitio específico se apaga mientras sus vecinos, y el propio par de HA, se ven completamente normales.
Primero revise los registros del sistema en busca de alarmas, luego confirme que el número y contenido de los sitios protegidos coinciden entre el par y que la sincronización de configuración realmente se completó. En Configuración > Sitios protegidos, confirme que cada sitio tiene el soporte VRRP habilitado, que el rol activo/respaldo de cada dispositivo es consistente en todos sus sitios, y que los ID de ruta virtual no están duplicados.
Confirme que ambos dispositivos están configurados en el mismo modo -- ambos dual-active, o uno primario y uno de respaldo, no una discrepancia entre los dos. Luego revise Configuración > Configuración de HA en ambos nodos y confirme que los campos de IP de interfaz son correctos, específicamente que la IP local y la IP del par no se hayan introducido al revés en ningún lado.
Esta nota se basa en el modelo de hot standby en doble máquina de un equipo WAF Huawei -- sus rutas de heartbeat de puerto HA / puerto de gestión, su failover de proxy inverso basado en VRRP, y el modelo de configuración de sitio protegido detrás de ambos casos de campo aquí. Si su plataforma usa un mecanismo de HA diferente, las rutas de menú exactas y las cadenas de registro cambian, pero el patrón subyacente -- verificar la sincronización de configuración antes de suponer una falla de red, y comprobar colisiones de direccionamiento antes de suponer una falla de HA -- se traslada directamente. No cubre diseños de HA geográficamente dispersos (entre sitios), ni clustering activo-activo más allá del modo dual-active mencionado arriba.
Cuéntenos el mensaje de registro exacto o qué sitio específico está afectado, además de si está en modo transparente o de proxy inverso, y le ayudamos a acotarlo.