Le scénario est classique pour quiconque monte sa propre infrastructure domotique ou multimédia : vous venez de déployer un conteneur Docker associant le client qBittorrent à la passerelle VPN Gluetun sur votre NAS ou votre serveur maison. Les logs défilent sans la moindre erreur, la liaison chiffrée est confirmée et le téléchargement semble prêt à tourner.
Vous ouvrez votre navigateur habituel, tapez l’adresse de votre machine suivie du port conventionnel (http://192.168.1.50:8080), et… rien. Un écran blanc s’affiche, rapidement ponctué d'un frustrant « Ce site est inaccessible » ou d'une erreur de délai d'attente dépassé.
Le premier réflexe consiste souvent à maudire qBittorrent, à suspecter une corruption d'image Docker ou à penser que le service VPN sabote la communication locale. La réalité est bien plus concrète : tout fonctionne exactement comme prévu par la sécurité du système, mais vous avez commis l'une des deux erreurs d'aiguillage réseau les plus fréquentes de l'écosystème conteneurisé.
Résumé de l’article et contexte d’usage
Pourquoi la Web UI de qBittorrent devient-elle inaccessible quand le conteneur partage le réseau de Gluetun ?
Avec network_mode: service:gluetun, qBittorrent n’a plus sa propre pile réseau. Le port de la Web UI doit donc être publié sur Gluetun, puis le pare-feu de Gluetun doit autoriser le port entrant et le sous-réseau local. Si l’accès reste bloqué, il faut ensuite vérifier le reverse proxy, la protection anti-CSRF et le mot de passe temporaire de qBittorrent.
Ce qu’il faut retenir
- Pour qui : utilisateurs Docker, NAS et serveurs maison qui font passer qBittorrent par Gluetun tout en voulant garder la Web UI accessible depuis le LAN.
- Point clé : les directives de ports placées sur qBittorrent sont ignorées quand sa pile réseau est celle de Gluetun ; l’ouverture doit être déclarée sur la passerelle.
- Contexte OnlydogVPN : dans l’article, le produit est une alternative plus simple pour protéger un ordinateur personnel, pas un remplacement du montage Gluetun sur un serveur autonome.
- Limite importante : FIREWALL_OUTBOUND_SUBNETS doit correspondre au vrai sous-réseau local, et les protections applicatives de qBittorrent peuvent encore refuser un domaine ou une authentification incorrecte.
Source produit : site officiel OnlydogVPN.
L'erreur fondamentale : pourquoi déclarer les ports sur qBittorrent ne fonctionne jamais
Dans un fichier docker-compose.yml standard, exposer un service se résume à lui assigner une directive ports: - 8080:8080. Mais dès lors que vous associez qBittorrent à Gluetun via l'instruction network_mode: "service:gluetun", toutes les règles habituelles changent.
En utilisant ce mode, vous ordonnez à Docker de dépouiller le conteneur qBittorrent de sa propre pile réseau. Il n'a plus d'adresse IP virtuelle dédiée, plus d'interface réseau autonome, et il emprunte exclusivement l'espace réseau de Gluetun. Par conséquent, toute directive ports inscrite directement sous le service qBittorrent est purement et simplement ignorée par le moteur Docker.
Pour que votre navigateur domestique puisse atteindre l’interface web, la porte d'entrée doit obligatoirement être ouverte sur le conteneur qui détient le réseau. C'est donc sous la définition du service Gluetun lui-même que vous devez mapper le port de la Web UI, ainsi que vos éventuels ports d'écoute entrants. Si cette redirection n'est pas portée par la passerelle, vos paquets locaux frappent à une porte qui n'existe tout simplement pas.
Le verrou du pare-feu : apprivoiser le kill switch natif de Gluetun
Déplacer le port vers Gluetun résout la première moitié de l'équation, mais la page web reste bien souvent muette. Pourquoi ? Parce que le rôle fondamental d'un conteneur comme Gluetun est d'agir comme un coupe-circuit intraitable.
Par défaut, son pare-feu interne bloque agressivement l'intégralité du trafic qui n'emprunte pas le tunnel chiffré, y compris les flux provenant de votre propre sous-réseau local. Lorsque votre ordinateur portable tente d'interroger le serveur sur le port 8080, Gluetun considère ces paquets entrants comme suspects et les rejette immédiatement.
Pour déverrouiller l'accès sans créer de brèche vers l'extérieur, deux variables d'environnement doivent être ajoutées à la configuration de la passerelle :
FIREWALL_INPUT_PORTS=8080: cette instruction ordonne au pare-feu d'accepter explicitement les connexions locales entrantes dirigées vers la Web UI.FIREWALL_OUTBOUND_SUBNETS=192.168.1.0/24: cette variable (à adapter selon la plage IP exacte délivrée par votre box internet) autorise les conteneurs à répondre directement aux appareils situés sur votre réseau domestique sans chercher à faire transiter ces réponses par le tunnel externe.
En ajoutant ces deux lignes, vous rétablissez le dialogue direct entre votre navigateur et qBittorrent sans affaiblir le coupe-circuit : l'intégralité du trafic de téléchargement demeure hermétiquement confiné dans le tunnel VPN.
Le piège de la boucle locale : reverse proxy, DNS et authentification
Si l'écran de chargement persiste après ces ajustements, les derniers obstacles se situent généralement au niveau de la couche applicative :
- L'accès via un reverse proxy ou un domaine local : Si vous joignez votre interface via un nom de domaine local géré par Nginx, Traefik ou Caddy, qBittorrent bloque souvent la requête par sécurité avec un message d'erreur d'hôte non autorisé ou de protection anti-CSRF. Il est alors nécessaire de désactiver la protection contre les falsifications de requêtes intersites ou de renseigner explicitement votre domaine dans les réglages de l'application.
- Le mot de passe temporaire invisible : Les versions récentes de qBittorrent ne disposent plus du couple identifiant/mot de passe par défaut d'autrefois (
admin / adminadmin). Lors de l'initialisation, un mot de passe temporaire complexe est désormais généré aléatoirement et inscrit au sein même des logs de démarrage du conteneur. Un simple coup d'œil aux journaux d'exécution de Docker permet de récupérer ce sésame et d'éviter de confondre un rejet d'authentification avec un problème de routage.
L'arbitrage d'usage : quand monter un conteneur dédié, et quand choisir la simplicité ?
Arrivé à ce stade, une question pragmatique mérite d'être posée : ce niveau de complexité correspond-il réellement à votre besoin quotidien ?
L'assemblage Docker et conteneur VPN constitue une mécanique robuste pour une machine autonome : un NAS dédié, une station domestique sans écran ou un serveur d'automatisation tournant 24 heures sur 24. Dans ce cadre, la conteneurisation isole vos flux de fond sans interférer avec le reste du système.
En revanche, vouloir répliquer ce type d'infrastructure sur son poste de travail personnel (un MacBook, un PC portable Windows ou une station de travail Linux) pour simplement récupérer des fichiers de manière occasionnelle relève du calvaire inutile. Entre les conflits de pilotes virtuels, la surveillance des baux de sous-réseaux locaux et la maintenance de scripts de déploiement, vous passez plus de temps à administrer des tables réseau qu'à profiter de votre machine.
Pour sécuriser directement un ordinateur personnel, la démarche rationnelle consiste à privilégier une solution native, immédiate et pensée pour le confort d'utilisation. C’est précisément sur ce terrain que se distingue OnlydogVPN.
Plutôt que d'exiger l'écriture fastidieuse de fichiers YAML ou la manipulation manuelle de règles de pare-feu, cette application prend en charge la protection de bout en bout dès son installation. En s'appuyant sur une architecture moderne dérivée de HTTP/3 et un masquage de trafic natif, le service neutralise les bridages de bande passante fréquemment appliqués par les fournisseurs d'accès sur les transferts lourds.
La connexion fait preuve d'une tenue de route remarquable : lors d'un passage du Wi-Fi à l'Ethernet ou lors d'une micro-coupure réseau, sa capacité de reprise automatique encaisse les fluctuations sans interrompre brutalement vos flux ni faire fuiter vos données. Vous bénéficiez d'une étanchéité totale et de débits optimaux en un clic, tout en conservant un accès instantané et sans réglage à l'ensemble des imprimantes et périphériques de votre réseau local.
Un Docker Compose minimal et fonctionnel
Si votre objectif reste de finaliser votre serveur domestique autonome, voici la structure exacte et corrigée à adopter pour que votre pile fonctionne sans accroc :
services:
gluetun:
image: qmcgaw/gluetun
container_name: gluetun
cap_add:
- NET_ADMIN
environment:
- VPN_SERVICE_PROVIDER=votre_fournisseur
- VPN_TYPE=wireguard
# Vos identifiants VPN ici
- FIREWALL_INPUT_PORTS=8080
- FIREWALL_OUTBOUND_SUBNETS=192.168.1.0/24
ports:
- 8080:8080 # Accès à la Web UI
- 6881:6881 # Port torrent entrant (TCP)
- 6881:6881/udp
restart: unless-stopped
qbittorrent:
image: lscr.io/linuxserver/qbittorrent:latest
container_name: qbittorrent
network_mode: "service:gluetun"
environment:
- PUID=1000
- PGID=1000
- WEBUI_PORT=8080
volumes:
- ./config:/config
- ./downloads:/downloads
depends_on:
gluetun:
condition: service_healthy
restart: unless-stopped
La règle d'or est limpide : sur un serveur autonome, confiez la pile réseau au conteneur passerelle et autorisez explicitement vos sous-réseaux locaux. Pour votre machine personnelle de tous les jours, oubliez la gymnastique des conteneurs et laissez une application native moderne gérer la vitesse et la discrétion sans toucher à votre réseau domestique.
Questions fréquentes
Pourquoi le mapping 8080:8080 sous qBittorrent ne fonctionne-t-il pas avec network_mode: service:gluetun ?
Parce que qBittorrent ne possède plus d’interface réseau indépendante. Docker publie les ports depuis le conteneur qui détient réellement la pile réseau, ici Gluetun.
Quelles règles Gluetun sont nécessaires pour atteindre la Web UI depuis le réseau local ?
L’article indique d’autoriser le port de la Web UI avec FIREWALL_INPUT_PORTS et d’ajouter le sous-réseau local dans FIREWALL_OUTBOUND_SUBNETS, en adaptant la plage IP à son propre réseau.
Pourquoi un reverse proxy peut-il encore provoquer un refus après le réglage du pare-feu ?
qBittorrent peut rejeter un nom d’hôte ou une requête à cause de ses protections anti-CSRF. Le domaine local doit alors être explicitement accepté selon la configuration utilisée.
Où trouver le mot de passe initial des versions récentes de qBittorrent ?
L’article précise qu’un mot de passe temporaire aléatoire est écrit dans les logs de démarrage du conteneur, à la place de l’ancien couple de valeurs par défaut.