L’application Docker Tailscale classique est pratique, mais un VPN conteneurisé ne se comporte pas toujours comme Tailscale installé directement sur un hôte Linux. L’auteur de la source voulait un démon hôte de première classe avec un véritable périphérique TUN afin que ZimaOS puisse lui-même agir comme routeur de sous-réseau ou nœud de sortie, et monter des ressources accessibles via le tailnet.
Comme ZimaOS possède une racine en lecture seule de type appliance et aucun apt install tailscale chemin, l’auteur a empaqueté Tailscale comme une systemd-sysext extension. Il s’agit d’un projet communautaire, et non d’un paquet Tailscale pris en charge par IceWhale ; ses commandes et son cycle de vie doivent donc être présentés comme tels.
Pourquoi exécuter Tailscale sur l’hôte ?
L’auteur de la source a décrit la mise en réseau en espace utilisateur de Docker comme suffisante pour une connectivité ordinaire, mais peu pratique pour le routage au niveau de l’hôte. Un démon natif peut utiliser directement le périphérique TUN du noyau et s’intégrer à systemctl, le transfert IP, les routes de sous-réseaux et le comportement du nœud de sortie.
Pourquoi systemd-sysext convient à ZimaOS
systemd-sysext superpose des fichiers supplémentaires dans des emplacements tels que /usr à l’exécution sans modifier l’image de base immuable. L’auteur a reproduit la structure Buildroot amont de Tailscale et stocké l’état d’authentification persistant sous /DATA/AppData/tailscale/.
Le projet fournit un script d’installation sur l’hôte
Le flux de démarrage rapide du dépôt communautaire clone le projet, exécute son programme d’installation avec sudo, puis authentifie avec tailscale up. Comme il s’agit de code tiers exécuté en tant que root, examinez le dépôt et l’historique des versions avant de l’exécuter.
Lisez le projet sysext actuel et ses notes d’installation maintenues plutôt que de copier une ancienne version du forum.
L’état d’authentification réside en dehors de l’extension éphémère
Le projet conserve l’état du nœud sous /DATA/AppData/tailscale/Cela permet à l’identité Tailscale de survivre à la reconstruction ou au remplacement de .raw fichier sysext.
Un véritable bogue de redémarrage a été découvert après la version initiale
Un utilisateur a signalé que tailscaled ne démarrait pas après un redémarrage. L’auteur du projet a reproduit le problème et expliqué la course : multi-user.target a résolu les dépendances des services avant systemd-sysext.service avait déjà fusionné l’extension, de sorte que l’unité de service n’existait pas au moment où systemd a construit la cible.
v1.0.1 a ajouté un minuteur de surveillance
L’auteur a corrigé la course au démarrage avec un petit minuteur et un service oneshot stockés sur la racine persistante sous /etc/systemd/system/Il s’exécute peu après le démarrage et lance tailscaled une fois la superposition sysext présente.
L’auteur de la source a indiqué avoir vérifié le correctif après un véritable redémarrage.
Les paramètres de transfert IP constituaient une question distincte de persistance
La discussion demandait également si les paramètres sysctl du routeur de sous-réseau survivaient à un redémarrage. L’auteur a expliqué que ZimaOS conserve /etc via une superposition reposant sur un stockage persistant, de sorte que la configuration sous /etc/sysctl.d/ survit et est réappliqué.
Ces paramètres de transfert sont nécessaires pour utiliser un routeur de sous-réseau ou un nœud de sortie, mais pas pour un client Tailscale ordinaire.
La limitation IPv6 a changé avec le noyau de ZimaOS
Le module original de mai 2026 documentait l’absence d’options du noyau pour le routage par politique IPv6 sur ZimaOS 1.6.1 avec le noyau 6.12.25, ce qui amenait Tailscale à désactiver l’IPv6 encapsulée.
Le 30 juillet, l’auteur a mis à jour la discussion, car le noyau plus récent d’IceWhale fournissait les capacités IPv6 requises. Le dépôt actuel du projet vérifie le fonctionnement de l’IPv6 dans le tailnet sur ZimaOS 1.7.0 avec le noyau 6.18.9.
Relancez le programme d’installation après les mises à jour de ZimaOS
Le projet est conçu pour reconstruire le sysext à partir des binaires statiques officiels de Tailscale et conserver séparément l’état d’authentification. Le dépôt recommande actuellement de relancer le programme d’installation après une mise à niveau de ZimaOS.
Traitez un module communautaire s’exécutant avec les privilèges root comme un logiciel système
Ce module s’exécute directement sur l’hôte NAS et son programme d’installation dispose de privilèges élevés. Examinez le code source, les sommes de contrôle, le comportement des mises à jour et celui de la désinstallation avant de le déployer sur un système contenant des données importantes.
Le projet a été revérifié sur ZimaOS 1.7.0
Le dépôt actuel fait état d’un test de bout en bout réussi sur ZimaOS 1.7.0 avec le noyau 6.18.9, incluant la persistance après redémarrage et le fonctionnement de l’IPv6 dans le tailnet. Il s’agit d’un élément plus probant que la publication originale de mai 2026, développée avec ZimaOS 1.6.1.
Docker et le sysext natif répondent à des besoins différents
Si vous avez seulement besoin que certaines applications soient accessibles via Tailscale, la solution Docker peut être plus simple et limiter les modifications de l’hôte. La solution sysext est intéressante lorsque l’hôte ZimaOS lui-même doit monter des ressources tailnet, annoncer des sous-réseaux LAN ou agir comme nœud de sortie.
Ne remplacez pas une installation Docker fonctionnelle simplement parce que l’approche native existe. Choisissez selon que le routage au niveau de l’hôte est réellement nécessaire ou non.
Désinstallation et purge sont deux opérations différentes
Le projet communautaire sépare délibérément la suppression du sysext de la suppression de l’état Tailscale. Son chemin de désinstallation normal peut conserver les données persistantes du nœud, tandis qu’une purge supprime également le répertoire d’état. Cette distinction est importante si vous prévoyez de réinstaller sans créer une autre identité tailnet.
Le watchdog de démarrage fait toujours partie de la conception
La documentation actuelle du projet indique que le watchdog reste nécessaire, même sur ZimaOS 1.7.0, car l’unité de service située dans le sysext peut encore manquer l’assemblage initial de la cible systemd. Le noyau plus récent a corrigé la capacité IPv6, mais pas la course liée à l’ordre de démarrage du service sysext.
FAQ sur Tailscale natif
S’agit-il d’un paquet Tailscale officiel d’IceWhale ?
Non. Il s’agit d’un projet communautaire systemd-sysext.
Pourquoi l’utiliser plutôt que Docker ?
Le projet vise l’intégration au niveau de l’hôte de TUN, d’un routeur de sous-réseau, d’un nœud de sortie et de systemd standard.
Le problème du démarrage après redémarrage a-t-il été corrigé ?
L’auteur du projet a reproduit le problème et publié un correctif basé sur un watchdog dans la version v1.0.1.
IPv6 présente-t-il toujours la limitation de la version 1.6.1 ?
Le projet indique que le noyau plus récent 6.18.9 utilisé par ZimaOS 1.7.0 fournit la prise en charge requise du routage par politique IPv6.
