SITE-TechnoLibre/underlay.yml

# Underlay de SITE-Technolibre — l'infrastructure PHYSIQUE de l'hébergeur.
#
# UN SEUL NŒUD PROXMOX, en version 9. C'est la différence de fond avec le site de
# Chezlepro : pas de Ceph, pas d'iSCSI, pas de migration, pas de fabric de stockage.
# Le gabarit et ses clones vivent sur la même machine — le SPOF est total, et assumé.
#
# Dérivé du modèle `exemples/modeles/socle` (« un seul commutateur, pas de fabric de
# stockage séparée — le point de départ honnête d'un petit hébergeur »), adapté.
#
# ⚠ TOUT CE QUI EST MARQUÉ <<…>> EST À RELEVER SUR PLACE. Voir COLLECTE.md.
---
underlay:
  # Le locataire que ce site hébergera. Son index est déjà fédéré (23) et il ne
  # change pas : c'est lui qui porte l'adressage d'OPS-Technolibre, ses VLAN et ses VMID.
  tenants:
    OPS-Technolibre: 23

  # CE QUI ROUTE ENTRE LES ZONES D'UN LOCATAIRE — à trancher devant le matériel.
  #   `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 (éprouvé à 3 nœuds, jamais à 1)
  # Voir COLLECTE.md §4 : la réponse dépend de ce qu'il y a entre le nœud et l'OPNsense.
  routage_tenants: <<SWITCH_OU_SDN>>
  routeur: <<NOM_DU_ROUTEUR>>          # le commutateur, ou la frontière si elle route tout
  dialecte: <<cisco|binardat>>          # dicte la forme des ACL et des routes du devis
  mtu_overlay: 1450
  # À `false` quand le matériel ne sait pas lier une ACL à une interface de routage.
  acl_inter_tenant: <<true|false>>

  stp:
    mode: rstp
    topologie: etoile

  reseaux:
    # PLAN DE GESTION — la seule chose qui doit être unique entre deux sites.
    # `10.<index>.0.0/24`, index 23 : la bande basse du supernet du locataire, que la
    # dérivation des zones n'alloue jamais (elles commencent à .16).
    - nom: management
      description: Gestion du nœud, OOB/IPMI, poste de l'exploitant
      vlan: null
      sous_reseau: 10.23.0.0/24
      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
      description: Lien nœud Proxmox <-> OPNsense, et sortie par défaut des locataires
      vlan: 40
      sous_reseau: 10.0.4.0/24
      passerelle_sortie: 10.0.4.1
      mtu: 1500

    # LES SIX ZONES DU SITE. Une préoccupation par zone.
    # ⚠ Identiques à celles du site de Chezlepro (statu quo décidé le 2026-09-12).
    # Conséquence connue : les deux sites ne pourront pas être reliés (§8 du guide)
    # tant qu'aucun des deux n'est renuméroté.
    - { nom: site-pilotage,    description: Runner et pilotage,          vlan: 31, sous_reseau: 10.0.31.0/24, pont: <<PONT>>, mtu: 1500 }
    - { nom: site-autorite,    description: Autorité de certification,   vlan: 32, sous_reseau: 10.0.32.0/24, pont: <<PONT>>, mtu: 1500 }
    - { nom: site-genome,      description: Forge et cache de paquets,   vlan: 33, sous_reseau: 10.0.33.0/24, pont: <<PONT>>, mtu: 1500 }
    - { nom: site-service,     description: Noms (DNS autoritaire),      vlan: 34, sous_reseau: 10.0.34.0/24, pont: <<PONT>>, mtu: 1500 }
    - { nom: site-sauvegarde,  description: Dépôt de sauvegarde mutualisé, vlan: 35, sous_reseau: 10.0.35.0/24, pont: <<PONT>>, mtu: 1500 }
    - { nom: site-supervision, description: Supervision et observabilité, vlan: 36, sous_reseau: 10.0.36.0/24, pont: <<PONT>>, mtu: 1500 }

  hotes:
    # L'UNIQUE NŒUD. `via` = l'interface physique qui porte le trunk vers la frontière.
    - { nom: <<NOEUD>>, reseau: management,        ip: <<IP_NOEUD>>, role: hyperviseur }
    - { nom: <<NOEUD>>, reseau: transit-frontiere, ip: 10.0.4.41,    role: hyperviseur, via: <<IFACE>> }

    # 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).
    - { nom: <<FRONTIERE>>, reseau: management,        ip: 10.23.0.1, role: frontiere }
    - { nom: <<FRONTIERE>>, reseau: transit-frontiere, ip: 10.0.4.1,  role: frontiere }
    - { nom: <<FRONTIERE>>, reseau: site-pilotage,     ip: 10.0.31.1, role: frontiere }
    - { nom: <<FRONTIERE>>, reseau: site-autorite,     ip: 10.0.32.1, role: frontiere }
    - { nom: <<FRONTIERE>>, reseau: site-genome,       ip: 10.0.33.1, role: frontiere }
    - { nom: <<FRONTIERE>>, reseau: site-service,      ip: 10.0.34.1, role: frontiere }
    - { nom: <<FRONTIERE>>, reseau: site-sauvegarde,   ip: 10.0.35.1, role: frontiere }
    - { nom: <<FRONTIERE>>, reseau: site-supervision,  ip: 10.0.36.1, role: frontiere }

  # LE GABARIT ET SON STOCKAGE. Sur un nœud unique, `clone_complet` est le choix sûr :
  # un clone lié dépend à vie du gabarit, et il n'y a pas d'autre nœud pour le porter.
  materialisation:
    vmid_modele: <<VMID_GABARIT>>
    stockage: <<STOCKAGE>>
    clone_complet: true