Une paire de WAF en double machine tombe en panne de deux façons très différentes : le journal système avertit d'un heartbeat VRRP qui est en réalité une incohérence de configuration, pas un pair mort -- et un seul site protégé s'éteint alors que tous les autres sites de la même paire continuent de fonctionner normalement. Voici comment bien lire les deux, la checklist HA qui les prévient, et la correction exacte pour chacun.
Par Yuwen Zhang (Atlas), fondateur d'AtlasCommTech — 13 ans de déploiements de réseaux opérateurs et d'entreprise · Mis à jour en juillet 2026
L'une ressemble à un problème réseau et n'en est pas un ; l'autre semble isolée à un site et est en réalité un conflit d'adressage qui en couvre plusieurs.
Le hot standby en double machine sur un WAF est censé être ennuyeux -- un nœud actif, un en veille, une IP virtuelle qui se moque de savoir quel boîtier physique répond. En pratique, deux pannes expliquent la plupart des tickets : une entrée de journal système indiquant que le heartbeat VRRP entre la paire est anormal, qui ressemble à un problème réseau ou de câblage mais qui est presque toujours une incohérence de configuration de site protégé ; et un seul site en proxy inverse devenant inaccessible alors que ses voisins sur la même paire vont bien, ce qui remonte à un chevauchement d'adresse de lien plutôt qu'à un problème de HA lui-même.
Voici comment bien lire chacune d'elles, la checklist de configuration HA qu'il vaut la peine d'exécuter avant que l'une ou l'autre n'apparaisse, les pièges qui expliquent la plupart de ce qui ne va vraiment pas, et des réponses de FAQ tirées de cas de terrain.
Le HA en proxy transparent et le HA en proxy inverse ne négocient même pas sur la même interface -- les confondre gaspille les dix premières minutes de toute investigation.
Les deux modes de déploiement partagent une IP virtuelle et un rôle actif/veille, mais le chemin de heartbeat sous-jacent diffère : les paires en proxy transparent négocient via un port HA directement connecté sur le panneau, tandis que les paires en proxy inverse négocient plutôt via le port de gestion -- qui doit se trouver dans le même sous-réseau que son pair et être routable. Clarifier cela d'abord indique quelle interface vaut réellement la peine d'être dépannée.
Les légendes du schéma restent en anglais pour la clarté technique.
La seconde panne se situe entièrement en dessous de la couche HA : les sites protégés en proxy inverse portent chacun leurs propres adresses de lien front-end et back-end, et quand l'adresse de lien d'un nouveau site entre en collision avec celle d'un autre site -- ou avec l'adresse de diffusion de son propre sous-réseau -- le site concerné s'éteint tandis que la paire HA elle-même ne signale absolument rien d'anormal, car la relation de veille n'a en réalité rien de cassé.
Symptôme différent, endroit différent à examiner -- le message du journal et la portée affectée vous orientent immédiatement vers le bon.
En mode proxy inverse, cette ligne de journal précise n'est pas une alarme réseau -- c'est le WAF qui vous dit que les configurations de site protégé des deux nœuds ne correspondent pas.
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)Lorsqu'un seul site protégé est affecté, il s'agit d'un conflit d'adressage sur le lien de ce site, pas d'un problème de HA ou de règle de transfert.
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)Une fois que vous savez laquelle des deux pannes vous observez, celles-ci expliquent l'essentiel de ce qui ne va vraiment pas.
SYMPTÔMEJournal système : heartbeat VRRP anormal, en mode proxy inverse, alors que le lien HA lui-même semble aller bien.
CAUSELes configurations de site protégé des deux nœuds ne correspondent pas. Cliquer sur Appliquer les modifications sur un nœud déclenche une vérification par rapport à la configuration du pair, et toute différence enregistre exactement cette ligne -- c'est un détecteur d'écart de configuration, pas une vérification de vivacité du pair.
SOLUTIONSynchronisez la configuration complète depuis le bon nœud via Configuration > Synchronisation de configuration > Synchroniser le fichier de configuration, et prenez l'habitude de ne modifier les sites que sur un seul nœud.
SYMPTÔMEUn site protégé spécifique en proxy inverse est inaccessible ; tous les autres sites sur la même paire fonctionnent normalement.
CAUSELes adresses de lien en proxy inverse (front-end et back-end) doivent être uniques sur tous les sites protégés du boîtier. L'adresse de lien d'un nouveau site entrant en collision avec celle d'un site existant -- ou tombant sur l'adresse de diffusion propre du sous-réseau -- provoque un mauvais aiguillage silencieux sans aucune erreur dans la couche HA.
SOLUTIONVérifiez d'abord dans Configuration > Sites protégés les adresses de lien du site affecté par rapport à celles de tous les autres sites et à leur adresse de diffusion de sous-réseau, avant de chercher ailleurs.
Site A back-end link: 10.10.1.11
Site B back-end link: 10.10.1.11 // duplicate -> Site B silently unreachableSYMPTÔMELa négociation HA en proxy inverse signale une anomalie même si les configurations des deux nœuds « semblent identiques ».
CAUSELe double machine en proxy inverse exige une configuration de site protégé identique sur les deux nœuds, sauf le rôle VRRP. Le champ qui casse réellement les choses est l'ID de route virtuelle, qui doit être identique entre la paire pour le même site tandis que le rôle actif/secours diffère -- un ID de route virtuelle dupliqué entre différents sites sur le même appareil est un mode de défaillance distinct et silencieux.
SOLUTIONConfirmez que chaque site protégé a le VRRP activé, que le rôle actif/secours de chaque appareil est cohérent sur tous ses sites, et qu'aucun couple de sites sur le même appareil ne partage un ID de route virtuelle.
SYMPTÔMENégociation HA anormale, et l'interface vérifiée ne correspond pas au mode de déploiement.
CAUSELe heartbeat du double machine en proxy transparent négocie via le port HA directement connecté sur le panneau. Le heartbeat du double machine en proxy inverse négocie plutôt via le port de gestion, qui doit en outre se trouver dans le même sous-réseau que celui du pair et être routable -- dépanner le mauvais de ces deux-là gaspille du temps sur du câblage ou du routage qui n'a jamais été le problème.
SOLUTIONConfirmez d'abord le mode de déploiement, puis vérifiez l'interface correspondante : port HA pour le proxy transparent, joignabilité du port de gestion pour le proxy inverse.
SYMPTÔMENégociation HA en proxy transparent anormale, alors que les deux boîtiers sont individuellement configurés et semblent aller bien.
CAUSEUn appareil est réglé en mode dual-active tandis que l'autre attend toujours une relation primaire/secours -- ou les champs IP locale et IP du pair de la configuration HA ont été inversés d'un côté.
SOLUTIONConfirmez que les deux appareils sélectionnent le même mode (tous deux dual-active, ou un primaire plus un secours), et revérifiez l'attribution IP locale vs IP du pair de la page Configuration HA sur les deux nœuds.
Tirées de cas de terrain -- celles qui méritent une réponse toute prête.
Le double machine en proxy transparent négocie son heartbeat via un port HA directement connecté sur le panneau de l'appareil. Le double machine en proxy inverse négocie plutôt via le port de gestion, et ce port de gestion doit en outre être dans le même sous-réseau que celui du pair et réellement routable -- il n'est pas interchangeable avec le port HA utilisé en mode transparent.
Généralement non. En mode proxy inverse, ce message précis se déclenche lorsque le nœud sur lequel vous avez appliqué des modifications vérifie sa configuration de site protégé par rapport à celle du pair et trouve une incohérence -- c'est une alarme d'écart de configuration déguisée en avertissement de heartbeat. Synchronisez la configuration depuis le bon nœud via la synchronisation de configuration avant de supposer un problème de câblage ou de routage.
Presque jamais -- vérifiez si l'adresse de lien front-end ou back-end du nouveau site chevauche celle d'un site existant, ou l'adresse de diffusion de son sous-réseau. Cette collision provoque exactement ce schéma : un site précis s'éteint tandis que ses voisins, et la paire HA elle-même, semblent parfaitement normaux.
Vérifiez d'abord les journaux système à la recherche d'alarmes, puis confirmez que le nombre et le contenu des sites protégés correspondent entre la paire et que la synchronisation de configuration s'est réellement terminée. Dans Configuration > Sites protégés, confirmez que chaque site a le support VRRP activé, que le rôle actif/secours de chaque appareil est cohérent sur tous ses sites, et que les ID de route virtuelle ne sont pas dupliqués.
Confirmez que les deux appareils sont réglés sur le même mode -- soit tous deux dual-active, soit un primaire et un secours, pas une incohérence entre les deux. Vérifiez ensuite Configuration > Configuration HA sur les deux nœuds et confirmez que les champs IP d'interface sont corrects, en particulier que l'IP locale et l'IP du pair n'ont pas été inversées d'un côté ou de l'autre.
Cette note s'appuie sur le modèle de hot standby en double machine d'un boîtier WAF Huawei -- ses chemins de heartbeat via port HA / port de gestion, son basculement en proxy inverse basé sur VRRP, et le modèle de configuration de site protégé derrière les deux cas de terrain présentés ici. Si votre plateforme utilise un mécanisme HA différent, les chemins de menu exacts et les chaînes de journal changent, mais le schéma sous-jacent -- vérifier la synchronisation de configuration avant de supposer une panne réseau, et vérifier les collisions d'adressage avant de supposer une panne HA -- s'applique directement. Elle ne couvre pas les conceptions HA géographiquement dispersées (multi-sites), ni le clustering actif-actif au-delà du mode dual-active mentionné ci-dessus.
Indiquez-nous le message de journal exact ou quel site précis est affecté, ainsi que si vous êtes en mode transparent ou proxy inverse, et nous vous aiderons à cerner le problème.