Modelli di configurazione WireGuard pronti all'uso 2026

Hai installato WireGuard sul tuo VPS. Hai letto tre tutorial contraddittori. Il wg0.conf che hai incollato non pinga, oppure pinga ma ci sono perdite DNS, o il kill switch blocca l'intera macchina quando ti disconnetti. La causa è quasi sempre la stessa: un modello copiato senza comprendere il contesto originale.

Questa guida fornisce 8 modelli wg0.conf per Contabo Cloud VPS 4, con casi d'uso, problemi noti e le quattro righe che devi adattare. Scegli quello che corrisponde al tuo scenario, scambia le chiavi, connettiti. Cinque minuti.

Non hai ancora un server? Tutti i modelli qui sotto presuppongono un VPS con IPv4 pubblico. Un Contabo Cloud VPS 4 è in listino da 5,50 €/mese su contabo.com (prezzo di listino verificato il 17 ottobre 2026, durata 24 mesi, IVA esclusa). È un link di affiliazione: potremmo ricevere una commissione, il tuo prezzo non cambia. Se preferisci un provider statunitense con 30 giorni soddisfatti o rimborsati, il VPS Basic di Ultahost costa 5,52 $ al mese su 24 mesi (1 GB di RAM, IPv4 dedicato, letto il 21 ottobre 2026), sufficiente per un server WireGuard con pochi dispositivi.

Vuoi il modello già compilato? Il nostro generatore di configurazione WireGuard gratuito prende l'IP del tuo server, la sottorete e il numero di peer, e scrive un wg0.conf pronto da incollare più le configurazioni dei client, con chiavi generate nel tuo browser. I modelli qui sotto servono a capire cosa fa ogni riga e i problemi di ciascun scenario. Il generatore è gratuito e senza account, fino a 250 dispositivi, e la sua esportazione ZIP raccoglie ogni .conf client e il suo codice QR in PNG, comodo per configurare un intero ufficio o una famiglia in una volta.

Non hai ancora scelto il VPS? Il nostro confronto Miglior VPS per una VPN mette a confronto otto provider per l'auto-hosting di WireGuard sul prezzo che paghi davvero, comprese le due voci che cambiano la classifica: IPv4 a pagamento e limitazione della banda.

Perché usare modelli invece di generare tutto a mano

WireGuard è noto per avere una configurazione minimalista rispetto a OpenVPN, ma minimalista non significa banale. Ogni sezione ha un significato implicito che i tutorial copiano e incollano senza spiegare, e un singolo valore errato può rompere silenziosamente il tunnel o far trapelare il traffico in chiaro senza sintomi visibili immediati. Una domanda che i principianti pongono di continuo: "il mio tunnel si avvia, il ping funziona verso il server, ma nessuna connessione HTTP funziona dal client". La causa abituale è un AllowedIPs fuori posto o un PostUp/PostDown mancante.

I modelli qui sotto coprono 8 scenari di distribuzione distinti e reali. Ognuno viene fornito con un commento contestuale che descrive per chi è, cosa garantisce e i limiti noti. Se il tuo caso corrisponde al modello all'80%, adatti il restante 20%; se il tuo caso non si adatta a nessun modello, ricostruisci dal modello più vicino e mantieni solo le direttive che si applicano a te. È più veloce che partire da zero e più affidabile che ricucire da una risposta casuale di Stack Overflow del 2020.

L'altro motivo per usare i modelli è la manutenzione a lungo termine. Se una futura versione di WireGuard modificherà una direttiva, ripubblicheremo i modelli con le regolazioni chiaramente indicate, e saprai esattamente quale linea aggiornare nel tuo wg0.conf. È l'equivalente VPN di un manifesto Kubernetes versionato - il valore non sta nel contenuto iniziale, ma nella capacità di iterare pulitamente sopra.

Convenzioni condivise

Ogni modello segue le stesse regole - semplifica il tuo modello mentale:

• Subnet client: 10.66.66.0/24 (peer .2 → .254)
• Interfaccia server pubblica: eth0 (controlla con ip route | awk '/default/ {print $5}')
• Porta UDP: 51820 (modificabile e da aprire nel firewall; vedi modello 7 offuscamento)
• Chiavi: generate tramite wg genkey | tee server.key | wg pubkey > server.pub
• Sysctl: net.ipv4.ip_forward=1 abilitato sul server (/etc/sysctl.conf)
• MTU: 1420 di default, ottimizzato quando necessario

I blocchi PrivateKey qui sotto sono segnaposto - sostituiscili con i tuoi. Non commettere mai questi file in un repository git pubblico.

Modello 1 - Server WireGuard standard (1 client roadwarrior)

