Redondance de passerelle : HSRP, VRRP, CARP et keepalived

Un protocole de redondance de passerelle (FHRP, First Hop Redundancy Protocol) permet à deux routeurs, deux pare-feu ou deux serveurs de partager une adresse IP virtuelle : l'un la porte, l'autre la reprend automatiquement en quelques secondes s'il tombe. HSRP (propriétaire Cisco), VRRP (le standard), CARP (pfSense, OPNsense) et keepalived (un logiciel Linux qui implémente VRRP) reposent tous sur ce principe. Ce chapitre explique le mécanisme commun, puis la configuration de chacun, et les réglages qui font une bascule propre : priorité, préemption et suivi.

Le problème : une passerelle, un SPOF

Chaque poste du VLAN 10 de Ravelle Conseil reçoit par DHCP une seule passerelle par défaut, 10.10.10.254. Dès qu'il veut joindre une machine d'un autre réseau (un serveur du VLAN 20, Internet), il envoie ses trames à l'adresse MAC de cette passerelle. Si l'équipement qui porte 10.10.10.254 tombe, plus aucun poste ne sort de son réseau, même si un second routeur est branché à côté.

Configurer deux passerelles sur les postes ne résout rien : un poste utilise sa passerelle par défaut tant qu'elle répond à ARP, et les mécanismes de détection de passerelle morte des systèmes sont lents et peu fiables. La solution consiste à faire porter l'adresse de passerelle par un groupe d'équipements plutôt que par un seul.

Le principe commun : une adresse virtuelle partagée

Tous les protocoles de ce chapitre fonctionnent de la même façon :

1. Chaque équipement garde sa propre adresse (ici 10.10.10.252 et 10.10.10.253), qui sert à l'administrer.
2. Le groupe partage une adresse IP virtuelle (VIP, ici 10.10.10.254) et une adresse MAC virtuelle, dérivée du numéro de groupe. C'est la VIP que les postes reçoivent comme passerelle.
3. Une élection désigne l'équipement actif, celui qui a la plus haute priorité (à égalité, la plus haute adresse IP). Lui seul répond aux requêtes ARP pour la VIP et transmet le trafic.
4. L'actif annonce régulièrement qu'il est vivant, par des messages envoyés en multidiffusion sur le réseau.
5. Si les annonces cessent pendant un délai donné, le secours se déclare actif, prend la VIP et envoie un ARP gratuit : un message qui annonce « la VIP est désormais derrière moi ». Les commutateurs mettent à jour leur table MAC, et le trafic des postes arrive au nouvel actif. Les postes n'ont rien vu : leur passerelle a gardé la même adresse IP et la même adresse MAC.

Trois réglages déterminent le comportement du groupe :

• la priorité : qui est actif quand tout va bien ;
• la préemption : quand un équipement de priorité supérieure revient (après un redémarrage, une réparation), reprend-il le rôle d'actif ? Avec préemption, oui, au prix d'une seconde microcoupure ; sans préemption, le secours garde le rôle jusqu'à sa propre panne ;
• le suivi (tracking) : l'actif baisse sa propre priorité si un élément qu'il surveille tombe (son lien vers Internet, son service HAProxy), pour laisser la place à un équipement en meilleur état.

HSRP, le protocole de Cisco

HSRP (Hot Standby Router Protocol) est le protocole propriétaire de Cisco, décrit dans une RFC informative (RFC 2281) pour sa version 1. Il ne fonctionne qu'entre équipements Cisco.

Dans les deux versions, l'actif et le secours envoient un hello toutes les 3 secondes ; le secours prend le relais après 10 secondes sans nouvelle (le hold time). La priorité vaut 100 par défaut, de 0 à 255. La préemption est désactivée par défaut : il faut l'activer explicitement. Les autres routeurs du groupe sont en écoute (listen), prêts à devenir secours.

L'exemple. Si le routage entre VLAN de Ravelle Conseil était assuré par deux commutateurs de niveau 3 plutôt que par le pare-feu, voici la configuration de la passerelle du VLAN 10. SW-CORE1 doit être actif, et céder sa place si son lien vers le pare-feu (Gi1/0/48) tombe :

! SW-CORE1
track 1 interface GigabitEthernet1/0/48 line-protocol
!
interface Vlan10
 ip address 10.10.10.252 255.255.255.0
 standby version 2
 standby 10 ip 10.10.10.254
 standby 10 priority 110
 standby 10 preempt
 standby 10 track 1 decrement 20

