Server WireGuard VPN su Ubuntu: 12 Step [2026]

Una VPN aziendale costruita su OpenVPN porta con sé migliaia di righe di codice, certificati X.509 difficili da gestire e una latenza che si fa sentire. WireGuard ribalta questo modello: circa 4.000 righe di codice nel kernel Linux, una manciata di primitive crittografiche moderne e un tunnel che si stabilisce in 1,5 round trip. Nel 2026 è diventato lo standard di fatto per chi vuole una VPN veloce, verificabile e facile da mantenere.

Questa guida ti porta passo dopo passo dalla macchina Ubuntu 24.04 LTS appena installata fino a un server WireGuard funzionante, con il primo client connesso, il NAT configurato e una chiave precondivisa per irrobustire il tunnel contro le minacce future. Trovi 12 step concreti, oltre 6 blocchi di codice pronti all’uso, gli errori più comuni e una sezione di troubleshooting con 8 casi reali. Tempo stimato: circa 30 minuti.

WireGuard nel 2026: la VPN che ha riscritto le regole

WireGuard è entrato ufficialmente nel kernel Linux con la versione 5.6 e da allora è il modulo VPN di riferimento per i sistemi Linux. Su Ubuntu 24.04 LTS il modulo è già compilato nel kernel: non serve installare DKMS né ricompilare nulla. Questo cambia radicalmente l’esperienza rispetto a OpenVPN, dove ogni aggiornamento di kernel poteva rompere il tunnel.

La filosofia di WireGuard è la minimalità. Mentre OpenVPN espone decine di opzioni configurabili (cifrari, modalità, compressione, autenticazione), WireGuard fissa un’unica suite crittografica moderna e non permette di sceglierla. Questa rigidità è un vantaggio di sicurezza: non esistono configurazioni deboli da evitare, non c’è negoziazione del cifrario da attaccare, non ci sono downgrade possibili. Il risultato è una superficie d’attacco ridotta all’osso e un codice abbastanza piccolo da essere stato sottoposto ad audit formale.

Il modello operativo è altrettanto snello. WireGuard non ha il concetto di “connessione” o “sessione” nel senso classico. Ogni interfaccia conosce un elenco di peer, identificati dalla loro chiave pubblica, e per ciascun peer sa quali indirizzi IP sono ammessi. Quando arriva un pacchetto cifrato, WireGuard verifica la firma, controlla che l’IP sorgente rientri negli AllowedIPs di quel peer e instrada di conseguenza. Questa associazione tra chiave pubblica e indirizzi ammessi si chiama cryptokey routing ed è il cuore del progetto.

Per chi gestisce infrastrutture, i benefici pratici sono concreti: roaming trasparente (un client che cambia rete mantiene il tunnel senza riconnettersi), assenza di stato sul server quando non c’è traffico, e una configurazione leggibile in pochi secondi. Se stai valutando l’alternativa al tunneling tradizionale o vuoi capire come si colloca rispetto ad altri strumenti di anonimato, il nostro confronto su Tor contro VPN chiarisce quando una VPN è la scelta giusta e quando serve altro.

Come funziona WireGuard: Noise, Curve25519 e ChaCha20

Per configurare bene un server WireGuard conviene capire cosa succede sotto il cofano. WireGuard si basa sul Noise Protocol Framework, lo stesso impianto crittografico usato da Signal per la messaggistica sicura. L’handshake è di tipo Noise IK e si completa in circa 1,5 round trip, contro i molti scambi necessari a TLS in OpenVPN. Questo handshake leggero è il motivo per cui WireGuard si riconnette quasi istantaneamente quando un dispositivo passa dal Wi-Fi alla rete mobile.

La suite crittografica è fissa e composta da cinque mattoni, ciascuno scelto per velocità e robustezza:

Primitiva	Funzione	Perché è stata scelta
Curve25519	Scambio di chiavi (ECDH)	Curva ellittica veloce e resistente agli attacchi a canale laterale
ChaCha20	Cifratura del traffico	Veloce in software, non richiede accelerazione hardware AES
Poly1305	Autenticazione (MAC)	Garantisce integrità e autenticità di ogni pacchetto
BLAKE2s	Hashing	Più veloce di SHA-2 con pari livello di sicurezza
SipHash	Hash delle tabelle interne	Protegge dalle collisioni mirate nelle strutture dati

La combinazione ChaCha20-Poly1305 è una cifratura autenticata (AEAD): in un’unica operazione cifra il payload e ne garantisce l’integrità. Se anche un solo bit del pacchetto viene alterato in transito, Poly1305 lo rileva e il pacchetto viene scartato in silenzio. WireGuard non risponde mai a pacchetti non validi, una caratteristica che lo rende invisibile agli scanner di rete: una porta WireGuard non rivela la propria esistenza a chi non possiede la chiave corretta.

