diff --git a/proxmox-hebergeur.yml b/proxmox-hebergeur.yml index 2d921cf..f19180c 100644 --- a/proxmox-hebergeur.yml +++ b/proxmox-hebergeur.yml @@ -15,11 +15,13 @@ # frontiere sans route de retour vers le locataire. Mesure faite avant la visite, pas # pendant. --- -# UNE ADRESSE, PAS UN NOM DE NOEUD. `atelier` ne resout ni depuis le poste de l'exploitant +# UNE ADRESSE, PAS UN NOM DE NOEUD — et celle du plan de controle (`grappe-controle`), +# pas celle de gestion : c est la patte ou l interface web et l API de Proxmox ecoutent, +# comme chez Chezlepro. `atelier` ne resout ni depuis le poste de l'exploitant # ni depuis le runner : seuls les hyperviseurs connaissent ce nom, par leur /etc/hosts. Les # NOEUDS gardent leurs noms plus bas — ce sont des identifiants dans les chemins d'API, pas # des points de contact. -proxmox_api_host: 10.31.0.41 +proxmox_api_host: 10.31.1.41 proxmox_api_port: '8006' proxmox_api_user: ansible@pve diff --git a/underlay.yml b/underlay.yml index c5fa64e..8335dc8 100644 --- a/underlay.yml +++ b/underlay.yml @@ -22,48 +22,31 @@ underlay: tenants: OPS-Technolibre: 23 - # CE QUI ROUTE ENTRE LES ZONES D'UN LOCATAIRE — TRANCHÉ LE 2026-09-13. + # CE QUI ROUTE ENTRE LES ZONES D'UN LOCATAIRE — `sdn`, COMME CHEZLEPRO. # - # Deux modes existent : - # `switch` : un commutateur porte les SVI et les ACL (mode par défaut du moteur) - # `sdn` : EVPN sur le nœud, un VRF par locataire + # En EVPN, le routage ET le filtrage inter-zone d'un locataire vivent sur le nœud : + # aucun VLAN de locataire ne circule sur le fil, seulement du VXLAN encapsulé. Le devis + # switch cesse alors d'émettre VLAN de locataire, SVI et ACL — vérifié le 2026-09-13 : + # sept VLAN émis (les six du site plus le transit), zéro SVI. # - # ICI IL N'Y A PAS DE COMMUTATEUR DE NIVEAU 3. Entre le nœud et l'OPNsense, il n'y a - # qu'un lien. En mode `switch`, le seul équipement capable de porter les SVI serait - # donc la frontière elle-même : il faudrait lui ajouter SIX interfaces VLAN de plus — - # celles du locataire — en plus de ses six pattes de site, et vérifier à la main les - # ACL entre elles. Douze interfaces sur une machine, pour un écosystème. - # - # En `sdn`, le routage ET le filtrage inter-zone du locataire vivent SUR LE NŒUD. - # Aucun VLAN de locataire ne circule sur le fil, la frontière ne voit que le transit, - # et le moteur sait déjà poser tout ça (`appliquer_sdn`). L'inter-locataire, lui, - # sort du VRF et passe par la frontière, qui le police. - # - # L'OBJECTION — « EVPN sur un seul nœud, c'est un maillage sans pair » — est réelle - # mais se retourne : un VTEP unique n'a AUCUNE session à établir, là où le mode - # `switch` demanderait de configurer et d'éprouver douze interfaces routées. La - # complexité qu'on croyait éviter était de l'autre côté. - # - # C'est aussi le mode qu'exerce Chezlepro : mêmes chemins de code, mêmes devis. + # L'inter-locataire, lui, sort du VRF et passe par la frontière, qui le police. routage_tenants: sdn - # LA FRONTIÈRE ROUTE TOUT — il n'y a pas d'autre équipement de niveau 3 sur ce site. - # Le champ accepte « le commutateur, ou la frontière si elle route tout » : c'est le - # second cas. - routeur: portail + # LE COMMUTATEUR, ET C'EST UNE CORRECTION (2026-09-13). Ce champ portait `portail`, la + # frontière, parce qu'on avait cru qu'il n'y avait rien entre la fabric et l'OPNsense. + # Il y a bien un commutateur — comme à Chezlepro, et à la même place. C'est lui qui + # porte l'underlay ; la frontière ne fait que la bordure nord/sud. + routeur: arche-1 - # Sans commutateur, le dialecte ne commande presque rien (le devis switch n'émet plus - # ni VLAN de locataire, ni SVI, ni ACL en mode `sdn`). On garde celui de la flotte, - # pour qu'un exploitant qui passe d'un site à l'autre lise la même forme. dialecte: binardat - mtu_overlay: 1450 - # UN SEUL LOCATAIRE, ET L'INTER-LOCATAIRE PASSE DÉJÀ PAR LA FRONTIÈRE. Rien à lier à - # une interface de routage qui n'existe pas. À revoir le jour où un deuxième - # écosystème s'installe ici — ce sera alors un geste, pas un effet de bord. + # UN SEUL LOCATAIRE POUR L'INSTANT, et l'inter-locataire passe déjà par la frontière. + # Même valeur qu'à Chezlepro. À revoir le jour où un deuxième écosystème s'installe. acl_inter_tenant: false + # `rstp` plutôt que `mstp` : un seul commutateur, donc aucune instance par VLAN à + # distinguer. La topologie reste l'étoile de Chezlepro — un centre, des feuilles. stp: mode: rstp topologie: etoile @@ -80,6 +63,17 @@ underlay: sous_reseau: 10.31.0.0/24 mtu: 1500 + # LE PLAN DE CONTRÔLE DE PROXMOX — interface web et API du nœud. + # Chezlepro le porte sur `vmbr0` en VLAN 1 ; même place ici. C'est l'adresse que + # `proxmox-hebergeur.yml` désigne comme point de contact, et la seule que le poste + # de l'exploitant doit joindre pour matérialiser des VM. + - nom: grappe-controle + description: Interface web Proxmox et API du nœud + vlan: 1 + sous_reseau: 10.31.1.0/24 + pont: vmbr0 + mtu: 1500 + # LIEN VERS LA FRONTIÈRE. Sans lui, la flotte n'a ni sortie ni chemin de retour : # elle serait routée jusqu'à la bordure puis muette — très difficile à diagnostiquer. - nom: transit-frontiere @@ -100,10 +94,33 @@ underlay: - { nom: site-sauvegarde, description: Dépôt de sauvegarde mutualisé, vlan: 35, sous_reseau: 10.31.35.0/24, pont: vmbr0, mtu: 1500 } - { nom: site-supervision, description: Supervision et observabilité, vlan: 36, sous_reseau: 10.31.36.0/24, pont: vmbr0, mtu: 1500 } + # TRANSPORT DU VXLAN ENTRE VTEP. Exigé par `routage_tenants: sdn` — c'est le réseau + # dans lequel les tunnels des locataires sont encapsulés. Il ne porte JAMAIS de + # trafic de gestion, et aucune machine de locataire ne le voit. + # + # Chezlepro l'adresse en 192.168.50.0/24 ; ici il DÉRIVE de l'index du site, comme + # tout le reste. Les deux sites ont vocation à être reliés : deux transports VXLAN + # au même adressage produiraient une panne dont le message ne parle pas d'adressage. + - nom: underlay-vxlan + description: Transport VXLAN entre VTEP — aucun trafic de gestion + vlan: 50 + sous_reseau: 10.31.50.0/24 + mtu: 1500 + hotes: # L'UNIQUE NŒUD. `via` = l'interface physique qui porte le trunk vers la frontière. - - { nom: atelier, reseau: management, ip: 10.31.0.41, role: hyperviseur } - - { nom: atelier, reseau: transit-frontiere, ip: 10.0.4.41, role: hyperviseur, via: <> } + - { nom: atelier, reseau: grappe-controle, ip: 10.31.1.41, role: hyperviseur, via: vmbr0 } + - { nom: atelier, reseau: management, ip: 10.31.0.41, role: hyperviseur } + - { nom: atelier, reseau: underlay-vxlan, ip: 10.31.50.41, role: hyperviseur, via: <> } + - { nom: atelier, reseau: transit-frontiere, ip: 10.0.4.41, role: hyperviseur, via: <> } + + # LE COMMUTATEUR, entre la fabric et la frontière. Une seule patte, sur le plan de + # gestion : c'est par là qu'on le configure, et le devis n'a pas besoin d'autre chose. + - { nom: arche-1, reseau: management, ip: 10.31.0.3, role: switch } + + # LA PASSERELLE AMONT — la boîte du fournisseur d'accès, en amont de la frontière. + # Déclarée pour que le devis sache où s'arrête notre responsabilité. + - { nom: routeur-site, reseau: grappe-controle, ip: 10.31.1.254, role: passerelle_amont } # LA FRONTIÈRE, patte par patte. Une ligne par zone qu'elle sert : c'est de là que # le devis dérive les interfaces d'arrivée des règles (D-61 raisonne en ARRIVÉE).