Set-OPS-Public/docs/frontiere-physique-virtuel.md

La frontière entre les deux mondes — physique et virtuel

Pour qui : l'exploitant et le mainteneur. Ce document tranche une question qui revenait à chaque décision : qui possède quoi, et où ça vit ?

Set-OPS manipule deux mondes qui se ressemblent et n'obéissent pas aux mêmes règles. Les confondre a coûté plusieurs soirées ; les séparer proprement rend la plupart des questions suivantes évidentes.

---

Les deux mondes

	Monde PHYSIQUE — l'underlay	Monde VIRTUEL — le tenant
Ce que c'est	commutateurs, hyperviseurs, frontière, stockage, transport VXLAN	VM, applications, données
Possédé par	l'hébergeur	l'organisation
Adressage	bande basse du site : 10.<index>.0-15.x	zones : 10.<index>.16+.x
Décrit dans	underlay.yml, proxmox-hebergeur.yml	plan/
Monté par	le symlink underlay.yml	le symlink instance
Change quand	on touche au matériel	on touche au service
Ses secrets	jeton d'API Proxmox, clé d'API de la frontière, accès aux commutateurs	LDAP, forge, SSO, bases
Sa voûte	la sienne, chez l'hébergeur	group_vars/all/vault.yml

Les deux symlinks sont indépendants (D-80) : instance dit quel tenant, underlay.yml dit sur quelle fabric. Un tenant se déplace d'une fabric à l'autre sans qu'on touche à son plan — c'est ce qui rend la portabilité possible.

---

La règle qui rend la frontière opérante

Un tenant ne détient jamais un secret du monde physique.

Aujourd'hui, chaque tenant porte dans sa voûte le jeton d'API du cluster. Patient 0 a dû le recopier pour exister. C'est exactement la faute des neuf copies de la résolution d'instance, appliquée aux secrets : une valeur qui vit à N endroits finit par diverger, et on ne peut plus révoquer l'une sans révoquer les autres.

Conséquence : l'underlay a sa propre voûte, chez l'hébergeur, à côté d'underlay.yml. Les opérations qui parlent au matériel — cloner une VM, poser une zone SDN, écrire sur la frontière — l'y lisent. Les tenants n'y ont pas accès et n'en ont pas besoin.

---

Qui administre quoi, et depuis où

L'administration du monde physique se fait depuis le tenant de l'hébergeur : c'est lui qui porte les outils, les clés et les traces. Le plan de gestion du site (10.<index>.0.0/24) est la seule source autorisée à ouvrir SSH sur la flotte et à franchir la frontière.

Ce n'est pas un détail de commodité. Une machine qui administre depuis l'extérieur des deux mondes — un portable sur le réseau de la maison — n'est ni sauvegardée, ni reconstructible, ni prouvée. Le jour où elle disparaît, l'écosystème est intact et personne ne peut plus y entrer.

---

Ce que la confusion a coûté

Une règle qui ne peut jamais correspondre. devis_opnsense dérive l'interface d'une règle de l'attachement réel de sa source (D-61), et cet attachement se lit dans underlay.yml. Un plan d'administration absent du fichier est classé « distant », et sa règle atterrit sur wan. Le 22 août, on s'apprêtait à poser 89 objets sur la frontière avec une règle d'admin qui n'aurait jamais laissé passer personne.

Un fichier qui décrit un monde disparu. Mesuré le même jour :

management  10.0.0.0/24    déclaré  →  PERSONNE
stockage    10.0.1.0/24    déclaré  →  PERSONNE
ceph        10.0.2-3.0/24  déclaré  →  PERSONNE
transit     10.0.4.0/24    déclaré  →  occupé (3 nœuds)
vxlan       10.0.5.0/24    déclaré  →  occupé (3 nœuds)

et, portés par les nœuds sans être déclarés nulle part :
192.168.11.x  10.11.5-7.x  192.168.50.x  10.1.110.254

La frontière avait déjà migré vers 10.17.0.1 ; les hyperviseurs, non. Le fichier était resté au monde d'avant.

---

L'instrument

make underlay-plan      # confronte le fichier au réel, n'écrit rien

Il interroge l'API du cluster pour les adresses réellement portées, et sonde en TCP ce qui répond. Deux précautions y sont inscrites, toutes deux apprises en l'écrivant :

• l'autorité dépend du rôle. L'API de Proxmox connaît ses hyperviseurs, et eux seuls. Déclarer un commutateur « porté par personne » parce que le cluster l'ignore, c'est accuser le monde de ce que l'instrument ne voit pas ;
• « pas joignable d'ici » n'est pas « absent ». Les réseaux de chemin (transit, transport VXLAN, stockage) ne sont jamais joignables depuis l'extérieur, par construction (D-78). Le premier jet du devis les déclarait morts.

---

Ce qui reste à faire, dans l'ordre

• Reconnaître : make underlay-plan, puis écrire dans underlay.yml ce qui est — pas ce qui était prévu. Chaque réseau porté et non déclaré est un réseau que le moteur ne sait pas classer.
• Séparer les voûtes : créer celle de l'underlay, y déplacer le jeton Proxmox et la clé de la frontière, les retirer des voûtes de tenants.
• Alors seulement, appliquer la frontière — ses règles dépendent des deux points ci-dessus.