Ogni handshake genera nuove chiavi di sessione effimere, garantendo la perfect forward secrecy: se un attaccante compromette le chiavi di oggi, non può decifrare il traffico catturato ieri. Le chiavi di sessione vengono inoltre rinnovate automaticamente ogni due minuti circa. Per approfondire i principi crittografici che reggono questi sistemi, abbiamo spiegato la crittografia end-to-end in un tutorial dedicato.

WireGuard contro OpenVPN: prestazioni a confronto

La differenza di prestazioni è il motivo principale per cui molte aziende stanno migrando. WireGuard gira nello spazio del kernel su Linux, evita i passaggi di contesto verso lo spazio utente che rallentano OpenVPN e usa una crittografia ottimizzata per le CPU moderne. Il risultato pratico è un throughput più alto e una latenza più bassa, soprattutto su hardware senza accelerazione AES.

Caratteristica	WireGuard	OpenVPN
Righe di codice	circa 4.000	oltre 100.000
Posizione	Kernel space (Linux)	User space
Protocollo di trasporto	UDP (51820 di default)	UDP o TCP
Handshake	circa 1,5 round trip	negoziazione TLS completa
Cifratura	ChaCha20-Poly1305 (fissa)	configurabile (AES, ecc.)
Riconnessione su cambio rete	trasparente (roaming)	richiede ristabilimento
Configurazione tipica	poche righe per peer	certificati X.509 e file multipli

Le cifre esatte di throughput dipendono da molti fattori: CPU del server, presenza di accelerazione crittografica, dimensione dei pacchetti e percorso di rete. La regola generale verificabile è che WireGuard offre throughput superiore e overhead inferiore rispetto a OpenVPN sulla stessa macchina, grazie all’esecuzione nel kernel e a una progettazione crittografica più semplice. Per un confronto numerico più dettagliato tra i due protocolli, rimandiamo all’analisi tecnica disponibile sul sito ufficiale del progetto.

Un punto a favore di OpenVPN resta la capacità di girare su TCP/443, indistinguibile dal traffico HTTPS, utile dove WireGuard su UDP viene bloccato. Per la stragrande maggioranza dei casi d’uso (VPN aziendale, accesso remoto, tunneling tra server) WireGuard è oggi la scelta più sensata.

Prerequisiti e versioni richieste

Prima di iniziare, assicurati di avere a disposizione tutto il necessario. Questa guida è stata scritta e testata su Ubuntu 24.04 LTS, ma i comandi funzionano con minime variazioni anche su Debian 12 e Ubuntu 22.04 LTS.

Un server con Ubuntu 24.04 LTS (un VPS o una macchina con IP pubblico statico). Il modulo WireGuard è già nel kernel a partire da Linux 5.6.
Accesso root o un utente con privilegi sudo. Tutti i comandi che modificano la rete richiedono privilegi amministrativi.
Pacchetti wireguard e wireguard-tools dai repository ufficiali Ubuntu. Forniscono wg e wg-quick.
Una porta UDP aperta verso l’esterno (51820 di default) sul firewall del provider e su quello locale.
Un client su cui installare WireGuard: Linux, Windows, macOS, Android o iOS. L’app ufficiale è disponibile per tutte le piattaforme.
Conoscenza di base della riga di comando Linux e dei concetti di rete (indirizzo IP, subnet, gateway).

Verifica subito la versione del kernel e l’architettura con un comando rapido. Se vedi un kernel 5.6 o superiore (Ubuntu 24.04 monta la serie 6.8), sei a posto.

uname -r
# Output atteso su Ubuntu 24.04 LTS:
# 6.8.0-71-generic

lsb_release -a
# Distributor ID: Ubuntu
# Description:    Ubuntu 24.04 LTS
# Release:        24.04
# Codename:       noble

Step 1-2: Installare WireGuard su Ubuntu 24.04

Il primo passo è aggiornare l’indice dei pacchetti e installare WireGuard. Su Ubuntu 24.04 LTS bastano i pacchetti dai repository ufficiali. Non serve aggiungere PPA né compilare nulla.

# Step 1: aggiorna l'indice dei pacchetti
sudo apt update

# Step 2: installa WireGuard e gli strumenti userspace
sudo apt install -y wireguard wireguard-tools

Il pacchetto wireguard è in realtà un metapacchetto che tira dentro wireguard-tools e, dove serve, il modulo. Su Ubuntu 24.04 il modulo kernel è già presente, quindi l’installazione è immediata. Verifica che tutto sia a posto controllando la versione degli strumenti userspace:

wg --version
# Output di esempio:
# wireguard-tools v1.0.x - https://git.zx2c4.com/wireguard-tools/

