Si quieres que determinadas aplicaciones de ZimaOS envíen su tráfico a través de una VPN comercial, el hilo de la comunidad recomienda Gluetun en lugar de tratar la entrada de WireGuard de la App Store como una simple interfaz para cargar la configuración del cliente. El autor original preguntó inicialmente cómo ejecutar WireGuard como cliente; después encontró Gluetun en ZimaOS y documentó el enfoque de red de Docker.
El diseño clave consiste en que la aplicación objetivo comparta el espacio de nombres de red de Gluetun. Gluetun gestiona el túnel VPN, el cortafuegos y los puertos publicados; qBittorrent u otra aplicación utiliza entonces esa pila de red en lugar de su propia interfaz bridge normal.
WireGuard y Tailscale en la App Store de ZimaOS no son lo mismo que un cliente de proveedor de VPN
Zima-Giorgio respondió que WireGuard y Tailscale estaban disponibles en la App Store. Entonces, el autor aclaró lo que faltaba: quería un flujo de trabajo de cliente en el que se pudiera importar una configuración del proveedor y utilizarla para enrutar el tráfico de la aplicación.
Esa distinción es importante. Tailscale y un punto de conexión de WireGuard autohospedado son útiles para redes de acceso remoto privado, mientras que Gluetun está diseñado específicamente para conectar cargas de trabajo de Docker mediante proveedores comerciales de VPN compatibles con OpenVPN o WireGuard.
El descubrimiento de Gluetun en el hilo original
Más tarde, el autor escribió que ZimaOS incluía Gluetun, aunque buscar el término genérico «VPN» en la App Store no lo hacía evidente.
La recomendación original era cambiar la red de la aplicación tunelizada del modo bridge normal al espacio de nombres de red de Gluetun y eliminar los puertos publicados propios de la aplicación, ya que Gluetun debe publicarlos en su lugar.
network_mode: container:gluetunEsa sintaxis es válida cuando un contenedor externo se conecta a un contenedor de Gluetun que ya está en ejecución mediante su nombre.
service:gluetun frente a container:gluetun
La documentación actual de Gluetun distingue dos casos comunes de Compose:
# Mismo proyecto de Compose
network_mode: "service:gluetun"y:
# Proyecto de Compose independiente / contenedor externo
network_mode: "container:gluetun"Ambas formas aparecieron conceptualmente en el debate de la comunidad. La correcta depende de si Gluetun y la aplicación enrutada están en la misma pila de Compose.
Guía actual de redes de contenedores de Gluetun
Por qué qBittorrent aún puede filtrar la IP del ISP
Más adelante, un usuario informó que Gluetun mostraba una IP de NordVPN en sus registros, pero que qBittorrent seguía pareciendo utilizar la dirección del ISP al realizar la prueba. Ese síntoma significa que «Gluetun está conectado» y que «qBittorrent realmente comparte la pila de red de Gluetun» deben comprobarse por separado.
Revisa la definición del contenedor de qBittorrent y confirma que su modo de red esté realmente conectado a Gluetun. Una interfaz bridge normal junto a Gluetun puede hacer que qBittorrent utilice la ruta ordinaria del host.
Mueve los puertos de qBittorrent al contenedor de Gluetun
La documentación actual de Gluetun indica que, cuando otro contenedor comparte su pila de red, los puertos de la aplicación de destino deben publicarse en Gluetun.
Por ejemplo, si qBittorrent escucha internamente en el puerto 8080:
services:
gluetun:
image: qmcgaw/gluetun
cap_add:
- NET_ADMIN
devices:
- /dev/net/tun:/dev/net/tun
ports:
- "8080:8080"
qbittorrent:
image: your-qbittorrent-image
network_mode: "service:gluetun"No publiques el mismo puerto de qBittorrent en ambos contenedores. Eso provoca los conflictos de puertos descritos en el hilo original.
Guía de asignación de puertos de Gluetun
El video mencionado en el hilo de la comunidad
Un participante posterior dijo explícitamente que siguió el video de CasaOS de DB Tech mientras intentaba enrutar qBittorrent a través de Gluetun. Como ese video forma parte del proceso de resolución de problemas del hilo original, se conserva aquí.
El video es anterior al hilo de ZimaOS y utiliza CasaOS, así que úsalo para comprender la arquitectura de Docker/Gluetun en lugar de copiar literalmente cada paso de la interfaz.
Más adelante, otro usuario confirmó que una pila de Compose personalizada funcionaba
En noviembre de 2025, otro miembro de la comunidad dijo que la solución fiable era implementar qBittorrent y Gluetun juntos como una aplicación personalizada o una pila de Compose, y configurar allí el proveedor de VPN. Informó que, al acceder a qBittorrent mediante el puerto del host elegido, el tráfico aparecía enrutado a través de la VPN.
El hilo original enlaza a un Gist creado por un usuario para esa configuración. Trata los archivos Compose de terceros como ejemplos: revisa las variables de entorno, las versiones de las imágenes, los secretos y la configuración de red antes de implementarlos.
Gluetun proporciona un interruptor de emergencia para la VPN
La documentación actual de Gluetun describe su firewall como un interruptor de emergencia de la VPN: cuando la ruta de la VPN no está disponible, el firewall bloquea el tráfico que no debería salir por la interfaz normal. Esta es una de las razones por las que es preferible compartir la pila de red de Gluetun en lugar de simplemente iniciar un contenedor de VPN junto a qBittorrent.
No deshabilites las reglas del firewall de Gluetun solo para hacer que un puerto sea accesible. Corrige las rutas LAN/de salida previstas.
Permitir deliberadamente el acceso a la LAN
Si la aplicación enrutada necesita acceder a subredes locales, Gluetun admite FIREWALL_OUTBOUND_SUBNETS. Por ejemplo:
FIREWALL_OUTBOUND_SUBNETS=192.168.1.0/24Usa la subred real de tu LAN y evita que se solape con el rango del túnel VPN.
El reenvío de puertos del proveedor VPN es diferente de la asignación de puertos de Docker
La documentación de Gluetun distingue entre:
- Publicación de puertos de Docker: hacer que la WebUI de qBittorrent sea accesible en tu LAN.
- Reenvío de puertos del proveedor VPN: obtener un puerto entrante de un proveedor VPN que lo admita.
No habilites VPN_PORT_FORWARDING solo para solucionar el acceso local a la WebUI de qBittorrent. Resuelven problemas diferentes.
Lista de comprobación de Gluetun para ZimaOS
- Configura Gluetun para tu proveedor de VPN real usando la documentación actual del proveedor.
- Confirma que los registros de Gluetun muestren la IP de salida VPN esperada.
- Coloca la aplicación objetivo en el espacio de nombres de red de Gluetun.
- Usa
servicio:gluetunpara la misma pila de Compose ocontenedor:gluetunpara un contenedor externo. - Elimina los puertos publicados duplicados de la aplicación enrutada.
- Publica los puertos necesarios de la WebUI y de escucha en Gluetun.
- Reinicia la pila.
- Prueba de forma independiente la IP pública de la aplicación objetivo, sin depender del registro de Gluetun.
- Mantén las credenciales de la VPN y las claves privadas de WireGuard fuera de los archivos Compose públicos.
Preguntas frecuentes sobre el cliente VPN de ZimaOS
¿Puede ZimaOS enrutar solo qBittorrent a través de una VPN?
Sí. El hilo de la comunidad usaba Gluetun específicamente para compartir su pila de red VPN con aplicaciones Docker seleccionadas, en lugar de tunelizar todos los servicios de ZimaOS.
¿Por qué Gluetun mostraba la IP de la VPN mientras qBittorrent seguía mostrando la IP del ISP?
Porque el contenedor VPN puede estar funcionando correctamente mientras qBittorrent sigue conectado a su red normal. Verifica el modo de red real de qBittorrent.
¿Por qué cambiar los puertos interrumpe la WebUI de qBittorrent?
Cuando qBittorrent comparte el espacio de nombres de red de Gluetun, publica el puerto de la WebUI en Gluetun en lugar de publicar el mismo puerto en qBittorrent.
¿Debo usar servicio:gluetun o contenedor:gluetun?
Usa servicio:gluetun cuando ambos servicios están en el mismo proyecto de Compose. Usa contenedor:gluetun cuando un contenedor externo se conecta a un contenedor Gluetun con nombre.
