Ein Tailscale-Container kann als verbunden angezeigt werden, ohne als Subnetzrouter zu funktionieren. In diesem ZimaOS-Thread vom April 2026 lief Tailscale in Docker mit Host-Netzwerk, privilegiertem Modus und /dev/net/tun eingebunden war, meldete die Tailscale-Administrationskonsole dennoch, dass der Rechner keine Routen bereitstellte. Navidrome funktionierte im lokalen Netzwerk, war aber remote über das Tailnet nicht erreichbar.
Der Thread endete nicht mit einer bestätigten Lösung durch den ursprünglichen Verfasser. Stattdessen teilte ein weiteres Community-Mitglied eine funktionierende Konfiguration für einen BigBear-Tailscale-Container, die in der eigenen ZimaOS-Umgebung erfolgreich ein LAN-Subnetz bekannt gab. Diese Konfiguration ist als Referenz zur Fehlersuche nützlich, stellt jedoch keine von IceWhale unterstützte Garantie für jedes Tailscale-App-Paket dar.
Mit Tailscale verbunden zu sein bedeutet nicht, dass Subnetzrouten bekannt gegeben werden
Die ursprüngliche Einrichtung hatte die Geräteauthentifizierung bereits abgeschlossen. Das Problem betraf ausdrücklich das Routing: Die Protokolle zeigten eine leere Routenliste, und die Tailscale-Administrationskonsole bot keine Subnetzroute zur Genehmigung an.
Dieser Unterschied ist wichtig, da ein normaler Tailscale-Knoten lediglich dem Tailnet beitritt. Ein Subnetzrouter hat zusätzliche Aufgaben: Er muss ein oder mehrere LAN-Präfixe bekannt geben und die Anforderungen des Betriebssystems für das Weiterleiten des Datenverkehrs zwischen Tailnet und LAN erfüllen.
Die aktuelle Tailscale-Dokumentation beschreibt Subnetzrouter als Gateways, die private Netzwerke für Geräte im Tailnet bekannt geben. Außerdem ist IP-Weiterleitung unter Linux sowie die Genehmigung der Route in der Tailscale-Administrationskonsole erforderlich, sofern keine autoApprovers die Richtlinie die Genehmigung automatisch übernimmt.
Dokumentation zu Tailscale-Subnetzroutern
Die funktionierende Community-Referenz verwendete TS_ROUTES
Die Antwort von TomasSzwed verwendete einen BigBear-Tailscale-Container und konfigurierte das Subnetz über Umgebungsvariablen, anstatt sich nach dem Start auf einen manuellen Einmalbefehl zu verlassen. Zu den wichtigen Teilen dieser Referenz gehörten:
-
network_mode: host; - privilegierter Modus;
-
/dev/net/tunin den Container eingebunden; -
TS_USERSPACE=false; -
TS_ROUTES=192.168.2.0/24für das beworbene LAN; -
TS_EXTRA_ARGS=--accept-routesin der Konfiguration dieses Benutzers; - persistenten Tailscale-Status unter
/var/lib/tailscale.
Verwenden Sie das korrekte LAN-Präfix für Ihr Netzwerk
Das funktionierende Beispiel verwendete das beworbene 192.168.2.0/24Dieser Wert ist nur für ein LAN sinnvoll, das dieses Subnetz verwendet. Ein anderes Heimnetzwerk könnte 192.168.1.0/24, 10.0.0.0/24oder ein anderes privates Präfix festlegen.
Die Bekanntgabe des falschen Subnetzes kann zu einem Tailscale-Knoten führen, der zwar fehlerfrei ist, aber die vorgesehenen ZimaOS-Dienste dennoch nicht routen kann. Ermitteln Sie das tatsächliche lokale Netzwerkpräfix, bevor Sie TS_ROUTES oder ein gleichwertiger --advertise-routes Option.
Beworbene Routen müssen weiterhin aktiviert werden
Die aktuellen Tailscale-Empfehlungen trennen das Ankündigen von Routen und deren Genehmigung. Sobald der Subnetz-Router eine Route bewirbt, muss die Route in der Tailscale-Administrationskonsole aktiviert werden, sofern die Tailnet-Richtlinie sie nicht automatisch genehmigt.
Wenn die Administrationskonsole angibt, dass der Rechner überhaupt keine Routen bereitstellt, konzentrieren Sie sich zunächst auf die Routenankündigungskonfiguration des Containers. Wenn die Route angezeigt wird, der Datenverkehr aber weiterhin nicht funktioniert, überprüfen Sie anschließend die Routengenehmigung, die Zugriffskontrollrichtlinie, die Weiterleitung und den Zieldienst selbst.
Docker-Netzwerk ändert, welche Routen der Container verwenden kann
Der ursprüngliche Verfasser verwendete das Host-Netzwerk und band das TUN-Gerät ein. Die Referenz aus der Community verwendete ebenfalls diese Konfiguration. Die aktuelle Tailscale-Dokumentation unterstützt Tailscale auch in Docker, aber Docker-Netzwerk und Tailscale-Routing sind getrennte Ebenen, die beide korrekt konfiguriert sein müssen.
Tailscale-Dokumentation zu Docker
Gehen Sie nicht davon aus, dass zwei Tailscale-Apps im ZimaOS App Store identische Containerdefinitionen verwenden. Der ursprüngliche Verfasser bemerkte ausdrücklich, dass das geteilte Beispiel das Tailscale-Paket von BigBear verwendete, während die bestehende Installation den anderen Tailscale-Eintrag nutzte.
Was das für Navidrome und andere lokale Dienste bedeutet
Ziel des ursprünglichen Threads war es, von einem iPhone aus auf Navidrome zuzugreifen, ohne eine öffentliche Portweiterleitung einzurichten. Wenn Navidrome im lokalen LAN bereits erreichbar ist, kann ein funktionierender Subnetz-Router diese LAN-Adresse für autorisierte Tailnet-Geräte erreichbar machen.
Der Thread bestätigt jedoch nicht, dass der ursprüngliche Verfasser den Wechsel zur BigBear-Konfiguration abgeschlossen oder Navidrome danach erfolgreich erreicht hat. Die Seite dokumentiert daher eine praktikable Referenz aus der Community und ein Diagnosemodell, aber keine bestätigte Lösung für genau diese Installation.
FAQ zum Tailscale-Subnetz-Routing in ZimaOS
Warum zeigt Tailscale „verbunden“ an, aber keine Subnetzrouten?
Dem Tailnet beizutreten und eine LAN-Route zu bewerben sind unterschiedliche Vorgänge. Im Ausgangsfall war die Authentifizierung erfolgreich, aber die Routenliste blieb leer.
Kann Tailscale in Docker unter ZimaOS als Subnetz-Router fungieren?
Ein Community-Mitglied berichtete, dass es in seiner ZimaOS-Konfiguration funktioniert hat, und teilte eine Tailscale-Konfiguration von BigBear. Tailscale selbst unterstützt ebenfalls Subnetz-Routing und Docker-Bereitstellungen, aber die genaue App-Konfiguration in ZimaOS ist weiterhin wichtig.
Muss ich die Route in Tailscale genehmigen?
Nach dem aktuellen Verhalten von Tailscale müssen beworbene Subnetzrouten normalerweise in der Administrationskonsole genehmigt werden, es sei denn, autoApprovers Die Richtlinie verarbeitet sie automatisch.
Soll ich 192.168.2.0/24 aus dem Screenshot kopieren?
Nein. Verwenden Sie das tatsächliche Subnetz des LANs, das Sie freigeben möchten. Der Wert im Screenshot gehört zum Netzwerk eines anderen Community-Mitglieds.
