Corriger les erreurs apt d’installation de Tailscale

Pourquoi les erreurs d’installation de Tailscale sur Ubuntu sont des erreurs apt

Les erreurs d’installation de Tailscale sur Ubuntu surviennent presque toujours avant l’exécution du moindre code Tailscale. Ce sont des erreurs apt. Ubuntu ne fournit pas de package tailscale qui lui soit propre : après vérification de l’archive de packages Ubuntu en août 2026, les seuls résultats sont des bibliothèques auxiliaires Go et python3-tailscale. Le daemon doit donc provenir du dépôt apt de Tailscale, à l’adresse pkgs.tailscale.com.

L’ajout de ce dépôt écrit deux fichiers. Le premier indique à apt où se trouvent les packages. Le second contient la clé publique qu’apt utilise pour vérifier la signature de l’index du dépôt. Presque tous les problèmes ci-dessous viennent d’une erreur dans l’un de ces deux fichiers, ou du refus de la requête par un équipement situé entre apt et le dépôt.

Voici les commandes publiées par Tailscale pour 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 est le codename d’Ubuntu 24.04, et il apparaît dans les deux URL. La deuxième commande écrit une ligne de commentaire et une ligne deb dans /etc/apt/sources.list.d/tailscale.list, et cat affiche exactement le contenu qui y a été écrit.

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

Lisez la ligne deb comme une adresse composée de quatre champs : l’option entre crochets [signed-by=/usr/share/keyrings/tailscale-archive-keyring.gpg], puis la base du dépôt, qui est pkgs.tailscale.com/stable/ubuntu accessible via https, puis la suite noble, et enfin le composant main. apt combine la base et la suite pour former une URL, puis la récupère : https://pkgs.tailscale.com/stable/ubuntu/dists/noble/InRelease. Si vous pouvez récupérer cette URL manuellement, apt peut également la récupérer. C’est tout le diagnostic.

Lisez l’erreur apt avant de modifier quoi que ce soit

Exécutez la mise à jour seule afin qu’aucune autre sortie ne fasse défiler l’erreur hors de l’écran.

sudo apt update

Un dépôt tiers défaillant ressemble à ceci. Le nom de code et l’adresse IP seront différents sur votre machine.

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.

Deux éléments de cette sortie déterminent la suite : le code d’état et l’URL complète sur la ligne E: Failed to fetch. Ne déduisez pas la cause à partir de la ligne récapitulative en bas. Copiez l’URL et interrogez vous-même le serveur.

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

Cette commande affiche 200 pour un nom de code publié par Tailscale. Vérifié en août 2026, noble renvoie un index signé contenant Origin: Tailscale et Codename: noble. Remplacez noble par le nom de code indiqué dans votre propre erreur, puis exécutez à nouveau la commande. Si curl obtient 200 alors qu’apt a renvoyé une erreur, le dépôt fonctionne et le problème vient de la configuration d’apt elle-même.

Ce que le code d’état vous indique

• 404 Not Found signifie que le dépôt ne contient aucun fichier à cet emplacement. Sur pkgs.tailscale.com, il s’agit presque toujours du codename utilisé dans l’URL.
• 403 Forbidden signifie qu’un serveur a répondu et a refusé la requête. En août 2026, ce dépôt renvoie 404 lorsqu’il ne possède pas le chemin demandé. Un 403 indique donc la présence d’un proxy, d’un équipement de filtrage ou d’un firewall entre votre serveur et Tailscale.
• 401 Unauthorized ou 407 Proxy Authentication Required signifie qu’un proxy demande des identifiants qu’apt n’envoie pas.
• Une erreur de connexion ou de résolution de nom signifie qu’aucun échange HTTP n’a eu lieu. Passez directement à la section sur IPv6.

Le nom de code indiqué dans l’URL n’est pas publié par Tailscale

Tailscale crée un répertoire distinct pour chaque nom de code Ubuntu. Si vous demandez un nom de code absent, vous obtenez une erreur 404, car le serveur ne contient aucun répertoire dists/<codename> à servir. La liste publiée par le fournisseur sur pkgs.tailscale.com/stable indique ceux qui existent. En août 2026, elle va de 16.04 à resolute, qui correspond à Ubuntu 26.04.

