WireGuard: cos’è, come funziona e quando usarlo in una VPN

WireGuard è un protocollo VPN progettato per creare tunnel IP cifrati fra peer con un’architettura volutamente essenziale. La sua forza non consiste semplicemente nell’essere “più nuovo” di OpenVPN o IPsec: deriva soprattutto dal fatto che cerca di fare poche cose a livello di protocollo, lasciando a software e servizi superiori compiti come gestione degli utenti, distribuzione delle configurazioni e policy applicative.

È proprio questa scelta progettuale a spiegare sia i vantaggi sia molti dei limiti di WireGuard. Configurazione e modello crittografico sono relativamente compatti, il roaming fra indirizzi IP è integrato e l’overhead può essere contenuto; in compenso WireGuard non include un trasporto TCP alternativo, non cerca di mascherare il proprio traffico e non offre da solo un sistema completo di gestione degli utenti.

Se vuoi partire dal livello precedente, nella guida su cos’è una VPN e come funziona trovi il modello generale di tunnel, routing e confini della protezione. Qui restringiamo il campo: vediamo cosa succede dentro un tunnel WireGuard, come leggere una configurazione e in quali scenari lo sceglierei davvero.

Cos’è WireGuard e a cosa serve

WireGuard è contemporaneamente il nome di un protocollo VPN e del progetto software che ne fornisce implementazioni e strumenti.

Il protocollo definisce il modo in cui due peer si autenticano, stabiliscono chiavi di sessione e scambiano pacchetti IP cifrati. Le implementazioni trasformano questo modello in un’interfaccia di rete utilizzabile sui sistemi operativi supportati.

Il progetto ufficiale WireGuard lo descrive come una VPN general purpose e multipiattaforma, disponibile su Linux, Windows, macOS, Android, iOS e altri sistemi. Lo sviluppo è inoltre ancora attivo: nel 2026 wireguard-tools ha ricevuto la release 1.0.20260223 e il repository upstream di wireguard-tools continua a documentarne l’evoluzione.

WireGuard è un protocollo, un software o una VPN?

La risposta più precisa è: dipende dal livello di cui stiamo parlando.

WireGuard definisce un protocollo per realizzare tunnel VPN, ma il progetto comprende anche software e strumenti che implementano quel protocollo. Non è invece, da solo, un servizio VPN commerciale paragonabile a un provider che vende account, server in più paesi, app, assistenza e funzioni aggiuntive.

Questa distinzione evita parecchia confusione.

Quando un provider scrive “supportiamo WireGuard”, significa che utilizza il protocollo — eventualmente insieme a componenti propri — all’interno del suo servizio. Kill switch, selezione automatica dei server, gestione dell’account, DNS leak protection, autenticazione dell’utente o politiche no-log appartengono al prodotto del provider, non diventano automaticamente caratteristiche del protocollo WireGuard.

Cosa fa WireGuard e cosa lascia agli altri componenti della VPN

WireGuard si occupa principalmente di:

• identificare i peer attraverso chiavi pubbliche;
• stabilire chiavi crittografiche di sessione;
• cifrare e autenticare pacchetti IP;
• associare peer e indirizzi di tunnel;
• spedire i pacchetti cifrati verso endpoint UDP;
• aggiornare l’endpoint di un peer quando riceve traffico autenticato da un nuovo indirizzo.

La documentazione ufficiale chiarisce anche che problemi come distribuzione delle chiavi e configurazioni inviate centralmente sono fuori dallo scope del protocollo. Questo non significa che tali funzioni non possano esistere: significa che devono essere implementate da un altro livello.

È uno dei concetti più importanti per capire WireGuard: la semplicità non elimina la complessità di una VPN completa. Sposta parte di quella complessità fuori dal protocollo.

Come funziona WireGuard

Una configurazione WireGuard è costruita attorno a interfacce e peer.

Ogni interfaccia possiede una chiave privata. I peer vengono identificati attraverso le rispettive chiavi pubbliche e associati agli indirizzi IP che possono usare all’interno del tunnel.

