diff --git a/CHANGELOG.md b/CHANGELOG.md index 130918c..876322d 100644 --- a/CHANGELOG.md +++ b/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 à diff --git a/docs/carte-set-ops.md b/docs/carte-set-ops.md index 4952c2f..d7eaa73 100644 --- a/docs/carte-set-ops.md +++ b/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-.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` | diff --git a/docs/sdn-evpn.md b/docs/sdn-evpn.md new file mode 100644 index 0000000..8a1e701 --- /dev/null +++ b/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 ?