Comment lier qBittorrent à une interface VPN sur macOS

J'ai ouvert qBittorrent sur un Mac mini, réglé Network Interface sur utun4, redémarré, puis passé un après-midi à regarder un torrent rester bloqué sur la récupération des métadonnées alors que le VPN affichait toujours une connexion saine. Le réglage n'était pas faux en principe ; le nom était périmé. macOS attribue les numéros utun au démarrage des services, donc l'utun4 qui était correct la semaine précédente pointait vers un tunnel qui n'existait plus, et le client liait ses sockets à un périphérique sans route. La séquence ci-dessous est celle que j'utilise maintenant : lire l'interface depuis le tunnel en cours, la sélectionner dans le client, redémarrer la session, puis prouver la liaison par un transfert et une déconnexion volontaire.

Ouvrez Avancé et trouvez le champ d'interface

Dans la fenêtre de qBittorrent, ouvrez les Préférences avec Cmd+, et allez à la page Avancé. Network Interface est le champ qui compte : il liste les noms d'interface du système et vaut Any Interface par défaut, ce qui signifie que le système d'exploitation choisit une route pour chaque socket ouvert par le client. La référence des options du projet documente ce champ et cette valeur par défaut, et c'est le même réglage sur toutes les plateformes même si les noms qu'il contient ne le sont pas.

Deux détails font trébucher ici. La liste affiche des noms de périphériques comme en0, en1 et utun0 à utun9, jamais le nom du produit du fournisseur VPN, il faut donc la correspondance avant de choisir quoi que ce soit de sensé. Et la sélection s'applique au démarrage de la session BitTorrent, pas à l'instant où vous cliquez sur OK, donc un changement qui semble enregistré peut encore tourner sur l'ancienne liaison.

Quittez l'application correctement avec Cmd+Q et confirmez que le processus a disparu avant de la rouvrir. Fermer la fenêtre ne fait que la masquer, et un client masqué conserve sa session, son port d'écoute et son ancienne interface.

pgrep -fl qbittorrent

Trouvez l'interface que votre VPN possède réellement

Connectez d'abord le VPN, via le client du fournisseur, puis lisez la vue du système plutôt que le menu du client. Les commandes ci-dessous listent chaque interface avec ses adresses, montrent celles que le système considère actives et impriment la table de routage ; vous cherchez le périphérique utun qui porte la plage privée attribuée par votre fournisseur.

ifconfig -a | grep -A4 '^utun'
scutil --nwi
netstat -rn -f inet | head -n 5

Trois lectures vous disent quel périphérique est le tunnel. L'entrée utun a besoin d'une adresse inet appartenant au pool du VPN. scutil --nwi montre quelles interfaces le système considère actives et laquelle est primaire. netstat -rn montre où pointe la route par défaut, et si cette route pointe encore vers en0 alors qu'un utun a une adresse, le tunnel ne transporte pas tout le trafic, ce qui change ce que fera la liaison plus tard.

Quand deux tunnels peuvent exister en même temps, par exemple un profil professionnel et un personnel, les deux périphériques utun sont présents et un seul est utile. Les compteurs d'octets tranchent : notez les compteurs, chargez une page ou lancez un petit transfert et voyez lequel a bougé.

netstat -ib | grep utun

Ne considérez pas le numéro comme stable non plus. Une reconnexion peut donner au même tunnel un autre nom utun, et un service iCloud ou Continuity peut occuper utun0 bien avant que votre VPN se connecte.

Adaptez la liaison à la portée du tunnel

Le champ lie un périphérique, et c'est tout ce qu'il fait. Si le VPN est un tunnel complet qui route 0.0.0.0/0 dans l'utun, lier à ce périphérique envoie chaque connexion de pair et chaque requête de tracker par le VPN. Si le VPN est un tunnel divisé qui ne route que quelques sous-réseaux, lier à l'utun envoie le trafic des pairs vers un périphérique sans route pour ces pairs, et les transferts s'arrêtent au lieu de fuir. Les deux résultats sont plus sûrs qu'Any Interface, mais un seul garde le client fonctionnel. Rien en dehors du client ne change : les navigateurs et les autres applications conservent leurs propres routes, donc une exigence couvrant toutes les applications doit être appliquée côté VPN.

Lisez la situation avant de sélectionner quoi que ce soit :

La famille d'adresses compte aussi. Un fournisseur qui n'attribue que de l'IPv4 laisse l'interface liée sans adresse IPv6, donc les pairs IPv6 échouent au lieu de s'échapper par le Wi-Fi. Séparément, lier des sockets ne fixe pas la résolution de noms : les noms d'hôtes des trackers sont résolus par le résolveur de macOS, qui suit la configuration DNS du système et non le périphérique sélectionné.

Trois façons dont une sélection qui semble correcte échoue

Le premier échec est de ne pas redémarrer. Le champ affiche utun4, les préférences semblent configurées, et un transfert de test sort quand même par le Wi-Fi parce que la session en cours a gardé l'ancienne liaison. Quittez complètement, confirmez avec pgrep, rouvrez et relancez le transfert.

Le deuxième est le nom périmé après une reconnexion. Dès que le périphérique lié disparaît, les connexions de pairs échouent et le client a tendance à signaler des erreurs de tracker plutôt qu'un message clair d'interface disparue, ce qui ressemble à un torrent mort. Relisez ifconfig, sélectionnez le nouveau nom et redémarrez.

Le troisième est de supposer que la liaison échoue fermée. Sélectionner une interface demande au système d'attacher des sockets à un nom de périphérique ; ce qui se passe quand ce nom manque ou est recyclé n'est pas garanti par l'écran de réglages. Le test de déconnexion de la section suivante est la seule preuve qui compte.

Vérifiez avec un vrai transfert et une déconnexion

Utilisez un transfert que vous êtes autorisé à lancer, comme une image de distribution Linux, et démarrez-le avec le VPN connecté. Observez les compteurs par interface avant et après, et comparez-les au compteur de données du client VPN ; les deux devraient monter ensemble pendant que la liste des pairs se remplit.

netstat -ib | grep utun
pgrep -fl qbittorrent

Déconnectez ensuite le VPN depuis sa propre interface et observez le transfert. Les pairs devraient disparaître, et les nouvelles connexions échouer peu après la chute du tunnel. Si le débit continue, la liaison n'est pas en vigueur et vous êtes de retour à l'étape du redémarrage, pas au pare-feu.

Reconnectez et vérifiez à nouveau le nom sélectionné, car le tunnel peut revenir sous un autre utun. Une courte note consignant le type de tunnel, le nom de l'interface et le comportement attendu quand le VPN tombe épargne la prochaine session : ce réglage est par machine et par fournisseur, et il ne survit ni à une mise à jour du client ni à un changement d'application VPN.