Quando devi spedire un pacchetto, WireGuard individua il peer appropriato, cifra il pacchetto usando il contesto crittografico relativo a quel peer e invia il risultato al suo endpoint attraverso UDP. In ricezione esegue il percorso inverso: autentica e decifra il pacchetto, identifica il peer e verifica se quell’origine è compatibile con gli indirizzi assegnati.

Il modello sembra semplice perché non esiste la classica sessione da amministrare come entità applicativa separata: porti su l’interfaccia, definisci peer e routing e WireGuard gestisce automaticamente handshake e rinnovo delle chiavi quando necessario.

Peer, chiavi pubbliche e private e handshake

In WireGuard l’identità crittografica di base di un peer è una coppia di chiavi.

La chiave privata deve rimanere sul dispositivo che la possiede. Dalla chiave privata viene derivata la relativa chiave pubblica, che può essere distribuita agli altri peer autorizzati.

Il principio ricorda più da vicino lo scambio di chiavi SSH che un’infrastruttura completa basata su certificati: per permettere a due peer di comunicare, ciascuno deve conoscere la chiave pubblica necessaria alla configurazione.

Per lo scambio delle chiavi di sessione WireGuard utilizza l’handshake Noise_IK. Le chiavi simmetriche utilizzate per il traffico non rimangono fisse per tutta la vita dell’interfaccia: il protocollo rinnova periodicamente il materiale di sessione per mantenere proprietà di forward secrecy. La documentazione tecnica del protocollo WireGuard descrive nel dettaglio handshake, derivazione delle chiavi e primitive crittografiche utilizzate.

Non devi quindi pensare alla chiave pubblica configurata come alla chiave utilizzata direttamente per cifrare per sempre ogni pacchetto. È parte dell’identità e del processo con cui vengono stabilite le chiavi operative.

Cryptokey routing: il ruolo di AllowedIPs

AllowedIPs è probabilmente il parametro più importante da capire, perché svolge due funzioni complementari.

In uscita aiuta WireGuard a stabilire a quale peer destinare un pacchetto. Se una destinazione ricade negli indirizzi associati a un peer, quel peer diventa il candidato a ricevere il traffico.

In ingresso funziona invece come controllo sugli indirizzi che un peer autenticato è autorizzato a presentare all’interno del tunnel.

Nella spiegazione ufficiale del Cryptokey Routing, WireGuard descrive infatti la lista degli IP consentiti come una sorta di tabella di routing durante l’invio e come una sorta di access control list durante la ricezione.

Immagina due peer:

• peer A → 10.0.0.2/32;
• peer B → 10.0.0.3/32.

Se l’interfaccia deve inviare traffico verso 10.0.0.3, l’associazione permette di individuare il peer B. Se dal peer B arriva invece un pacchetto autenticato che sostiene di provenire da 10.0.0.2, la configurazione non coincide e quel traffico può essere rifiutato.

Con 0.0.0.0/0 per IPv4 o ::/0 per IPv6 il match diventa molto più ampio. Nei setup client usati per un full tunnel è comune associare al peer remoto la route predefinita, ma bisogna distinguere il comportamento del protocollo dalla gestione delle route del sistema operativo.

In particolare, wg-quick può dedurre e creare automaticamente le route a partire da AllowedIPs; usando strumenti più bassi come wg e le normali utility di networking, il routing del sistema deve essere gestito esplicitamente. Il comportamento è documentato anche nella pagina di manuale di wg-quick.

Questa distinzione è utile nel troubleshooting: un AllowedIPs corretto non significa automaticamente che qualsiasi stack o tool abbia creato tutte le route che immagini.

UDP, roaming e rinnovo delle chiavi

WireGuard trasporta i propri pacchetti attraverso UDP. Non esiste una modalità WireGuard nativa equivalente a “passa a TCP se UDP è bloccato”.

Il protocollo sfrutta però il proprio modello autenticato per gestire molto bene il cambio di endpoint.

Quando arrivano pacchetti validi da un peer, WireGuard può ricordare l’indirizzo IP e la porta UDP più recenti da cui quel peer ha comunicato. Questo permette, per esempio, a un dispositivo mobile di passare da Wi-Fi a rete cellulare senza dover legare rigidamente la propria identità crittografica a un unico indirizzo Internet.

