Una VPN WireGuard self-hosted offre al tuo portatile e al tuo telefono un percorso cifrato verso un server che controlli tu. È utile quando vuoi un IP di uscita stabile, un accesso sicuro su Wi-Fi non affidabili o una rotta privata verso un'altra rete. Non ti rende anonimo: i siti web vedono comunque un solo indirizzo del VPS e il provider di hosting continua a gestire la rete sottostante.
Questa guida costruisce una VPN IPv4 full-tunnel su Ubuntu Server. Installerai WireGuard, genererai chiavi con permessi restrittivi, abiliterai il routing, aggiungerai regole di firewall e NAT, collegherai client desktop e mobili e verificherai il tunnel. Lo stesso schema può supportare IPv6, ma solo dopo che il VPS dispone di spazio IPv6 instradato e hai configurato separatamente il forwarding e le regole firewall IPv6.
Che cos'è WireGuard?
WireGuard è un protocollo VPN moderno e multipiattaforma, insieme alla sua implementazione, che trasporta pacchetti IP cifrati su UDP. La specifica del protocollo WireGuard definisce un insieme fisso di primitive crittografiche, tra cui ChaCha20-Poly1305, Curve25519, BLAKE2s, SipHash24 e HKDF. Questo impianto volutamente ridotto rende la configurazione e l'audit più semplici rispetto ai protocolli con molte cipher suite intercambiabili.
WireGuard non ha un sistema centrale di account né una rubrica utenti integrata. Ogni dispositivo è un peer con la propria coppia di chiavi, il proprio indirizzo nel tunnel e le proprie regole AllowedIPs. Su un VPS di solito un peer fa da gateway verso internet, mentre portatili e telefoni avviano le connessioni verso di esso.
Perché usare WireGuard su un VPS?
- Modello peer semplice: Ogni dispositivo riceve una coppia di chiavi e una voce peer.
- Superficie di attacco ridotta: WireGuard adotta un protocollo compatto e una suite crittografica fissa, invece di esporre un lungo elenco di opzioni legacy.
- Buone prestazioni: L'integrazione nel kernel su Linux e una crittografia efficiente possono garantire un throughput elevato, anche se il risultato dipende comunque da CPU, capacità di rete, latenza e dimensione dei pacchetti.
- Client multipiattaforma: Sono disponibili client ufficiali per Windows 10 e 11, macOS, Android e iOS, mentre Linux e diversi sistemi BSD offrono strumenti o pacchetti nativi.
- Roaming: Un peer può cambiare rete e indirizzo IP di origine senza ricevere una nuova identità WireGuard; il server apprende l'ultimo endpoint autenticato.
- Controllo del routing chiaro: AllowedIPs determina sia quali destinazioni passano dal tunnel sia quali indirizzi del tunnel appartengono a ciascun peer.
Letture correlate: la guida Cloudzy al VPS per VPN. Per installazioni più datate, vedi la guida Cloudzy alla configurazione di PPTP; non scegliere PPTP per una nuova VPN in cui la sicurezza conta.
Salta l'installazione manuale: WireGuard con un clic
Se non hai una formazione tecnica, o preferisci non occuparti tu dell'installazione, Cloudzy offre un deployment di WireGuard VPN con un clic. Il resto di questa guida tratta la costruzione manuale; questa sezione tratta la scorciatoia.
- Accedi al pannello di controllo Cloudzy.
- Seleziona WireGuard dall'elenco delle applicazioni.
- Crea un VPS nella località che preferisci con il piano che vuoi. Basta una macchina Ubuntu con specifiche di base.
Quando il VPS è pronto, accedi ed esegui il comando seguente per visualizzare la configurazione:
cat client.confVedrai qualcosa di simile:
Usa quella configurazione per creare un nuovo tunnel nel client WireGuard sul tuo PC e la connessione è pronta. Se invece preferisci capire ogni singolo pezzo, o ti serve uno schema che l'immagine con un clic non copre, prosegui con la costruzione manuale qui sotto.
Come configurare WireGuard su Ubuntu
I comandi seguenti sono pensati per una release attuale di Ubuntu Server. Eseguili via SSH con un utente dotato di sudo. Tieni aperta la sessione SSH finché il firewall non è confermato e, se il tuo provider lo consente, crea prima uno snapshot del VPS.
Prerequisiti
- Un VPS Ubuntu con indirizzo IPv4 pubblico
- Un account non root con accesso sudo
- Accesso SSH e i dati della console di ripristino del provider VPS
- Un dispositivo client con l'app ufficiale WireGuard o gli strumenti da riga di comando
Non ti serve un secondo server Ubuntu. Il client può essere un PC Windows, un Mac, un portatile Linux, un telefono Android o un iPhone.
Passaggio 1: installare WireGuard
sudo apt update
sudo apt install wireguard -yVerifica che gli strumenti siano disponibili:
wg --versionPassaggio 2: generare le chiavi del server in sicurezza
Crea la directory di WireGuard e genera la coppia di chiavi con una umask restrittiva. La chiave privata non va mai copiata su un client né pubblicata nei log.
sudo install -d -m 700 /etc/wireguard
sudo sh -c 'umask 077; wg genkey > /etc/wireguard/server.key; wg pubkey < /etc/wireguard/server.key > /etc/wireguard/server.pub'Mostra le chiavi quando devi incollarle nei file di configurazione:
sudo cat /etc/wireguard/server.key
sudo cat /etc/wireguard/server.pubPassaggio 3: creare la configurazione del server
Apri la configurazione dell'interfaccia:
sudo nano /etc/wireguard/wg0.confIncolla il blocco seguente e sostituisci SERVER_PRIVATE_KEY con la chiave privata del passaggio precedente:
[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = SERVER_PRIVATE_KEYLa rete del tunnel 10.8.0.0/24 è solo un esempio. Scegli un altro intervallo privato se si sovrappone a una rete domestica, aziendale o cloud che devi raggiungere. Non aggiungere SaveConfig = true: può riscrivere il file allo spegnimento dell'interfaccia e cancellare le modifiche fatte a mano.
sudo chmod 600 /etc/wireguard/wg0.confPassaggio 4: abilitare il forwarding IPv4
Il VPS deve instradare i pacchetti tra wg0 e la sua interfaccia di rete pubblica. Metti l'impostazione in un file sysctl dedicato:
sudo nano /etc/sysctl.d/70-wireguard-routing.confnet.ipv4.ip_forward = 1Applica e verifica:
sudo sysctl -p /etc/sysctl.d/70-wireguard-routing.conf
sysctl net.ipv4.ip_forwardQuesto segue il modello di routing descritto nella guida al gateway WireGuard di Ubuntu. IPv6 richiede un prefisso IPv6 instradato, indirizzi di tunnel separati, forwarding IPv6 e regole firewall IPv6; non inviare il traffico del client a ::/0 finché quel percorso non è completo.
Passaggio 5: aggiungere regole di firewall e NAT
Individua il nome dell'interfaccia pubblica del VPS. Nell'output qui sotto, osserva il valore dopo dev; nomi comuni sono eth0, ens3 ed enp1s0.
ip route show defaultRiapri wg0.conf e aggiungi le righe seguenti sotto [Interface]. Sostituisci eth0 ovunque se la tua interfaccia pubblica ha un altro nome:
PostUp = iptables -I FORWARD 1 -i %i -o eth0 -j ACCEPT; iptables -I FORWARD 1 -i eth0 -o %i -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT; iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
PreDown = iptables -D FORWARD -i %i -o eth0 -j ACCEPT; iptables -D FORWARD -i eth0 -o %i -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT; iptables -t nat -D POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADESe UFW è attivo, consenti SSH prima di toccarne lo stato, poi apri la porta UDP di WireGuard:
sudo ufw allow OpenSSH
sudo ufw allow 51820/udp
sudo ufw statusSe UFW è attualmente disattivato e vuoi abilitarlo, verifica prima che esista la regola OpenSSH. Non disattivare e riattivare UFW via SSH solo per applicare queste regole: aggiunge un rischio di lockout del tutto evitabile.
Passaggio 6: avviare l'interfaccia WireGuard
sudo systemctl enable --now wg-quick@wg0
sudo systemctl status wg-quick@wg0 --no-pager
sudo wg showSe il servizio fallisce, esegui journalctl prima di modificare qualsiasi altra cosa:
sudo journalctl -u wg-quick@wg0 -n 50 --no-pagerAggiungere un client WireGuard
Ogni dispositivo ha bisogno di una coppia di chiavi e di un IP nel tunnel univoci. Non riutilizzare mai una stessa configurazione client su due dispositivi: chiavi e indirizzi duplicati rendono il routing imprevedibile e impediscono una revoca pulita.
Passaggio 1: generare le chiavi del client
Le app ufficiali desktop e mobili possono generare le chiavi quando crei un tunnel vuoto. Su un client Linux usa:
umask 077
wg genkey | tee client.key | wg pubkey > client.pubTieni client.key su quel dispositivo. Copia sul server soltanto client.pub.
Passaggio 2: aggiungere il peer sul server
sudo nano /etc/wireguard/wg0.confAggiungi un blocco peer. Sostituisci CLIENT_PUBLIC_KEY con la chiave pubblica del client:
[Peer]
PublicKey = CLIENT_PUBLIC_KEY
AllowedIPs = 10.8.0.2/32La riga Address = 10.8.0.2/32 assegna l'indirizzo del tunnel sul client. Nel blocco [Peer] del server, AllowedIPs = 10.8.0.2/32 associa quell'indirizzo a questo peer per il routing e la validazione della sorgente. Usa 10.8.0.3/32 per il dispositivo successivo, poi prosegui in ordine crescente senza duplicati.
sudo systemctl restart wg-quick@wg0Passaggio 3: creare la configurazione del client
Crea client.conf sul client e sostituisci tutti i segnaposto:
[Interface]
PrivateKey = CLIENT_PRIVATE_KEY
Address = 10.8.0.2/32
DNS = 1.1.1.1
[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = VPS_PUBLIC_IP:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25AllowedIPs = 0.0.0.0/0 rende questo un full tunnel IPv4. Per accedere solo alla rete VPN, usa AllowedIPs = 10.8.0.0/24. PersistentKeepalive è utile per un client dietro NAT il cui mapping deve restare raggiungibile anche da inattivo; la guida rapida di WireGuard osserva che la maggior parte dei peer non ne ha bisogno.
Passaggio 4: importare la configurazione
Usa il guida all'installazione dei client WireGuard per ottenere il client supportato per la tua piattaforma.
- Windows: Scegli Add Tunnel, poi importa client.conf.
- macOS: Scegli Import tunnel(s) from file e seleziona client.conf.
- Android o iOS: Importa il file oppure scansiona un codice QR generato da esso.
Su un client Ubuntu o Debian che contiene client.conf, installa qrencode e visualizza il file nel terminale di quel client:
sudo apt install qrencode -y
qrencode -t ansiutf8 < client.confIl codice QR contiene la chiave privata del client. Mostralo solo in un terminale affidabile, non salvare screenshot e pulisci il terminale dopo che il telefono lo ha importato.
Passaggio 5: verificare il tunnel
Attiva il tunnel, genera traffico dal client ed esegui questi controlli sul VPS:
sudo wg show
ip -brief address show wg0Un handshake recente e contatori di trasferimento in crescita confermano che WireGuard sta scambiando pacchetti. Poi verifica l'uscita in full tunnel dal client:
curl -4 https://api.ipify.org; echoIl comando dovrebbe restituire l'indirizzo IPv4 pubblico del VPS. Se non c'è handshake, controlla l'indirizzo dell'endpoint, la porta UDP, il firewall del cloud, la regola UFW e le chiavi. Se l'handshake c'è ma manca l'accesso a internet, controlla l'IP forwarding, il nome dell'interfaccia pubblica, le regole NAT e il DNS.
Si può mettere WireGuard dietro Nginx?
L' documentazione del modulo stream di NGINX spiega come NGINX possa inoltrare UDP da una porta a un'altra, quindi può girare UDP/80 o UDP/443 verso WireGuard su UDP/51820. Si tratta di un relay UDP, non di un reverse proxy HTTP. Non converte WireGuard in TCP o HTTPS e non fa sembrare il protocollo normale traffico web.
Per la maggior parte delle installazioni, cambiare il ListenPort di WireGuard e aprire la porta UDP corrispondente è più semplice che aggiungere NGINX. Se una rete blocca del tutto UDP o usa la deep packet inspection, un relay UDP con NGINX non risolve il problema. La documentazione sui limiti di WireGuard afferma che l'offuscamento è fuori dallo scopo del protocollo.
Collegare il VPS a una rete domestica
Un VPS può fare da hub tra un client in mobilità e un dispositivo dentro casa tua. Il peer lato casa avvia una connessione WireGuard in uscita verso il VPS, così non serve un IP pubblico domestico. Imposta PersistentKeepalive su quel peer domestico quando si trova dietro NAT.
Raggiungere l'intera LAN di casa richiede più che aggiungere un peer. La voce peer sul VPS relativa al gateway domestico deve includere la subnet di casa in AllowedIPs, ad esempio 192.168.1.0/24. Un client remoto in full tunnel (AllowedIPs = 0.0.0.0/0) invia già quel traffico attraverso il VPS; aggiungi 192.168.1.0/24 sul client solo se usi lo split tunneling. Anche il gateway domestico deve inoltrare il traffico tra WireGuard e la LAN. Aggiungi una rotta sul router di casa oppure una regola NAT delimitata con attenzione sul gateway domestico. Controlla prima le sovrapposizioni: un client collegato a un'altra rete 192.168.1.0/24 non può instradare entrambe le reti in modo pulito senza rinumerare o ricorrere a un policy routing più avanzato.
WireGuard self-hosted o VPN commerciale
Il self-hosting cambia chi gestisce la VPN, ma non migliora automaticamente l'anonimato. Un VPS personale ti dà un IP di uscita stabile, facile da ricondurre a una rete di hosting. Un servizio commerciale di solito offre indirizzi di uscita condivisi e cambio di località immediato, ma devi affidarti alle sue policy, alla sua gestione e agli eventuali audit indipendenti che pubblica.
WireGuard di per sé è leggero, e un VPS piccolo è spesso un punto di partenza ragionevole per una persona e pochi dispositivi. Non considerare un valore fisso di RAM o vCPU come una garanzia di throughput. Fai una prova con il numero reale di dispositivi, la tua regione, la dimensione dei pacchetti e la banda che ti aspetti, poi ridimensiona se saturazione della CPU, perdita di pacchetti o latenza diventano il limite.
Scegli il self-hosting quando un IP di uscita personale stabile, l'accesso remoto o il controllo sul server contano più della scelta della località e della comodità. Scegli una VPN commerciale quando vuoi molti Paesi, uscite condivise, ampio supporto per i dispositivi di consumo e qualcun altro che gestisca i guasti.
| Fattore decisionale | WireGuard self-hosted | VPN commerciale |
|---|---|---|
| Modello di costo | Un server più il tuo tempo di amministrazione | Abbonamento, spesso scontato sui periodi più lunghi |
| Località di uscita | Una località per server | Molte località disponibili nell'app |
| Configurazione | Configuri tu chiavi, routing, regole firewall e client | Installare l'app e accedere |
| Manutenzione | Sei tu a fare patch, monitoraggio, backup e troubleshooting | Il provider gestisce il servizio |
| Modello di privacy | Controlli il server, ma il provider di hosting può comunque osservare i metadati | Ti affidi alle policy del provider e agli eventuali audit indipendenti che pubblica |
| Migliore corrispondenza | IP di uscita personale stabile, accesso remoto e controllo dell'infrastruttura | Cambio di località, poca manutenzione e ampio supporto ai dispositivi |
Conclusione
Un deployment WireGuard affidabile si riduce a cinque cose: chiavi private protette, indirizzi peer univoci, AllowedIPs corretti, forwarding e NAT funzionanti e una regola firewall per la porta UDP in ascolto. Verifica sia l'handshake sia l'indirizzo pubblico di uscita prima di affidarti al tunnel, e tieni il VPS aggiornato dopo il deployment.
Se vuoi costruire il server manualmente, parti da un soluzioni Cloudzy Ubuntu VPS. Se invece preferisci saltare i passaggi di installazione, usa il deployment WireGuard con un clic di Cloudzy e passa direttamente alla configurazione del client e alla verifica.
Domande frequenti
Perché WireGuard mostra un peer ma nessun handshake?
Una voce peer dimostra soltanto che la configurazione è stata caricata. L'assenza di handshake di solito significa che il client non raggiunge il server o che le chiavi non corrispondono. Controlla l'Endpoint del client, l'IP pubblico del server, la porta UDP/51820 sia nel firewall del provider sia in UFW, e le chiavi pubbliche su entrambi i lati. Genera traffico dal client prima di verificare, perché WireGuard resta silenzioso quando è inattivo.
Perché il tunnel si connette ma l'accesso a internet si interrompe?
Un handshake senza accesso a internet di solito indica un problema di routing, non di cifratura. Verifica net.ipv4.ip_forward, conferma il nome dell'interfaccia pubblica nella regola NAT, controlla le regole FORWARD e prova il DNS separatamente dalla connettività IP pura. Assicurati inoltre che AllowedIPs sul client corrisponda allo schema full tunnel o split tunnel che avevi in mente.
Ogni client ha bisogno di PersistentKeepalive?
No. Aggiungilo quando un peer dietro NAT deve mantenere aperto il proprio mapping nei periodi di inattività, cosa comune per telefoni, gateway domestici e alcune reti restrittive. Omettilo quando il peer comunica di frequente o non ha bisogno di essere raggiunto dall'altro capo mentre è inattivo.
