Un contenedor VPN puede conectarse a una red remota mientras el host ZimaOS permanece completamente ajeno a esa ruta. Ese era el problema descrito en este hilo de septiembre de 2025. El contenedor de Tailscale del usuario se unió correctamente a la red tailnet, pero el propio ZimaOS —y, por tanto, la aplicación Archivos y el flujo de trabajo para montar recursos SMB en el host— no podía acceder al servidor CasaOS remoto a través del espacio de nombres de red del contenedor.
El usuario resolvió el problema práctico de las copias de seguridad cambiando la arquitectura, en lugar de intentar convertir el contenedor de Tailscale en una VPN del host. Unió el servidor CasaOS remoto a la red ZeroTier asociada con ZimaOS e informó de que el acceso SMB funcionaba correctamente.
La topología original tenía dos servidores remotos
La configuración original era la siguiente:
- un ZimaBlade con ZimaOS como máquina de origen;
- un servidor remoto con CasaOS como destino de la copia de seguridad SMB;
- Tailscale conectando ambos sitios.
Cuando ambas máquinas utilizaban CasaOS, el usuario había instalado Tailscale directamente en los hosts y montaba normalmente el recurso compartido SMB remoto.
El contenedor de Tailscale se unió a la red tailnet, pero ZimaOS no
En ZimaOS, el usuario ejecutaba Tailscale en Docker. Esto proporcionaba conectividad al propio contenedor de Tailscale, pero no añadía automáticamente las rutas ni las direcciones de Tailscale al espacio de nombres de red del host ZimaOS.
Por tanto, la aplicación Archivos no podía explorar directamente un servidor SMB que solo era accesible desde dentro del contenedor de Tailscale.
Esto es un límite del espacio de nombres de red, no un problema de contraseña SMB
Normalmente, un contenedor Docker tiene sus propias interfaces, rutas y contexto de cortafuegos. Aunque el contenedor pueda hacer ping a una dirección remota de la red tailnet, las aplicaciones del host no heredan esas rutas a menos que la VPN se haya integrado deliberadamente con la red del host, el enrutamiento o una arquitectura basada en proxy.
Cambiar las credenciales SMB no resolvería la ausencia de esa ruta.
El usuario cambió el servidor CasaOS remoto a ZeroTier
Después de investigar más, el autor original instaló ZeroTier en el servidor CasaOS remoto y lo unió a la red virtual utilizada por ZimaOS. Después indicó que el servidor remoto podía acceder al recurso compartido SMB y que la solución funcionaba correctamente.
El comando exacto del instalador que aparecía en el foro era una recomendación aportada por la comunidad. La arquitectura reutilizable es más importante que copiar ese script de instalación de una sola línea.
El acceso remoto actual de ZimaOS se basa en una red virtual basada en ZeroTier
La documentación actual de IceWhale describe el ID de red de acceso remoto de ZimaOS como una identidad de red ZeroTier. ZimaClient utiliza esta red virtual para ofrecer conectividad remota cifrada.
Esto hace que la solución del usuario parezca menos un recurso improvisado de lo que podría parecer: en lugar de intentar exportar al host una ruta de Tailscale dentro de Docker, el NAS remoto se une a la red virtual que ZimaOS ya utiliza a nivel del host.
IceWhale documenta ahora el mismo patrón con otras plataformas NAS
La documentación actual de ZimaOS para la sincronización con QNAP indica a los usuarios que obtengan el ID de red de ZimaOS, instalen ZeroTier en el lado de QNAP y se unan a ese ID antes de crear una tarea de sincronización entre redes.
Utiliza el patrón actual de red ZeroTier entre NAS como referencia arquitectónica compatible.
Una opción de Tailscale a nivel del host es una solución diferente
Proyectos comunitarios posteriores han empaquetado Tailscale como un systemd-sysext nativo para ZimaOS, específicamente para proporcionar al host una interfaz TUN real y permitir el enrutamiento a nivel del host. Esto puede resolver la limitación original del espacio de nombres, pero se trata de software comunitario, no de una función de Tailscale de ZimaOS proporcionada oficialmente.
Si el objetivo es únicamente realizar copias de seguridad SMB remotas, unir el servidor remoto a la red virtual existente de ZimaOS puede ser más sencillo que instalar una nueva extensión VPN a nivel del host.
La accesibilidad a nivel del host debe existir antes de que Archivos pueda montar SMB
Independientemente de la red superpuesta que elijas, el host ZimaOS debe poder enrutar hacia la dirección del servidor SMB remoto. Solo entonces el nombre del recurso compartido SMB, el nombre de usuario, la contraseña y los permisos pasan a ser la siguiente capa de diagnóstico.
Trata el destino SMB remoto como parte del límite de seguridad de la copia de seguridad
Un recurso compartido de copia de seguridad accesible a través de una red superpuesta debe seguir requiriendo autenticación y exponer únicamente las carpetas que necesita el flujo de trabajo de copia de seguridad. Evita hacer que todo el servidor remoto sea escribible simplemente porque el tráfico está cifrado.
Preguntas frecuentes sobre SMB remoto a través de redes superpuestas
¿Por qué el contenedor de Tailscale podía acceder al servidor remoto, pero Archivos de ZimaOS no?
El contenedor tenía su propio espacio de nombres de red y sus propias rutas; el host ZimaOS no las heredaba automáticamente.
¿Qué utilizó el autor original en su lugar?
Unió el servidor CasaOS remoto a la red ZeroTier utilizada por ZimaOS e indicó que funcionaba correctamente.
¿ZimaOS utiliza actualmente ZeroTier para las redes remotas?
La documentación actual de IceWhale describe el ID de red de acceso remoto y los flujos de trabajo entre NAS mediante redes virtuales basadas en ZeroTier.
