Creare un cluster VPS privato con una mesh WireGuard

In breve: per trasformare più VPS in un cluster privato, assegna a ogni nodo VPS un'interfaccia WireGuard con un indirizzo di un'unica subnet privata, aggiungi ogni altro nodo come `[Peer]` con il suo `Endpoint` pubblico e un `/32` in `AllowedIPs`, consenti UDP 51820 solo dai tuoi nodi e lega database e servizi interni all'indirizzo di `wg0` invece che all'IP pubblico. Fino a una decina di nodi è facile da gestire a mano o con un template; oltre, usa strumenti che generano e distribuiscono le configurazioni.

Questa guida presuppone che tu conosca già le basi dalla guida alla VPN WireGuard e che abbia protetto SSH su ogni nodo come nella guida all'hardening SSH; per raggiungere i nodi tramite un bastion senza agent forwarding, vedi la guida a StrictModes e agent forwarding.

Piano di indirizzamento per i nodi VPN

Scegli un unico range privato che non entri in conflitto con nient'altro che usi (LAN di casa, Docker, range dei pod Kubernetes). Una `/24` basta per un cluster piccolo e mantiene gli indirizzi leggibili. Assegna a ogni nodo un indirizzo fisso e tieni il piano sotto controllo di versione, perché ogni configurazione deriva da esso.

Configurazione per peer su ogni nodo VPS

In una mesh completa ogni nodo parla direttamente con ogni altro nodo, quindi ogni configurazione ha un `[Interface]` e N-1 sezioni `[Peer]`. Quattro nodi significano sei tunnel in totale; dieci nodi ne significano 45. Ogni nodo ha un IP pubblico, quindi di solito `PersistentKeepalive` non serve; i dettagli sono nella guida a keepalive e PresharedKey.

1. 01.Su ogni nodo esegui `apt install wireguard`, poi `umask 077; wg genkey | tee /etc/wireguard/wg0.key | wg pubkey > /etc/wireguard/wg0.pub`.
2. 02.Raccogli in un unico posto tutte le chiavi pubbliche e il piano di indirizzamento.
3. 03.Facoltativamente genera una chiave `wg genpsk` per ogni coppia di nodi come protezione post-quantistica.
4. 04.Scrivi `/etc/wireguard/wg0.conf` su ogni nodo come mostrato sotto.
5. 05.Esegui `systemctl enable --now wg-quick@wg0` e verifica con `wg show` un handshake recente con ogni peer.

# /etc/wireguard/wg0.conf on node1
[Interface]
Address = 10.88.0.1/24
ListenPort = 51820
PrivateKey = <node1 private key>

[Peer]
# node2
PublicKey = <node2 public key>
Endpoint = 203.0.113.12:51820
AllowedIPs = 10.88.0.2/32

[Peer]
# node3
PublicKey = <node3 public key>
Endpoint = 203.0.113.13:51820
AllowedIPs = 10.88.0.3/32

[Peer]
# node4
PublicKey = <node4 public key>
Endpoint = 203.0.113.14:51820
AllowedIPs = 10.88.0.4/32

Come funziona AllowedIPs in una mesh

`AllowedIPs` svolge due compiti contemporaneamente. In uscita è una tabella di routing: i pacchetti per `10.88.0.3` vanno al peer che elenca `10.88.0.3/32`. In ingresso è una lista di accesso: un pacchetto in arrivo da quel peer viene accettato solo se il suo indirizzo sorgente rientra negli `AllowedIPs` di quel peer. Ecco perché ogni peer riceve esattamente il proprio `/32`, non l'intera `/24`.

La `/24` nella riga `Address` crea solo la route del kernel per la subnet su `wg0`; poi è WireGuard a scegliere il peer giusto per ogni destinazione.

• ▹Due peer non devono mai condividere range `AllowedIPs` sovrapposti sulla stessa interfaccia; vince l'ultimo.
• ▹Se un nodo instrada anche una subnet privata (per esempio Docker su node3), aggiungi quella subnet agli `AllowedIPs` di node3 sugli altri nodi.
• ▹Non mettere `0.0.0.0/0` in un peer della mesh a meno che tu non voglia davvero far uscire tutto il traffico da quel nodo.

Firewall: solo i tuoi nodi raggiungono il tunnel

WireGuard non risponde ai pacchetti non autenticati, ma limitare UDP 51820 agli IP noti dei nodi riduce comunque il rumore. Dentro il tunnel apri solo le porte di cui ogni servizio ha bisogno. Questo esempio nftables per Debian 12/13 e Ubuntu 24.04 va in `/etc/nftables.conf`; caricalo con `nft -f /etc/nftables.conf` e abilita `nftables.service`. Tieni aperta una sessione SSH mentre fai le prove.

table inet filter {
  set mesh_peers {
    type ipv4_addr
    elements = { 203.0.113.11, 203.0.113.12, 203.0.113.13, 203.0.113.14 }
  }
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif lo accept
    meta l4proto { icmp, ipv6-icmp } accept
    tcp dport 22 accept
    udp dport 51820 ip saddr @mesh_peers accept
    iifname "wg0" ip saddr 10.88.0.0/24 tcp dport { 5432, 6379, 9100 } accept
  }
}

Lega i servizi all'interfaccia wg

Il firewall è un livello; il secondo è non mettersi affatto in ascolto sull'indirizzo pubblico. Lega i servizi interni all'indirizzo `wg0` del nodo così un errore nel firewall non li espone. Poiché `wg0` deve esistere prima che il servizio si metta in ascolto, ordina le unit con un drop-in systemd, oppure consenti il bind su indirizzi non ancora attivi con `net.ipv4.ip_nonlocal_bind = 1`.

# PostgreSQL on node3: postgresql.conf
listen_addresses = '10.88.0.3'
# pg_hba.conf
host  all  all  10.88.0.0/24  scram-sha-256

# Redis: /etc/redis/redis.conf
bind 10.88.0.3

# systemctl edit postgresql  (repeat for other services)
[Unit]
[email protected]
[email protected]

Note · Controlla il risultato con `ss -tlnp`: i servizi interni devono mostrare `10.88.0.x`, mai `0.0.0.0` o l'IP pubblico.

Scalare: quando passare agli strumenti

Una mesh scritta a mano va bene finché i nodi sono pochi e le modifiche rare. Ogni nuovo nodo significa modificare tutte le configurazioni esistenti, quindi il lavoro cresce in modo quadratico. Quando diventa un peso, genera le configurazioni invece di scriverle.

Su NoctisNode tutti i nuovi nodi VPS vengono attivati in FI-1 (Finlandia), ciascuno con un IPv4 dedicato e una porta da 1 Gbps senza limiti di traffico, e la fatturazione oraria insieme all'agent API (con TTL di autodistruzione) rende economico aggiungere e rimuovere nodi di test. I piani partono dal livello Wisp; vedi piani VPS.

FAQ