VPN site-to-site con WireGuard: unire due reti (guida 2026)

Avviso di affiliazione — Questo articolo contiene link di affiliazione Contabo. Se ordini un VPS tramite essi, guadagniamo una commissione senza costi aggiuntivi per te. Tutti i comandi e le configurazioni qui sotto sono documentati dalle fonti ufficiali WireGuard e scritti per essere riproducibili sulle tue macchine.

Una VPN site-to-site unisce due intere reti perché si comportino come una sola. Ogni host della LAN dell'ufficio può raggiungere ogni host della LAN di casa — il tuo NAS, una stampante, un hypervisor, un database — senza installare un client VPN su ciascun dispositivo. WireGuard lo rende leggero e veloce: una sola porta UDP, poche righe di configurazione, crittografia in spazio kernel. Questa guida costruisce un tunnel WireGuard site-to-site funzionante da zero, poi spiega le tre cose che si sbagliano sempre: AllowedIPs, l'inoltro IP e il routing degli host.

Useremo una topologia concreta e comune: il Sito A è una LAN domestica o d'ufficio dietro NAT (nessun IP pubblico utilizzabile), e il Sito B è un VPS con IPv4 pubblico che fa da hub sempre attivo. La stessa configurazione unisce anche due case, due uffici o due data center — cambiano solo le sottoreti.

Site-to-site vs road-warrior: cosa cambia davvero

Se hai già configurato WireGuard per un portatile, il 90 % di tutto questo ti è familiare. Il cambio di mentalità è piccolo ma cruciale:

• Road-warrior (accesso remoto): un dispositivo entra nella rete. Il suo peer annuncia un singolo indirizzo di tunnel — AllowedIPs = 10.66.66.2/32.
• Site-to-site: un'intera rete entra. Il peer annuncia la sottorete LAN che ha dietro — AllowedIPs = 10.66.66.2/32, 192.168.10.0/24 — e la box WireGuard inoltra per ogni host di quella LAN.

Tutto il resto — chiavi, handshake, porta UDP — è identico. Se l'handshake non si completa mai, le cause sono le stesse di qualsiasi tunnel; segui la lista di soluzioni per l'handshake WireGuard prima di incolpare la parte site-to-site.

Pianifica prima lo spazio di indirizzamento (5 minuti che fanno risparmiare ore)

Prima di toccare una configurazione, scrivi tre intervalli. Sbagliare qui è la causa numero uno di un tunnel che si connette ma non trasporta traffico degli host.

La regola ferrea: le due LAN non devono sovrapporsi. Se entrambi i lati usano oggi 192.168.1.0/24, rinumera uno adesso. Un host non può instradare verso una sottorete remota identica alla propria — tratterà l'indirizzo come locale e non consegnerà mai il pacchetto a WireGuard. Se la matematica delle sottoreti ti sfugge, la nostra spiegazione di cos'è una subnet copre il CIDR in modo semplice.

Passo 1 — Predisporre l'hub (Sito B, il VPS)

Il Sito B ha bisogno di un IPv4 pubblico e di una porta UDP aperta. Usiamo un Contabo Cloud VPS 10 (4 vCPU, 8 GB RAM, 75 GB NVMe) a 5,50 €/mese sul piano da 12 mesi — sovradimensionato per un tunnel, comodo se esegue anche altri servizi. Se non hai ancora un VPS, prendi il Contabo Cloud VPS 10; scegli una regione vicina al sito che invia più traffico. Per un'installazione pulita di WireGuard, segui la guida passo passo Contabo + WireGuard, poi torna qui per il routing site-to-site.

Installa WireGuard e genera le chiavi sul VPS:

sudo apt update && sudo apt install -y wireguard
umask 077
wg genkey | tee siteB.key | wg pubkey > siteB.pub

Passo 2 — Predisporre il router WireGuard al Sito A

La box WireGuard del Sito A è una qualsiasi macchina Linux sempre accesa della LAN — un Raspberry Pi, una piccola VM, un vecchio portatile. Non serve un IP pubblico; compone verso il VPS. Genera le sue chiavi allo stesso modo:

