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 control plane: 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 la quantità di questo coordinamento che si vuole gestire autonomamente.

Le risposte corrette sono tre. Usate WireGuard senza componenti aggiuntivi quando avete un server e pochi client che si connettono tutti a quel server. Usate Tailscale quando volete che ogni macchina possa raggiungere tutte le altre senza dover gestire un file di configurazione. Usate Headscale quando volete questa mesh, ma non volete che un fornitore esterno conservi l'elenco dei nodi.

Che cosa offre realmente il control plane

WireGuard senza componenti aggiuntivi non dispone di discovery. Ogni peer è un blocco di testo che si scrive manualmente: una chiave pubblica, una riga AllowedIPs e una riga Endpoint se quel peer è raggiungibile. Aggiungere una macchina a una rete di dieci macchine significa modificare dieci file di configurazione, perché ogni lato deve conoscere la chiave dell'altro. Per questo quasi tutte le configurazioni WireGuard self-hosted usano un'architettura hub-and-spoke: un server con un 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 dal server di coordinamento. Il server trasporta soltanto metadati: quali nodi esistono, quale chiave appartiene a ciascun nodo e quali nodi possono comunicare tra loro.

Da questo derivano tre vantaggi concreti.

Attraversamento del NAT. Due laptop dietro due router domestici diversi non dispongono di un percorso pubblico diretto tra loro. Tailscale usa STUN (session traversal utilities for NAT) per rilevare l'indirizzo e la porta esterni di ciascun lato, quindi entrambi i lati inviano pacchetti nello stesso momento. In questo modo ogni router rileva prima un flusso in uscita e accetta la risposta. Se questa procedura non riesce, il traffico passa a un relay DERP, cioè un relay cifrato gestito da Tailscale. I dati restano cifrati end-to-end anche attraverso il relay, perché il relay non dispone delle chiavi. Esegui tailscale status: ogni riga del peer riporta direct oppure relay. Esegui tailscale netcheck per vedere 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 e, a luglio 2026, il periodo di scadenza predefinito per un nuovo tailnet è di 180 giorni. Una macchina che non esegue nuovamente l'autenticazione 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 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 comporta 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, il server appartiene a un'azienda che non controlli. I suoi operatori non possono leggere i tuoi pacchetti, perché le chiavi private WireGuard restano sulle tue macchine. Tuttavia, possono vedere la struttura della tua rete e la tua capacità di connetterti dipende dalla disponibilità del loro servizio e dal buon mantenimento del tuo account. Il peso da attribuire a questi aspetti dipende da ciò che un server di coordinamento compromesso o un account con identità sottratta potrebbe effettivamente fare con le informazioni in suo possesso. Per questo vale la pena leggere per intero il modello di trust di Tailscale.

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

Il terzo costo riguarda la fatturazione. A luglio 2026 il piano Personal è gratuito e consente 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 nel piano gratuito. Un team di dieci persone no. Il superamento della soglia dipende dal numero di utenti, non da quello dei dispositivi. Prima di invitare il settimo utente, vale la pena leggere cosa copre effettivamente il piano gratuito.

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 si connettono a esso e nessun requisito che imponga a tali 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 capire il livello su cui si basa tutto il resto. Configurare in self-hosting una VPN WireGuard su un VPS illustra la generazione delle chiavi, wg0.conf, l'inoltro IP, il NAT e gli errori di handshake; tutti questi meccanismi continuano a funzionare sotto una tailnet. Se stai ancora valutando l'opzione precedente, WireGuard e OpenVPN a confronto descrive i quattro casi in cui OpenVPN mantiene un vantaggio.

L'installazione è breve:

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

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

Quando Tailscale è la scelta giusta

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

L'installazione del client richiede un solo comando dell'installer ufficiale:

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

tailscale up stampa un URL. Aprilo, effettua l'accesso e la macchina viene aggiunta alla rete. Non devi copiare alcuna chiave né aprire porte in ingresso, perché il daemon 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 subnet router 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 intenzionale: un nodo non può inserire autonomamente una route nella tua rete. I client Linux richiedono inoltre 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 alcun effetto su un portatile Linux finché non imposti anche questo parametro. Se questa è la configurazione che vuoi ottenere, eseguire un subnet router su un VPS descrive la procedura di approvazione e le impostazioni di forwarding nell'ordine che evita di lasciare una route parzialmente funzionante.

Un exit node invia tutto il traffico di un client attraverso una macchina, cioè il comportamento full tunnel che di solito si intende con "una VPN":

sudo tailscale set --advertise-exit-node

Quel flag è la parte più semplice. trasformare un VPS in un exit node descrive i passaggi successivi: approvare la route nella console di amministrazione e correggere il comportamento di DNS e IPv6, che altrimenti può fare uscire il traffico dal percorso sbagliato. Se vuoi raggiungere un singolo servizio web invece di un'intera rete, serve e funnel pubblicano HTTPS davanti a una sola porta locale, limitandolo al tailnet oppure rendendolo accessibile da Internet.