Un nom de code incorrect provient généralement de l’exécution de lsb_release -cs sur une distribution basée sur Ubuntu, mais qui n’est pas Ubuntu. Sur Linux Mint 22, cette commande affiche wilma, le nom de code propre à Mint, pour lequel Tailscale ne publie aucun paquet. Consultez plutôt la base Ubuntu.

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

Sur Ubuntu, les deux valeurs sont identiques. Sur une distribution dérivée, VERSION_CODENAME est le nom de la distribution dérivée et UBUNTU_CODENAME est la version Ubuntu sur laquelle elle repose. Utilisez UBUNTU_CODENAME dans les deux URL.

La deuxième cause est une mise à niveau de la version. L’outil de mise à niveau Ubuntu désactive les sources tierces pendant son exécution. Après la mise à niveau d’Ubuntu 24.04 vers 26.04, vous constaterez donc que /etc/apt/sources.list.d/tailscale.list est commentée ou indique encore noble sur une machine qui utilise désormais resolute. Corrigez ce problème en réexécutant les deux commandes curl avec le nouveau nom de code. Elles écrasent les deux fichiers.

La troisième cause est le délai de publication. Dans les semaines qui suivent la sortie d’une nouvelle version Ubuntu, le nom de code existe chez Canonical avant d’exister chez Tailscale. En indiquant le nom de code de la LTS précédente dans le fichier, l’installation fonctionne généralement, car ces paquets ont peu de dépendances. Vous utilisez toutefois une build conçue pour une version plus ancienne. Vérifiez ce qui a réellement été installé avec apt policy tailscale, puis remplacez le nom de code par le bon dès qu’il apparaît.

Le trousseau de clés est vide et la commande qui l’a écrit n’a rien affiché

Ce cas est silencieux et explique la plupart des échecs de ce type. Reprenez la commande qui écrit le trousseau :

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

Le shell construit tout le pipeline avant l’exécution de l’un ou l’autre programme. Ainsi, sudo tee ouvre immédiatement le chemin du trousseau et le tronque à 0 octet. Si curl échoue, et -f le fait échouer pour toute erreur HTTP, curl n’écrit rien et se termine avec un code différent de 0. Le fichier reste vide. Le statut de sortie d’un pipeline est celui de sa dernière commande, ici tee, qui a réussi. Rien ne s’affiche et vous passez à la commande suivante en pensant que la clé est installée.

Vérifiez le fichier, pas la commande qui l’a créé.

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

Un trousseau valide affiche une ligne pub et une ligne uid qui identifie Tailscale. Un fichier de 0 octet affiche gpg: no valid OpenPGP data found. et rien d’autre. Un fichier qui contient une page d’erreur HTML affiche la même chose ; head -c 80 affiche alors le début d’une page web au lieu de données binaires de clé.

Avec un trousseau qui ne contient aucune clé utilisable, sudo apt update télécharge l’index, puis le refuse. Vous obtenez une ligne W: GPG error qui identifie le dépôt Tailscale et sa suite, le texte The following signatures couldn't be verified because the public key is not available: NO_PUBKEY suivi d’un identifiant de clé de 16 caractères, puis une erreur indiquant que le dépôt n’est pas signé. Notez ce que vous indique apt : il a téléchargé l’index correctement, mais n’a pas pu vérifier la signature. Le problème concerne la clé, pas le réseau. Si le fichier du trousseau est complètement absent, le message est encore différent et indique directement le chemin avec Could not open file /usr/share/keyrings/tailscale-archive-keyring.gpg.

Écrivez la clé en deux étapes afin qu’un téléchargement échoué ne puisse pas détruire un trousseau fonctionnel.

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 ligne du milieu est le contrôle décisif : si elle n’affiche pas un uid Tailscale, arrêtez-vous et ne copiez pas le fichier. Le mode 0644 est important, car apt utilise l’utilisateur non privilégié _apt pour télécharger et vérifier la clé. Un trousseau que seul root peut lire est inutilisable par apt.

Les fichiers .list et .sources décrivent le même dépôt