wg genkey | tee siteA.key | wg pubkey > siteA.pub

Questa macchina diventa il gateway della sottorete remota, quindi deve inoltrare i pacchetti tra la sua interfaccia LAN e l'interfaccia WireGuard.

Passo 3 — Le due configurazioni

Ecco l'intero tunnel. Nota come l'AllowedIPs di ciascun lato elenca la LAN dell'altro sito — è quella riga a trasformare un collegamento punto-punto in un collegamento rete-rete.

Sito B — l'hub VPS (/etc/wireguard/wg0.conf):

[Interface]
Address = 10.66.66.1/24
ListenPort = 51820
PrivateKey = <siteB.key>
# forward + masquerade perché anche gli host del Sito A raggiungano internet tramite il VPS
PostUp = sysctl -w net.ipv4.ip_forward=1
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# Sito A
PublicKey = <siteA.pub>
AllowedIPs = 10.66.66.2/32, 192.168.10.0/24

Sito A — il router LAN (/etc/wireguard/wg0.conf):

[Interface]
Address = 10.66.66.2/24
PrivateKey = <siteA.key>
PostUp = sysctl -w net.ipv4.ip_forward=1
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT

[Peer]
# Sito B (l'hub VPS)
PublicKey = <siteB.pub>
Endpoint = 203.0.113.10:51820
AllowedIPs = 10.66.66.0/24, 192.168.20.0/24
PersistentKeepalive = 25

Due dettagli che contano:

• PersistentKeepalive = 25 va sul lato dietro NAT (Sito A). Invia un pacchetto minuscolo ogni 25 secondi affinché il router domestico tenga aperto il percorso UDP e il VPS possa sempre rispondere.
• Endpoint compare solo nel blocco peer del Sito A — è il Sito A a chiamare il VPS. Il VPS apprende l'indirizzo del Sito A all'arrivo del primo pacchetto, quindi il suo blocco peer non ha Endpoint.

Avvia entrambi i tunnel con sudo wg-quick up wg0 e controlla sudo wg show. Un latest handshake di meno di due minuti su entrambi i lati significa che il collegamento è vivo.

Passo 4 — Il passo che tutti dimenticano: il routing degli host

È qui che la maggior parte dei tunnel site-to-site si blocca. I router si fanno ping su 10.66.66.x, ma un portatile del Sito A continua a non raggiungere un NAS del Sito B. Perché? Perché gli altri host di ogni LAN non sanno che la box WireGuard è la porta verso la sottorete remota. Inviano il pacchetto al loro gateway predefinito, che non ha rotta per 192.168.20.0/24, e muore.

Hai due modi puliti per risolvere:

1. Rotta statica sul gateway della LAN (il migliore). Sul router principale del Sito A, aggiungi una rotta statica: destinazione 192.168.20.0/24, gateway = l'IP LAN della box WireGuard del Sito A (es. 192.168.10.5). Specchia lo stesso al Sito B. Ora ogni host eredita la rotta automaticamente. La maggior parte dei router domestici e professionali supporta le rotte statiche nel pannello di amministrazione.
2. Rotte statiche per host. Se non puoi toccare il router, aggiungi una rotta su ogni macchina che deve accedere all'altro sito:

# su un host del Sito A, raggiungere la LAN del Sito B tramite la box WireGuard locale
sudo ip route add 192.168.20.0/24 via 192.168.10.5

Se la box WireGuard è il gateway predefinito della tua LAN, puoi saltare del tutto questo passo — inoltra già. Concettualmente è un problema di routing, non di VPN; la stessa logica del port forwarding ma applicata a un'intera sottorete invece che a una sola porta.

Passo 5 — Firewall sul percorso di inoltro

Inoltrare senza regola di firewall significa lasciar passare o niente o tutto. Sii esplicito. Sull'hub VPS, il PostUp qui sopra accetta già il traffico inoltrato da wg0; stringilo se vuoi che parlino solo certe sottoreti:

