Come usare un VPS come exit node Tailscale

Cosa fa un exit node Tailscale

Un exit node Tailscale è una macchina della tua tailnet che gestisce tutto il traffico Internet degli altri dispositivi. Un VPS (virtual private server) è adatto a questo scopo perché ha un indirizzo pubblico fisso e rimane online. La configurazione richiede cinque passaggi: installare Tailscale sul server, pubblicizzare l'exit node, abilitare l'inoltro IP, approvare la route nella console di amministrazione e selezionare il nodo sul laptop. Il quarto passaggio consiste nell'attivare un'opzione in una pagina Web, non nell'eseguire un comando. È il punto in cui la maggior parte degli utenti si blocca.

Dopo l'attivazione, il laptop cifra ogni pacchetto e lo invia al VPS. Il VPS applica il source NAT (network address translation) e inoltra il pacchetto usando il proprio indirizzo IP pubblico. I siti Web vedono il VPS. La rete Wi-Fi del bar vede un solo flusso UDP cifrato verso il VPS e nient'altro.

Tailscale usa WireGuard per il data path e un server di coordinamento che distribuisce le chiavi e aiuta due macchine a trovarsi attraverso il NAT. Grazie a questo server di coordinamento, nei passaggi seguenti non è necessario copiare alcuna chiave. Per un confronto completo tra Tailscale e WireGuard senza componenti aggiuntivi, leggi come confrontare Tailscale e WireGuard senza componenti aggiuntivi. Se preferisci gestire autonomamente ogni componente del tunnel, configura una VPN WireGuard senza componenti aggiuntivi sul tuo VPS.

I passaggi seguenti presuppongono che Tailscale sia già in esecuzione sul laptop e che entrambe le macchine abbiano effettuato l'accesso alla stessa tailnet. Una tailnet è la tua rete Tailscale privata e ogni dispositivo al suo interno riceve un indirizzo stabile all'interno di 100.64.0.0/10.

Installa Tailscale sul tuo VPS

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

Lo script di installazione seleziona il repository dei pacchetti per la tua distribuzione e installa il demone tailscaled. tailscale up stampa quindi un URL di autenticazione. Aprilo in un browser e accedi con lo stesso account usato dal laptop, perché un VPS autenticato su un tailnet diverso non può fornire in alcun modo l'accesso al laptop.

tailscale status
tailscale ip -4

tailscale status dovrebbe ora elencare entrambe le macchine. tailscale ip -4 mostra l'indirizzo del VPS nel tailnet, che userai più avanti sul client.

Tailscale richiede un dispositivo TUN per creare il tunnel. Su un VPS KVM il dispositivo è disponibile. Nei piani basati sulla virtualizzazione tramite container, che condividono il kernel dell'host, /dev/net/tun a volte è assente e tailscaled non può creare l'interfaccia tailscale0. Esegui ls -l /dev/net/tun prima di procedere.

Abilitare l'inoltro IP, altrimenti il VPS scarta ogni pacchetto

Una macchina Linux scarta tutti i pacchetti non indirizzati a se stessa, perché net.ipv4.ip_forward è impostato su 0 per impostazione predefinita. Il nodo di uscita accetterebbe il traffico, lo decifrerebbe e poi lo scarterebbe. Scrivere l'impostazione in un file permette di conservarla dopo un riavvio.

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

tee -a aggiunge il contenuto, quindi eseguendo queste righe una seconda volta si scrivono entrambe le impostazioni due volte. Il risultato continua a funzionare, ma cat /etc/sysctl.d/99-tailscale.conf mostrerà un contenuto anomalo. Verificare il valore effettivo invece di affidarsi al file:

sysctl net.ipv4.ip_forward

Deve stampare net.ipv4.ip_forward = 1. Se si salta questo passaggio e si usa tailscale up --advertise-exit-node, il client mostra:

Warning: IP forwarding is disabled, subnet routing/exit nodes will not work.

tailscale set --advertise-exit-node non esegue questo controllo, quindi l'assenza di output da set non dimostra che l'inoltro sia attivo. Leggere direttamente il valore sysctl.

