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>
72 lines
3.6 KiB
YAML
72 lines
3.6 KiB
YAML
# Underlay du modèle « socle » — l'infrastructure PHYSIQUE la plus simple qui tienne.
|
|
#
|
|
# Un modèle d'underlay décrit le matériel d'un HÉBERGEUR, pas un plan de services :
|
|
# tous les hébergeurs n'ont pas les mêmes équipements. Celui-ci est volontairement
|
|
# minimal — un seul commutateur, pas de fabric de stockage séparée — parce que c'est
|
|
# le point de départ honnête d'un petit hébergeur. Les montages plus riches (étoile à
|
|
# trois commutateurs, paire en MLAG, stockage jumbo dédié) sont d'autres modèles.
|
|
#
|
|
# À l'usage : copier ce fichier dans le dépôt de l'hébergeur, l'adapter, puis le monter
|
|
# ln -s ../OPS-<hebergeur>/underlay.yml underlay.yml
|
|
# Validé par `python3 scripts/modeles.py verifier` (preuve P17, structure du modèle)
|
|
# puis, une fois adapté et monté, par `make underlay` (site réel, preuve P23).
|
|
---
|
|
underlay:
|
|
# LE commutateur, qui route tout. Avec un seul équipement il n'y a pas de switches
|
|
# d'accès : le devis n'émet donc que sa partie A.
|
|
routeur: switch-01
|
|
|
|
# Dialecte de CLI : décide la forme des masques d'ACL, des routes, du spanning-tree.
|
|
dialecte: cisco
|
|
|
|
# Un seul commutateur = aucun lien redondant, donc aucune boucle par construction.
|
|
# RSTP reste actif comme filet : deux ports brassés ensemble par mégarde suffiraient
|
|
# à provoquer une tempête de diffusion.
|
|
stp:
|
|
mode: rstp
|
|
topologie: etoile
|
|
|
|
reseaux:
|
|
# Plan de gestion : le commutateur lui-même, l'hyperviseur, l'OOB/IPMI.
|
|
- nom: management
|
|
description: Commutateur, mgmt de l'hyperviseur, OOB/IPMI
|
|
vlan: 10
|
|
sous_reseau: 10.0.0.0/24
|
|
passerelle: 10.0.0.1
|
|
mtu: 1500
|
|
|
|
# Lien vers le pare-feu de bordure. SANS LUI, la flotte n'a ni sortie vers
|
|
# Internet ni chemin de retour vers l'administration : elle serait routée
|
|
# jusqu'à la bordure puis muette, ce qui est très difficile à diagnostiquer.
|
|
# `passerelle_sortie` = l'adresse du pare-feu sur ce lien ; c'est elle qui fait
|
|
# émettre la route par défaut et les routes de retour.
|
|
- nom: transit-frontiere
|
|
description: Lien commutateur L3 <-> pare-feu de bordure
|
|
vlan: 40
|
|
sous_reseau: 10.0.4.0/29
|
|
# Le /29 loge deux pare-feux (transition, ou haute disponibilité plus tard) :
|
|
# ils occupent le bas de la plage, le SVI du commutateur le haut.
|
|
passerelle: 10.0.4.6 # SVI du commutateur
|
|
passerelle_sortie: 10.0.4.1 # pare-feu = sortie par défaut de la flotte
|
|
mtu: 1500
|
|
|
|
# Équipements fixes. Le routeur PORTE le SVI de management : son adresse de gestion
|
|
# EST la passerelle du réseau — `make underlay` refuse deux valeurs divergentes.
|
|
hotes:
|
|
- nom: switch-01
|
|
reseau: management
|
|
ip: 10.0.0.1
|
|
# Ports physiques (optionnel). Déclarés, le devis sort applicable tel quel ;
|
|
# absents, il émet des marqueurs `<PORT-VERS-...>` à remplacer à la main — et
|
|
# le travail est perdu à chaque régénération.
|
|
ports:
|
|
hyperviseurs: [Gi1/0/1]
|
|
frontiere: [Gi1/0/23]
|
|
# Le commutateur porte AUSSI une adresse sur le lien de transit : c'est son SVI.
|
|
# Le déclarer ici n'est pas une redite — c'est ce qui permet au devis de savoir
|
|
# QUI porte la passerelle, et donc s'il doit émettre une interface routée. Sans
|
|
# cette ligne, la passerelle 10.0.4.6 n'appartiendrait à personne.
|
|
- { nom: switch-01, role: switch, reseau: transit-frontiere, ip: 10.0.4.6 }
|
|
# Le pare-feu de bordure : hors flotte Ansible, déclaré ici pour documenter le
|
|
# lien et réserver son nom.
|
|
- { nom: pare-feu-1, reseau: transit-frontiere, ip: 10.0.4.1, role: frontiere }
|