Set-OPS-Public/docs/preparer-un-site-hebergeur.md

Préparer un site hébergeur

Pour qui : l'hébergeur qui met son matériel à disposition — il n'a pas besoin de connaître Set-OPS. L'exploitant du tenant lui transmet ce document, puis relit §7 pour savoir ce qu'il doit recevoir en retour.

Set-OPS déploie un écosystème complet (annuaire, SSO, courriel, forge, nuage collaboratif, supervision, sauvegardes) à partir d'un plan. Tout cet adressage se dérive d'un seul chiffre — l'index du tenant.

Ce que la machine ne peut pas deviner, c'est le matériel : le câblage, le nom des stockages, le chemin de sortie vers Internet. C'est l'objet de ce document, et c'est tout ce qui est demandé à l'hébergeur.

1. Le partage des rôles

	Décide quoi	Où ça vit
Hébergeur	réseau physique, pare-feu de bordure, stockage, hyperviseur	underlay.yml et proxmox-hebergeur.yml, dans son dépôt
Tenant	quels services, sur quel nœud/stockage/pont les poser	inventories/*/group_vars/, dans le dépôt du tenant

Cette séparation n'est pas cosmétique. Tant que ces valeurs étaient recopiées chez chaque tenant, elles ont divergé : deux inventaires contradictoires du même cluster, avec des listes de stockages et de ponts différentes. Un hébergeur décrit son matériel une fois.

2. Le plan d'adressage — la seule chose à respecter à la lettre

Un site prend son PROPRE index, comme un tenant. Il n'y a pas de second registre à tenir : le seul seed de tout l'adressage reste l'index, et sites et tenants se partagent la même classe A — chacun le sien, aucun partagé.

Corrigé le 2026-09-12. Cette règle disait « un site dérive du même index que son tenant ». Conséquence mesurée chez l'hébergeur de référence : le plan d'administration du site vivait dans 10.17.0.0/24, à l'intérieur du supernet du locataire OPS-Chezlepro. Ce n'était pas dangereux — les zones d'un tenant commencent à l'octet 16 par construction — mais 10.17.0.0/16 désignait alors deux choses : un locataire, et le plan d'administration de celui qui l'héberge. Deux sens pour une adresse.

L'exception disparaît : tout prend un index. Le seul cas particulier restant serait qu'il n'y en ait plus, et l'octet en offre 256.

make instances compte désormais les sites avec les tenants — un site et un locataire ne peuvent plus réclamer le même nombre sans que la garde le dise.

Rôle	VLAN	Sous-réseau	MTU	Nature
Gestion	10 (ou aucun — voir ci-dessous)	10.<index>.0.0/24	1500	destination — unique par site
Sortie des tenants	40	192.168.40.0/24	1500	chemin — identique partout
Transport VXLAN	50	192.168.50.0/24	1500	chemin — identique partout
Stockage iSCSI	20	192.168.20.0/24	9000	chemin — identique partout
Ceph public	30	192.168.30.0/24	9000	chemin — identique partout
Ceph cluster	31	192.168.31.0/24	9000	chemin — identique partout

Index 17 → gestion en 10.17.0.0/24 ; index 11 → 10.11.0.0/24. Deux sites ne peuvent donc pas se chevaucher, sans qu'on ait rien de plus à décider.

Le VLAN de gestion peut n'exister pas du tout. Chez l'hébergeur de référence, ce plan est un segment physique — une patte dédiée sur la frontière, aucune étiquette, et aucun pont d'hyperviseur ne le touche. Conséquence recherchée : aucune VM ne peut y naître, et le validateur refuse qu'on y déclare une machine. Un port d'accès étiqueté 10 convient aussi ; ce qui compte est que rien du monde virtuel n'y ait de patte.

Les VLAN ne changent jamais d'un site à l'autre : ils sont locaux, ils ne traversent aucun lien inter-sites. Un seul modèle mental, et l'adresse de stockage porte son propre numéro de VLAN — 192.168.20.x est sur le VLAN 20.

Pourquoi la bande basse est sûre, et non pas seulement libre aujourd'hui. Les zones d'un tenant sont dérivées en 10.<index>.(15+categorie).0/24 : leur troisième octet vaut donc 16 au minimum, et croît avec le nombre de zones. Les octets 0 à 15 ne sont jamais alloués — c'est une propriété de la règle, pas une place restée vide. L'underlay y tient largement.

Un seul réseau doit être unique, et c'est la gestion. Le critère n'est pas « y a-t-il des machines dedans » — le VLAN de gestion n'en a pas plus qu'un autre — c'est : ce réseau est-il jamais une destination, ou seulement un chemin ?

La gestion est une destination : le poste de l'exploitant, un VPN, demain un lien inter-sites doivent l'atteindre. Les autres ne sont que traversés — le transit ne porte que des prochains sauts entre deux voisins directs, le VXLAN va d'un hyperviseur à l'autre, le stockage de la baie aux hyperviseurs. Aucun n'est jamais joint depuis l'extérieur de son propre lien.

D'où 192.168.<vlan>.0/24, identique chez tous les hébergeurs : l'adresse dit son VLAN, et cinq réseaux sur six cessent d'exiger la moindre coordination. Contrepartie assumée : ils ne pourront jamais franchir un lien inter-sites. Sans conséquence — ce qui voyage entre deux sites, c'est l'état (par le dépôt de sauvegarde), pas la plomberie.

Un hébergeur qui n'exploite lui-même aucun tenant prend quand même un index : c'est le seed de son site. Une seule règle, aucun cas particulier.

Le MTU n'est pas un détail

Le trafic des VM voyage encapsulé en VXLAN, ce qui coûte 50 octets. Avec un transport à 1500, les VM tournent à 1450 — automatiquement, mais à condition que 1500 passe réellement de bout en bout sur les VLAN de transport et de transit — 50 et 40 (le tableau ci-dessus fait foi ; ce paragraphe disait « 11 et 40 », le numéro d'avant). Un MTU rogné en chemin donne le pire des symptômes : les petites requêtes passent, les grosses meurent, et rien n'est signalé.

Le jumbo (9000) sur le stockage est facultatif. À moitié configuré, il ne fonctionne pas du tout — mieux vaut rester à 1500 que le poser sur un seul des trois maillons.

3. La frontière (pare-feu de bordure)

C'est le seul équipement qui route, et l'unique point de passage entre l'extérieur et l'intérieur. Set-OPS pilote ses règles par API : le boîtier reste à l'hébergeur, rien n'y est installé.

Interfaces : le WAN (noter l'IP publique) ; la gestion en 10.<index>.0.1/24 ; le transit en 192.168.40.1/24, par où sortent les machines du tenant.

Un point de routage porte le même dernier octet partout : .1, quel que soit l'équipement qui l'assure. Invariant porté par la preuve P23.

Un compte pour l'exploitant : un utilisateur ansible avec sa clé publique. Aucun sudo n'est nécessaire — l'outil lit et appelle l'API. Un compte qui ne peut pas devenir root ne peut pas casser le pare-feu par accident.

Une clé d'API : sur OPNsense, System → Access → Users → ansible → API keys → « + ». Le secret n'est affiché qu'une seule fois.

4. Le stockage

Rien de spécifique à Set-OPS : il faut que l'hyperviseur puisse y poser des disques de VM (NFS ou iSCSI). Seuls comptent les stockages qui acceptent le contenu images.

Dimensionnement, mesuré sur un écosystème complet de quatorze machines :

	Mesuré	À prévoir
Disques provisionnés	~460 Go	600 Go
RAM allouée	~37 Go	48 Go (32 à la rigueur, en démarrant par vagues)

5. L'hyperviseur (Proxmox VE)

À noter et transmettre : le nom exact du nœud tel qu'il apparaît dans l'interface, les noms exacts des stockages, et les ponts (vmbrN). Pas les descriptions : les noms, tels qu'ils seront lus par l'API.

Sur un cluster de plusieurs nœuds, un pont doit exister sur tous — un pont partiel est un piège : la VM ne démarre que sur certains nœuds, et l'erreur ne le dit pas.

Le SDN n'est pas à configurer par l'hébergeur. Set-OPS crée le contrôleur EVPN, la zone (un VRF par tenant) et les réseaux. Il faut seulement que le SDN soit disponible et le VLAN de transport en place.

Le compte d'API

pveum user add ansible@pve
pveum aclmod / -user ansible@pve -role Administrator
pveum user token add ansible@pve set-ops --privsep 0

Le Token ID et le secret sont à noter — le secret n'est affiché qu'une fois.

Sur Administrator, autant le dire franchement. Le minimum documenté est VM.Allocate, VM.Clone, VM.Config.*, Datastore.AllocateSpace et les droits SDN. Mais l'outil crée aussi des objets réseau et détruit des VM : partir large le premier jour évite de courir après des 403 pendant le déploiement. Le resserrer ensuite est un rôle sur mesure, dix minutes — et c'est un geste à faire, pas une intention.

6. Le gabarit — et le piège qu'il porte

Toutes les VM sont clonées depuis un même modèle Debian, nommé modeleSetOPS : c'est un artefact du moteur, pas d'un tenant. Une VM Debian minimale avec qemu-guest-agent et cloud-init, convertie en template, suffit.

Ne pas le personnaliser. Un gabarit qui porte une clé privée d'hôte SSH, un /etc/resolv.conf figé ou un compte nominatif recopie tout cela dans chaque clone. C'est arrivé, et il a fallu recapturer le gabarit puis reconstruire pour s'en défaire.

En cas de doute, laisser l'exploitant le fabriquer : c'est une demi-heure, et la procédure est écrite (docs/procedure-template-debian13-proxmox.md).

7. Ce que l'exploitant doit recevoir

Élément	Exemple
IP publique (WAN)	203.0.113.10
Nom du nœud hyperviseur	asgard
Stockages (noms exacts)	TrueNAS, local-lvm
Ponts	vmbr0, vmbr3
RAM et disque disponibles	64 Go / 2 To
Modèle du commutateur	dicte le dialecte de CLI (cisco | binardat)
Domaine public prévu	exemple.ca
Gabarit	fait, ou à faire
index du site	le même que son tenant — voir §2, à fixer avant de câbler
Accès de l'exploitant	sur place, ou lien vers le VLAN de gestion (voir §8)

Et deux paires de secrets, par un canal chiffré et séparément du reste : le Token ID + secret de l'hyperviseur, la clé + secret de l'API de la frontière. Ils n'entrent jamais dans un dépôt git : leur place est la voûte chiffrée de l'instance.

Les accès réseau nécessaires

Cible	Port	Pour quoi
Hyperviseur	8006	créer et détruire les VM
Frontière	443	poser les règles par API
Frontière	22	SSH, compte ansible
Réseau du tenant	22	SSH vers les VM une fois créées

Les VM ont besoin de sortir sur Internet pour leurs paquets système. Le reste — les artefacts applicatifs — est poussé depuis le poste de l'exploitant, pas téléchargé par les machines.

8. Relier deux sites (exploitation à distance, reprise après sinistre)

Deux besoins bien distincts, qu'il ne faut pas confondre :

Les services publiés n'ont besoin de rien. Nuage, forge, courriel, SSO sortent par la frontière en TLS, derrière l'authentification unique. Aucun tunnel n'est requis pour les utiliser, et en ajouter un n'apporterait rien.

Le plan de contrôle, si. L'inventaire adresse les machines par leurs IP privées dérivées ; il n'existe aucun chemin publié vers elles, et il ne peut pas y en avoir sans casser la dérivation. Les API de l'hyperviseur et de la frontière, elles, tournent avec la vérification du certificat désactivée — les exposer publiquement reviendrait à publier les deux surfaces les plus privilégiées sans savoir à qui l'on parle.

Besoin	Forme adaptée
Déployer et exploiter à distance, ponctuellement	accès nomade (poste → site) : une clé, révocable, aucun couplage entre sites
Réplication de sauvegardes, reprise mutuelle	lien site-à-site : il doit tenir sans qu'aucun poste soit allumé

Dans les deux cas, la politique doit être explicite : un lien qui joint simplement deux réseaux défait en silence l'isolation inter-tenant. WireGuard s'y prête bien — ses allowed-ips sont la politique : ce qui n'y figure pas ne traverse pas.

Ce que la reprise mutuelle exige en plus : des plages de gestion distinctes (§2), de la capacité chez le survivant pour faire tourner les deux écosystèmes, un gabarit présent des deux côtés, et la voûte de chaque instance conservée hors de son propre site. Les sauvegardes, elles, sont chiffrées côté client : le site d'accueil héberge du chiffré qu'il ne peut pas lire. La confiance demandée porte sur la disponibilité, pas sur la confidentialité.

9. Ce qu'il ne faut pas faire

• Ne pas créer de VM à la main pour le tenant. Elles sont toutes dérivées du plan ; une VM créée à côté est invisible pour l'outil — et le risque n'est pas celui qu'on croit. make raser dérive sa liste du plan : il ne la détruira jamais. Elle survit donc à tout, sans DNS, sans certificat, sans sauvegarde, sans politique de pare-feu, et son VMID n'est gardé par aucune preuve contre une collision. Un VMID oublié squatte le cluster sans que rien ne le signale. (Cette ligne annonçait l'inverse — « l'outil la détruira sans le savoir » — jusqu'au 2026-09-06.) Pour une machine d'épreuve jetable, il existe une voie prévue et documentée : make cloner-vm, hors plan, à détruire à la main (cf. vm-lifecycle.md §4bis).
• Ne pas configurer le SDN : l'outil le fait entièrement.
• Ne pas écrire les secrets dans un fichier partagé ni dans un dépôt git.
• Ne pas contourner un blocage en silence. Un point resté ouvert et signalé se règle en dix minutes ; un contournement non dit se paie en heures, parce que la panne sera cherchée au mauvais endroit.

Voir aussi

• sdn-evpn.md — pourquoi une zone EVPN par tenant.
• config-proxmox.md — les intrants côté hyperviseur, et le token.
• frontiere-opnsense.md — la frontière, hors flotte Ansible.
• procedure-template-debian13-proxmox.md — fabriquer modeleSetOPS.