Fais basculer une passerelle avec VRRP

L’idée reçue

« Deux routeurs configurés suffisent pour rendre la passerelle hautement disponible. »

Les clients doivent utiliser une identité stable. VRRP déplace une adresse virtuelle entre les routeurs ; il ne rend pas automatiquement disponibles le WAN, le pare-feu, le DNS ou l’application.

Client10.90.10.10gateway 10.90.10.1

→

VIP10.90.10.1GW1 MASTER ou GW2 MASTER

→

Service10.90.20.10:8080validation end-to-end

01Installer les composants

sudo apt update
sudo apt install -y keepalived nftables curl python3 iproute2

Le laboratoire utilise VRRP en unicast entre deux gateways. GW1 reçoit une priorité de 150 et GW2 une priorité de 100.

02Créer les gateways et le VIP

chmod +x module5b-routing-ha-lab.sh
sudo ./module5b-routing-ha-lab.sh vrrp

GW110.90.10.2priorité 150 · MASTER attendu

GW210.90.10.3priorité 100 · BACKUP attendu

Identité client10.90.10.1VIP, jamais une IP physique

03Identifier le MASTER

sudo ip -n m5-gw1 -brief address show lan0
sudo ip -n m5-gw2 -brief address show lan0
sudo ip netns exec m5-vcli ip neigh show 10.90.10.1

Le VIP doit apparaître sur GW1 uniquement. La table ARP du client associe la passerelle virtuelle à l’adresse MAC actuellement annoncée par le MASTER.

04Valider le service avant panne

sudo ip netns exec m5-vcli curl -s http://10.90.20.10:8080/ | head

Le service HTTP est placé derrière les gateways. Les deux gateways appliquent un masquerade afin que le serveur réponde au routeur qui a réellement transmis la requête.

Comprends ce que prouve ce test

Un ping du VIP prouve seulement que la passerelle virtuelle répond. Le test HTTP valide la chaîne client → VIP → forwarding → NAT → serveur → retour.

05Mesurer le failover

Dans un terminal, répète la requête :

while true; do
date +%H:%M:%S.%3N
sudo ip netns exec m5-vcli curl -fsS --max-time 1   http://10.90.20.10:8080/ >/dev/null && echo OK || echo ECHEC
sleep 0.2
done

Dans un autre terminal :

sudo ./module5b-routing-ha-lab.sh vrrp-fail
sleep 4
sudo ip -n m5-gw2 -brief address show lan0

GW2 doit devenir MASTER et recevoir 10.90.10.1. Consigne le nombre d’échecs HTTP et le délai entre la dernière réussite via GW1 et la première réussite via GW2.

06Observer la préemption

sudo ./module5b-routing-ha-lab.sh vrrp-recover
sleep 4
sudo ip -n m5-gw1 -brief address show lan0
sudo ip -n m5-gw2 -brief address show lan0

GW1 possède une priorité supérieure. Après son retour, il doit reprendre le rôle MASTER. Cette préemption peut être souhaitée, retardée ou désactivée selon la politique d’exploitation.

07Distinguer les niveaux de disponibilité

État

Preuve

Conclusion

VIP présent

ip address

Gateway élue

VIP joignable

ping 10.90.10.1

LAN + VRRP

HTTP accessible

curl

Chaîne complète

VIP présent, HTTP en échec

VIP + curl

Panne au-delà de VRRP

Panne volontaire

Arrête seulement le service HTTP

arrête le serveur Python dans m5-vsrv ;
vérifie que le VIP reste présent et que VRRP ne bascule pas ;
montre que curl échoue malgré une gateway saine ;
explique pourquoi un suivi de processus ou de route WAN serait nécessaire pour déclencher un basculement pertinent ;
consigne la différence entre haute disponibilité réseau et disponibilité applicative.

08Nettoyer

sudo ./module5b-routing-ha-lab.sh cleanup

✓Ce que tu retiens

VRRP fournit une passerelle stable grâce à un VIP et une élection MASTER/BACKUP. Un failover utile doit être mesuré de bout en bout et ne doit pas être confondu avec la santé de l’application.