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
25 lines
1 KiB
YAML
25 lines
1 KiB
YAML
# Intrants de la frontière de Technolibre (OPNsense).
|
|
# Les SECRETS (clé et secret d'API) ne vivent PAS ici : voûte chiffrée de l'instance.
|
|
---
|
|
opnsense_api_url: https://<<IP_FRONTIERE_ADMIN>>
|
|
opnsense_wan_ip: <<IP_PUBLIQUE>>
|
|
|
|
# L'interface d'arrivée de chaque zone. D-61 : le devis raisonne en ARRIVÉE, donc une
|
|
# règle posée sur la mauvaise patte ne correspond JAMAIS — et rien ne le signale.
|
|
# Relever les noms exacts (`optN`) dans Interfaces > Assignments.
|
|
opnsense_if_zones:
|
|
site-pilotage: <<optN>>
|
|
site-autorite: <<optN>>
|
|
site-genome: <<optN>>
|
|
site-service: <<optN>>
|
|
site-sauvegarde: <<optN>>
|
|
site-supervision: <<optN>>
|
|
# La patte face au nœud Proxmox — par où arrive TOUT le trafic des locataires.
|
|
# Elle manquait chez Chezlepro et les règles entrantes des tenants ne correspondaient
|
|
# à rien : la poser dès le premier jour.
|
|
transit-frontiere: <<optN>>
|
|
|
|
opnsense_if_transit: <<optN>>
|
|
opnsense_if_wan: wan
|
|
opnsense_if_gestion: <<lan|optN>>
|
|
opnsense_if_site: <<optN>>
|