D-79 : l'hyperviseur filtre encore en iptables legacy — dette, pas option

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 <noreply@anthropic.com>

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.<index>`. Ces plages

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.<index>.0–15.x` ; les réseaux de **stockage** en sortent et sont **identiques partout**, en `192.168.<vlan>.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.<index>.(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.<index>.0–15.x`) ; les chemins sortent de cet espace en **`192.168.<vlan>.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