Un contenedor de Tailscale puede aparecer como conectado sin funcionar como enrutador de subred. En este hilo de ZimaOS de abril de 2026, Tailscale se ejecutaba en Docker con la red del host, el modo privilegiado y /dev/net/tun montado, aunque la consola de administración de Tailscale indicaba que la máquina no exponía ninguna ruta. Navidrome funcionaba en la red local, pero no se podía acceder a él de forma remota a través de la tailnet.
El hilo no terminó con una solución confirmada por el autor original. En su lugar, otro miembro de la comunidad compartió una configuración funcional de un contenedor de BigBear Tailscale que anunciaba correctamente una subred de LAN en su propio entorno ZimaOS. Esa configuración es útil como referencia para solucionar problemas, pero no constituye una garantía compatible con IceWhale para todos los paquetes de aplicaciones de Tailscale.
Estar conectado a Tailscale no significa que se anuncien rutas de subred
La configuración original ya había completado la autenticación del dispositivo. El problema era específicamente de enrutamiento: los registros mostraban una lista de rutas vacía y la consola de administración de Tailscale no ofrecía ninguna ruta de subred para aprobar.
Esta distinción es importante porque un nodo normal de Tailscale solo se une a la tailnet. Un enrutador de subred tiene responsabilidades adicionales: debe anunciar uno o más prefijos de LAN y cumplir los requisitos de enrutamiento del sistema operativo necesarios para reenviar tráfico entre la tailnet y esa LAN.
La documentación actual de Tailscale describe los enrutadores de subred como puertas de enlace que anuncian redes privadas a los dispositivos de tailnet. También requiere el reenvío de IP en Linux y la aprobación de la ruta en la consola de administración de Tailscale, a menos que una autoApprovers la política gestiona la aprobación automáticamente.
documentación del enrutador de subred de Tailscale
La referencia funcional de la comunidad utilizaba TS_ROUTES
La respuesta de TomasSzwed utilizó un contenedor de BigBear Tailscale y configuró la subred mediante variables de entorno, en lugar de depender de un comando manual ejecutado una sola vez después del inicio. Entre los elementos importantes de esa referencia se incluían:
-
network_mode: host; - modo privilegiado;
-
/dev/net/tunmontado en el contenedor; -
TS_USERSPACE=false; -
TS_ROUTES=192.168.2.0/24para la LAN que se anuncia; -
TS_EXTRA_ARGS=--accept-routesen la configuración de ese usuario; - estado persistente de Tailscale en
/var/lib/tailscale.
Usa el prefijo de LAN correcto para tu red
El ejemplo funcional anunciado 192.168.2.0/24. Ese valor solo tiene sentido para una LAN que use esa subred. Otra red doméstica podría usar 192.168.1.0/24, 10.0.0.0/24, o cualquier otro prefijo privado.
Anunciar la subred incorrecta puede producir un nodo de Tailscale que esté activo, pero que aun así no pueda enrutar hacia los servicios de ZimaOS previstos. Determina el prefijo de red local real antes de configurarlo TS_ROUTES o un equivalente --advertise-routes opción.
Las rutas anunciadas aún deben activarse
Las directrices actuales de Tailscale separan el anuncio de rutas de la aprobación de rutas. Una vez que el enrutador de subredes anuncia una ruta, esta debe habilitarse en la consola de administración de Tailscale, a menos que la política de la tailnet la apruebe automáticamente.
Si la consola de administración indica que la máquina no expone ninguna ruta, céntrate primero en la configuración de anuncio de rutas del contenedor. Si la ruta aparece, pero el tráfico sigue sin funcionar, revisa la aprobación de la ruta, la política de control de acceso, el reenvío y el propio servicio de destino.
Las redes de Docker cambian lo que el contenedor puede enrutar
El autor original utilizó la red del host y montó el dispositivo TUN. La referencia de la comunidad hizo lo mismo. La documentación actual de Tailscale también admite ejecutar Tailscale en Docker, pero las redes de Docker y el enrutamiento de Tailscale son capas independientes que deben configurarse correctamente.
Documentación de Tailscale para Docker
No des por sentado que dos aplicaciones de Tailscale de la tienda de aplicaciones de ZimaOS utilizan definiciones de contenedor idénticas. El autor original señaló específicamente que el ejemplo compartido utilizaba el paquete de Tailscale de BigBear, mientras que su instalación existente utilizaba la otra entrada de Tailscale.
Qué significa esto para Navidrome y otros servicios locales
El objetivo del hilo original era acceder a Navidrome desde un iPhone sin configurar un reenvío de puertos público. Si Navidrome ya es accesible en la LAN local, un enrutador de subredes funcional puede hacer que esa dirección de la LAN sea accesible desde dispositivos autorizados de la tailnet.
Sin embargo, el hilo no confirma que el autor original completara el cambio a la configuración de BigBear ni que lograra acceder posteriormente a Navidrome. Por tanto, la página documenta una referencia viable de la comunidad y un modelo de diagnóstico, no una resolución confirmada para esa instalación concreta.
Preguntas frecuentes sobre el enrutamiento de subredes de Tailscale en ZimaOS
¿Por qué Tailscale indica que está conectado, pero no muestra rutas de subred?
Unirse a la tailnet y anunciar una ruta de LAN son operaciones diferentes. En el caso original, la autenticación se realizó correctamente, pero la lista de rutas permaneció vacía.
¿Puede Tailscale en Docker actuar como enrutador de subredes en ZimaOS?
Un miembro de la comunidad informó que funcionaba en su configuración de ZimaOS y compartió una configuración de Tailscale de BigBear. Tailscale también admite el enrutamiento de subredes y las implementaciones con Docker, pero la configuración exacta de la aplicación en ZimaOS sigue siendo importante.
¿Tengo que aprobar la ruta en Tailscale?
Según el comportamiento actual de Tailscale, las rutas de subred anunciadas normalmente necesitan aprobación en la consola de administración, a menos que autoApprovers la política los gestiona automáticamente.
¿Debo copiar 192.168.2.0/24 de la captura de pantalla?
No. Usa la subred real de la LAN que quieres exponer. El valor de la captura de pantalla pertenece a la red de otro miembro de la comunidad.