È importante separare le due cose:

identità del peer → chiave pubblica

posizione attuale del peer → endpoint IP

L’endpoint può cambiare; l’identità crittografica no.

Come protegge il traffico: crittografia e sicurezza di WireGuard

WireGuard utilizza una suite crittografica deliberatamente poco configurabile.

Fra le primitive documentate dal progetto troviamo:

• ChaCha20 per la cifratura simmetrica;
• Poly1305 per l’autenticazione;
• Curve25519 per ECDH;
• BLAKE2s per hashing;
• HKDF per derivazione delle chiavi;
• SipHash24 per specifiche funzioni interne.

L’handshake è costruito sul framework Noise e utilizza il pattern Noise_IK.

Il fatto che le scelte crittografiche siano definite dal protocollo riduce una classe di problemi tipica dei sistemi estremamente configurabili: non devi selezionare manualmente fra decine di combinazioni di algoritmi.

Questo, però, non autorizza la conclusione “WireGuard non può essere configurato male”. Routing, chiavi, firewall, DNS, endpoint, autorizzazioni e infrastruttura continuano a incidere sulla sicurezza reale del deployment.

Perché un design più compatto facilita analisi e audit

Uno degli obiettivi dichiarati di WireGuard è mantenere l’implementazione comprensibile e relativamente compatta rispetto a stack molto più ampi.

Il vantaggio concettuale è chiaro: una superficie più piccola è più facile da studiare, revisionare e mantenere rispetto a un sistema che combina molti protocolli, modalità legacy e possibilità di configurazione.

Ma qui conviene evitare una semplificazione comune nella SERP.

Meno righe di codice non equivalgono matematicamente a più sicurezza.

La dimensione del codice può incidere sull’auditabilità e sulla superficie da analizzare, ma la sicurezza effettiva dipende anche dalla correttezza dell’implementazione, dal modello crittografico, dalla piattaforma, dalla configurazione e da ciò che viene costruito intorno al protocollo.

Dire “WireGuard è sicuro perché ha poche righe di codice” salta troppi passaggi.

Sicurezza del protocollo e sicurezza del servizio VPN non sono la stessa cosa

Puoi avere un ottimo protocollo all’interno di un servizio gestito male.

Puoi anche avere due provider che usano entrambi WireGuard e implementano in modo diverso:

• assegnazione degli indirizzi interni;
• gestione delle chiavi;
• DNS;
• kill switch;
• autenticazione dell’account;
• telemetria;
• logging;
• rotazione delle credenziali;
• infrastruttura server.

WireGuard, da solo, non promette che un provider sia “no-log” e non rende automaticamente anonimo l’utente.

Un esempio utile viene da Proton VPN, che nella propria documentazione su privacy e implementazione di WireGuard spiega come il servizio gestisca aspetti ulteriori rispetto al protocollo base. Il punto non è stabilire quale provider abbia l’implementazione migliore, ma mostrare che la privacy del servizio dipende da molto più del nome del protocollo.

Lo stesso criterio vale quando scegli fra i migliori servizi VPN: il supporto a WireGuard è una caratteristica tecnica importante, non un sostituto dell’analisi di proprietà, policy, audit, infrastruttura e modello di fiducia.

Quali sono i limiti di WireGuard

La documentazione ufficiale sui limiti di WireGuard è utile proprio perché impedisce di trattarlo come una soluzione universalmente superiore.

I limiti più importanti non sono bug accidentali: molti derivano direttamente dalle scelte progettuali.

WireGuard non offre offuscamento nativo

WireGuard non nasce per nascondere il fatto che stai utilizzando WireGuard.

Il progetto considera l’offuscamento un problema da gestire sopra il protocollo. In altre parole, il tunnel può essere crittograficamente solido e allo stesso tempo produrre traffico che una rete è in grado di classificare o bloccare.

Questa distinzione conta in reti aziendali molto restrittive, hotspot filtrati o ambienti in cui il semplice traffico UDP sconosciuto viene limitato.