# Verifica che il modulo kernel sia disponibile
sudo modprobe wireguard
lsmod | grep wireguard
# wireguard             autorizzato
# Se compare la riga, il modulo è caricato correttamente.

Se wg --version restituisce un numero di versione e lsmod mostra il modulo, l’installazione è completa. In caso di errore “module not found”, aggiorna il sistema con sudo apt upgrade e riavvia: su un kernel aggiornato il modulo è sempre disponibile. Per conoscere la versione esatta del modulo caricato puoi usare modinfo wireguard, che mostra i metadati del modulo presente nel tuo kernel.

Una buona pratica è creare subito la directory di configurazione con permessi restrittivi, perché conterrà le chiavi private del server. WireGuard si aspetta i file in /etc/wireguard/.

# Imposta una umask restrittiva per i file che creeremo
sudo mkdir -p /etc/wireguard
sudo chmod 700 /etc/wireguard
umask 077

Step 3-4: Generare le chiavi crittografiche

WireGuard usa una coppia di chiavi Curve25519 per ogni dispositivo: una privata, che non deve mai lasciare la macchina, e una pubblica, da condividere con i peer. Genera la coppia del server con i comandi wg genkey e wg pubkey. La pipe collega i due: la chiave privata viene generata, salvata e immediatamente passata a wg pubkey per derivare quella pubblica.

# Step 3: genera la chiave privata del server e derivane la pubblica
cd /etc/wireguard
wg genkey | sudo tee server_private.key | wg pubkey | sudo tee server_public.key

# Proteggi la chiave privata da letture non autorizzate
sudo chmod 600 server_private.key

# Visualizza le chiavi generate
sudo cat server_private.key
# Esempio: 8Fz...stringa base64 di 44 caratteri...=
sudo cat server_public.key
# Esempio: HIg...stringa base64 di 44 caratteri...=

Ogni chiave è una stringa base64 di 44 caratteri. La chiave privata del server è il segreto più importante dell’intera installazione: chiunque la possieda può impersonare il server. Per questo le abbiamo dato permessi 600 (lettura e scrittura solo per root).

Genera ora anche la coppia di chiavi per il primo client. Puoi generarla sul server e poi trasferire la parte privata al client in modo sicuro, oppure generarla direttamente sul client. In questa guida la generiamo sul server per semplicità, ma ricorda di cancellare la chiave privata del client dal server dopo averla trasferita.

# Step 4: genera la coppia di chiavi del primo client
wg genkey | sudo tee client1_private.key | wg pubkey | sudo tee client1_public.key
sudo chmod 600 client1_private.key

# Genera anche la chiave precondivisa (preshared key) per questo peer
wg genpsk | sudo tee client1_psk.key
sudo chmod 600 client1_psk.key

La chiave precondivisa generata con wg genpsk è un segreto simmetrico aggiuntivo, opzionale ma raccomandato. La useremo allo Step 11 per aggiungere uno strato di difesa contro le minacce post-quantistiche. I principi alla base di queste chiavi simmetriche sono gli stessi che trovi nel nostro confronto sui servizi di posta cifrata, dove la gestione delle chiavi fa la differenza.

Step 5: Configurare l’interfaccia del server (wg0.conf)

Ora creiamo il file di configurazione dell’interfaccia del server, che per convenzione si chiama wg0. Il file /etc/wireguard/wg0.conf definisce l’indirizzo del tunnel, la porta di ascolto, la chiave privata del server e le regole di NAT. Apri il file con il tuo editor preferito.

sudo nano /etc/wireguard/wg0.conf

Incolla la configurazione seguente, sostituendo CHIAVE_PRIVATA_SERVER con il contenuto del file server_private.key e eth0 con il nome della tua interfaccia di rete pubblica (verificalo con ip route get 8.8.8.8).

[Interface]
# Indirizzo del server all'interno della rete VPN
Address = 10.10.10.1/24
# Porta UDP su cui WireGuard ascolta
ListenPort = 51820
# Chiave privata del server (contenuto di server_private.key)
PrivateKey = CHIAVE_PRIVATA_SERVER

# Abilita il NAT all'avvio del tunnel
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
# Rimuove le regole quando il tunnel viene fermato
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -D FORWARD -o wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

# I peer (client) verranno aggiunti piu' avanti

Analizziamo le righe chiave. Address = 10.10.10.1/24 assegna al server l’indirizzo 10.10.10.1 dentro una subnet privata dedicata alla VPN: i client useranno 10.10.10.2, 10.10.10.3 e così via. ListenPort = 51820 è la porta UDP standard di WireGuard. Le direttive PostUp e PostDown eseguono le regole iptables che instradano e mascherano il traffico, attivandole quando il tunnel sale e rimuovendole quando scende, così da non lasciare regole orfane.