Ubuntu a converti ses propres sources au format deb822 dans Ubuntu 24.10, où /etc/apt/sources.list est devenu /etc/apt/sources.list.d/ubuntu.sources. Tailscale publie toujours le format sur une seule ligne. Vérifié en août 2026, aucun fichier .sources n’est disponible au téléchargement depuis pkgs.tailscale.com : cette URL renvoie 404. Donc, si votre machine contient un fichier tailscale.sources, vous ou un guide l’avez créé manuellement. Si tailscale.list est également toujours présent, apt décrit maintenant le même dépôt deux fois.

Le cas le moins grave produit un avertissement à chaque mise à jour :

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

Le cas grave se produit lorsque les deux fichiers indiquent des chemins de keyring différents, car apt ne peut pas déterminer quelle clé contrôle le dépôt. Il affiche E: Conflicting values set for option Signed-By regarding source, puis le dépôt et sa suite, puis les deux chemins de keyring séparés par !=, avant de refuser de continuer :

E: The list of sources could not be read.

Cette erreur bloque toutes les commandes apt, et pas uniquement la mise à jour, jusqu’à la suppression de l’un des fichiers. Le même problème peut se produire avec les propres dépôts d’Ubuntu. L’erreur de source apt dupliquée après une migration vers deb822 présente le cas général.

Recherchez tous les fichiers qui mentionnent Tailscale avant d’en supprimer un.

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

Conservez un seul fichier. Pour désactiver l’autre sans le supprimer, renommez-le : apt ne lit que les fichiers se terminant par .list ou .sources. Le fichier tailscale.list.bak est donc ignoré et reste sur le disque à titre de référence.

Rédiger correctement le fichier de sources au format deb822

Si vous préférez le format plus récent, convertissez le fichier existant au lieu de retaper l’adresse du dépôt, car une faute de frappe à cet endroit est précisément à l’origine des erreurs ci-dessus. Les versions récentes d’apt intègrent un convertisseur qui réécrit les fichiers .list en stanzas deb822 et reporte l’option signed-by sous la forme Signed-By.

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

Ubuntu 24.04 fournit une version d’apt antérieure à cette sous-commande. La ligne d’aide vous indique donc immédiatement si la vôtre la prend en charge. Si ce n’est pas le cas, construisez la stanza à partir de la ligne déjà présente sur le disque. La base provient ainsi du fichier du fournisseur, et non de votre saisie.

. /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

Cette commande affiche la stanza qu’elle a écrite. Vous pouvez donc relire les champs avant le prochain apt update. Quatre champs méritent une explication détaillée, car chacun échoue d’une manière différente :

• URIs s’arrête à la base du dépôt. Si vous y collez la partie dists/noble, apt renvoie une erreur 404, car apt ajoute lui-même dists/<suite> et demande dists/noble/dists/noble.
• Suites est le codename, c’est-à-dire exactement la valeur qui figurait au milieu du format sur une seule ligne.
• Signed-By prend le chemin absolu d’un fichier de keyring. Il accepte également une clé au format armored directement sous ce champ. Chaque ligne de la clé doit alors être indentée d’une espace, et chaque ligne vide à l’intérieur de la clé doit être écrite sous la forme d’un point unique.
• Enabled: no désactive une source sans la supprimer. Cette méthode est plus facile à annuler qu’un changement de nom et à expliquer à la personne qui reprendra la maintenance.

Conservez une stanza par fichier pour les dépôts tiers. Si vous regroupez plusieurs stanzas dans un même fichier, séparez-les par une ligne vide. L’index du dépôt liste amd64 et arm64 parmi ses architectures. Un VPS ARM n’a donc besoin d’aucun champ Architectures supplémentaire.

Un proxy intermédiaire renvoie 403

Comme ce dépôt renvoie 404 lorsqu’un chemin n’existe pas, un code 403 signifie qu’un autre composant a répondu à sa place. Commencez par la configuration propre à apt, car un proxy défini à cet endroit s’applique à apt, mais pas à votre commande curl interactive.

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

Observez ensuite ce qu’apt envoie réellement.

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