Non è necessario scrivere manualmente una regola masquerade. tailscaled installa le proprie catene firewall, denominate ts-input, ts-forward e ts-postrouting, e la regola NAT per il traffico del nodo di uscita si trova in ts-postrouting. Visualizzarle con sudo iptables-save | grep ts- oppure con sudo nft list ruleset su un sistema che usa nftables.

Pubblicizzare il VPS come exit node

sudo tailscale set --advertise-exit-node

tailscale set modifica una preferenza e lascia invariate le altre. tailscale up --advertise-exit-node pubblicizza anche il nodo, ma introduce un effetto collaterale: up considera i flag nella riga di comando come l’insieme completo delle impostazioni non predefinite. Di conseguenza, un successivo sudo tailscale up senza argomenti non viene eseguito e stampa

changing settings via 'tailscale up' requires mentioning all
non-default flags. To proceed, either re-run your command with --reset or
use the command below to explicitly mention the current value of
all non-default settings:

Per le modifiche successive, usa set. In questo modo il messaggio non viene visualizzato.

La pubblicizzazione è un’offerta. Il VPS comunica ora al coordination server di essere disponibile come exit node. Nessun client può ancora utilizzarlo.

Approva il nodo di uscita Tailscale nella console di amministrazione

Questo passaggio non prevede alcun comando. Apri la pagina Machines nella console di amministrazione, individua il VPS, apri il menu con i tre puntini alla fine della relativa riga, seleziona Edit route settings e attiva Use as exit node.

Finché questa opzione non è attiva, il control plane conserva la proposta senza assegnarla ad alcun dispositivo. tailscale exit-node list sul laptop non mostra nulla e il traffico continua a seguire il percorso normale. Su nessuna delle due macchine viene visualizzato un messaggio di errore. Il nodo di uscita semplicemente non compare.

Puoi approvare automaticamente i nodi di uscita inserendo una voce nel file dei criteri tailnet:

"autoApprovers": {
  "exitNode": ["tag:exit"],
}

Un dispositivo avviato con --advertise-tags=tag:exit viene quindi approvato automaticamente, purché tag:exit sia definito sotto tagOwners nello stesso file dei criteri. L'assegnazione di un tag modifica la proprietà: un dispositivo con tag appartiene alla tailnet anziché al tuo account utente e cambiano anche le regole di accesso applicate. Per un singolo VPS, l'opzione nella console è più semplice.

Selezionare il nodo di uscita sul laptop

Su un client Linux:

tailscale exit-node list
sudo tailscale set --exit-node=vps.your-tailnet.ts.net

exit-node list stampa i nodi di uscita approvati nella tailnet, con i relativi indirizzi. Un elenco vuoto indica che il passaggio di approvazione non è stato completato. Su macOS, Windows, iOS e Android, la stessa scelta è disponibile come voce di menu Exit Node nell'app Tailscale.

Verificare dal client, mai dal server:

curl -4 https://ifconfig.me

Eseguire il comando una volta prima di selezionare il nodo di uscita e una volta dopo. L'indirizzo deve cambiare da quello locale all'indirizzo IP pubblico del VPS. Per smettere di usare il nodo di uscita:

sudo tailscale set --exit-node=

Un altro flag è importante fin dal primo giorno. Quando è selezionato un nodo di uscita, il client invia tutto nel tunnel, inclusi i pacchetti destinati a 192.168.1.50. Di conseguenza, la stampante e lo storage di rete non rispondono più. Mantenere la rete locale sulla route locale:

sudo tailscale set --exit-node=<name> --exit-node-allow-lan-access=true

Perché il DNS cambia non appena attivi l’exit node

Per impostazione predefinita, un dispositivo che usa un exit node usa anche quell’exit node come resolver DNS (domain name system) per ogni dominio. Questo comportamento sostituisce i nameserver DNS globali e split DNS configurati per il tuo tailnet. È una scelta intenzionale. Se le query continuassero a essere inviate al resolver della rete locale, il router del bar vedrebbe comunque il nome di ogni sito visitato, mentre il traffico resterebbe privato. Nomi e pacchetti devono uscire dallo stesso punto.

