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