Solución de la comunidad

ZimaOS Tailscale indica que el servicio no está disponible: usa la IP de Tailscale

A June 2026 ZimaOS thread where Tailscale appeared unavailable after restart. Diagnostics showed a healthy container, and the phone connected successfully after using the server’s 100.x Tailscale IP instead of its LAN address.

Un usuario de ZimaOS creyó que Tailscale había fallado después de su primer lanzamiento porque la página de la aplicación mostraba «servicio no disponible» y un teléfono no podía acceder a los servicios del servidor doméstico. Los diagnósticos del contenedor mostraron un resultado diferente: Tailscale estaba en ejecución, el dispositivo estaba autorizado y los montajes del estado y del túnel estaban presentes.

El problema confirmado era la dirección utilizada desde el teléfono. El usuario intentaba acceder a una dirección LAN doméstica normal sin configurar el enrutamiento de subredes. Al conectarse al servicio mediante la dirección de Tailscale del dispositivo ZimaOS 100.x.x.x la dirección funcionaba.

El contenedor de Tailscale no había fallado

El síntoma inicial sugería que el contenedor se había detenido después de reiniciarse, pero el estado recopilado mostró lo siguiente:

  • El estado del contenedor era «en ejecución», con código de salida 0.
  • Tailscale pasó de Iniciando a En ejecución.
  • La máquina estaba autorizada en el tailnet del usuario.
  • El directorio de estado persistente estaba asignado al contenedor.
  • El dispositivo TUN requerido por Tailscale también estaba asignado.
  • El dispositivo recibió una dirección IPv4 de Tailscale y pudo ver a sus pares.

Esta evidencia distinguió un mensaje de la página de la aplicación o de la interfaz web de ZimaOS del estado del propio demonio de Tailscale.

Por qué los primeros intentos de diagnóstico mostraron «Permiso denegado»

La sesión de terminal utilizó un usuario normal de ZimaOS. El primer listado de Docker se ejecutó con privilegios elevados, pero los comandos posteriores intentaron acceder al socket de Docker sin ellos y, por tanto, devolvieron errores de permisos. Las comillas curvas copiadas del foro también impidieron que algunas sustituciones de comandos se interpretaran correctamente.

Esos mensajes de permisos describían la sesión de diagnóstico, no un fallo de Tailscale durante su funcionamiento. El resultado posterior, obtenido con los privilegios adecuados, mostró que el contenedor estaba en buen estado.

Una dirección LAN doméstica no es automáticamente una dirección de Tailscale

Una dirección como 10.0.0.93 pertenece a la LAN doméstica. Un teléfono conectado de forma remota al mismo tailnet no obtiene automáticamente una ruta a todas las direcciones LAN privadas.

Tailscale asigna a cada nodo su propia dirección, normalmente en el rango 100.x.x.x. La documentación oficial sobre direcciones IP de Tailscale explica que estas direcciones identifican los dispositivos dentro del tailnet y permanecen separadas de las direcciones LAN habituales.

El método de conexión que funcionó

El encargado de responder pidió al usuario que se conectara a la aplicación mediante la IP de Tailscale del nodo de ZimaOS y el puerto propio de la aplicación:

http://TAILSCALE-IP:APP-PORT

Por ejemplo, un servicio en el puerto 8096 usaría una URL con el siguiente formato:

http://100.x.x.x:8096

El teléfono también debe haber iniciado sesión en el mismo tailnet y estar conectado activamente a Tailscale. El usuario confirmó que esta dirección funcionaba, lo que demostró que Tailscale funcionaba correctamente.

Cuándo se requiere el enrutamiento de subredes

Si el objetivo es acceder a los dispositivos mediante sus direcciones LAN existentes, como 10.0.0.x—un dispositivo de esa red debe anunciar la subred de la LAN como una ruta, y la ruta debe aprobarse según la configuración de la tailnet.

Esta configuración es distinta de acceder directamente al host de ZimaOS mediante su propia IP de Tailscale. Consulta la documentación oficial sobre enrutadores de subred de Tailscale antes de esperar que las direcciones normales de la LAN funcionen de forma remota.

Por qué la página de la aplicación aún podía mostrar «Servicio no disponible»

Una comprobación de disponibilidad de la interfaz web puede fallar aunque el demonio de red esté en ejecución. En el caso original, las pruebas decisivas fueron el estado en ejecución, la autorización correcta en la tailnet, la IP de Tailscale asignada, los pares visibles y una conexión funcional al servicio remoto.

Cambiar puertos de aplicaciones al azar, eliminar el estado de Tailscale o reinstalar repetidamente el contenedor no resolvería una dirección de destino incorrecta. Verifica el estado del demonio y el método de conexión antes de restablecer una identidad que funciona.

Por qué la conexión funcional podía parecer lenta

La respuesta final indicó que la conexión podría estar usando una retransmisión DERP en lugar de una ruta directa entre pares. El tráfico de Tailscale retransmitido puede funcionar correctamente y, aun así, ofrecer un menor rendimiento o una latencia más alta, según las redes, los enrutadores y la región de retransmisión disponible.

La lentitud por sí sola no demuestra que el contenedor esté fallando. Primero confirma si la conexión funciona y si Tailscale informa de una ruta directa o retransmitida; después, si el rendimiento es importante, investiga el comportamiento de la NAT y del firewall.

Un orden de diagnóstico más seguro

  1. Comprueba si el contenedor de Tailscale está en ejecución en lugar de basarte únicamente en el estado de la página de la aplicación.
  2. Confirma que el nodo de ZimaOS aparezca como autorizado y conectado en la misma tailnet que el teléfono.
  3. Identifica la dirección de Tailscale del nodo de ZimaOS 100.x.x.x dirección mediante la interfaz de Tailscale o la consola de administración.
  4. Conéctate al servicio de destino usando esa dirección de Tailscale y el puerto del servicio.
  5. Configura el enrutamiento de subred solo si se necesita acceder mediante las direcciones normales de la LAN doméstica.
  6. Investiga por separado el uso de retransmisión DERP si la conexión funciona pero es lenta.

Preguntas frecuentes sobre la conexión de Tailscale en ZimaOS

¿«Servicio no disponible» demuestra que Tailscale se detuvo?

No. En este caso, el contenedor estaba en ejecución, autorizado y conectado, aunque la página de la aplicación mostrara ese mensaje.

¿Por qué no ayudó cambiar el puerto de la aplicación de Tailscale?

El problema era la dirección de destino, no un conflicto normal de puertos de una aplicación web. El usuario necesitaba la IP de Tailscale del nodo.

¿Qué dirección debe usar un teléfono remoto?

Usa Tailscale del nodo de ZimaOS 100.x.x.x la dirección y el puerto de la aplicación, a menos que se haya configurado un enrutador de subred para las direcciones de la LAN.

¿Por qué falla una dirección 10.0.0.x a través de Tailscale?

Es una dirección privada de la LAN doméstica. Para acceder a esa subred de forma remota se necesita una ruta de subred anunciada y aprobada.

¿Por qué puede ser lenta una conexión de Tailscale que funciona?

La conexión puede retransmitirse mediante DERP en lugar de usar una ruta directa entre pares.