La regola MASQUERADE è ciò che permette ai client di navigare in internet attraverso il server: traduce gli indirizzi privati della VPN nell’IP pubblico del server, esattamente come fa un router domestico. Senza questa regola i pacchetti dei client uscirebbero con indirizzo sorgente 10.10.10.x e nessuna risposta tornerebbe indietro.

Step 6: Abilitare l’IP forwarding e il NAT

Di default il kernel Linux non inoltra i pacchetti tra interfacce diverse: si comporta come un host, non come un router. Per trasformare il server in un gateway VPN dobbiamo abilitare l’IP forwarding. È uno degli step più dimenticati e una causa frequente di tunnel che si connettono ma non lasciano navigare.

# Abilita l'inoltro IPv4 subito (non persistente)
sudo sysctl -w net.ipv4.ip_forward=1

# Rendi la modifica permanente al riavvio
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-wireguard.conf

# Se usi anche IPv6, aggiungi:
echo 'net.ipv6.conf.all.forwarding=1' | sudo tee -a /etc/sysctl.d/99-wireguard.conf

# Applica le impostazioni dal file
sudo sysctl -p /etc/sysctl.d/99-wireguard.conf
# Output atteso:
# net.ipv4.ip_forward = 1

Il comando sysctl -w applica la modifica nella sessione corrente, ma viene persa al riavvio. Scrivendo la direttiva in un file dentro /etc/sysctl.d/ la rendiamo permanente. Abbiamo usato un file dedicato (99-wireguard.conf) invece di modificare /etc/sysctl.conf: è più pulito e facile da rimuovere se un giorno disinstalli la VPN.

Verifica che l’impostazione sia attiva leggendo direttamente il valore dal kernel. Un valore di 1 conferma che l’inoltro è abilitato:

cat /proc/sys/net/ipv4/ip_forward
# 1   ->  inoltro abilitato, tutto pronto
# 0   ->  inoltro disabilitato, ricontrolla i passaggi precedenti

Questo passaggio lavora in coppia con la regola MASQUERADE dello Step 5: l’IP forwarding consente al kernel di instradare i pacchetti tra l’interfaccia wg0 e quella pubblica, mentre il MASQUERADE riscrive l’indirizzo sorgente. Insieme trasformano il server in un gateway funzionante.

Step 7-8: Avviare il server e aprire la porta UDP 51820

Con la configurazione pronta e l’IP forwarding attivo, possiamo avviare il tunnel. Lo strumento wg-quick legge wg0.conf, crea l’interfaccia, applica le regole iptables e mette tutto online con un solo comando.

# Step 7: avvia il tunnel leggendo /etc/wireguard/wg0.conf
sudo wg-quick up wg0
# Output atteso:
# [#] ip link add wg0 type wireguard
# [#] wg setconf wg0 /dev/fd/63
# [#] ip -4 address add 10.10.10.1/24 dev wg0
# [#] ip link set mtu 1420 up dev wg0
# [#] iptables -A FORWARD -i wg0 -j ACCEPT; ...

# Verifica lo stato dell'interfaccia
sudo wg show
# interface: wg0
#   public key: HIg...=
#   private key: (hidden)
#   listening port: 51820

Nota che wg-quick imposta automaticamente l’MTU a 1420, valore prudente che lascia spazio per l’incapsulamento WireGuard ed evita la frammentazione dei pacchetti. Per abilitare l’avvio automatico al boot, usa systemd con il servizio dedicato che il pacchetto installa per te.

# Step 8: abilita l'avvio automatico al riavvio del server
sudo systemctl enable wg-quick@wg0
# Verifica che il servizio sia attivo
sudo systemctl status wg-quick@wg0
# Active: active (exited)

Resta da aprire la porta UDP 51820 sul firewall. Se usi UFW (il firewall predefinito di Ubuntu), il comando è immediato. Ricorda di aprire la porta anche nel pannello del tuo provider cloud, perché molti VPS hanno un firewall esterno separato.

# Apri la porta WireGuard su UFW
sudo ufw allow 51820/udp comment 'WireGuard VPN'

# Verifica le regole attive
sudo ufw status verbose | grep 51820
# 51820/udp    ALLOW    Anywhere    # WireGuard VPN

Se gestisci un firewall personalizzato o un reverse proxy, dai un’occhiata anche al nostro tutorial su Certbot e Let’s Encrypt per capire come orchestrare più servizi sulla stessa macchina senza conflitti di porta.

Step 9-10: Configurare il primo client (peer)

Il server è online ma non conosce ancora alcun client. WireGuard funziona in modo simmetrico: il server deve sapere quale chiave pubblica del client accettare, e il client deve sapere a quale server connettersi. Configuriamo entrambi i lati.

