Faire passer le trafic de Qbittorrent-nox dans un VPN (Celui du nord...) Le sujet est résolu

[lol]

Salut à tous,

J'ai un serveur (Debian stable) sur lequel j'ai un client torrent (Qbittorrent-nox).

Code : Tout sélectionner

# uname -sv
Linux #1 SMP Debian 5.10.92-1 (2022-01-18)

Code : Tout sélectionner

# apt policy qbittorrent-nox
qbittorrent-nox:
  Installé : 4.2.5-0.1
  Candidat : 4.2.5-0.1
 Table de version :
 *** 4.2.5-0.1 500
        500 http://deb.debian.org/debian bullseye/main amd64 Packages
        100 /var/lib/dpkg/status

Jusqu'a présent je faisais passer le trafic de qbittorrent via un VPN en utilisant un Proxy Socks5 C'est ne option de qbitorrent-nox et NordVPN le permettait jusqu'au mois dernier...

Socks.png

Du coup, évidemment, mon client qbittorrent ne fonctionne plus.

Il est possible d'utiliser NordVPN en mode "OpenVPN", je peux donc configurer un tunnel sans forcer tout le trafic à passer dedans.

Sauriez-vous comment forcer le trafic d'une seule application (Ici qbittorrent-nox) via un client Openvpn ?

Merci d'avance.

[dezix]

Peut-être des pistes sur le blog de sundialsvcs | LinuxQuestions (il faut un compte).
Le type est spécialisé dans la sécurisation serveur via OpenVPN notamment un papier Understanding OpenVPN as "a Network Router".

C'est pas grand-chose mais peut-être un début...

Celui-ci est peut-être déjà plus concret :
[HOWTO] A quick explanation of routing setup with OpenVPN tunnels
https://www.linuxquestions.org/question ... 175593272/

[dezix]

Les liens précédents ne sont pas intéressants,
mais en lisant, il me vient une idée de principe : configurer ton application sur un port spécifique et forcer le VPN sur ce port.

[vv222]

Sauriez-vous comment forcer le trafic d'une seule application (Ici qbittorrent-nox) via un client Openvpn ?

Ici j’avais le problème opposé : alors que par défaut tout mon trafic passe par un VPN, comment le faire contourner par une poignée de logiciels ?

La solution que j’ai adoptée est probablement overkill, mais elle fonctionne très bien : un conteneur léger systemd-nspawn dans lequel tournent les applications qui doivent contourner le VPN, et qui se branche via un bridge directement au routeur de l’appartement.

[PascalHambourg]

Autre piste possible : utiliser des "network namespaces" avec des tables de routage distinctes. Mais je n'ai jamais étudié le sujet.

Sinon, la méthode traditionnelle consiste à faire du routage avancé avec un critère permettant de discriminer le trafic à router. Cela peut être le port source ou destination, l'adresse source (si c'est l'adresse de destination pas besoin de routage avancé, le routage de base suffit), l'UID ou le GID du processus...

[lol]

Salut,

Merci pour vos pistes.
@vv222 c'est effectivement une idée. Je n'y avait pas pensé. ça ressemble à un chroot, c'est ça ?
Comment le mettre en place ?

@PascalHambourg, j'ai vu ça ce matin.
On en parle notamment ici: https://superuser.com/questions/241178/ ... -processes mais j'ai pas tout compris...
Un peu au dessus de mes compétences.

@Dezix, c'est du torrent, ça part dans tous les sens (Ports et IPs) c'est compliqué à canaliser...
Pour des questions de sécurité/discrétion je préfère changer de port d'écoute relativement fréquemment.

[PascalHambourg]

Plusieurs méthodes différentes sont décrites dans ce fil de superuser.com. Celle basée sur netns ne me semble pas très compliquée à mettre en oeuvre. Celles basées sur LD_PRELOAD pour changer le comportement par défaut du programme sont aussi intéressantes, par exemple pour forcer une adresse source ou marquer les paquets avec une valeur qui peut ensuite être utilisée pour faire du routage avancé (mais il faut installer/compiler la bibliothèque).

[vv222]

@vv222 c'est effectivement une idée. Je n'y avait pas pensé. ça ressemble à un chroot, c'est ça ?
Comment le mettre en place ?

Pour le conteneur systemd-nspawn, ça ressemble en effet fortement à un chroot et ça se crée de la même manière avec un outil comme debootstrap.

Je vois que j’avais envisagé d’entamer la rédaction d’une documentation sur le sujet fin 2020, mais ça n’a finalement jamais avancé… On a quelque chose de basique sur le wiki Debian officiel, qui ne propose pas tout à fait la méthode que je suis mais donne tout de même les bases : nspawn - Debian Wiki.

C’est le bridge réseau que j’ai eu plus de difficultés à mettre en place, en partie parce que je fonctionne avec une configuration /etc/network/interfaces "à l’ancienne" plutôt que quelque chose comme network-manager ou systemd-networkd. Et surtout parce que je suis une bille en réseau, donc même comprendre les documentations m’a demandé pas mal de boulot.

Je crois me rappeler m’être en partie reposé sur cette documentation pour la mise en place des bridges : BridgeNetworkConnections - Debian Wiki.

[PascalHambourg]

On a vraiment besoin d'un pont pour ce genre de chose ?

[lol]

