Als je geselecteerde ZimaOS-applicaties hun verkeer via een commerciële VPN wilt laten lopen, verwijst de communitythread naar Gluetun in plaats van de WireGuard-vermelding in de App Store te beschouwen als een eenvoudige interface om je clientconfiguratie te uploaden. De oorspronkelijke auteur vroeg aanvankelijk hoe WireGuard als client kon worden uitgevoerd, vond vervolgens Gluetun in ZimaOS en documenteerde de Docker-netwerkbenadering.
Het belangrijkste ontwerp is dat de doelapplicatie de netwerknaamruimte van Gluetun deelt. Gluetun beheert de VPN-tunnel, firewall en gepubliceerde poorten; qBittorrent of een andere applicatie gebruikt vervolgens die netwerkstack in plaats van de eigen normale bridge-interface.
WireGuard en Tailscale in de ZimaOS App Store zijn niet hetzelfde als een VPN-providerclient
Zima-Giorgio antwoordde dat WireGuard en Tailscale beschikbaar waren in de App Store. De auteur verduidelijkte vervolgens wat er ontbrak: ze wilden een client-workflow waarin een providerconfiguratie kon worden geïmporteerd en gebruikt om applicatieverkeer te routeren.
Dat onderscheid is belangrijk. Tailscale en een zelfgehost WireGuard-eindpunt zijn nuttig voor privénetwerken voor externe toegang, terwijl Gluetun specifiek is ontworpen om Docker-workloads via ondersteunde commerciële VPN-providers te verbinden met OpenVPN of WireGuard.
De ontdekking van Gluetun in de brondiscussie
De auteur schreef later dat ZimaOS Gluetun bevatte, hoewel dat niet duidelijk werd door in de App Store te zoeken op de algemene term “VPN”.
Het advies in de bron was om de netwerkconfiguratie van de applicatie die via de tunnel werkt te wijzigen van de normale bridgemodus naar de netwerknaamruimte van Gluetun en de gepubliceerde poorten van de applicatie zelf te verwijderen, omdat Gluetun deze in plaats daarvan moet publiceren.
network_mode: container:gluetunDeze syntaxis is geldig wanneer een externe container zich op basis van de naam bij een al draaiende Gluetun-container voegt.
service:gluetun versus container:gluetun
De huidige Gluetun-documentatie maakt onderscheid tussen twee veelvoorkomende Compose-situaties:
# Hetzelfde Compose-project
network_mode: "service:gluetun"en:
# Afzonderlijk Compose-project / externe container
network_mode: "container:gluetun"Beide vormen kwamen conceptueel voor in de communitydiscussie. De juiste vorm hangt ervan af of Gluetun en de applicatie die via de routering wordt geleid zich in dezelfde Compose-stack bevinden.
De huidige handleiding voor Gluetun-containernetwerken
Waarom qBittorrent nog steeds het IP-adres van de internetprovider kan lekken
Een latere gebruiker meldde dat Gluetun zelf in de logs een NordVPN-IP liet zien, maar dat qBittorrent bij een test nog steeds het ISP-adres leek te gebruiken. Dat symptoom betekent dat “Gluetun is verbonden” en “qBittorrent daadwerkelijk de netwerkstack van Gluetun deelt” afzonderlijk moeten worden getest.
Controleer de definitie van de qBittorrent-container en bevestig dat de netwerkmodus daadwerkelijk aan Gluetun is gekoppeld. Een normale bridge-interface naast Gluetun kan ertoe leiden dat qBittorrent de gewone hostroute gebruikt.
Verplaats de qBittorrent-poorten naar de Gluetun-container
In de huidige documentatie van Gluetun staat dat, wanneer een andere container zijn netwerkstack deelt, de poorten van de doelapplicatie op Gluetun moeten worden gepubliceerd.
Als qBittorrent bijvoorbeeld intern op poort 8080 luistert:
services:
gluetun:
image: qmcgaw/gluetun
cap_add:
- NET_ADMIN
devices:
- /dev/net/tun:/dev/net/tun
ports:
- "8080:8080"
qbittorrent:
image: jouw-qbittorrent-image
network_mode: "service:gluetun"Publiceer dezelfde qBittorrent-poort niet op beide containers. Dat veroorzaakt de poortconflicten die in de brondiscussie worden beschreven.
Handleiding voor poortkoppeling in Gluetun
De video waarnaar in de communitythread wordt verwezen
Een latere deelnemer zei expliciet dat die de CasaOS-video van DB Tech had gevolgd bij het proberen om qBittorrent via Gluetun te routeren. Omdat die video deel uitmaakt van het probleemoplossingstraject in de brondiscussie, is deze hier behouden.
De video is ouder dan de ZimaOS-thread en gebruikt CasaOS. Gebruik de video daarom om de Docker/Gluetun-architectuur te begrijpen, in plaats van elke stap in de interface letterlijk te kopiëren.
Een latere gebruiker bevestigde dat een aangepaste Compose-stack werkte
In november 2025 zei een ander communitylid dat de betrouwbare oplossing was om qBittorrent en Gluetun samen te implementeren als een aangepaste app/Compose-stack en daar de VPN-provider te configureren. Volgens hen liet toegang tot qBittorrent via de gekozen hostpoort vervolgens verkeer via de VPN zien.
De brontekst verwijst naar een door een gebruiker gemaakte Gist voor die configuratie. Beschouw Compose-bestanden van derden als voorbeelden: controleer omgevingsvariabelen, imageversies, geheimen en netwerkinstellingen voordat je ze implementeert.
Gluetun biedt een VPN-kill switch
In de huidige Gluetun-documentatie wordt de firewall beschreven als een kill switch: wanneer het VPN-pad niet beschikbaar is, blokkeert de firewall verkeer dat niet via de normale interface mag vertrekken. Dit is een van de redenen waarom het delen van Gluetuns netwerkstack de voorkeur heeft boven simpelweg een VPN-container naast qBittorrent starten.
Schakel de firewallregels van Gluetun niet uit alleen om een poort bereikbaar te maken. Corrigeer in plaats daarvan de bedoelde LAN-/uitgaande routes.
Sta LAN-toegang bewust toe
Als de gerouteerde applicatie toegang nodig heeft tot lokale subnetten, ondersteunt Gluetun FIREWALL_OUTBOUND_SUBNETSBijvoorbeeld:
FIREWALL_OUTBOUND_SUBNETS=192.168.1.0/24Gebruik je daadwerkelijke LAN-subnet en voorkom overlap met het bereik van de VPN-tunnel.
Port forwarding door de VPN-provider verschilt van Docker-poortkoppeling
De documentatie van Gluetun maakt onderscheid tussen:
- Docker-poortpublicatie: de qBittorrent WebUI bereikbaar maken op je LAN.
- Port forwarding door de VPN-provider: een inkomende poort verkrijgen bij een VPN-provider die dit ondersteunt.
Niet inschakelen VPN_PORT_FORWARDING alleen om lokale toegang tot de qBittorrent WebUI te herstellen. Ze lossen verschillende problemen op.
ZimaOS Gluetun-checklist
- Configureer Gluetun voor je daadwerkelijke VPN-provider aan de hand van de actuele documentatie van de provider.
- Controleer of de Gluetun-logboeken het verwachte VPN-uitgaande IP-adres tonen.
- Plaats de doelapplicatie in de netwerknaamruimte van Gluetun.
- Gebruik
service:gluetunvoor dezelfde Compose-stack ofcontainer:gluetunvoor een externe container. - Verwijder dubbel gepubliceerde poorten uit de gerouteerde applicatie.
- Publiceer de vereiste WebUI-/luisterpoorten op Gluetun.
- Start de stack opnieuw.
- Test het openbare IP-adres van de doelapplicatie onafhankelijk van het eigen logboek van Gluetun.
- Houd VPN-inloggegevens en privésleutels van WireGuard buiten openbare Compose-bestanden.
Veelgestelde vragen over de ZimaOS VPN-client
Kan ZimaOS alleen qBittorrent via een VPN routeren?
Ja. In de communitydiscussie werd Gluetun specifiek gebruikt om de VPN-netwerkstack ervan te delen met geselecteerde Docker-applicaties, in plaats van alle ZimaOS-services door een tunnel te leiden.
Waarom toonde Gluetun het VPN-IP terwijl qBittorrent nog steeds het IP-adres van de internetprovider toonde?
Omdat de VPN-container gezond kan zijn terwijl qBittorrent nog steeds met zijn normale netwerk is verbonden. Controleer de daadwerkelijke netwerkmodus van qBittorrent.
Waarom breekt het wijzigen van poorten de qBittorrent WebUI?
Wanneer qBittorrent de netwerknaamruimte van Gluetun deelt, publiceer je de WebUI-poort op Gluetun in plaats van dezelfde poort op qBittorrent te publiceren.
Moet ik service:gluetun of container:gluetun gebruiken?
Gebruik service:gluetun wanneer beide services zich in hetzelfde Compose-project bevinden. Gebruik container:gluetun wanneer een externe container deelneemt aan een benoemde Gluetun-container.
