Tailscale: cos'è e come funziona la VPN WireGuard

Che cos'è Tailscale?

Tailscale è una VPN che collega direttamente tra loro le macchine, invece di instradare tutto il traffico attraverso un unico gateway gestito da te. Ogni nodo esegue WireGuard, quindi i pacchetti viaggiano cifrati da un server all'altro e nessun elemento lungo il percorso può leggerli. Un server di coordinamento ospitato gestisce l'handshake tra i nodi. Memorizza e distribuisce le chiavi pubbliche e comunica a ogni nodo dove si trovano gli altri. Inoltre distribuisce le regole di accesso che hai definito.

Questa separazione costituisce l'intero design. Il piano dati è peer-to-peer e il traffico è cifrato tra i nodi. Il piano di controllo è un servizio che Tailscale gestisce per te. Tutte le questioni importanti su Tailscale, comprese quelle più delicate relative alla fiducia, derivano da questi due aspetti. Se hai già configurato una VPN WireGuard manualmente su un VPS, Tailscale offre lo stesso tunnel, occupandosi della distribuzione delle chiavi e dell'attraversamento dei firewall.

Come funziona Tailscale?

La rete privata dei nodi si chiama tailnet. Quando una macchina entra a farne parte, si verificano quattro eventi.

1. Il daemon tailscaled viene avviato, genera una coppia di chiavi WireGuard e mantiene il proprio stato in /var/lib/tailscale/tailscaled.state. La chiave privata resta su quella macchina. Tailscale lo afferma chiaramente: «la chiave privata non lascia mai, in nessun caso, il proprio nodo».
2. Il nodo accede al server di coordinamento e carica la propria chiave pubblica, oltre agli indirizzi dai quali ritiene di poter essere raggiunto. Tailscale descrive quel server come «un'area condivisa per depositare le chiavi pubbliche».
3. Il server di coordinamento restituisce una mappa di rete contenente la chiave pubblica, l'indirizzo della tailnet, il nome della macchina e gli endpoint candidati di ogni nodo che questa macchina è autorizzata a raggiungere.
4. Ogni coppia di nodi prova quindi a creare un tunnel WireGuard diretto tra i due nodi. Se il tentativo fallisce, i pacchetti vengono inoltrati tramite un relay.

Ogni nodo riceve un indirizzo stabile dall'intervallo 100.64.0.0/10, l'intervallo carrier-grade NAT compreso tra 100.64.0.0 e 100.127.255.255. Tailscale usa questo intervallo perché è riservato all'infrastruttura dei provider e quindi entra raramente in conflitto con gli indirizzi privati già utilizzati dai server. Su Linux, il tunnel compare come un'interfaccia denominata tailscale0.

L'implementazione WireGuard risiede nello spazio utente all'interno di tailscaled, non nel modulo del kernel. Per questo Tailscale si avvia in ambienti con virtualizzazione dei container in cui sudo modprobe wireguard fallisce con Operation not supported. Questo significa anche che, su una determinata macchina, il limite di throughput è inferiore a quello di WireGuard nel kernel. È uno dei compromessi descritti in Tailscale rispetto a WireGuard senza componenti aggiuntivi.

Due comandi mostrano la situazione corrente.

tailscale ip -4
tailscale status

tailscale status stampa una riga per ogni nodo. L'ultima colonna è quella rilevante.

100.101.102.103  web-1      you@  linux  -
100.101.102.104  db-1       you@  linux  active; direct 198.51.100.24:41641
100.101.102.105  ci-runner  you@  linux  active; relay "fra"

direct seguito da un indirizzo e da una porta indica che le due macchine hanno trovato un percorso tra loro e che il traffico è peer-to-peer. relay "fra" indica che il traffico passa attraverso un relay Tailscale a Francoforte. - indica che al momento non esiste una sessione attiva con quel nodo, una situazione normale.

Cosa può vedere e cosa non può vedere il server di coordinamento

Il server di coordinamento conserva chiavi pubbliche e metadati. Conosce i nomi delle macchine, l'utente o il tag proprietario di ogni nodo, l'indirizzo tailnet di ciascun nodo, gli indirizzi pubblici dai quali i nodi sono raggiungibili, l'ultima volta in cui ciascun nodo è stato online e il file delle policy scritto dall'utente. Dispone quindi di una mappa completa della flotta.

Non conserva alcuna chiave privata, quindi non può decrittografare il traffico tra due nodi. La crittografia è end-to-end tra i peer WireGuard e il server di coordinamento non è un peer.

