WireGuard, Tailscale o Headscale: quale scegliere

WireGuard vs Tailscale: la risposta breve

WireGuard vs Tailscale non è una scelta tra due protocolli, perché Tailscale è WireGuard. Tailscale usa la stessa crittografia e lo stesso tunnel, quindi aggiunge un piano di controllo: un server di coordinamento che scambia le chiavi pubbliche, assegna gli indirizzi, attraversa i NAT (network address translation) e applica una policy di accesso. La scelta riguarda quanta parte di questo coordinamento si desidera gestire autonomamente.

Le risposte corrette sono tre. Usare WireGuard senza componenti aggiuntivi quando si dispone di un server e di pochi client che si connettono tutti a esso. Usare Tailscale quando si vuole che ogni macchina possa raggiungere tutte le altre senza dover gestire un file di configurazione. Usare Headscale quando si vuole quella rete mesh, ma non si vuole che un soggetto terzo conservi l'elenco dei nodi.

Cosa offre concretamente il control plane

WireGuard senza componenti aggiuntivi non dispone di meccanismi di individuazione. Ogni peer è un blocco di testo da scrivere manualmente: una chiave pubblica, una riga AllowedIPs e una riga Endpoint se quel peer è raggiungibile. Aggiungere una macchina a una rete di dieci macchine richiede la modifica di dieci file di configurazione, perché ogni lato deve conoscere la chiave dell'altro. Per questo quasi tutte le configurazioni WireGuard autogestite usano una topologia hub-and-spoke: un server con un indirizzo IP pubblico e client che comunicano esclusivamente con quel server.

Un control plane elimina la modifica manuale dei file. Ogni nodo si registra una volta, riceve un indirizzo dall'intervallo 100.64.0.0/10 CGNAT (carrier grade NAT) e riceve le chiavi pubbliche dei nodi che può raggiungere. Il tunnel resta una connessione WireGuard diretta tra due peer e il traffico non passa mai attraverso il server di coordinamento. Il server trasporta solo metadati: quali nodi esistono, quale chiave appartiene a ciascuno e quali nodi possono comunicare tra loro.

Da questo derivano tre vantaggi concreti.

Attraversamento del NAT. Due laptop dietro due router domestici diversi non hanno un indirizzo IP pubblico in comune. Tailscale usa STUN (session traversal utilities for NAT) per individuare l'indirizzo e la porta esterni di ciascun lato. Poi entrambi i lati inviano pacchetti nello stesso momento, in modo che ogni router rilevi prima un flusso in uscita e accetti la risposta. Se questa procedura non riesce, il traffico passa a un relay DERP, cioè un relay crittografato gestito da Tailscale. I dati restano crittografati end-to-end attraverso il relay, perché il relay non possiede le chiavi. Eseguire tailscale status mostra, per ogni peer, direct oppure relay. Eseguire tailscale netcheck indica quale relay è più vicino e se la rete consente il traffico UDP.

Rotazione delle chiavi con scadenza. Le chiavi WireGuard non scadono mai. Una chiave emessa tre anni fa continua a funzionare indefinitamente, a meno che non si elimini manualmente il blocco del peer. Tailscale fa invece scadere le chiavi dei nodi. A luglio 2026, il periodo di scadenza predefinito per un nuovo tailnet è di 180 giorni. Una macchina che non esegue più la riautenticazione smette di connettersi. È possibile disattivare la scadenza per singolo dispositivo, ad esempio per un server o un subnet router al quale nessuno accederà per eseguire il login.

Policy invece del routing. In WireGuard senza componenti aggiuntivi, AllowedIPs è contemporaneamente la tabella di routing e l'elenco di controllo degli accessi. Di conseguenza, la regola "alice può raggiungere il database" deve essere espressa come un intervallo di indirizzi IP. Tailscale mantiene un file di policy separato, nel quale le regole identificano utenti, gruppi e tag. Una regola può stabilire che tag:laptop può raggiungere tag:db sulla porta 5432 e nessun'altra destinazione. La regola resta valida anche se una macchina riceve un nuovo indirizzo.

Cosa ti costa il control plane

Il server di coordinamento conosce la tua rete. Contiene la chiave pubblica di ogni nodo, il nome di ogni nodo, gli indirizzi assegnati e i criteri. Con Tailscale in hosting, questo server appartiene a un'azienda che non controlli. L'azienda non può leggere i tuoi pacchetti, perché le chiavi private WireGuard restano sulle tue macchine. Tuttavia, può vedere la struttura della tua rete. Inoltre, la tua capacità di connetterti dipende dal fatto che il suo servizio sia operativo e che il tuo account sia in regola.

Esiste un secondo costo, facile da trascurare. Tailscale è un daemon presente su ogni macchina. Devi quindi mantenere aggiornato il software su ogni macchina. WireGuard semplice su Ubuntu 24.04 è un modulo del kernel incluso nella distribuzione e aggiornato insieme al kernel.

