Hi rjakobsson,
I had exactly the same objective:
To start a torrent client and make it only use the OpenVPN tunnel through the anonine.net anonymizer service.
I started testing on my b3, but it soon became apparent that openvpn would use up too much of the b3 CPU, and also it would complicate the already complex network configuration on b3 even further (it is already configured as an openvpn server).
So I decided to use my old bubba2 as a dedicated torrent machine. It works quite well, even though the speed suffers because of the CPU bottle-neck.
Here are the steps I took. It is a bit crude, but it seems to work so far.
1. I wiped my old bubba2 and installed 2.4 release candidate 3.
I read there are still problems with this concerning RAID setups, but I don't need that.
I set it up as “Server only” and deactivated most of the preconfigured services.
2. Installed openvpn from the repositories and set it up on bubba2:
I copied the example script supplied by anonine and their certificate to /etc/openvpn. Also renamed the script so it is called client.conf.
If you start openvpn using the script as-is, it will prompt for a username and password, so I changed this section:
Code: Select all
#auth-user-pass
# Read credentials from a file
auth-user-pass /etc/openvpn/credentials
The credentials file is just a text file with two lines: username and password.
I also entered the full path to the cert:
To make it work I forwarded UDP ports 1194-1201 to the bubba2 in the b3 firewall.
I also added this to /etc/network/firewall.conf on bubba2:
Code: Select all
-A INPUT -i tap+ -j ACCEPT
-A FORWARD -i tap+ -j ACCEPT
3. Installed transmission-daemon and made it use the tunnel:
After configuring transmission-daemon to my liking, I changed /etc/init.d/transmission-daemon and added openvpn as a requirement to make sure it starts up after openvpn:
Code: Select all
# Required-Start: $local_fs $remote_fs $network openvpn
To make it happen:
Code: Select all
# insserv -vr transmission-daemon
# insserv -v transmission-daemon
Unfortunately that wasn't enough. I had to also add a sleep in the startup-script to make sure the openvpn tunnel was up before starting transmission (see the full script below).
Transmission allows you to configure an IP address to bind to (unfortunately not a network interface).
There is a discussion about that here:
https://trac.transmissionbt.com/ticket/2313
At the bottom of the thread the user forty has posted a useful script that gets the address from ifconfig and updates the settings for transmission-daemon. Thanks!
I modified it to read the address from the openvpn tap interface and called it /etc/transmission-daemon/transmission-ip.sh.
Code: Select all
#!/bin/sh
sed -i "s/\"bind-address-ipv4\":.*\$/\"bind-address-ipv4\": \
\"$(ifconfig tap0 | egrep -o 'addr:[^ ]* ' | cut -d':' -f2 \
| sed 's/ //')\",/" /etc/transmission-daemon/settings.json
I changed /etc/init.d/transmission-daemon so it calls the script above on start, reload and restart.
Code: Select all
#!/bin/sh -e
### BEGIN INIT INFO
# Provides: transmission-daemon
# Required-Start: $local_fs $remote_fs $network openvpn
# Required-Stop: $local_fs $remote_fs $network
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start or stop the transmission-daemon.
### END INIT INFO
NAME=transmission-daemon
DAEMON=/usr/bin/$NAME
USER=debian-transmission
# FIXME: no pidfile support; forks, so --make-pidfile doesn't work either
#PIDFILE=/var/run/$NAME.pid
STOP_TIMEOUT=3
export PATH="${PATH:+$PATH:}/sbin"
[ -x $DAEMON ] || exit 0
[ -e /etc/default/$NAME ] && . /etc/default/$NAME
. /lib/lsb/init-functions
start_daemon () {
if [ $ENABLE_DAEMON != 1 ]; then
log_progress_msg "(disabled, see /etc/default/${NAME})"
else
sleep 15
/etc/transmission-daemon/transmission-ip.sh
start-stop-daemon --start \
--nicelevel 10 \
--chuid $USER \
--exec $DAEMON -- $OPTIONS
fi
}
case "$1" in
start)
log_daemon_msg "Starting bittorrent daemon" "$NAME"
start_daemon
log_end_msg 0
;;
stop)
log_daemon_msg "Stopping bittorrent daemon" "$NAME"
start-stop-daemon --stop --quiet \
--exec $DAEMON --retry $STOP_TIMEOUT \
--oknodo
log_end_msg 0
;;
reload)
log_daemon_msg "Reloading bittorrent daemon" "$NAME"
/etc/transmission-daemon/transmission-ip.sh
start-stop-daemon --stop --quiet \
--exec $DAEMON \
--oknodo --signal 1
log_end_msg 0
;;
restart|force-reload)
log_daemon_msg "Restarting bittorrent daemon" "$NAME"
/etc/transmission-daemon/transmission-ip.sh
start-stop-daemon --stop --quiet \
--exec $DAEMON --retry $STOP_TIMEOUT \
--oknodo
start_daemon
log_end_msg 0
;;
*)
echo "Usage: /etc/init.d/$NAME {start|stop|reload|force-reload|restart}"
exit 2
;;
esac
exit 0
I haven't had to force it to reload the IP address yet. The openvpn tunnel to anonine seems very stable.
It gives me a new IP every time the machine is restarted, but it works just fine with the 15 second delay in the startup of transmission-daemon.
If you haven't got a spare bubba2 lying around, you could do something similar on the b3. You could set a bandwidth limit on the torrent client to keep the openvpn process from using up all your CPU.
You can also set the nice level in the openvpn startup script (like I did in the transmission startup script above).