Homelab on Mook’s Lab Chronicles

Je voulais juste mettre à jour mes OPNsense

Sat, 15 Aug 2026 20:00:00 +0200

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 :

1
2


8 VIP : p1 BACKUP / p2 MASTER
VIP LAN : p1 MASTER / p2 MASTER

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 :

1
2


P1 devait cibler 10.0.0.3
P2 devait cibler 10.0.0.2

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 :

1
2
3


P1 ─┐
 ├── 224.0.0.18
P2 ─┘

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.

1
2
3
4


fw-core-p1 : MASTER 9/9
fw-core-p2 : BACKUP 9/9
demotion : 0
pfsync : synchronisé

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.

Je reconstruisais tout. Je ne notais rien.

Sat, 15 Feb 2025 10:00:00 +0100

Je venais de refaire une bonne partie de mon homelab. La virtualisation, le stockage, le réseau, les sauvegardes : tout avait été repris, déplacé ou repensé.

Quelques semaines plus tard, j’ai rouvert une configuration et je me suis posé une question assez simple :

Pourquoi est-ce que j’avais fait ça comme ça ?

Je savais qu’il y avait une raison. J’avais probablement testé plusieurs solutions, rencontré un problème puis choisi celle qui s’adaptait le mieux à mon environnement. Le résultat fonctionnait toujours, mais le chemin pour y arriver avait déjà commencé à disparaître.

Ce n’était pas la première fois.

Résoudre, passer au suivant, oublier

J’ai longtemps travaillé de cette manière dans mon homelab. Une idée me trottait dans la tête, je montais un petit lab, je cassais quelques trucs et je finissais par obtenir quelque chose d’utilisable.

Une fois le problème résolu, je passais au suivant.

Le raisonnement restait quelque part entre ma mémoire, un historique de commandes et quelques fichiers dont le nom commençait parfois par final et finissait par v2. Autant dire que, six mois plus tard, la recherche archéologique était rarement brillante.

Le plus frustrant n’était pas d’avoir oublié une commande. Une documentation constructeur pouvait souvent me la redonner. Ce que je perdais, c’était la raison du choix : pourquoi cet outil, pourquoi cette architecture et quelle mauvaise piste j’avais déjà éliminée.

La reconstruction qui a servi de déclic

Cette remise à plat du homelab est arrivée pendant une période plus compliquée professionnellement, où je me suis retrouvé au chômage. J’avais davantage de temps pour reprendre les fondations, expérimenter et remettre de l’ordre dans ce que j’avais accumulé.

En reconstruisant la virtualisation, le stockage, le réseau et les sauvegardes, j’ai compris que mon principal problème n’était pas technique.

Je ne gardais aucune trace de ce que je faisais.

Je pouvais passer plusieurs soirées à comprendre un comportement, trouver le bon compromis, vérifier que tout fonctionnait… puis ne laisser derrière moi que la configuration finale. Toute la partie intéressante disparaissait alors que c’était justement elle qui pouvait m’être utile plus tard.

Un blog plutôt qu’un dossier de notes oublié

J’aurais pu ouvrir un dossier documentation/, rédiger trois fichiers Markdown et oublier leur existence. Je me connais suffisamment pour savoir comment cette histoire se serait terminée.

Le blog ajoutait une petite contrainte qui me manquait : pour publier un article, je devais remettre les événements dans l’ordre, expliquer le problème et vérifier que ce que j’écrivais correspondait encore à la réalité.

Il ne s’agissait plus seulement de conserver une commande. Il fallait raconter pourquoi elle avait été nécessaire.

C’est devenu la première mission de ce blog : servir de mémoire technique à mon homelab. Si un retour d’expérience peut ensuite faire gagner du temps à quelqu’un ou lui donner une idée à essayer, c’est un très bon bonus.

Pour mon parcours et ce qui se cache derrière le pseudo, la page mook –about fait désormais bien mieux le travail qu’une longue présentation au milieu de cet article.

Ce que cette mauvaise habitude a fini par produire

Depuis, les articles les plus intéressants sont justement ceux que je n’aurais probablement jamais documentés avant.

La naissance de WarpgateSH aurait pu rester un script lancé à la main puis oublié. Les sauvegardes qui malmenaient mon cluster Ceph auraient pu se résumer à « j’ai décalé les horaires et ça va mieux ». Et ma petite révision du cluster OPNsense aurait probablement laissé derrière elle une correction sans son raisonnement.

Tout n’est pas documenté pour autant. Certains essais restent dans un terminal, certains projets attendent encore leur article et je continue parfois à comprendre trop tard que j’aurais dû prendre des notes plus tôt.

Mais le réflexe a changé. Quand je termine quelque chose, je ne me demande plus seulement si ça fonctionne aujourd’hui. Je me demande aussi ce que j’aurai oublié le jour où je devrai y revenir.

C’est généralement là qu’un nouvel article commence.