docs : décision SDN EVPN — le routage passe aux hyperviseurs

Les commutateurs ne savent pas lier une ACL à une interface de routage.
Plutôt que d'assumer indéfiniment la perte d'isolation réseau, le routage
inter-zone passe à Proxmox SDN, zones EVPN.

Une zone EVPN est un VRF — celui qu'on regrettait de ne pas avoir dans le
matériel, obtenu en logiciel. Il referme le trou signalé quelques heures plus
tôt : un tenant n'a plus de route vers l'underlay, celui-ci n'étant pas dans
sa table de routage. Le plan de gestion redevient protégé par construction.

La projection du modèle ne demande AUCUN changement de dérivation, vérifiée
sur les deux tenants : zone=tenant, VNet=zone de sécurité, tag=vlan_de(),
subnet et gateway inchangés. Le `.1` change de porteur, pas d'adresse — du
SVI du commutateur vers la passerelle anycast du VNet.

Rien n'est éprouvé, rien n'est généré. Le document fixe la cible et une
séquence de spike en cinq points, dont le MTU (premier mur de VXLAN) et la
tentative d'accès à l'underlay qui DOIT échouer.

Preuves : 24 OK, 0 échec.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

CHANGELOG.md

@@ -1,5 +1,38 @@
 # CHANGELOG — Set-OPS
 
+## 2026-08-02 (suite 20) — décision : le routage passe aux hyperviseurs (SDN EVPN)
+
+`docs/sdn-evpn.md`. Les commutateurs ne savent pas lier une ACL à une interface de routage ;
+plutôt que d'assumer indéfiniment la perte d'isolation réseau que cela entraîne, le routage
+inter-zone passe à **Proxmox SDN, zones EVPN**.
+
+**Une zone EVPN est un VRF** — c'est celui qu'on regrettait de ne pas avoir dans le matériel,
+obtenu en logiciel. Et il referme le trou signalé quelques heures plus tôt : un tenant n'a plus
+de route vers l'underlay, celui-ci n'étant pas dans sa table de routage. Le plan de gestion
+redevient protégé **par construction**, pas par une règle qu'on pourrait oublier.
+
+**La projection du modèle ne demande aucun changement de dérivation** — vérifiée sur les deux
+tenants fédérés :
+
+| Objet SDN | Vient de |
+|---|---|
+| zone (VRF) | le tenant |
+| VNet | la zone de sécurité |
+| tag (VNI) | `vlan_de(index, zone)` |
+| subnet + gateway | `sous_reseau_de(...)` + `passerelle_de(...)` |
+
+Le `.1` ne change pas d'adresse, il change de porteur : du SVI d'un commutateur vers la
+passerelle **anycast** du VNet, présente sur chaque hyperviseur. L'invariant du dernier octet
+survit tel quel.
+
+Le devis switch maigrira d'autant : plus de VLAN tenants, plus de SVI de zone, plus d'ACL — en
+EVPN aucun VLAN de tenant ne circule sur le fil. La fabric redevient un transport IP.
+
+**Rien n'est éprouvé et rien n'est généré.** Le document fixe la cible, la projection et une
+séquence de spike en cinq points — dont la vérification du MTU, premier mur de VXLAN, et
+surtout la **tentative d'accès à l'underlay qui doit échouer**, puisque c'est le gain
+principal. Le principe du dépôt s'applique : éprouver l'outil avant d'écrire le rôle.
+
 ## 2026-08-02 (suite 19) — pas d'ACL sur cette fabric : on route, et c'est tout
 
 Les interfaces VLAN du Binardat n'offrent aucun `access-group` : impossible de lier une ACL à

docs/carte-set-ops.md

