Ce site declarait deux reseaux d administration, calques sur Chezlepro : `management` (le plan d admin) et `grappe-controle` (interface web et API de Proxmox). Cette separation a une cause HISTORIQUE chez Chezlepro : ses trois noeuds existaient avant Set-OPS, sur un reseau qui leur etait deja propre — et que le poste de l exploitant atteint par routage, pas en s y posant. Ici, un seul noeud et un terrain vierge : le second reseau ne separait rien. Il obligeait seulement a router entre les deux pour que le poste — pose sur l admin — atteigne une API posee ailleurs. L exploitant se donne une adresse secondaire dans 10.31.0.0/24, exactement comme il le fait deja pour 10.17.0.x et 10.37.0.x chez lui, et atteint d un coup la frontiere (.1), le noeud (.41) et le rebond. - reseau `grappe-controle` retire ; le noeud et la passerelle amont reviennent sur `management` (10.31.0.41 et 10.31.0.254) - `proxmox_api_host` suit : 10.31.0.41 - COLLECTE.md dit ou le poste doit se poser Verifie : devis SDN conforme (1 zone, 6 VNets), devis reseau emet les VLAN 31-36, 40 et 50 avec zero SVI, contrat du site inchange. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
7.6 KiB
À relever sur place — TechnoLibre
Tout ce qui pouvait être décidé l'a été le 2026-09-13. Ce qui suit n'est pas un choix : ce sont des FAITS que seul le matériel peut dire. Treize valeurs, pas trente-cinq.
| Ce qu'il faut | Où le lire | Pourquoi personne ne peut le décider |
|---|---|---|
<<IFACE>> |
ip -br link sur le nœud |
Le nom de la carte réseau dépend du matériel (eno1, enp1s0…) |
<<IP_PUBLIQUE>> |
OPNsense, interface WAN | Donnée par le fournisseur d'accès |
<<IP_FRONTIERE_ADMIN>> |
OPNsense, interface de gestion | Dépend du plan d'adressage existant sur place |
<<optN>> ×9 |
OPNsense → Interfaces → Assignments | Les noms optN sont attribués dans l'ordre de création |
| `<<lan | optN>>` | Idem |
proxmox_api_token_id |
Datacenter → Permissions → API Tokens | Délivré par le nœud à la création |
proxmox_api_token_secret |
Idem — affiché une seule fois | Ne se relit jamais ; le noter tout de suite |
vault_opnsense_api_key |
System → Access → Users → api keys | Délivré par la frontière |
vault_opnsense_api_secret |
Téléchargé avec la clé, même fichier | Idem |
Le piège des optN. Le devis raisonne en ARRIVÉE : une règle posée sur la mauvaise
patte ne correspond jamais, et rien ne le signale. Relever les neuf noms exacts avant de
poser quoi que ce soit, y compris celui de la patte face au nœud Proxmox — elle manquait
chez Chezlepro et toutes les règles entrantes des locataires tombaient dans le vide.
Ce qui est mesuré, pas relevé. local-lvm accueille quinze clones complets, soit
environ 600 Go. Vérifier vgs et df -h AVANT de lancer la matérialisation : c'est la
seule décision de ce document qui peut encore changer, et elle se prend avec un chiffre.
Les quatre jetons vont dans la voûte, pas dans un fichier de plan :
cd ../Set-OPS-public
ANSIBLE_VAULT_IDENTITY_LIST="$(python3 scripts/voutes.py identites)" \
ansible-vault edit ../SITE-Technolibre/underlay.vault.yml
Ils y sont déjà déclarés, vides. C'est volontaire : une clé absente donne une erreur de variable indéfinie, une clé vide donne l'assertion du rôle — qui dit quoi manque et où le prendre. Les dix autres secrets du site sont déjà engendrés.
Ce qui a été décidé, et qu'il suffit de confirmer
| Valeur | Raison | |
|---|---|---|
| Index du site | 31 |
Les sites prennent leur propre index depuis le 2026-09-12 |
| Plan d'administration | 10.31.0.0/24 |
Un seul — frontière .1, nœud .41, passerelle amont .254 |
| Adresse du poste | une secondaire dans 10.31.0.0/24 |
De là, l'API Proxmox, la frontière et le rebond sont tous joignables |
| Nœud Proxmox | atelier |
À poser comme nom d'hôte à l'installation |
| Frontière | portail |
Étiquette dans la carte ; l'OPNsense peut garder son nom réel |
| Domaine du site | socle.internal |
Distinct de technolibre.internal, qui est au locataire |
| Routage des locataires | sdn (EVPN sur le nœud) |
Sans commutateur L3, le mode switch obligerait la frontière à porter douze interfaces routées |
| ASN | 65031 |
Dérivé de l'index — deux sites reliés ne peuvent pas collisionner |
| Contrôleur EVPN | EVPN0031 |
Objet de cluster : nommé d'après le site, pas d'après son premier locataire |
| Pont | vmbr0 |
Un seul, VLAN-aware — sans seconde carte, d'autres ponts ne sépareraient rien |
| Gabarit | 99998 |
Le même dans toute la flotte |
1. Le chiffre qui décide de tout
SITE 7 VM 20 Go RAM 776 Go provisionnés
tenant 14 VM 37 Go RAM 460 Go provisionnés
─────────────────────────────────────────
TOTAL 21 VM 57 Go RAM ~1,2 To
Sur trois nœuds ça se répartit. Sur un seul, la même machine porte tout — et la RAM est la contrainte dure (le disque se dégonfle en provisionnement fin, pas la mémoire).
- RAM physique du nœud : ______ Go → si < 64, décider de réduire AVANT de câbler
- Espace libre du stockage
images: ______ Go (viser 1,2 To ; 800 Go à la rigueur)
2. L'hyperviseur
- Nom exact du nœud tel qu'il apparaît dans l'interface : ______
- Version :
pveversion | head -1→ ______ (attendu :pve-manager/9.x) - Noms exacts des stockages acceptant le contenu
images:pvesm status - Ponts présents :
ip -br link | grep vmbr - Adresse de gestion du nœud : ______
- SDN disponible ?
pvesh get /cluster/sdnrépond sans erreur : oui / non
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
- Token ID + secret notés (le secret ne s'affiche qu'une fois)
3. La frontière (OPNsense)
- IP publique (WAN) : ______
- Version : ______
- Interfaces libres pour les zones du site : ______
- Clé + secret d'API créés et notés
- Compte
ansibleen SSH par clé,sudovérifié :sudo -n -l - Une patte face au nœud Proxmox (le lien de transit) : interface ______
4. Entre les deux — LA question de forme
Ce qu'il y a entre le nœud Proxmox et l'OPNsense décide du mode de routage :
- Un commutateur capable de SVI et d'ACL → mode
switch, modèle : ______ - Un commutateur simple (VLAN seulement) → l'OPNsense route tout, mode
switchavec l'OPNsense comme routeur - Un lien direct nœud ↔ OPNsense → trunk 802.1Q, l'OPNsense route tout
- SDN EVPN sur le nœud → indépendant du matériel, mais jamais éprouvé sur un nœud unique
5. Cohabitation d'adressage
ip routesur le poste de Mathieu — quelles plages10.xsont déjà prises ?- Son réseau bureautique / son VPN utilisent-ils
10.31.xou10.23.x? ______ - Docker présent sur ses machines d'administration ? (
172.17+ déjà pris)
6. Le gabarit
- Gabarit Debian 13
modeleSetOPS-minimal: fait / à faire (procédure :docs/procedure-template-debian13-proxmox.md, ~30 min) - Si fait : VMID ______ , nom ______ , stockage ______
- Vérifier
machine: q35etbios: ovmf— ne jamais convertir un i440fx
7. Les accès réseau nécessaires depuis le poste
| Cible | Port | Pour quoi | OK |
|---|---|---|---|
| Hyperviseur | 8006 | créer et détruire les VM | [ ] |
| Hyperviseur | 22 | pvesh, qm, SDN |
[ ] |
| Frontière | 443 | poser les règles par API | [ ] |
| Frontière | 22 | SSH, compte ansible |
[ ] |
| Zones du site | 22 | SSH vers les VM une fois créées | [ ] |
8. Les deux paires de secrets
Par un canal chiffré, séparément du reste, et jamais dans git :
- Token ID + secret de l'hyperviseur → voûte de l'instance
- Clé + secret de l'API de la frontière → voûte de l'instance
9. Ce qui n'a jamais été éprouvé, et qu'il faut regarder de près
- Proxmox 9 — le moteur n'analyse aucune version et n'appelle que des chemins
d'API stables, mais rien n'a jamais tourné contre un PVE 9. Surveiller le pare-feu
(
proxmox-firewallnftables en 9) et le SDN (passé GA). - Nœud unique — pas de Ceph, pas de migration, le gabarit et les clones sont sur la même machine. Le SPOF est total et assumé.
- Index 31 — celui du SITE. Vérifier qu'aucune plage
10.31.xn'existe déjà chez Mathieu (ip route | grep 10.31).make instancesgarde la fédération.