Quel VPN fonctionne vraiment dans un conteneur Docker dédié au P2P ? Celui que Docker peut utiliser sans protéger tout le serveur

Je pensais avoir terminé mon serveur domestique. Plex fonctionnait. Les sauvegardes fonctionnaient. qBittorrent tournait dans Docker.

Il ne me restait qu’une chose : faire passer uniquement le conteneur P2P par un VPN. J’ai commencé par la solution qui paraît naturelle sur un ordinateur. Installer le VPN sur la machine. Connexion.

Puis relancer le conteneur.

Un test d’IP à l’intérieur de qBittorrent a immédiatement montré pourquoi cette approche ne répondait pas vraiment à mon besoin.

Je ne voulais pas simplement que le serveur utilise un VPN.

Je voulais que le conteneur P2P ne puisse sortir que par ce VPN, pendant que Plex, les sauvegardes et le reste du serveur continuaient normalement.

À partir de là, « quel VPN fonctionne avec Docker ? » n’était plus une question d’application ou de nombre de pays.

C’était une question d’architecture réseau.

Le VPN devait être placé là où sortait réellement le trafic

Docker isole normalement le réseau de chaque conteneur et permet aussi à un conteneur de partager la pile réseau d’un autre.

C’était exactement ce qu’il me fallait. Pas :

serveur entier → VPN → Internet.

Mais :

qBittorrent → conteneur VPN → Internet

pendant que :

Plex → connexion normale.

Cette confusion existe encore dans beaucoup de homelabs : certains utilisateurs se demandent s’il faut lancer le VPN sur l’ordinateur depuis lequel ils administrent qBittorrent ou directement sur le serveur Docker.

Dans mon cas, la réponse devenait simple. Le trafic P2P partait du serveur. Le tunnel devait donc se trouver sur ce chemin-là.

Mon fournisseur habituel avait l’avantage qui comptait ici

Mon fournisseur principal avait plusieurs qualités classiques : beaucoup de serveurs, une longue histoire publique et des applications matures.

Mais aucune de ces qualités n’était décisive. Ce qui comptait était beaucoup plus précis : il me donnait une configuration WireGuard exploitable en dehors de son application graphique.

J’ai donc ajouté Gluetun comme conteneur VPN, puis fait partager sa pile réseau à qBittorrent avec network_mode: "service:gluetun".

Le principe utile tient en une ligne :

qBittorrent n’avait plus sa propre sortie Internet ; il utilisait celle du conteneur VPN.

J’ai lancé le téléchargement d’une image Linux. Puis vérifié l’adresse publique depuis le même environnement. Adresse VPN. J’ai ensuite arrêté Gluetun.

Le téléchargement s’est arrêté. Plex, lui, continuait à fonctionner. C’était exactement le résultat que je cherchais.

Le bon test était ce qui arrivait quand le tunnel disparaissait

Pour du P2P, une adresse VPN correcte quand tout fonctionne ne suffit pas. Je voulais aussi éviter que qBittorrent reprenne silencieusement la connexion normale si le tunnel tombait. Gluetun inclut justement un pare-feu de type kill switch pour ce scénario. J’ai refait le test.

Torrent actif. Conteneur VPN arrêté. Plus de trafic P2P. Pas de reprise visible par l’adresse publique normale.

Gluetun relancé. Connexion restaurée. Le reste du serveur n’avait jamais changé de route. À ce stade, mon critère était fixé :

l’isolation du conteneur comptait plus que la qualité de l’application VPN sur le bureau.

Et c’est précisément ce critère qui allait décider si OnlydogVPN^↗ avait sa place dans cette architecture.

J’ai ensuite essayé de voir si OnlydogVPN pouvait entrer dans ce schéma

J’utilisais déjà OnlydogVPN sur un ordinateur portable.

Sur cet appareil, j’aimais justement ce qui rend l’application plus simple : peu de réglages, une logique par situation et aucune nécessité de manipuler des fichiers WireGuard.

Pour un usage classique, c’est un avantage. Dans Docker, c’est une autre histoire.

Le site public du service propose actuellement des applications pour iPhone, Android, Mac et Windows. Il ne documente pas de client Linux/Docker ni d’export WireGuard ou OpenVPN destiné à une intégration Gluetun.

Or c’était précisément ce que mon conteneur devait pouvoir consommer.

Je ne pouvais pas observer d’éventuelles fonctions internes ou non publiées du service ; je pouvais seulement travailler avec les méthodes officiellement disponibles.

Et avec ce qui est documenté aujourd’hui, je n’avais pas de moyen propre de transformer la petite application en passerelle réseau pour qBittorrent.

Cela ne rendait pas le produit moins intéressant sur mes appareils personnels. Cela signifiait simplement qu’ici, le problème appartenait à une catégorie différente.

Docker inverse presque mes préférences habituelles

Sur mon téléphone ou mon Mac, moins je vois la mécanique du VPN, mieux je me porte. Je préfère choisir une situation. Me connecter. Continuer.

Dans Docker, je veux presque l’inverse. Je veux savoir exactement : quel conteneur porte le tunnel ; quel autre conteneur partage sa pile réseau ;

et ce qui se passe si cette pile disparaît.

Gluetun prend en charge plusieurs fournisseurs et accepte aussi des configurations WireGuard ou OpenVPN personnalisées.

C’est donc cette compatibilité que je vérifierais en premier. Pas le nombre de serveurs. Pas la vitesse annoncée. Pas l’interface mobile.

Et pour un usage P2P plus avancé, je regarderais ensuite si le fournisseur prend en charge le port forwarding, puisque cela peut améliorer la connectivité avec les pairs.

Mais ce point vient après l’isolation. D’abord, je veux être certain que qBittorrent n’a qu’une seule sortie autorisée.

Le P2P en conteneur demande moins de marketing et plus de contrôle

Les discussions récentes autour de qBittorrent et Gluetun montrent bien où apparaissent les vrais problèmes : routage, kill switch, ports entrants et comportement du conteneur lorsque le tunnel tombe.

C’est beaucoup plus concret qu’un badge « P2P compatible ».

Et c’est aussi ce qui m’a évité de forcer OnlydogVPN dans une architecture pour laquelle son offre publique n’est pas encore conçue.

Sur mes appareils personnels, je continue à préférer la petite application précisément parce qu’elle masque les décisions techniques inutiles.

Sur le serveur Docker, je veux les décisions techniques explicites. Les deux usages ne demandent pas la même chose.

J’ai donc gardé deux outils pour deux problèmes différents

Pour mon ordinateur portable, je préfère une application qui me demande le moins possible de configuration. Pour mon conteneur P2P, je veux au contraire une intégration que Docker puisse utiliser directement. Un conteneur VPN. Une pile réseau partagée uniquement avec qBittorrent.

Un kill switch au même endroit. Et aucun retour automatique vers la connexion normale. Mon fournisseur compatible Gluetun a donc gagné ce test précis.

OnlydogVPN reste plus simple pour mes appareils personnels, mais son offre publique actuelle ne documente pas encore l’intégration Linux/Docker nécessaire pour remplacer ce rôle.

C’est une limite que je préfère voir clairement plutôt que de prétendre qu’une bonne application de bureau suffit partout.

Car dans un conteneur P2P, la question décisive n’est pas :

« Ce VPN fonctionne-t-il sur mon ordinateur ? »

C’est :

« Puis-je faire de ce VPN l’unique sortie réseau autorisée à qBittorrent sans toucher au reste du serveur ? »