Può però distribuire chiavi. Qualsiasi server di coordinamento, ospitato da un provider o gestito autonomamente, deve essere considerato affidabile nel comunicare ai nodi quali chiavi pubbliche appartengono alla tailnet. Questo è il punto centrale del modello delle minacce descritto più avanti e il motivo per cui esiste Headscale, un server di coordinamento open source che puoi gestire autonomamente.

Come comunicano direttamente due server dietro firewall diversi

Il NAT (network address translation) consente a più macchine di condividere un unico indirizzo pubblico. In genere il VPS dispone di un proprio indirizzo pubblico, ma spesso le altre macchine che vuoi aggiungere alla tailnet non lo hanno: ad esempio un server domestico, un build runner su una rete aziendale o un host dietro il firewall del provider che non puoi modificare.

Tailscale individua un percorso usando tecniche basate sugli standard STUN (session traversal utilities for NAT) e ICE. Ogni nodo invia un piccolo pacchetto UDP a un server STUN e rileva l'indirizzo pubblico e la porta che il router ha assegnato a quel socket. Entrambi i nodi comunicano questi candidati al coordination server, che li inoltra all'altra parte. Quindi i due nodi iniziano a inviare pacchetti l'uno all'altro nello stesso momento. Ogni router rileva prima un pacchetto in uscita, crea una mappatura e accetta la risposta proveniente dallo stesso indirizzo. Nessuna delle due parti ha bisogno di una regola firewall in ingresso.

Le porte sono specifiche. I tunnel WireGuard diretti usano UDP con una porta sorgente predefinita pari a 41641. STUN usa UDP 3478 per raggiungere i relay server di Tailscale. La connessione di controllo e tutti i dati inoltrati tramite relay usano HTTPS sulla porta TCP 443. Nella maggior parte dei casi non è necessario aprire porte in ingresso, anche se, su una rete con NAT problematico, consentire UDP 41641 in ingresso rende più probabile una connessione diretta.

tailscale netcheck

Leggi due righe di quel report. UDP: true indica che UDP esce dalla macchina, mentre UDP: false indica che tutte le connessioni da questo nodo verranno inoltrate tramite relay. MappingVariesByDestIP: true indica che il router assegna una porta pubblica diversa per ogni destinazione; di conseguenza, la previsione dell'indirizzo descritta sopra non può funzionare e questi nodi rimangono in genere collegati tramite relay.

Quando Tailscale usa un relay DERP

DERP (designated encrypted relay for packets) è il fallback. Tailscale gestisce relay in molte regioni, raggiungibili tramite TCP 443, e un nodo che non riesce a stabilire un percorso diretto invia i pacchetti WireGuard attraverso uno di questi relay.

I pacchetti restano crittografati. Tailscale lo dichiara esplicitamente: "non esiste alcun modo per cui un server DERP possa decrittografare il traffico. Si limita a inoltrare ciecamente traffico già crittografato da un nodo all'altro." Un relay vede il testo cifrato e vede quali nodi comunicano tra loro.

I relay trasportano anche i primi pacchetti della maggior parte delle connessioni. Individuare un percorso diretto richiede un po' di tempo, quindi una sessione spesso inizia tramite relay e passa a un percorso diretto senza interrompersi, non appena i due nodi si individuano. È possibile osservare questo passaggio.

tailscale ping db-1

Le prime risposte arrivano tramite via DERP(fra), quindi una riga successiva segnala qualcosa di simile a via 198.51.100.24:41641. Questo cambiamento indica il passaggio a un tunnel diretto. Se il valore non cambia mai, esegui tailscale netcheck su entrambe le estremità. Un percorso tramite relay continua comunque a funzionare. Aumenta la latenza, perché ogni pacchetto passa da una macchina intermedia aggiuntiva. Se hai notato trasferimenti lenti, ma non una connessione interrotta, perché una connessione Tailscale tramite relay è molto più lenta di una connessione diretta misura la differenza e mostra come instradare un VPS tramite un percorso diretto.

Unire una VPS alla tailnet

Lo script di installazione supporta Ubuntu e Debian.

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

sudo tailscale up visualizza un URL. Aprilo, esegui l'autenticazione e il nodo comparirà nella console di amministrazione. Verifica quindi che il daemon si riavvii dopo un reboot, perché questo è il passaggio che spesso viene saltato.

sudo systemctl is-enabled tailscaled
tailscale status

is-enabled dovrebbe visualizzare enabled, mentre tailscale status dovrebbe elencare il nuovo nodo con il relativo indirizzo 100.x. Per un server creato tramite script, un URL interattivo non è utile. Genera una auth key nella console di amministrazione e passala al comando insieme a un tag che indichi il tipo di macchina.

