Un contenedor permanente de Tailscale debería seguir siendo la misma máquina en la consola de administración de Tailscale después de reiniciar ZimaOS o editar la aplicación. En el hilo de la fuente de septiembre de 2025, eso no ocurría: cada reinicio o nueva implementación creaba otro nodo de Tailscale aunque el archivo Compose ya montaba /var/lib/tailscale al AppData persistente de ZimaOS.
El resultado final de la fuente es importante porque acota la causa. El autor original indicó que el almacenamiento persistente ya era correcto; eliminar la variable de entorno de la clave de autenticación suministrada continuamente fue el único cambio que necesitó. Después de eso, la identidad del nodo de Tailscale persistió.
Tailscale necesita conservar el estado persistente de la máquina
Tailscale almacena la identidad del nodo, las claves y el estado de conexión en su directorio de estado. En Docker, la ruta suele configurarse con:
TS_STATE_DIR=/var/lib/tailscaleSi ese directorio existe únicamente dentro del sistema de archivos desechable del contenedor, recrearlo genera una identidad de Tailscale nueva.
La fuente ya montaba el directorio de estado
El archivo Compose original incluía:
/DATA/AppData/tailscale:/var/lib/tailscalejunto con TS_STATE_DIR=/var/lib/tailscale, la red del host, NET_ADMIN, NET_RAW, así como acceso a /dev/net/tun. En teoría, eso debería conservar el estado.
Una clave de autenticación sirve para el registro inicial, no necesariamente para cada reinicio
El archivo Compose también proporcionaba TS_AUTHKEY en cada inicio del contenedor. Un usuario de la comunidad explicó que la reautenticación puede crear una máquina nueva cuando el estado del nodo existente no se reutiliza como se espera.
El usuario que respondió sugirió usar una clave de autenticación reutilizable y no efímera durante el primer inicio, esperar a que el nodo apareciera en la consola de administración y, después, eliminar la línea de la clave de autenticación y volver a implementar, para que el estado guardado de la máquina pasara a ser la fuente de identidad.
El autor original confirmó que eliminar la clave de autenticación solucionó su caso
La respuesta final de la fuente indica que las demás piezas de persistencia ya estaban configuradas y que solo había que eliminar la variable de entorno de la clave de autenticación. Después, el nombre de la máquina se conservó tras los reinicios.
Esa confirmación es más sólida que una suposición genérica sobre los permisos. Para esta instalación en particular, la reautenticación era el desencadenante práctico.
La versión actual de Tailscale proporciona TS_AUTH_ONCE
Las implementaciones modernas de Tailscale en Docker pueden usar TS_AUTH_ONCE=true. Cuando ya existe un estado persistente, esto indica al contenedor que no debe forzar otro inicio de sesión cada vez que se inicia.
Revisa los parámetros actuales de estado y autenticación de Tailscale para Docker antes de reutilizar sin cambios un archivo Compose de 2025.
Usa una carpeta de host dedicada para el estado
Una carpeta de host dedicada, como una carpeta AppData/estado de Tailscale, facilita la verificación de que las claves de la máquina sobreviven a una nueva implementación. El usuario que respondió originalmente también recomendó asegurarse de que la carpeta tenga permisos de escritura para el proceso que almacena el estado de Tailscale.
Los permisos importan porque un volumen puede montarse correctamente mientras el proceso aún no puede actualizar sus archivos. En esa situación, Tailscale puede comportarse como si la máquina no tuviera un estado reutilizable.
Evita las claves de autenticación efímeras para un servidor permanente
Tailscale admite nodos efímeros que son intencionadamente temporales. Esto resulta útil para trabajos de CI de corta duración o contenedores desechables, pero es lo contrario de lo que necesita un servidor ZimaOS permanente.
Al crear una credencial, verifica que coincida con el ciclo de vida previsto. Un servidor doméstico persistente normalmente debe conservar la misma identidad hasta que la revoques o reemplaces deliberadamente.
TS_HOSTNAME no define la identidad de la máquina
El contenedor de origen usaba TS_HOSTNAME=zimaos. Esa configuración controla el nombre descriptivo que se muestra en la tailnet, pero conservar la misma cadena de nombre de host no conserva la identidad criptográfica de la máquina. Dos máquinas autenticadas recientemente pueden intentar usar nombres similares y seguir siendo nodos independientes.
Prueba tanto el reinicio como la nueva implementación de la aplicación
El problema original ocurrió después de reinicios completos del sistema operativo y de ediciones de la aplicación de ZimaOS. Por lo tanto, una solución correcta debe superar ambos:
- reiniciar el contenedor de Tailscale;
- editar y volver a implementar la aplicación sin cambiar el volumen de estado;
- reiniciar ZimaOS;
- verifica que la misma máquina siga conectada en la consola de administración de Tailscale.
Si aparece un duplicado después de solo uno de esos eventos, compara qué ocurre con el directorio de estado durante esa operación específica del ciclo de vida.
Preguntas frecuentes sobre la persistencia de Tailscale
¿Por qué se creó una máquina nueva de Tailscale después de cada reinicio?
En el caso de origen, el volumen de estado ya existía y el uso repetido de la clave de autenticación era el problema práctico restante.
¿Qué ruta debe persistir?
La ruta configurada por TS_STATE_DIR, normalmente /var/lib/tailscale dentro del contenedor.
¿Debe TS_AUTHKEY permanecer para siempre en el entorno?
No necesariamente. El usuario de origen solucionó los nodos duplicados eliminándolo después del registro, y las versiones actuales de Tailscale también proporcionan TS_AUTH_ONCE.
¿TS_HOSTNAME conserva la identidad del nodo?
No. El estado de la máquina almacenado de Tailscale es lo que conserva la identidad.