# permetti solo LAN Sito A <-> LAN Sito B, scarta il resto
iptables -A FORWARD -s 192.168.10.0/24 -d 192.168.20.0/24 -i wg0 -j ACCEPT
iptables -A FORWARD -s 192.168.20.0/24 -d 192.168.10.0/24 -o wg0 -j ACCEPT

Rendi le regole persistenti (iptables-save, o netfilter-persistent save su Debian/Ubuntu) perché sopravvivano a un riavvio. Anche la singola porta UDP deve essere aperta davanti al VPS — vedi quale porta usa WireGuard e come aprirla se l'handshake non parte mai.

Verificare l'intero percorso

Esegui questi in ordine e fermati al primo fallimento:

1. Tunnel attivo? sudo wg show a entrambe le estremità → latest handshake recente, transfer diverso da zero.
2. Router a router? Dalla box WireGuard del Sito A: ping 10.66.66.1. Fallisce → è un problema di tunnel, non di site-to-site.
3. Router verso LAN remota? Dalla box del Sito A: ping 192.168.20.1. Fallisce → AllowedIPs o ip_forward sul Sito B.
4. Host verso host remoto? Da un portatile del Sito A: ping 192.168.20.50. Fallisce qui ma il passo 3 funzionava → routing degli host (passo 4).

Questa scala in quattro righe isola in meno di un minuto il livello esatto che è rotto.

Quando aggiungere altri siti — hub-and-spoke

Per unire tre reti o più, mantieni il VPS come hub centrale e aggiungi ogni nuova LAN come peer spoke su di esso. Ogni spoke elenca tutte le altre sottoreti LAN nel suo AllowedIPs (instradate via hub), e l'hub elenca la LAN di ogni spoke. Questo resta semplice fino a una manciata di siti. Oltre — o se vuoi rotazione automatica delle chiavi, ACL e attraversamento del NAT senza IP pubblico da nessun lato — un piano di controllo a mesh come Tailscale o Headscale è meno lavoro che modificare i peer a mano; valutalo nel nostro confronto Tailscale vs WireGuard self-host.

Perché auto-ospitare l'hub invece di un servizio gestito

Un collegamento site-to-site è esattamente il punto in cui possedere la box ripaga: niente prezzo per postazione, niente limiti di dati, nessun terzo nel percorso tra le tue due reti. Un Contabo Cloud VPS 10 a 5,50 €/mese offre IPv4 pubblico, root completo, traffico illimitato (fair-use) e la libertà di aprire l'unica porta UDP che ti serve — l'hub sempre attivo ideale per legare i tuoi siti. Costruiscilo una volta e gira per anni.

Per approfondire

• VPN autogestito su Contabo: guida completa a WireGuard 2026
• L'handshake WireGuard non si completa: la lista completa di soluzioni
• Cos'è una subnet? Subnetting e CIDR spiegati
• Il port forwarding spiegato: raggiungere un server dietro il router
• Tailscale vs WireGuard self-host: quale scegliere
• Modelli di configurazione WireGuard pronti all'uso 2026

Fonti e riferimenti:

• Whitepaper WireGuard — Jason A. Donenfeld
• Quickstart WireGuard e docs wg-quick
• Manpage wg(8) e wg-quick(8)
• Arch Wiki — WireGuard (routing & site-to-site)

Pubblicato il 2026-06-26. Topologia validata su Debian 12 e Ubuntu 24.04 con un hub Contabo Cloud VPS 10 e un router LAN Raspberry Pi. Le tue sottoreti, i modelli di router e il comportamento NAT del tuo ISP saranno diversi — conferma sempre ogni livello con wg show, ping e ip route prima di considerare finale una configurazione.

Promemoria: eseguire WireGuard e auto-ospitare una VPN è legale nell'UE, negli USA, in Canada e nella maggior parte dei paesi democratici. VPNSmith pubblica questo contenuto a scopo educativo.