! SW-CORE2
interface Vlan10
 ip address 10.10.10.253 255.255.255.0
 standby version 2
 standby 10 ip 10.10.10.254
 standby 10 preempt

Si Gi1/0/48 tombe, la priorité de SW-CORE1 passe de 110 à 90, sous les 100 de SW-CORE2. Comme SW-CORE2 a la préemption, il prend le rôle d'actif alors que SW-CORE1 est toujours vivant. La vérification :

SW-CORE1# show standby brief
                     P indicates configured to preempt.
                     |
Interface   Grp  Pri P State   Active          Standby         Virtual IP
Vl10        10   110 P Active  local           10.10.10.253    10.10.10.254

Cisco propose aussi GLBP (Gateway Load Balancing Protocol), qui répartit le trafic sortant entre plusieurs passerelles actives en distribuant plusieurs adresses MAC virtuelles. Il est propriétaire, et rarement exigé au BTS.

VRRP, le standard

VRRP (Virtual Router Redundancy Protocol) est le protocole normalisé, que tous les constructeurs implémentent. Sa version 3, pour IPv4 et IPv6, est décrite par la RFC 9568 (2024), qui remplace la RFC 5798.

Le décalage (skew time) vaut (256 − priorité) ÷ 256 intervalle d'annonce : plus un secours a une priorité élevée, plus il réagit tôt, ce qui évite que plusieurs secours se déclarent maîtres en même temps. Avec la priorité 100 et une annonce par seconde : 3 + 156 ÷ 256 ≈ 3,61 secondes. Les rôles s'appellent traditionnellement Master et Backup ; la RFC 9568 parle désormais de routeur actif.

Sur un équipement Cisco, la syntaxe classique est proche de celle de HSRP :

interface Vlan10
 ip address 10.10.10.252 255.255.255.0
 vrrp 10 ip 10.10.10.254
 vrrp 10 priority 110

Sur les versions récentes d'IOS XE, VRRP version 3 s'active avec fhrp version vrrp v3, puis se configure par famille d'adresses (vrrp 10 address-family ipv4, puis address 10.10.10.254 primary et priority 110). La logique reste identique.

keepalived : VRRP sous Linux

keepalived implémente VRRP sous Linux. Il sert à faire flotter une adresse virtuelle entre deux serveurs : deux répartiteurs HAProxy, deux serveurs DNS, deux passerelles Linux. C'est la réponse à la question qui tombe à chaque recette d'E6 : « Votre répartiteur est un point unique de panne, non ? »

L'exemple. Chez Ravelle Conseil, l'unique répartiteur SRV-LB (10.10.20.30) devient deux VM, LB1 (10.10.20.28) et LB2 (10.10.20.29), placées sur deux hôtes différents. Elles se partagent la VIP 10.10.20.30, l'ancienne adresse de SRV-LB : le DNS, le certificat et les postes ne changent pas. Sur les deux machines :

apt install keepalived
useradd --system --no-create-home --shell /usr/sbin/nologin keepalived_script
echo 'net.ipv4.ip_nonlocal_bind = 1' > /etc/sysctl.d/90-vip.conf
sysctl --system

Le compte keepalived_script sert à exécuter les scripts de contrôle sans les droits de root : keepalived l'utilise automatiquement s'il existe. Le réglage ip_nonlocal_bind permet à HAProxy de démarrer en écoutant sur la VIP même sur la machine qui ne la porte pas encore, sinon HAProxy refuse de démarrer sur le secours.

Le fichier /etc/keepalived/keepalived.conf de LB1 :

global_defs {
    router_id LB1
    enable_script_security
}

vrrp_script chk_haproxy {
    script "/usr/bin/systemctl is-active --quiet haproxy"
    interval 2
    fall 2
    rise 2
    weight -30
}

vrrp_instance VI_INTRANET {
    state MASTER
    interface ens18
    virtual_router_id 30
    priority 150
    advert_int 1
    virtual_ipaddress {
        10.10.20.30/24
    }
    track_script {
        chk_haproxy
    }
}

Sur LB2, le même fichier avec router_id LB2, state BACKUP et priority 130.

