Si l’application Tailscale s’installe sur ZimaOS, mais que le fait de cliquer sur sa WebUI vous renvoie simplement au tableau de bord ZimaOS, cela ne signifie pas nécessairement que le conteneur Tailscale est défectueux. Le fil de discussion communautaire de novembre 2024 a commencé exactement par ce symptôme sur ZimaOS 1.2.5. La correction utile était que Tailscale se configure principalement via l’authentification, les variables d’environnement et l’interface de ligne de commande Tailscale, plutôt que par une WebUI d’application classique.
La réponse d’origine recommandait d’utiliser le paquet de l’App Store et de fournir une clé d’authentification Tailscale via TS_AUTHKEY. Un fil ZimaOS ultérieur datant de 2025 a confirmé une autre méthode fonctionnelle : installer Tailscale, exécuter tailscale status dans l’interface de ligne de commande, ouvrez l’URL de connexion qu’il renvoie et authentifiez le nœud. La documentation actuelle de Tailscale pour Docker prend en charge les flux fondés sur une clé d’authentification et ceux fondés sur une connexion, tout en recommandant également un état persistant afin que le conteneur conserve la même identité de nœud après les redémarrages.
Pourquoi le lien « WebUI » de Tailscale peut être trompeur
L’utilisateur d’origine s’attendait à ce que l’application ouvre une page de gestion après l’installation. Au lieu de cela, le navigateur revenait à la page d’accueil de ZimaOS.
La solution communautaire d’origine : utiliser TS_AUTHKEY
La première réponse indiquait que le paquet de l’App Store pouvait fonctionner en créant une clé d’authentification Tailscale et en la collant dans :
TS_AUTHKEYLa documentation actuelle de Tailscale définit toujours TS_AUTHKEY comme variable d’environnement utilisée pour authentifier un conteneur Docker auprès d’un tailnet.
Référence actuelle : paramètres de configuration Docker de Tailscale.
Générez la clé dans la console d’administration Tailscale, puis traitez-la comme un secret. Ne la publiez pas dans des captures d’écran, des messages sur les forums, des dépôts Git ou des fichiers Compose partagés.
Alternative : s’authentifier via l’interface de ligne de commande Tailscale
Une solution ultérieure proposée par la communauté ZimaOS utilisait :
tailscale statusLorsque le nœud ne s’était pas encore authentifié, Tailscale renvoyait une URL de connexion. L’utilisateur ouvrait cette URL dans un navigateur et approuvait l’appareil.
Selon le conteneur installé et le contexte du shell, vous devrez peut-être exécuter la commande à l’intérieur du conteneur Tailscale plutôt que directement sur l’hôte ZimaOS.
Commencez par identifier le conteneur :
docker ps --format '{{.Names}}' | grep -i tailscaleEnsuite, si nécessaire :
docker exec -it TAILSCALE_CONTAINER tailscale statusUtilisez le nom réel du conteneur affiché par votre système.
Conserver l’état de Tailscale entre les redémarrages
La documentation Docker actuelle de Tailscale recommande de définir :
TS_STATE_DIR=/var/lib/tailscaleet monter ce répertoire sur un stockage persistant de l’hôte. Sans état persistant, un conteneur redémarré ou recréé peut s’enregistrer comme un nouveau nœud au lieu de conserver son identité précédente.
Tailscale fournit également :
TS_AUTH_ONCE=truepour les déploiements qui doivent s’authentifier uniquement lorsque le conteneur ne possède aucun état existant.
Ce dont une configuration actuelle du conteneur a besoin
Une configuration Docker conceptuelle minimale comprend :
environment :
- TS_AUTHKEY=YOUR_SECRET_KEY
- TS_STATE_DIR=/var/lib/tailscale
- TS_AUTH_ONCE=true
volumes :
- /YOUR/ZIMAOS/PERSISTENT/PATH:/var/lib/tailscaleLe chemin exact sur l’hôte ainsi que les paramètres réseau et de périphérique supplémentaires dépendent de la définition de l’application ZimaOS App Store. Ne remplacez pas une définition d’application actuelle fonctionnelle par un ancien fichier YAML CasaOS uniquement parce que la discussion de 2024 renvoyait vers un tutoriel CasaOS.
Accéder à ZimaOS est différent de l’annonce de l’ensemble du réseau local
Il existe deux objectifs courants :
- Accéder directement au nœud Tailscale : connectez-vous au nœud ZimaOS/Tailscale à l’aide de son adresse Tailscale ou de son nom MagicDNS.
- Accéder aux autres appareils du réseau local ZimaOS : configurez le nœud comme routeur de sous-réseau Tailscale.
Le deuxième objectif est plus complexe. La documentation actuelle de Tailscale exige que le routeur annonce les routes et que celles-ci soient approuvées dans la console d’administration.
Consultez la documentation de Tailscale sur les routeurs de sous-réseau.
Le routage de sous-réseau dans l’application Tailscale Dockerisée de ZimaOS nécessite des exigences supplémentaires
Un rapport de la communauté ZimaOS datant de 2026 a montré qu’un conteneur Docker Tailscale s’était connecté correctement, mais n’avait pas réussi à annoncer les routes du réseau local. Cette configuration utilisait le réseau de l’hôte, le mode privilégié et /dev/net/tun, pourtant les routes de sous-réseau n’apparaissaient toujours pas.
Voici un point important : un conteneur qui rejoint correctement votre tailnet n’est pas automatiquement un routeur de sous-réseau fonctionnel. Le routage nécessite des privilèges liés au noyau et au réseau, la redirection IP, l’annonce des routes et une approbation par l’administrateur.
Si votre seul objectif est d’accéder à ZimaOS lui-même à distance, n’activez pas inutilement le routage de sous-réseau.
Tailscale n’exige pas l’accès Invité SMB
La réponse de la communauté publiée en 2024 affirmait que le partage de dossiers SMB nécessitait des autorisations Invité pour fonctionner via le tunnel Tailscale. Cela ne doit pas être généralisé comme une exigence actuelle de Tailscale.
Tailscale fournit la connectivité réseau. L’authentification SMB reste une couche indépendante de permissions Samba/Windows/macOS. Un compte SMB nominatif correctement configuré peut fonctionner via Tailscale tout comme via un réseau local.
L’accès Invité a peut-être servi de solution de contournement pour la configuration Samba particulière de CasaOS/ZimaOS dans cette ancienne discussion, mais il n’est pas inhérent à Tailscale.
Notes de sécurité
- Utilisez une clé d’authentification limitée, réutilisable ou éphémère selon les besoins de votre déploiement.
- Ne laissez pas les clés d’authentification apparaître dans des captures d’écran ou des dépôts.
- Conservez l’état afin que le nœud ne se réenregistre pas à répétition.
- Utilisez les ACL ou les grants Tailscale pour contrôler les appareils du tailnet autorisés à accéder au nœud ZimaOS.
- N’exposez pas directement le tableau de bord ZimaOS sur Internet simplement parce qu’un accès à distance est nécessaire.
Liste de contrôle de la configuration de Tailscale sur ZimaOS
- Installez la version actuelle du paquet Tailscale de l’App Store.
- Ne vous fiez pas au lien vers l’interface Web de l’application comme méthode de configuration principale.
- Authentifiez-vous avec
TS_AUTHKEYou utilisez l’URL de connexion CLI de Tailscale. - Conservez
/var/lib/tailscaleavecTS_STATE_DIR. - Vérifiez que le nœud apparaît dans la console d’administration Tailscale.
- Exécutez
tailscale statuset confirmez que le nœud est connecté. - Testez l’accès au nœud ZimaOS avant de tenter le routage de sous-réseau.
- Si vous avez besoin d’accéder à l’ensemble du réseau local, configurez et approuvez séparément les routes de sous-réseau.
FAQ sur ZimaOS et Tailscale
Pourquoi le lien vers l’interface Web de Tailscale renvoie-t-il vers ZimaOS ?
Le conteneur Tailscale est normalement configuré au moyen de variables d’environnement, de l’authentification et de commandes CLI, plutôt que par une interface Web classique. C’est précisément la confusion montrée dans le fil de discussion source.
Qu’est-ce que TS_AUTHKEY ?
Il s’agit de la variable d’environnement Docker de Tailscale utilisée pour authentifier le conteneur auprès de votre tailnet.
Pourquoi dois-je conserver TS_STATE_DIR ?
La conservation de l’état permet au conteneur de conserver l’identité et l’authentification de son nœud après des redémarrages ou des recréations.
Ai-je besoin du routage de sous-réseau pour accéder à ZimaOS à distance ?
Non. Le routage de sous-réseau est uniquement nécessaire lorsque le nœud Tailscale doit acheminer le trafic vers d’autres appareils non connectés à Tailscale sur le réseau local.
SMB a-t-il besoin du mode Invité via Tailscale ?
Non, pas comme règle générale de Tailscale. L’authentification du compte SMB est distincte du réseau Tailscale.
