Arrêter ou supprimer Tailscale sans perdre l'accès

Arrêter ou supprimer Tailscale : les quatre opérations à distinguer

Arrêter Tailscale sur un serveur, ce n'est pas une opération mais quatre, et elles ne laissent pas la même trace. tailscale down coupe la connexion au tailnet en gardant le démon et l'enregistrement de la machine. tailscale logout rend la clé du nœud, donc la machine devra se réauthentifier avant de revenir. systemctl disable --now tailscaled arrête le démon et l'empêche de repartir au démarrage suivant. apt-get remove tailscale retire le paquet, et ne retire rien du tout dans la console d'administration.

Le vrai danger n'est aucune de ces commandes prise isolément. Le vrai danger, c'est que Tailscale soit votre seul chemin vers le serveur. Si vous avez enrôlé la machine avec tailscale up --ssh, votre session SSH passe par le tunnel, et la première commande de cette liste la ferme sous vos pieds.

Beaucoup de lecteurs sont dans ce cas sans l'avoir choisi. Derrière une box grand public ou un abonnement mobile en CGNAT (carrier grade NAT, la traduction d'adresses faite par le fournisseur), aucune machine de la maison n'a d'adresse publique joignable. Le VPS devient le seul point d'entrée public de l'installation, et le tunnel est souvent le seul chemin vers lui. C'est pour cette raison que ce guide commence par le retour, et pas par la désinstallation.

Vérifiez une voie de retour avant de taper quoi que ce soit

Une voie de retour, c'est un chemin vers le serveur qui ne passe pas par Tailscale. Elle doit être ouverte et testée avant la première commande, pas après.

