Daniel Allaire
1bc516fd92
Aucun des trois SVI de sleipnir-01 n'avait de consommateur : les VTEP sont dans le même sous-réseau, les nœuds de sortie sont adjacents à la frontière, et les commutateurs peuvent sortir par l'OPNsense qui a déjà une patte sur le VLAN 10. Deux décisions séparées avaient vidé ce rôle sans qu'on regarde leur effet cumulé : le passage à l'EVPN a retiré les VLAN tenants du fil, puis la fusion du lien de sortie dans le VLAN 40 a rendu les nœuds de sortie adjacents. sleipnir-01 disparaît, pas seulement son rôle : en étoile, le centre est sur tous les chemins, donc un point de panne unique du plan de données — ce qui vidait aussi de son sens l'ajout d'une seconde carte à bond3. Deux switches L2 reliés, bond3 répartis. D-51 ; D-05 renversée. Le devis perd trois SVI, quatre routes, et surtout sa section 5 — celle qui coupait l'accès d'administration au switch en cas d'erreur. D-50 : `passerelle` signifiait « adresse du SVI du switch », une hypothèse déguisée en donnée. Elle signifie maintenant « la passerelle de ce sous-réseau, où qu'elle vive », et le devis dérive s'il doit émettre une interface routée — uniquement si le porteur déclaré a le rôle switch. Le même moteur sert les deux postures : le modèle public démontre celle où le switch route. Deux gardes remplacées, pas affaiblies. À la place de « passerelle_sortie exige passerelle » et « routeur.ip == passerelle », une règle plus forte : une passerelle doit être l'adresse d'un hôte déclaré sur ce réseau. Elle attrape en plus les passerelles fantômes. Éprouvée par trois sabotages, tous attrapés — et elle a trouvé une sous-déclaration dans le modèle public. Quatre trous corrigés, tous de la même famille (une liste figée finit par mentir) : port de frontière figé sur le transit, trunk Proxmox excluant le transit, switches d'accès sautant sa déclaration, et le switch de tête privé d'adresse de gestion par la suppression du SVI. D-03 renversée : le /29 élargi en /24 fait tomber l'exemption d'invariant, le .1 revient à la passerelle. 30 preuves OK. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| inventories/production/group_vars/all | ||
| plan | ||
| README.md | ||
| underlay.yml | ||
Modèle : socle
Infrastructure de base souveraine — 4 VM : edge (nginx), DNS (PowerDNS),
PKI (step-ca), magasin courriel (Dovecot). Le point de départ minimal, extensible
vers un écosystème complet (voir modèle integral).
Zones : Frontière (VLAN 16) · Services-infra (VLAN 19). VMID ip-miroir 9 chiffres.
Copier vers OPS-<tenant>, adapter index/domaine/intrants, puis make instancier.
Deux moitiés, deux propriétaires
Ce modèle en contient deux, qui ne vont pas au même endroit :
| Fichiers | Décrit | Copier vers |
|---|---|---|
plan/, inventories/ |
les services d'une organisation | OPS-<tenant> |
underlay.yml |
le matériel qui les porte | OPS-<hébergeur> |
Un tenant qui se fait héberger prend la première moitié seulement : l'underlay appartient à qui possède les commutateurs. Chez un hébergeur qui est aussi son propre tenant, les deux atterrissent dans le même dépôt — c'est un cas particulier, pas la règle.
L'underlay fourni est volontairement minimal : un seul commutateur, pas de fabric de stockage séparée. Tous les hébergeurs n'ont pas le même matériel ; les montages plus riches (étoile à trois commutateurs, paire en MLAG, stockage jumbo dédié) relèvent d'autres modèles.
Il est facultatif : un modèle sans underlay.yml reste valide. Présent, il est vérifié
pour sa cohérence interne par la preuve P17, sans être confronté aux tenants réels — un
modèle est un gabarit, pas un site déployé.