# Intrants de la frontiere du site de TechnoLibre (OPNsense sur QOTOM : 5 ports 2,5G, 4 SFP+ 10G).
# Memes cles qu'au site de Chezlepro (refait sur son modele le 2026-10-12).
# Les SECRETS (cle et secret d'API) ne vivent PAS ici : `underlay.vault.yml`.
---
opnsense_api_key: '{{ vault_opnsense_api_key }}'
opnsense_api_secret: '{{ vault_opnsense_api_secret }}'
opnsense_api_url: https://10.31.0.1
# FAUX JUSQU'A CE QUE LA FRONTIERE SOIT CERTIFIEE : elle sert d'abord le certificat
# auto-signe d'OPNsense. `scripts/frontiere_pki.py` lui donne son autorite (signee par la
# racine de CE site, une fois site-pki-01 en place) puis l'interface passe au certificat de
# services ; alors seulement, mettre `true` — comme au site de Chezlepro le 2026-10-12.
opnsense_api_verifier_certs: false

# L'INTERFACE D'ARRIVEE DE CHAQUE ZONE. Le devis raisonne en ARRIVEE : une regle posee sur la
# mauvaise patte ne correspond JAMAIS, et rien ne le signale. MESURE le 2026-10-13 dans
# `config.xml` de `requin`, pas devine : OPNsense attribue les `optN` a l'assignation.
# Les zones sont des VLAN poses sur `ix0` (SFP+ 10G), qui rejoint `caillou` puis `nic2` de
# `maurice` ; `ix0` lui-meme n'est plus assigne.
opnsense_if_gestion: lan        # igc0, GESTION
opnsense_if_transit: opt1       # vlan040, TENANTS
opnsense_if_zones:
  site-pilotage:     opt2       # vlan031, PILOTAGE
  site-autorite:     opt3       # vlan032, AUTORITE
  site-genome:       opt4       # vlan033, GENOME
  site-service:      opt5       # vlan034, SERVICE
  site-sauvegarde:   opt6       # vlan035, SAUVEGARDE
  site-supervision:  opt7       # vlan036, SUPERVISION
  site-publication:  opt8       # vlan037, PUBLICATION
  # La patte face au noeud — par ou arrive TOUT le trafic des locataires. Elle manquait chez
  # Chezlepro le premier jour et les regles entrantes des locataires tombaient dans le vide.
  transit-frontiere: opt1       # vlan040, TENANTS
# AUCUNE PATTE « SITE » PLATE ICI. Chez Chezlepro, `opnsense_if_site` nomme l'ancienne patte
# du /24 d'avant les zones (vlan030) ; ce site est ne avec ses zones et n'en a pas. Le devis
# s'en sert encore en repli et pour la sortie DNS du site : la cle reste un MARQUEUR, que le
# devis rend visible, plutot qu'une patte inventee — a trancher au premier devis.
opnsense_if_site: <<optN>>
opnsense_if_wan: wan

opnsense_silences:
  - nom: wan
    interface: wan
    motif: >-
      Refus par defaut du WAN. Le balayage d'Internet est permanent ; le refus par defaut reste
      CONSIGNE sur toutes les interfaces internes, ou il sert au diagnostic.
  - nom: relais
    interface: opt9
    motif: >-
      La face publique arrive par le relais : le balayage d'Internet aussi. Meme refus muet
      que le WAN — mesure le 2026-10-13, des balayages consignes sur les trois adresses
      relayees des la premiere minute du tunnel.

# L'exportateur de metriques de la frontiere (greffon os-node_exporter), sur sa patte de
# supervision ; `frontiere_pki.py` le passe en HTTPS.
opnsense_exportateur_metriques:
  patte: site-supervision
  port: 9100

# LA FACE PUBLIQUE PASSE PAR LE RELAIS (2026-10-13). Le WAN (`igc4`) n'a qu'une adresse
# DHCP, derriere un reseau prive amont : il sert la SORTIE du site (apt, mises a jour), rien
# d'autre. Les adresses fixes sont louees sur un VPS d'OVH et arrivent par le tunnel `wg0`,
# assigne `opt9` (RELAIS) — voir le reseau `relais` de `underlay.yml`.
#
# `interface` : la ou le devis pose ce que le site publie (regles entrantes, redirections,
# poignees de main des tunnels d'administration, traduction sortante des locataires).
# `passerelle` : le `reply-to` de chacune de ces regles. SANS LUI, la requete entre et la
# reponse repart par la route par defaut — le WAN — et se perd : mesure le 2026-10-13, trois
# pings depuis l'Internet arrives sur `wg0`, zero reponse, jusqu'a `replyto: RELAIS_GW`.
# C'est aussi la sortie des locataires repris : tout leur trafic passe par le relais, pour
# qu'ils gardent UNE adresse vue de l'exterieur (decision de Daniel, 2026-10-13).
opnsense_face_publique:
  interface: opt9
  passerelle: RELAIS_GW

# L'adresse publique du SITE — relayee, comme les autres.
opnsense_wan_ip: 51.79.45.193
# Le pool des locataires, pour une reprise. Un locataire repris ici RECOIT cette adresse par
# le contrat du site (`make site-intrants`) a la place de celle qu'il a au site de Chezlepro.
opnsense_ips_publiques:
  51.79.45.194: OPS-Chezlepro
  51.79.58.151: OPS-Technolibre

# LE LIEN ENTRE LES SITES (2026-10-14) — le tunnel `inter-sites` vers SITE-Chezlepro. Par lui passe la
# replication du DNS public (`dns_public_pairs`, actif des deux cotes). Le prochain saut est
# la `frontiere_pair` de la carte ; les regles et les routes, le devis les derive.
opnsense_liens_sites:
  - site: SITE-Chezlepro
    interface: opt10   # INTERSITES, `wg1` — mesure le 2026-10-13