Step 9: aggiungi il peer al server. Apri di nuovo wg0.conf e, in fondo, aggiungi un blocco [Peer] con la chiave pubblica del client e l’indirizzo VPN che gli assegni.

# In coda a /etc/wireguard/wg0.conf
[Peer]
# Chiave pubblica del client (contenuto di client1_public.key)
PublicKey = CHIAVE_PUBBLICA_CLIENT1
# Chiave precondivisa per questo peer (contenuto di client1_psk.key)
PresharedKey = CHIAVE_PRECONDIVISA_CLIENT1
# Indirizzo VPN riservato a questo client, /32 = un solo IP
AllowedIPs = 10.10.10.2/32

Qui AllowedIPs = 10.10.10.2/32 dice al server: “accetta da questo peer solo i pacchetti che arrivano dall’indirizzo 10.10.10.2, e instrada verso di lui solo il traffico destinato a quell’IP”. Lato server, gli AllowedIPs agiscono come una whitelist di indirizzi sorgente, un controllo crittografico che impedisce a un peer di spacciarsi per un altro.

Step 10: crea la configurazione del client. Sul dispositivo client, crea un file wg0.conf (o importalo nell’app ufficiale). Sostituisci i segnaposto con le chiavi corrette e con l’IP pubblico del tuo server.

[Interface]
# Chiave privata del client (contenuto di client1_private.key)
PrivateKey = CHIAVE_PRIVATA_CLIENT1
# Indirizzo VPN del client
Address = 10.10.10.2/24
# DNS usato dal client mentre il tunnel e' attivo
DNS = 1.1.1.1

[Peer]
# Chiave pubblica del server (contenuto di server_public.key)
PublicKey = CHIAVE_PUBBLICA_SERVER
# Chiave precondivisa, identica a quella nel blocco [Peer] del server
PresharedKey = CHIAVE_PRECONDIVISA_CLIENT1
# IP pubblico del server e porta
Endpoint = IP_PUBBLICO_SERVER:51820
# 0.0.0.0/0 instrada TUTTO il traffico nel tunnel (full tunnel)
AllowedIPs = 0.0.0.0/0
# Mantiene viva la sessione attraverso il NAT
PersistentKeepalive = 25

Due righe meritano attenzione. AllowedIPs = 0.0.0.0/0 nel client significa “manda tutto il mio traffico internet attraverso la VPN” (configurazione full tunnel). Se invece volessi instradare solo la rete aziendale, useresti per esempio AllowedIPs = 10.10.10.0/24 (split tunnel). PersistentKeepalive = 25 invia un pacchetto vuoto ogni 25 secondi per mantenere aperta la mappatura NAT, indispensabile quando il client è dietro un router domestico o una rete mobile.

La riga DNS = 1.1.1.1 fa sì che il client risolva i nomi tramite un resolver esterno mentre il tunnel è attivo, evitando le fughe DNS verso il provider di accesso. Puoi puntare a un resolver pubblico orientato alla privacy o, meglio ancora, a un resolver che gestisci tu sul server VPN.

Step 11: Aggiungere il preshared key per la difesa post-quantum

WireGuard usa Curve25519, una curva ellittica oggi sicura ma teoricamente vulnerabile a un futuro computer quantistico abbastanza potente. Un attaccante potrebbe registrare oggi il traffico cifrato e decifrarlo domani, quando la crittografia a chiave pubblica verrà violata. È lo scenario “harvest now, decrypt later”.

La risposta di WireGuard è la chiave precondivisa (PresharedKey) che abbiamo generato allo Step 4. È un segreto simmetrico a 256 bit, condiviso fuori banda tra server e client, che viene mescolato nell’handshake in aggiunta allo scambio di chiavi Curve25519. Anche se un attaccante rompesse la crittografia a chiave pubblica con un computer quantistico, senza la chiave precondivisa non potrebbe decifrare il traffico, perché i 256 bit simmetrici restano fuori dalla portata degli algoritmi quantistici noti.

Abbiamo già inserito le righe PresharedKey nei blocchi [Peer] di server e client agli step precedenti. L’importante è che la stessa chiave compaia su entrambi i lati per quel peer. Verifica che corrispondano:

# Sul server, mostra la chiave precondivisa del client1
sudo cat /etc/wireguard/client1_psk.key
# La stessa stringa deve comparire nel campo PresharedKey
# sia nel blocco [Peer] del server sia nella config del client.

# Applica la nuova configurazione del server senza interrompere il tunnel
sudo wg syncconf wg0 <(sudo wg-quick strip wg0)

Il comando wg syncconf applica le modifiche al volo senza far cadere le connessioni esistenti, a differenza di wg-quick down seguito da up che interromperebbe tutti i tunnel. È il modo corretto di aggiornare la configurazione su un server di produzione con client attivi. La difesa post-quantistica è un tema che approfondiamo in altri contenuti del nostro canale dedicato alla privacy, dove spieghiamo perché iniziare a prepararsi ora è una scelta prudente.