sudo tailscale up --auth-key=tskey-auth-REPLACE-ME --advertise-tags=tag:server

Un nodo con tag appartiene al tag e non alla persona che ha eseguito il comando. Continua quindi a funzionare anche dopo la rimozione dell'account di quella persona. Il tag deve essere dichiarato prima nel file delle policy, alla voce tagOwners, altrimenti il comando viene rifiutato. L'uso dei tag modifica anche il modo in cui la macchina viene conteggiata nel piano, perché una risorsa con tag viene fatturata separatamente dai dispositivi personali dell'utente. Cosa include realmente il piano gratuito spiega i limiti applicabili.

Per una flotta sono importanti due impostazioni. Per impostazione predefinita, le node key scadono dopo 180 days (ad agosto 2026). Quando una chiave scade, "le connessioni da e verso l'endpoint indicato smetteranno di funzionare" finché qualcuno non esegue nuovamente l'accesso. Per i server non presidiati, apri quindi la riga della macchina nella console di amministrazione e seleziona Disable Key Expiry. MagicDNS, abilitato per impostazione predefinita per le tailnet create il 20 October 2022 o dopo tale data, assegna a ogni nodo un nome come db-1.yak-bebop.ts.net, risolto da uno stub resolver all'indirizzo 100.100.100.100. Usa i nomi invece degli indirizzi, perché un nodo ricreato riceve un nuovo indirizzo ma mantiene il proprio nome.

Se l'installazione non riesce con apt o con il repository, Gli errori comuni durante l'installazione di Tailscale su Ubuntu descrive le relative correzioni. Se gestisci la VPS da un Mac, quale delle tre versioni di Tailscale installare sul Mac spiega come la scelta tra standalone, Mac App Store e tailscaled open source incide su aggiornamenti, tailscale ssh ed exit node.

Raggiungere un servizio in ascolto su localhost

È qui che una tailnet diventa utile e che spesso si verificano problemi. L'adesione alla tailnet non rende raggiungibile un servizio in ascolto sul loopback.

ss -tlnp | grep 3000

Se il comando restituisce 127.0.0.1:3000, il socket accetta soltanto pacchetti la cui destinazione è 127.0.0.1. Una richiesta proveniente da un altro nodo arriva con destinazione l'indirizzo 100.x di questo nodo. Il kernel non trova quindi alcun processo in ascolto su quell'indirizzo e risponde con un reset TCP. Il client restituisce Connection refused. Il tunnel funziona. Il problema riguarda il listener.

Esistono due soluzioni corrette. Associare il servizio all'indirizzo tailnet del nodo, mantenendolo così non esposto sull'interfaccia pubblica e senza un proxy intermedio: passare --bind 100.101.102.104 o l'opzione equivalente nella configurazione; per un container, pubblicare la porta come -p 100.101.102.104:3000:3000. In alternativa, lasciare il servizio sul loopback e mettere Tailscale davanti al servizio.

tailscale serve 3000

Questa configurazione inoltra le richieste a http://127.0.0.1:3000 e le rende disponibili nella tailnet con un nome ts.net tramite HTTPS, dopo aver abilitato i certificati HTTPS per la tailnet. Il servizio rimane privato e accessibile soltanto dai nodi della tailnet. La versione pubblica dello stesso approccio è Funnel; Tailscale serve rispetto a Funnel spiega quale soluzione scegliere.

Due attività correlate hanno pagine dedicate. Per raggiungere un'intera rete privata su cui Tailscale non è installato, serve un subnet router su un VPS; per instradare il traffico Internet in uscita di un nodo attraverso un altro nodo, serve un exit node.

Chiusura delle porte non più necessarie

Quando ogni amministratore accede al server tramite la tailnet, la porta pubblica 22 non ha più alcuna funzione. Questo è il vantaggio pratico: una porta chiusa non può essere sottoposta a tentativi di forza bruta e i log non si riempiono più di tentativi di accesso.

L’ordine delle operazioni è importante. Aggiungi l’accesso tramite tailnet, verifica di riuscire ad accedere da una seconda sessione e solo dopo rimuovi la regola pubblica.

sudo ufw allow in on tailscale0
sudo ufw status verbose

Dopo questa verifica, elimina la regola pubblica per SSH e riconnettiti usando il nome MagicDNS. Nota che cosa fa realmente ufw allow in on tailscale0: considera attendibile tutto il traffico che arriva dal tunnel, quindi il file delle policy di Tailscale diventa il controllo degli accessi al posto di ufw. Scrivi la policy tenendo conto di questo comportamento.

