Daniel Allaire f9e45b1676 relais : la face publique d'un site sans adresse fixe, et le site de reprise de TechnoLibre

Le site de TechnoLibre n'a qu'une adresse DHCP. Trois adresses fixes sont louees sur un VPS
(le relais), qui repond a l'ARP pour elles et les route en /32 dans un tunnel WireGuard que la
frontiere initie. Aucune traduction : l'adresse du client arrive intacte.

- underlay.py : `tunnel: wireguard` dispense de VLAN ; role d'hote `relais`.
- devis_opnsense.py : `opnsense_face_publique`. Les entrees publiques s'y posent avec
  reply-to ; les sorties des locataires du pool passent par le relais ; une redirection n'y
  vise plus `wanip`. Le devis de Chezlepro est identique au caractere pres.
- appliquer_opnsense.py : replyto et gateway transmis et dans l'identite (seulement s'ils
  existent) ; le NAT sortant en mode automatic arrete l'application au lieu de dupliquer.
- role serveur_relais, inventorie depuis la carte comme un hyperviseur ; cle privee dans la
  voute du site. Deploye, idempotent.
- site_inventaire.py : les hyperviseurs ne sont plus filtres sur 192.168.11. ; site-appliquer
  charge la voute designee par SETOPS_UNDERLAY ; voute.py n'exige plus d'un locataire un
  secret du site.
- prouver.py : P67 lit le plan par underlay.plan_site() ; P53 couvre la face publique.
- Tests : test_underlay_tunnel, test_face_publique_relais, test_mode_nat_sortant.

95 preuves (make verifier), make test passe. CHANGELOG 144 et 145.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

2026-10-13 21:20:04 -04:00

3.2 KiB

Raw Blame History

serveur_relais

La face publique d'un site qui n'a qu'une adresse DHCP. Un VPS loue des adresses fixes, répond à l'ARP de son hébergeur pour elles (proxy ARP) et les route en /32 dans un tunnel WireGuard que la frontière du site initie. Aucune traduction d'adresse : les adresses arrivent intactes sur la frontière, qui les porte et qui filtre. L'adresse du client reste visible de bout en bout (courriel, journaux, blocage des abus).

Internet ──► hébergeur (ARP « qui a 51.79.x ? ») ──► relais : « c'est moi » (proxy ARP)
         ──► route /32 vers wg0 ──► tunnel ──► frontière (porte les adresses, filtre)

Né le 2026-10-13 au site de TechnoLibre (VPS OVH, Debian 13, frontière requin).

Ce que le rôle pose

Fichier	Rôle
`/etc/wireguard/wg0.conf`	le tunnel ; routes /32 et proxy ARP en `PostUp`, sans `Table`
`/etc/wireguard/relais.key`	la clé privée, depuis la voûte du site
`/etc/nftables.conf`	entrée : SSH et tunnel sur la console seulement ; transit : les adresses relayées, dans chaque sens, rien d'autre
`/etc/sysctl.d/90-relais.conf`	`ip_forward`
`/etc/systemd/resolved.conf.d/90-relais.conf`	LLMNR et mDNS coupés (ils écoutaient sur l'adresse publique)

Le relais ne décide d'aucun service : il ne connaît que des adresses. Ce qui est publié, et à qui, se décide sur la frontière (devis_opnsense.py, opnsense_face_publique).

D'où viennent les valeurs

Toutes dérivées par scripts/site_inventaire.py ; aucune n'est à recopier.

Variable	Source
`serveur_relais_tunnel_adresse`, `serveur_relais_tunnel_mtu`	hôte `role: relais` et réseau `tunnel: wireguard` de `underlay.yml`
`serveur_relais_tunnel_port`	51800 + index du site
`serveur_relais_pair_*`	hôte `role: frontiere` du même réseau, avec sa `cle_publique`
`serveur_relais_adresses_relayees`	`opnsense_wan_ip` + `opnsense_ips_publiques` de `opnsense.yml`
`serveur_relais_cle_privee`	`vault_relais_wg_cle_privee`, voûte du site
`ansible_host`	`console:` de l'hôte relais — jamais une adresse relayée

Le relais n'est pas dans plan/serveurs.yml : tout ce qu'une machine du plan reçoit descend des zones du site, que le VPS n'atteint pas. Comme un hyperviseur, c'est un équipement de la carte.

Ce qui reste hors du rôle

Côté frontière (OPNsense) : l'instance WireGuard, l'interface, la passerelle et les adresses virtuelles se posent par l'API, une fois. Le devis y pose ensuite les règles avec reply-to (voir test_face_publique_relais.py).
La supervision : le relais est hors du site et ne joint pas sa supervision. Ce qui le dit vivant aujourd'hui, c'est la passerelle RELAIS_GW de la frontière (surveillée par ping à travers le tunnel). Une sonde propre au rôle reste à écrire.
Le durcissement commun (serveur_durci) : il dérive son pare-feu des zones du site et écraserait celui du relais. Non appliqué ici.

Déployer

SETOPS_UNDERLAY=../SITE-<site>/underlay.yml make site-appliquer GROUPE=serveur_relais ARGS="--check --diff"

Le pare-feu est validé (nft -c) avant d'être posé : la seule porte du VPS est son SSH.

3.2 KiB Raw Blame History