Risolvere gli errori apt installando Tailscale su Ubuntu

Perché gli errori di installazione di Tailscale su Ubuntu sono errori di apt

Gli errori di installazione di Tailscale su Ubuntu si verificano quasi sempre prima dell'esecuzione di qualsiasi codice di Tailscale. Sono errori di apt. Ubuntu non include un pacchetto tailscale proprio: verificando l'archivio dei pacchetti Ubuntu ad agosto 2026, le uniche corrispondenze sono librerie helper Go e python3-tailscale. Per questo il daemon deve provenire dal repository apt di Tailscale all'indirizzo pkgs.tailscale.com.

L'aggiunta del repository scrive due file. Un file indica ad apt dove si trovano i pacchetti. L'altro contiene la chiave pubblica che apt usa per verificare la firma dell'indice del repository. Quasi tutti gli errori descritti di seguito dipendono da uno di questi due file configurato in modo errato oppure da un dispositivo tra apt e il repository che rifiuta la richiesta.

Questi sono i comandi pubblicati da Tailscale per Ubuntu 24.04:

sudo mkdir -p --mode=0755 /usr/share/keyrings
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.noarmor.gpg | sudo tee /usr/share/keyrings/tailscale-archive-keyring.gpg >/dev/null
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.tailscale-keyring.list | sudo tee /etc/apt/sources.list.d/tailscale.list
sudo apt-get update && sudo apt-get install tailscale

noble è il codename di Ubuntu 24.04 e compare in entrambi gli URL. Il secondo comando scrive una riga di commento e una riga deb in /etc/apt/sources.list.d/tailscale.list, mentre cat mostra esattamente il contenuto scritto.

cat /etc/apt/sources.list.d/tailscale.list

Interpreta la riga deb come un indirizzo composto da quattro campi: l'opzione tra parentesi quadre [signed-by=/usr/share/keyrings/tailscale-archive-keyring.gpg], quindi la base del repository, ossia pkgs.tailscale.com/stable/ubuntu raggiunta tramite https, poi la suite noble e infine il componente main. apt combina la base e la suite in un unico URL e lo recupera: https://pkgs.tailscale.com/stable/ubuntu/dists/noble/InRelease. Se puoi recuperare manualmente quell'URL, anche apt può farlo. Questa è l'intera diagnosi.

Leggi l'errore di apt prima di modificare qualsiasi cosa

Esegui l'aggiornamento separatamente, così nessun altro output fa scorrere via l'errore.

sudo apt update

Un repository di terze parti non raggiungibile appare in questo modo. Il nome in codice e l'indirizzo IP saranno diversi sul tuo computer.

E: Failed to fetch https://pkgs.tailscale.com/stable/ubuntu/dists/wilma/InRelease  404  Not Found [IP: 203.0.113.9 443]
E: Some index files failed to download. They have been ignored, or old ones used instead.

Nell'output, due elementi determinano la procedura successiva: il codice di stato e l'URL completo nella riga E: Failed to fetch. Non dedurre la causa dalla riga riepilogativa in fondo. Copia l'URL e interrogalo direttamente sul server.

curl -sS -o /dev/null -w '%{http_code}\n' https://pkgs.tailscale.com/stable/ubuntu/dists/noble/InRelease

Il comando restituisce 200 per un nome in codice pubblicato da Tailscale. Verificato ad agosto 2026, noble restituisce un indice firmato che contiene Origin: Tailscale e Codename: noble. Sostituisci noble con il nome in codice riportato nel tuo errore ed esegui di nuovo il comando. Se curl restituisce 200 mentre apt ha restituito un errore, il repository funziona e il problema riguarda la configurazione interna di apt.

Cosa indica il codice di stato