Cette commande affiche la ligne de requête, les en-têtes envoyés par apt et, le cas échéant, le proxy utilisé pour la connexion. Comparez le résultat avec une commande curl simple vers la même URL. Si curl renvoie 200 et apt renvoie 403, les deux requêtes diffèrent sur un élément pris en compte par le middlebox. Le user agent est le candidat le plus fréquent :

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

Si cette commande renvoie 403 alors que curl renvoie 200 par défaut, un équipement de filtrage refuse apt en fonction de son nom. La correction doit être appliquée sur cet équipement, et non sur votre serveur. Un proxy d’entreprise qui inspecte TLS se comporte autrement : apt signale un échec de vérification du certificat au lieu d’un code d’état, car le certificat reçu a été émis par le proxy et non par l’autorité de certification de Tailscale. Un firewall cloud de sortie qui autorise uniquement les miroirs Ubuntu est l’autre cause fréquente. Dans ce cas, autorisez pkgs.tailscale.com sur le firewall.

Egress IPv6 uniquement et erreurs qui ne sont pas des codes d’état

Si apt n’a jamais reçu de réponse HTTP, testez chaque protocole séparément.

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

Lorsque IPv4 répond mais qu’IPv6 se bloque ou renvoie Network is unreachable, apt échoue parce que la bibliothèque de résolution privilégie IPv6 et que le serveur ne dispose d’aucun chemin IPv6 fonctionnel. Forcez une exécution sur IPv4 pour confirmer cette hypothèse :

sudo apt -o Acquire::ForceIPv4=true update

Si cette mise à jour réussit, rendez le réglage permanent.

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

Tenez compte également du cas inverse. Sur un VPS qui n’a aucune adresse IPv4, forcer IPv4 ne résout rien, car aucune route IPv4 ne permet d’y faire passer le trafic. Vous avez alors besoin de NAT64 avec DNS64 fourni par votre fournisseur, ou d’un proxy disposant d’une adresse IPv4. Le symptôme est une erreur de connexion qui mentionne une adresse IPv6 ; la ligne curl -6 est donc celle qui indique la cause réelle.

Les solutions de repli et le coût de chacune

Le script d’installation du fournisseur. curl -fsSL https://tailscale.com/install.sh | sh est la commande recommandée par Tailscale. En lisant le script, on constate qu’il détecte votre distribution à partir de /etc/os-release, puis écrit les deux mêmes chemins que ce guide corrige, /usr/share/keyrings/tailscale-archive-keyring.gpg et /etc/apt/sources.list.d/tailscale.list, à partir des mêmes URL. Cela définit clairement ce que vous pouvez en attendre : le script ne contourne pas un dépôt bloqué par un proxy. Il échoue de la même manière, avec moins de sortie. Transmettre un script téléchargé à un shell avec les privilèges de root est un compromis, pas une solution, car vous faites confiance à ce que le serveur renvoie à cet instant et vous ne conservez aucune copie de ce qui a été exécuté. Si vous acceptez ce compromis, faites-le en connaissance de cause :

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

Les binaires statiques. Le même serveur publie des tarballs simples dans la section des binaires statiques de pkgs.tailscale.com/stable. En août 2026, la version stable est 1.102.2 et le fichier x86 64 bits est tailscale_1.102.2_amd64.tgz. Vous placez vous-même le client tailscale et le daemon tailscaled, et vous supervisez vous-même le daemon. Il n’existe donc aucun chemin apt upgrade, et chaque mise à jour future devra être téléchargée manuellement. Cette solution est pertinente sur un hôte isolé du réseau, ou lorsque vous devez verrouiller une version précise.

Le paquet fourni par Ubuntu. Il n’existe pas. L’exécution de sudo apt install tailscale sans avoir configuré le dépôt du fournisseur se termine par E: Unable to locate package tailscale, et aucun réglage de apt update ne change cela. Si vous cherchez en réalité un serveur de coordination que vous contrôlez plutôt que celui hébergé par Tailscale, il s’agit d’une décision distincte : exécuter Headscale comme votre propre serveur de contrôle l’explique, et la comparaison entre Tailscale et WireGuard simple indique si vous avez besoin de toute cette infrastructure.

Le paquet est installé, mais tailscaled ne démarre pas

Une fois qu’apt fonctionne correctement, les erreurs concernent le daemon.

