L’erreur clé dans cette discussion de septembre 2025 a été d’interpréter modprobe tun échec comme preuve que ZimaOS ne prenait pas du tout en charge TUN. Zima-Jerry a corrigé cette supposition : dans la version source, TUN était directement compilé dans le noyau, il n’y avait donc aucun fichier tun.ko fichier sous /lib/modules pour modprobe à charger.
Cependant, le flux de travail Docker spécifique de l’utilisateur pour le routeur de sous-réseau nécessitait toujours le comportement du périphérique et du module attendu par Tailscale. IceWhale a donc modifié le conditionnement dans ZimaOS 1.5.0 afin que TUN devienne un module du noyau chargeable. L’auteur du message initial a retesté le 29 septembre et a répondu que cela fonctionnait désormais.
L’utilisateur voulait un routeur de sous-réseau Tailscale intersites
La conception d’origine reliait deux sites physiques, le Mexique et l’Uruguay, et visait à permettre aux appareils locaux de chaque site de communiquer via Tailscale sans installer Tailscale sur chaque point d’extrémité.
Il s’agit d’un cas d’utilisation de routeur de sous-réseau, et non pas simplement d’un « accès à distance au tableau de bord de ZimaOS ». Un routeur de sous-réseau doit transférer des paquets entre le tailnet et un autre sous-réseau IP.
modprobe n’a signalé aucun fichier de module tun
L’utilisateur a exécuté un conteneur Tailscale privilégié et a vu :
modprobe : FATAL : Module tun introuvable dans le répertoire /lib/modules/6.12.25Ils n’ont également trouvé aucun tun.ko fichier et n’a trouvé aucune entrée TUN dans la sortie des vérifications listant les modules.
IceWhale a indiqué que TUN était directement compilé dans le noyau
La première réponse officielle de Zima-Jerry était explicite : la fonctionnalité TUN était directement intégrée au noyau, elle n’apparaissait donc pas comme un fichier de module normal dans /lib/modules/6.12.25.
Il s’agit d’une distinction du noyau Linux : une fonctionnalité compilée en dur est présente sans apparaître dans lsmod ou être chargeable par modprobe.
La prise en charge intégrée n’a pas entièrement résolu le fonctionnement du conteneur source
L’auteur du message initial a répondu que son conteneur passait toujours en mode espace utilisateur et ne pouvait pas fournir le comportement complet de routeur de sous-réseau côté hôte qu’il souhaitait. Il a notamment demandé si TUN pouvait être exposé sous forme de module.
Zima-Jerry a indiqué que cela pourrait être ajusté dans la prochaine version.
ZimaOS 1.5.0 a transformé TUN en module chargeable
Le 28 septembre, Zima-Jerry a indiqué que, dans la nouvelle version 1.5.0, tun.ko était devenu un module du noyau et a demandé à l’utilisateur de réessayer.
L’auteur du message initial a répondu le lendemain : « Merci, maintenant ça fonctionne. »
Il s’agit d’une correction confirmée par la source et de la conclusion la plus importante de la discussion.
La mise en réseau Tailscale en espace utilisateur est un mode de fonctionnement différent
La documentation actuelle de Tailscale explique que les conteneurs peuvent fonctionner sans périphérique TUN en utilisant la mise en réseau en espace utilisateur. Dans ce mode, tailscaled fonctionne via une pile réseau ou un proxy en espace utilisateur au lieu de se comporter comme une interface tunnel Linux normale.
Utilisez le modèle actuel de réseau en espace utilisateur de Tailscale pour déterminer si TUN du noyau est réellement nécessaire.
Tailscale actuel peut acheminer les sous-réseaux en mode noyau ou en mode espace utilisateur
La documentation actuelle de Tailscale décrit désormais le routage de sous-réseaux en mode noyau et en mode espace utilisateur/netstack. Sous Linux, le mode noyau conserve le comportement normal de redirection des paquets et offre généralement de meilleures performances ; le mode espace utilisateur peut également assurer le routage, mais termine et recrée le trafic pris en charge dans sa propre pile réseau.
Pour Docker, la documentation actuelle de Tailscale indique également que TS_USERSPACE est activé par défaut, tandis que le mode noyau nécessite /dev/net/tun et les capacités requises.
Un périphérique TUN fonctionnel ne constitue pas toute la configuration d’un routeur de sous-réseau
Un routeur de sous-réseau Linux nécessite également la redirection IP, la publication des routes, l’approbation des routes dans la console d’administration Tailscale et des règles d’accès au tailnet appropriées. Un conteneur qui crée avec succès tailscale0 ne signifie pas à lui seul que les appareils du réseau local distant peuvent y acheminer leur trafic.
Suivez le processus actuel de configuration d’un routeur de sous-réseau Tailscale une fois que la couche noyau/périphérique de ZimaOS fonctionne.
N’appliquez pas le diagnostic « tun.ko manquant » de la version 1.4.x aux versions actuelles de ZimaOS
Le texte source documente lui-même la limite entre les versions : le fichier était absent en raison de la manière dont le noyau 1.4.x avait été compilé, et ZimaOS 1.5.0 a transformé la fonctionnalité TUN en module. La version actuelle de ZimaOS est depuis longtemps passée à une version bien plus récente.
En cas de problème actuel, examinez les paramètres actuels du conteneur, la disponibilité du périphérique TUN, le mode espace utilisateur/noyau, la redirection IP et l’autorisation des routes, plutôt que de supposer que le problème de conditionnement du noyau de 2025 est réapparu.
FAQ TUN de Tailscale
L’échec de modprobe tun prouvait-il que ZimaOS ne prenait pas en charge TUN ?
Non. IceWhale a indiqué que TUN était compilé directement dans le noyau source plutôt que fourni sous forme de module séparé.
Qu’est-ce qui a changé dans ZimaOS 1.5.0 ?
Zima-Jerry a déclaré tun.ko est devenu un module de noyau chargeable.
L’auteur du message d’origine a-t-il confirmé que la nouvelle version fonctionnait ?
Oui. Ils ont effectué un nouveau test après la modification de la version 1.5.0 et ont indiqué que cela fonctionnait.
