Un utilisateur de ZimaOS pensait que Tailscale avait échoué après son premier lancement, car la page de l’application affichait « service indisponible » et qu’un téléphone ne pouvait pas accéder aux services du serveur domestique. Les diagnostics du conteneur ont montré un résultat différent : Tailscale fonctionnait, l’appareil était autorisé, et les montages de l’état et du tunnel étaient présents.
Le problème confirmé concernait l’adresse utilisée depuis le téléphone. L’utilisateur tentait d’accéder à une adresse LAN domestique normale sans avoir configuré le routage de sous-réseau. La connexion au service via l’adresse Tailscale de l’appareil ZimaOS 100.x.x.x l’adresse fonctionnait.
Le conteneur Tailscale n’avait pas échoué
Le symptôme initial laissait penser que le conteneur s’était arrêté après un redémarrage, mais l’état recueilli montrait :
- L’état du conteneur indiquait qu’il fonctionnait avec le code de sortie 0.
- Tailscale est passé de l’état Starting à l’état Running.
- La machine était autorisée dans le tailnet de l’utilisateur.
- Le répertoire d’état persistant était mappé dans le conteneur.
- Le périphérique TUN requis par Tailscale était également mappé.
- L’appareil a reçu une adresse IPv4 Tailscale et pouvait voir ses pairs.
Ces éléments ont permis de distinguer un message de la page de l’application ZimaOS ou de l’interface web de l’état de santé du démon Tailscale lui-même.
Pourquoi les premières tentatives de diagnostic ont affiché « Permission denied »
La session de terminal utilisait un utilisateur ZimaOS standard. La première liste Docker a été exécutée avec des privilèges élevés, mais les commandes suivantes ont tenté d’accéder au socket Docker sans ces privilèges et ont donc renvoyé des erreurs d’autorisation. Les guillemets courbes copiés depuis le forum ont également empêché certaines substitutions de commandes d’être interprétées correctement.
Ces messages d’autorisation décrivaient la session de diagnostic, et non un échec de Tailscale lors de son fonctionnement. La sortie obtenue ultérieurement avec les privilèges appropriés a montré que le conteneur fonctionnait correctement.
Une adresse du LAN domestique n’est pas automatiquement une adresse Tailscale
Une adresse telle que 10.0.0.93 appartient au réseau LAN domestique. Un téléphone connecté à distance au même tailnet n’obtient pas automatiquement une route vers chaque adresse LAN privée.
Tailscale attribue à chaque nœud sa propre adresse, généralement dans la plage 100.x.x.x. La documentation officielle des adresses IP de Tailscale explique que ces adresses identifient les appareils au sein du tailnet et restent distinctes des adresses LAN ordinaires.
La méthode de connexion qui a fonctionné
L’intervenant a demandé à l’utilisateur de se connecter à l’application avec l’adresse IP Tailscale du nœud ZimaOS et le port utilisé par l’application :
http://TAILSCALE-IP:APP-PORTPar exemple, un service sur le port 8096 utiliserait une URL de la forme suivante :
http://100.x.x.x:8096Le téléphone doit également être connecté au même tailnet et activement connecté à Tailscale. L’utilisateur a confirmé que cette adresse fonctionnait, ce qui a établi que Tailscale lui-même fonctionnait.
Lorsque le routage de sous-réseau est requis
Si l’objectif est d’accéder aux appareils via leurs adresses LAN existantes, par exemple 10.0.0.x—un appareil de ce réseau doit annoncer le sous-réseau local comme route, et cette route doit être approuvée conformément à la configuration du tailnet.
Cette configuration est différente de l’accès direct à l’hôte ZimaOS via sa propre adresse IP Tailscale. Consultez la documentation officielle sur les routeurs de sous-réseau de Tailscale avant de vous attendre à ce que les adresses habituelles du réseau local fonctionnent à distance.
Pourquoi la page de l’application pouvait-elle tout de même afficher « Service indisponible » ?
Une vérification de disponibilité de l’interface web peut échouer même lorsque le démon réseau fonctionne. Dans le cas d’origine, les éléments décisifs étaient l’état d’exécution, l’autorisation réussie sur le tailnet, l’adresse IP Tailscale attribuée, les pairs visibles et une connexion fonctionnelle au service distant.
Modifier aléatoirement les ports de l’application, supprimer l’état Tailscale ou réinstaller plusieurs fois le conteneur ne résoudrait pas un problème d’adresse de destination incorrecte. Vérifiez l’état du démon et la méthode de connexion avant de réinitialiser une identité fonctionnelle.
Pourquoi une connexion fonctionnelle pouvait sembler lente
La réponse finale suggérait que la connexion pouvait utiliser un relais DERP plutôt qu’une liaison directe de pair à pair. Le trafic Tailscale relayé peut fonctionner correctement tout en offrant un débit inférieur ou une latence plus élevée, selon les réseaux, les routeurs et la région de relais disponible.
Une simple lenteur ne prouve pas que le conteneur est défaillant. Commencez par vérifier si la connexion fonctionne et si Tailscale signale une liaison directe ou relayée, puis examinez le comportement du NAT et du pare-feu si les performances sont importantes.
Un ordre de diagnostic plus sûr
- Vérifiez que le conteneur Tailscale est en cours d’exécution au lieu de vous fier uniquement à l’état affiché sur la page de l’application.
- Vérifiez que le nœud ZimaOS apparaît comme autorisé et en ligne sur le même tailnet que le téléphone.
- Identifiez l’adresse Tailscale du nœud ZimaOS
100.x.x.xl’adresse via l’interface Tailscale ou la console d’administration. - Connectez-vous au service cible en utilisant cette adresse Tailscale et le port du service.
- Configurez le routage de sous-réseau uniquement si l’accès via les adresses habituelles du réseau local est nécessaire.
- Examinez séparément l’utilisation d’un relais DERP si la connexion fonctionne mais est lente.
FAQ sur la connexion Tailscale de ZimaOS
Le message « service indisponible » prouve-t-il que Tailscale s’est arrêté ?
Non. Dans ce cas, le conteneur était en cours d’exécution, autorisé et connecté, même si la page de l’application affichait ce message.
Pourquoi la modification du port de l’application Tailscale n’a-t-elle rien changé ?
Le problème venait de l’adresse de destination, et non d’un conflit normal de ports d’application web. L’utilisateur devait utiliser l’adresse IP Tailscale du nœud.
Quelle adresse un téléphone distant doit-il utiliser ?
Utilisez le nœud ZimaOS de Tailscale 100.x.x.x l’adresse ainsi que le port de l’application, sauf si un routeur de sous-réseau a été configuré pour les adresses du réseau local.
Pourquoi une adresse 10.0.0.x échoue-t-elle via Tailscale ?
Il s’agit d’une adresse privée du réseau local domestique. Pour accéder à ce sous-réseau à distance, il faut une route de sous-réseau annoncée et approuvée.
Pourquoi une connexion Tailscale fonctionnelle peut-elle être lente ?
La connexion peut être relayée via DERP au lieu d’emprunter une liaison directe de pair à pair.
