Un conteneur Tailscale peut apparaître comme connecté sans fonctionner comme routeur de sous-réseau. Dans ce fil de discussion ZimaOS d’avril 2026, Tailscale s’exécutait dans Docker avec le réseau de l’hôte, le mode privilégié et /dev/net/tun était monté, mais la console d’administration Tailscale indiquait que la machine n’exposait aucune route. Navidrome fonctionnait sur le réseau local, mais était inaccessible à distance via le tailnet.
Le fil de discussion ne s’est pas conclu par une résolution confirmée par l’auteur de la publication initiale. En revanche, un autre membre de la communauté a partagé une configuration fonctionnelle d’un conteneur BigBear Tailscale qui annonçait correctement un sous-réseau LAN dans son propre environnement ZimaOS. Cette configuration constitue une référence utile pour le dépannage, mais ne garantit pas la prise en charge par IceWhale de chaque paquet d’application Tailscale.
Être connecté à Tailscale ne signifie pas que des routes de sous-réseau sont annoncées
La configuration initiale avait déjà terminé l’authentification de l’appareil. Le problème concernait spécifiquement le routage : les journaux affichaient une liste de routes vide et la console d’administration Tailscale ne proposait aucune route de sous-réseau à approuver.
Cette distinction est importante, car un nœud Tailscale normal rejoint simplement le tailnet. Un routeur de sous-réseau a des responsabilités supplémentaires : il doit annoncer un ou plusieurs préfixes LAN et satisfaire aux exigences de routage du système d’exploitation nécessaires pour transférer le trafic entre le tailnet et ce LAN.
La documentation actuelle de Tailscale décrit les routeurs de sous-réseau comme des passerelles qui annoncent des réseaux privés aux appareils du tailnet. Elle exige également l’activation du transfert IP sous Linux et l’approbation de la route dans la console d’administration Tailscale, sauf si une autoApprovers la validation de la règle gère automatiquement l’approbation.
Documentation Tailscale sur les routeurs de sous-réseau
La référence communautaire fonctionnelle utilisait TS_ROUTES
La réponse de TomasSzwed utilisait un conteneur BigBear Tailscale et configurait le sous-réseau au moyen de variables d’environnement, plutôt que de dépendre d’une commande manuelle exécutée une seule fois après le démarrage. Les éléments importants de cette référence comprenaient :
-
network_mode: host; - le mode privilégié ;
-
/dev/net/tunmonté dans le conteneur ; -
TS_USERSPACE=false; -
TS_ROUTES=192.168.2.0/24pour le LAN annoncé ; -
TS_EXTRA_ARGS=--accept-routesdans la configuration de cet utilisateur ; - l’état Tailscale persistant sous
/var/lib/tailscale.
Utilisez le préfixe LAN correct pour votre réseau
L’exemple fonctionnel annonçait 192.168.2.0/24. Cette valeur n’a de sens que pour un réseau local utilisant ce sous-réseau. Un autre réseau domestique peut utiliser 192.168.1.0/24, 10.0.0.0/24, ou un autre préfixe privé.
Annoncer le mauvais sous-réseau peut produire un nœud Tailscale sain, mais qui ne peut toujours pas acheminer le trafic vers les services ZimaOS prévus. Déterminez le préfixe réseau local réel avant de définir TS_ROUTES ou un équivalent --advertise-routes option.
Les routes annoncées doivent encore être activées
Les recommandations actuelles de Tailscale distinguent l’annonce des routes de leur approbation. Une fois que le routeur de sous-réseau a annoncé une route, celle-ci doit être activée dans la console d’administration de Tailscale, sauf si la policy du tailnet l’approuve automatiquement.
Si la console d’administration indique que la machine n’expose aucune route, concentrez-vous d’abord sur la configuration d’annonce des routes du conteneur. Si la route apparaît, mais que le trafic ne fonctionne toujours pas, vérifiez ensuite l’approbation de la route, la politique de contrôle d’accès, la redirection et le service de destination lui-même.
La mise en réseau Docker détermine ce que le conteneur peut acheminer
L’auteur original utilisait le réseau de l’hôte et montait le périphérique TUN. La référence communautaire faisait de même. La documentation actuelle de Tailscale prend également en charge l’exécution de Tailscale dans Docker, mais la mise en réseau Docker et le routage Tailscale sont deux couches distinctes qui doivent toutes deux être correctement configurées.
Documentation Docker de Tailscale
Ne supposez pas que deux applications Tailscale de l’App Store ZimaOS utilisent des définitions de conteneur identiques. L’auteur original a précisément remarqué que l’exemple partagé utilisait le paquet Tailscale de BigBear, tandis que son installation existante utilisait l’autre entrée Tailscale.
Ce que cela signifie pour Navidrome et les autres services locaux
L’objectif du fil source était d’accéder à Navidrome depuis un iPhone sans redirection de port publique. Si Navidrome est déjà accessible sur le réseau local, un routeur de sous-réseau fonctionnel peut rendre cette adresse du réseau local accessible depuis les appareils autorisés du tailnet.
Cependant, le fil de discussion ne confirme pas que l’auteur original a terminé le passage à la configuration BigBear ni qu’il a réussi à accéder à Navidrome par la suite. La page présente donc une référence communautaire viable et un modèle de diagnostic, mais pas une résolution confirmée pour cette installation précise.
FAQ sur le routage de sous-réseau de Tailscale dans ZimaOS
Pourquoi Tailscale indique-t-il être connecté, mais n’affiche-t-il aucune route de sous-réseau ?
Rejoindre le tailnet et annoncer une route du réseau local sont deux opérations différentes. Dans le cas présenté, l’authentification a réussi, mais la liste des routes est restée vide.
Tailscale dans Docker peut-il servir de routeur de sous-réseau sur ZimaOS ?
Un membre de la communauté a indiqué que cela fonctionnait dans sa configuration ZimaOS et a partagé une configuration Tailscale de BigBear. Tailscale prend également en charge le routage de sous-réseau et les déploiements Docker, mais la configuration exacte de l’application ZimaOS reste importante.
Dois-je approuver la route dans Tailscale ?
Avec le comportement actuel de Tailscale, les routes de sous-réseau annoncées doivent normalement être approuvées dans la console d’administration, sauf si une autoApprovers la policy les gère automatiquement.
Dois-je copier 192.168.2.0/24 depuis la capture d’écran ?
Non. Utilisez le sous-réseau réel du réseau local que vous souhaitez exposer. La valeur de la capture d’écran appartient au réseau d’un autre membre de la communauté.