• 404 Not Found indica che il repository non contiene alcun file nel percorso specificato. Su pkgs.tailscale.com questo corrisponde quasi sempre al codename incluso nell’URL.
• 403 Forbidden indica che un componente ha risposto rifiutando la richiesta. Ad agosto 2026 questo repository restituisce 404 per un percorso inesistente. Pertanto, un 403 indica la presenza di un proxy, di un apparato di filtraggio o di un firewall tra il server e Tailscale.
• 401 Unauthorized o 407 Proxy Authentication Required indica che un proxy richiede credenziali che apt non sta inviando.
• Un errore di connessione o di risoluzione del nome indica che non è avvenuta alcuna comunicazione HTTP. Passare alla sezione IPv6.

Il nome in codice nell’URL non è pubblicato da Tailscale

Tailscale crea una directory separata per ogni nome in codice di Ubuntu. Se si richiede un nome in codice che non esiste, il server restituisce 404 perché sul server non esiste dists/<codename> da servire. L’elenco ufficiale del fornitore, disponibile in pkgs.tailscale.com/stable, mostra quali nomi in codice sono disponibili. Ad agosto 2026 l’elenco va dalla versione 16.04 fino a resolute, che corrisponde a Ubuntu 26.04.

Il modo più comune in cui viene inserito un nome in codice errato è eseguire lsb_release -cs su una distribuzione basata su Ubuntu, ma non coincidente con Ubuntu. Su Linux Mint 22, il comando restituisce wilma, cioè il nome in codice specifico di Mint, per il quale Tailscale non pubblica alcun pacchetto. È necessario rilevare invece la base Ubuntu.

. /etc/os-release
echo "$VERSION_CODENAME $UBUNTU_CODENAME"

Su Ubuntu, i due valori coincidono. Su una distribuzione derivata, VERSION_CODENAME è il nome della distribuzione derivata e UBUNTU_CODENAME è la release Ubuntu su cui è basata. Usare UBUNTU_CODENAME in entrambi gli URL.

Il secondo caso è un aggiornamento della release. Lo strumento di aggiornamento di Ubuntu disabilita le sorgenti di terze parti durante l'esecuzione. Dopo l'aggiornamento di Ubuntu 24.04 a 26.04, quindi, /etc/apt/sources.list.d/tailscale.list può risultare commentato oppure può indicare ancora noble su un sistema che ora esegue resolute. Correggere il problema eseguendo nuovamente i due comandi curl con il nuovo nome in codice. I comandi sovrascrivono entrambi i file.

Il terzo caso è legato alla tempistica. Nelle settimane successive al rilascio di una nuova versione di Ubuntu, il nome in codice può essere già disponibile presso Canonical ma non ancora presso Tailscale. Impostare nel file il nome in codice della LTS precedente normalmente consente l'installazione, perché questi pacchetti hanno poche dipendenze, ma in questo modo si esegue una build creata per una release precedente. Verificare che cosa è stato effettivamente installato con apt policy tailscale e ripristinare nel file il nome in codice corretto non appena diventa disponibile.

Il keyring è vuoto e il comando che lo ha scritto non ha prodotto alcun messaggio

Questo caso è silenzioso ed è il punto in cui termina la maggior parte di questi problemi. Esamina di nuovo il comando del keyring:

curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.noarmor.gpg | sudo tee /usr/share/keyrings/tailscale-archive-keyring.gpg >/dev/null

La shell costruisce l'intera pipeline prima di avviare uno dei due programmi, quindi sudo tee apre il percorso del keyring e lo tronca immediatamente a zero byte. Se curl non riesce, e -f fa sì che fallisca in caso di qualsiasi errore HTTP, curl non scrive nulla e termina con un codice diverso da zero. Il file rimane vuoto. Il codice di uscita di una pipeline è quello dell'ultimo comando, cioè tee, che è terminato correttamente. Non viene visualizzato nulla e si passa al comando successivo credendo che la chiave sia stata installata.

Controlla il file, non il comando che lo ha creato.

ls -l /usr/share/keyrings/tailscale-archive-keyring.gpg
gpg --show-keys /usr/share/keyrings/tailscale-archive-keyring.gpg

