Abstract

Run deluged in an isolated environment, so that it cannot make direct connections.

A very simple and reliable measure forces all traffic through the proxy.

Prerequisites

Client
- Docker
Server:
- running sshd
  - both OpenSSH and Dropbear work
  - enabled GatewayPorts
  - enabled public key authentication for user with NET_ADMIN rights
- installed pppd

Disclaimer

Use at your own risk

Usage

On the server, add the following iptables rule:
```
# iptables -I FORWARD 1 -i ppp-deluged -j ACCEPT
```
On OpenWrt it can be added through Network → Firewall → Custom Rules or, alternatively:
- Network → Interfaces → Add new interface
  - Name: deluged
  - Protocol: Unmanaged
  - Custom Interface: ppp-deluged
- Network → Firewall → General Settings → Zones → Add
  - Name: deluged
  - Covered networks: deluged
  - Inter-Zone Forwarding (both destination and source): wan

Add the following to ~/.ssh/config:

Host deluged-proxy
        Hostname <ssh server ip>
        Port <ssh server port>
        User <ssh server user>
        IdentityFile <ssh private key>

The private key should be also in ~/.ssh directory, otherwise it would not be shared with the container.

Put deluged files into ~/var-lib-deluged, so that it looks like this:

~/var-lib-deluged
├── Downloads
└── config
    ├── auth
    └── core.conf

Start the daemon and the proxy:
```
deluge-via-proxy$ ./restart
```
Start the client:
```
deluge-via-proxy$ ./deluge-console
```

Port forwarding

If seeding performs badly, set the following in ~/var-lib-deluged/config/core.conf:
```
"random_port": false

"listen_interface": "0.0.0.0"

"listen_ports": [
  6881,
  6891
]
```
and forward them to 192.168.77.2 on the server.

Setting listen_interface to 0.0.0.0 here is safe, since the daemon runs inside a container. Doing so helps with reestablishing ppp0 interface on reconnect.

How does it work

deluged container is connected only to the internal deluge network.
- Daemon cannot connect to the Internet directly - all packets are blocked, including pings, DNS requests and regular traffic.
- Besides deluged itself, this container also runs pppd
  - One end of pppd is connected to a local interface. A default route points to a remote peer of this interface.
  - The other end is connected to port 7777 in deluged-proxy container.
deluged-proxy container is connected to both deluge network and LAN.
- Incoming connections to port 7777 are bound to new ssh connection to the server, which runs pppd command.
- The effect is that pppd instances inside the deluged container and on the server talk to each other through the ssh tunnel.
- SOCKS proxies are not used, because their way of relaying UDP is incompatible with ssh, and ssh's own -D option is not used, because it does not support UDP.
deluged-public container is also connected to both deluge network and LAN. It publishes deluged's port 58846 in order for GUI clients to connect. It is needed, because deluged must not be attached to the host network, and therefore its ports cannot be published directly.
deluge-console is docker execed inside the deluged container.

Misc

When running deluged on slow hardware, deleting or pausing unneeded torrents helps with performance.

Debugging

To debug libtorrent, use:

deluge-via-proxy$ ./debug

and then either

 # strace \
     -f \
     -o strace.out \
     -s 4096 \
     -ttt \
     deluged \
         --do-not-daemonize \
         --config=/var/lib/deluged/config \
         --loglevel=debug &
 # less strace.out

 # gdb --args \
     python $(which deluged) \
         --do-not-daemonize \
         --config=/var/lib/deluged/config \
         --loglevel=debug

mephi42/deluged-via-proxy