Se il requisito principale è “deve collegarsi anche quando la rete tenta attivamente di impedire questo tipo di VPN”, il protocollo crittografico è soltanto una parte del problema.

Perché WireGuard non supporta il tunneling TCP

WireGuard invia i propri pacchetti su UDP e non implementa una modalità TCP nativa.

La motivazione dichiarata è evitare i problemi associati all’incapsulamento di TCP dentro TCP. Se serve trasformare il traffico UDP di WireGuard in qualcosa che attraversi un ambiente diverso, il progetto demanda anche questa funzione a un layer superiore.

La conseguenza pratica è importante.

Su una rete normale, UDP è spesso esattamente ciò che vuoi.

Su una rete che lascia passare quasi esclusivamente traffico web, proxy aziendali o TCP su porte consentite, OpenVPN può offrire opzioni di trasporto che WireGuard puro non possiede.

Non è un dettaglio teorico: può essere il criterio che decide quale protocollo riesce effettivamente a collegarsi.

Gestione utenti, distribuzione delle chiavi e altre funzioni restano fuori dal protocollo

WireGuard autentica peer tramite chiavi, ma non definisce un sistema completo di account utenti, password, directory aziendale, provisioning, MFA o distribuzione centralizzata delle configurazioni.

Un prodotto può aggiungere tutte queste funzioni. Il protocollo di base no.

Questo è il trade-off della sua filosofia minimalista: se hai cinque dispositivi personali può essere una qualità enorme; se devi amministrare migliaia di identità, revoche e policy, hai bisogno di un control plane sopra WireGuard oppure di una tecnologia che includa un modello operativo differente.

C’è anche un limite crittografico da non nascondere nel 2026: la documentazione ufficiale afferma che WireGuard non è post-quantum secure di default. È disponibile una pre-shared key aggiuntiva che può fornire un ulteriore livello di protezione, ma non va descritta come se trasformasse automaticamente il protocollo in un sistema post-quantum completo.

WireGuard vs OpenVPN: differenze e quale scegliere

Il confronto WireGuard vs OpenVPN ha senso soltanto se specifichiamo il problema da risolvere.

Entrambi possono creare tunnel VPN robusti. Differiscono però molto nella filosofia progettuale.

Criterio	WireGuard	OpenVPN
Trasporto	UDP	UDP o TCP
Modello crittografico	suite moderna e definita dal protocollo	stack TLS/OpenSSL più configurabile
Identità base	coppie di chiavi fra peer	modelli basati su certificati e altre opzioni secondo il deployment
Configurazione	superficie relativamente piccola	molte più opzioni
Roaming	endpoint aggiornabile da traffico autenticato	dipende dal client/deployment
Offuscamento nativo	no	non è una proprietà automatica del protocollo, ma l’ecosistema offre più strategie/wrapper
Reti che bloccano UDP	limite importante	possibilità TCP può aiutare
Gestione utenti	fuori scope nel protocollo	ecosistema più orientato a deployment complessi
Prestazioni	overhead generalmente contenuto	dipendono molto dall’implementazione; DCO cambia il confronto moderno

Prestazioni ed efficienza: perché WireGuard parte avvantaggiato, ma non sempre

Molti confronti online presentano ancora benchmark in cui WireGuard viene messo contro una vecchia configurazione OpenVPN interamente userspace e da quei numeri ricavano una regola universale.

Nel 2026 è un confronto troppo semplice.

WireGuard rimane progettato attorno a un data path molto snello e, su Linux, beneficia di una stretta integrazione con il networking del kernel. Questa architettura può produrre ottime prestazioni e basso overhead.

OpenVPN però continua a evolvere. La documentazione corrente su Data Channel Offload (DCO) di OpenVPN descrive un’architettura che sposta parte dell’elaborazione del canale dati nel sistema operativo, riducendo passaggi fra kernel space e user space e migliorando l’efficienza nelle configurazioni compatibili.

Questo non significa che WireGuard abbia perso il vantaggio prestazionale. Significa una cosa più utile: non userei un moltiplicatore fisso tipo “WireGuard è sempre 3× più veloce” come criterio editoriale o tecnico.