Un keyring integro stampa una riga pub e una riga uid che identifica Tailscale. Un file di zero byte stampa gpg: no valid OpenPGP data found. e nient'altro. Un file che contiene una pagina di errore HTML produce lo stesso risultato, mentre head -c 80 mostra l'inizio di una pagina web invece dei dati binari della chiave.

Con un keyring che non contiene alcuna chiave utilizzabile, sudo apt update scarica l'indice e poi lo rifiuta. Viene visualizzata una riga W: GPG error che identifica il repository Tailscale e la relativa suite, il testo The following signatures couldn't be verified because the public key is not available: NO_PUBKEY seguito da un key id di 16 caratteri e, sotto, un errore che indica che il repository non è firmato. Nota cosa sta comunicando apt: ha scaricato correttamente l'indice, ma non è riuscito a verificarne la firma. È un problema della chiave, non della rete. Se il file del keyring manca del tutto, il messaggio è ancora diverso e indica direttamente il percorso con Could not open file /usr/share/keyrings/tailscale-archive-keyring.gpg.

Scrivi la chiave in due passaggi, in modo che un download non riuscito non possa distruggere un keyring funzionante.

curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.noarmor.gpg -o /tmp/tailscale.gpg
gpg --show-keys /tmp/tailscale.gpg
sudo install -m 0644 -o root -g root /tmp/tailscale.gpg /usr/share/keyrings/tailscale-archive-keyring.gpg

La riga centrale è il controllo decisivo: se non stampa un uid di Tailscale, fermati e non copiare il file. La modalità 0644 è importante perché apt passa all'utente non privilegiato _apt per scaricare e verificare il file; di conseguenza, un keyring leggibile soltanto da root è un keyring che apt non può utilizzare.

Sia un file .list sia un file .sources descrivono lo stesso repository

Ubuntu ha spostato le proprie sorgenti nel formato deb822 in Ubuntu 24.10, quando /etc/apt/sources.list è diventato /etc/apt/sources.list.d/ubuntu.sources. Tailscale pubblica ancora il formato su una sola riga. Verificato ad agosto 2026, non esiste alcun file .sources da scaricare da pkgs.tailscale.com: l’URL restituisce 404. Quindi, se sul computer è presente un tailscale.sources, lo hai creato tu oppure lo ha creato manualmente una guida; se è ancora presente anche tailscale.list, apt ora descrive lo stesso repository due volte.

Il caso meno grave genera un avviso a ogni aggiornamento:

W: Target Packages (main/binary-amd64/Packages) is configured multiple times in /etc/apt/sources.list.d/tailscale.list:1 and /etc/apt/sources.list.d/tailscale.sources:1

Il caso più grave si verifica quando i due file indicano percorsi diversi per il keyring, perché apt non riesce a determinare quale chiave gestisca il repository. Stampa E: Conflicting values set for option Signed-By regarding source, quindi il repository e la relativa suite, poi i due percorsi dei keyring separati da != e infine interrompe l’operazione:

E: The list of sources could not be read.

Questo blocca ogni comando apt, non solo l’aggiornamento, finché uno dei due file non viene rimosso. Lo stesso errore si verifica con i repository di Ubuntu; l’errore relativo a una sorgente apt duplicata dopo una migrazione a deb822 descrive il caso generale.

Prima di eliminare qualsiasi file, individua tutti i file che contengono riferimenti a Tailscale.

grep -RIn tailscale /etc/apt/sources.list /etc/apt/sources.list.d/

Conserva un solo file. Per disabilitare l’altro senza perderlo, rinominalo: apt legge soltanto i file che terminano con .list o .sources, quindi tailscale.list.bak viene ignorato e resta sul disco come riferimento.

Scrivere correttamente il file delle sorgenti in formato deb822

Se preferisci il formato più recente, converti il file che hai già invece di riscrivere l'indirizzo del repository. Un errore di battitura in quell'indirizzo è infatti proprio il modo in cui iniziano gli errori descritti sopra. Le versioni recenti di apt includono un convertitore che riscrive i file .list in blocchi deb822 e trasferisce l'opzione signed-by nel campo Signed-By.

