Ein ZimaOS-Benutzer glaubte, Tailscale sei nach dem ersten Start ausgefallen, weil auf der App-Seite „service unavailable“ angezeigt wurde und ein Telefon keine Dienste auf dem Heimserver erreichen konnte. Die Containerdiagnose zeigte ein anderes Ergebnis: Tailscale lief, das Gerät war autorisiert, und die Zustands- und Tunnel-Einbindungen waren vorhanden.
Das bestätigte Problem war die vom Telefon verwendete Adresse. Der Benutzer versuchte, eine normale Heim-LAN-Adresse zu erreichen, ohne Subnetz-Routing zu konfigurieren. Durch die Verbindung mit dem Dienst über die Tailscale-Adresse des ZimaOS-Geräts 100.x.x.x Die Adresse funktionierte.
Der Tailscale-Container war nicht ausgefallen
Das anfängliche Symptom deutete darauf hin, dass der Container nach einem Neustart beendet wurde, doch der erfasste Zustand zeigte:
- Der Container lief mit Exit-Code 0.
- Tailscale wechselte von „Starting“ zu „Running“.
- Das Gerät war im Tailnet des Benutzers autorisiert.
- Das Verzeichnis für den dauerhaften Zustand war in den Container eingebunden.
- Auch das von Tailscale benötigte TUN-Gerät war eingebunden.
- Das Gerät erhielt eine Tailscale-IPv4-Adresse und konnte Peers sehen.
Diese Hinweise trennten eine Meldung der ZimaOS-App-Seite oder Weboberfläche vom Zustand des Tailscale-Daemons selbst.
Warum die ersten Diagnoseversuche „Zugriff verweigert“ meldeten
Für die Terminalsitzung wurde ein normaler ZimaOS-Benutzer verwendet. Die erste Docker-Auflistung wurde mit erhöhten Berechtigungen ausgeführt, spätere Befehle versuchten jedoch, ohne diese auf den Docker-Socket zuzugreifen, und gaben daher Berechtigungsfehler zurück. Aus dem Forum kopierte typografische Anführungszeichen verhinderten außerdem, dass einige Befehlssubstitutionen korrekt interpretiert wurden.
Diese Berechtigungsmeldungen beschrieben die Diagnosesitzung, nicht einen Laufzeitfehler von Tailscale. Die spätere Ausgabe, die mit den erforderlichen Berechtigungen abgerufen wurde, zeigte, dass der Container fehlerfrei war.
Eine Heim-LAN-Adresse ist nicht automatisch eine Tailscale-Adresse
Eine Adresse wie 10.0.0.93 gehört zum Heim-LAN. Ein Telefon, das remote mit demselben Tailnet verbunden ist, erhält nicht automatisch eine Route zu jeder privaten LAN-Adresse.
Tailscale weist jedem Knoten eine eigene Adresse zu, üblicherweise im Bereich 100.x.x.x. Die offizielle Dokumentation zu IP-Adressen von Tailscale erklärt, dass diese Adressen Geräte innerhalb des Tailnets identifizieren und von der üblichen LAN-Adressierung getrennt bleiben.
Die funktionierende Verbindungsmethode
Der Antwortende bat den Benutzer, eine Verbindung zur Anwendung über die Tailscale-IP-Adresse des ZimaOS-Knotens und den eigenen Port der Anwendung herzustellen:
http://TAILSCALE-IP:APP-PORTBeispielsweise ein Dienst auf Port 8096 würde eine URL im folgenden Format verwenden:
http://100.x.x.x:8096Das Telefon muss ebenfalls im selben Tailnet angemeldet und aktiv mit Tailscale verbunden sein. Der Benutzer bestätigte, dass diese Adresse funktionierte, womit feststand, dass Tailscale selbst ordnungsgemäß lief.
Wenn Subnetz-Routing erforderlich ist
Wenn das Ziel darin besteht, Geräte über ihre bestehenden LAN-Adressen zu erreichen, etwa 10.0.0.x—ein Gerät in diesem Netzwerk muss das LAN-Subnetz als Route bekanntgeben, und die Route muss gemäß der Tailnet-Konfiguration genehmigt werden.
Dies ist eine andere Konfiguration als der direkte Zugriff auf den ZimaOS-Host über seine eigene Tailscale-IP. Lies zunächst die offizielle Dokumentation zu Subnetz-Routern von Tailscale, bevor du erwartest, dass normale LAN-Adressen remote funktionieren.
Warum auf der App-Seite weiterhin „Dienst nicht verfügbar“ stehen konnte
Eine Verfügbarkeitsprüfung der Weboberfläche kann fehlschlagen, obwohl der Netzwerk-Daemon läuft. Im Ausgangsfall waren der laufende Status, die erfolgreiche Tailnet-Autorisierung, die zugewiesene Tailscale-IP, die sichtbaren Peers und eine funktionierende Verbindung zum entfernten Dienst die entscheidenden Belege.
Das Ändern zufälliger App-Ports, Löschen des Tailscale-Status oder wiederholte Neuinstallieren des Containers würde eine falsche Zieladresse nicht beheben. Überprüfe den Zustand des Daemons und die Verbindungsmethode, bevor du eine funktionierende Identität zurücksetzt.
Warum sich die funktionierende Verbindung langsam anfühlen konnte
Die abschließende Antwort wies darauf hin, dass die Verbindung möglicherweise ein DERP-Relay statt eines direkten Peer-to-Peer-Pfads verwendet. Weitergeleiteter Tailscale-Datenverkehr kann ordnungsgemäß funktionieren und dennoch je nach Netzwerken, Routern und verfügbarer Relay-Region einen geringeren Durchsatz oder eine höhere Latenz aufweisen.
Allein die Langsamkeit beweist nicht, dass der Container fehlschlägt. Bestätige zunächst, ob die Verbindung funktioniert und ob Tailscale einen direkten oder weitergeleiteten Pfad meldet. Untersuche anschließend NAT- und Firewall-Verhalten, wenn die Leistung wichtig ist.
Eine sicherere Reihenfolge für die Diagnose
- Prüfe, ob der Tailscale-Container läuft, statt dich ausschließlich auf den Status der App-Seite zu verlassen.
- Bestätige, dass der ZimaOS-Knoten im selben Tailnet wie das Smartphone als autorisiert und online angezeigt wird.
- Ermittle die Tailscale-Adresse des ZimaOS-Knotens
100.x.x.xAdresse über die Tailscale-Oberfläche oder die Admin-Konsole. - Verbinde dich über diese Tailscale-Adresse und den Dienstport mit dem Zieldienst.
- Konfiguriere Subnetz-Routing nur, wenn der Zugriff über normale Heim-LAN-Adressen erforderlich ist.
- Untersuche die Verwendung eines DERP-Relays separat, wenn die Verbindung funktioniert, aber langsam ist.
FAQ zur Tailscale-Verbindung von ZimaOS
Beweist „Dienst nicht verfügbar“, dass Tailscale beendet wurde?
Nein. In diesem Fall lief der Container, war autorisiert und verbunden, obwohl die App-Seite diese Meldung anzeigte.
Warum hat die Änderung des Tailscale-App-Ports nicht geholfen?
Das Problem war die Zieladresse, nicht ein gewöhnlicher Konflikt mit einem Web-App-Port. Der Benutzer benötigte die Tailscale-IP-Adresse des Knotens.
Welche Adresse sollte ein entferntes Smartphone verwenden?
Verwende den Tailscale 100.x.x.x Adresse plus Anwendungsport, sofern kein Subnetz-Router für LAN-Adressen konfiguriert wurde.
Warum schlägt eine 10.0.0.x-Adresse über Tailscale fehl?
Es handelt sich um eine private Adresse im Heim-LAN. Für den entfernten Zugriff auf dieses Subnetz ist eine beworbene und genehmigte Subnetzroute erforderlich.
Warum kann eine funktionierende Tailscale-Verbindung langsam sein?
Die Verbindung wird möglicherweise über DERP weitergeleitet, statt einen direkten Peer-to-Peer-Pfad zu verwenden.
