J’étais parti pour une petite révision tranquille de mes deux OPNsense. Une sauvegarde, une mise à jour du premier firewall, quelques contrôles, puis la même chose sur le second.
Le premier venait de terminer. J’ai lancé la mise à jour du second, puis contrôlé l’état du cluster pendant qu’elle avançait.
Un cluster qui fonctionnait… presque
Mon réseau repose sur deux firewalls, fw-core-p1 et fw-core-p2, avec neuf adresses IP virtuelles CARP. En temps normal, p1 porte les neuf VIP et p2 attend sagement en secours.
Après la mise à jour du premier nœud, l’état était un peu plus créatif :
| |
Le réseau fonctionnait encore. Les interfaces répondaient, pfsync synchronisait toujours les connexions et rien ne semblait cassé à la maison. Mais la VIP du LAN était portée par les deux firewalls en même temps.
C’était le genre de problème assez discret pour passer inaperçu, jusqu’au jour où il décide de ne plus l’être.
Je n’ai rien tenté au milieu de l’opération. p1 a repris les neuf VIP avant le redémarrage du second, puis j’ai simplement surveillé le trafic jusqu’à son retour. Quelques minutes plus tard, les deux nœuds étaient bien en OPNsense 26.7.2_2 sur FreeBSD 15.1 et tous les services répondaient.
La mise à jour était terminée. Restait à comprendre ce petit double-MASTER.
P2 discutait avec lui-même
Le CARP du LAN utilisait l’unicast. Chaque firewall devait envoyer ses annonces directement à l’adresse réelle de l’autre :
| |
Dans la configuration réelle, les deux ciblaient 10.0.0.3.
Pour p1, c’était correct. Pour p2, beaucoup moins : il envoyait ses annonces CARP à sa propre adresse.
Le plus amusant, c’est que la synchronisation HA faisait exactement ce que je lui demandais. p1 copiait sa configuration vers p2, y compris ce pair unicast qui aurait justement dû être différent sur chaque machine. Corriger uniquement le second nœud n’aurait servi à rien : la synchronisation suivante aurait remis la mauvaise valeur.
Mes huit autres VIP fonctionnaient déjà avec le multicast CARP classique. J’ai donc vérifié que les annonces envoyées vers 224.0.0.18 traversaient bien le bridge Proxmox et arrivaient sur p2. C’était le cas.
J’ai supprimé le pair unicast du LAN et laissé CARP revenir à son fonctionnement normal :
| |
Cette fois, les deux firewalls pouvaient partager exactement la même configuration sans que l’un d’eux finisse par se parler à lui-même.
Le petit test qui évite les grandes suppositions
Une fois la correction appliquée, j’ai placé p1 en maintenance. p2 a repris les neuf VIP, le DNS a continué de répondre et mes routes applicatives sont restées accessibles. En quittant le mode maintenance, p1 est redevenu MASTER par préemption et p2 est retourné en BACKUP.
| |
Au final, la mise à jour vers la série OPNsense 26.7 s’est passée sans incident. Elle m’a surtout donné une bonne excuse pour regarder un peu plus loin que le voyant vert.
Je voulais faire une petite révision. J’ai retiré une adresse dans un champ, relancé un vrai failover et mon cluster est maintenant plus simple qu’avant.
C’est déjà pas mal pour une matinée de maintenance.