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.

Cosa offre realmente il control plane

WireGuard senza componenti aggiuntivi non dispone di discovery. Ogni peer è un blocco di testo da scrivere manualmente: una chiave pubblica, una riga AllowedIPs e una riga Endpoint se il peer è raggiungibile. Aggiungere una macchina a una rete di dieci nodi richiede la modifica di dieci file di configurazione, perché ogni lato deve conoscere la chiave dell'altro. Per questo quasi tutte le configurazioni WireGuard self-hosted usano una topologia 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 è autorizzato a 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 ciascun nodo e quali nodi possono comunicare tra loro.

Da questo derivano tre vantaggi concreti.

Attraversamento del NAT. Due laptop dietro due router domestici non dispongono di un percorso diretto tramite IP pubblico. Tailscale usa STUN (session traversal utilities for NAT) per scoprire l'indirizzo e la porta esterni di ciascun lato. Poi entrambi i lati inviano pacchetti nello stesso momento, così ogni router rileva prima un flusso in uscita e accetta la risposta. Se questo meccanismo non funziona, 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 possiede le chiavi. Esegui tailscale status: ogni riga del peer indica direct oppure relay. Esegui tailscale netcheck per verificare qual è il relay più vicino e se la rete consente il traffico UDP.

Rotazione delle chiavi con scadenza. Le chiavi WireGuard non scadono. Una chiave emessa tre anni fa continua a funzionare indefinitamente, a meno che il blocco del peer non venga eliminato manualmente. Tailscale fa invece scadere le chiavi dei nodi e, a ottobre 2026, il periodo di scadenza predefinito per un nuovo tailnet è di 180 giorni. Una macchina che non esegue una nuova autenticazione smette di connettersi. Puoi disabilitare la scadenza per singolo dispositivo, ad esempio per un server o per un subnet router sul quale non sarà presente nessuno per eseguire l'accesso.

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 tramite un intervallo di indirizzi IP. Tailscale usa un file di policy separato, nel quale le regole fanno riferimento a utenti, gruppi e tag. Una regola può stabilire che tag:laptop può raggiungere tag:db sulla porta 5432 e nient'altro. La regola resta valida anche se una macchina riceve un nuovo indirizzo.

Quanto 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 la policy. Con Tailscale in hosting, questo server appartiene a un'azienda esterna al tuo controllo. L'azienda non può leggere i tuoi pacchetti, perché le chiavi private WireGuard restano sui tuoi computer. Tuttavia, può vedere la struttura della tua rete e la tua possibilità di connetterti dipende dalla disponibilità del suo servizio e dal fatto che il tuo account sia in regola. Quanto questo aspetto sia importante dipende da ciò che un server di coordinamento compromesso o un account con identità sottratta potrebbe effettivamente fare con le informazioni che contiene. 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 computer. Devi quindi mantenerlo aggiornato con le patch su ogni computer. WireGuard nativo su Ubuntu 24.04 è un modulo del kernel incluso nella distribuzione e aggiornato insieme al kernel.

Il terzo costo è la fatturazione. A ottobre 2026 il piano Personal è gratuito con dispositivi utente 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 di questa soglia dipende soprattutto dal numero di utenti, non da quello dei dispositivi, con un'eccezione: i server e gli altri dispositivi contrassegnati hanno una propria quota. Ogni piano include 50 risorse contrassegnate e, a ottobre 2026, la pagina dei prezzi indica un costo di $1 al mese per ciascuna risorsa aggiuntiva. Prima di invitare il settimo utente o contrassegnare il cinquantunesimo server, vale la pena leggere cosa copre effettivamente il piano gratuito.

Quando WireGuard puro è la scelta corretta

Scegli WireGuard puro 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 consenta a questi dispositivi di raggiungersi tra loro. La configurazione occupa una sola schermata, non c’è alcun daemon da aggiornare, nessun account da recuperare e nessun servizio esterno tra te e il server.

È inoltre la scelta corretta quando vuoi comprendere il livello su cui si basa tutto il resto. Configurare in autonomia una VPN WireGuard su un VPS illustra la generazione delle chiavi, wg0.conf, l’IP forwarding, il NAT e i problemi di handshake. Le chiavi e l’handshake continuano a operare sotto ogni tailnet, mentre l’IP forwarding torna in gioco quando un nodo tailnet agisce da subnet router o da exit node. Se stai ancora valutando l’opzione precedente, WireGuard vs OpenVPN 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 puro smette di essere pratico quando ogni dispositivo deve raggiungere tutti gli altri. Una mesh completa di N nodi richiede N volte N meno un blocco peer. Con sei dispositivi si devono mantenere manualmente sincronizzati trenta blocchi; 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 a reti Wi-Fi di hotel, telefoni con connessione dati mobile e server domestici dietro un router che non controlli sono esattamente i casi che WireGuard puro 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, disponibile nell'installer ufficiale:

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

tailscale up stampa un URL. Aprilo, esegui l'accesso e la macchina entra nella rete. Non devi copiare alcuna chiave né aprire porte 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 sulla quale 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. Questo comportamento è 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 per impostazione predefinita le route pubblicizzate. Di conseguenza, una route che risulta approvata sul server non produce ancora alcun effetto su un portatile Linux finché non imposti questa opzione. Se questo è lo scenario che ti serve, eseguire un subnet router su un VPS illustra il passaggio di approvazione e le impostazioni di forwarding nell'ordine corretto, evitando una route parzialmente funzionante.