Attenzione se esegui container. Una porta pubblicata da Docker installa regole NAT proprie e ignora ufw, quindi un ufw deny non la chiude. Le porte pubblicate da Docker ignorano ufw spiega il meccanismo. Pubblicare la porta sull’indirizzo della tailnet, come descritto sopra, evita il problema. Se l’applicazione viene eseguita con Docker Compose, un sidecar Tailscale nello stack Compose elimina del tutto la porta pubblicata, lasciando il container raggiungibile soltanto tramite il relativo nome nella tailnet.

Cosa protegge Tailscale e cosa invece non protegge

È importante dirlo chiaramente, perché la versione presentata dal marketing tende a confondere la distinzione.

Protetto: il traffico tra due nodi è cifrato end-to-end con WireGuard e nessun relay intermedio può leggerlo. Le chiavi private non lasciano mai la macchina che le ha generate. I nodi non richiedono alcuna porta pubblica in ingresso, quindi su Internet non c'è nulla in ascolto sulle porte 22 o 5432 da sottoporre a scansione. L'accesso tra i nodi è deciso da un file di policy, non da chiunque conosca un indirizzo.

Non protetto: il server di coordinamento vede il grafo dei dispositivi. Questi metadati sono sensibili di per sé, perché i nomi delle macchine, i proprietari, gli indirizzi e gli orari di connessione descrivono la tua infrastruttura. Il server distribuisce inoltre le chiavi, e questo rappresenta il rischio più rilevante. Tailscale lo dichiara esplicitamente: "Se Tailscale fosse malevolo e inserisse di nascosto nuovi nodi nella tua rete, potrebbe inviare o ricevere traffico dai nodi esistenti in testo in chiaro." Anche il provider di single sign-on rientra nello stesso percorso di trust, perché chiunque possa creare un'identità al suo interno può aggiungere un nodo. Un nodo compromesso è inoltre un peer all'interno del tailnet, quindi ciò che può raggiungere dipende da quanto consentito dalla policy. Stabilire se questo rischio sia accettabile dipende dall'avversario da cui vuoi difenderti; il modello completo di trust analizza ciascuno di questi casi, compreso ciò che può fare effettivamente un account di identità sottratto.

Esistono due risposte al rischio legato alla distribuzione delle chiavi. La prima è tailnet lock, che richiede ai nodi trusted già esistenti di firmare crittograficamente un nuovo nodo prima che gli altri nodi lo accettino. Un control plane che aggiunge un nodo senza una firma valida viene ignorato. La console di amministrazione genera la riga tailscale lock init esatta per i nodi che effettuano la firma e ogni nodo può verificare ciò che rileva.

tailscale lock status

Tutti i nodi devono segnalare lo stesso insieme di chiavi di firma trusted. La seconda risposta consiste nell'eseguire personalmente il control plane. Un server di coordinamento Headscale self-hosted utilizza lo stesso protocollo con gli stessi client, trasferendo il grafo dei dispositivi e la distribuzione delle chiavi su hardware di tua proprietà. Sarai quindi responsabile anche dell'uptime di quel server. Se stai ancora confrontando control plane self-hosted invece di scegliere questa soluzione, NetBird è una VPN mesh distinta, il cui server viene eseguito interamente da te su un singolo VPS.

C'è un'impostazione predefinita da correggere il primo giorno. Un nuovo tailnet viene rilasciato con una configurazione permissiva: "il file di policy predefinito del tailnet abilita la comunicazione tra tutti i dispositivi all'interno del tailnet." Non appena aggiungi una sezione acls, il modello passa al deny by default e vengono autorizzate soltanto le tue regole.

{
  "tagOwners": {
    "tag:server": ["autogroup:admin"]
  },
  "acls": [
    {"action": "accept", "src": ["autogroup:member"], "dst": ["tag:server:22"]}
  ]
}

Questa policy consente ai membri del tailnet di raggiungere SSH sui server contrassegnati con un tag, e nient'altro. Aggiungi una regola per ogni servizio invece di lasciare il wildcard, perché il wildcard significa che una singola chiave sottratta da un laptop consente di raggiungere il database.

Modalità di errore e stringhe visualizzate

tailscale status restituisce sempre relay. I due nodi non hanno mai stabilito un percorso diretto. Esegui tailscale netcheck su entrambe le estremità. UDP: false indica che il traffico UDP in uscita è bloccato, quindi può funzionare soltanto un relay. MappingVariesByDestIP: true indica la presenza di un NAT restrittivo; consentire il traffico UDP in ingresso sulla porta 41641 dal lato sotto il tuo controllo risolve spesso il problema.

