diff --git a/docs/preparer-un-site-hebergeur.md b/docs/preparer-un-site-hebergeur.md index 94452fa..1d66935 100644 --- a/docs/preparer-un-site-hebergeur.md +++ b/docs/preparer-un-site-hebergeur.md @@ -25,12 +25,27 @@ listes de stockages et de ponts différentes. Un hébergeur décrit son matérie ## 2. Le plan d'adressage — la seule chose à respecter à la lettre +**Chaque site porte un numéro**, et tout son adressage en dérive : `10..x.0/24`. +Le premier hébergeur est le site `0`, le deuxième le site `1`, et ainsi de suite. + | Rôle | VLAN | Sous-réseau | MTU | Qui y vit | |---|---|---|---|---| -| Gestion | 10 | `10.0.0.0/24` | 1500 | frontière `.1`, commutateurs, OOB/IPMI, admin hyperviseur | -| Transport VXLAN | 11 | `10.0.5.0/24` | 1500 | hyperviseurs seulement | -| Stockage iSCSI | 20 | `10.0.1.0/24` | 9000 | baie ↔ hyperviseurs | -| Sortie des tenants | 40 | `10.0.4.0/24` | 1500 | frontière `.1`, nœuds de sortie | +| Gestion | 10 | `10..0.0/24` | 1500 | frontière `.1`, commutateurs, OOB/IPMI, admin hyperviseur | +| Transport VXLAN | 11 | `10..5.0/24` | 1500 | hyperviseurs seulement | +| Stockage iSCSI | 20 | `10..1.0/24` | 9000 | baie ↔ hyperviseurs | +| Sortie des tenants | 40 | `10..4.0/24` | 1500 | frontière `.1`, nœuds de sortie | + +Les **VLAN ne changent pas** d'un site à l'autre : ils sont locaux, ils ne traversent +jamais un lien inter-sites. Un seul modèle mental vaut mieux qu'une seconde table à +retenir. Seules les plages L3 diffèrent. + +> **Pourquoi ce numéro de site, alors qu'un seul hébergeur n'en a pas besoin.** Le jour +> où deux sites doivent se joindre — reprise après sinistre mutuelle, sauvegardes +> croisées, exploitation à distance — deux sites qui portent `10.0.0.0/24` **ne peuvent +> pas être reliés** : chaque routeur croit que le réseau est chez lui. Décider ce chiffre +> coûte une minute avant de câbler ; renuméroter un site vivant, c'est refaire les baies, +> les hyperviseurs et la frontière. **C'est la décision la moins chère et la plus +> irréversible de tout ce document.** Deux invariants portés par la preuve `P23` : @@ -56,8 +71,8 @@ C'est le seul équipement qui route, et l'unique point de passage entre l'extér 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.0.0.1/24` ; le transit -en `10.0.4.1/24`, par où sortent les machines du tenant. +**Interfaces :** le WAN (noter l'IP publique) ; la gestion en `10..0.1/24` ; le +transit en `10..4.1/24`, par où sortent les machines du tenant. **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 @@ -132,7 +147,8 @@ est écrite (`docs/procedure-template-debian13-proxmox.md`). | Modèle du commutateur | dicte le dialecte de CLI (`cisco` \| `binardat`) | | Domaine public prévu | `exemple.ca` | | Gabarit | fait, ou à faire | -| Accès | sur place, ou VPN débouchant sur le VLAN 10 | +| Numéro de site | `0`, `1`… — voir §2, à décider **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** @@ -151,7 +167,37 @@ Les VM ont besoin de sortir sur Internet pour leurs paquets système. Le reste artefacts applicatifs — est **poussé depuis le poste de l'exploitant**, pas téléchargé par les machines. -## 8. Ce qu'il ne faut pas faire +## 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, qui la détruira sans le savoir.