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. Il VPS di solito 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 nella rete dell'ufficio oppure un sistema dietro un 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 e la porta pubblici che il router ha assegnato a quel socket. Entrambi i nodi comunicano questi candidati al server di coordinamento, che li inoltra all'altra estremità. Poi entrambi i nodi iniziano a inviare pacchetti contemporaneamente. Ogni router vede prima un pacchetto in uscita, quindi crea una mappatura e accetta la risposta proveniente dallo stesso indirizzo. Nessuno dei due lati ha bisogno di una regola firewall in ingresso. Per questo un NAS o un Pi nella rete domestica può rimanere raggiungibile senza alcun port forwarding configurato sul router. La guida usare Tailscale invece del port forwarding illustra questa configurazione, compresi i suoi limiti.

Le porte utilizzate sono specifiche. I tunnel WireGuard diretti usano UDP con una porta sorgente che, per impostazione predefinita, è 41641. STUN usa UDP 3478 per raggiungere i server relay di Tailscale. La connessione di controllo preferisce HTTP semplice sulla porta TCP 80, incapsulato nel trasporto crittografato proprietario di Tailscale, e passa a HTTPS sulla porta TCP 443 quando la porta 80 non risponde. I dati inoltrati tramite i server DERP di Tailscale usano HTTPS sulla porta TCP 443, mentre un relay peer eseguito all'interno della tua tailnet li trasporta tramite UDP. Nella maggior parte dei casi non devi aprire porte in ingresso, ma in una rete con un NAT complesso consentire UDP 41641 in ingresso aumenta la probabilità di stabilire una connessione diretta.

tailscale netcheck

Leggi due righe di quel report. UDP: true significa che questa macchina può inviare pacchetti UDP a Internet, mentre UDP: false significa che non può farlo; pertanto tutte le connessioni originate da questo nodo passeranno attraverso un relay. MappingVariesByDestIP: true significa che il router assegna una porta pubblica diversa per ogni destinazione; di conseguenza la previsione dell'indirizzo descritta sopra non può funzionare e quei nodi rimangono in genere collegati tramite relay.

Quando Tailscale usa invece 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 propri pacchetti WireGuard attraverso uno di questi relay. Fa eccezione una tailnet con relay peer designati, cioè dispositivi propri che inoltrano il traffico tramite UDP. Tailscale prova prima questi relay e usa DERP solo quando nessuno è disponibile; in tal caso tailscale status mostra la connessione come peer-relay.

I pacchetti restano crittografati. Tailscale lo dichiara esplicitamente: "there is never a way for a DERP server to decrypt your traffic. It just blindly forwards already-encrypted traffic from one node to another." 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. La ricerca di un percorso diretto richiede alcuni istanti, quindi una sessione spesso inizia tramite relay e passa a un percorso diretto non appena i due nodi si individuano. È possibile osservare questo passaggio.

tailscale ping db-1

Le prime risposte arrivano via DERP(fra), quindi una riga successiva riporta un valore 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 a funzionare. Aumenta però la latenza, perché ogni pacchetto passa da un terzo computer prima di raggiungere la destinazione. Se hai notato trasferimenti lenti anziché una connessione interrotta, perché una connessione Tailscale tramite relay è molto più lenta di una connessione diretta misura la differenza e mostra come portare un VPS su un percorso diretto.

Collegare 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 stampa un URL. Aprilo, esegui l'autenticazione e il nodo comparirà nella console di amministrazione. Verifica quindi che il demone si riavvii dopo un reboot, perché questo è il passaggio che spesso viene saltato.

sudo systemctl is-enabled tailscaled
tailscale status

is-enabled dovrebbe stampare 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 chiave di autenticazione nella console di amministrazione e passala 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 se l'account di quella persona viene eliminato. Il tag deve essere prima dichiarato nel file dei criteri in 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 tariffata separatamente dai dispositivi personali di un utente; cosa include realmente il piano gratuito spiega i limiti applicabili.