Quando Headscale è la scelta giusta

Headscale è un'implementazione open source del server di coordinamento ed è eseguito su un VPS di tua proprietà. I client Tailscale ufficiali si collegano a questo server invece che al servizio gestito:

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

Tutto ciò che riguarda il percorso dei dati resta invariato. Si usa ancora WireGuard e il traffico passa ancora direttamente tra i peer quando la rete lo consente. Cambia invece la posizione dell'elenco dei nodi, delle chiavi e dei criteri: questi dati risiedono in un file SQLite su un disco di tua proprietà. Nessun soggetto esterno può vedere la struttura della tua rete, disabilitare il tuo account o addebitarti un costo per utente.

Il compromesso richiede lavoro operativo. Ora gestisci un servizio HTTPS pubblico, quindi ti servono un nome DNS, un certificato e un reverse proxy configurato per inoltrare correttamente gli upgrade WebSocket. La disponibilità del servizio è una tua responsabilità. Se il server di coordinamento non è raggiungibile, i nuovi nodi non possono registrarsi e quelli esistenti non possono ricevere le modifiche. Headscale è inoltre ancora sotto la versione 1.0 e gli aggiornamenti minor hanno introdotto modifiche incompatibili, quindi consulta il changelog prima di ogni upgrade. Eseguire Headscale come server di controllo Tailscale personale descrive l'installazione, config.yaml, le chiavi preauth e le porte da aprire.

C'è un aspetto che spesso viene 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 indicarne un altro nella configurazione. In entrambi i casi, il relay è un singolo server in una singola regione, non una flotta distribuita in tutto il mondo. I peer situati dall'altra parte del pianeta risentono di questa differenza. Se preferisci non gestire autonomamente questo componente, eseguire NetBird in modalità self-hosted è l'altra opzione per mantenere il control plane nella tua infrastruttura, perché il quickstart avvia insieme i servizi di gestione, signal e relay su un unico VPS.

Come decidere in un'unica valutazione

Chiedete quante macchine devono raggiungersi tra loro. Se la risposta è che comunicano tutte soltanto con il server, WireGuard semplice 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 hole punching è la parte più complessa e non conviene ricostruirla.

Chiedete chi può conoscere la struttura della vostra rete. Se la risposta esclude aziende esterne, oppure il numero di utenti rende onerosa la fatturazione per singola utenza, eseguite Headscale e accettate di dover gestire il control server. Se il costo è il fattore decisivo, fate i calcoli prima di impegnarvi nella migrazione, perché quanto paga realmente un team delle vostre dimensioni dipende da quante persone dispongono di un account, non da quante macchine eseguite; e questi due numeri raramente coincidono.

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

Cosa non offre nessuna delle tre soluzioni

Nessuna delle tre soluzioni è un firewall. Un tunnel stabilisce quali pacchetti vengono trasportati, non quali servizi restano in ascolto. Un server raggiungibile tramite il tunnel resta raggiungibile da Internet su tutte le porte lasciate aperte. Per questo, lascia che le regole firewall UFW sul VPS continuino a svolgere il loro compito. Il file delle policy di Tailscale limita i nodi che possono raggiungere altre risorse, ma non modifica l'interfaccia pubblica.

Nessuna delle tre soluzioni fornisce autenticazione per singolo servizio né un audit trail delle operazioni 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 piano dati, quindi la crittografia 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. Sono gli aspetti che WireGuard semplice lascia a voi e che diventano complessi quando le macchine cambiano rete.

Il mio traffico passa attraverso i server Tailscale?

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

Posso usare Headscale con le applicazioni 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. È possibile configurare anche le applicazioni desktop e mobili per usare un server di login personalizzato, anche se l'impostazione si trova in una posizione diversa su ogni piattaforma e sono soprattutto le applicazioni mobili a richiedere una versione specifica. Testate un telefono prima di migrare un'intera rete.

Devo comunque aprire porte per Tailscale o Headscale?

Un client Tailscale non richiede porte in ingresso, perché avvia una connessione 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 usate una verifica del certificato HTTP-01 e solo 3478/udp quando abilitate il relay integrato. WireGuard semplice richiede che la porta UDP di ascolto, generalmente 51820, sia aperta sul server e su qualsiasi firewall di rete separato gestito dal provider.

Quale dei tre è più veloce?

Il throughput è lo stesso, perché tutti e tre trasferiscono i pacchetti tramite WireGuard. La differenza riguarda l'instaurazione della connessione e la 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 passano a un relay quando la rete blocca l'attraversamento NAT, mentre un percorso tramite relay aggiunge latenza. Misurate il vostro percorso con tailscale ping <node>, che indica se la route è diretta o passa da un relay, oppure con iperf3 attraverso il tunnel. Se il valore è molto inferiore alla velocità della vostra linea su un percorso diretto, il problema non dipende dalla scelta tra i tre strumenti: la causa abituale è un mismatch del percorso MTU, che si comporta nello stesso modo con o senza un piano di controllo.