Le prestazioni reali dipendono da hardware, sistema operativo, implementazione, cifratura, MTU, rete, latenza, server e presenza o meno di accelerazioni come DCO.

UDP, TCP, configurabilità e reti restrittive

Qui la differenza è più netta.

WireGuard è UDP-only.

OpenVPN può funzionare sia su UDP sia su TCP e il suo ecosistema include modalità adatte a proxy e reti più restrittive.

Per una VPN personale su una rete domestica o mobile che lascia passare UDP, probabilmente questa flessibilità aggiuntiva non ti interessa.

Per un portatile che deve collegarsi da hotel, reti corporate, campus o ambienti filtrati, può diventare molto più importante della differenza teorica di throughput.

Sicurezza: perché “più sicuro” è una risposta troppo semplice

Non sceglierei WireGuard perché qualcuno dice che “OpenVPN è vecchio”, né sceglierei OpenVPN soltanto perché ha una storia più lunga.

WireGuard offre primitive moderne, un design compatto e una superficie intenzionalmente ridotta.

OpenVPN offre un ecosistema più maturo e configurabile, con vent’anni di deployment alle spalle e meccanismi di autenticazione e gestione che possono essere utili in installazioni complesse.

La domanda di sicurezza reale dovrebbe quindi essere:

quale architettura riduce meglio il rischio nel mio scenario e quale sono in grado di amministrare correttamente?

Una VPN personale, un homelab con tre peer e un accesso remoto enterprise con centinaia di utenti non hanno lo stesso threat model.

WireGuard o OpenVPN: decisione per scenario

Sceglierei WireGuard come prima opzione quando:

• vuoi un tunnel personale o self-hosted semplice;
• utilizzi reti che consentono normalmente UDP;
• vuoi una configurazione relativamente compatta;
• passi spesso da Wi-Fi a rete mobile;
• lavori su router o dispositivi con risorse limitate;
• non hai bisogno che il protocollo gestisca direttamente account e policy complesse.

Sceglierei o manterrei OpenVPN quando:

• il collegamento deve funzionare anche dove UDP viene bloccato;
• hai bisogno del fallback TCP;
• devi attraversare proxy aziendali compatibili;
• la tua infrastruttura dipende già da certificati, sistemi di autenticazione o workflow OpenVPN consolidati;
• una maggiore flessibilità operativa vale più della semplicità.

In altre parole, WireGuard è un ottimo default per molti tunnel moderni, non un sostituto universale di qualsiasi deployment OpenVPN.

Come si configura WireGuard: capire i parametri prima dei comandi

Prima di copiare un file .conf, conviene capire chi gestisce ogni parametro.

Esiste infatti una distinzione che molte guide saltano: alcune direttive appartengono alla configurazione WireGuard gestita da wg, mentre altre sono comodità aggiunte da strumenti come wg-quick.

Questo spiega perché lo stesso file può contenere impostazioni che non descrivono direttamente il protocollo crittografico.

La sezione [Interface]: chiave privata, indirizzi e impostazioni locali

La sezione [Interface] descrive il lato locale del tunnel.

PrivateKey identifica la chiave privata dell’interfaccia WireGuard. Deve essere trattata come un segreto: chi la possiede può impersonare quel peer finché la configurazione corrispondente rimane valida.

ListenPort indica, quando configurata, la porta UDP sulla quale l’interfaccia ascolta.

Campi come Address e DNS, che incontri spesso nei file utilizzati con wg-quick, meritano invece una precisazione: sono gestiti da wg-quick per configurare indirizzi e DNS del sistema, non sono parametri crittografici del protocollo WireGuard in sé.

È un dettaglio utile quando passi da un’applicazione a un altro sistema di networking: stesso protocollo non significa necessariamente stessa sintassi di orchestrazione dell’interfaccia.

La sezione [Peer]: PublicKey, Endpoint e AllowedIPs

Ogni blocco [Peer] descrive un interlocutore autorizzato.

PublicKey identifica crittograficamente quel peer.

Endpoint indica normalmente l’indirizzo e la porta UDP iniziali a cui inviare i pacchetti. Non è però un’identità permanente: WireGuard può aggiornarlo in base all’origine degli ultimi pacchetti correttamente autenticati.