Le calcul des priorités est la clé : si HAProxy s'arrête sur LB1, sa priorité passe de 150 à 120, sous les 130 de LB2, qui prend la VIP alors que LB1 est toujours allumé. Sans ce contrôle, keepalived ne surveillerait que la machine : un HAProxy arrêté sur un LB1 vivant couperait l'intranet sans aucune bascule.

On démarre et on vérifie :

systemctl enable --now keepalived
ip -br address show ens18
# ens18   UP   10.10.20.28/24 10.10.20.30/24      ← sur LB1 : la VIP est là
journalctl -u keepalived -n 20
# ... (VI_INTRANET) Entering MASTER STATE

Le pare-feu local. Les annonces VRRP sont des paquets IP de protocole 112, envoyés en multidiffusion vers 224.0.0.18. Si le pare-feu local d'une des machines les bloque, chaque nœud croit l'autre mort et les deux deviennent maîtres : la même VIP existe deux fois sur le réseau, et l'intranet fonctionne par intermittence au gré des mises à jour ARP. Avec nftables, autorise-les explicitement dans la chaîne d'entrée :

ip protocol 112 ip saddr { 10.10.20.28, 10.10.20.29 } accept

Être prévenu des bascules. keepalived peut lancer un script à chaque changement d'état (notify_master, notify_backup, notify_fault), et il écrit chaque transition dans le journal. Fais remonter ces lignes dans ta supervision : une bascule qui passe inaperçue laisse le service sans redondance (chapitre 11).

CARP et pfsync : deux pare-feu en cluster

Le pare-feu est souvent le SPOF le plus critique : il route entre les VLAN, il fait la traduction d'adresses vers Internet, il termine les VPN. pfSense (comme OPNsense) le double avec trois mécanismes complémentaires :

Les conditions d'un cluster de pare-feu.

• Trois adresses par réseau : une pour chaque pare-feu et l'adresse virtuelle. Côté WAN, il faut donc trois adresses publiques dans le même réseau, ce qu'une simple box d'opérateur ne fournit pas toujours.
• Une interface dédiée à la synchronisation, idéalement un câble direct entre les deux pare-feu : pfsync transporte la table d'états, et ce trafic n'a rien à faire sur le LAN.
• La traduction d'adresses sortante sur l'adresse virtuelle WAN : si les connexions sortaient avec l'adresse réelle de PF1, elles casseraient à la bascule.
• Les services du pare-feu sur les adresses virtuelles : le DHCP distribue la VIP LAN comme passerelle et comme DNS, les VPN écoutent sur la VIP WAN.
• Un matériel identique (ou des interfaces nommées à l'identique), pour que la configuration recopiée corresponde.

Pour une mise à jour, pfSense propose un mode maintenance CARP (dans Status > CARP) : le maître cède volontairement son rôle, on le met à jour, on vérifie, on sort du mode maintenance, puis on fait de même pour le secours. Les utilisateurs ne voient au pire qu'une microcoupure. Le cours Pare-feu pfSense monte cette grappe pas à pas sur le labo de Sorbier, plan d'adressage compris : Haute disponibilité pfSense : CARP et pfsync.

Préemption, minuteries et suivi : les bons réglages

La préemption. Elle garantit que l'équipement le mieux placé (le plus puissant, le mieux relié) reprend son rôle dès qu'il revient. Mais un équipement qui redémarre en boucle fait alors basculer le service à chaque redémarrage : c'est le flapping, et chaque bascule est une microcoupure. On peut retarder la préemption (standby 10 preempt delay minimum 60 sur Cisco) pour laisser au revenant le temps de converger, ou la désactiver et revenir à la main, de façon planifiée. Avec keepalived, nopreempt impose que les deux nœuds démarrent en state BACKUP.

Les minuteries. Des annonces plus fréquentes détectent la panne plus vite, mais une simple surcharge du processeur ou une congestion passagère peut alors déclencher une bascule inutile. Les valeurs par défaut (environ 3,6 secondes en VRRP, 10 secondes en HSRP) conviennent à la plupart des services ; on les réduit seulement si l'engagement de service l'exige, et après des tests.

Le suivi. Sans suivi, le protocole ne surveille que la présence du voisin. Un routeur actif dont le lien vers Internet est tombé reste actif et jette tout le trafic. Suis toujours ce qui fait l'utilité de l'équipement : le lien montant d'un routeur, le service d'un serveur.

Exercices