Der entscheidende Fehler in diesem Thread vom September 2025 bestand darin, die modprobe tun das Fehlschlagen als Beweis dafür, dass ZimaOS überhaupt keine TUN-Unterstützung habe. Zima-Jerry korrigierte diese Annahme: Im Quell-Build war TUN direkt in den Kernel kompiliert, daher gab es keine separate tun.ko Datei unter /lib/modules für modprobe zu laden.
Der konkrete Docker-Workflow des Benutzers für einen Subnetzrouter benötigte jedoch weiterhin das von Tailscale erwartete Geräte-/Modulverhalten. IceWhale änderte daher die Paketierung in ZimaOS 1.5.0, sodass TUN zu einem ladbaren Kernelmodul wurde. Der ursprüngliche Verfasser testete am 29. September erneut und antwortete, dass es nun funktioniere.
Der Benutzer wollte einen standortübergreifenden Tailscale-Subnetzrouter
Die Quelldesigns verbanden zwei physische Standorte, Mexiko und Uruguay, und sollten es lokalen Geräten an jedem Standort ermöglichen, über Tailscale miteinander zu kommunizieren, ohne Tailscale auf jedem Endpunkt zu installieren.
Das ist ein Anwendungsfall für einen Subnetzrouter, nicht bloß für „Fernzugriff auf das ZimaOS-Dashboard“. Ein Subnetzrouter muss Pakete zwischen dem Tailnet und einem anderen IP-Subnetz weiterleiten.
modprobe meldete, dass keine tun-Moduldatei vorhanden sei
Der Benutzer startete einen privilegierten Tailscale-Container und sah:
modprobe: FATAL: Module tun not found in directory /lib/modules/6.12.25Außerdem fanden sie kein tun.ko Datei erscheinen; außerdem wurde in der Ausgabe der Modulprüfungen kein TUN-Eintrag gefunden.
IceWhale sagte, dass TUN direkt in den Kernel kompiliert wurde
Die erste offizielle Antwort von Zima-Jerry war eindeutig: Die TUN-Funktionalität war direkt in den Kernel integriert und würde daher nicht als normale Moduldatei in /lib/modules/6.12.25.
Dies ist eine Unterscheidung des Linux-Kernels: Eine als integriert konfigurierte Funktion ist vorhanden, ohne in lsmod oder geladen werden kann durch modprobe.
Die integrierte Unterstützung löste den Container-Workflow der Quelle nicht vollständig
Der ursprüngliche Verfasser antwortete, dass sein Container weiterhin in den Userspace-Modus wechselte und nicht das vollständige subnetzrouterartige Verhalten des Hosts bereitstellen konnte, das er benötigte. Er fragte ausdrücklich, ob TUN auf modulare Weise bereitgestellt werden könne.
Zima-Jerry sagte, dies könne in der nächsten Version angepasst werden.
ZimaOS 1.5.0 änderte TUN in ein ladbares Modul
Am 28. September schrieb Zima-Jerry, dass in der neuen Version 1.5.0 tun.ko war zu einem Kernelmodul geworden und bat den Benutzer, den Test zu wiederholen.
Der ursprüngliche Verfasser antwortete am nächsten Tag: „Danke, jetzt funktioniert es.“
Das ist eine durch die Quelle bestätigte Lösung und die wichtigste Schlussfolgerung des Threads.
Das Userspace-Netzwerk von Tailscale ist ein anderer Betriebsmodus
In der aktuellen Tailscale-Dokumentation wird erklärt, dass Container ohne TUN-Gerät ausgeführt werden können, indem sie das Userspace-Netzwerk verwenden. In diesem Modus, tailscaled arbeitet über einen Userspace-Netzwerk-Stack/Proxy, anstatt sich wie eine normale Linux-Tunnelschnittstelle zu verhalten.
Verwenden Sie Tailscales aktuelles Userspace-Vernetzungsmodell, wenn Sie entscheiden, ob Kernel-TUN tatsächlich erforderlich ist.
Aktuelles Tailscale kann Subnetze im Kernel- oder Userspace-Modus routen
Die aktuelle Tailscale-Dokumentation beschreibt inzwischen sowohl die Subnet-Routenführung im Kernelmodus als auch im Userspace-/Netstack-Modus. Der Kernelmodus unter Linux bewahrt das normale Verhalten der Paketweiterleitung und bietet im Allgemeinen eine bessere Leistung; der Userspace-Modus kann ebenfalls routen, beendet den Datenverkehr jedoch in seinem eigenen Netzwerk-Stack und erstellt ihn dort neu.
Für Docker dokumentiert Tailscale aktuell außerdem, dass TS_USERSPACE ist standardmäßig aktiviert, während der Kernelmodus /dev/net/tun und die erforderlichen Berechtigungen.
Ein funktionierendes TUN-Gerät ist nicht die vollständige Subnet-Router-Konfiguration
Ein Linux-Subnet-Router benötigt außerdem IP-Weiterleitung, angekündigte Routen, Routengenehmigung in der Tailscale-Administrationskonsole und geeignete Tailnet-Zugriffsregeln. Ein Container, der erfolgreich ein tailscale0 bedeutet nicht automatisch, dass entfernte LAN-Geräte darüber geroutet werden können.
Befolgen Sie den aktuellen Tailscale-Workflow für Subnet-Router, nachdem die ZimaOS-Kernel-/Geräteebene funktioniert.
Wenden Sie die Diagnose „Fehlendes tun.ko“ aus Version 1.4.x nicht auf das aktuelle ZimaOS an
Die Quelle selbst dokumentiert die Versionsgrenze: Die Datei fehlte aufgrund der Art, wie der 1.4.x-Kernel erstellt wurde, und ZimaOS 1.5.0 änderte die TUN-Funktion in ein Modul. Das aktuelle ZimaOS ist inzwischen weit über diese Version hinaus.
Bei einem aktuellen Fehler sollten die aktuellen Container-Einstellungen, die Verfügbarkeit des TUN-Geräts, der Userspace-/Kernel-Modus, die IP-Weiterleitung und die Routengenehmigung überprüft werden, statt anzunehmen, dass das Kernel-Paketierungsproblem von 2025 zurückgekehrt ist.
Tailscale-TUN-FAQ
Bewies das Fehlschlagen von modprobe tun, dass ZimaOS keine TUN-Unterstützung hatte?
Nein. IceWhale sagte, dass TUN direkt in den Quellkernel kompiliert wurde, anstatt als separates Modul ausgeliefert zu werden.
Was wurde in ZimaOS 1.5.0 geändert?
Zima-Jerry sagte tun.ko wurde zu einem ladbaren Kernelmodul.
Hat der ursprüngliche Verfasser bestätigt, dass die neue Version funktionierte?
Ja. Nach der Änderung auf 1.5.0 testeten sie erneut und sagten, dass es funktionierte.
