{"id":127,"date":"2026-06-14T16:46:01","date_gmt":"2026-06-14T16:46:01","guid":{"rendered":"https:\/\/shattered.io\/it\/2026\/06\/14\/configurare-server-wireguard-vpn\/"},"modified":"2026-06-14T16:47:18","modified_gmt":"2026-06-14T16:47:18","slug":"configurare-server-wireguard-vpn","status":"publish","type":"post","link":"https:\/\/shattered.io\/it\/2026\/06\/14\/configurare-server-wireguard-vpn\/","title":{"rendered":"Server WireGuard VPN su Ubuntu: 12 Step [2026]"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">Una VPN aziendale costruita su OpenVPN porta con s\u00e9 migliaia di righe di codice, certificati X.509 difficili da gestire e una latenza che si fa sentire. <strong>WireGuard<\/strong> 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 \u00e8 diventato lo standard di fatto per chi vuole una VPN veloce, verificabile e facile da mantenere.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Questa guida ti porta passo dopo passo dalla macchina Ubuntu 24.04 LTS appena installata fino a un server <strong>WireGuard<\/strong> 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&#8217;uso, gli errori pi\u00f9 comuni e una sezione di troubleshooting con 8 casi reali. Tempo stimato: circa 30 minuti.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"wireguard-2026\">WireGuard nel 2026: la VPN che ha riscritto le regole<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">WireGuard \u00e8 entrato ufficialmente nel kernel Linux con la versione 5.6 e da allora \u00e8 il modulo VPN di riferimento per i sistemi Linux. Su Ubuntu 24.04 LTS il modulo \u00e8 gi\u00e0 compilato nel kernel: non serve installare DKMS n\u00e9 ricompilare nulla. Questo cambia radicalmente l&#8217;esperienza rispetto a OpenVPN, dove ogni aggiornamento di kernel poteva rompere il tunnel.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">La filosofia di <strong>WireGuard<\/strong> \u00e8 la minimalit\u00e0. Mentre OpenVPN espone decine di opzioni configurabili (cifrari, modalit\u00e0, compressione, autenticazione), WireGuard fissa un&#8217;unica suite crittografica moderna e non permette di sceglierla. Questa rigidit\u00e0 \u00e8 un vantaggio di sicurezza: non esistono configurazioni deboli da evitare, non c&#8217;\u00e8 negoziazione del cifrario da attaccare, non ci sono downgrade possibili. Il risultato \u00e8 una superficie d&#8217;attacco ridotta all&#8217;osso e un codice abbastanza piccolo da essere stato sottoposto ad audit formale.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Il modello operativo \u00e8 altrettanto snello. WireGuard non ha il concetto di &#8220;connessione&#8221; o &#8220;sessione&#8221; 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&#8217;IP sorgente rientri negli <code>AllowedIPs<\/code> di quel peer e instrada di conseguenza. Questa associazione tra chiave pubblica e indirizzi ammessi si chiama <em>cryptokey routing<\/em> ed \u00e8 il cuore del progetto.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">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&#8217;\u00e8 traffico, e una configurazione leggibile in pochi secondi. Se stai valutando l&#8217;alternativa al tunneling tradizionale o vuoi capire come si colloca rispetto ad altri strumenti di anonimato, il nostro confronto su <a href=\"\/it\/tor-vs-vpn\/\">Tor contro VPN<\/a> chiarisce quando una VPN \u00e8 la scelta giusta e quando serve altro.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"come-funziona\">Come funziona WireGuard: Noise, Curve25519 e ChaCha20<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Per configurare bene un server <strong>WireGuard<\/strong> 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&#8217;handshake \u00e8 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 \u00e8 il motivo per cui WireGuard si riconnette quasi istantaneamente quando un dispositivo passa dal Wi-Fi alla rete mobile.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">La suite crittografica \u00e8 fissa e composta da cinque mattoni, ciascuno scelto per velocit\u00e0 e robustezza:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Primitiva<\/th><th>Funzione<\/th><th>Perch\u00e9 \u00e8 stata scelta<\/th><\/tr><\/thead><tbody><tr><td>Curve25519<\/td><td>Scambio di chiavi (ECDH)<\/td><td>Curva ellittica veloce e resistente agli attacchi a canale laterale<\/td><\/tr><tr><td>ChaCha20<\/td><td>Cifratura del traffico<\/td><td>Veloce in software, non richiede accelerazione hardware AES<\/td><\/tr><tr><td>Poly1305<\/td><td>Autenticazione (MAC)<\/td><td>Garantisce integrit\u00e0 e autenticit\u00e0 di ogni pacchetto<\/td><\/tr><tr><td>BLAKE2s<\/td><td>Hashing<\/td><td>Pi\u00f9 veloce di SHA-2 con pari livello di sicurezza<\/td><\/tr><tr><td>SipHash<\/td><td>Hash delle tabelle interne<\/td><td>Protegge dalle collisioni mirate nelle strutture dati<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">La combinazione ChaCha20-Poly1305 \u00e8 una cifratura autenticata (AEAD): in un&#8217;unica operazione cifra il payload e ne garantisce l&#8217;integrit\u00e0. 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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ogni handshake genera nuove chiavi di sessione effimere, garantendo la <em>perfect forward secrecy<\/em>: se un attaccante compromette le chiavi di oggi, non pu\u00f2 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 <a href=\"\/it\/crittografia-end-to-end-nodejs\/\">crittografia end-to-end<\/a> in un tutorial dedicato.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"wireguard-vs-openvpn\">WireGuard contro OpenVPN: prestazioni a confronto<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">La differenza di prestazioni \u00e8 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 \u00e8 un throughput pi\u00f9 alto e una latenza pi\u00f9 bassa, soprattutto su hardware senza accelerazione AES.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Caratteristica<\/th><th>WireGuard<\/th><th>OpenVPN<\/th><\/tr><\/thead><tbody><tr><td>Righe di codice<\/td><td>circa 4.000<\/td><td>oltre 100.000<\/td><\/tr><tr><td>Posizione<\/td><td>Kernel space (Linux)<\/td><td>User space<\/td><\/tr><tr><td>Protocollo di trasporto<\/td><td>UDP (51820 di default)<\/td><td>UDP o TCP<\/td><\/tr><tr><td>Handshake<\/td><td>circa 1,5 round trip<\/td><td>negoziazione TLS completa<\/td><\/tr><tr><td>Cifratura<\/td><td>ChaCha20-Poly1305 (fissa)<\/td><td>configurabile (AES, ecc.)<\/td><\/tr><tr><td>Riconnessione su cambio rete<\/td><td>trasparente (roaming)<\/td><td>richiede ristabilimento<\/td><\/tr><tr><td>Configurazione tipica<\/td><td>poche righe per peer<\/td><td>certificati X.509 e file multipli<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">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 \u00e8 che WireGuard offre throughput superiore e overhead inferiore rispetto a OpenVPN sulla stessa macchina, grazie all&#8217;esecuzione nel kernel e a una progettazione crittografica pi\u00f9 semplice. Per un confronto numerico pi\u00f9 dettagliato tra i due protocolli, rimandiamo all&#8217;analisi tecnica disponibile sul sito ufficiale del progetto.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Un punto a favore di OpenVPN resta la capacit\u00e0 di girare su TCP\/443, indistinguibile dal traffico HTTPS, utile dove WireGuard su UDP viene bloccato. Per la stragrande maggioranza dei casi d&#8217;uso (VPN aziendale, accesso remoto, tunneling tra server) WireGuard \u00e8 oggi la scelta pi\u00f9 sensata.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"prerequisiti\">Prerequisiti e versioni richieste<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Prima di iniziare, assicurati di avere a disposizione tutto il necessario. Questa guida \u00e8 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.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Un server con Ubuntu 24.04 LTS<\/strong> (un VPS o una macchina con IP pubblico statico). Il modulo WireGuard \u00e8 gi\u00e0 nel kernel a partire da Linux 5.6.<\/li>\n<li><strong>Accesso root o un utente con privilegi sudo.<\/strong> Tutti i comandi che modificano la rete richiedono privilegi amministrativi.<\/li>\n<li><strong>Pacchetti <code>wireguard<\/code> e <code>wireguard-tools<\/code><\/strong> dai repository ufficiali Ubuntu. Forniscono <code>wg<\/code> e <code>wg-quick<\/code>.<\/li>\n<li><strong>Una porta UDP aperta verso l&#8217;esterno<\/strong> (51820 di default) sul firewall del provider e su quello locale.<\/li>\n<li><strong>Un client<\/strong> su cui installare WireGuard: Linux, Windows, macOS, Android o iOS. L&#8217;app ufficiale \u00e8 disponibile per tutte le piattaforme.<\/li>\n<li><strong>Conoscenza di base della riga di comando Linux<\/strong> e dei concetti di rete (indirizzo IP, subnet, gateway).<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Verifica subito la versione del kernel e l&#8217;architettura con un comando rapido. Se vedi un kernel 5.6 o superiore (Ubuntu 24.04 monta la serie 6.8), sei a posto.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>uname -r\n# Output atteso su Ubuntu 24.04 LTS:\n# 6.8.0-71-generic\n\nlsb_release -a\n# Distributor ID: Ubuntu\n# Description:    Ubuntu 24.04 LTS\n# Release:        24.04\n# Codename:       noble<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"step-1-2-installazione\">Step 1-2: Installare WireGuard su Ubuntu 24.04<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Il primo passo \u00e8 aggiornare l&#8217;indice dei pacchetti e installare WireGuard. Su Ubuntu 24.04 LTS bastano i pacchetti dai repository ufficiali. Non serve aggiungere PPA n\u00e9 compilare nulla.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Step 1: aggiorna l'indice dei pacchetti\nsudo apt update\n\n# Step 2: installa WireGuard e gli strumenti userspace\nsudo apt install -y wireguard wireguard-tools<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Il pacchetto <code>wireguard<\/code> \u00e8 in realt\u00e0 un metapacchetto che tira dentro <code>wireguard-tools<\/code> e, dove serve, il modulo. Su Ubuntu 24.04 il modulo kernel \u00e8 gi\u00e0 presente, quindi l&#8217;installazione \u00e8 immediata. Verifica che tutto sia a posto controllando la versione degli strumenti userspace:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>wg --version\n# Output di esempio:\n# wireguard-tools v1.0.x - https:\/\/git.zx2c4.com\/wireguard-tools\/\n\n# Verifica che il modulo kernel sia disponibile\nsudo modprobe wireguard\nlsmod | grep wireguard\n# wireguard             autorizzato\n# Se compare la riga, il modulo \u00e8 caricato correttamente.<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Se <code>wg --version<\/code> restituisce un numero di versione e <code>lsmod<\/code> mostra il modulo, l&#8217;installazione \u00e8 completa. In caso di errore &#8220;module not found&#8221;, aggiorna il sistema con <code>sudo apt upgrade<\/code> e riavvia: su un kernel aggiornato il modulo \u00e8 sempre disponibile. Per conoscere la versione esatta del modulo caricato puoi usare <code>modinfo wireguard<\/code>, che mostra i metadati del modulo presente nel tuo kernel.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Una buona pratica \u00e8 creare subito la directory di configurazione con permessi restrittivi, perch\u00e9 conterr\u00e0 le chiavi private del server. WireGuard si aspetta i file in <code>\/etc\/wireguard\/<\/code>.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Imposta una umask restrittiva per i file che creeremo\nsudo mkdir -p \/etc\/wireguard\nsudo chmod 700 \/etc\/wireguard\numask 077<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"step-3-4-chiavi\">Step 3-4: Generare le chiavi crittografiche<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">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 <code>wg genkey<\/code> e <code>wg pubkey<\/code>. La pipe collega i due: la chiave privata viene generata, salvata e immediatamente passata a <code>wg pubkey<\/code> per derivare quella pubblica.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Step 3: genera la chiave privata del server e derivane la pubblica\ncd \/etc\/wireguard\nwg genkey | sudo tee server_private.key | wg pubkey | sudo tee server_public.key\n\n# Proteggi la chiave privata da letture non autorizzate\nsudo chmod 600 server_private.key\n\n# Visualizza le chiavi generate\nsudo cat server_private.key\n# Esempio: 8Fz...stringa base64 di 44 caratteri...=\nsudo cat server_public.key\n# Esempio: HIg...stringa base64 di 44 caratteri...=<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Ogni chiave \u00e8 una stringa base64 di 44 caratteri. La chiave privata del server \u00e8 il segreto pi\u00f9 importante dell&#8217;intera installazione: chiunque la possieda pu\u00f2 impersonare il server. Per questo le abbiamo dato permessi <code>600<\/code> (lettura e scrittura solo per root).<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">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\u00e0, ma ricorda di cancellare la chiave privata del client dal server dopo averla trasferita.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Step 4: genera la coppia di chiavi del primo client\nwg genkey | sudo tee client1_private.key | wg pubkey | sudo tee client1_public.key\nsudo chmod 600 client1_private.key\n\n# Genera anche la chiave precondivisa (preshared key) per questo peer\nwg genpsk | sudo tee client1_psk.key\nsudo chmod 600 client1_psk.key<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">La chiave precondivisa generata con <code>wg genpsk<\/code> \u00e8 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 <a href=\"\/it\/proton-mail-vs-tuta\/\">servizi di posta cifrata<\/a>, dove la gestione delle chiavi fa la differenza.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"step-5-config-server\">Step 5: Configurare l&#8217;interfaccia del server (wg0.conf)<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Ora creiamo il file di configurazione dell&#8217;interfaccia del server, che per convenzione si chiama <code>wg0<\/code>. Il file <code>\/etc\/wireguard\/wg0.conf<\/code> definisce l&#8217;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.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo nano \/etc\/wireguard\/wg0.conf<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Incolla la configurazione seguente, sostituendo <code>CHIAVE_PRIVATA_SERVER<\/code> con il contenuto del file <code>server_private.key<\/code> e <code>eth0<\/code> con il nome della tua interfaccia di rete pubblica (verificalo con <code>ip route get 8.8.8.8<\/code>).<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>[Interface]\n# Indirizzo del server all'interno della rete VPN\nAddress = 10.10.10.1\/24\n# Porta UDP su cui WireGuard ascolta\nListenPort = 51820\n# Chiave privata del server (contenuto di server_private.key)\nPrivateKey = CHIAVE_PRIVATA_SERVER\n\n# Abilita il NAT all'avvio del tunnel\nPostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE\n# Rimuove le regole quando il tunnel viene fermato\nPostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -D FORWARD -o wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE\n\n# I peer (client) verranno aggiunti piu' avanti<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Analizziamo le righe chiave. <code>Address = 10.10.10.1\/24<\/code> assegna al server l&#8217;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\u00ec via. <code>ListenPort = 51820<\/code> \u00e8 la porta UDP standard di WireGuard. Le direttive <code>PostUp<\/code> e <code>PostDown<\/code> eseguono le regole iptables che instradano e mascherano il traffico, attivandole quando il tunnel sale e rimuovendole quando scende, cos\u00ec da non lasciare regole orfane.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">La regola <code>MASQUERADE<\/code> \u00e8 ci\u00f2 che permette ai client di navigare in internet attraverso il server: traduce gli indirizzi privati della VPN nell&#8217;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.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"step-6-ip-forward\">Step 6: Abilitare l&#8217;IP forwarding e il NAT<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">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&#8217;IP forwarding. \u00c8 uno degli step pi\u00f9 dimenticati e una causa frequente di tunnel che si connettono ma non lasciano navigare.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Abilita l'inoltro IPv4 subito (non persistente)\nsudo sysctl -w net.ipv4.ip_forward=1\n\n# Rendi la modifica permanente al riavvio\necho 'net.ipv4.ip_forward=1' | sudo tee \/etc\/sysctl.d\/99-wireguard.conf\n\n# Se usi anche IPv6, aggiungi:\necho 'net.ipv6.conf.all.forwarding=1' | sudo tee -a \/etc\/sysctl.d\/99-wireguard.conf\n\n# Applica le impostazioni dal file\nsudo sysctl -p \/etc\/sysctl.d\/99-wireguard.conf\n# Output atteso:\n# net.ipv4.ip_forward = 1<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Il comando <code>sysctl -w<\/code> applica la modifica nella sessione corrente, ma viene persa al riavvio. Scrivendo la direttiva in un file dentro <code>\/etc\/sysctl.d\/<\/code> la rendiamo permanente. Abbiamo usato un file dedicato (<code>99-wireguard.conf<\/code>) invece di modificare <code>\/etc\/sysctl.conf<\/code>: \u00e8 pi\u00f9 pulito e facile da rimuovere se un giorno disinstalli la VPN.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Verifica che l&#8217;impostazione sia attiva leggendo direttamente il valore dal kernel. Un valore di 1 conferma che l&#8217;inoltro \u00e8 abilitato:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>cat \/proc\/sys\/net\/ipv4\/ip_forward\n# 1   ->  inoltro abilitato, tutto pronto\n# 0   ->  inoltro disabilitato, ricontrolla i passaggi precedenti<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Questo passaggio lavora in coppia con la regola <code>MASQUERADE<\/code> dello Step 5: l&#8217;IP forwarding consente al kernel di instradare i pacchetti tra l&#8217;interfaccia <code>wg0<\/code> e quella pubblica, mentre il MASQUERADE riscrive l&#8217;indirizzo sorgente. Insieme trasformano il server in un gateway funzionante.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"step-7-8-avvio\">Step 7-8: Avviare il server e aprire la porta UDP 51820<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Con la configurazione pronta e l&#8217;IP forwarding attivo, possiamo avviare il tunnel. Lo strumento <code>wg-quick<\/code> legge <code>wg0.conf<\/code>, crea l&#8217;interfaccia, applica le regole iptables e mette tutto online con un solo comando.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Step 7: avvia il tunnel leggendo \/etc\/wireguard\/wg0.conf\nsudo wg-quick up wg0\n# Output atteso:\n# [#] ip link add wg0 type wireguard\n# [#] wg setconf wg0 \/dev\/fd\/63\n# [#] ip -4 address add 10.10.10.1\/24 dev wg0\n# [#] ip link set mtu 1420 up dev wg0\n# [#] iptables -A FORWARD -i wg0 -j ACCEPT; ...\n\n# Verifica lo stato dell'interfaccia\nsudo wg show\n# interface: wg0\n#   public key: HIg...=\n#   private key: (hidden)\n#   listening port: 51820<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Nota che <code>wg-quick<\/code> imposta automaticamente l&#8217;MTU a 1420, valore prudente che lascia spazio per l&#8217;incapsulamento WireGuard ed evita la frammentazione dei pacchetti. Per abilitare l&#8217;avvio automatico al boot, usa systemd con il servizio dedicato che il pacchetto installa per te.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Step 8: abilita l'avvio automatico al riavvio del server\nsudo systemctl enable wg-quick@wg0\n# Verifica che il servizio sia attivo\nsudo systemctl status wg-quick@wg0\n# Active: active (exited)<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Resta da aprire la porta UDP 51820 sul firewall. Se usi UFW (il firewall predefinito di Ubuntu), il comando \u00e8 immediato. Ricorda di aprire la porta anche nel pannello del tuo provider cloud, perch\u00e9 molti VPS hanno un firewall esterno separato.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Apri la porta WireGuard su UFW\nsudo ufw allow 51820\/udp comment 'WireGuard VPN'\n\n# Verifica le regole attive\nsudo ufw status verbose | grep 51820\n# 51820\/udp    ALLOW    Anywhere    # WireGuard VPN<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Se gestisci un firewall personalizzato o un reverse proxy, dai un&#8217;occhiata anche al nostro tutorial su <a href=\"\/it\/certbot-lets-encrypt-https\/\">Certbot e Let&#8217;s Encrypt<\/a> per capire come orchestrare pi\u00f9 servizi sulla stessa macchina senza conflitti di porta.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"step-9-10-client\">Step 9-10: Configurare il primo client (peer)<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Il server \u00e8 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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Step 9: aggiungi il peer al server. Apri di nuovo <code>wg0.conf<\/code> e, in fondo, aggiungi un blocco <code>[Peer]<\/code> con la chiave pubblica del client e l&#8217;indirizzo VPN che gli assegni.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># In coda a \/etc\/wireguard\/wg0.conf\n[Peer]\n# Chiave pubblica del client (contenuto di client1_public.key)\nPublicKey = CHIAVE_PUBBLICA_CLIENT1\n# Chiave precondivisa per questo peer (contenuto di client1_psk.key)\nPresharedKey = CHIAVE_PRECONDIVISA_CLIENT1\n# Indirizzo VPN riservato a questo client, \/32 = un solo IP\nAllowedIPs = 10.10.10.2\/32<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Qui <code>AllowedIPs = 10.10.10.2\/32<\/code> dice al server: &#8220;accetta da questo peer solo i pacchetti che arrivano dall&#8217;indirizzo 10.10.10.2, e instrada verso di lui solo il traffico destinato a quell&#8217;IP&#8221;. Lato server, gli <code>AllowedIPs<\/code> agiscono come una whitelist di indirizzi sorgente, un controllo crittografico che impedisce a un peer di spacciarsi per un altro.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Step 10: crea la configurazione del client. Sul dispositivo client, crea un file <code>wg0.conf<\/code> (o importalo nell&#8217;app ufficiale). Sostituisci i segnaposto con le chiavi corrette e con l&#8217;IP pubblico del tuo server.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>[Interface]\n# Chiave privata del client (contenuto di client1_private.key)\nPrivateKey = CHIAVE_PRIVATA_CLIENT1\n# Indirizzo VPN del client\nAddress = 10.10.10.2\/24\n# DNS usato dal client mentre il tunnel e' attivo\nDNS = 1.1.1.1\n\n[Peer]\n# Chiave pubblica del server (contenuto di server_public.key)\nPublicKey = CHIAVE_PUBBLICA_SERVER\n# Chiave precondivisa, identica a quella nel blocco [Peer] del server\nPresharedKey = CHIAVE_PRECONDIVISA_CLIENT1\n# IP pubblico del server e porta\nEndpoint = IP_PUBBLICO_SERVER:51820\n# 0.0.0.0\/0 instrada TUTTO il traffico nel tunnel (full tunnel)\nAllowedIPs = 0.0.0.0\/0\n# Mantiene viva la sessione attraverso il NAT\nPersistentKeepalive = 25<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Due righe meritano attenzione. <code>AllowedIPs = 0.0.0.0\/0<\/code> nel client significa &#8220;manda tutto il mio traffico internet attraverso la VPN&#8221; (configurazione full tunnel). Se invece volessi instradare solo la rete aziendale, useresti per esempio <code>AllowedIPs = 10.10.10.0\/24<\/code> (split tunnel). <code>PersistentKeepalive = 25<\/code> invia un pacchetto vuoto ogni 25 secondi per mantenere aperta la mappatura NAT, indispensabile quando il client \u00e8 dietro un router domestico o una rete mobile.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">La riga <code>DNS = 1.1.1.1<\/code> fa s\u00ec che il client risolva i nomi tramite un resolver esterno mentre il tunnel \u00e8 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.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"step-11-psk\">Step 11: Aggiungere il preshared key per la difesa post-quantum<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">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\u00e0 violata. \u00c8 lo scenario &#8220;harvest now, decrypt later&#8221;.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">La risposta di WireGuard \u00e8 la chiave precondivisa (<code>PresharedKey<\/code>) che abbiamo generato allo Step 4. \u00c8 un segreto simmetrico a 256 bit, condiviso fuori banda tra server e client, che viene mescolato nell&#8217;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\u00e9 i 256 bit simmetrici restano fuori dalla portata degli algoritmi quantistici noti.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Abbiamo gi\u00e0 inserito le righe <code>PresharedKey<\/code> nei blocchi <code>[Peer]<\/code> di server e client agli step precedenti. L&#8217;importante \u00e8 che la stessa chiave compaia su entrambi i lati per quel peer. Verifica che corrispondano:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Sul server, mostra la chiave precondivisa del client1\nsudo cat \/etc\/wireguard\/client1_psk.key\n# La stessa stringa deve comparire nel campo PresharedKey\n# sia nel blocco [Peer] del server sia nella config del client.\n\n# Applica la nuova configurazione del server senza interrompere il tunnel\nsudo wg syncconf wg0 &lt;(sudo wg-quick strip wg0)<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Il comando <code>wg syncconf<\/code> applica le modifiche al volo senza far cadere le connessioni esistenti, a differenza di <code>wg-quick down<\/code> seguito da <code>up<\/code> che interromperebbe tutti i tunnel. \u00c8 il modo corretto di aggiornare la configurazione su un server di produzione con client attivi. La difesa post-quantistica \u00e8 un tema che approfondiamo in altri contenuti del nostro <a href=\"\/it\/privacy\/\">canale dedicato alla privacy<\/a>, dove spieghiamo perch\u00e9 iniziare a prepararsi ora \u00e8 una scelta prudente.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"step-12-verifica\">Step 12: Verificare il tunnel e il traffico<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Arrivati a questo punto, attiva il tunnel sul client (con <code>wg-quick up wg0<\/code> su Linux o premendo &#8220;connetti&#8221; nell&#8217;app) e verifica che tutto funzioni. Il comando <code>wg show<\/code> sul server \u00e8 il tuo cruscotto principale: mostra ogni peer, l&#8217;ultimo handshake e i byte trasferiti.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo wg show\n# interface: wg0\n#   public key: HIg...=\n#   private key: (hidden)\n#   listening port: 51820\n#\n# peer: CHIAVE_PUBBLICA_CLIENT1\n#   preshared key: (hidden)\n#   endpoint: 93.45.12.88:54210\n#   allowed ips: 10.10.10.2\/32\n#   latest handshake: 18 seconds ago\n#   transfer: 1.24 MiB received, 8.91 MiB sent<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Le righe da controllare sono due. <code>latest handshake<\/code> deve mostrare un valore recente (pochi secondi o minuti): se \u00e8 assente, l&#8217;handshake non \u00e8 mai avvenuto e c&#8217;\u00e8 un problema di chiavi, porta o firewall. <code>transfer<\/code> 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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Dal client, esegui due test rapidi per confermare che la VPN funzioni e non ci siano fughe. Il primo verifica la connettivit\u00e0 dentro il tunnel, il secondo conferma che il tuo IP pubblico \u00e8 quello del server.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># 1. Verifica la connettivita' verso il server dentro il tunnel\nping -c 3 10.10.10.1\n# 64 bytes from 10.10.10.1: icmp_seq=1 ttl=64 time=12.3 ms\n\n# 2. Conferma che l'IP pubblico visto da internet sia quello del server\ncurl -s https:\/\/ifconfig.me\n# Deve restituire l'IP pubblico del tuo server WireGuard,\n# non quello della tua connessione locale.<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Se il ping risponde e <code>curl<\/code> mostra l&#8217;IP del server, il tunnel \u00e8 pienamente operativo: tutto il traffico del client passa cifrato attraverso WireGuard. Complimenti, hai un server VPN funzionante.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"errori-comuni\">6 errori comuni da evitare<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Questi sono gli errori che fanno perdere pi\u00f9 tempo durante la configurazione di un server <strong>WireGuard<\/strong>. Conoscerli in anticipo ti risparmia ore di debug.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Dimenticare l&#8217;IP forwarding.<\/strong> Il tunnel si connette, il ping verso 10.10.10.1 funziona, ma internet non va. Nove volte su dieci la causa \u00e8 <code>net.ipv4.ip_forward<\/code> a 0. \u00c8 l&#8217;errore numero uno in assoluto.<\/li>\n<li><strong>Sbagliare il nome dell&#8217;interfaccia di rete.<\/strong> La regola MASQUERADE punta a <code>eth0<\/code>, ma sul tuo VPS l&#8217;interfaccia si chiama <code>ens3<\/code> o <code>enp1s0<\/code>. Verifica sempre con <code>ip route get 8.8.8.8<\/code> e correggi <code>PostUp<\/code>\/<code>PostDown<\/code>.<\/li>\n<li><strong>Confondere chiave pubblica e privata.<\/strong> Nel blocco <code>[Interface]<\/code> va la chiave <em>privata<\/em> della macchina locale; nel blocco <code>[Peer]<\/code> va la chiave <em>pubblica<\/em> dell&#8217;altro lato. Invertirle impedisce l&#8217;handshake.<\/li>\n<li><strong>AllowedIPs troppo larghi sul server.<\/strong> Mettere <code>AllowedIPs = 0.0.0.0\/0<\/code> nel blocco <code>[Peer]<\/code> del server \u00e8 un errore: significherebbe instradare tutto il traffico verso quel singolo client. Lato server usa sempre un \/32 per peer.<\/li>\n<li><strong>Porta UDP chiusa nel firewall del provider.<\/strong> UFW pu\u00f2 essere aperto, ma il firewall esterno del cloud (Security Group, ad esempio) blocca ancora la 51820. Controlla entrambi i livelli.<\/li>\n<li><strong>Permessi troppo aperti sulle chiavi.<\/strong> Lasciare <code>server_private.key<\/code> leggibile da tutti \u00e8 un rischio di sicurezza grave. Imposta sempre <code>chmod 600<\/code> e tieni la directory a <code>700<\/code>.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"troubleshooting\">Risoluzione dei problemi: 8 casi frequenti<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Quando qualcosa non funziona, questa tabella ti porta dritto alla causa. Ogni riga associa un sintomo osservabile alla diagnosi pi\u00f9 probabile e all&#8217;azione correttiva.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Sintomo<\/th><th>Causa probabile<\/th><th>Soluzione<\/th><\/tr><\/thead><tbody><tr><td>Nessun &#8220;latest handshake&#8221; in <code>wg show<\/code><\/td><td>Porta chiusa o chiave errata<\/td><td>Apri la 51820\/udp su entrambi i firewall e ricontrolla le chiavi<\/td><\/tr><tr><td>Handshake presente ma niente internet<\/td><td>IP forwarding disabilitato<\/td><td><code>sudo sysctl -w net.ipv4.ip_forward=1<\/code><\/td><\/tr><tr><td>Byte ricevuti crescono, inviati a zero<\/td><td>Regola MASQUERADE mancante<\/td><td>Verifica l&#8217;interfaccia in <code>PostUp<\/code> e riavvia il tunnel<\/td><\/tr><tr><td>Il tunnel cade dopo qualche minuto<\/td><td>NAT che chiude la sessione<\/td><td>Aggiungi <code>PersistentKeepalive = 25<\/code> sul client<\/td><\/tr><tr><td>Le pagine web non caricano ma il ping va<\/td><td>Problema di MTU<\/td><td>Riduci l&#8217;MTU del client a 1380 o 1280<\/td><\/tr><tr><td>I siti risolvono lentamente o non risolvono<\/td><td>DNS non configurato nel tunnel<\/td><td>Aggiungi <code>DNS = 1.1.1.1<\/code> nel blocco <code>[Interface]<\/code><\/td><\/tr><tr><td><code>wg-quick<\/code> da&#8217; &#8220;RTNETLINK File exists&#8221;<\/td><td>Interfaccia gia&#8217; attiva<\/td><td>Esegui <code>sudo wg-quick down wg0<\/code> e poi <code>up<\/code><\/td><\/tr><tr><td>&#8220;module wireguard not found&#8221;<\/td><td>Kernel non aggiornato<\/td><td><code>sudo apt upgrade<\/code> e riavvia il server<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Per un debug pi\u00f9 profondo, abilita temporaneamente i log dettagliati del modulo kernel. WireGuard scrive nel ring buffer del kernel, leggibile con <code>dmesg<\/code>. Questo ti mostra eventuali errori di handshake o pacchetti scartati in tempo reale.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Abilita il logging dinamico del modulo WireGuard\necho 'module wireguard +p' | sudo tee \/sys\/kernel\/debug\/dynamic_debug\/control\n\n# Osserva i messaggi del kernel in tempo reale\nsudo dmesg -wT | grep wireguard\n# Disabilita il logging quando hai finito:\necho 'module wireguard -p' | sudo tee \/sys\/kernel\/debug\/dynamic_debug\/control<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Se il problema riguarda l&#8217;MTU (pagine che non caricano mentre il ping funziona), il colpevole \u00e8 quasi sempre la frammentazione su un percorso di rete con MTU ridotto, tipico delle connessioni PPPoE. Abbassare l&#8217;MTU del client risolve nella maggior parte dei casi.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"tecniche-avanzate\">Tecniche avanzate: nftables, pi\u00f9 client e IPv6<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Una volta che il tunnel di base funziona, vale la pena alzare l&#8217;asticella. Ecco le ottimizzazioni che usiamo sui server di produzione.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"nftables\">Passare da iptables a nftables<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Ubuntu 24.04 usa nftables come backend predefinito del firewall. Le regole iptables degli esempi funzionano grazie a un livello di compatibilit\u00e0, ma su un server moderno conviene scrivere direttamente in sintassi nftables, pi\u00f9 pulita e performante. Sostituisci le righe <code>PostUp<\/code>\/<code>PostDown<\/code> con regole nftables equivalenti.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>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\nPostDown = nft delete table inet wg<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"piu-client\">Gestire decine di client in modo ordinato<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">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 <code>[Peer]<\/code> al server. Usa <code>wg syncconf<\/code> 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\u00e0 quando dovrai revocare l&#8217;accesso a un client.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Per revocare un client basta rimuovere il suo blocco <code>[Peer]<\/code> dal server e applicare <code>wg syncconf<\/code>. Senza la sua riga, il server rifiuter\u00e0 ogni handshake da quella chiave pubblica, escludendo immediatamente il dispositivo.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"ipv6\">Aggiungere il supporto IPv6<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Per offrire IPv6 ai client, assegna anche una subnet IPv6 privata (ULA) all&#8217;interfaccia e abilita l&#8217;inoltro IPv6 come abbiamo fatto allo Step 6. Aggiungi un secondo indirizzo all&#8217;<code>[Interface]<\/code> del server e un corrispondente <code>AllowedIPs<\/code> a ciascun peer.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Nel blocco [Interface] del server, indirizzo dual-stack:\nAddress = 10.10.10.1\/24, fd86:ea04:1115::1\/64\n\n# Nel blocco [Peer] di ogni client, aggiungi l'IP IPv6:\nAllowedIPs = 10.10.10.2\/32, fd86:ea04:1115::2\/128<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"sicurezza-best-practice\">Buone pratiche di sicurezza per il server WireGuard<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Un tunnel cifrato \u00e8 solo una parte della sicurezza. Il server che lo ospita va protetto con la stessa cura. Queste pratiche riducono la superficie d&#8217;attacco e ti tengono al riparo dagli errori pi\u00f9 costosi.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Mantieni il sistema aggiornato.<\/strong> Il modulo WireGuard viene aggiornato con il kernel: applica le patch di sicurezza con <code>sudo apt update &amp;&amp; sudo apt upgrade<\/code> con regolarit\u00e0. Nel 2026 la guida operativa \u00e8 preferire il modulo del kernel della distribuzione e tenerlo aggiornato.<\/li>\n<li><strong>Usa sempre la chiave precondivisa.<\/strong> Non costa nulla e aggiunge uno strato di difesa post-quantistica. Generala con <code>wg genpsk<\/code> e inseriscila in ogni coppia di peer.<\/li>\n<li><strong>Limita i permessi delle chiavi.<\/strong> Directory a <code>700<\/code>, file delle chiavi a <code>600<\/code>. Le chiavi private non devono mai finire in un backup non cifrato o in un repository Git.<\/li>\n<li><strong>Disabilita l&#8217;accesso SSH con password<\/strong> sul server e usa solo chiavi. Un server VPN esposto su internet \u00e8 un bersaglio appetibile.<\/li>\n<li><strong>Cambia la porta di default se necessario.<\/strong> Spostare WireGuard su una porta UDP non standard non \u00e8 sicurezza vera, ma riduce il rumore degli scanner automatici.<\/li>\n<li><strong>Monitora gli handshake.<\/strong> Un peer che non fa handshake da giorni pu\u00f2 indicare un dispositivo perso o compromesso: \u00e8 il momento di revocarlo.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">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\u00e0 critiche aperte sul modulo del kernel di Ubuntu 24.04. La raccomandazione resta quella di affidarsi al modulo della distribuzione anzich\u00e9 a DKMS, salvo casi particolari. Per una panoramica pi\u00f9 ampia delle scelte di protezione del browser e della rete, leggi il confronto <a href=\"\/it\/brave-vs-firefox\/\">Brave contro Firefox<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"faq\">Domande frequenti su WireGuard<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"wireguard-e-sicuro-quanto-openvpn\">WireGuard \u00e8 sicuro quanto OpenVPN?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">S\u00ec, e per molti aspetti \u00e8 pi\u00f9 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 \u00e8 stato sottoposto ad audit formale, contro le oltre 100.000 righe di OpenVPN. L&#8217;assenza di opzioni negoziabili elimina intere classi di attacchi di downgrade.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"posso-usare-wireguard-su-windows-macos-e-smartphone\">Posso usare WireGuard su Windows, macOS e smartphone?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">S\u00ec. 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 <code>wg0.conf<\/code> oppure inquadrare un codice QR generato dal server. Il server resta identico, sono i client a cambiare.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"qual-e-la-differenza-tra-full-tunnel-e-split-tunnel\">Qual \u00e8 la differenza tra full tunnel e split tunnel?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Con il full tunnel (<code>AllowedIPs = 0.0.0.0\/0<\/code> 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 <code>10.10.10.0\/24<\/code>), lasciando il resto del traffico sulla connessione diretta. Lo split tunnel \u00e8 utile per accedere a una rete aziendale senza far passare tutto Netflix per il server.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"wireguard-funziona-dietro-un-nat-o-un-firewall-restrittivo\">WireGuard funziona dietro un NAT o un firewall restrittivo?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">S\u00ec, purch\u00e9 il client possa raggiungere la porta UDP del server. La direttiva <code>PersistentKeepalive = 25<\/code> mantiene aperta la mappatura NAT inviando un piccolo pacchetto ogni 25 secondi. Se il provider blocca completamente UDP, l&#8217;unica alternativa \u00e8 incapsulare WireGuard in altri protocolli, una configurazione avanzata fuori dallo scopo di questa guida.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"wireguard-registra-la-mia-attivita\">WireGuard registra la mia attivit\u00e0?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Il protocollo in s\u00e9 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 <a href=\"\/it\/nordvpn-vs-surfshark-vs-proton-vpn\/\">tra i principali provider VPN<\/a>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"perche-la-connessione-e-lenta-nonostante-wireguard-sia-veloce\">Perch\u00e9 la connessione \u00e8 lenta nonostante WireGuard sia veloce?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Le cause pi\u00f9 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 \u00e8 veloce a livello di protocollo, ma resta limitato dalla banda e dalla potenza dell&#8217;hardware su cui gira.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"devo-aprire-altre-porte-oltre-alla-51820\">Devo aprire altre porte oltre alla 51820?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">No. WireGuard usa una sola porta UDP (51820 di default, ma puoi cambiarla). Non servono porte aggiuntive perch\u00e9 tutto il traffico cifrato, controllo e dati, passa per quell&#8217;unica porta. Questo rende la configurazione del firewall estremamente semplice rispetto a protocolli che usano pi\u00f9 canali.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"conclusione\">Conclusione: una VPN tua, in 30 minuti<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Hai costruito da zero un server <strong>WireGuard<\/strong> 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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">I prossimi passi naturali sono aggiungere altri client con <code>wg syncconf<\/code>, 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\u00e0 sicuro e affidabile nel tempo. Una VPN ben configurata \u00e8 oggi uno degli strumenti pi\u00f9 efficaci per proteggere il traffico su reti non fidate.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"related-coverage\">Related Coverage<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"\/it\/tor-vs-vpn\/\">Tor contro VPN: 3 rel\u00e8 contro 1 tunnel a confronto<\/a><\/li>\n<li><a href=\"\/it\/nordvpn-vs-surfshark-vs-proton-vpn\/\">NordVPN contro Surfshark contro Proton VPN: il confronto 2026<\/a><\/li>\n<li><a href=\"\/it\/crittografia-end-to-end-nodejs\/\">Crittografia end-to-end in Node.js: tutorial in 12 step<\/a><\/li>\n<li><a href=\"\/it\/certbot-lets-encrypt-https\/\">Let&#8217;s Encrypt e Certbot: HTTPS gratis in 10 step<\/a><\/li>\n<li><a href=\"\/it\/brave-vs-firefox\/\">Brave contro Firefox: privacy e velocit\u00e0 a confronto<\/a><\/li>\n<li><a href=\"\/it\/proton-mail-vs-tuta\/\">Proton Mail contro Tuta: la posta cifrata a confronto<\/a><\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\"><em>Fonti e approfondimenti: <a href=\"https:\/\/www.wireguard.com\/\" target=\"_blank\" rel=\"noopener\">sito ufficiale WireGuard<\/a>, <a href=\"https:\/\/www.wireguard.com\/quickstart\/\" target=\"_blank\" rel=\"noopener\">guida rapida WireGuard<\/a>, <a href=\"https:\/\/www.wireguard.com\/papers\/wireguard.pdf\" target=\"_blank\" rel=\"noopener\">whitepaper tecnico del protocollo (PDF)<\/a>, <a href=\"https:\/\/documentation.ubuntu.com\/server\/how-to\/wireguard-vpn\/\" target=\"_blank\" rel=\"noopener\">documentazione ufficiale Ubuntu Server<\/a> e <a href=\"https:\/\/en.wikipedia.org\/wiki\/WireGuard\" target=\"_blank\" rel=\"noopener\">scheda WireGuard su Wikipedia<\/a>.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Una VPN aziendale costruita su OpenVPN porta con s\u00e9 migliaia di righe di codice, certificati X.509 difficili da gestire e una latenza che si fa sentire. WireGuard ribalta questo modello:\u2026<\/p>\n","protected":false},"author":9,"featured_media":128,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[],"class_list":["post-127","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-privacy"],"_links":{"self":[{"href":"https:\/\/shattered.io\/it\/wp-json\/wp\/v2\/posts\/127","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/shattered.io\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/shattered.io\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/shattered.io\/it\/wp-json\/wp\/v2\/users\/9"}],"replies":[{"embeddable":true,"href":"https:\/\/shattered.io\/it\/wp-json\/wp\/v2\/comments?post=127"}],"version-history":[{"count":1,"href":"https:\/\/shattered.io\/it\/wp-json\/wp\/v2\/posts\/127\/revisions"}],"predecessor-version":[{"id":129,"href":"https:\/\/shattered.io\/it\/wp-json\/wp\/v2\/posts\/127\/revisions\/129"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/shattered.io\/it\/wp-json\/wp\/v2\/media\/128"}],"wp:attachment":[{"href":"https:\/\/shattered.io\/it\/wp-json\/wp\/v2\/media?parent=127"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/shattered.io\/it\/wp-json\/wp\/v2\/categories?post=127"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/shattered.io\/it\/wp-json\/wp\/v2\/tags?post=127"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}