Falhas de alta disponibilidade do WAF: heartbeat VRRP e sites inacessíveis
Um par de WAF em dupla máquina falha de duas maneiras muito diferentes: o log do sistema avisa sobre um heartbeat VRRP que na verdade é uma incompatibilidade de configuração, não um par morto -- e um único site protegido fica inativo enquanto todos os outros sites do mesmo par continuam funcionando bem. Aqui está como interpretar corretamente os dois, a checklist de HA que os previne, e a correção exata para cada um.
Por Atlas Yuwen Zhang, fundador da AtlasCommTech — 18 anos em ICT, 13 deles em redes de operadoras · Atualizado em julho de 2026
Duas falhas, duas formas de falha diferentes
Uma parece um problema de rede e não é; a outra parece isolada a um site e na verdade é um conflito de endereçamento que abrange vários.
O hot standby em dupla máquina em um WAF deveria ser tedioso -- um nó ativo, um em espera, um IP virtual que não se importa com qual caixa física responde. Na prática, duas falhas respondem pela maioria dos chamados: uma entrada de log do sistema dizendo que o heartbeat VRRP entre o par está anormal, que soa como um problema de rede ou cabeamento mas quase sempre é uma incompatibilidade de configuração de site protegido; e um único site de proxy reverso ficando inacessível enquanto seus vizinhos no mesmo par estão bem, o que remonta a uma sobreposição de endereço de link em vez de algo errado no próprio HA.
A seguir está como interpretar corretamente cada uma delas, a checklist de configuração de HA que vale a pena executar antes que qualquer uma delas apareça, as armadilhas que respondem pela maior parte do que realmente está errado, e respostas de perguntas frequentes tiradas de casos de campo.
Leia a topologia ativo/em espera antes de correr atrás de um cabo
O HA de proxy transparente e o HA de proxy reverso nem sequer negociam pela mesma interface -- confundi-los desperdiça os primeiros dez minutos de qualquer investigação.
Ambos os modos de implantação compartilham um IP virtual e um papel ativo/em espera, mas o caminho de heartbeat subjacente é diferente: pares de proxy transparente negociam por uma porta HA diretamente conectada no painel, enquanto pares de proxy reverso negociam pela porta de gerenciamento -- que precisa estar na mesma sub-rede do par e ser roteável. Esclarecer isso primeiro indica qual interface realmente vale a pena investigar.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
A segunda falha fica inteiramente abaixo da camada de HA: os sites protegidos de proxy reverso carregam cada um seus próprios endereços de link front-end e back-end, e quando o endereço de link de um novo site colide com o de outro site -- ou com o endereço de broadcast de sua própria sub-rede -- o site afetado fica inativo enquanto o próprio par de HA não relata nada de errado, porque nada na relação de espera realmente quebrou.
Percorrendo as duas falhas
Sintoma diferente, lugar diferente a verificar -- a mensagem de log e o escopo afetado apontam imediatamente para a certa.
Falha 1 -- Log do sistema: “heartbeat VRRP anormal”
No modo de proxy reverso, essa linha de log específica não é um alarme de rede -- é o WAF dizendo que as configurações de site protegido dos dois nós não coincidem.
- Leia o log no contexto: ele aparece no modo de proxy reverso quando o nó em que você clicou em “Aplicar alterações” verifica se sua própria configuração de site protegido existe no par, e encontra pelo menos uma incompatibilidade.
- Identifique qual nó atualmente possui a configuração de site protegido completa e correta -- geralmente aquele editado mais recentemente.
- A partir desse nó, vá em Configuração > Sincronização de configuração > Sincronizar arquivo de configuração e envie a configuração para o par.
- Daqui em diante, faça alterações de site protegido apenas em um nó e sincronize imediatamente -- não edite os dois lados de forma independente contando com a etapa de sincronização para reconciliá-los depois.
- Se o alarme persistir após uma sincronização, reverifique se ambos os dispositivos estão no mesmo modo de HA (ambos dual-active, ou um primário e um backup) e se cada site tem o suporte VRRP habilitado com IDs de rota virtual coincidentes.
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)Falha 2 -- Um site de proxy reverso caiu, o resto está bem
Quando apenas um site protegido é afetado, é um conflito de endereçamento no link daquele site, não um problema de HA ou regra de encaminhamento.
- Abra Configuração > Sites protegidos e compare os endereços de link front-end e back-end do site afetado com os de todos os outros sites, e com o endereço de broadcast de sua sub-rede.
- Se uma sobreposição for encontrada, reatribua ao site afetado um endereço de link que não colida com nenhum outro site ou com o endereço de broadcast dessa sub-rede.
- Se o endereçamento parecer limpo, capture pacotes em três interfaces ao mesmo tempo: a interface de loopback (endereço do lado do servidor), a interface de link front-end do site, e a interface de link back-end do site.
- Compare a solicitação HTTP do cliente capturada na interface front-end com o que o WAF realmente encaminha na interface back-end para a mesma solicitação -- uma incompatibilidade aponta para o próprio processamento do WAF, não para a rede.
- Se a solicitação foi encaminhada corretamente, verifique se o servidor alguma vez responde: nenhuma resposta significa um problema de conectividade WAF-servidor; um RST do servidor significa que o próprio servidor está recusando a conexão; um RST do WAF de volta ao cliente (sem RST do servidor) significa que as próprias regras do WAF estão bloqueando.
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)Cinco armadilhas que aparecem repetidamente
Depois de saber qual das duas falhas você está vendo, estas respondem pela maior parte do que realmente está errado.
1. Um alarme de “heartbeat” que na verdade é uma lacuna de sincronização de configuração
SINTOMALog do sistema: heartbeat VRRP anormal, no modo de proxy reverso, com o link de HA aparentemente bem.
CAUSAAs configurações de site protegido dos dois nós não coincidem. Clicar em Aplicar alterações em um nó dispara uma verificação contra a configuração do par, e qualquer diferença registra exatamente essa linha -- é um detector de diferença de configuração, não uma checagem de atividade do par.
SOLUÇÃOSincronize a configuração completa a partir do nó correto via Configuração > Sincronização de configuração > Sincronizar arquivo de configuração, e crie o hábito de editar sites em apenas um nó.
2. O IP de link front-end/back-end sobrepõe silenciosamente outro site -- ou o endereço de broadcast
SINTOMAUm site protegido específico de proxy reverso está inacessível; todos os outros sites no mesmo par funcionam normalmente.
CAUSAOs endereços de link de proxy reverso (front-end e back-end) precisam ser únicos em todos os sites protegidos no dispositivo. O endereço de link de um novo site colidindo com o de um site existente -- ou caindo no próprio endereço de broadcast da sub-rede -- causa desvio silencioso sem nenhum erro na camada de HA.
SOLUÇÃOAudite Configuração > Sites protegidos comparando os endereços de link do site afetado com os de todos os outros sites e seu endereço de broadcast de sub-rede, antes de olhar em qualquer outro lugar.
Site A back-end link: 10.10.1.11
Site B back-end link: 10.10.1.11 // duplicate -> Site B silently unreachable3. Tudo deve coincidir exceto o papel VRRP -- e o ID de rota virtual é o que as pessoas invertem
SINTOMAA negociação de HA de proxy reverso reporta anormal mesmo que as configurações dos dois nós “pareçam iguais”.
CAUSAO dual machine de proxy reverso exige configuração de site protegido idêntica em ambos os nós, exceto o papel VRRP. O campo que realmente quebra as coisas é o ID de rota virtual, que precisa ser idêntico entre o par para o mesmo site enquanto o papel ativo/backup difere -- um ID de rota virtual duplicado entre sites diferentes no mesmo dispositivo é um modo de falha separado e silencioso.
SOLUÇÃOConfirme que cada site protegido tem VRRP habilitado, que o papel ativo/backup de cada dispositivo é consistente em todos os seus sites, e que nenhum par de sites no mesmo dispositivo compartilha um ID de rota virtual.
4. Os heartbeats de proxy transparente e proxy reverso não usam a mesma interface
SINTOMANegociação de HA anormal, e a interface sendo verificada não coincide com o modo de implantação.
CAUSAO heartbeat do dual machine em proxy transparente negocia pela porta HA diretamente conectada no painel. O heartbeat do dual machine em proxy reverso negocia pela porta de gerenciamento, que além disso precisa estar na mesma sub-rede do par e ser roteável -- resolver o errado desses dois desperdiça tempo em cabeamento ou roteamento que nunca foi o problema.
SOLUÇÃOConfirme primeiro o modo de implantação, depois verifique a interface correspondente: porta HA para proxy transparente, alcançabilidade da porta de gerenciamento para proxy reverso.
5. Os modos dual-active e primário/backup não coincidem entre as duas caixas
SINTOMANegociação de HA de proxy transparente anormal, com ambas as caixas configuradas individualmente e aparentemente bem.
CAUSAUm dispositivo está configurado em modo dual-active enquanto o outro ainda espera uma relação primário/backup -- ou os campos de IP local e IP do par da configuração de HA foram inseridos ao contrário em um dos lados.
SOLUÇÃOConfirme que ambos os dispositivos selecionam o mesmo modo (ambos dual-active, ou um primário mais um backup), e reverifique a atribuição de IP local versus IP do par na página de Configuração de HA em ambos os nós.
Projetos de soluções relacionadas
Cinco perguntas que surgem constantemente
Tiradas de casos de campo -- as que vale a pena ter uma resposta pronta.
Qual é a diferença real no caminho de heartbeat entre o HA de proxy transparente e o HA de proxy reverso?
O dual machine de proxy transparente negocia seu heartbeat por uma porta HA diretamente conectada no painel do dispositivo. O dual machine de proxy reverso negocia pela porta de gerenciamento, e essa porta de gerenciamento além disso precisa estar na mesma sub-rede do par e ser realmente roteável -- não é intercambiável com a porta HA usada no modo transparente.
O log do sistema diz heartbeat VRRP anormal -- isso significa que o link entre os dois WAFs realmente caiu?
Geralmente não. No modo de proxy reverso, essa mensagem específica dispara quando o nó em que você aplicou alterações verifica sua configuração de site protegido contra a do par e encontra uma incompatibilidade -- é um alarme de diferença de configuração disfarçado de aviso de heartbeat. Sincronize a configuração a partir do nó correto via Sincronização de configuração antes de supor que há um problema de cabeamento ou roteamento.
Adicionamos um novo site protegido e agora um site diferente e não relacionado parou de funcionar -- isso é uma falha de HA?
Quase nunca -- verifique se o endereço de link front-end ou back-end do novo site sobrepõe o de um site existente, ou o endereço de broadcast de sua sub-rede. Essa colisão causa exatamente esse padrão: um site específico fica inativo enquanto seus vizinhos, e o próprio par de HA, parecem completamente normais.
Dois WAFs em modo de proxy reverso, a negociação primário/backup reporta anormal -- o que verifico primeiro?
Primeiro verifique os logs do sistema em busca de alarmes, depois confirme que o número e o conteúdo dos sites protegidos coincidem entre o par e que a sincronização de configuração realmente foi concluída. Em Configuração > Sites protegidos, confirme que cada site tem o suporte VRRP habilitado, que o papel ativo/backup de cada dispositivo é consistente em todos os seus sites, e que os IDs de rota virtual não estão duplicados.
Dois WAFs em modo de proxy transparente, a negociação reporta anormal -- o que verifico primeiro?
Confirme que ambos os dispositivos estão configurados no mesmo modo -- ambos dual-active, ou um primário e um backup, não uma incompatibilidade entre os dois. Depois verifique Configuração > Configuração de HA em ambos os nós e confirme que os campos de IP de interface estão corretos, especificamente que o IP local e o IP do par não foram inseridos ao contrário em nenhum dos lados.
Limites honestos desta nota
Esta nota se baseia no modelo de hot standby em dupla máquina de um appliance WAF Huawei -- seus caminhos de heartbeat de porta HA / porta de gerenciamento, seu failover de proxy reverso baseado em VRRP, e o modelo de configuração de site protegido por trás dos dois casos de campo aqui. Se sua plataforma usa um mecanismo de HA diferente, os caminhos de menu exatos e as strings de log mudam, mas o padrão subjacente -- verificar a sincronização de configuração antes de supor uma falha de rede, e checar colisões de endereçamento antes de supor uma falha de HA -- se aplica diretamente. Não cobre projetos de HA geograficamente dispersos (entre sites), nem clustering ativo-ativo além do modo dual-active mencionado acima.
Referências
Normas e documentos do fabricante em que esta nota se baseia. A sintaxe dos comandos segue a documentação do fabricante; verifique o comportamento exato na sua versão de firmware.
Não tem certeza de qual das duas falhas você está vendo?
Conte-nos a mensagem de log exata ou qual site específico está afetado, além de se você está em modo transparente ou de proxy reverso, e ajudamos você a restringir isso.