Per una flotta sono importanti due impostazioni. Per impostazione predefinita, le chiavi dei nodi scadono dopo 180 giorni (a ottobre 2026) e, quando una chiave scade, "le connessioni da e verso l'endpoint indicato smettono di funzionare" finché il dispositivo non esegue nuovamente l'autenticazione. Un amministratore può scegliere Temporarily extend key su una macchina scaduta nella console di amministrazione. Questa opzione concede 30 minuti per accedere nuovamente o disabilitare la scadenza. Per impostazione predefinita, la scadenza della chiave è disabilitata per un nodo autenticato con un tag, come quello precedente. Per qualsiasi altro server non presidiato, apri la riga della macchina nella console di amministrazione e scegli Disable Key Expiry. MagicDNS, abilitato per impostazione predefinita nelle tailnet create il 20 ottobre 2022 o in una data successiva, assegna a ogni nodo un nome come db-1.yak-bebop.ts.net, risolto da uno stub resolver in 100.100.100.100. Usa i nomi anziché gli indirizzi, perché un nodo ricreato riceve un nuovo indirizzo ma conserva 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 soluzioni.

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 non protegge

Vale la pena dichiararlo chiaramente, poiché la versione di marketing confonde i confini.

Protetto: il traffico tra due nodi è crittografato 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 necessitano di porte pubbliche in ingresso, quindi non c'è nulla sulla 22 o sulla 5432 che Internet possa scansionare. L'accesso tra i nodi è stabilito da un file di policy anziché da chiunque conosca un indirizzo.

Non protetto: il server di coordinamento vede il grafo dei tuoi dispositivi. Tali metadati sono sensibili di per sé, poiché i nomi delle macchine, i proprietari, gli indirizzi e i tempi di attività descrivono la tua infrastruttura. Distribuisce inoltre le chiavi, che rappresenta il rischio più acuto. Tailscale lo afferma direttamente: "Se Tailscale fosse malevolo e inserisse furtivamente nuovi nodi nella tua rete, allora Tailscale potrebbe inviare o ricevere traffico verso i tuoi nodi esistenti in chiaro". Il tuo provider di single sign-on si trova nello stesso percorso di fiducia, poiché chiunque possa creare un'identità lì può aggiungere un nodo. Inoltre, un nodo compromesso è un peer all'interno della tailnet, quindi ciò che può raggiungere in seguito è tutto ciò che la tua policy consente. Se questo costituisca un rischio accettabile dipende da chi stai cercando di contrastare, e il modello di fiducia completo analizza ciascuno di questi casi, incluso ciò che un account d'identità rubato può effettivamente fare.

Esistono due risposte al rischio di distribuzione delle chiavi. La prima è il tailnet lock, che richiede ai nodi fidati 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 l'esatta riga tailscale lock init per i tuoi nodi di firma e ogni nodo può confermare ciò che vede.

tailscale lock status

Tutti i nodi dovrebbero segnalare lo stesso insieme di chiavi di firma trusted. La seconda risposta è gestire il control plane autonomamente. Un server di coordinamento Headscale self-hosted utilizza lo stesso protocollo per gli stessi client, il che sposta il grafo dei dispositivi e la distribuzione delle chiavi su hardware di tua proprietà. In questo modo diventi responsabile anche dell'uptime di quel server. Se stai ancora confrontando control plane self-hosted invece di optare per questo, NetBird è una VPN mesh separata il cui server viene eseguito interamente su una singola VPS.

Un'impostazione predefinita da correggere il primo giorno. Una nuova tailnet viene rilasciata con configurazione permissiva: "la policy predefinita della tailnet abilita la comunicazione tra tutti i dispositivi all'interno della tailnet". Non appena aggiungi una sezione acls, il modello passa al negato per impostazione predefinita e solo le tue regole vengono applicate.