AllowedIPs mette invece in relazione l’identità del peer con gli indirizzi trasportabili nel tunnel. Il significato dei parametri core è documentato nella pagina di manuale di wg.

Per questo una configurazione non va letta soltanto così:

“questa è la lista delle reti da raggiungere”.

È più corretto chiedersi:

1. quali destinazioni fanno selezionare questo peer in uscita?
2. quali indirizzi interni sono accettabili quando i pacchetti arrivano da questo peer?
3. quale tool creerà realmente le route nel sistema operativo?

Se queste tre risposte non coincidono con ciò che intendevi ottenere, il tunnel può risultare “connesso” e continuare a instradare male il traffico.

PersistentKeepalive, NAT e quando serve davvero

PersistentKeepalive non serve a rendere WireGuard “più stabile” in modo generico.

Serve soprattutto a mantenere vivo lo stato di NAT o di un firewall stateful quando un peer che si trova dietro quel dispositivo deve poter ricevere traffico anche dopo un periodo di inattività.

Il valore comunemente indicato nella guida Quick Start ufficiale di WireGuard è 25 secondi, ma WireGuard lo lascia disabilitato di default perché la maggioranza delle configurazioni non ne ha bisogno.

Quindi:

• peer sempre raggiungibile e traffico normale → spesso non serve;
• peer dietro NAT che deve ricevere traffico dopo periodi di silenzio → può essere utile;
• attivarlo ovunque “per sicurezza” → aggiunge traffico senza risolvere necessariamente alcun problema.

È un buon esempio della filosofia WireGuard: poche impostazioni, ma ognuna ha un significato preciso.

Dove si può usare WireGuard

WireGuard non è più una tecnologia confinata a Linux.

La documentazione ufficiale di installazione di WireGuard mantiene supporto e istruzioni per Windows, macOS, Android, iOS, numerose distribuzioni Linux, OpenWrt, BSD e altri ambienti.

Questo amplia parecchio gli scenari possibili: puoi usarlo come client di un provider, per entrare nella rete di casa, per collegare due reti, su un router oppure come componente di un’infrastruttura più ampia.

Windows, macOS, Linux, Android e iOS

Per l’uso quotidiano, le differenze fra sistemi operativi riguardano soprattutto implementazione e integrazione, non il protocollo crittografico.

Su Windows e piattaforme Apple esistono client dedicati; su Linux il supporto è profondamente integrato nell’ecosistema networking; Android e iOS dispongono di app WireGuard ufficiali.

Il progetto elenca inoltre supporto per diversi sistemi server e router.

Per un utente normale questo significa che non sceglierei più WireGuard in base alla domanda “esiste sul mio sistema operativo moderno?”. Controllerei piuttosto:

• come viene gestita la configurazione;
• se il dispositivo può importare profili;
• come vengono trattati DNS e routing;
• se serve split tunneling;
• quali funzioni il client aggiunge sopra il protocollo.

Router e VPN self-hosted

WireGuard è particolarmente interessante quando vuoi costruire un accesso remoto alla tua rete o collegare due reti.

Router moderni e firmware come OpenWrt possono supportarlo direttamente.

Qui però entra in gioco un problema che WireGuard non può risolvere: la raggiungibilità dell’endpoint.

Se ospiti il server a casa e il tuo indirizzo pubblico cambia, un servizio DynDNS o DDNS può mantenere stabile l’hostname utilizzato dai client.

Se sei dietro CGNAT, invece, aggiornare perfettamente il DNS non crea da solo una connessione IPv4 in ingresso. Dovrai risolvere prima la raggiungibilità, usare IPv6 dove appropriato oppure adottare un’architettura che stabilisca le connessioni in modo differente.

WireGuard risolve il tunnel. Non risolve automaticamente DNS, NAT, CGNAT e firewall.

Provider VPN: WireGuard standard e implementazioni derivate

Un servizio commerciale può usare WireGuard in modi diversi.

Alcuni permettono di scaricare normali file di configurazione compatibili con client WireGuard standard. Proton VPN, per esempio, documenta la possibilità di scaricare configurazioni WireGuard standard e distingue le funzioni aggiunte dalla propria app dalle specifiche aperte del protocollo.

