1,201 25/03/2026 07/04/2026 8 min

Se devi far convivere accesso remoto, rete aziendale e navigazione normale, la VPN sbagliata ti complica la vita. Il problema non è “funziona o non funziona”. Il problema è quale traffico passa nel tunnel, quale DNS usa il client e cosa succede quando hai più dispositivi attivi.

In questo articolo confronto WireGuard e OpenVPN in uno scenario reale: split routing per raggiungere solo alcune subnet, prevenzione dei DNS leak, correzione MTU e gestione di client multipli sullo stesso account. L’obiettivo è scegliere l’approccio giusto, non tifare per un protocollo.

Prerequisiti

Assumo un server Linux con accesso root o sudo e una rete privata già definita. Gli esempi usano una VPN con queste reti:

  • LAN aziendale: 10.20.0.0/16
  • DNS interno: 10.20.0.53
  • Endpoint pubblico della VPN: vpn.example.net

Tool utili lato client:

  • WireGuard con wg-quick su Linux o app ufficiale su Windows, macOS, iOS, Android.
  • OpenVPN con client ufficiale o openvpn da terminale.
  • resolvectl o systemd-resolved su Linux moderno.
  • tcpdump per verifiche rapide sul traffico.

Note: se il tuo server è dietro NAT o un firewall gestito, la parte più importante non è il protocollo. È il routing di ritorno e la coerenza dei DNS.

Step 1: scegli l’architettura prima del client

Il punto di partenza è decidere se vuoi full tunnel o split tunnel. Nel full tunnel mandi tutto nella VPN. Nel split tunnel mandi solo le reti interne. Per la maggior parte dei team misti, lo split tunnel è più pulito.

WireGuard rende lo split routing molto semplice perché il routing dipende da AllowedIPs. OpenVPN lo fa con push route, iroute e opzioni DNS, ma richiede più disciplina lato server.

WireGuard, esempio concettuale:

[Peer]
PublicKey = ...
AllowedIPs = 10.20.0.0/16, 10.20.0.53/32

# Output: solo la rete interna e il DNS interno passano nel tunnel.

OpenVPN, esempio concettuale lato server:

push "route 10.20.0.0 255.255.0.0"
push "dhcp-option DNS 10.20.0.53"

# Output: il client riceve la rotta per la LAN e il DNS interno.

Perché conta: se devi pubblicare servizi SaaS e raggiungere solo il gestionale interno, lo split tunnel riduce latenza e problemi di supporto. Il full tunnel ha senso quando vuoi filtrare tutto il traffico o imporre policy centralizzate.

Step 2: WireGuard per routing pulito e pochi componenti

WireGuard è la scelta migliore quando vuoi semplicità, latenza bassa e configurazione essenziale. È più facile da auditare. Ha meno opzioni. Questo è un vantaggio, non un limite, se la tua topologia è chiara.

Configurazione server minima:

[Interface]
Address = 10.99.0.1/24
ListenPort = 51820
PrivateKey = SERVER_PRIVATE_KEY

[Peer]
PublicKey = CLIENT1_PUBLIC_KEY
AllowedIPs = 10.99.0.10/32

# Output: il peer client viene raggiunto come 10.99.0.10.

Configurazione client con split routing:

[Interface]
Address = 10.99.0.10/32
PrivateKey = CLIENT1_PRIVATE_KEY
DNS = 10.20.0.53
MTU = 1380

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16, 10.99.0.0/24
PersistentKeepalive = 25

# Output: solo la LAN e la subnet VPN passano nel tunnel.

Perché scegliere WireGuard:

  • Hai pochi peer e vuoi configurazioni brevi.
  • Ti serve performance prevedibile.
  • Vuoi meno superfici di errore su route e cifrature.

Quando non basta: se hai bisogno di assegnare policy diverse per gruppi utenti, script di connessione, o compatibilità con ambienti vecchi, OpenVPN resta più flessibile.

Step 3: OpenVPN quando serve controllo fine e compatibilità

OpenVPN è più verboso, ma ancora utile quando vuoi gestire profili diversi, client legacy o integrazioni con autenticazione esterna. È spesso la scelta giusta in ambienti dove il client deve ricevere route, DNS e policy da server con maggiore granularità.

Snippet server OpenVPN per split tunnel e DNS interno:

server 10.8.0.0 255.255.255.0
push "route 10.20.0.0 255.255.0.0"
push "dhcp-option DNS 10.20.0.53"
push "block-outside-dns"

# Output: il client usa la LAN interna e riduce il rischio di leak DNS su Windows.

Su Linux con systemd-resolved, lato client puoi verificare e forzare la DNS route così:

resolvectl status tun0
resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~internal.example

# Output: le query per il dominio interno seguono il tunnel.

Perché scegliere OpenVPN:

  • Ti serve compatibilità con appliance o client più vecchi.
  • Vuoi push policy centralizzate lato server.
  • Devi fare troubleshooting dettagliato con log e hook.

Nota: OpenVPN richiede più attenzione al pairing tra route, DNS e firewall. Se la tua squadra cambia spesso, documenta le eccezioni per client e OS.

Step 4: evita i DNS leak con una sola regola operativa

Il DNS leak nasce quando il traffico passa nella VPN, ma le query DNS escono fuori. Questo succede spesso con split tunnel mal configurato, oppure quando il client usa il resolver locale invece di quello interno.

Con WireGuard, la soluzione è definire esplicitamente il DNS nel profilo e limitare AllowedIPs solo alle reti necessarie. Con OpenVPN, la soluzione è pushare il DNS corretto e bloccare il fallback verso resolver pubblici, dove possibile.