Un nodo che ha funzionato per mesi è scomparso. La sua chiave del nodo è scaduta dopo i 180 giorni predefiniti. La macchina risulta scaduta nella console di amministrazione e sudo tailscale up sul server la riattiva. Disabilita la scadenza delle chiavi sui server per evitare che il problema si ripeta.

I peer sono elencati, ma le connessioni vanno in timeout. La connettività funziona e la policy nega il traffico. Controlla la sezione acls per verificare la presenza di una regola che copra questa origine, questa destinazione e questa porta. Un pacchetto negato viene eliminato invece di ricevere una risposta; per questo ottieni un timeout anziché Connection refused.

I nomi MagicDNS non vengono risolti. ping db-1 ha esito negativo, mentre ping 100.101.102.104 funziona. Qualcosa ha sostituito /etc/resolv.conf, quindi le query non raggiungono lo stub resolver su 100.100.100.100. Controlla cat /etc/resolv.conf per 100.100.100.100 e verifica quale altro componente della macchina scrive in quel file. Si tratta della stessa classe di problema descritta in DNS che non funziona all'interno di un tunnel WireGuard.

tailscale up rifiuta il tuo tag. Il tag non è dichiarato in tagOwners nel file della policy. Aggiungilo, quindi esegui nuovamente il comando.

FAQ

Tailscale è una VPN o una rete mesh?

Entrambe le definizioni sono corrette, ma descrivono livelli diversi. I tunnel usano WireGuard, quindi Tailscale è una VPN. La topologia è mesh perché ogni nodo crea un tunnel diretto verso ciascun nodo con cui comunica, invece di inviare ogni pacchetto attraverso un server centrale. Il server di coordinamento opera nel piano di controllo, non nel piano dati. Se diventa irraggiungibile, i tunnel esistenti continuano a trasportare il traffico. Durante l'interruzione si interrompono invece l'aggiunta di nuovi nodi e l'applicazione delle modifiche alle chiavi o ai criteri.

Tailscale può leggere il mio traffico?

Non può leggere i contenuti. Il traffico è crittografato end-to-end tra i nodi tramite WireGuard, le chiavi private non lasciano mai i nodi e un relay DERP inoltra pacchetti che non può decrittografare. Tailscale vede però i metadati: nomi delle macchine, proprietari, chiavi pubbliche, indirizzi degli endpoint e momento in cui ogni nodo è online. Distribuisce inoltre le chiavi. Un server di coordinamento compromesso potrebbe quindi tentare di inserire un nodo che la tua infrastruttura considererebbe attendibile. Tailnet lock impedisce questo comportamento richiedendo firme dai tuoi nodi attendibili, mentre Headscale rimuove il piano di controllo gestito dall'esterno.

Devo aprire porte del firewall per Tailscale?

Quasi mai in ingresso. Le indicazioni di Tailscale specificano che "nella maggior parte dei casi non è necessario aprire porte del firewall". In uscita, un nodo deve poter raggiungere il server di coordinamento e i relay sulla porta TCP 443, oltre a usare UDP 3478 per STUN. I tunnel diretti usano UDP con una porta sorgente predefinita pari a 41641. Consentire UDP 41641 in ingresso è facoltativo e aiuta a stabilire connessioni dirette soltanto su reti con configurazioni particolari.

Perché gli altri nodi non riescono a raggiungere il mio servizio sulla porta 3000?

Controlla prima l'indirizzo di ascolto con ss -tlnp. Un listener su 127.0.0.1:3000 rifiuta le connessioni indirizzate all'indirizzo tailnet 100.x del nodo perché quel socket accetta soltanto la destinazione di loopback; il client visualizza quindi Connection refused. Associa il servizio all'indirizzo tailnet oppure esegui tailscale serve 3000 per inoltrare le connessioni. Se il listener è già associato a 0.0.0.0 e la connessione va in timeout invece di essere rifiutata, la causa è una regola dei criteri o il firewall dell'host, non l'indirizzo di ascolto.

Devo eseguire Headscale invece del server di coordinamento di Tailscale?

Esegui Headscale quando il grafo dei dispositivi o la distribuzione delle chiavi devono rimanere su un'infrastruttura sotto il tuo controllo, oppure quando la tailnet deve funzionare senza dipendere da un servizio esterno. I client e il protocollo sono gli stessi. Il costo operativo consiste nel dover gestire il server di coordinamento. Se il server non è disponibile, i nuovi nodi non possono unirsi e le modifiche ai criteri non vengono applicate. Per una flotta di piccole dimensioni, il piano di controllo gestito con tailnet lock abilitato offre in genere il compromesso migliore.