Altri provider possono aggiungere meccanismi proprietari sopra una base WireGuard.

Per questo, quando confronti due servizi, controllerei separatamente:

protocollo utilizzato → implementazione → infrastruttura → privacy policy → funzioni client.

Dire soltanto “entrambi hanno WireGuard” non significa che offrano la stessa esperienza né lo stesso modello di privacy.

Quando conviene usare WireGuard e quando scegliere un’alternativa

Il vantaggio più interessante di WireGuard emerge quando il suo perimetro coincide con il problema che devi risolvere.

Se cerchi un tunnel IP moderno, relativamente semplice da configurare e senza necessità di trasporto TCP, è spesso una scelta molto razionale.

Se invece pretendi che il protocollo risolva autenticazione aziendale, offuscamento, proxy traversal e ogni tipo di rete ostile, stai chiedendo a WireGuard cose che il progetto ha deliberatamente lasciato fuori scope.

Reti domestiche, mobile e accesso remoto

Per collegare smartphone, notebook e dispositivi personali a una rete controllata, WireGuard ha caratteristiche particolarmente adatte:

• poche informazioni essenziali per peer;
• roaming fra endpoint;
• basso overhead;
• disponibilità multipiattaforma;
• possibilità di definire con precisione le reti raggiungibili tramite AllowedIPs.

È probabilmente uno dei casi in cui sceglierei WireGuard per primo, salvo vincoli specifici dell’infrastruttura.

Server e tunnel self-hosted

Per collegamenti server-to-server, site-to-site e homelab, il modello a peer è altrettanto efficace.

La semplicità diventa però responsabilità operativa quando cresce il numero degli endpoint.

Con pochi peer puoi gestire facilmente chiavi e indirizzi.

Con centinaia o migliaia di dispositivi hai bisogno di processi affidabili per:

• provisioning;
• revoca;
• inventory;
• assegnazione degli indirizzi;
• rotazione delle chiavi;
• controllo degli accessi;
• distribuzione delle configurazioni.

A quel punto la domanda non è più soltanto “WireGuard o OpenVPN?”. Diventa anche quale control plane userò sopra il protocollo?

Reti restrittive, offuscamento e casi in cui OpenVPN conserva un vantaggio

Il caso più chiaro in cui non sceglierei WireGuard come unica possibilità è una connessione che deve funzionare attraverso reti imprevedibili o fortemente filtrate.

WireGuard non dispone di TCP nativo e non considera l’offuscamento parte del proprio protocollo.

OpenVPN può invece offrire un percorso TCP e un ecosistema più maturo per alcuni scenari di proxy, firewall traversal e wrapper di offuscamento.

Non significa che OpenVPN “sia migliore”.

Significa che la disponibilità della connessione viene prima del benchmark.

Un protocollo teoricamente più efficiente vale poco se la rete su cui ti trovi non gli consente di stabilire il tunnel.

Conclusione

WireGuard è riuscito a cambiare il modo in cui si pensa ai protocolli VPN non aggiungendo funzioni, ma eliminandone molte dal livello più basso.

Peer identificati da chiavi, cryptokey routing, un trasporto UDP, primitive crittografiche definite e una superficie di configurazione relativamente piccola producono un sistema facile da comprendere rispetto a stack molto più estesi.

Ma semplice non significa completo.

WireGuard non gestisce da solo utenti, provisioning, policy commerciali, offuscamento, TCP fallback o privacy del provider. Queste responsabilità devono essere risolte altrove.

Per una rete domestica, un dispositivo mobile, un homelab o molti tunnel self-hosted sceglierei normalmente WireGuard come prima opzione da valutare. Per ambienti nei quali UDP può essere bloccato, servono proxy, autenticazione enterprise complessa o compatibilità con workflow esistenti, OpenVPN può ancora avere più senso.

La domanda utile, quindi, non è “qual è il protocollo migliore in assoluto?”.

È: quali responsabilità voglio affidare al protocollo e quali sono disposto a gestire negli strati che gli stanno intorno?