Se vuoi che alcune applicazioni ZimaOS selezionate inviino il proprio traffico tramite una VPN commerciale, la discussione della community indica Gluetun, invece di considerare la voce WireGuard dell’App Store come una semplice interfaccia per caricare la configurazione del client. L’autore originale aveva inizialmente chiesto come eseguire WireGuard come client, poi ha trovato Gluetun in ZimaOS e ha documentato l’approccio basato sulla rete Docker.
Il concetto chiave è che l’app di destinazione condivide lo spazio dei nomi di rete di Gluetun. Gluetun gestisce il tunnel VPN, il firewall e le porte pubblicate; qBittorrent o un’altra applicazione utilizza quindi quello stack di rete invece della propria normale interfaccia bridge.
WireGuard e Tailscale nell’App Store di ZimaOS non equivalgono a un client VPN di un provider
Zima-Giorgio ha risposto che WireGuard e Tailscale erano disponibili nell’App Store. L’autore ha poi chiarito il punto mancante: voleva un flusso di lavoro da client in cui fosse possibile importare la configurazione di un provider e usarla per instradare il traffico delle applicazioni.
La distinzione è importante. Tailscale e un endpoint WireGuard autogestito sono utili per la rete di accesso remoto privato, mentre Gluetun è progettato specificamente per collegare i carichi di lavoro Docker ai provider VPN commerciali supportati tramite OpenVPN o WireGuard.
La scoperta di Gluetun nella discussione originale
L’autore ha poi scritto che ZimaOS includeva Gluetun, anche se cercando il termine generico “VPN” nell’App Store non risultava evidente.
Il consiglio originale era cambiare la rete dell’applicazione instradata dalla modalità bridge normale allo spazio dei nomi di rete di Gluetun e rimuovere le porte pubblicate dall’applicazione, perché dovrebbe essere Gluetun a pubblicarle.
network_mode: container:gluetunQuesta sintassi è valida quando un container esterno si collega, tramite il nome, a un container Gluetun già in esecuzione.
service:gluetun vs container:gluetun
La documentazione attuale di Gluetun distingue due casi comuni con Compose:
# Stesso progetto Compose
network_mode: "service:gluetun"e:
# Progetto Compose separato / container esterno
network_mode: "container:gluetun"Entrambe le forme sono apparse concettualmente nella discussione della community. Quella corretta dipende dal fatto che Gluetun e l’applicazione instradata si trovino o meno nello stesso stack Compose.
Guida attuale al networking dei container Gluetun
Perché qBittorrent può ancora esporre l’IP dell’ISP
Un utente successivo ha riferito che Gluetun stesso mostrava un IP NordVPN nei log, ma qBittorrent sembrava continuare a utilizzare l'indirizzo dell'ISP durante il test. Questo sintomo significa che “Gluetun è connesso” e “qBittorrent sta effettivamente condividendo lo stack di rete di Gluetun” devono essere verificati separatamente.
Controlla la definizione del container qBittorrent e conferma che la sua modalità di rete sia effettivamente collegata a Gluetun. Un'interfaccia bridge normale accanto a Gluetun può lasciare qBittorrent instradato tramite la normale route dell'host.
Sposta le porte di qBittorrent nel container Gluetun
La documentazione attuale di Gluetun indica che, quando un altro container condivide il suo stack di rete, le porte dell'applicazione di destinazione devono essere pubblicate su Gluetun.
Ad esempio, se qBittorrent ascolta internamente sulla 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"Non pubblicare la stessa porta di qBittorrent su entrambi i container. Ciò causa i conflitti di porta descritti nella discussione di origine.
Guida al port mapping di Gluetun
Il video citato nella discussione della community
Un partecipante successivo ha dichiarato di aver seguito il video di DB Tech su CasaOS mentre cercava di instradare qBittorrent tramite Gluetun. Poiché il video fa parte del percorso di risoluzione dei problemi della discussione di origine, viene conservato qui.
Il video è precedente alla discussione su ZimaOS e utilizza CasaOS, quindi guardalo per comprendere l'architettura Docker/Gluetun, invece di copiare alla lettera ogni passaggio dell'interfaccia.
Un utente successivo ha confermato che uno stack Compose personalizzato funzionava
Nel novembre 2025, un altro membro della community ha affermato che la soluzione affidabile consisteva nel distribuire qBittorrent e Gluetun insieme come app personalizzata/stack Compose e configurare lì il provider VPN. Ha riferito che accedendo a qBittorrent sulla porta host scelta veniva quindi mostrato traffico instradato tramite VPN.
La discussione di origine contiene il link a un Gist creato da un utente per questa configurazione. Considera i file Compose di terze parti come esempi: verifica le variabili d'ambiente, le versioni delle immagini, i segreti e le impostazioni di rete prima di distribuirli.
Gluetun offre un kill switch VPN
La documentazione attuale di Gluetun descrive il suo firewall come un kill switch: quando il percorso VPN non è disponibile, il firewall blocca il traffico che non dovrebbe uscire dall'interfaccia normale. Questo è uno dei motivi per cui condividere lo stack di rete di Gluetun è preferibile al semplice avvio di un container VPN accanto a qBittorrent.
Non disabilitare le regole firewall di Gluetun solo per rendere raggiungibile una porta. Correggi invece le route LAN/di uscita previste.
Consenti deliberatamente l'accesso alla LAN
Se l'app instradata deve raggiungere le subnet locali, Gluetun supporta FIREWALL_OUTBOUND_SUBNETS. Ad esempio:
FIREWALL_OUTBOUND_SUBNETS=192.168.1.0/24Usa la subnet LAN effettiva ed evita di sovrapporla all'intervallo del tunnel VPN.
L'inoltro delle porte del provider VPN è diverso dalla mappatura delle porte Docker
La documentazione di Gluetun distingue tra:
- Pubblicazione delle porte Docker: rendere la WebUI di qBittorrent raggiungibile sulla LAN.
- Inoltro delle porte del provider VPN: ottenere una porta in ingresso da un provider VPN che lo supporta.
Non abilitare VPN_PORT_FORWARDING solo per correggere l'accesso locale alla WebUI di qBittorrent. Risolvono problemi diversi.
Checklist di Gluetun per ZimaOS
- Configura Gluetun per il tuo provider VPN effettivo usando la documentazione aggiornata del provider.
- Verifica che i log di Gluetun mostrino l'IP di uscita VPN previsto.
- Inserisci l'app di destinazione nello spazio dei nomi di rete di Gluetun.
- Usa
service:gluetunper lo stesso stack Compose ocontainer:gluetunper un container esterno. - Rimuovi le porte pubblicate duplicate dall'applicazione instradata.
- Pubblica le porte WebUI/di ascolto necessarie su Gluetun.
- Riavvia lo stack.
- Verifica l'IP pubblico dell'applicazione di destinazione separatamente dal log di Gluetun.
- Tieni le credenziali VPN e le chiavi private WireGuard fuori dai file Compose pubblici.
Domande frequenti sul client VPN di ZimaOS
ZimaOS può instradare solo qBittorrent tramite una VPN?
Sì. La discussione della community usava specificamente Gluetun per condividere lo stack di rete VPN con applicazioni Docker selezionate, invece di instradare tramite tunnel ogni servizio ZimaOS.
Perché Gluetun mostrava l'IP della VPN mentre qBittorrent mostrava ancora l'IP dell'ISP?
Perché il container VPN può essere integro mentre qBittorrent è ancora connesso alla sua rete normale. Verifica l'effettiva modalità di rete di qBittorrent.
Perché la modifica delle porte interrompe la WebUI di qBittorrent?
Quando qBittorrent condivide lo spazio dei nomi di rete di Gluetun, pubblica la porta della WebUI su Gluetun invece di pubblicare la stessa porta su qBittorrent.
Devo usare service:gluetun o container:gluetun?
Usa service:gluetun quando entrambi i servizi si trovano nello stesso progetto Compose. Usa container:gluetun quando un container esterno si unisce a un container Gluetun denominato.