Il caso più comune: il tuo VPS Contabo espone un tunnel per il tuo MacBook in viaggio.

# /etc/wireguard/wg0.conf (server)
[Interface]
PrivateKey = SERVER_PRIVATE_KEY_HERE
Address = 10.66.66.1/24
ListenPort = 51820
MTU = 1420

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# MacBook di Eric
PublicKey = CLIENT_PUBLIC_KEY_HERE
AllowedIPs = 10.66.66.2/32

Lato client:

# /etc/wireguard/wg0.conf (client macOS/Linux)
[Interface]
PrivateKey = CLIENT_PRIVATE_KEY_HERE
Address = 10.66.66.2/24
DNS = 9.9.9.9, 149.112.112.112
MTU = 1420

[Peer]
PublicKey = SERVER_PUBLIC_KEY_HERE
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

Punti di attenzione:

• AllowedIPs = 0.0.0.0/0, ::/0 instrada TUTTO il traffico del client attraverso il VPS - è ciò che desideri per una VPN classica.
• PersistentKeepalive = 25 è obbligatorio se il client si trova dietro NAT (rete dell'hotel, 4G) - senza di esso, il tunnel muore non appena scade il mapping NAT.
• DNS = 9.9.9.9 forza la risoluzione Quad9 - altrimenti il client utilizza il DNS locale e le tue query trapelano.

Modello 2 - VPN domestica (split-tunnel: LAN locale esclusa)

Vuoi la VPN per il tuo traffico web ma mantenere l'accesso alla LAN locale (stampante, NAS) senza passare attraverso il tunnel.

# Client domestico
[Interface]
PrivateKey = CLIENT_PRIVATE_KEY_HERE
Address = 10.66.66.2/24
DNS = 9.9.9.9
MTU = 1420

[Peer]
PublicKey = SERVER_PUBLIC_KEY_HERE
Endpoint = vpn.example.com:51820
# Tutto tranne LAN RFC1918 + multicast + APIPA
AllowedIPs = 0.0.0.0/1, 128.0.0.0/2, 192.0.0.0/3, 224.0.0.0/4, 240.0.0.0/5, 248.0.0.0/6, 252.0.0.0/7, 254.0.0.0/8, 255.0.0.0/9
PersistentKeepalive = 25

Il trucco della subnet frammentata (invece di 0.0.0.0/0) fa sì che WireGuard aggiunga rotte specifiche che non sovrascrivono la rotta predefinita. La tua LAN 192.168.x.x e 10.x.x.x rimangono raggiungibili direttamente.

Un calcolatore AllowedIPs online può generare questi intervalli per te.

Modello 3 - VPN da viaggio con kill switch netfilter rigoroso

Stai volando verso Cina, Iran, Russia. Se il tunnel cade, niente trapela. Soluzione: kill switch netfilter che blocca tutto tranne il traffico tramite wg0 e la stretta di mano del server.

# Client kill-switch da viaggio
[Interface]
PrivateKey = CLIENT_PRIVATE_KEY_HERE
Address = 10.66.66.2/24
DNS = 9.9.9.9
MTU = 1280

PostUp = iptables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PostUp = ip6tables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PreDown = ip6tables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT

[Peer]
PublicKey = SERVER_PUBLIC_KEY_HERE
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

Quelle quattro righe PostUp/PreDown sono il vero kill switch - non un popup dell'applicazione. Fino a quando wg-quick down wg0 non viene eseguito, nessun pacchetto lascia l'interfaccia che non sia marcato WireGuard.

MTU 1280 per reti esigenti (hotel, 3G). Perdere un po' di throughput è meglio di un tunnel instabile.

Modello 4 - Multi-peer (5 dispositivi, stesso utente)

Hai un MacBook, iPhone, iPad, VPS di lavoro, Raspberry Pi. Vuoi che siano tutti instradati tramite la stessa VPN con subnet separate per il monitoraggio.

# /etc/wireguard/wg0.conf (server)
[Interface]
PrivateKey = SERVER_PRIVATE_KEY_HERE
Address = 10.66.66.1/24
ListenPort = 51820

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# MacBook
PublicKey = MAC_PUBKEY
AllowedIPs = 10.66.66.2/32

[Peer]
# iPhone
PublicKey = IPHONE_PUBKEY
AllowedIPs = 10.66.66.3/32

[Peer]
# iPad
PublicKey = IPAD_PUBKEY
AllowedIPs = 10.66.66.4/32

[Peer]
# VPS di lavoro (Hetzner)
PublicKey = WORKER_PUBKEY
AllowedIPs = 10.66.66.5/32

[Peer]
# Raspberry Pi a casa
PublicKey = RPI_PUBKEY
AllowedIPs = 10.66.66.6/32

Ogni peer ha un IP fisso sulla subnet 10.66.66.0/24. Se monitori tramite Prometheus (vedi la guida al monitoraggio), puoi etichettare per IP e sapere chi consuma quanta larghezza di banda.

Modello 5 - Hub-and-spoke (peer-to-peer tra client)

Di default WireGuard non instrada tra peer. Se vuoi che il tuo iPhone parli con il tuo Raspberry Pi attraverso il server hub:

Sul server, aggiungi:

sysctl -w net.ipv4.ip_forward=1

E nei blocchi [Peer] del server, imposta AllowedIPs = 10.66.66.X/32 (IP unico del peer).

Sui client, cambia AllowedIPs:

[Peer]
PublicKey = SERVER_PUBLIC_KEY_HERE
Endpoint = vpn.example.com:51820
# Intera subnet, non solo 0.0.0.0/0
AllowedIPs = 10.66.66.0/24

Ora dal tuo iPhone (10.66.66.3) puoi ssh pi@10.66.66.6 direttamente - l'hub inoltra.

Modello 6 - Restrizione egress per peer (lista di permessi)

Caso avanzato: un peer (tuo figlio, un ospite, un servizio automatizzato) dovrebbe connettersi al tunnel ma raggiungere solo domini/IP specifici.

Aggiungi al PostUp del server, oltre a MASQUERADE:

iptables -A FORWARD -s 10.66.66.50/32 -d 1.1.1.1 -j ACCEPT
iptables -A FORWARD -s 10.66.66.50/32 -d 142.250.0.0/15 -j ACCEPT  # Google
iptables -A FORWARD -s 10.66.66.50/32 -j REJECT

Il peer 10.66.66.50 può raggiungere solo 1.1.1.1 (DNS) e gli IP di Google. Tutto il resto è rifiutato.

Modello 7 - Offuscamento su porta 443 tramite udp2raw

Alcuni firewall aziendali bloccano l'UDP in uscita. Soluzione: incapsulare WireGuard all'interno di falso TCP/443 tramite udp2raw.

Lato server:

udp2raw_amd64 -s -l 0.0.0.0:443 -r 127.0.0.1:51820 -k "p@ssw0rd_long" --raw-mode faketcp

Lato client:

udp2raw_amd64 -c -l 127.0.0.1:50000 -r vpn.example.com:443 -k "p@ssw0rd_long" --raw-mode faketcp

Nel wg0.conf del client, cambia Endpoint:

Endpoint = 127.0.0.1:50000

Il throughput diminuisce (l'incapsulamento aggiuntivo ha un costo) ma si tunnelizza attraverso quasi qualsiasi DPI aziendale.

Modello 8 - Site-to-site (due LAN collegate)

Due case, due gateway Raspberry Pi, un VPS Contabo come hub. Ogni LAN vede l'altra come se fosse locale.

Server (hub VPS):

[Interface]
PrivateKey = HUB_PRIVATE_KEY_HERE
Address = 10.66.66.1/24
ListenPort = 51820

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# Sito A (LAN 192.168.10.0/24)
PublicKey = SITE_A_PUBKEY
AllowedIPs = 10.66.66.10/32, 192.168.10.0/24

[Peer]
# Sito B (LAN 192.168.20.0/24)
PublicKey = SITE_B_PUBKEY
AllowedIPs = 10.66.66.20/32, 192.168.20.0/24

Sito A (Raspberry Pi):

[Interface]
PrivateKey = SITE_A_PRIVATE_KEY_HERE
Address = 10.66.66.10/24

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE

[Peer]
PublicKey = HUB_PUBLIC_KEY_HERE
Endpoint = vpn.example.com:51820
AllowedIPs = 10.66.66.0/24, 192.168.20.0/24
PersistentKeepalive = 25

Non dimenticare ip_forward su entrambi i Raspberry e una rotta statica su altre macchine LAN se devono rispondere dall'altro sito.

Diagnostica rapida quando nulla funziona

Hai incollato il modello, esegui wg-quick up wg0, si avvia - ma il ping fallisce. Checklist in questo ordine:

• wg show: ultima stretta di mano recente? Se "mai" → stretta di mano KO, controlla Endpoint, porta UDP sul firewall del server (ufw status o iptables -L).
• ip route sul client: rotta verso la subnet VPN presente? Se no → AllowedIPs del client errato.
• dig @9.9.9.9 ifconfig.me +short dal client connesso: restituisce l'IP del VPS? Se no → MASQUERADE mancante sul server, o ip_forward = 0.
• tcpdump -i wg0 sul server: vedi pacchetti in arrivo? Se sì ma nulla esce da eth0 → regola FORWARD/MASQUERADE mancante.
• MTU: ping -M do -s 1400 1.1.1.1 dal client. Se "Necessaria frammentazione" → riduci MTU in wg0.conf a 1380 o 1280. La nostra guida per riparare l'MTU di WireGuard descrive la misurazione senza frammentazione e il valore corretto per tipo di collegamento.

Se stai iniziando da zero e sei bloccato, la guida passo-passo all'installazione su Contabo copre l'intera installazione dall'SSH iniziale.

In produzione: cosa saltano questi modelli

Sono intenzionalmente minimali. Per una produzione a lungo termine, pianifica:

• Backup regolare di /etc/wireguard/ (perdere la chiave del server = rigenerare tutti i client)
• Rotazione delle chiavi ogni 12-18 mesi (procedura: genera nuova chiave, aggiungi peer parallelo, migra i client uno per uno, ritira il vecchio peer)
• Monitoraggio tramite Prometheus + wireguard_exporter (vedi guida al monitoraggio)
• Cos'è una Subnet? Spiegazione di Subnetting e CIDR (2026)
• WireGuard su Android: Guida Completa all'Installazione (2026)
• Fail2ban su SSH, non su WireGuard. WireGuard non risponde mai a un pacchetto non autenticato e non scrive alcuna riga di tentativo fallito, quindi journalctl -u wg-quick@wg0 non dà a fail2ban nulla da rilevare. Proteggi invece la porta SSH.
• Limite di larghezza di banda per peer tramite tc (controllo del traffico Linux) se un peer consuma troppa larghezza di banda

E soprattutto: non commettere mai un vero wg0.conf in un repository, anche privato. Mantienili .gitignore'd o crittografali con age / sops.

Quando WireGuard non basta: V2Ray per paesi censurati

WireGuard è eccellente per casi d'uso di privacy standard. Tuttavia, il WireGuard standard (incluso NordLynx) è ora sistematicamente bloccato dal Grande Firewall della Cina e sempre più filtrato in Russia e Iran: il suo formato di handshake fisso è riconoscibile dalla deep packet inspection.

Se il tuo obiettivo è bypassare la censura attiva (Cina, Iran, Russia), i modelli WireGuard non ti aiuteranno da soli. Hai bisogno di offuscamento: o WireGuard + Cloak (strato di mascheramento TLS) o un cambio completo di protocollo a V2Ray VMess/VLESS con REALITY per Cina, Iran, Russia. Il protocollo REALITY di V2Ray rende il tuo server indistinguibile da un nodo CDN di Microsoft - lo stato dell'arte attuale contro l'ispezione profonda dei pacchetti del GFW nel 2026.

Per avere l'essenziale a portata di mano: la WireGuard Cheat Sheet gratuita (PDF di 5 pagine in inglese, download diretto, senza registrazione) raccoglie le tabelle di keepalive e MTU, i comandi wg genkey/wg pubkey/wg genpsk e i quattro controlli del server in una riga da lanciare per primi quando un tunnel non fa passare traffico. Il WireGuard Self-Hosting Kit a pagamento (9 USD, in inglese) aggiunge una checklist di diagnosi con 12 cause e 11 modelli di configurazione.

Una VPN cambia il tuo IP. Non cambia il tuo browser.

Un tunnel sostituisce l'indirizzo che un servizio vede. Non cambia nulla di ciò che il tuo browser dichiara da solo - caratteri, schermo, fuso orario, stack grafico - e quella combinazione basta spesso a riconoscerti da una sessione all'altra.

Misura la tua impronta del browser - misurazione passiva, senza domande, senza account, senza email.

Approfondimenti

Se vuoi capire perché WireGuard supera OpenVPN a parità di CPU, vedi il nostro confronto tecnico WireGuard vs OpenVPN (modulo kernel vs spazio utente).

E per la parte anti-perdite, la guida al kill switch su Linux (iptables + systemd) mostra come garantire zero perdite anche quando WireGuard si arresta.

Preferisci un wizard visivo ai blocchi INI grezzi? Il nostro generatore di configurazione WireGuard prende l'IP del tuo server, la subnet e il numero di peer e produce un wg0.conf pronto da incollare in meno di un minuto. E per verificare se il VPS Contabo S è più economico del tuo attuale piano NordVPN su 2 anni, inserisci i numeri nel nostro calcolatore di costi VPN self-hosted.

Ogni modello sopra è costruito per funzionare su un Contabo Cloud VPS 4 - abbastanza spazio per un tunnel di produzione stabile più altri servizi self-hosted a fianco.