The normal Tailscale Docker app is convenient, but a containerized VPN does not always behave like Tailscale installed directly on a Linux host. The source author wanted a first-class host daemon with a real TUN device so ZimaOS itself could act as a subnet router or exit node and mount resources reachable through the tailnet.
Die normale Tailscale-Docker-App ist praktisch, aber ein containerisiertes VPN verhält sich nicht immer wie Tailscale, das direkt auf einem Linux-Host installiert ist. Der Autor wollte einen vollwertigen Host-Daemon mit einem echten TUN-Gerät, damit ZimaOS selbst als Subnetzrouter oder Exit-Node fungieren und Ressourcen einbinden kann, die über das Tailnet erreichbar sind. Da ZimaOS ein appliance-artiges, schreibgeschütztes Root-Dateisystem und kein herkömmliches apt install tailscale Pfad verpackte der Autor Tailscale als systemd-sysext
Erweiterung. Dies ist ein Community-Projekt und kein von IceWhale unterstütztes Tailscale-Paket; Befehle und Lebenszyklus sollten daher entsprechend gekennzeichnet werden.
Warum Tailscale auf dem Host ausführen? Der Autor der Quelle beschrieb die Userspace-Netzwerkfunktion von Docker als ausreichend für gewöhnliche Verbindungen, aber umständlich für Routing auf Hostebene. Ein nativer Daemon kann direkt das TUN-Gerät des Kernels verwenden und sich integrieren.systemctl
, IP-Weiterleitung, Subnetzrouten und Exit-Node-Verhalten.
Warum systemd-sysext zu ZimaOS passt systemd-sysext legt zusätzliche Dateien an Orten wie /usr /DATA/AppData/tailscale/.
zur Laufzeit, ohne das unveränderliche Basis-Image zu ändern. Der Autor orientierte sich am Buildroot-Layout von Tailscale und speicherte den persistenten Authentifizierungsstatus unter
Das Projekt stellt ein Installationsskript für den Host bereit Der Quickstart-Ablauf des Community-Repositorys klont das Projekt, führt das Installationsprogramm mit sudo aus und authentifiziert sich anschließend mittailscale up
. Da es sich um Code von Drittanbietern handelt, der als Root ausgeführt wird, solltest du das Repository und die Versionshistorie vor der Ausführung prüfen.
Lies das aktuelle sysext-Projekt und die gepflegten Installationshinweise, statt eine alte Forenversion zu kopieren.
Der Projektstatus bleibt außerhalb der temporären Erweiterung erhalten /DATA/AppData/tailscale/Dadurch bleibt die Tailscale-Identität beim erneuten Erstellen oder Ersetzen von .raw sysext-Datei.
Nach der ersten Veröffentlichung wurde ein echter Neustartfehler entdeckt
Ein Benutzer meldete, dass tailscaled nach dem Neustart nicht gestartet wurde. Der Projektautor reproduzierte das Problem und erklärte das Wettrennen: multi-user.target Dienstabhängigkeiten auflöste, bevor systemd-sysext.service die Erweiterung bereits zusammengeführt hatte, sodass die Service-Unit zu dem Zeitpunkt, als systemd das Ziel erstellte, noch nicht existierte.
v1.0.1: Watchdog-Timer hinzugefügt
Der Autor behob das Startwettrennen mit einem kleinen Timer und einem Oneshoot-Dienst, die im persistenten Root-Dateisystem unter /etc/systemd/system/Es läuft kurz nach dem Systemstart und startet tailscaled sobald das sysext-Overlay vorhanden ist.
Der Autor der Quelle berichtete, dass er die Fehlerbehebung bei einem echten Neustart überprüft habe.
Die Einstellungen für die IP-Weiterleitung waren eine separate Frage zur Persistenz
Der Thread fragte außerdem, ob die sysctl-Einstellungen des Subnetzrouters einen Neustart überstehen. Der Autor erklärte, dass ZimaOS die Einstellungen für die IP-Weiterleitung dauerhaft speichert. /etc über ein Overlay, das durch persistenten Speicher gesichert wird, sodass die Konfiguration unter /etc/sysctl.d/ überlebt und erneut angewendet.
Diese Weiterleitungseinstellungen werden für die Verwendung als Subnetz-Router oder Exit-Node benötigt, nicht für einen gewöhnlichen Tailscale-Client.
Die IPv6-Einschränkung änderte sich mit dem ZimaOS-Kernel
Das ursprüngliche Modul vom Mai 2026 dokumentierte fehlende IPv6-Richtlinienrouting-Kerneloptionen unter ZimaOS 1.6.1/Kernel 6.12.25, wodurch Tailscale getunneltes IPv6 deaktivierte.
Am 30. Juli aktualisierte der Autor den Thread, weil der neuere Kernel von IceWhale die erforderlichen IPv6-Funktionen bereitstellte. Das aktuelle Projekt-Repository bestätigt den IPv6-Tailnet-Betrieb unter ZimaOS 1.7.0/Kernel 6.18.9.
Installationsprogramm nach ZimaOS-Updates erneut ausführen
Das Projekt ist darauf ausgelegt, die Sysext aus offiziellen statischen Tailscale-Binärdateien neu zu erstellen und den Authentifizierungsstatus separat zu bewahren. Das Repository empfiehlt derzeit, das Installationsprogramm nach einem ZimaOS-Upgrade erneut auszuführen.
Behandle ein Community-Modul auf Root-Ebene wie Systemsoftware
Dieses Modul läuft direkt auf dem NAS-Host, und sein Installationsprogramm verfügt über erhöhte Berechtigungen. Prüfe Quellcode, Hashes, Aktualisierungsverhalten und Deinstallationsverhalten, bevor du es auf einem System mit wichtigen Daten einsetzt.
Das Projekt wurde unter ZimaOS 1.7.0 erneut verifiziert
Das aktuelle Repository berichtet von einem erfolgreichen End-to-End-Test unter ZimaOS 1.7.0 mit Kernel 6.18.9, einschließlich persistenter Funktion nach Neustarts und funktionierendem Tailnet-IPv6. Das ist eine stärkere Evidenz als der ursprüngliche Beitrag vom Mai 2026, der für ZimaOS 1.6.1 entwickelt wurde.
Docker und native Sysext erfüllen unterschiedliche Anforderungen
Wenn du nur ausgewählte Anwendungen über Tailscale erreichbar machen möchtest, kann der Docker-Weg einfacher sein und die Änderungen am Host auf ein Minimum beschränken. Der Sysext-Weg ist attraktiv, wenn der ZimaOS-Host selbst Tailnet-Ressourcen einbinden, LAN-Subnetze bekannt geben oder als Exit-Node fungieren soll.
Ersetze eine funktionierende Docker-Installation nicht einfach deshalb, weil der native Ansatz existiert. Entscheide danach, ob Routing auf Host-Ebene tatsächlich erforderlich ist.
Deinstallation und vollständige Entfernung sind unterschiedliche Vorgänge
Das Community-Projekt trennt bewusst das Entfernen der Sysext vom Löschen des Tailscale-Zustands. Der normale Deinstallationspfad kann die persistenten Node-Daten beibehalten, während eine vollständige Entfernung auch das Zustandsverzeichnis löscht. Dieser Unterschied ist wichtig, wenn du eine Neuinstallation planst, ohne eine weitere Tailnet-Identität zu erstellen.
Der Boot-Watchdog ist weiterhin Bestandteil des Designs
Die aktuelle Projektdokumentation besagt, dass der Watchdog auch unter ZimaOS 1.7.0 weiterhin erforderlich ist, da die Service-Unit innerhalb der Sysext beim anfänglichen Zusammenstellen des systemd-Ziels weiterhin übergangen werden kann. Der neuere Kernel hat die IPv6-Fähigkeit behoben, nicht jedoch das Race-Problem bei der Reihenfolge der Sysext-Services.
FAQ zu nativem Tailscale
Ist dies ein offizielles IceWhale-Tailscale-Paket?
Nein. Es handelt sich um ein Community-Projekt für systemd-sysext.
Warum sollte man es statt Docker verwenden?
Das Projekt zielt auf TUN auf Host-Ebene, Subnetz-Router, Exit-Node und eine normale systemd-Integration ab.
Wurde das Problem mit dem Start nach einem Neustart behoben?
Der Autor des Projekts konnte das Problem reproduzieren und hat in v1.0.1 eine auf einem Watchdog basierende Lösung veröffentlicht.
Gilt die Einschränkung für IPv6 aus Version 1.6.1 weiterhin?
Das Projekt berichtet, dass der neuere, von ZimaOS 1.7.0 verwendete Kernel 6.18.9 die erforderliche Unterstützung für IPv6-Richtlinienrouting bereitstellt.
