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 testati in produzione che funzionano su Contabo VPS S, 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.

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. Negli ultimi sei mesi abbiamo contato più di venti thread su Reddit in cui i principianti hanno posto la stessa domanda: "il mio tunnel si avvia, il ping funziona verso il server, ma nessuna connessione HTTP funziona dal client". In 9 casi su 10 era 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. Quando WireGuard 1.1 verrà rilasciato (probabilmente 2026-2027) con modifiche alle direttive, 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, 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 dopo ~3 min di inattività.
• 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.

Strumenti online per generare questi intervalli: wg-allowed-ips.compute() o Tunsafe / WireGuard Network Calc.

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 l'1% 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 (~30% di overhead) 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.

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)
• Fail2ban sulla porta UDP 51820 se noti tentativi di scansione delle porte in journalctl -u wg-quick@wg0
• 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 ML-DPI del GFW identifica le sessioni WireGuard in pochi minuti.

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.

Approfondimenti

Se vuoi capire perché WireGuard supera OpenVPN a parità di CPU, abbiamo eseguito un confronto tecnico dettagliato con benchmark reali iperf3 su Contabo, modulo kernel vs spazio utente, e profilo batteria iPhone.

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 VPS S a 4,99 €/mese (/go/contabo-vps-2y) — abbastanza spazio per un tunnel di produzione stabile più altri servizi self-hosted a fianco.