• La console du fournisseur : accès VNC ou console série depuis le panneau de gestion (certains panneaux l'appellent KVM). Ouvrez-la maintenant et connectez-vous vraiment. Un écran de login qui s'affiche ne prouve rien si vous ne connaissez aucun mot de passe.
• Un compte avec un mot de passe que vous connaissez. Si vous n'en avez jamais défini, faites-le tant que vous avez encore la main : sudo passwd votre_utilisateur.
• SSH sur l'adresse IP publique, port 22 ou celui que vous avez choisi. sudo ss -tlnp | grep sshd vous dit si le service écoute et sur quel port.
• Le pare-feu, des deux côtés. Celui de la machine se lit avec sudo ufw status ou sudo nft list ruleset. Celui du fournisseur est un réglage séparé dans le panneau, et il bloque le paquet avant même qu'il atteigne le serveur, donc une règle locale correcte ne suffit pas.

La vérification qui compte n'est pas la lecture des règles. C'est une deuxième session ouverte en même temps : depuis votre poste, lancez ssh utilisateur@ADRESSE_PUBLIQUE dans un second terminal pendant que la session Tailscale est encore vivante. Laissez cette session ouverte jusqu'à la fin du guide.

Si cette connexion échoue, lisez le message avant d'aller plus loin, parce qu'il désigne l'endroit où ça casse. Un refus de connexion et un délai dépassé ne décrivent pas le même problème : le premier veut dire que le paquet est arrivé et qu'un service a répondu non, le second qu'il n'est jamais arrivé. Une clé rejetée relève d'une autre piste, celle des permissions du dossier et du bon fichier authorized_keys. Si aucun compte ne vous reste, la console du fournisseur est la sortie de secours, et réinitialiser le mot de passe root depuis le panneau va plus vite qu'une réinstallation.

tailscale down : couper la connexion, garder la machine

sudo tailscale down
tailscale status

tailscale down fait la même chose que le bouton Disconnect du client graphique. Le démon tailscaled continue de tourner. La machine reste enregistrée dans la console d'administration, sa clé reste valable, et sudo tailscale up la ramène sans réauthentification.

Lisez votre propre sortie de tailscale status plutôt que de croire ce qu'un guide vous promet. La CLI y indique l'état de la connexion et la liste des pairs, et cette sortie dépend de votre version du client et de votre tailnet. Aucune sortie n'est reproduite ici volontairement : la vôtre est la seule qui décrive votre machine.

La CLI connaît le risque que vous prenez. Lancée depuis une session qui passe par le tunnel, elle refuse de couper et demande une confirmation explicite avec --accept-risk=lose-ssh. Ce refus n'est pas un obstacle à contourner. C'est le dernier filet avant la perte d'accès. Si vous le voyez, revenez à la section précédente et ouvrez d'abord votre seconde session.

La préférence est enregistrée. Le démon garde dans son état local le fait qu'il ne doit pas se connecter, donc un redémarrage ne rebranche pas la machine toute seule. Pour le vérifier chez vous : redémarrez, puis relisez tailscale status.

tailscale logout : rendre la clé du nœud

sudo tailscale logout

tailscale logout déconnecte et expire la session de login. Au prochain sudo tailscale up, la machine doit se réauthentifier. C'est la différence de fond avec down : down garde l'identité du nœud, logout la rend.

Sur un serveur sans navigateur, cette réauthentification est le piège classique. tailscale up affiche une URL à ouvrir dans un navigateur, depuis n'importe quelle machine, et attend pendant ce temps. Si le serveur avait été enrôlé avec une clé d'authentification (auth key) à usage unique, cette clé est consommée : il vous en faut une nouvelle, générée dans la console. Préparez-la avant de lancer logout, pas après.

Ce que logout ne fait pas : retirer la machine du tailnet. L'entrée reste visible dans la console d'administration. Seuls les nœuds éphémères (ephemeral) sont supprimés automatiquement à la déconnexion, parce que c'est exactement ce que ce type de nœud promet.

Arrêter et désactiver tailscaled sous systemd

sudo systemctl disable --now tailscaled
systemctl is-enabled tailscaled

disable --now fait les deux moitiés du travail. stop arrête le démon tout de suite, disable retire le lien qui le relance au démarrage. N'exécuter que sudo systemctl stop tailscaled laisse le service activé, donc la machine se reconnecte seule au prochain redémarrage. C'est la surprise la plus fréquente de cette étape.

Quand le démon est arrêté, l'interface tailscale0 disparaît, et l'adresse en 100.x avec elle. Vérifiez-le sans passer par Tailscale : ip addr show tailscale0 échoue quand l'interface n'existe plus.

Attention à l'ordre des opérations. La commande tailscale ne fait rien toute seule : elle parle au démon par une socket locale. Démon arrêté, plus de tailscale down et plus de tailscale logout. Si vous vouliez déconnecter la machine du tailnet, faites-le avant d'arrêter le service, sinon il faudra relancer tailscaled juste pour ça.

Désinstaller le paquet tailscale

sudo tailscale logout
sudo systemctl disable --now tailscaled
sudo apt-get remove tailscale

L'ordre est volontaire : on rend la clé pendant qu'on a encore la commande pour le faire.

apt-get remove retire les binaires et laisse l'état local. Pour effacer aussi l'identité du nœud stockée sur la machine :

sudo apt-get purge tailscale
sudo rm -rf /var/lib/tailscale

/var/lib/tailscale/tailscaled.state contient l'état et les clés locales du nœud. Tant que ce fichier existe, une réinstallation reprend l'identité précédente et la machine retrouve sa place dans le tailnet. Une fois effacé, elle revient comme un nouveau nœud, avec une nouvelle entrée dans la console.

ls /etc/apt/sources.list.d/
sudo rm /etc/apt/sources.list.d/tailscale.list
sudo rm /usr/share/keyrings/tailscale-archive-keyring.gpg
sudo apt-get update

Supprimer la machine dans la console d'administration

Rien de ce qui précède ne touche au tailnet. La documentation de Tailscale le dit clairement : désinstaller le client ne retire pas l'appareil. L'entrée reste dans la console, avec son nom et ses règles d'accès. C'est pour cette raison que les tailnets personnels accumulent des serveurs fantômes.

La suppression se fait depuis la page Machines de la console. Trouvez la machine, ouvrez le menu à côté de son nom, choisissez Remove, puis confirmez. Il faut être Owner, Admin ou IT admin du tailnet. L'effet est immédiat : la machine perd l'accès à toutes les ressources du tailnet.

Un détail qui compte pour la sécurité. Si l'approbation des appareils (device approval) n'est pas activée sur votre tailnet, une machine supprimée qui a gardé une session de login valide peut se réinscrire toute seule au prochain démarrage du démon. D'où l'ordre recommandé : logout sur la machine d'abord, suppression dans la console ensuite.

Est-ce grave de laisser un nœud mort ? Sur le plan gratuit, au 22 septembre 2026, Tailscale annonce jusqu'à 6 utilisateurs et un nombre illimité d'appareils utilisateur, avec 50 ressources taguées incluses. Un vieux poste non tagué ne consomme donc pas de quota. Un serveur tagué, ce qu'est presque toujours un VPS, occupe une de ces 50 places. Ces chiffres évoluent : vérifiez-les sur la page de tarifs officielle avant de raisonner dessus, et lisez ce que le plan gratuit compte vraiment comme appareil pour la version détaillée. De toute façon, le quota n'est pas le vrai coût : un nœud fantôme garde un nom MagicDNS et reste présent dans vos règles d'accès.

Ce que voient les autres machines quand l'adresse 100.x disparaît

Le reste du tailnet ne reçoit pas d'annonce. Il constate.

Une machine simplement déconnectée ou éteinte garde son entrée et son nom MagicDNS. Le nom continue donc de se résoudre vers son adresse en 100.x, et l'échec arrive plus loin, au moment de joindre cette adresse. Une machine supprimée de la console perd son nom : la résolution elle-même ne renvoie plus rien.

Cette différence est un outil de diagnostic. Un nom qui ne se résout plus du tout indique une entrée supprimée. Un nom qui se résout mais ne répond pas indique une machine hors ligne ou déconnectée. C'est la même lecture que la distinction entre refus et délai dépassé, appliquée au tailnet.

Deux conséquences que l'on oublie souvent. Si le serveur servait de nœud de sortie pour le trafic internet de vos clients, ceux qui l'avaient sélectionné n'ont plus de route de sortie, et leur trafic tombe ou repart par leur connexion locale selon leur configuration. S'il annonçait des routes de sous-réseau, les plages privées qu'il publiait depuis le VPS disparaissent des tables de routage des pairs, et les services qui vivaient derrière deviennent injoignables.

Le nom, enfin. Si vous réinstallez plus tard sans avoir supprimé l'ancienne entrée, le nouveau nœud arrive avec un nom d'hôte déjà pris, et Tailscale distingue les deux en ajoutant un suffixe numérique. Vos scripts qui visaient l'ancien nom visent alors une machine morte. Ouvrez la page Machines après réinstallation au lieu de supposer.

Expiration de clé sur un serveur arrêté mais jamais déconnecté

L'expiration de clé ne dépend pas de l'état de la machine. La clé du nœud porte une date d'échéance côté plan de contrôle, pas un compteur de temps de fonctionnement. Un serveur dont vous avez arrêté tailscaled en janvier voit son échéance arriver comme les autres.

Au 22 septembre 2026, la documentation de Tailscale indique une période par défaut de 180 jours pour les nouveaux tailnets, réglable de 1 à 180 jours dans les paramètres de gestion des appareils. Quand la clé expire, la machine ne communique plus avec le tailnet tant qu'elle ne s'est pas réauthentifiée.

Pour une machine arrêtée, le scénario est précis. Vous la rallumez des mois plus tard, tailscaled démarre, et la connexion ne revient pas : il faut refaire sudo tailscale up et se réauthentifier, donc disposer d'un navigateur ou d'une clé d'authentification valide. Sur un VPS distant, cette réauthentification se prépare avant, pas au moment où vous en avez besoin.

La colonne Expires de la page Machines donne la date réelle pour chaque nœud. Pour un serveur que vous gardez en place, l'option Disable key expiry retire l'échéance. Elle existe précisément pour les machines de confiance difficiles à atteindre, et un VPS sans clavier en fait partie.

À retenir : logout déclenche tout de suite ce que l'expiration déclenche toute seule plus tard. Les deux mènent au même état, une machine connue du tailnet qui doit se réauthentifier avant de revenir.

Revenir en arrière

sudo systemctl enable --now tailscaled
sudo tailscale up

Si vous n'aviez fait que down, sudo tailscale up suffit. Si vous aviez fait logout, la même commande vous demandera de vous réauthentifier. Si vous aviez effacé /var/lib/tailscale, la machine revient comme un nouveau nœud, et l'ancienne entrée reste à supprimer à la main dans la console.

Pour retrouver l'accès SSH par le tunnel, relancez sudo tailscale up --ssh, et vérifiez que les règles d'accès du tailnet autorisent toujours cette machine. Une entrée supprimée ne récupère pas ses anciens tags : vous les remettez dans la console, ou vous réenrôlez la machine avec une clé d'authentification qui les porte. Gardez votre session SSH publique ouverte jusqu'à ce que la connexion par le tunnel fonctionne de nouveau.

FAQ

Quelle est la différence entre tailscale down et tailscale logout ?

tailscale down coupe la connexion au tailnet et conserve l'authentification. Un simple sudo tailscale up reconnecte la machine sans rien redemander. tailscale logout déconnecte et expire la session de login : au prochain tailscale up, la machine doit se réauthentifier, avec une URL ouverte dans un navigateur ou avec une clé d'authentification. Dans les deux cas le démon tailscaled continue de tourner, et dans les deux cas la machine reste listée dans la console d'administration, sauf s'il s'agit d'un nœud éphémère.

Est-ce que désinstaller Tailscale retire la machine du tailnet ?

Non. La documentation de Tailscale est explicite : si le client est désinstallé sans action de suppression, l'appareil n'est pas retiré du tailnet. L'entrée reste sur la page Machines, avec son nom MagicDNS et ses règles d'accès. La suppression est une action séparée, faite dans la console par un Owner, un Admin ou un IT admin. Faites tailscale logout sur la machine avant la désinstallation, puis Remove dans la console.

Je n'ai que Tailscale SSH pour entrer sur mon VPS. Comment couper sans me bloquer dehors ?

Ouvrez d'abord une seconde voie et testez-la pendant que le tunnel fonctionne encore : console VNC ou série du fournisseur, ou SSH sur l'adresse IP publique avec une clé ou un mot de passe que vous avez vérifiés. Vérifiez le pare-feu de la machine et celui du panneau du fournisseur, qui sont deux réglages distincts. Gardez cette seconde session ouverte pendant toute l'opération. Si tailscale down vous demande de confirmer avec --accept-risk=lose-ssh, c'est que la commande va fermer la session depuis laquelle vous la lancez.

Un serveur éteint garde-t-il sa clé Tailscale indéfiniment ?

Non. L'échéance est portée par la clé du nœud côté Tailscale, pas par le temps de fonctionnement de la machine, donc elle continue de courir pendant que le serveur est arrêté. La période par défaut documentée est de 180 jours, réglable de 1 à 180 jours dans les paramètres de gestion des appareils. Regardez la colonne Expires de la page Machines pour connaître la date de votre nœud, et utilisez Disable key expiry sur un serveur que vous ne pourrez pas réauthentifier facilement.