Un conteneur Tailscale permanent devrait rester la même machine dans la console d’administration Tailscale après un redémarrage de ZimaOS ou une modification de l’application. Dans la discussion source de septembre 2025, ce n’était pas le cas : chaque redémarrage ou redéploiement créait un autre nœud Tailscale, même si le fichier Compose montait déjà /var/lib/tailscale vers les données d’application ZimaOS persistantes.
Le résultat final de la source est important, car il restreint la cause possible. L’auteur du message original a indiqué que le stockage persistant était déjà correctement configuré ; supprimer la variable d’environnement de clé d’authentification fournie en permanence était la seule modification nécessaire. Après cela, l’identité du nœud Tailscale a persisté.
Tailscale a besoin d’un état de machine persistant
Tailscale stocke l’identité du nœud, les clés et l’état de connexion dans son répertoire d’état. Dans Docker, le chemin est généralement configuré avec :
TS_STATE_DIR=/var/lib/tailscaleSi ce répertoire n’existe que dans le système de fichiers temporaire du conteneur, recréer le conteneur crée une nouvelle identité Tailscale.
La source montait déjà le répertoire d’état
Le fichier Compose d’origine incluait :
/DATA/AppData/tailscale:/var/lib/tailscaleainsi que TS_STATE_DIR=/var/lib/tailscale, le réseau de l’hôte, NET_ADMIN, NET_RAW, ainsi qu’un accès à /dev/net/tun. En théorie, cela devrait préserver l’état.
Une clé d’authentification sert à l’enrôlement, pas nécessairement à chaque redémarrage
Le fichier Compose fournissait également TS_AUTHKEY à chaque démarrage du conteneur. Une personne de la communauté a expliqué qu’une nouvelle authentification peut créer une nouvelle machine lorsque l’état du nœud existant n’est pas réutilisé comme prévu.
La personne répondante a suggéré d’utiliser une clé d’authentification réutilisable et non éphémère lors du premier démarrage, d’attendre que le nœud apparaisse dans la console d’administration, puis de supprimer la ligne de clé d’authentification et de redéployer afin que l’état enregistré de la machine devienne la source de son identité.
L’auteur du message original a confirmé que la suppression de la clé d’authentification avait résolu son problème
La réponse finale de la source indique que les autres éléments de persistance étaient déjà en place et qu’il suffisait de supprimer la variable d’environnement de clé d’authentification. Le nom de la machine a ensuite persisté après les redémarrages.
Cette confirmation est plus solide qu’une simple supposition générale concernant les autorisations. Pour cette installation particulière, les authentifications répétées étaient concrètement à l’origine du problème.
Tailscale prend actuellement en charge TS_AUTH_ONCE
Les déploiements Docker modernes de Tailscale peuvent utiliser TS_AUTH_ONCE=true. Lorsque l’état persistant existe déjà, cela indique au conteneur de ne pas forcer une nouvelle authentification à chaque démarrage.
Consultez les paramètres actuels d’état Docker et d’authentification de Tailscale avant de réutiliser tel quel un fichier Compose de 2025.
Utiliser un dossier hôte dédié pour l’état
Un dossier hôte dédié, tel qu’un dossier AppData/d’état Tailscale, facilite la vérification de la persistance des clés de la machine lors d’un redéploiement. La personne ayant répondu à la question source recommandait également de s’assurer que le dossier est accessible en écriture par le processus qui stocke l’état de Tailscale.
Les autorisations sont importantes, car un volume peut être correctement monté alors que le processus ne peut toujours pas mettre à jour ses fichiers. Dans ce cas, Tailscale peut se comporter comme si la machine ne disposait d’aucun état réutilisable.
Éviter les clés d’authentification éphémères pour un serveur permanent
Tailscale prend en charge les nœuds éphémères, intentionnellement temporaires. C’est utile pour les tâches CI de courte durée ou les conteneurs jetables, mais c’est l’inverse de ce dont un serveur ZimaOS permanent a besoin.
Lors de la création d’un identifiant, vérifiez qu’il correspond au cycle de vie prévu. Un serveur personnel persistant doit normalement conserver la même identité jusqu’à ce que vous la révoquiez ou la remplaciez délibérément.
TS_HOSTNAME ne définit pas l’identité de la machine
Le conteneur source utilisait TS_HOSTNAME=zimaos. Ce paramètre contrôle le nom convivial présenté au tailnet, mais conserver la même chaîne de nom d’hôte ne préserve pas l’identité cryptographique de la machine. Deux machines nouvellement authentifiées peuvent toutes deux tenter d’utiliser des noms similaires tout en restant des nœuds distincts.
Tester le redémarrage et le redéploiement de l’application
Le problème initial est apparu après des redémarrages complets du système d’exploitation et des modifications de l’application ZimaOS. Une correction appropriée doit donc résister aux deux :
- redémarrer le conteneur Tailscale ;
- modifier et redéployer l’application sans changer le volume d’état ;
- redémarrer ZimaOS ;
- vérifiez que la même machine reste en ligne dans la console d’administration Tailscale.
Si un doublon apparaît après un seul de ces événements, comparez ce qui arrive au répertoire d’état pendant cette opération précise du cycle de vie.
FAQ sur la persistance de Tailscale
Pourquoi une nouvelle machine Tailscale était-elle créée après chaque redémarrage ?
Dans le cas source, le volume d’état existait déjà et l’utilisation répétée de la clé d’authentification constituait le dernier problème pratique.
Quel chemin doit être conservé ?
Le chemin configuré par TS_STATE_DIR, généralement /var/lib/tailscale à l’intérieur du conteneur.
TS_AUTHKEY doit-elle rester définitivement dans l’environnement ?
Pas nécessairement. L’utilisateur source a résolu les nœuds en double en le supprimant après l’inscription, et Tailscale propose également désormais TS_AUTH_ONCE.
TS_HOSTNAME préserve-t-il l’identité du nœud ?
Non. C’est l’état enregistré de la machine Tailscale qui préserve son identité.