Una conseguenza crea problemi a chi esegue un resolver interno: un nameserver del tailnet da cui dipendi non viene più usato mentre l’exit node è attivo. Attiva Use with exit node per quel nameserver nella pagina DNS della console di amministrazione per riabilitarlo.

I nomi MagicDNS continuano a funzionare, perché il client Tailscale risponde localmente a 100.100.100.100 prima che qualsiasi richiesta raggiunga l’exit node. Verificalo con dig @100.100.100.100 your-vps.your-tailnet.ts.net oppure, su un client systemd-resolved, con resolvectl status, dove l’interfaccia Tailscale elenca 100.100.100.100 come server DNS.

Se disabiliti la gestione DNS di Tailscale con --accept-dns=false, il client continua a usare il resolver ricevuto dalla rete locale. Il traffico viene incanalato nel tunnel, ma le query DNS no: si tratta di la stessa perdita DNS che interessa i tunnel WireGuard configurati manualmente. Lascia --accept-dns invariato, a meno che tu non abbia un motivo specifico per modificarlo.

IPv6 attraverso il nodo di uscita

Un nodo di uscita pubblicizza entrambe le route predefinite, 0.0.0.0/0 e ::/0. Se il VPS non dispone di un percorso IPv6 funzionante verso Internet, i pacchetti IPv6 arrivano attraverso il tunnel e si fermano lì. Esegui il test sul VPS prima di considerarlo affidabile:

ip -6 addr show
curl -6 https://ifconfig.me

Una richiesta non riuscita indica che il VPS non dispone di connettività IPv6 upstream. I siti web dual stack continuano generalmente a caricarsi, perché il client rinuncia a IPv6 e riprova tramite IPv4, anche se il nuovo tentativo aggiunge un ritardo alla prima connessione a ogni sito. Le destinazioni raggiungibili solo tramite IPv6 restano irraggiungibili.

L'altra parte riguarda l'inoltro. net.ipv4.ip_forward = 1 con net.ipv6.conf.all.forwarding impostato su 0 consente il corretto funzionamento del percorso IPv4, ma crea un black hole per IPv6. Per l'utente questo si manifesta come un rallentamento di alcuni siti, non come un errore facilmente ricercabile. Entrambe le righe devono essere presenti nel file sysctl.

La VPS deve pubblicizzare anche le route delle subnet?

Un exit node trasporta tutto il traffico Internet. Una route di subnet trasporta un singolo intervallo privato che si trova dietro la macchina che lo pubblicizza. Sono funzionalità separate, con autorizzazioni separate, e una macchina può svolgere entrambi i ruoli.

sudo tailscale set --advertise-routes=10.0.0.0/24

Pubblicizza una subnet quando la VPS condivide una rete privata con altri server che vuoi raggiungere tramite i relativi indirizzi privati. Approvala nello stesso pannello Edit route settings, usando l'interruttore dedicato.

Scegli con attenzione l'intervallo. Una route pubblicizzata è più specifica della route predefinita del laptop. Di conseguenza, se dalla VPS pubblichi 192.168.1.0/24, la route prende il controllo degli indirizzi di una rete domestica che usa lo stesso intervallo e i dispositivi sulla tua scrivania diventano irraggiungibili. Usa un intervallo scelto da te, non quello assegnato automaticamente dal router di casa.

Rendere veloce l’exit node con l’inoltro UDP GRO

Tailscale 1.54 e versioni successive, su un kernel Linux 6.2 o successivo, può usare un meccanismo di receive offload che aumenta il throughput del traffico inoltrato. GRO (generic receive offload) aggrega i pacchetti in ingresso prima che il kernel li elabori singolarmente. Ad agosto 2026 questa procedura deve ancora essere eseguita manualmente sull’exit node.

sudo apt install -y ethtool
NETDEV=$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")
sudo ethtool -K $NETDEV rx-udp-gro-forwarding on rx-gro-list off