apt modernize-sources --help
sudo apt modernize-sources

Ubuntu 24.04 include una versione di apt precedente all'introduzione di questo sottocomando. La riga della guida mostra quindi immediatamente se la tua versione lo supporta. Se non lo supporta, crea il blocco a partire dalla riga già presente sul disco, così la base viene ricavata dal file del fornitore e non dalla digitazione manuale.

. /etc/os-release
{
  echo 'Types: deb'
  echo "URIs: $(awk '/^deb /{print $3}' /etc/apt/sources.list.d/tailscale.list)"
  echo "Suites: $UBUNTU_CODENAME"
  echo 'Components: main'
  echo 'Signed-By: /usr/share/keyrings/tailscale-archive-keyring.gpg'
} | sudo tee /etc/apt/sources.list.d/tailscale.sources
sudo rm /etc/apt/sources.list.d/tailscale.list

Il comando stampa il blocco che ha scritto, quindi puoi rileggere i campi prima del prossimo apt update. Quattro campi meritano particolare attenzione, perché ciascuno può causare un errore diverso:

• URIs si ferma alla base del repository. Se vi incolli la parte dists/noble, apt restituisce un errore 404, perché aggiunge autonomamente dists/<suite> e richiede dists/noble/dists/noble.
• Suites è il codename, cioè esattamente il valore che compariva al centro del formato a riga singola.
• Signed-By accetta il percorso assoluto di un file keyring. Accetta anche una chiave in formato armored inserita direttamente sotto il campo; in questo caso ogni riga della chiave deve essere indentata di uno spazio e ogni riga vuota interna deve essere rappresentata da un singolo punto.
• Enabled: no disabilita una sorgente senza eliminarla. È quindi più semplice da ripristinare rispetto alla modifica del nome del file e più facile da spiegare alla persona che gestirà il sistema in seguito.

Mantieni un solo blocco per file per i repository di terze parti e, se raccogli più blocchi nello stesso file, inserisci una riga vuota tra un blocco e l'altro. L'indice del repository elenca amd64 e arm64 tra le architetture supportate, quindi una VPS ARM non richiede alcun campo Architectures aggiuntivo.

Un proxy intermedio restituisce 403

Poiché un percorso che non esiste in questo repository restituisce 404, un 403 indica che qualcosa ha risposto al suo posto. Inizia dalla configurazione di apt, perché un proxy impostato in quel punto si applica ad apt, ma non al tuo comando curl interattivo.

grep -RIn -i proxy /etc/apt/apt.conf.d/ /etc/apt/apt.conf
sudo apt-config dump | grep -i 'acquire::http'

Quindi controlla cosa invia effettivamente apt.

sudo apt -o Debug::Acquire::http=1 update

Questo comando stampa la riga della richiesta, gli header inviati da apt e, se presente, il proxy attraverso cui si è connesso. Confronta il risultato con un comando curl diretto verso lo stesso URL. Se curl restituisce 200 e apt restituisce 403, le due richieste differiscono in un elemento che il dispositivo intermedio considera rilevante. Il candidato più comune è lo user agent:

curl -sS -o /dev/null -w '%{http_code}\n' -A 'Debian APT-HTTP/1.3' https://pkgs.tailscale.com/stable/ubuntu/dists/noble/InRelease

Se questo comando restituisce 403 mentre curl, con lo user agent predefinito, restituisce 200, un dispositivo di filtraggio rifiuta apt in base al nome. La correzione va applicata su quel dispositivo, non sul server. Un proxy aziendale che ispeziona TLS si comporta diversamente: apt segnala un errore di verifica del certificato invece di un codice di stato, perché il certificato ricevuto è stato emesso dal proxy e non dall'autorità di certificazione di Tailscale. Un firewall cloud per il traffico in uscita che consente soltanto i mirror Ubuntu è l'altra causa comune. In questo caso, la correzione consiste nel consentire pkgs.tailscale.com nel firewall.

