3 ms·

I think you mean proxy, not VPN? AFAIK qBittorrent doesn't natively do any kind of VPN stuff, so the issue would be elsewere, since it shouldn't be possible if

by 3np 2y ago

I think you mean proxy, not VPN? AFAIK qBittorrent doesn't natively do any kind of VPN stuff, so the issue would be elsewere, since it shouldn't be possible if configured properly. If we're actually talking proxies: If you enable UDP-based protocols, it's very hard to avoid IP leaking. A surprising amount of clients just don't support proxying UDP at at all, or misbehave in various ways. Word of advice: Set up the torrent client in a dedicated VM (or box) and set it up on kernel-level to route all its traffic through a separate VM(/box), which itself connects to the VPN (Wireguard,OVPN or what-have-you) and forwards traffic. It sounds complex but is robust and avoids a lot of potential pitfalls. Reliably routing P2P UDP traffic with container networks is a fool's errand so I wouldn't recommend Docker networks (ofc fine to run the container with network=host tho)

seymon 2y ago
There is the open source software project gluetun, that allows setting up a containers that are only able to communicate through a vpn network interface in an easy way. https://github.com/qdm12/gluetun https://github.com/qdm12/gluetun With this it is not much effort to set up qbittorrent in a privacy secure way.
- 3np 2y ago
  gluetun can be great for many other use-cases, but what I said still stands regarding udp p2p like bittorrent. You are very likely to get surprises like GP unless you are very lucky or really know what you are doing wrt the actual networking configuration.
  - harshreality 2y ago
    If the VPN container does things correctly and kills the default non-vpn route, how would those surprises occur? To be clear, I hope 3np is talking about containers like the following, and not trying to proxy only udp or only tcp piecemeal. services: vpncontainer: image: <whatever> container_name: vpncontainer cap_add: [NET_ADMIN] vpn-qbittorrent: image: lscr.io/linuxserver/qbittorrent:latest container_name: vpn-qbittorrent network_mode: service:vpncontainer # and optionally, for other purposes, not qbittorrent above vpn-socks: image: serjs/go-socks5-proxy container_name: vpn-socks network_mode: service:vpncontainer # environments, volumes, ports, systctls, port-fwd helpers omitted
    - 3np 2y ago
      I'm saying that the underlying container networking (Docker or whatever backend you use for podman) might not behave like you/the software are expecting with these in context more esoteric protocols. If you verify that it behaves like you intend (dump network traffic and make sure packets go where they should over some reasonable timespan and across restarts) and ideally are prepared to file issue for any bug you come across (clears throat) definitely don't let me dissuade you from trying, though. It _should_ work.

by 3np 2y ago

seymon 2y ago

There is the open source software project gluetun, that allows setting up a containers that are only able to communicate through a vpn network interface in an easy way. https://github.com/qdm12/gluetun https://github.com/qdm12/gluetun With this it is not much effort to set up qbittorrent in a privacy secure way.

3np 2y ago
gluetun can be great for many other use-cases, but what I said still stands regarding udp p2p like bittorrent. You are very likely to get surprises like GP unless you are very lucky or really know what you are doing wrt the actual networking configuration.
- harshreality 2y ago
  If the VPN container does things correctly and kills the default non-vpn route, how would those surprises occur? To be clear, I hope 3np is talking about containers like the following, and not trying to proxy only udp or only tcp piecemeal. services: vpncontainer: image: <whatever> container_name: vpncontainer cap_add: [NET_ADMIN] vpn-qbittorrent: image: lscr.io/linuxserver/qbittorrent:latest container_name: vpn-qbittorrent network_mode: service:vpncontainer # and optionally, for other purposes, not qbittorrent above vpn-socks: image: serjs/go-socks5-proxy container_name: vpn-socks network_mode: service:vpncontainer # environments, volumes, ports, systctls, port-fwd helpers omitted
  - 3np 2y ago
    I'm saying that the underlying container networking (Docker or whatever backend you use for podman) might not behave like you/the software are expecting with these in context more esoteric protocols. If you verify that it behaves like you intend (dump network traffic and make sure packets go where they should over some reasonable timespan and across restarts) and ideally are prepared to file issue for any bug you come across (clears throat) definitely don't let me dissuade you from trying, though. It _should_ work.