Step 12: Verificare il tunnel e il traffico

Arrivati a questo punto, attiva il tunnel sul client (con wg-quick up wg0 su Linux o premendo “connetti” nell’app) e verifica che tutto funzioni. Il comando wg show sul server è il tuo cruscotto principale: mostra ogni peer, l’ultimo handshake e i byte trasferiti.

sudo wg show
# interface: wg0
#   public key: HIg...=
#   private key: (hidden)
#   listening port: 51820
#
# peer: CHIAVE_PUBBLICA_CLIENT1
#   preshared key: (hidden)
#   endpoint: 93.45.12.88:54210
#   allowed ips: 10.10.10.2/32
#   latest handshake: 18 seconds ago
#   transfer: 1.24 MiB received, 8.91 MiB sent

Le righe da controllare sono due. latest handshake deve mostrare un valore recente (pochi secondi o minuti): se è assente, l’handshake non è mai avvenuto e c’è un problema di chiavi, porta o firewall. transfer deve crescere mentre navighi dal client: se i byte ricevuti aumentano ma quelli inviati restano a zero, il traffico arriva al server ma non torna indietro, segno tipico di IP forwarding o MASQUERADE mancanti.

Dal client, esegui due test rapidi per confermare che la VPN funzioni e non ci siano fughe. Il primo verifica la connettività dentro il tunnel, il secondo conferma che il tuo IP pubblico è quello del server.

# 1. Verifica la connettivita' verso il server dentro il tunnel
ping -c 3 10.10.10.1
# 64 bytes from 10.10.10.1: icmp_seq=1 ttl=64 time=12.3 ms

# 2. Conferma che l'IP pubblico visto da internet sia quello del server
curl -s https://ifconfig.me
# Deve restituire l'IP pubblico del tuo server WireGuard,
# non quello della tua connessione locale.

Se il ping risponde e curl mostra l’IP del server, il tunnel è pienamente operativo: tutto il traffico del client passa cifrato attraverso WireGuard. Complimenti, hai un server VPN funzionante.

6 errori comuni da evitare

Questi sono gli errori che fanno perdere più tempo durante la configurazione di un server WireGuard. Conoscerli in anticipo ti risparmia ore di debug.

Dimenticare l’IP forwarding. Il tunnel si connette, il ping verso 10.10.10.1 funziona, ma internet non va. Nove volte su dieci la causa è net.ipv4.ip_forward a 0. È l’errore numero uno in assoluto.
Sbagliare il nome dell’interfaccia di rete. La regola MASQUERADE punta a eth0, ma sul tuo VPS l’interfaccia si chiama ens3 o enp1s0. Verifica sempre con ip route get 8.8.8.8 e correggi PostUp/PostDown.
Confondere chiave pubblica e privata. Nel blocco [Interface] va la chiave privata della macchina locale; nel blocco [Peer] va la chiave pubblica dell’altro lato. Invertirle impedisce l’handshake.
AllowedIPs troppo larghi sul server. Mettere AllowedIPs = 0.0.0.0/0 nel blocco [Peer] del server è un errore: significherebbe instradare tutto il traffico verso quel singolo client. Lato server usa sempre un /32 per peer.
Porta UDP chiusa nel firewall del provider. UFW può essere aperto, ma il firewall esterno del cloud (Security Group, ad esempio) blocca ancora la 51820. Controlla entrambi i livelli.
Permessi troppo aperti sulle chiavi. Lasciare server_private.key leggibile da tutti è un rischio di sicurezza grave. Imposta sempre chmod 600 e tieni la directory a 700.

Risoluzione dei problemi: 8 casi frequenti

Quando qualcosa non funziona, questa tabella ti porta dritto alla causa. Ogni riga associa un sintomo osservabile alla diagnosi più probabile e all’azione correttiva.

Sintomo	Causa probabile	Soluzione
Nessun “latest handshake” in `wg show`	Porta chiusa o chiave errata	Apri la 51820/udp su entrambi i firewall e ricontrolla le chiavi
Handshake presente ma niente internet	IP forwarding disabilitato	`sudo sysctl -w net.ipv4.ip_forward=1`
Byte ricevuti crescono, inviati a zero	Regola MASQUERADE mancante	Verifica l’interfaccia in `PostUp` e riavvia il tunnel
Il tunnel cade dopo qualche minuto	NAT che chiude la sessione	Aggiungi `PersistentKeepalive = 25` sul client
Le pagine web non caricano ma il ping va	Problema di MTU	Riduci l’MTU del client a 1380 o 1280
I siti risolvono lentamente o non risolvono	DNS non configurato nel tunnel	Aggiungi `DNS = 1.1.1.1` nel blocco `[Interface]`
`wg-quick` da’ “RTNETLINK File exists”	Interfaccia gia’ attiva	Esegui `sudo wg-quick down wg0` e poi `up`
“module wireguard not found”	Kernel non aggiornato	`sudo apt upgrade` e riavvia il server

