El error clave en este hilo de septiembre de 2025 fue interpretar modprobe tun el fallo como prueba de que ZimaOS no tenía compatibilidad con TUN. Zima-Jerry corrigió esa suposición: en la compilación de origen, TUN estaba compilado directamente en el kernel, por lo que no había un archivo tun.ko archivo bajo /lib/modules para modprobe cargar.
Sin embargo, el flujo de trabajo específico del usuario con un enrutador de subred Docker seguía necesitando el comportamiento del dispositivo o módulo esperado por Tailscale. Por ello, IceWhale cambió el empaquetado en ZimaOS 1.5.0 para que TUN se convirtiera en un módulo del kernel cargable. El autor original volvió a probarlo el 29 de septiembre y respondió que ahora funcionaba.
El usuario quería un enrutador de subred Tailscale entre sitios
La fuente describía un diseño que conectaba dos ubicaciones físicas, México y Uruguay, y quería que los dispositivos locales de cada sitio se comunicaran mediante Tailscale sin instalar Tailscale en cada terminal.
Ese es un caso de uso de enrutador de subred, no simplemente «acceso remoto al panel de ZimaOS». Un enrutador de subred debe reenviar paquetes entre la red de Tailscale y otra subred IP.
modprobe no informó de ningún archivo de módulo tun
El usuario ejecutó un contenedor de Tailscale con privilegios y vio:
modprobe: FATAL: Module tun not found in directory /lib/modules/6.12.25Tampoco encontraron tun.ko el archivo y no vio ninguna entrada de TUN en la salida de las comprobaciones de listado de módulos.
IceWhale dijo que TUN estaba compilado directamente en el kernel
La primera respuesta oficial de Zima-Jerry fue explícita: la funcionalidad TUN estaba integrada directamente en el kernel, por lo que no aparecería como un archivo de módulo normal en /lib/modules/6.12.25.
Esta es una distinción del kernel de Linux: una función configurada como integrada está presente sin aparecer en lsmod o poder cargarse mediante modprobe.
La compatibilidad integrada no resolvió por completo el flujo de trabajo del contenedor de origen
El autor original respondió que su contenedor seguía pasando al modo de espacio de usuario y no podía proporcionar el comportamiento completo de enrutador de subred del host que quería. Preguntó específicamente si TUN podía exponerse de forma modular.
Zima-Jerry dijo que esto podría ajustarse en la siguiente versión.
ZimaOS 1.5.0 convirtió TUN en un módulo cargable
El 28 de septiembre, Zima-Jerry publicó que, en la nueva versión 1.5.0, tun.ko se había convertido en un módulo del kernel y pidió al usuario que volviera a probarlo.
El autor original respondió al día siguiente: «Gracias, ahora funciona».
Esa es una solución confirmada por la fuente y la conclusión más importante del hilo.
Las redes de Tailscale en el espacio de usuario son un modo de operación diferente
La documentación actual de Tailscale explica que los contenedores pueden ejecutarse sin un dispositivo TUN mediante redes en el espacio de usuario. En ese modo, tailscaled funciona mediante una pila de red/proxy de espacio de usuario, en lugar de comportarse como una interfaz de túnel normal de Linux.
Usa el modelo actual de redes de espacio de usuario de Tailscale al decidir si realmente se requiere TUN del kernel.
Tailscale Actual Puede Enrutar Subredes en Modo Kernel o de Espacio de Usuario
La documentación actual de Tailscale describe tanto el enrutamiento de subredes en modo kernel como en modo de espacio de usuario/netstack. El modo kernel en Linux conserva el comportamiento normal de reenvío de paquetes y, por lo general, ofrece un mejor rendimiento; el modo de espacio de usuario también puede enrutar, pero termina y vuelve a originar el tráfico compatible en su propia pila de red.
Para Docker, Tailscale también documenta actualmente que TS_USERSPACE está habilitado de forma predeterminada, mientras que el modo kernel requiere /dev/net/tun y las capacidades necesarias.
Un Dispositivo TUN Funcional No Es Toda la Configuración del Enrutador de Subred
Un enrutador de subred Linux también necesita reenvío de IP, rutas anunciadas, aprobación de rutas en la consola de administración de Tailscale y reglas de acceso adecuadas en tailnet. Que un contenedor cree correctamente tailscale0 no significa por sí solo que los dispositivos LAN remotos puedan enrutar el tráfico a través de él.
Sigue el flujo de trabajo actual del enrutador de subred de Tailscale después de que la capa de kernel/dispositivo de ZimaOS funcione.
No Apliques el Diagnóstico de «Falta tun.ko» de la Versión 1.4.x al ZimaOS Actual
El propio código fuente documenta el límite entre versiones: el archivo estaba ausente debido a cómo se compiló el kernel de la versión 1.4.x, y ZimaOS 1.5.0 cambió la función TUN a un módulo. El ZimaOS actual ha avanzado mucho desde esa versión.
Para un fallo actual, inspecciona la configuración actual del contenedor, la disponibilidad del dispositivo TUN, el modo de espacio de usuario/kernel, el reenvío de IP y la aprobación de rutas, en lugar de asumir que volvió el problema del empaquetado del kernel de 2025.
Preguntas frecuentes sobre TUN de Tailscale
¿Que fallara modprobe tun demostraba que ZimaOS no era compatible con TUN?
No. IceWhale dijo que TUN se compiló directamente en el kernel de origen, en lugar de distribuirse como un módulo independiente.
¿Qué cambió en ZimaOS 1.5.0?
Zima-Jerry dijo tun.ko se convirtió en un módulo del kernel que se puede cargar.
¿El autor original de la publicación confirmó que la nueva versión funcionaba?
Sí. Volvieron a probarlo después del cambio de la versión 1.5.0 y dijeron que funcionaba.
