Se quiser que aplicações selecionadas do ZimaOS enviem o respetivo tráfego através de uma VPN comercial, o tópico da comunidade aponta para o Gluetun, em vez de tratar a entrada do WireGuard na App Store como uma simples interface para carregar a configuração do cliente. O autor original perguntou inicialmente como executar o WireGuard como cliente, mas encontrou depois o Gluetun no ZimaOS e documentou a abordagem baseada na rede Docker.
O princípio fundamental é que a aplicação-alvo partilha o namespace de rede do Gluetun. O Gluetun gere o túnel VPN, a firewall e as portas publicadas; o qBittorrent ou outra aplicação utiliza depois essa stack de rede, em vez da sua interface bridge normal.
O WireGuard e o Tailscale na App Store do ZimaOS não são o mesmo que um cliente de VPN de um fornecedor
Zima-Giorgio respondeu que o WireGuard e o Tailscale estavam disponíveis na App Store. O autor esclareceu então o que faltava: pretendia um fluxo de trabalho de cliente em que fosse possível importar uma configuração de fornecedor e utilizá-la para encaminhar o tráfego das aplicações.
Essa distinção é importante. O Tailscale e um endpoint WireGuard autoalojado são úteis para redes privadas de acesso remoto, enquanto o Gluetun foi concebido especificamente para ligar cargas de trabalho Docker através de fornecedores de VPN comerciais compatíveis, utilizando OpenVPN ou WireGuard.
A descoberta do Gluetun no tópico original
Mais tarde, o autor escreveu que o ZimaOS incluía o Gluetun, embora procurá-lo na App Store pelo termo genérico “VPN” não o tornasse evidente.
O conselho original era alterar a rede da aplicação encaminhada, passando do modo bridge normal para o namespace de rede do Gluetun, e remover as portas publicadas pela própria aplicação, uma vez que deve ser o Gluetun a publicá-las.
network_mode: container:gluetunEssa sintaxe é válida quando um contentor externo se junta, pelo nome, a um contentor Gluetun já em execução.
service:gluetun vs container:gluetun
A documentação atual do Gluetun distingue dois casos comuns do Compose:
# Mesmo projeto Compose
network_mode: "service:gluetun"e:
# Projeto Compose separado / contentor externo
network_mode: "container:gluetun"Ambas as formas surgiram conceptualmente na discussão da comunidade. A correta depende de o Gluetun e a aplicação encaminhada estarem na mesma stack do Compose.
Guia atual de configuração da rede do contentor Gluetun
Porque é que o qBittorrent pode continuar a revelar o IP do ISP
Um utilizador posterior relatou que o próprio Gluetun apresentava um IP da NordVPN nos registos, mas o qBittorrent continuava a parecer utilizar o endereço do ISP quando testado. Esse sintoma significa que “o Gluetun está ligado” e que “o qBittorrent está realmente a partilhar a pilha de rede do Gluetun” têm de ser testados separadamente.
Verifique a definição do contentor qBittorrent e confirme que o seu modo de rede está realmente ligado ao Gluetun. Uma interface bridge normal juntamente com o Gluetun pode fazer com que o qBittorrent utilize a rota normal do anfitrião.
Mova as portas do qBittorrent para o contentor Gluetun
A documentação atual do Gluetun indica que, quando outro contentor partilha a sua pilha de rede, as portas da aplicação-alvo devem ser publicadas no Gluetun.
Por exemplo, se o qBittorrent escutar internamente na porta 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"Não publique a mesma porta do qBittorrent em ambos os contentores. Isso cria os conflitos de portas descritos no tópico de origem.
Guia de mapeamento de portas do Gluetun
O vídeo referido no tópico da comunidade
Um participante posterior afirmou explicitamente que seguiu o vídeo do DB Tech sobre o CasaOS enquanto tentava encaminhar o qBittorrent através do Gluetun. Como esse vídeo faz parte do percurso de resolução de problemas do tópico de origem, é preservado aqui.
O vídeo é anterior ao tópico do ZimaOS e utiliza o CasaOS, por isso deve ser usado para compreender a arquitetura Docker/Gluetun, em vez de copiar literalmente todos os passos da interface.
Um utilizador posterior confirmou que uma pilha Compose personalizada funcionava
Em novembro de 2025, outro membro da comunidade afirmou que a solução fiável era implementar o qBittorrent e o Gluetun juntos como uma aplicação personalizada/pilha Compose e configurar aí o fornecedor de VPN. Relatou que, ao aceder ao qBittorrent através da porta escolhida no anfitrião, o tráfego passou a ser encaminhado pela VPN.
O tópico de origem inclui uma ligação para um Gist criado por um utilizador para essa configuração. Trate os ficheiros Compose de terceiros como exemplos: reveja as variáveis de ambiente, as versões das imagens, os segredos e as definições de rede antes de os implementar.
O Gluetun fornece um interruptor de segurança da VPN
A documentação atual do Gluetun descreve a sua firewall como um interruptor de segurança: quando o caminho da VPN está indisponível, a firewall bloqueia o tráfego que não deveria sair pela interface normal. Esta é uma das razões pelas quais partilhar a pilha de rede do Gluetun é preferível a simplesmente iniciar um contentor VPN ao lado do qBittorrent.
Não desative as regras de firewall do Gluetun apenas para tornar uma porta acessível. Corrija antes as rotas LAN/de saída pretendidas.
Permitir deliberadamente o acesso à LAN
Se a aplicação encaminhada precisar de aceder a sub-redes locais, o Gluetun suporta FIREWALL_OUTBOUND_SUBNETSPor exemplo:
FIREWALL_OUTBOUND_SUBNETS=192.168.1.0/24Utilize a sua sub-rede LAN real e evite sobrepô-la ao intervalo do túnel VPN.
O encaminhamento de portas do fornecedor VPN é diferente do mapeamento de portas do Docker
A documentação do Gluetun distingue:
- Publicação de portas do Docker: disponibilização da WebUI do qBittorrent na sua LAN.
- Encaminhamento de portas do fornecedor VPN: obtenção de uma porta de entrada junto de um fornecedor VPN que o suporte.
Não ative VPN_PORT_FORWARDING apenas para corrigir o acesso local à WebUI do qBittorrent. Resolvem problemas diferentes.
Lista de verificação do Gluetun no ZimaOS
- Configure o Gluetun para o seu fornecedor de VPN efetivo, utilizando a documentação atual do fornecedor.
- Confirme que os registos do Gluetun mostram o IP de saída VPN esperado.
- Coloque a aplicação de destino no espaço de nomes de rede do Gluetun.
- Utilize
serviço:gluetunpara a mesma stack Compose oucontentor:gluetunpara um contentor externo. - Remova as portas publicadas duplicadas da aplicação encaminhada.
- Publique as portas necessárias da WebUI/escuta no Gluetun.
- Reinicie a stack.
- Teste o IP público da aplicação de destino de forma independente do próprio registo do Gluetun.
- Mantenha as credenciais da VPN e as chaves privadas WireGuard fora dos ficheiros Compose públicos.
Perguntas frequentes sobre o cliente VPN do ZimaOS
O ZimaOS consegue encaminhar apenas o qBittorrent através de uma VPN?
Sim. O tópico da comunidade utilizou especificamente o Gluetun para partilhar a pilha de rede VPN com aplicações Docker selecionadas, em vez de criar um túnel para todos os serviços ZimaOS.
Porque é que o Gluetun mostrou o IP da VPN enquanto o qBittorrent continuou a mostrar o IP do ISP?
Porque o contentor VPN pode estar saudável enquanto o qBittorrent continua ligado à sua rede normal. Verifique o modo de rede efetivo do qBittorrent.
Porque é que alterar as portas faz com que a WebUI do qBittorrent deixe de funcionar?
Quando o qBittorrent partilha o espaço de nomes de rede do Gluetun, publique a porta da WebUI no Gluetun em vez de publicar a mesma porta no qBittorrent.
Devo utilizar serviço:gluetun ou contentor:gluetun?
Utilize serviço:gluetun quando ambos os serviços estão no mesmo projeto Compose. Utilize contentor:gluetun quando um contentor externo se junta a um contentor Gluetun com nome.