Salut,

Celle basée sur netns ne me semble pas très compliquée à mettre en oeuvre.

Oui, c'est la méthode qui me semblais le plus adaptée (D’autant qu'on peux lier un process à une interface et non à une IP - Ce qui serait problématique dans mon cas).
Je vais chercher des explications sur le net.

C’est le bridge réseau que j’ai eu plus de difficultés à mettre en place, en partie parce que je fonctionne avec une configuration /etc/network/interfaces "à l’ancienne" plutôt que quelque chose comme network-manager ou systemd-networkd.

Merci mais on est tout de même dans l'artillerie lourde là... Si je pouvais éviter ça m'arrangerais!

[vv222]

On a vraiment besoin d'un pont pour ce genre de chose ?

Je ne sais pas si c’est la seule solution possible, mais c’est la seule que j’avais trouvé pour mon cas. Qui pour rappel est inversé par rapport à celui de lol : l’interface par défaut est le VPN, et je cherchais à le contourner avec certains logiciels.

Ironiquement, le client torrent fait partie des logiciels que je ne souhaite pas faire passer par le VPN.

[lol]

Ironiquement, le client torrent fait partie des logiciels que je ne souhaite pas faire passer par le VPN.

Zut, je suis démasqué...

[vv222]

Dans mon cas c’est parce que le VPN bride ma bande-passante, et que par principe je préfère pour ce genre de trafic "user les tuyaux" de mon FAI commercial (Orange) plutôt que ceux du FAI associatif chez qui je loue le VPN.

Une autre application que je sors du VPN est un proxy cache pour APT (apt-cacher-ng), encore une fois pour ne pas être bridé par la bande-passante réduite du VPN.

[lol]

Dans mon cas c’est parce que le VPN bride ma bande-passante, et que par principe je préfère pour ce genre de trafic "user les tuyaux" de mon FAI commercial (Orange) plutôt que ceux du FAI associatif chez qui je loue le VPN.

Une autre application que je sors du VPN est un proxy cache pour APT (apt-cacher-ng), encore une fois pour ne pas être bridé par la bande-passante réduite du VPN.

Ok, compris.
Je suis sur un VPN payant avec de la bande passante.
Ils ont des points d'entrée dédiés au P2P. Je ne me sens pas gêné du coup.

[PascalHambourg]

On a vraiment besoin d'un pont pour ce genre de chose ?

Je ne sais pas si c’est la seule solution possible, mais c’est la seule que j’avais trouvé pour mon cas. Qui pour rappel est inversé par rapport à celui de lol : l’interface par défaut est le VPN, et je cherchais à le contourner avec certains logiciels

Une solution basée sur du routage avancé devrait être possible, mais à la réflexion elle serait probablement plus compliquée à mettre en place et moins flexible qu'un pont en cas de configuration dynamique par DHCP. Par contre il me semble qu'un pont ne fonctionne pas avec une interface wifi en mode managed/infrastructure ou ad-hoc.

[vv222]

Dans mon cas c’est uniquement un accès via Ethernet (pas de Wi-Fi sur cette machine) et sans DHCP (assignation statique des IPs locales).

Il est tout à fait possible (et même probable) que je ne sois pas parti sur la solution la plus simple. Mais comme je suis vraiment ignare en réseau et qu’au contraire je savais déjà bien manipuler des conteneurs systemd-nspawn, c’était l’option qui pour moi faisait appel au moins de concepts inconnus.

J’en suis quand même ressorti un peu moins ignorant sur les questions de réseau, la mise en place de bridges et leur utilisation par des conteneurs n’étant pas non plus triviale.

À savoir que le routage avancé avait été ma première piste, mais je m’étais vite senti noyé sous une trop grande quantité de connaissances théoriques à assimiler avant de pouvoir envisager la mise en place de quoi que ce soit.

[lol]

Salut,

Soit j'ai loupé une mise à jour, soit je suis un âne...
Le choix de l'interface est possible dans les options avancées de qBittorrent-nox

Capture d’écran 2022-03-08 155953.png

Je garde à l'esprit la possibilité offerte par netns, j'ai fait quelques essais infructueux, mais je n'ai pas tant insisté que ça...

[PascalHambourg]

Le choix de l'interface est possible dans les options avancées de qBittorrent-nox

Et ça suffit à faire passer son trafic par le VPN même sans routage avancé ?
Par contre si ça force le programme à utiliser l'adresse IP de l'interface comme source, ça simplifierait la mise en place de routage avancé.

Il est tout à fait possible (et même probable) que je ne sois pas parti sur la solution la plus simple.

Bof, de toute façon il y a forcément de la complexité quelle que soit la solution choisie. Soit dans la couche réseau pour le routage avancé, soit dans la couche liaison pour le pontage. Les performances sont peut-être un peu moins bonnes avec le pontage puisqu'il faut gérer la couche liaison.

[lol]

Salut,

Et ça suffit à faire passer son trafic par le VPN même sans routage avancé ?
Par contre si ça force le programme à utiliser l'adresse IP de l'interface comme source, ça simplifierait la mise en place de routage avancé.

Je ne suis pas certain que ça utilise l'IP plutôt que l'interface, mais par contre je suis sur que le process (/usr/bin/qbittorrent-nox) est attaché au VPN.
Je viens de vérifier avec nethogs