Per un debug più profondo, abilita temporaneamente i log dettagliati del modulo kernel. WireGuard scrive nel ring buffer del kernel, leggibile con dmesg. Questo ti mostra eventuali errori di handshake o pacchetti scartati in tempo reale.

# Abilita il logging dinamico del modulo WireGuard
echo 'module wireguard +p' | sudo tee /sys/kernel/debug/dynamic_debug/control

# Osserva i messaggi del kernel in tempo reale
sudo dmesg -wT | grep wireguard
# Disabilita il logging quando hai finito:
echo 'module wireguard -p' | sudo tee /sys/kernel/debug/dynamic_debug/control

Se il problema riguarda l’MTU (pagine che non caricano mentre il ping funziona), il colpevole è quasi sempre la frammentazione su un percorso di rete con MTU ridotto, tipico delle connessioni PPPoE. Abbassare l’MTU del client risolve nella maggior parte dei casi.

Tecniche avanzate: nftables, più client e IPv6

Una volta che il tunnel di base funziona, vale la pena alzare l’asticella. Ecco le ottimizzazioni che usiamo sui server di produzione.

Passare da iptables a nftables

Ubuntu 24.04 usa nftables come backend predefinito del firewall. Le regole iptables degli esempi funzionano grazie a un livello di compatibilità, ma su un server moderno conviene scrivere direttamente in sintassi nftables, più pulita e performante. Sostituisci le righe PostUp/PostDown con regole nftables equivalenti.

PostUp = nft add table inet wg; nft add chain inet wg postrouting { type nat hook postrouting priority 100 \; }; nft add rule inet wg postrouting oifname "eth0" masquerade
PostDown = nft delete table inet wg

Gestire decine di client in modo ordinato

Aggiungere ogni client a mano diventa scomodo oltre i cinque o sei peer. Per ciascun nuovo client, genera una coppia di chiavi e una chiave precondivisa, assegna un IP progressivo (10.10.10.3, 10.10.10.4, ecc.) e aggiungi il blocco [Peer] al server. Usa wg syncconf per applicare le modifiche senza interrompere i tunnel esistenti. Tieni un registro (anche un semplice file di testo) che associ ogni IP a un dispositivo: ti salverà quando dovrai revocare l’accesso a un client.

Per revocare un client basta rimuovere il suo blocco [Peer] dal server e applicare wg syncconf. Senza la sua riga, il server rifiuterà ogni handshake da quella chiave pubblica, escludendo immediatamente il dispositivo.

Aggiungere il supporto IPv6

Per offrire IPv6 ai client, assegna anche una subnet IPv6 privata (ULA) all’interfaccia e abilita l’inoltro IPv6 come abbiamo fatto allo Step 6. Aggiungi un secondo indirizzo all’[Interface] del server e un corrispondente AllowedIPs a ciascun peer.

# Nel blocco [Interface] del server, indirizzo dual-stack:
Address = 10.10.10.1/24, fd86:ea04:1115::1/64

# Nel blocco [Peer] di ogni client, aggiungi l'IP IPv6:
AllowedIPs = 10.10.10.2/32, fd86:ea04:1115::2/128

Con il dual-stack i client raggiungono sia i servizi IPv4 sia quelli IPv6 attraverso il tunnel. Ricorda di aggiungere una regola MASQUERADE anche per la tabella nat IPv6 se i client devono uscire verso internet in IPv6.

Buone pratiche di sicurezza per il server WireGuard

Un tunnel cifrato è solo una parte della sicurezza. Il server che lo ospita va protetto con la stessa cura. Queste pratiche riducono la superficie d’attacco e ti tengono al riparo dagli errori più costosi.

Mantieni il sistema aggiornato. Il modulo WireGuard viene aggiornato con il kernel: applica le patch di sicurezza con sudo apt update && sudo apt upgrade con regolarità. Nel 2026 la guida operativa è preferire il modulo del kernel della distribuzione e tenerlo aggiornato.
Usa sempre la chiave precondivisa. Non costa nulla e aggiunge uno strato di difesa post-quantistica. Generala con wg genpsk e inseriscila in ogni coppia di peer.
Limita i permessi delle chiavi. Directory a 700, file delle chiavi a 600. Le chiavi private non devono mai finire in un backup non cifrato o in un repository Git.
Disabilita l’accesso SSH con password sul server e usa solo chiavi. Un server VPN esposto su internet è un bersaglio appetibile.
Cambia la porta di default se necessario. Spostare WireGuard su una porta UDP non standard non è sicurezza vera, ma riduce il rumore degli scanner automatici.
Monitora gli handshake. Un peer che non fa handshake da giorni può indicare un dispositivo perso o compromesso: è il momento di revocarlo.