systemctl status tailscaled
sudo journalctl -u tailscaled -n 50

Sur un VPS utilisant une virtualisation par conteneurs qui partage le kernel de l’hôte, comme LXC ou OpenVZ, le journal contient une ligne indiquant que /dev/net/tun n’existe pas. Le daemon a besoin d’un périphérique TUN pour créer l’interface tailscale0, mais aucun périphérique ne lui a été attribué dans le conteneur. Demandez à votre fournisseur d’activer TUN dans le conteneur, ou passez à une offre KVM avec votre propre kernel. Avec KVM, cette configuration fonctionne sans réglage supplémentaire.

Ensuite, sudo tailscale up affiche une URL de connexion, et tailscale status doit répertorier votre machine avec une adresse dans la plage 100.64.0.0/10. Une machine qui apparaît à cet endroit peut servir de base, que ce soit pour annoncer un sous-réseau privé depuis votre VPS ou pour utiliser le VPS comme exit node.

FAQ

Pourquoi apt indique-t-il que le dépôt Tailscale n’est pas signé ?

Parce qu’apt a téléchargé l’index du dépôt, mais n’a pas pu vérifier sa signature avec /usr/share/keyrings/tailscale-archive-keyring.gpg. La cause habituelle est que le keyring est vide : sudo tee a tronqué le fichier avant que curl échoue à télécharger quoi que ce soit, et le pipeline a signalé une réussite parce que tee a réussi. Exécutez gpg --show-keys /usr/share/keyrings/tailscale-archive-keyring.gpg. Un keyring fonctionnel affiche une ligne pub et une ligne uid qui nomme Tailscale. Un keyring vide ou corrompu affiche gpg: no valid OpenPGP data found.. Téléchargez la clé dans un fichier temporaire, vérifiez-la à cet endroit, puis copiez-la au bon emplacement avec le mode 0644 afin que l’utilisateur _apt puisse la lire.

Quel nom de version Ubuntu dois-je utiliser dans les URL Tailscale ?

Utilisez la valeur de UBUNTU_CODENAME obtenue avec /etc/os-release. Il s’agit de noble sur Ubuntu 24.04 et de resolute sur Ubuntu 26.04. N’utilisez pas lsb_release -cs sur une distribution dérivée d’Ubuntu : sur Linux Mint 22, cette commande affiche wilma, Tailscale ne publie rien sous ce nom et apt renvoie une erreur 404 sur dists/wilma/InRelease. Confirmez votre choix avant toute modification en récupérant manuellement l’index avec curl -sS -o /dev/null -w '%{http_code}\n' vers https://pkgs.tailscale.com/stable/ubuntu/dists/<codename>/InRelease.

Est-il sûr d’exécuter le script d’installation Tailscale transmis à un shell ?

C’est un compromis à accepter délibérément. Le script provient de Tailscale et effectue les mêmes opérations que les étapes manuelles : il lit /etc/os-release, écrit le même keyring et le même /etc/apt/sources.list.d/tailscale.list, puis installe le paquet. En contrepartie, vous exécutez avec root ce que le serveur renvoie à cet instant, sans en conserver une copie. Téléchargez-le avec -o install.sh, lisez-le, puis exécutez-le si vous voulez cette simplicité sans perdre la visibilité sur son contenu. Le script ne peut pas non plus résoudre un dépôt bloqué, car il utilise les mêmes URL que celles qui ont déjà échoué.

Comment installer Tailscale sur Ubuntu sans le dépôt apt ?

Utilisez les archives tar statiques publiées sur pkgs.tailscale.com. En août 2026, elles sont disponibles en version 1.102.2, avec un fichier amd64 nommé tailscale_1.102.2_amd64.tgz. Vous installez vous-même les programmes tailscale et tailscaled, puis vous exécutez vous-même le daemon sous systemd. La contrepartie concerne les mises à niveau : aucun paquet apt ne permet de récupérer une nouvelle version, donc chaque mise à jour est manuelle. L’archive Ubuntu ne contient aucun paquet tailscale propre à cette distribution. Par conséquent, sudo apt install tailscale sur une machine dépourvue du dépôt du fournisseur s’arrête à E: Unable to locate package tailscale.