Un exit node invia attraverso una macchina il normale traffico Internet del client. In altre parole, inoltra tutto il traffico che non è già diretto a un altro dispositivo della tailnet o a una subnet autorizzata. Questo è il comportamento di full tunnel che generalmente si intende con "VPN". Su Linux devi impostare gli stessi parametri di IP forwarding mostrati sopra prima di pubblicizzarlo:

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 errato. Se devi raggiungere un solo servizio web invece di un'intera rete, pubblicare un servizio e usare il funnel espone HTTPS davanti a una singola porta locale, limitandolo alla 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 considerato troppo tardi. Headscale non include la rete globale di relay di Tailscale. Quando due peer non riescono a connettersi direttamente, è necessario abilitare il relay integrato sul proprio 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 della differenza. Se non vuoi assemblare autonomamente questo componente, il self-hosting di NetBird è l’alternativa per mantenere internamente il control plane, perché la procedura rapida avvia insieme i servizi di gestione, segnalazione e relay su un unico VPS. NetBird non è però un server Tailscale sostitutivo immediato come Headscale: distribuisce client propri e utilizza un proprio modello di policy. Prima di preferirlo a Headscale, leggi come differiscono NetBird e Tailscale nelle regole di accesso e nei relay.

Come decidere in un'unica valutazione

Chiedete quante macchine devono raggiungersi tra loro. Se la risposta è che comunicano tutte soltanto 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 piano di controllo, 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 postazione, eseguite Headscale e accettate di dover gestire il server di controllo. Se il costo è il fattore decisivo, fate i calcoli prima di impegnarvi nella migrazione, perché quanto paga realmente un team delle vostre dimensioni dipende soprattutto da quante persone dispongono di account, non da quante macchine eseguite, finché i server con tag non superano i 50 inclusi in ogni piano; questi due numeri raramente coincidono.

Potete cambiare scelta con costi contenuti. Poiché il piano dati 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 di registrare nuovamente ogni nodo su un server di accesso 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 è solo WireGuard con passaggi aggiuntivi?

Tailscale utilizza il protocollo WireGuard per il data path, quindi la crittografia e il tunnel sono identici. Ciò che aggiunge è il coordinamento: scambio di chiavi, assegnazione degli indirizzi, NAT traversal tramite STUN e relay DERP, scadenza delle chiavi e un file di policy che utilizza i nomi degli utenti invece degli intervalli IP. Queste sono le componenti che WireGuard standard lascia alla gestione dell'utente e sono le parti che diventano complesse quando le macchine si spostano tra reti diverse.

Il mio traffico passa attraverso i server di Tailscale?

Normalmente no. I peer si connettono direttamente tra loro una volta che il server di coordinamento li ha messi in contatto, e tailscale status mostra direct su quelle righe dei peer. Quando non è possibile stabilire un percorso diretto, il traffico ripiega su un relay DERP e la riga riporta relay. Anche in quel caso, il relay trasporta pacchetti crittografati e non possiede le tue chiavi private WireGuard, quindi non può leggerne il contenuto. Esegui tailscale netcheck per verificare se la tua rete sta bloccando l'UDP necessario per le connessioni dirette.

Posso usare Headscale con le app ufficiali di Tailscale?

Sì. Headscale utilizza lo stesso protocollo di controllo, quindi i client ufficiali si collegano con sudo tailscale up --login-server https://headscale.example.com. Anche le app desktop e mobile possono essere indirizzate verso un server di login personalizzato, sebbene l'impostazione si trovi in posizioni diverse su ogni piattaforma e le app mobile siano quelle che più probabilmente richiedono una versione specifica. Testa un singolo telefono prima di migrare un'intera rete.

Devo ancora aprire porte per Tailscale o Headscale?

Un client Tailscale non necessita di porte in ingresso, poiché effettua una connessione in uscita verso il server di coordinamento e la mantiene aperta. Un server Headscale self-hosted richiede porte in ingresso: la 443 per il protocollo di controllo, la 80 se utilizzi la sfida per certificati HTTP-01 e la 3478/udp solo quando abiliti il relay integrato. WireGuard standard richiede che la sua porta di ascolto UDP, solitamente la 51820, sia aperta sul server e su qualsiasi firewall di rete separato gestito dal tuo provider.

Quale dei tre è il più veloce?

Il throughput è identico, poiché tutti e tre spostano i pacchetti tramite WireGuard. La differenza emerge nella configurazione della connessione e nella qualità del percorso. WireGuard standard con un Endpoint corretto si connette direttamente ogni volta. Tailscale e Headscale si connettono direttamente nella maggior parte dei casi e ripiegano su un relay quando la rete blocca l'hole punching; un percorso tramite relay aggiunge latenza. Misura il tuo percorso con tailscale ping <node>, che segnala se la rotta è diretta o tramite relay, oppure con iperf3 attraverso il tunnel. Se quel valore risulta molto inferiore alla velocità della tua linea su un percorso diretto, la scelta tra i tre non è la causa del problema, e la causa abituale è una discrepanza nel path MTU che si comporta allo stesso modo con o senza un control plane.