Daniel Allaire
f9e45b1676
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> |
||
|---|---|---|
| .. | ||
| defaults | ||
| handlers | ||
| meta | ||
| tasks | ||
| templates | ||
| README.md | ||
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(voirtest_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_GWde 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.