- plan/10-intrants.yml : dns_public_pairs SITE-Chezlepro, etat actif.
- opnsense.yml : opnsense_liens_sites vers SITE-Chezlepro, interface opt10 (wg1).
- COLLECTE.md : la console de maurice sur la GTX 950 (fbcon=map:1).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Carte au schema actuel (index 31, zones derivees, publication VLAN 37), equipements reels :
frontiere requin, noeud maurice, commutateur caillou.
- Neuf machines, memes noms et VMID qu'au site de Chezlepro ; runner des deux locataires.
- maurice : vmbr0 administration (nic0), vmbr1 VLAN-aware pour les VM (nic2) ; stockages nvme
et miroir (ZFS 2 x 12 To, site-backup-01).
- opnsense.yml : optN mesures (opt1 transit, opt2..opt8 zones, opt9 RELAIS) ; face publique par
le relais (opt9, RELAIS_GW), adresse du site et pool des locataires ; silence du relais.
- underlay.yml : reseau `relais` (tunnel WireGuard 10.31.60.0/30), hote relais (VPS OVH) et
cles publiques des deux bouts.
- plan/domaines.yml et plan/mainteneurs.yml ; documentation (README, PREMIERE-HEURE,
COLLECTE) a jour du releve sur place.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Un seul noeud Proxmox en version 9, une frontiere OPNsense. Trois
consequences ecrites dans le README : le SPOF est total, les clones sont
complets (un clone lie n achete rien sans second noeud), et rien n a jamais
tourne contre un PVE 9.
Le chiffre a verifier avant de cabler : 57 Go de RAM pour le site et son
locataire sur la meme machine. La RAM est la contrainte dure.
Adressage au statu quo : gestion en 10.23.0.0/24, zones du site en
10.0.31-36 comme chez Chezlepro. Consequence connue et ecrite : les deux
sites ne pourront pas etre relies tant qu aucun n est renumerote.
COLLECTE.md liste dans l ordre ce qui doit etre releve sur place, dont la
question de forme : ce qu il y a entre le noeud et l OPNsense decide du mode
de routage.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
