From 03aa035cabd85ef5de740838a28f0acf4f2ba970 Mon Sep 17 00:00:00 2001 From: Daniel Allaire Date: Wed, 12 Aug 2026 18:37:49 -0400 Subject: [PATCH] =?UTF-8?q?D-79=20:=20l'hyperviseur=20filtre=20encore=20en?= =?UTF-8?q?=20iptables=20legacy=20=E2=80=94=20dette,=20pas=20option?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Question de l'exploitant : pourquoi les regles au pare-feu global alors que chaque VNet peut en porter ? La reponse honnete a demande trois corrections. CE QUE J'AVAIS TORT D'AFFIRMER : - « une regle de VNet serait trop grossiere » : faux, elle porte source, dest, dport, proto. Eprouve (regle creee, relue, retiree). - « c'etait un arbitrage » : faux. Zero mention du pare-feu SDN dans le depot. Pas un choix, une omission presentee comme un raisonnement. - « sur Debian 12 iptables c'est iptables-nft » : faux ici. Mesure sur asgard : iptables v1.8.9 (legacy). Proxmox force l'alternative sur legacy. LE DEFAUT D'UNE DISTRIBUTION N'EST PAS UNE MESURE. MESURE : proxmox-firewall 0.7.1 installe mais ABSENT des services ; seul pve-firewall 5.1.3 tourne ; node firewall enable 0. Le pare-feu de VNet est entierement expressif (source/dest/dport/proto, policy_forward ACCEPT|DROP) et implemente par le SEUL moteur nftables : une regle posee aujourd'hui serait acceptee, stockee, visible, et n'appliquerait rien. Quatrieme occurrence du motif de la journee. TROIS GAINS DANS LE MEME GESTE : moteur xtables -> nftables natif (la doctrine que les invites respectent deja), pare-feu de VNet reel, et regles qui SURVIVENT a la reconstruction la ou 38 groupes par VM doivent etre re-attaches a chaque cycle. Differe apres la reconstruction, sur un noeud d'abord, avec controle negatif. Reserves : jeu de regles charge non inspecte (nft exige root), aucun blocage reel eprouve (aucune VM en service). Co-Authored-By: Claude Opus 5 --- CHANGELOG.md | 48 ++++++++++++++++++++++++++++++++++ docs/decisions-architecture.md | 19 ++++++++++++++ 2 files changed, 67 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index 624b9fa..d14b492 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,5 +1,53 @@ # CHANGELOG — Set-OPS +## 2026-08-12 — D-79 : l'hyperviseur filtre encore en iptables *legacy* + +Question de l'exploitant : *« pourquoi les règles de sécurité au pare-feu global, alors +que chaque VNet peut en porter ? »* La réponse honnête a demandé trois corrections +successives — et la dernière était la bonne. + +### Ce que j'avais tort d'affirmer + +**« Une règle de VNet serait trop grossière. »** Faux : elle porte `source`, `dest`, +`dport`, `proto`. Éprouvé — règle créée, relue, retirée. L'exploitant avait raison. + +**« C'était un arbitrage. »** Faux, et pire : **zéro mention** du pare-feu SDN dans le +dépôt — ni doc, ni script, ni CHANGELOG. Ce n'était pas un choix, c'était une omission, +présentée comme un raisonnement. + +**« Sur Debian 12, `iptables` c'est `iptables-nft`, donc c'est déjà du nftables. »** Faux +ici. Mesuré sur `asgard` : `iptables v1.8.9 (legacy)`. Proxmox force l'alternative sur +legacy, parce que `pve-firewall` dépend de l'ancien sous-système. **Le défaut d'une +distribution n'est pas une mesure.** + +### Ce que la mesure établit + +``` +asgard iptables v1.8.9 (legacy) nftables v1.0.6 installé, inutilisé par Proxmox + proxmox-firewall 0.7.1 INSTALLÉ, absent des services en cours + pve-firewall 5.1.3 en service + node firewall enable: 0 cluster firewall enable: 1 +VNet fw type/action/proto/source/dest/dport + policy_forward ∈ {ACCEPT, DROP} +``` + +Le pare-feu de VNet est **entièrement expressif** — et **implémenté par le seul moteur +nftables**. Posée aujourd'hui, une règle serait acceptée, stockée, visible dans +l'interface, et n'appliquerait rien. C'est le motif de la journée, une quatrième fois. + +### Trois gains dans le même geste + +Activer `proxmox-firewall` fait passer le moteur de xtables à **nftables natif** (la +doctrine « tout est nftables », que les invités respectent déjà et que l'hyperviseur +trahissait), rend le pare-feu de VNet **réel**, et donne des règles qui **survivent à la +reconstruction** — là où les 38 groupes par VM doivent être ré-attachés à chaque cycle. + +Ce n'est donc pas une entorse à évaluer : c'est une **dette à rembourser**. + +**Différé** après la reconstruction, sur un nœud d'abord, avec preuve de blocage et +contrôle négatif. Deux réserves consignées : le jeu de règles chargé n'a pas été inspecté +(`nft list tables` exige root, le compte `ansible` ne l'a pas), et aucun blocage réel n'a +été éprouvé — aucune VM n'était en service. + ## 2026-08-12 — Technolibre 11→23, lab 1→13 : sortir des plages qu'occupait le matériel Le retrait du décalage de `+10` a déplacé les tenants vers `10.`. Ces plages diff --git a/docs/decisions-architecture.md b/docs/decisions-architecture.md index fb9b5c6..57c4fd5 100644 --- a/docs/decisions-architecture.md +++ b/docs/decisions-architecture.md @@ -119,6 +119,25 @@ sont les seules vérifiables. | **D-77** | **L'underlay d'un site dérive du même `index` que son tenant**, dans la **bande basse** `10..0–15.x` ; les réseaux de **stockage** en sortent et sont **identiques partout**, en `192.168..0/24` | tant qu'il n'existait qu'un site, `10.0.x.x` suffisait. Deux sites qui doivent se joindre — reprise mutuelle, sauvegardes croisées, exploitation à distance — **ne peuvent pas** porter les mêmes plages : chaque routeur croit que le réseau est chez lui. Un « numéro de site » a d'abord été proposé : **rejeté**, c'était un SECOND SEED à tenir et à synchroniser, alors que tout dérive déjà d'`index` (D-17). La bande basse est sûre **par la règle, pas par chance** : les zones valent `10..(15+categorie).0/24`, donc troisième octet ≥ 16 — les octets 0 à 15 ne sont jamais alloués. Les troisièmes et derniers octets de l'underlay actuel sont ainsi **préservés** : seul le deuxième change, et l'invariant `.1` (D-04) survit intact. Le **stockage** en est sorti parce qu'il est jumbo, non routé, et ne quitte jamais son site : il n'a aucun besoin d'être unique, et l'aligner sur le VLAN (`192.168.20.x` ↔ VLAN 20) fait dire son VLAN à l'adresse. Contrepartie assumée : ces réseaux ne pourront jamais traverser un lien inter-sites — sans conséquence, puisque ce qui voyage entre deux sites est l'**état**, par le dépôt de sauvegarde, pas le stockage bloc | `underlay.yml` (`index`), `scripts/underlay.py`, `docs/preparer-un-site-hebergeur.md` | **P23** | +| **D-79** | Le filtrage que l'hyperviseur applique aux VM tourne encore sur **iptables *legacy***. Le passer à `proxmox-firewall` (nftables natif) est une **dette à rembourser**, pas une option — et c'est le même geste qui rend le **pare-feu de VNet** opérant. Décidée le 2026-08-12, **différée après la reconstruction** | mesuré sur `asgard` : `iptables v1.8.9 (legacy)` — pas `(nf_tables)` ; `nftables v1.0.6` installé mais inutilisé par Proxmox ; `proxmox-firewall 0.7.1` **installé et absent des services en cours** ; seul `pve-firewall 5.1.3` tourne. Le pare-feu de VNet est **entièrement expressif** (`type/action/proto/source/dest/dport`, et `policy_forward` ∈ `ACCEPT,DROP` — donc un vrai default-deny inter-zone) : une règle d'essai a été créée, relue, puis retirée. **Mais il n'est implémenté QUE par le moteur nftables** : posée aujourd'hui, une règle serait acceptée, stockée, visible dans l'interface, et n'appliquerait rien. Trois gains dans le même geste — le moteur rejoint la doctrine (« tout est nftables »), le pare-feu de VNet devient réel, et ses règles **survivent à la reconstruction** là où les groupes par VM doivent être ré-attachés à chaque cycle | `devis_proxmox_fw.py`, `docs/sdn-evpn.md` | P25 *(sur le mécanisme actuel)* | + +> **Ce qui n'a PAS été établi, et qu'il faudra éprouver.** `nft list tables` exige root et le +> compte `ansible` ne l'a pas sur les hyperviseurs : **le jeu de règles réellement chargé n'a +> pas été inspecté**. Et aucune VM n'était en service au moment de la mesure : **aucun blocage +> n'a été prouvé**, ni avec l'ancien moteur ni avec le nouveau. La conclusion sur l'inertie du +> pare-feu de VNet repose sur l'état du service, pas sur un paquet refusé. +> +> **Une supposition erronée, gardée ici parce qu'elle est instructive.** L'assistance avait +> avancé que sur Debian 12 `iptables` est `iptables-nft`, donc que les paquets passaient déjà +> par nf_tables. C'est faux ici : Proxmox force l'alternative sur `iptables-legacy`, parce que +> `pve-firewall` dépend de comportements de l'ancien sous-système. **Le défaut d'une +> distribution n'est pas une mesure.** +> +> **Séquence retenue** : après la reconstruction, quand `make valider` et les sept devis +> donnent une référence propre — activer `nftables` sur **un seul nœud**, vérifier que le +> filtrage par VM tient toujours, puis poser un `policy_forward: DROP` sur un VNet et +> **prouver qu'il bloque, avec son contrôle négatif**. + | **D-78** | Un réseau d'underlay est soit une **destination**, soit un **chemin**. Les destinations gardent l'adressage dérivé (`10..0–15.x`) ; les chemins sortent de cet espace en **`192.168..0/24`, identiques à tous les sites** — décidée le 2026-08-12, **appliquée au déplacement physique** | D-77 sortait déjà le stockage, mais par une exception nommée plutôt que par une règle. Le critère n'est pas « y a-t-il des VM dedans » — le VLAN de gestion n'en a pas non plus — c'est : **ce réseau est-il jamais une destination, ou seulement un chemin ?** Transit (40) : rien que des prochains sauts, deux extrémités adjacentes en L2. Transport VXLAN (**VLAN 50**) : VTEP ↔ VTEP, destination de rien. Stockage (20/30/31) : baie ↔ hyperviseurs. **Gestion (10) : le poste de l'exploitant, un VPN, demain le lien inter-sites doivent l'atteindre** — elle reste dérivée et unique. Effet : sur six réseaux, **cinq** cessent d'exiger la moindre coordination entre deux hébergeurs, et « unique » redevient signifiant — seul ce qui doit l'être l'est | `underlay.yml`, `docs/preparer-un-site-hebergeur.md` | P23 *(la borne de bande basse ne s'applique qu'aux destinations)* | > **Ce que D-78 coûte, et ce qui la renverserait.** Le jour où l'un de ces liens devrait