Quel VPN coupe automatiquement le client P2P si le tunnel tombe ? J’ai fini par préférer lui retirer toute route de sortie

Le téléchargement affichait encore plusieurs mégaoctets par seconde. Le problème, c’est que mon VPN affichait Déconnecté. J’ai regardé les deux fenêtres une deuxième fois. VPN : hors ligne.

qBittorrent : téléchargement en cours.

Pendant une seconde, j’ai cru que le client P2P affichait simplement une ancienne valeur. Les compteurs de débit peuvent mettre quelques secondes à retomber.

Alors je n’ai pas regardé le chiffre. J’ai regardé la quantité de données reçues. Elle continuait d’avancer.

C’est là que mon vieux raisonnement — « j’ai un kill switch, donc qBittorrent s’arrête si le VPN tombe » — a commencé à me paraître beaucoup moins rassurant.

Je ne voulais pourtant rien télécharger de douteux

Pour mes tests, j’utilisais l’image officielle d’Ubuntu proposée par Canonical en BitTorrent. Ubuntu distribue officiellement ses images de cette manière, ce qui me permettait de provoquer des coupures et des reconnexions sans transformer le test en question de droit d’auteur.

Et c’était précisément ce que je voulais mesurer. Pas le débit maximal. Pas le nombre de pairs. Une seule chose :

si le tunnel disparaît pendant que qBittorrent travaille, existe-t-il encore un chemin permettant au client de continuer directement par ma connexion normale ?

J’avais longtemps pensé qu’un kill switch répondait automatiquement à cette question.

En réalité, j’avais mélangé deux mécanismes.

Un kill switch ne « ferme » pas nécessairement qBittorrent

Le nom prête presque à confusion. J’imaginais un interrupteur qui voyait le VPN tomber et envoyait immédiatement l’ordre : fermer qBittorrent. Ce n’est généralement pas ce qui se passe.

Un kill switch agit surtout sur le réseau. Il bloque le trafic lorsque le tunnel protégé n’est plus disponible. Proton documente par exemple un mode avancé qui empêche l’appareil d’accéder à Internet tant qu’aucune connexion VPN n’est active.

qBittorrent, lui, peut rester parfaitement ouvert. La fenêtre ne disparaît pas. Les torrents restent dans la liste. Le compteur peut même mettre un instant à redescendre.

Ce qui compte n’est donc pas de savoir si le programme s’est fermé. La vraie question est beaucoup plus stricte : peut-il encore envoyer ou recevoir des données en dehors du tunnel ? À partir de là, j’ai arrêté de regarder uniquement le bouton du VPN.

J’ai commencé à regarder la route dont disposait réellement le client P2P.

Le premier réflexe était logique : utiliser le kill switch le plus strict possible

J’ai commencé avec un grand fournisseur. Kill switch avancé activé. VPN connecté. Torrent Ubuntu lancé.

Puis j’ai interrompu le tunnel. Cette fois, le résultat était net. Le transfert s’est arrêté. Mais mon navigateur aussi.

Ma messagerie aussi. Tout l’ordinateur avait perdu Internet.

Techniquement, c’était exactement ce qu’un kill switch global devait faire : empêcher les applications de profiter de la connexion normale dès que le VPN disparaissait.

Pour quelqu’un qui veut que tout son trafic passe constamment par le tunnel, c’est une protection très cohérente.

Mon besoin était pourtant plus précis. Je voulais une règle impossible à oublier pour qBittorrent. Même si, un jour, je modifiais le kill switch. Même si le client P2P se lançait avant que je pense à connecter le VPN.

Même si un réglage changeait après une mise à jour. Je ne voulais plus demander au VPN : « Peux-tu arrêter qBittorrent si quelque chose tourne mal ? » Je voulais dire directement à qBittorrent :

« Cette interface VPN est ta seule porte. Si elle disparaît, tu ne sors plus. »

qBittorrent possède justement cette porte unique

Le projet qBittorrent maintient un guide consacré exactement à cette configuration.

Dans les paramètres avancés, le client permet de sélectionner une Network Interface précise. En liant qBittorrent à l’interface créée par le VPN, les transferts utilisent cette interface au lieu de pouvoir basculer librement vers la connexion normale.

C’était beaucoup plus proche de ce que je cherchais. Sur Windows, j’ai observé les interfaces réseau avec le VPN déconnecté. Puis je l’ai connecté. Une interface supplémentaire est apparue.

Dans qBittorrent : Options. Avancé. Interface réseau.

J’ai sélectionné celle du tunnel. Puis redémarré le client. Le changement paraissait minuscule. Pourtant, il déplaçait la protection exactement à l’endroit où se trouvait mon risque.

Le VPN n’avait plus besoin de « reconnaître » qBittorrent et de lui couper Internet au bon moment.

qBittorrent n’avait simplement plus le droit d’emprunter une autre porte.

Le test qui m’a convaincu était celui où rien ne se passait

J’ai repris le torrent Ubuntu. VPN connecté. Le téléchargement est parti. J’ai attendu que le débit se stabilise, puis j’ai coupé le tunnel.

Cette fois, je n’ai pas regardé immédiatement le nombre de Mo/s.

Un utilisateur de r/qBittorrent posait justement cette question en 2026 : après avoir lié son client au VPN, l’interface affichait encore « downloading » après la coupure, ce qui lui faisait penser que le bind avait échoué. La discussion montrait surtout pourquoi l’état affiché ou une moyenne de débit ne suffit pas à savoir si de nouvelles données circulent encore.

J’ai donc regardé la progression réelle. Elle s’est immobilisée. J’ai attendu. Toujours rien.

J’ai reconnecté le tunnel. Le transfert est reparti.