Il terzo costo riguarda la fatturazione. A luglio 2026, il piano Personal è gratuito con dispositivi illimitati per un massimo di 6 utenti, Standard costa $8 per utente al mese e Premium costa $18 per utente al mese. Un nucleo familiare resta gratuito. Un team di dieci persone no.

Quando WireGuard semplice è la scelta giusta

Scegli WireGuard semplice quando la topologia è realmente a hub e spoke. Un VPS con un IP pubblico, tre o quattro dispositivi che vi si connettono e nessun requisito che consenta a questi dispositivi di raggiungersi tra loro. La configurazione occupa una sola schermata, non c'è alcun demone da aggiornare, nessun account da perdere e nessun servizio esterno tra te e il server.

È anche la scelta giusta quando vuoi comprendere il livello su cui è costruito tutto il resto. Gestire in proprio una VPN WireGuard su un VPS illustra la generazione delle chiavi, wg0.conf, l'inoltro IP, il NAT e i problemi di handshake; tutti questi meccanismi continuano a funzionare sotto una tailnet. Se stai ancora valutando l'opzione precedente, WireGuard rispetto a OpenVPN descrive i quattro casi in cui OpenVPN conserva un vantaggio.

L'installazione è breve:

sudo apt update && sudo apt install -y wireguard
sudo modprobe wireguard && echo ok

WireGuard semplice smette di essere pratico nel momento in cui ogni dispositivo deve raggiungere tutti gli altri. Una mesh completa di N nodi richiede N volte N meno uno blocchi peer. Con sei dispositivi, sono trenta blocchi da mantenere sincronizzati manualmente; una voce AllowedIPs duplicata sottrae silenziosamente il traffico al peer che la aveva per primo, senza stampare alcun errore.

Quando Tailscale è la scelta giusta

Scegli Tailscale quando le macchine cambiano rete. Laptop collegati alle reti degli hotel, un telefono su rete dati mobile, un server domestico dietro un router che non controlli. Sono esattamente i casi che WireGuard semplice gestisce male, perché nessuno dei due lati ha un endpoint pubblico stabile da inserire in Endpoint.

L'installazione del client richiede un solo comando, disponibile nell'installer ufficiale:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
tailscale status

tailscale up stampa un URL. Aprilo, accedi e la macchina entra nella rete. Non devi copiare alcuna chiave né aprire alcuna porta in ingresso, perché il demone stabilisce una connessione in uscita al server di coordinamento e la mantiene aperta. Per questo un nodo Tailscale funziona anche su una rete in cui non controlli alcun firewall.

Dopo l'installazione, due impostazioni svolgono gran parte del lavoro utile. Un router di subnet pubblicizza un'intera LAN nella rete, così non devi installare il client su ogni dispositivo:

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf
sudo tailscale set --advertise-routes=192.0.2.0/24

La route resta inattiva finché non la approvi nella console di amministrazione. È una scelta deliberata: un nodo non può inserire autonomamente una route nella tua rete. I client Linux richiedono anche sudo tailscale set --accept-routes, perché Linux non accetta le route pubblicizzate per impostazione predefinita. Di conseguenza, una route che risulta approvata sul lato server non produce ancora alcun effetto su un laptop Linux finché non imposti questa opzione.

Un exit node invia tutto il traffico di un client attraverso una macchina. Questo corrisponde al comportamento full tunnel che di solito si intende con "VPN":

sudo tailscale set --advertise-exit-node

Quando Headscale è la scelta giusta

Headscale è un'implementazione open source del server di coordinamento e viene eseguito su un VPS di tua proprietà. I client ufficiali Tailscale si collegano a questo server anziché al servizio ospitato:

sudo tailscale up --login-server https://headscale.example.com

Il percorso dei dati non cambia. Usa ancora WireGuard e, quando la rete lo consente, il traffico passa ancora direttamente tra i peer. Cambia invece il punto in cui sono archiviati l'elenco dei nodi, le chiavi e i criteri: si trovano in un file SQLite su un disco di tua proprietà. Nessuno dall'esterno può vedere la struttura della tua rete, disabilitare il tuo account o fatturarti in base al numero di utenti.

Il compromesso richiede lavoro operativo. Ora gestisci un servizio HTTPS pubblico, quindi ti servono un nome DNS, un certificato e un reverse proxy che inoltri correttamente gli upgrade WebSocket. La disponibilità del servizio è a tuo carico. Se il server di coordinamento è inattivo, i nuovi nodi non possono registrarsi e quelli esistenti non possono ricevere informazioni sulle modifiche. Headscale è inoltre ancora al di sotto della versione 1.0 e i suoi aggiornamenti minori hanno introdotto modifiche incompatibili. Leggi quindi il changelog prima di ogni aggiornamento. Eseguire Headscale come server di controllo Tailscale personale illustra l'installazione, config.yaml, le chiavi preauth e le porte da aprire.

