La aplicación normal de Tailscale para Docker es práctica, pero una VPN en contenedor no siempre se comporta como Tailscale instalado directamente en un host Linux. El autor original quería un demonio de host de primera clase con un dispositivo TUN real para que ZimaOS pudiera actuar como enrutador de subred o nodo de salida y montar recursos accesibles a través de la tailnet.
Debido a que ZimaOS tiene una raíz de solo lectura al estilo de un dispositivo y no dispone de un apt install tailscale ruta, el autor empaquetó Tailscale como una systemd-sysext extensión. Este es un proyecto comunitario, no un paquete de Tailscale respaldado por IceWhale, por lo que sus comandos y ciclo de vida deben etiquetarse como corresponde.
¿Por qué ejecutar Tailscale en el host?
El autor original describió las redes en el espacio de usuario de Docker como suficientes para la conectividad habitual, pero poco prácticas para el enrutamiento a nivel del host. Un demonio nativo puede usar directamente el dispositivo TUN del kernel e integrarse con systemctl, el reenvío de IP, las rutas de subred y el comportamiento del nodo de salida.
Por qué systemd-sysext encaja con ZimaOS
systemd-sysext superpone archivos adicionales en ubicaciones como /usr en tiempo de ejecución sin modificar la imagen base inmutable. El autor reprodujo la estructura de Buildroot original de Tailscale y almacenó el estado de autenticación persistente en /DATA/AppData/tailscale/.
El proyecto proporciona un script de instalación en el host
El flujo de inicio rápido del repositorio comunitario clona el proyecto, ejecuta su instalador con sudo y luego se autentica con tailscale up. Dado que se trata de código de terceros que se ejecuta como root, revisa el repositorio y el historial de versiones antes de ejecutarlo.
Lee el proyecto sysext actual y sus notas de instalación mantenidas en lugar de copiar una versión antigua del foro.
El estado de autenticación vive fuera de la extensión desechable
El proyecto mantiene el estado del nodo en /DATA/AppData/tailscale/. Esto permite que la identidad de Tailscale sobreviva a la reconstrucción o sustitución de .raw archivo sysext.
Se encontró un error de reinicio real después del lanzamiento inicial
Un usuario informó que tailscaled no se iniciaba después del reinicio. El autor del proyecto reprodujo el problema y explicó la condición de carrera: multi-user.target resolvió las dependencias del servicio antes de systemd-sysext.service había fusionado la extensión, por lo que la unidad de servicio no existía cuando systemd compiló el destino.
v1.0.1 añadió un temporizador de vigilancia
El autor solucionó la condición de carrera durante el arranque con un pequeño temporizador y un servicio oneshot almacenados en la raíz persistente en /etc/systemd/system/Se ejecuta poco después del arranque e inicia tailscaled una vez que la superposición de sysext está presente.
El autor original informó que verificó la solución tras un reinicio real.
La configuración de reenvío de IP planteaba una cuestión de persistencia independiente
El hilo también preguntaba si la configuración de sysctl del enrutador de subred sobrevive al reinicio. El autor explicó que ZimaOS conserva /etc mediante una superposición respaldada por almacenamiento persistente, por lo que la configuración de /etc/sysctl.d/ sobrevive y se vuelve a aplicar.
Esos ajustes de reenvío son necesarios para usar el enrutador de subred o el nodo de salida, no para un cliente normal de Tailscale.
La limitación de IPv6 cambió con el kernel de ZimaOS
El módulo original de mayo de 2026 documentaba la ausencia de opciones del kernel para el enrutamiento basado en políticas IPv6 en ZimaOS 1.6.1/kernel 6.12.25, lo que hacía que Tailscale desactivara el IPv6 tunelizado.
El 30 de julio, el autor actualizó el hilo porque el kernel más reciente de IceWhale proporcionaba las capacidades IPv6 necesarias. El repositorio actual del proyecto verifica el funcionamiento de la tailnet IPv6 en ZimaOS 1.7.0/kernel 6.18.9.
Vuelve a ejecutar el instalador después de actualizar ZimaOS
El proyecto está diseñado para reconstruir el sysext a partir de binarios estáticos oficiales de Tailscale y conservar el estado de autenticación por separado. Actualmente, el repositorio recomienda volver a ejecutar el instalador después de actualizar ZimaOS.
Trata un módulo comunitario con privilegios de root como software del sistema
Este módulo se ejecuta directamente en el host NAS y su instalador tiene privilegios elevados. Revisa el código fuente, los hashes, el comportamiento de las actualizaciones y el de la desinstalación antes de implementarlo en un sistema que contenga datos importantes.
El proyecto se volvió a verificar en ZimaOS 1.7.0
El repositorio actual informa de una prueba completa y satisfactoria en ZimaOS 1.7.0 con el kernel 6.18.9, incluida la persistencia tras reinicios y el funcionamiento de IPv6 en la tailnet. Esto constituye una evidencia más sólida que la publicación original de mayo de 2026, desarrollada para ZimaOS 1.6.1.
Docker y sysext nativo resuelven necesidades diferentes
Si solo necesitas que determinadas aplicaciones sean accesibles a través de Tailscale, la opción de Docker puede ser más sencilla y mantiene al mínimo las modificaciones del host. La opción sysext resulta atractiva cuando el propio host ZimaOS necesita montar recursos de la tailnet, anunciar subredes LAN o actuar como nodo de salida.
No reemplaces una instalación funcional de Docker simplemente porque exista el enfoque nativo. Elige según si realmente necesitas el enrutamiento en el nivel del host.
Desinstalar y purgar son operaciones diferentes
El proyecto comunitario separa deliberadamente la eliminación del sysext del borrado del estado de Tailscale. Su proceso normal de desinstalación puede conservar los datos persistentes del nodo, mientras que una purga también elimina el directorio de estado. Esta distinción importa si pretendes reinstalarlo sin crear otra identidad de tailnet.
El watchdog de arranque sigue formando parte del diseño
La documentación actual del proyecto indica que el watchdog sigue siendo necesario incluso en ZimaOS 1.7.0, porque la unidad de servicio dentro del sysext todavía puede no detectar el ensamblaje inicial del destino de systemd. El kernel más reciente solucionó la capacidad de IPv6, no la condición de carrera en el orden de los servicios del sysext.
Preguntas frecuentes sobre Tailscale nativo
¿Es un paquete oficial de Tailscale de IceWhale?
No. Es un proyecto comunitario de systemd-sysext.
¿Por qué usarlo en lugar de Docker?
El proyecto está orientado al uso de TUN en el nivel del host, enrutador de subred, nodo de salida e integración normal con systemd.
¿Se solucionó el problema de inicio tras el reinicio?
El autor del proyecto reprodujo el problema y publicó una solución basada en un watchdog en la versión v1.0.1.
¿IPv6 todavía tiene la limitación de la versión 1.6.1?
El proyecto informa que el kernel 6.18.9 más reciente utilizado por ZimaOS 1.7.0 proporciona la compatibilidad necesaria con el enrutamiento basado en políticas IPv6.
