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> |
||
|---|---|---|
| .. | ||
| socle | ||
| README.md | ||
Modèles d'écosystèmes numériques
Un modèle générique prêt à déployer : copier socle, le renseigner à ses
couleurs, instancier. Le socle souverain minimal — DNS interne, AC/PKI, edge TLS,
relais courriel — sur lequel on ajoute des modules.
Utilisation
cp -r exemples/modeles/socle ../mon-instance
# éditer mon-instance : intrants (domaine_interne, fuseau_horaire, organisation,
# identite_realm), plan/nomenclature.yml (index de fédération + zones), domaines
cd <moteur Set-OPS>
ln -s ../mon-instance instance # ou export SETOPS_INSTANCE=../mon-instance
make instancier-appliquer FORCE=1 # première génération de l'inventaire
Modèles assemblés (dépôt privé)
Les modèles assemblés — combinaisons de modules prêtes pour des offres
(identite, observabilite, forge, collaboration, presence-web, integral) —
ne sont pas ici. Ils constituent un actif à part, dans un dépôt privé
(Set-OPS-modeles). Le moteur (rôles, machinerie) reste libre ; socle en est
la preuve reproductible.
| Modèle | = socle + | Où |
|---|---|---|
socle |
(rien) — le socle générique | ✅ public (ici) |
| identite · observabilite · forge · collaboration · presence-web · integral | modules assemblés | 🔒 privé |