Uscita solo IPv6 e errori che non sono codici di stato

Se apt non ha mai ricevuto una risposta HTTP, verifica separatamente ogni protocollo.

curl -4 -sS -o /dev/null -w 'v4 %{http_code}\n' https://pkgs.tailscale.com/stable/ubuntu/dists/noble/InRelease
curl -6 -sS -o /dev/null -w 'v6 %{http_code}\n' https://pkgs.tailscale.com/stable/ubuntu/dists/noble/InRelease

Quando IPv4 risponde e IPv6 resta in attesa o restituisce Network is unreachable, apt non funziona perché la libreria del resolver preferisce IPv6, ma il server non dispone di un percorso IPv6 operativo. Forza una singola esecuzione su IPv4 per verificare questa ipotesi:

sudo apt -o Acquire::ForceIPv4=true update

Se l'aggiornamento riesce, rendi permanente la modifica.

echo 'Acquire::ForceIPv4 "true";' | sudo tee /etc/apt/apt.conf.d/99force-ipv4

Considera anche il caso opposto. Su un VPS che non dispone affatto di un indirizzo IPv4, forzare IPv4 non risolve il problema, perché non esiste alcuna route IPv4 su cui instradare il traffico. In questo caso servono NAT64 con DNS64 forniti dal provider oppure un proxy che disponga di un indirizzo IPv4. Il sintomo è un errore di connessione che indica un indirizzo IPv6; per questo la riga curl -6 è quella che mostra la causa effettiva.

I fallback e relativo costo

Lo script di installazione del produttore. curl -fsSL https://tailscale.com/install.sh | sh è il comando promosso da Tailscale. Dallo script si vede che rileva la distribuzione tramite /etc/os-release e quindi scrive gli stessi due percorsi che questa guida ha corretto, /usr/share/keyrings/tailscale-archive-keyring.gpg e /etc/apt/sources.list.d/tailscale.list, usando gli stessi URL. Questo è importante per definire le aspettative: lo script non aggira un repository bloccato da un proxy. Fallisce nello stesso modo, mostrando meno output. Inviare uno script scaricato a una shell eseguita come root è un compromesso, non una soluzione, perché ci si fida di ciò che il server restituisce in quel momento e non si conserva una copia di quanto è stato eseguito. Se si accetta questo compromesso, lo si faccia in modo consapevole:

curl -fsSL https://tailscale.com/install.sh -o install.sh
less install.sh
sh install.sh

I binari statici. Lo stesso server pubblica archivi tarball semplici nella sezione dei binari statici di pkgs.tailscale.com/stable. Ad agosto 2026 la release stabile è 1.102.2 e il file x86 a 64 bit è tailscale_1.102.2_amd64.tgz. Si installano manualmente il client tailscale e il demone tailscaled, e si supervisiona manualmente il demone; non esiste quindi alcun percorso apt upgrade e ogni aggiornamento futuro richiede un download eseguito manualmente. Questa opzione è adatta a un host isolato dalla rete oppure quando è necessario bloccare una versione esatta.

Il pacchetto fornito da Ubuntu. Non esiste. L'esecuzione di sudo apt install tailscale senza avere configurato il repository del produttore termina con E: Unable to locate package tailscale, e nessuna quantità di apt update può cambiare questo comportamento. Se ciò che si vuole realmente è un server di coordinamento sotto il proprio controllo, anziché quello ospitato da Tailscale, si tratta di una decisione separata: eseguire Headscale come server di controllo personale spiega come fare, mentre il confronto tra Tailscale e WireGuard semplice chiarisce se sia necessaria tutta questa infrastruttura.

Il pacchetto è installato, ma tailscaled non si avvia

Quando apt non segnala più problemi, gli errori si spostano sul daemon.

systemctl status tailscaled
sudo journalctl -u tailscaled -n 50