ip -o route get 8.8.8.8 indica l’interfaccia che raggiunge effettivamente Internet, quindi non è necessario scegliere manualmente tra eth0, ens3 e enp1s0. Verifica con ethtool -k $NETDEV | grep udp-gro-forwarding, che ora dovrebbe restituire on.

L’impostazione viene persa al riavvio. Su un sistema che esegue networkd-dispatcher, rendila automatica:

printf '#!/bin/sh\n\nethtool -K %s rx-udp-gro-forwarding on rx-gro-list off \n' "$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")" | sudo tee /etc/networkd-dispatcher/routable.d/50-tailscale
sudo chmod 755 /etc/networkd-dispatcher/routable.d/50-tailscale

Verifica prima che /etc/networkd-dispatcher/routable.d/ esista. Se non esiste, la macchina non esegue networkd-dispatcher; una piccola unità systemd che esegue la riga ethtool all’avvio svolge la stessa funzione.

Cosa prevede la policy di utilizzo accettabile del provider per il traffico in uscita

Ogni pacchetto inviato da un client attraverso il nodo di uscita lascia il server con l'indirizzo IP pubblico del VPS e viene quindi associato al tuo account. Le segnalazioni di abuso arrivano nella tua casella di posta: notifiche per violazioni del copyright e reclami relativi a port scan. Leggi la AUP (acceptable use policy) del provider prima di instradare attraverso un unico server il traffico di una famiglia o di un team. Non rendere disponibile un nodo di uscita a persone di cui non puoi garantire l'affidabilità.

La larghezza di banda viene conteggiata due volte. Il traffico arriva al VPS attraverso il tunnel e poi esce nuovamente verso Internet. In genere entrambe le direzioni vengono conteggiate nell'allowance di trasferimento del piano. Uno stream video visualizzato attraverso un nodo di uscita incide sul consumo più di quanto molti prevedano.

Anche gli intervalli di indirizzi dei datacenter hanno una reputazione. Alcuni siti mostrano più CAPTCHA a questi indirizzi e alcuni servizi di streaming li rifiutano direttamente. Nessuna modifica alla configurazione può cambiare questo comportamento, perché dipende dal blocco di indirizzi posseduto dal provider.

Perché il traffico continua a uscire dalla connessione locale

Il nodo di uscita è pubblicizzato ma non approvato. tailscale exit-node list sul client non restituisce nulla e nessuna delle due macchine registra errori. Apri la pagina Machines e abilita Use as exit node.

Il client non lo ha mai selezionato. L'approvazione rende il nodo disponibile nella tailnet. La selezione è un'azione separata su ogni dispositivo. Esegui di nuovo sudo tailscale set --exit-node=<name>, quindi controlla nuovamente curl -4 https://ifconfig.me.

Il forwarding è disabilitato. Il sintomo è specifico: tailscale ping <vps> ha esito positivo, il tunnel è chiaramente attivo e ogni indirizzo esterno va in timeout. sysctl net.ipv4.ip_forward restituisce 0. Correggi il file sysctl, quindi esegui sudo sysctl -p /etc/sysctl.d/99-tailscale.conf.

Un firewall scarta i pacchetti inoltrati. tailscaled inserisce una propria catena ts-forward, sufficiente su un VPS appena configurato. Un sistema che esegue già ufw o Docker può ritrovarsi con una policy FORWARD impostata su DROP e con regole precedenti a quelle di Tailscale. Non procedere per tentativi: esegui sudo iptables -L FORWARD -n -v mentre il client prova a caricare una pagina e controlla quali contatori aumentano. Su un sistema con ufw, la correzione usuale è DEFAULT_FORWARD_POLICY="ACCEPT" in /etc/default/ufw, seguita da sudo ufw reload. Controlla anche il firewall di rete del provider nel pannello di controllo, perché è un controllo separato da qualsiasi firewall in esecuzione sul server.

Funziona, ma è lento. Esegui tailscale netcheck su entrambe le macchine. Se indica che UDP è bloccato, i due dispositivi non possono creare un percorso diretto e usano un relay DERP, che aggiunge latenza a ogni connessione. Consentire il traffico UDP in ingresso sulla porta 41641 verso il VPS nel firewall di rete del provider ripristina generalmente il percorso diretto.