@@ -22,6 +22,7 @@ code + les README de rôles). Cette page comble ces deux trous.
 | **Réseau / pare-feu** | `docs/flux-conception.md` (le modèle) → `docs/registre-flux.md` (**généré**, matrice d'audit) → `docs/frontiere-opnsense.md` (la bordure nord/sud) ; underlay : `underlay.yml.example` + `make underlay` |
 | **Ordre de déploiement** | `docs/couches-deploiement.yml` (couches) + `docs/dependances-groupes.yml` (graphe) → `playbooks/site.yml` (**généré**, `make site`) |
 | **Preuve / recette** | `docs/audit/affirmations.md` (registre), `make prouver` → `docs/audit/preuve-<date>.md`, `docs/audit/plan-de-recette.md` (**généré** du wiki), `docs/audit/protocole-operateur-independant.md` |
+| **SDN / routage** | `docs/sdn-evpn.md` — décision du 2026-08-02 : le routage inter-zone passe des commutateurs aux hyperviseurs (zones EVPN = VRF). **Non éprouvé** : spike avant génération |
 | **Migration de tenant** | `docs/migration-tenant.md` — recette en 8 étapes, machine à états, gardes ; le receveur se construit **avant** tout gel |
 | **Exploitation courante** | `docs/runbooks-exploitation.md`, `docs/intrants-communs.md`, `docs/intrants-base-gui-conception.md`, `docs/theme-forgejo-hors-flotte.md` |
 | **Pédagogie (le wiki)** | `wiki/` — 21 unités (+ `_Sidebar`) publiées par `make wiki-publier` ; entrer par `wiki/Home.md` |

docs/sdn-evpn.md

@@ -0,0 +1,98 @@
+# SDN EVPN : le routage passe aux hyperviseurs
+
+> **Décision d'architecture du 2026-08-02.** Elle remplace le routage inter-zone sur les
+> commutateurs L3 par des zones EVPN de Proxmox SDN. Complète `docs/frontiere-opnsense.md`
+> (la bordure, inchangée) et `underlay.yml.example` (la fabric, très allégée).
+>
+> **Rien n'est encore éprouvé.** Ce document fixe la cible et la projection du modèle ; le
+> spike vient avant toute génération.
+
+## 1. Ce que la décision résout
+
+Les commutateurs Binardat ne savent pas lier une ACL à une interface de routage : l'isolation
+inter-tenant ne pouvait pas vivre sur la fabric. On l'a d'abord assumé — tout sur les nftables
+d'hôte — en notant ce qu'on perdait : **le plan de gestion n'avait plus de protection réseau
+contre les tenants**, une VM émettant vers `10.0.0.x` étant routée localement vers le mgmt des
+commutateurs, celui de Proxmox et l'OOB/IPMI.
+
+**Une zone EVPN est un VRF.** Le tenant n'a plus de route vers l'underlay — celui-ci n'est pas
+dans sa table de routage. Son seul chemin vers l'extérieur passe par le nœud de sortie, donc
+par l'OPNsense, qui filtre. Le plan de gestion redevient protégé **par construction**, pas par
+une règle qu'on pourrait oublier.
+
+C'est le VRF qu'on regrettait de ne pas avoir dans le matériel, obtenu en logiciel.
+
+## 2. La projection du modèle
+
+Vérifiée sur les deux tenants fédérés, elle ne demande **aucun changement de dérivation** :
+
+| Objet Proxmox SDN | Vient de | Exemple (Chezlepro, zone Services-infra) |
+|---|---|---|
+| **zone** (un VRF) | le tenant | `CHEZ17` |
+| **VNet** | la zone de sécurité | `chez17-services-infra` |
+| **tag** (VNI) | `vlan_de(index, zone)` | `1174` |
+| **subnet** | `sous_reseau_de(index, zone)` | `10.27.19.0/24` |
+| **gateway** | `passerelle_de(index, zone)` | `10.27.19.1` |
+
+Le seed `index` reste la source unique. Le `.1` ne change pas d'adresse, il **change de
+porteur** : du SVI d'un commutateur vers la passerelle **anycast** du VNet, présente sur
+chaque hyperviseur — donc plus proche de la VM, et sans point unique de défaillance.
+
+Effet de bord favorable : un VNI est codé sur 24 bits là où un VLAN plafonne à 4094. La limite
+du nombre de tenants n'est plus l'espace de VLAN mais le second octet IPv4 du supernet — le
+plafond de 245 tenants reste, sa cause change.
+
+## 3. Ce que le devis switch devient
+
+Il maigrit beaucoup. Disparaissent : les VLAN tenants, les SVI de zone, les ACL d'isolation,
+et les VLAN tenants dans les trunks. En EVPN, **aucun VLAN de tenant ne circule sur le fil** —
+seulement du VXLAN encapsulé dans de l'IP.
+
+Restent : les VLAN d'underlay, le SVI de management, les trunks qui ne portent plus qu'eux,
+les routes, le spanning-tree. La fabric redevient ce qu'elle aurait dû être — un **transport
+IP**.
+
+`underlay.routeur` garde son sens, mais son rôle se réduit : il route l'underlay, plus les
+tenants.
+
+## 4. Ce que ça change ailleurs
+
+**Le nœud de sortie remplace le prochain saut.** En EVPN, le trafic quitte le VRF par un ou
+plusieurs *exit nodes* désignés. Ce sont eux, et non plus le commutateur, que l'OPNsense voit
+comme voisins. `underlay.passerelle_sortie` changera de nature : il désignera l'entrée du
+tenant vers la bordure, côté hyperviseur.
+
+**Le MTU devient un prérequis, pas un détail.** VXLAN ajoute 50 octets. Le transport doit
+passer à 1550 au minimum, jumbo de préférence. C'est le premier mur, et le plus déroutant : il
+ne casse pas franchement, il casse **partiellement** — le ping passe, les transferts échouent.
+
+**Ce qui ne change pas** : le plan, le registre des flux, les nftables d'hôte, la frontière
+OPNsense et ses règles dérivées, la voûte, les preuves. La cible d'émission change ; le modèle
+non.
+
+## 5. Ce qui reste à éprouver — avant toute génération
+
+Le principe du dépôt s'applique : **éprouver l'outil avant d'écrire le rôle.** L'EVPN est la
+partie la plus jeune de Proxmox SDN, et c'est là que vivent les bogues.
+
+Un tenant de labo, une zone EVPN, deux VNet, une VM dans chacun — et vérifier dans l'ordre :
+
+1. le MTU de bout en bout, avec des paquets pleins et le bit *don't fragment* ;
+2. le routage **entre VNet d'une même zone** (c'est ce qui remplace le SVI du commutateur) ;
+3. l'**absence** de route vers l'underlay depuis le tenant — c'est le gain principal, il se
+   vérifie par une tentative qui doit échouer ;
+4. la sortie par le nœud de sortie, jusqu'à la bordure ;
+5. le comportement à la **perte d'un nœud** : la passerelle anycast est censée survivre.
+
+Ce n'est qu'après que la question « comment générer cette configuration » se pose.
+
+## 6. Ce qui reste à trancher
+
+- **Où vit la configuration SDN.** Elle est *par cluster*, donc propriété de l'hébergeur —
+  comme `underlay.yml`, et par le même raisonnement.
+- **Le contrôleur EVPN** : ASN, voisins, et si l'on fait du BGP avec la bordure ou des routes
+  statiques comme aujourd'hui.
+- **Le nombre de nœuds de sortie** et leur redondance.
+- **La migration depuis l'existant** : le tenant Chezlepro tourne déjà sur des VLAN. Passer à
+  EVPN est un changement de plan de transport pour des VM en service — la recette de
+  `docs/migration-tenant.md` s'applique-t-elle, ou faut-il un chemin plus court ?