Su un VPS che usa la virtualizzazione a container e condivide il kernel dell'host, come LXC o OpenVZ, il log contiene una riga relativa all'assenza di /dev/net/tun. Il daemon richiede un dispositivo TUN per creare l'interfaccia tailscale0, ma al container non ne è stato assegnato uno. Chiedi al provider di abilitare TUN sul container oppure passa a un piano KVM, che fornisce un kernel dedicato. Su KVM questa configurazione funziona senza ulteriori interventi.

Dopo questa modifica, sudo tailscale up stampa un URL di accesso e tailscale status dovrebbe elencare la macchina con un indirizzo nell'intervallo 100.64.0.0/10. Una macchina visualizzata in questo elenco è pronta per essere utilizzata, ad esempio per pubblicizzare una subnet privata dal VPS oppure usare il VPS come exit node.

FAQ

Perché apt indica che il repository di Tailscale non è firmato?

apt ha scaricato l'indice del repository, ma non ha potuto verificarne la firma rispetto a /usr/share/keyrings/tailscale-archive-keyring.gpg. La causa abituale è un keyring di dimensione zero: sudo tee ha troncato il file prima che curl riuscisse a scaricare il contenuto e la pipeline ha segnalato il successo perché tee è terminato correttamente. Eseguire gpg --show-keys /usr/share/keyrings/tailscale-archive-keyring.gpg. Un keyring funzionante stampa una riga pub e una riga uid con il nome Tailscale, mentre un keyring vuoto o danneggiato stampa gpg: no valid OpenPGP data found.. Scaricare la chiave in un file temporaneo, verificarla in quella posizione, quindi copiarla nella posizione definitiva con modalità 0644, in modo che l'utente _apt possa leggerla.

Quale codename Ubuntu devo inserire negli URL di Tailscale?

Usare il valore di UBUNTU_CODENAME ricavato da /etc/os-release, che è noble su Ubuntu 24.04 e resolute su Ubuntu 26.04. Non usare lsb_release -cs su una distribuzione derivata da Ubuntu: su Linux Mint 22 stampa wilma, Tailscale non pubblica nulla con quel nome e apt restituisce 404 su dists/wilma/InRelease. Confermare la scelta prima di modificare qualsiasi file, scaricando manualmente l'indice con curl -sS -o /dev/null -w '%{http_code}\n' verso https://pkgs.tailscale.com/stable/ubuntu/dists/<codename>/InRelease.

È sicuro eseguire lo script di installazione di Tailscale tramite una shell?

È una scelta che va valutata consapevolmente. Lo script proviene da Tailscale ed esegue le stesse operazioni dei passaggi manuali: legge /etc/os-release, scrive lo stesso keyring e lo stesso /etc/apt/sources.list.d/tailscale.list, quindi installa il pacchetto. Il rischio è eseguire con root tutto ciò che il server restituisce in quel momento, senza conservarne una copia. Scaricarlo con -o install.sh, leggerlo e quindi eseguirlo se si desidera la comodità senza rinunciare alla possibilità di esaminarlo. Lo script non può inoltre risolvere un repository bloccato, perché usa gli stessi URL che hanno già restituito un errore.

Come installo Tailscale su Ubuntu senza il repository apt?

Usare gli archivi tar statici pubblicati su pkgs.tailscale.com, che ad agosto 2026 sono alla versione 1.102.2 e includono un file amd64 denominato tailscale_1.102.2_amd64.tgz. Installare manualmente i programmi tailscale e tailscaled ed eseguire manualmente il daemon tramite systemd. Il limite riguarda gli aggiornamenti: non è disponibile un pacchetto apt da cui ottenere la nuova versione, quindi ogni aggiornamento deve essere eseguito manualmente. L'archivio Ubuntu non contiene un pacchetto tailscale proprio, quindi sudo apt install tailscale su una macchina senza il repository del fornitore si arresta a E: Unable to locate package tailscale.