Si la aplicación Tailscale se instala en ZimaOS, pero al hacer clic en su WebUI simplemente vuelves al panel de ZimaOS, eso no significa necesariamente que el contenedor de Tailscale esté averiado. El hilo de la comunidad de noviembre de 2024 comenzó exactamente con ese síntoma en ZimaOS 1.2.5. La corrección útil fue que Tailscale se configura principalmente mediante la autenticación, las variables de entorno y la CLI de Tailscale, no mediante una WebUI de aplicación convencional.
La respuesta original recomendaba usar el paquete de la App Store y proporcionar una clave de autenticación de Tailscale mediante TS_AUTHKEY. Un hilo posterior de ZimaOS de 2025 confirmó otra vía funcional: instalar Tailscale, ejecutar tailscale status en la CLI, abre la URL de inicio de sesión que devuelve y autentica el nodo. La documentación actual de Tailscale para Docker admite flujos basados tanto en claves de autenticación como en inicio de sesión, y también recomienda conservar el estado para que el contenedor mantenga la misma identidad de nodo tras los reinicios.
Por qué el enlace de «WebUI» de Tailscale puede resultar engañoso
El usuario original esperaba que la aplicación abriera una página de administración después de la instalación. En su lugar, el navegador volvió a la página de inicio de ZimaOS.
La solución original de la comunidad: usar TS_AUTHKEY
La primera respuesta indicaba que el paquete de la App Store podía funcionar creando una clave de autenticación de Tailscale y pegándola en:
TS_AUTHKEYLa documentación actual de Tailscale todavía define TS_AUTHKEY como variable de entorno utilizada para autenticar un contenedor de Docker en una tailnet.
Referencia actual: Parámetros de configuración de Tailscale para Docker.
Genera la clave en la consola de administración de Tailscale y trátala como un secreto. No la publiques en capturas de pantalla, publicaciones de foros, repositorios de Git ni archivos Compose compartidos.
Alternativa: autenticarse mediante la CLI de Tailscale
Una solución posterior de la comunidad de ZimaOS utilizó:
tailscale statusCuando el nodo aún no se había autenticado, Tailscale devolvió una URL de inicio de sesión. El usuario abrió esa URL en un navegador y aprobó el dispositivo.
Según el contenedor instalado y el contexto del shell, es posible que debas ejecutar el comando dentro del contenedor de Tailscale en lugar de hacerlo directamente en el host de ZimaOS.
Primero identifica el contenedor:
docker ps --format '{{.Names}}' | grep -i tailscaleDespués, si es necesario:
docker exec -it TAILSCALE_CONTAINER tailscale statusUsa el nombre real del contenedor que muestra tu sistema.
Conservar el estado de Tailscale entre reinicios
La documentación actual de Docker de Tailscale recomienda configurar:
TS_STATE_DIR=/var/lib/tailscaley montar ese directorio en un almacenamiento persistente del host. Sin un estado persistente, un contenedor reiniciado o recreado puede registrarse como un nodo nuevo en lugar de conservar su identidad anterior.
Tailscale también proporciona:
TS_AUTH_ONCE=truepara implementaciones que solo deban autenticarse cuando el contenedor no tenga un estado existente.
Qué necesita una configuración actual del contenedor
Una configuración conceptual mínima de Docker incluye:
environment:
- TS_AUTHKEY=YOUR_SECRET_KEY
- TS_STATE_DIR=/var/lib/tailscale
- TS_AUTH_ONCE=true
volumes:
- /YOUR/ZIMAOS/PERSISTENT/PATH:/var/lib/tailscaleLa ruta exacta del host y las configuraciones adicionales de red/dispositivo dependen de la definición de la aplicación en la tienda de aplicaciones de ZimaOS. No sustituyas una definición actual de la aplicación que funciona por un YAML antiguo de CasaOS únicamente porque el hilo de 2024 enlazara a un tutorial de CasaOS.
Acceder a ZimaOS es diferente de anunciar toda la LAN
Hay dos objetivos habituales:
- Acceder directamente al nodo de Tailscale: conéctate al nodo de ZimaOS/Tailscale mediante su dirección de Tailscale o su nombre de MagicDNS.
- Acceder a otros dispositivos de la LAN de ZimaOS: configura el nodo como un enrutador de subred de Tailscale.
El segundo objetivo es más complejo. La documentación actual de Tailscale requiere que el enrutador anuncie las rutas y que estas se aprueben en la consola de administración.
Consulta la documentación del enrutador de subred de Tailscale.
El enrutamiento de subred en una aplicación Tailscale de ZimaOS en Docker tiene requisitos adicionales
Un informe de la comunidad de ZimaOS de 2026 mostró un contenedor Docker de Tailscale que se conectaba correctamente, pero no lograba anunciar las rutas de la LAN. Esa configuración usaba la red del host, el modo privilegiado y /dev/net/tun, pero las rutas de subred aún no aparecían.
Este es un límite importante: un contenedor que se conecta correctamente a tu tailnet no se convierte automáticamente en un enrutador de subred funcional. El enrutamiento requiere privilegios de kernel/red, reenvío, anuncio de rutas y aprobación del administrador.
Si tu único objetivo es acceder al propio ZimaOS de forma remota, no habilites innecesariamente el enrutamiento de subred.
Tailscale no requiere acceso de invitado para SMB
La respuesta de la comunidad de 2024 afirmaba que el uso compartido de carpetas SMB necesitaba permisos de invitado para funcionar a través del túnel de Tailscale. Esto no debería generalizarse como un requisito actual de Tailscale.
Tailscale proporciona conectividad de red. La autenticación de SMB sigue siendo una capa independiente de permisos de Samba/Windows/macOS. Una cuenta SMB con nombre y correctamente configurada puede funcionar a través de una conexión de Tailscale igual que a través de una LAN.
El acceso de invitado pudo haber sido una solución alternativa para la configuración específica de Samba de CasaOS/ZimaOS en aquella discusión antigua, pero no es una característica inherente a Tailscale.
Notas de seguridad
- Usa una clave de autenticación con permisos limitados, reutilizable o efímera, según las necesidades de tu implementación.
- Mantén las claves de autenticación fuera de las capturas de pantalla y los repositorios.
- Conserva el estado para que el nodo no tenga que registrarse de nuevo repetidamente.
- Usa las ACL o las concesiones de Tailscale para controlar qué dispositivos del tailnet pueden acceder al nodo de ZimaOS.
- No expongas directamente el panel de ZimaOS a Internet pública solo porque necesites acceso remoto.
Lista de comprobación para configurar Tailscale en ZimaOS
- Instala el paquete actual de Tailscale de la tienda de aplicaciones.
- No dependas del enlace de la WebUI de la aplicación como método principal de configuración.
- Autentica con
TS_AUTHKEYo la URL de inicio de sesión de la CLI de Tailscale. - Conserva
/var/lib/tailscaleusandoTS_STATE_DIR. - Verifica que el nodo aparezca en la consola de administración de Tailscale.
- Ejecuta
tailscale statusy confirma que el nodo está conectado. - Prueba el acceso al nodo de ZimaOS antes de intentar configurar el enrutamiento de subred
- Si necesitas toda la LAN, configura y aprueba las rutas de subred por separado.
Preguntas frecuentes sobre ZimaOS y Tailscale
¿Por qué el enlace de la WebUI de Tailscale vuelve a ZimaOS?
El contenedor de Tailscale normalmente se configura mediante variables de entorno, autenticación y comandos de la CLI, en lugar de una WebUI convencional de la aplicación. El hilo original mostraba exactamente esta confusión.
¿Qué es TS_AUTHKEY?
Es la variable de entorno de Docker de Tailscale que se utiliza para autenticar el contenedor en tu tailnet.
¿Por qué debería conservar TS_STATE_DIR?
El estado persistente permite que el contenedor conserve la identidad de su nodo y la autenticación después de reiniciarse o recrearse.
¿Necesito el enrutamiento de subred para acceder a ZimaOS de forma remota?
No. El enrutamiento de subred solo es necesario cuando el nodo de Tailscale debe enrutar tráfico hacia otros dispositivos de la red local que no usan Tailscale.
¿SMB necesita el modo Invitado a través de Tailscale?
No como regla general de Tailscale. La autenticación de la cuenta SMB es independiente de la red de Tailscale.
