Daniel Allaire
aab1bcc83a
README reduit au role du projet et au demarrage rapide. docs/architecture.md (schemas Mermaid), docs/setup.md, docs/usage.md (154 cibles en 13 familles), docs/README.md (index). Documents ranges en conception/, exploitation/, hebergement/, projet/ ; 598 chemins suivis. QUICKSTART.md, SOLUTION.md, architecture-set-ops.md et la carte fondus puis retires. Preuves : P48 lit l'index et conception/mecanismes.md ; les gardes parcourent docs/ sous- dossiers compris (_documents) ; usage.md suit le Makefile dans les deux sens. 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.