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>
63 lines
3.2 KiB
Markdown
63 lines
3.2 KiB
Markdown
# 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.
|