Quando non usare più il server di coordinamento di Tailscale

Tutto quanto descritto finora dipende dal server di coordinamento in hosting di Tailscale per lo scambio delle chiavi e per l'approvazione che hai selezionato. Il traffico continua a passare direttamente dal laptop al VPS e non transita mai dal server di coordinamento, che però stabilisce chi può entrare nella tailnet e quali risorse può raggiungere ogni dispositivo. Se vuoi eliminare proprio questa dipendenza, esegui Headscale come server di controllo Tailscale autonomo e configura entrambi i client affinché lo utilizzino. In seguito, i passaggi per il nodo di uscita restano gli stessi, ma l'approvazione della route viene eseguita tramite la riga di comando di Headscale invece che dalla console in hosting. Headscale sostituisce il control plane, ma consente di continuare a usare i client Tailscale; se invece preferisci gestire autonomamente l'intero stack, NetBird include un proprio server di coordinamento e client che puoi ospitare su un VPS.

FAQ

Perché il mio traffico continua a usare la connessione locale dopo avere selezionato il nodo di uscita?

Le cause comuni sono due. Il nodo di uscita è stato pubblicizzato, ma non è mai stato approvato: apri la pagina Machines nella console di amministrazione, individua il VPS, seleziona Edit route settings e attiva Use as exit node. L'approvazione è un'opzione della console; nessun comando eseguito sul server può attivarla. La seconda causa è diversa: l'inoltro IP è disattivato, quindi il tunnel viene stabilito, tailscale ping verso il VPS funziona, ma ogni indirizzo esterno va in timeout. Verifica con sysctl net.ipv4.ip_forward, che deve restituire 1.

Devo approvare manualmente il nodo di uscita ogni volta?

L'opzione va attivata una sola volta per ogni macchina. Se ricrei spesso il VPS, aggiungi un blocco autoApprovers al file delle policy della tailnet contenente "exitNode": ["tag:exit"], definisci tag:exit sotto tagOwners e avvia il nodo con --advertise-tags=tag:exit. Un dispositivo contrassegnato appartiene alla tailnet anziché al tuo account utente, quindi cambiano anche le regole di accesso applicate.

Quale server DNS usa il mio laptop quando è attivo un nodo di uscita?

Usa il nodo di uscita stesso. Un dispositivo che usa un nodo di uscita invia tutte le query DNS a quel nodo, sostituendo i nameserver DNS globali e split DNS configurati per la tailnet. In questo modo la rete locale non vede i nomi che cerchi. Per mantenere attivo un nameserver della tailnet, abilita l'opzione Use with exit node per quel nameserver nella pagina DNS della console di amministrazione. I nomi MagicDNS continuano a essere risolti, perché il client Tailscale risponde localmente su 100.100.100.100.

Un VPS può essere contemporaneamente un nodo di uscita e un router di sottorete?

Sì. sudo tailscale set --advertise-exit-node e sudo tailscale set --advertise-routes=10.0.0.0/24 sono indipendenti e ciascuno dispone di una propria opzione di approvazione in Edit route settings. L'inoltro IP deve essere attivo sul VPS per entrambe le funzioni. Evita di pubblicizzare un intervallo che corrisponde alla rete domestica del laptop, perché la route pubblicizzata è più specifica della route predefinita e i dispositivi locali diventano irraggiungibili.

Un nodo di uscita nasconde il mio traffico al provider del VPS?

No. Il tunnel termina sul VPS, quindi il traffico lascia il server nel formato richiesto dalla destinazione e il provider lo trasporta in chiaro nei casi in cui il sito stesso non usa la crittografia. Un nodo di uscita sposta il punto in cui il traffico entra in Internet: dalla rete a cui sei connesso al server che noleggi. Nasconde la tua navigazione al Wi-Fi del bar e al tuo ISP domestico, ma la mostra al provider del VPS associandola al nome del tuo account.