WireGuard ha una storia di sicurezza solida: il suo codice ridotto ha facilitato gli audit formali e, alla data di questa guida, le fonti ufficiali non segnalano vulnerabilità critiche aperte sul modulo del kernel di Ubuntu 24.04. La raccomandazione resta quella di affidarsi al modulo della distribuzione anziché a DKMS, salvo casi particolari. Per una panoramica più ampia delle scelte di protezione del browser e della rete, leggi il confronto Brave contro Firefox.

Domande frequenti su WireGuard

WireGuard è sicuro quanto OpenVPN?

Sì, e per molti aspetti è più sicuro. WireGuard usa una suite crittografica moderna e fissa (Curve25519, ChaCha20, Poly1305, BLAKE2s) che non lascia spazio a configurazioni deboli. Il codice ridotto a circa 4.000 righe è stato sottoposto ad audit formale, contro le oltre 100.000 righe di OpenVPN. L’assenza di opzioni negoziabili elimina intere classi di attacchi di downgrade.

Posso usare WireGuard su Windows, macOS e smartphone?

Sì. Esistono app ufficiali per Windows, macOS, Android e iOS. La configurazione del client che hai creato allo Step 10 funziona su tutte le piattaforme: basta importare il file wg0.conf oppure inquadrare un codice QR generato dal server. Il server resta identico, sono i client a cambiare.

Qual è la differenza tra full tunnel e split tunnel?

Con il full tunnel (AllowedIPs = 0.0.0.0/0 sul client) tutto il traffico passa per la VPN, ideale per la privacy su reti pubbliche. Con lo split tunnel indichi solo le subnet specifiche da instradare nel tunnel (per esempio 10.10.10.0/24), lasciando il resto del traffico sulla connessione diretta. Lo split tunnel è utile per accedere a una rete aziendale senza far passare tutto Netflix per il server.

WireGuard funziona dietro un NAT o un firewall restrittivo?

Sì, purché il client possa raggiungere la porta UDP del server. La direttiva PersistentKeepalive = 25 mantiene aperta la mappatura NAT inviando un piccolo pacchetto ogni 25 secondi. Se il provider blocca completamente UDP, l’unica alternativa è incapsulare WireGuard in altri protocolli, una configurazione avanzata fuori dallo scopo di questa guida.

WireGuard registra la mia attività?

Il protocollo in sé non scrive log delle connessioni: mantiene solo lo stato minimo necessario in memoria e dimentica i peer inattivi. Se gestisci tu il server, decidi tu cosa registrare. Se usi un provider VPN commerciale basato su WireGuard, dipende dalla sua politica di no-log, che vale la pena verificare con un audit indipendente come spieghiamo nel nostro confronto tra i principali provider VPN.

Perché la connessione è lenta nonostante WireGuard sia veloce?

Le cause più comuni sono tre: un MTU mal configurato che frammenta i pacchetti (prova ad abbassarlo a 1380), una CPU del server saturata dalla cifratura su VPS economici, o la distanza geografica dal server che aggiunge latenza. WireGuard è veloce a livello di protocollo, ma resta limitato dalla banda e dalla potenza dell’hardware su cui gira.

Devo aprire altre porte oltre alla 51820?

No. WireGuard usa una sola porta UDP (51820 di default, ma puoi cambiarla). Non servono porte aggiuntive perché tutto il traffico cifrato, controllo e dati, passa per quell’unica porta. Questo rende la configurazione del firewall estremamente semplice rispetto a protocolli che usano più canali.

Conclusione: una VPN tua, in 30 minuti

Hai costruito da zero un server WireGuard completo: pacchetti installati, chiavi generate, interfaccia configurata, NAT e IP forwarding attivi, primo client connesso e chiave precondivisa per la difesa post-quantistica. Con i 12 step di questa guida hai una VPN veloce, verificabile e interamente sotto il tuo controllo, senza dipendere da un provider esterno.

I prossimi passi naturali sono aggiungere altri client con wg syncconf, migrare le regole a nftables e abilitare il dual-stack IPv6. Tieni il server aggiornato, proteggi le chiavi private e monitora gli handshake: con queste accortezze il tuo tunnel resterà sicuro e affidabile nel tempo. Una VPN ben configurata è oggi uno degli strumenti più efficaci per proteggere il traffico su reti non fidate.

Fonti e approfondimenti: sito ufficiale WireGuard, guida rapida WireGuard, whitepaper tecnico del protocollo (PDF), documentazione ufficiale Ubuntu Server e scheda WireGuard su Wikipedia.