Checklist pratica:

  • Il client deve ricevere un DNS interno raggiungibile nel tunnel.
  • Il dominio interno deve essere instradato nel resolver corretto.
  • Il firewall del client non deve forzare un DNS esterno in parallelo.

Verifica rapida su Linux:

resolvectl query host.interno.example
ip route get 10.20.0.53
tcpdump -ni any port 53

# Output: la query interna risolve via DNS VPN e non verso 8.8.8.8.

Warning: se usi browser con DoH attivo, il DNS leak può continuare anche con la VPN perfetta. In quel caso devi gestire il resolver del browser o la policy aziendale.

Step 5: correggi MTU prima di inseguire finti problemi applicativi

Molti “bug” di VPN sono solo frammentazione o pacchetti troppo grandi. La sintomatologia è classica: siti che aprono a metà, SSH che cade, upload che si bloccano, API che rispondono male solo da remoto.

WireGuard spesso lavora bene con MTU = 1380 o simili, ma il valore dipende dal tuo percorso reale. OpenVPN su UDP può richiedere correzioni diverse, spesso con mssfix o tun-mtu.

Esempio OpenVPN lato server o client:

tun-mtu 1500
mssfix 1360

# Output: i pacchetti TCP si adattano al percorso senza frammentazione inutile.

Test veloce da Linux:

ping -M do -s 1372 10.20.0.53
ping -M do -s 1300 10.20.0.53

# Output: il ping grande fallisce se l’MTU è troppo alta; quello più piccolo passa.

Perché conta: WireGuard tende a essere più prevedibile sulla latenza. OpenVPN è più tollerante come ecosistema, ma richiede tuning più frequente.

Step 6: gestisci client multipli senza mischiare identità

Quando hai più dispositivi per lo stesso utente, il problema non è solo la connessione simultanea. Devi evitare conflitti di IP, route e revoca selettiva.

Con WireGuard, ogni dispositivo deve avere una chiave propria e un IP unico. Non condividere lo stesso profilo tra laptop, telefono e server di test.

Con OpenVPN, puoi usare certificati diversi per ogni device e revocare solo quello compromesso. Questo è un vantaggio forte in ambienti aziendali.

WireGuard, esempio di separazione device:

[Peer]
PublicKey = LAPTOP_PUBLIC_KEY
AllowedIPs = 10.99.0.10/32

[Peer]
PublicKey = PHONE_PUBLIC_KEY
AllowedIPs = 10.99.0.11/32

# Output: ogni client ha indirizzo e identità distinti.

OpenVPN, approccio con certificati diversi:

easy-rsa revoke laptop-01
systemctl restart openvpn-server@server

# Output: il laptop revocato non si collega più, gli altri restano attivi.

Note: se la tua priorità è la revoca fine per device, OpenVPN resta più comodo. Se la tua priorità è semplicità operativa, WireGuard è più lineare.

Step 7: scegli in base al problema, non al marchio

WireGuard vince quando ti serve un tunnel pulito, veloce e facile da mantenere. OpenVPN vince quando ti serve flessibilità, compatibilità e controllo granulare lato server.

Regola pratica:

  • WireGuard se hai pochi peer, routing chiaro e vuoi meno manutenzione.
  • OpenVPN se hai client eterogenei, policy complesse e revoca per certificato.

In uno scenario con team piccolo e subnet ben definite, WireGuard è quasi sempre più efficiente. In un ambiente con utenti numerosi, device misti e policy centralizzate, OpenVPN è spesso meno elegante ma più robusto sul piano organizzativo.

Verifica finale

Prima di considerare chiusa la configurazione, controlla questi punti:

  1. Il client raggiunge solo le subnet autorizzate.
  2. Il DNS interno risolve i nomi privati.
  3. Il traffico verso internet segue il comportamento previsto: full tunnel o split tunnel.
  4. Non ci sono timeout anomali su SSH, RDP o API.
  5. Ogni device ha una chiave o certificato distinto.

Comandi utili di verifica su Linux:

ip route
wg show
resolvectl status
curl -s https://ifconfig.me

# Output: route coerenti, tunnel attivo, DNS corretto e IP pubblico atteso.

Troubleshooting

1) RTNETLINK answers: File exists

Causa: hai inserito una rotta duplicata, spesso perché AllowedIPs e route manuale puntano alla stessa subnet.

Fix:

ip route
ip route del 10.20.0.0/16 dev wg0
wg-quick down wg0 && wg-quick up wg0

# Output: la tabella route torna coerente e il tunnel riparte.

2) Temporary failure in name resolution

Causa: il client usa il DNS locale, ma il dominio interno è raggiungibile solo nel tunnel.

Fix:

resolvectl dns wg0 10.20.0.53
resolvectl domain wg0 ~internal.example
resolvectl flush-caches

# Output: le query del dominio interno risolvono via VPN.

3) sendmsg: Message too long

Causa: MTU troppo alta rispetto al percorso reale, spesso con UDP e incapsulamento aggiuntivo.

Fix:

sed -i 's/^MTU = .*/MTU = 1380/' /etc/wireguard/wg0.conf
wg-quick down wg0 && wg-quick up wg0

# Output: i pacchetti passano senza frammentazione visibile.

Conclusione

Se vuoi semplicità operativa, routing pulito e meno manutenzione, WireGuard è il primo candidato. Se ti servono policy più ricche, compatibilità ampia e revoca per certificato, OpenVPN resta molto forte.

Il prossimo passo concreto è testare lo stesso scenario su due client reali: un laptop e uno smartphone. Misura DNS, MTU e route prima di standardizzare il profilo per tutto il team.