Un aspetto problematico viene spesso scoperto tardi. Headscale non include la rete globale di relay di Tailscale. Quando due peer non possono connettersi direttamente, devi abilitare il relay integrato sul tuo server oppure indicare un altro relay nella configurazione. In entrambi i casi, il relay è un singolo host in una singola regione, non una flotta distribuita in tutto il mondo. I peer che si trovano dall'altra parte del pianeta risentono di questa differenza.

Come decidere in un solo passaggio

Chiedete quante macchine devono comunicare tra loro. Se la risposta è che devono tutte comunicare solo con il server, WireGuard senza componenti aggiuntivi richiede meno software per ottenere lo stesso risultato.

Chiedete se le macchine hanno indirizzi pubblici stabili. Se la maggior parte si trova dietro NAT che non controllate, vi serve un control plane, perché il problema più complesso è il hole punching e non vale la pena ricostruirlo.

Chiedete chi può conoscere la struttura della vostra rete. Se la risposta esclude le aziende esterne, oppure il numero di utenti rende onerosa la fatturazione per utente, eseguite Headscale e accettate di dover gestire il control server.

Potete cambiare scelta con costi contenuti. Poiché il data plane usa lo stesso protocollo in tutte e tre le soluzioni, passare da WireGuard senza componenti aggiuntivi a una mesh coordinata richiede l'installazione del client, non una riprogettazione. Passare da Tailscale a Headscale richiede invece una nuova registrazione di ogni nodo su un login server diverso.

Cosa non offre nessuna delle tre opzioni

Nessuna delle tre opzioni è un firewall. Un tunnel determina quali pacchetti vengono trasportati, non quali servizi sono in ascolto. Un server raggiungibile tramite il tunnel resta raggiungibile da Internet su ogni porta lasciata aperta. Mantieni quindi attive le regole del firewall UFW sul VPS.

Il file delle policy di Tailscale limita ciò che gli altri nodi possono raggiungere. Non influisce sull'interfaccia pubblica.

Nessuna delle tre opzioni fornisce l'autenticazione per singolo servizio. Nessuna registra le attività eseguite da un utente dopo la connessione. Considerale tutte come sistemi di trasporto e configura i controlli di accesso nell'applicazione.

FAQ

Tailscale è semplicemente WireGuard con passaggi aggiuntivi?

Tailscale usa il protocollo WireGuard per il percorso dati, quindi la cifratura e il tunnel sono gli stessi. Aggiunge però il coordinamento: scambio delle chiavi, assegnazione degli indirizzi, attraversamento del NAT con relay STUN e DERP, scadenza delle chiavi e un file delle policy che identifica gli utenti invece degli intervalli IP. Questi aspetti, con WireGuard semplice, restano a tuo carico. Diventano complessi quando i computer passano da una rete all'altra.

Il mio traffico passa attraverso i server Tailscale?

Normalmente no. Dopo che il server di coordinamento li ha messi in contatto, i peer si connettono direttamente tra loro e tailscale status mostra direct nelle righe relative ai peer. Se non è possibile stabilire un percorso diretto, il traffico passa a un relay DERP e la riga contiene relay. Anche in questo caso, il relay trasporta pacchetti cifrati e non dispone delle chiavi private WireGuard, quindi non può leggerne il contenuto. Esegui tailscale netcheck per verificare se la rete blocca il traffico UDP necessario alle connessioni dirette.

Posso usare Headscale con le app Tailscale ufficiali?

Sì. Headscale usa lo stesso protocollo di controllo, quindi i client ufficiali si connettono con sudo tailscale up --login-server https://headscale.example.com. Le app per desktop e dispositivi mobili possono usare anche un server di accesso personalizzato, ma l'impostazione si trova in una posizione diversa su ogni piattaforma. Le app mobili sono inoltre quelle che più probabilmente richiedono una versione specifica. Prova prima con un telefono, quindi esegui la migrazione dell'intera rete.

Devo comunque aprire porte per Tailscale o Headscale?

Un client Tailscale non richiede una porta in ingresso, perché stabilisce una connessione in uscita verso il server di coordinamento e la mantiene aperta. Un server Headscale self-hosted richiede invece porte in ingresso: 443 per il protocollo di controllo, 80 se usi una verifica del certificato HTTP-01 e solo 3478/udp quando abiliti il relay integrato. WireGuard semplice richiede che la porta UDP in ascolto, di solito 51820, sia aperta sul server e su eventuali firewall di rete separati gestiti dal provider.

Quale dei tre è più veloce?

Il throughput è lo stesso, perché tutti e tre trasportano i pacchetti con WireGuard. La differenza si vede durante la configurazione della connessione e nella qualità del percorso. WireGuard semplice, con un Endpoint corretto, si connette direttamente ogni volta. Tailscale e Headscale si connettono direttamente nella maggior parte dei casi e usano un relay quando la rete blocca il hole punching; un percorso tramite relay aumenta la latenza. Misura il tuo percorso con tailscale ping <node>, che indica se la route è diretta o passa da un relay, oppure con iperf3 attraverso il tunnel.