C’était exactement le comportement que j’avais essayé d’obtenir en cherchant un « VPN qui coupe automatiquement le client P2P ».

En réalité, je n’avais pas besoin de tuer le programme.

J’avais besoin que le programme se retrouve sans route autorisée.

Un rapport récent m’a empêché de considérer le bind comme une formule magique

J’aurais pu m’arrêter là. Bind configuré. Problème réglé.

Mais un rapport ouvert en août 2026 dans le projet qBittorrent m’a poussé à conserver une deuxième couche de protection.

Dans une configuration Linux particulière, son auteur indiquait que certaines requêtes vers des trackers pouvaient encore emprunter l’interface normale malgré un bind vers tun0, notamment après l’échec d’une première tentative réseau.

Ce rapport ne signifie pas que tous les utilisateurs rencontrent cette fuite. Il m’a surtout appris à ne pas donner à un seul réglage des pouvoirs absolus. Je préfère désormais deux protections qui échouent dans le bon sens :

qBittorrent lié au tunnel, pour qu’il n’ait normalement aucune route de secours ;

et une protection réseau côté VPN, pour éviter qu’une erreur du premier mécanisme transforme immédiatement ma connexion directe en solution de repli.

Cette combinaison m’intéressait davantage que la simple présence du mot « kill switch » dans une fiche produit.

C’est avec ce test-là que j’ai ouvert OnlydogVPN

J’ai donc refait l’expérience avec OnlydogVPN^↗. Pas de Speedtest. Pas de comparaison de vingt destinations. Le même torrent Ubuntu.

Le même ordinateur. La même question. J’ai relié qBittorrent à l’interface créée par le tunnel, puis lancé le transfert. Il est parti normalement.

J’ai ensuite provoqué une perte de connexion VPN. La progression s’est arrêtée. Pas de tunnel. Pas de nouveau trafic P2P.

Puis la connexion protégée est revenue. Et le transfert a repris par le chemin auquel je l’avais lié.

À ce moment-là, le comportement de récupération du service est devenu intéressant pour une raison très simple : une coupure sûre n’avait plus besoin de rester une coupure longue.

Le service utilise un transport basé sur HTTP/3 et documente justement son comportement lors des interruptions et des reprises de réseau.

Dans mon test, les deux mécanismes avaient donc des rôles très différents. Le bind décidait où qBittorrent avait le droit de passer. Le VPN devait surtout remettre cette route en état rapidement lorsqu’elle disparaissait.

Cette séparation m’a beaucoup plus rassuré qu’un grand bouton « kill switch ».

La reconnexion est secondaire — jusqu’au jour où elle devient pénible

Pour du P2P, je préfère toujours un torrent bloqué toute la nuit à un torrent qui reprend trente secondes par ma véritable connexion Internet.

La priorité reste donc évidente : échouer fermé d’abord. Reprendre proprement ensuite. Mais une fois le premier point assuré, la récupération compte vraiment.

Des utilisateurs de qBittorrent décrivent aussi l’autre extrême : le bind fonctionne, le torrent s’arrête correctement lorsque le VPN disparaît, puis il reste bloqué après la reconnexion et nécessite parfois une intervention manuelle.

Ce n’est pas une fuite.

Mais c’est exactement le genre de friction qui finit par pousser quelqu’un à assouplir une bonne protection parce qu’elle devient pénible au quotidien.

Dans mon test, je n’avais pas ce choix à faire. Le torrent cessait d’avancer lorsque sa route disparaissait. Puis il retrouvait cette route lorsque le tunnel revenait. Je pouvais donc conserver la règle stricte sans transformer chaque brève coupure en maintenance manuelle.

J’ai aussi cessé d’utiliser un test qui ne testait presque rien

Avant, ma vérification ressemblait à cela : VPN connecté. Je visite une page affichant mon IP. Elle montre celle du VPN.

Parfait. Mais ce test répond seulement à la question : « Quelle adresse utilise mon navigateur maintenant ? » Il ne répond pas à celle qui m’intéresse :

« Que fera qBittorrent trois secondes après la disparition du tunnel ? » Mon test est désormais volontairement plus brutal. Je prends un torrent légal. Je connecte le VPN.

Je vérifie que le transfert fonctionne. Je provoque une coupure. Les octets doivent cesser d’avancer. Puis je reconnecte.

Le torrent ne doit reprendre qu’une fois la route VPN revenue.

Cette séquence m’en apprend davantage qu’une icône verte ou qu’un test d’adresse IP effectué lorsque tout fonctionne normalement.

Le petit service n’est pas celui que je choisirais pour toutes les architectures P2P

OnlydogVPN possède moins de régions, moins de recul public et moins de tests indépendants accumulés que plusieurs fournisseurs installés depuis longtemps.

Pour un serveur P2P sous Docker, un NAS fortement personnalisé ou une configuration nécessitant un port entrant particulier, je vérifierais séparément les besoins techniques.

Mais ce n’était pas mon problème.

J’avais qBittorrent sur un ordinateur.

Je voulais pouvoir le laisser travailler sans qu’une chute du tunnel transforme silencieusement ma connexion normale en sortie de secours.

Au début, je cherchais donc le kill switch le plus impressionnant.

qBittorrent m’a appris qu’il était plus sûr de retirer directement au client les routes qu’il ne devait jamais emprunter.

Puis le test avec le petit VPN a rendu ce choix beaucoup plus facile à conserver : lorsque la route protégée disparaissait, le transfert s’arrêtait ; lorsqu’elle revenait, le travail pouvait reprendre là où il devait.

J’avais commencé en cherchant quel VPN pouvait fermer automatiquement qBittorrent.

Je ne cherche plus cela.

Pour mon client P2P, je préfère que le tunnel soit sa seule porte : s’il tombe, le torrent n’a rien d’autre à emprunter.