{
  "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 associati ai tag e nient'altro. Aggiungete una regola per ogni servizio invece di lasciare il carattere jolly, perché con il carattere jolly la compromissione della chiave di un solo laptop consente di raggiungere il database. Se state ancora scegliendo una VPN mesh, il modo in cui definite regole di questo tipo è uno degli aspetti in cui le opzioni differiscono realmente; NetBird e Tailscale confronta i due modelli di policy e indica anche chi gestisce il control plane.

Modalità di errore e stringhe visualizzate

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

Un nodo che ha funzionato per mesi è scomparso. Una causa comune è la scadenza della chiave del nodo dopo i 180 giorni predefiniti. Controlla quindi prima la macchina nella console di amministrazione. Se risulta scaduta, sudo tailscale up sulla macchina la riattiva. Disabilitare la scadenza delle chiavi sui server impedisce che il problema si ripeta. Se la chiave non è scaduta, controlla il file della policy. Per un dispositivo che non compare in tailscale status, Tailscale consiglia infatti di verificare la presenza di regole di accesso che impediscono la connessione.

I peer sono elencati, ma le connessioni scadono. Se tailscale ping riceve risposte, la connettività funziona e la causa probabile è che la policy neghi il traffico. Controlla la sezione acls per verificare la presenza di una regola che copra questa origine, destinazione e porta. Un pacchetto negato viene scartato invece di ricevere una risposta. Per questo ottieni un timeout anziché Connection refused.

I nomi MagicDNS non vengono risolti. ping db-1 non funziona mentre ping 100.101.102.104 funziona. Verifica prima che il client accetti le impostazioni DNS di Tailscale: un nodo avviato con --accept-dns=false non invia le query al resolver stub in ascolto su 100.100.100.100. Controlla quindi cat /etc/resolv.conf e qualsiasi altro componente della macchina che scriva in quel file. In un sistema che usa systemd-resolved, il file è normalmente un link simbolico a /run/systemd/resolve/stub-resolv.conf. In questo caso è previsto che 100.100.100.100 non sia elencato in quel file. Quando tailscaled scrive direttamente nel file, un client DHCP o un altro strumento che lo sovrascrive interrompe MagicDNS. Se nessuna di queste cause è applicabile, il problema può trovarsi anche nella configurazione DNS locale o di rete. È la stessa classe di problema descritta in Interruzione del DNS 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 di nuovo il comando.

FAQ

Tailscale è una VPN o una rete mesh?

Entrambi i termini sono corretti e descrivono livelli diversi. I tunnel usano WireGuard, quindi la soluzione è una VPN. La topologia è una mesh, perché ogni nodo crea un tunnel diretto verso ciascun nodo con cui comunica, invece di inviare tutti i pacchetti attraverso un unico server centrale. Il server di coordinamento si trova nel piano di controllo, non nel piano dati. Se diventa irraggiungibile, i tunnel esistenti continuano a trasportare il traffico. Durante un'interruzione si fermano invece l'aggiunta di nuovi nodi e la propagazione delle modifiche alle chiavi o alle policy. Tuttavia, per impostazione predefinita non è una VPN per la privacy: i siti web continuano a vedere il tuo indirizzo pubblico finché non invii il traffico attraverso un nodo di uscita, e cosa nasconde Tailscale ai siti web e al tuo ISP dipende dalla configurazione adottata.

Tailscale può leggere il mio traffico?

Non può leggere il contenuto. Il traffico è cifrato 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, quindi un server di coordinamento compromesso potrebbe tentare di inserire un nodo che la rete riconoscerebbe come attendibile. Tailnet lock impedisce questo comportamento richiedendo firme dai nodi attendibili dell'organizzazione. Headscale rimuove invece il piano di controllo ospitato dall'architettura.

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 usare TCP 443 verso il server di coordinamento e i relay, oltre a UDP 3478 per STUN. I tunnel diretti usano UDP con una porta di origine che per impostazione predefinita è 41641. Consentire UDP 41641 in ingresso è facoltativo e aiuta solo a stabilire connessioni dirette su reti con configurazioni problematiche.

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

Controlla prima l'indirizzo di bind 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 solo la destinazione di loopback. Il client visualizza quindi Connection refused. Associa il servizio all'indirizzo tailnet oppure esegui tailscale serve 3000 per creare un proxy. Se il listener è già associato a 0.0.0.0 e la connessione va in timeout invece di essere rifiutata, il problema non riguarda l'indirizzo di bind. Controlla prima le regole dei criteri e i firewall dell'host, quindi i firewall di rete e l'eventuale scadenza dell'autenticazione di uno dei due dispositivi.

Devo eseguire Headscale invece del server di coordinamento di Tailscale?

Esegui Headscale quando il grafo dei dispositivi o la distribuzione delle chiavi devono restare 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 consiste nel dover gestire il server di coordinamento: se diventa indisponibile, i nuovi nodi non possono unirsi e le modifiche ai criteri non vengono applicate. Per una flotta ridotta, il piano di controllo ospitato con tailnet lock abilitato è in genere il compromesso migliore.