主页 / ubuntu / 问题 / 583679
Accepted
seanlano
Asked: 2015-02-10 21:45:00 +0800 CST

OpenVPN 上的传输守护进程

  • 772

我最近获得了一个 BeagleBone Black，我已经使用这种方法在其上安装了 Ubuntu 。到目前为止一切正常。我想将我的 BeagleBone 用作 torrent box，但我不想直接通过我的 Internet 连接进行（我认为我的 ISP 不会喜欢它）- 所以我从欧洲服务器购买了 VPN 订阅. 我之前已经手动将我的笔记本电脑连接到这个 VPN 并运行 Transmission。我知道 VPN 连接在 Ubuntu 中有效，主机提供了 OpenVPN 的设置信息。恼人的是，分配的 IP 地址的动态特性意味着它会经常更改，因此当我将笔记本电脑与 VPN 一起使用时，我会手动将传输中的侦听地址设置为所需的值。

理想情况下，我想要以下设置：

  • 传输仅通过 VPN 运行，禁止通过普通 WAN 连接运行种子
  • 只有定向到传输的流量将被接受或通过 VPN 发送，所有其他未经请求的流量将被丢弃
  • 传输根据分配的 IP 地址使用适当的端口进行侦听
  • OpenVPN 在启动时自动启动，随后启动传输
  • Transmission 的 Web GUI 可以通过 LAN 访问，也可以通过我的 WAN 连接通过 Internet 访问（即不通过 VPN 返回）
networking

5 个回答

  1. 更新： (2022-04-13) 已经有一段时间了，我找到了一种新方法，使用 Linux 网络命名空间。有关步骤，请参阅我的新答案。我也绝对不会再使用那个旧的 Beaglebone 板了！这些步骤同样适用于任何 CPU 类型。

    注意： (2016-02-22) 我已经意识到此配置通过普通 WAN 将 DNS 查询泄漏给 torrent 跟踪器，而不是通过 VPN 发送它。我正在研究如何解决这个问题。不过，我将继续运行我的配置，因为连接本身确实正确使用了 VPN。

    更新： 我注意到，当我在 Beaglebone 上将 Transmission 设置为通宵下载时，一段时间后 CPU 使用率会达到 100%。它似乎不会在相同的时间后发生，有时整晚都很好，有时它会在 10 分钟后挣扎。它还可以通过暂停所有种子并等待 CPU 负载恢复正常，然后重新开始来恢复。我还在调查。一种解决方法可能是定期暂停和恢复种子，尽管这不是一个很好的解决方法。 请注意，此问题仅适用于 Beaglebone，也可能适用于其他 ARM 设备。我从来没有在 x86 CPU 上遇到过这个问题。

    介绍

    我已经为在 BeagleBone Black 上运行的 Ubuntu 14.04 开发并测试了这个解决方案。我使用的 VPN 提供商称为ibVPN。它应该适用于任何支持的硬件（即在“普通”x86 计算机上），适用于任何兼容 OpenVPN 的 VPN 提供商 - 并且可能适用于 14.10 或更高版本。在某些时候，我相信 Ubuntu 将使用 SystemD 进行引导，这意味着需要迁移此处使用的 Upstart 脚本。更新： Jonas Kalderstam在下面给出了使用 SystemD 的答案。我还假设 ufw 被用作防火墙，如果您使用的是不同的东西，那么这里的 ufw 命令将需要更改。

    我假设所有工作都是通过与系统的 SSH 连接完成的，尽管如果输入到物理终端也同样有效。

    这是一个相当长的教程，请先阅读所有内容，并确保您对将要做的事情感到满意。

    我还注意到传输没有正确绑定到用于发送 UPnP/NAT-PMP 数据的 IP 地址——即 torrent 数据正确地通过 VPN，但是如果启用了 UPnP 端口转发，传输将请求从本地路由器转发端口，而不是通过来自 VPN 服务器的 VPN。因此，我已经让 Upstart 脚本禁用端口转发，因为它可能看起来好像有效，但实际上没有。应该可以使用 iptables 和 iproute 强制来自 debian-transmission 用户的所有流量通过 VPN，但我仍在研究这个问题。如果将默认路由更改为通过 VPN 发送所有 Internet 数据，它也应该可以工作，但我不想这样做，因为我也将此服务器用于其他事情，这也会导致所有系统更新都通过VPN。如果您真的想让 UPnP 通过 VPN 工作，这个问题有更多信息。 更新： falk0069 在下面有一个很棒的提示，可以帮助鼓励通过 VPN 进行 UPnP。

    安装和配置 OpenVPN

    我建议您先尝试使用 Ubuntu 让您的 VPN 连接正常工作，然后再尝试让它在这里工作——即从桌面上工作。这将确认您拥有正确的配置并减少调试时间。

    首先，安装需要的包

    sudo apt-get install openvpn

    接下来，创建一个目录来存储配置文件。我正在使用 /opt/ibVPN，因为这是我正在使用的提供商。将其更改为您喜欢的任何内容。

    sudo mkdir /opt/ibVPN

    在这个新目录中要做的第一件事是创建用于运行 VPN 客户端的配置文件。ibVPN 为 Linux 用户提供了一个基本的配置文件，我主要只是复制并粘贴了它。

    cd /opt/ibVPN
sudo vim config.ovpn

    使用 VPN 提供商的设置，将编辑后的版本复制并粘贴到 vim 中。（仅供参考，在 Ubuntu 终端中粘贴是Ctrl+Shift+V）您应该可以从您的 VPN 提供商处获得它。

    remote 888.888.888.888 1194 udp      #This address will be different for you
client
dev tap1
resolv-retry infinite
script-security 3 system
explicit-exit-notify 3
persist-key
mute-replay-warnings
ca ibvpn.com.crt
comp-lzo
verb 3
mute 20
ns-cert-type server
fragment 1300
route-delay 2
reneg-sec 0
max-routes 5000
link-mtu 1578

auth-user-pass pass
auth-nocache
persist-tun
route-noexec
lport 1195
lladdr 00:FF:11:AA:BB:CC
route-up "/opt/home/openvpn/route-up.sh"
down "/opt/home/openvpn/down.sh"

    对于那些不熟悉 vim 的人，按下 Insert 以键入或粘贴文本，然后按下 Escape 并键入 :wq 以保存并退出。当然，您不必使用 vim - 任何文本编辑器都可以。

    我将快速解释这个配置文件：前 18 行指定用于服务器的特定设置，这些来自 ibVPN - 如果您有不同的提供商，您的设置可能会略有不同。下一行是我指定的修改选项。

    • 如果您的设置文件中有任何带有 的行auth-user*，请将其注释掉。为了使此设置自动运行，我们需要一个包含用户名和密码的文件 - 因此请确保您为 VPN 提供商选择的密码是强密码、随机密码和唯一密码。

    • 这auth-user-pass pass告诉 OpenVPN 查找一个名为pass从中读取用户和密码的文件。

    • auth-nocache从内存中删除密码，如果您担心的话，这可能会稍微提高安全性。

    • persist-tun如果您的连接断开，将尝试与服务器保持相同的 IP 地址，这应该意味着更少的传输守护进程的启动和停止。

    • route-noexec告诉 OpenVPN 客户端不要自动使用服务器提供的路由 - 这将通过 VPN 拉取所有网络流量。我们只想发送种子流量，因此我们需要使用不同的路由设置。

    • lport 1195告诉 OpenVPN 客户端使用端口 1195 而不是 1194 - 在我的例子中，我还想在同一设备上运行 OpenVPN 服务器，并且服务器需要使用端口 1194。即使你没有运行 OpenVPN 服务器，它进行此更改并没有什么坏处。

    • 我将行更改dev tap为dev tap1, 以强制虚拟设备成为 tap1 而不是由 OpenVPN 分配，同样是因为运行单独的 OpenVPN 服务器。即使您没有运行 VPN 服务器，此更改也无关紧要。防火墙脚本是为使用而编写的tap1，因此如果您更愿意使用其他设备，请记住在适当的地方更改这些脚本。

    • lladdr 00:FF:11:AA:BB:CC告诉 OpenVPN 为 tap 接口分配这个 MAC 地址，这对 iptables 防火墙规则很有用。

    • route-up并down根据需要运行脚本来启动和停止 Transmission-daemon - 这里需要这些，因为它们使用包含有关连接信息的环境变量运行，这是将 Transmission 正确绑定到正确的 IP 地址和端口所必需的。

    在我的例子中，我有一个来自 VPN 提供商的服务器证书——它也必须与配置文件位于同一目录中。

    sudo vim /opt/ibVPN/ibvpn.com.crt

    复制并粘贴它，或通过 SCP 或 SSHFS 移动它。

    -----BEGIN CERTIFICATE-----
MIIDeDCCAuGgAwIBAgIJAMVKgpjMPUfxMA0GCSqGSIb3DQEBBQUAMIGFMQswCQYD
VQQGEwJVUzELMAkGA1UECBMCQ0ExFTATBgNVBAcTDFNhbkZyYW5jaXNjbzEVMBMG
A1UEChMMRm9ydC1GdW5zdG9uMRgwFgYDVQQDEw9Gb3J0LUZ1bnN0b24gQ0ExITAf
BgkqhkiG9w0BCQEWEm1lQG15aG9zdC5teWRvbWFpbjAeFw0xMDA3MjExOTU5MzVa
Fw0yMDA3MTgxOTU5MzVaMIGFMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFTAT
BgNVBAcTDFNhbkZyYW5jaXNjbzEVMBMGA1UEChMMRm9ydC1GdW5zdG9uMRgwFgYD
VQQDEw9Gb3J0LUZ1bnN0b24gQ0ExITAfBgkqhkiG9w0BCQEWEm1lQG15aG9zdC5t
eWRvbWFpbjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAz23m3BXY5Asiw8Dx
T4F6feqsp+pIx6ivftTniyUCbSAxI1J1s1x75DzxmUpIwPu5xavzgPXgZr8FT81X
JGqF9km4AE95iddJawKx0wNgdTo7GximQq9rw0dsQIB5hZZQ9TJwHC3VOnmEic5A
OawKOCybMcRs8saLakZOgh7Xc+UCAwEAAaOB7TCB6jAdBgNVHQ4EFgQUeRhE2N4l
XwL4H1dbjkZ4ou6fj3AwgboGA1UdIwSBsjCBr4AUeRhE2N4lXwL4H1dbjkZ4ou6f
j3ChgYukgYgwgYUxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTEVMBMGA1UEBxMM
U2FuRnJhbmNpc2NvMRUwEwYDVQQKEwxGb3J0LUZ1bnN0b24xGDAWBgNVBAMTD0Zv
cnQtRnVuc3RvbiBDQTEhMB8GCSqGSIb3DQEJARYSbWVAbXlob3N0Lm15ZG9tYWlu
ggkAxUqCmMw9R/EwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQASt0pl
WzVseQLTNM8Mlgw4ZnGAv/x2xnijmMqrkE+F7pnaOicGpxgCfMKzjZuJu0TNJqF2
fibE7GhMdomD4dLFgIu8Wb5E7iQ1CSBEOGumRhK8qCsDzjr7WXUdhqA6Xvo+ylU6
DMzy0Wn3NNvfGC+qxOgybYCJwDnVPi0CEDSbzQ==
-----END CERTIFICATE-----

    显然，如果您没有使用 ibVPN 帐户，您的证书将有所不同。

    现在让我们制作密码文件：

    sudo vim /opt/ibVPN/pass

    第一行必须是完整的用户名，然后第二行必须是密码。这必须是该文件的唯一内容。

    [email protected]
myBIGstrongpassword1234567890

    我们还必须保护此文件的权限，否则 OpenVPN 将无法启动。

    sudo chmod 400 pass

    这将使该文件成为只读文件，并且仅供所有者使用（即其他用户根本无法读取它）

    这些命令将创建在启动时运行的文件，并将它们设置为只能由 root 执行。

    sudo touch route-up.sh
sudo touch down.sh
sudo chmod 700 route-up.sh
sudo chmod 700 down.sh

    此时，测试 VPN 连接是否真正有效可能是个好主意。开始连接：

    sudo openvpn --cd /opt/ibVPN --config config.ovpn

    您会看到无法运行 up 和 down 外部命令的警告，但不要担心。如果成功，您将Initialization Sequence Completed在终端上看到。按Control+C结束连接。如果它不起作用，您将必须调查原因并在继续之前修复它。我发现有时需要几次才能开始工作。确保您的密码文件正确。互联网上有很多关于 OpenVPN 的重要资源，所以请四处看看。

    此时，继续启动并运行 Transmission 可能是最简单的方法。一旦确定 VPN 和 Transmission 都可以单独运行，就可以将它们组合起来。

    安装和配置传输

    安装所需的包：

    sudo apt-get install transmission-daemon

    默认情况下，Transmission 将在启动时自动运行。由于我们最终将使用 OpenVPN 启动传输，因此我们希望禁用它。为此，编辑 Transmission-daemon 的配置文件

    sudo vim /etc/default/transmission-daemon

    并将以下行更改为：

    ENABLE_DAEMON=0

    现在传输不会在启动时启动。

    现在让我们为传输设置创建一个目录，并为下载的种子文件创建一个目录。这假设您已经设置了某种类型的磁盘，并将其安装在 /media/arm-disk/。出于安全目的，守护进程将由其自己的用户运行，而不是以 root 或“ubuntu”身份运行。transmission-daemon“debian-transmission”的安装程序创建了一个新用户。该用户需要拥有我们创建的文件夹，并且对正在下载的种子文件的存储位置具有读写权限。

    sudo mkdir /opt/transmission
sudo chown debian-transmission:debian-transmission /opt/transmission
sudo mkdir /media/arm-disk/torrents-complete
sudo chown debian-transmission:debian-transmission /media/arm-disk/torrents-complete
sudo mkdir /media/arm-disk/torrents-incomplete
sudo chown debian-transmission:debian-transmission /media/arm-disk/torrents-incomplete

    现在我们需要开始传输，只是简单地，以便它创建我们需要的设置文件：

    sudo -u debian-transmission -g debian-transmission /usr/bin/transmission-daemon --config-dir /opt/transmission --foreground

    该命令以 debian-transmission 用户身份启动 transmission-daemon，告诉它使用 /opt/transmission 目录作为设置文件，并告诉它继续在前台运行。运行几秒钟后，按Control+C结束它。我们现在可以编辑设置文件。

    sudo -u debian-transmission vim /opt/transmission/settings.json

    我们现在需要将默认值更改为以下行：

    "download-dir": "/media/arm-disk/torrents-complete",

"incomplete-dir": "/media/arm-disk/torrents-incomplete",

"incomplete-dir-enabled": true,

"rpc-whitelist": "127.0.0.1,192.168.1.*",

    保存并退出（Escape，输入：wq，然后回车）

    中间的两个编辑将允许使用“不完整”目录，将完成的种子与未完成的种子分开。这不是完全必要的，但我个人认为它非常有用。最后的编辑使局域网中的任何计算机都可以访问 web GUI（假设您的局域网子网是 192.168.1.0，如果不同则修改此项）。

    现在再次运行 Transmission 是个好主意，看看它是否有效，是否真的可以下载 torrent。我们将使用 Web 浏览器窗口访问 GUI 并添加 Torrent。首先，让我们允许从 LAN 通过防火墙访问 Web GUI，然后再次运行 transmission-daemon。

    sudo ufw allow in from 192.168.0.0/16 to any port 9091
sudo -u debian-transmission -g debian-transmission /usr/bin/transmission-daemon --config-dir /opt/transmission --foreground

    在 Firefox（或您喜欢的任何浏览器）中访问此 URL：http://XXX.XXX.XXX.XXX:9091，其中 XXX 替换为您在 LAN 上的服务器地址（即 192.168.1.10）。找到要下载的种子文件，例如 1080p60hz 的 Big Buck Bunny。这是一部免费短片，可合法免费下载。在传输 GUI 中，单击“打开 Torrent”按钮，并将此链接（或您喜欢的任何其他 Torrent）粘贴到第一个框中。然后按“上传”。如果 Transmission 工作正常，torrent 将开始下载。如果没有，那么您需要在继续之前找出原因。Internet 上有很多资源可用于使用 transmission-daemon。也可能是您选择的种子无效，请先尝试其他几个。

    下载完成后，Control+C在终端窗口中按停止传输守护进程。

    配置绑定传输到 VPN 接口

    现在让我们制作一个 Upstart 脚本，它将用于在 VPN 准备就绪时启动传输。

    sudo mv /etc/init/transmission-daemon.conf /etc/init/transmission-daemon.conf.bak

    如果出现此问题，请不要担心，这只是为了备份 Upstart 文件（如果存在的话）——它可能不存在。让我们打开 vim 来编辑新的：

    sudo vim /etc/init/transmission-daemon.conf

    将其粘贴到编辑器中：

    description "transmission-daemon, attached to OpenVPN tunnel tap1"

start on transmission-daemon-start
stop on runlevel [!2345] or transmission-vpn-down

# This includes the information from OpenVPN into this environment

export LOCAL_IP
env PORT=51413

# give time to send info to trackers
kill timeout 30

# Run as unprivileged user
setuid debian-transmission
setgid debian-transmission

# Start transmission again if it stops for some reason
respawn
# If transmission stops 5 times in a minute, give up trying to respawn it
respawn limit 5 60

exec /usr/bin/nice -15 /usr/bin/transmission-daemon --config-dir /opt/transmission --bind-address-ipv4 $LOCAL_IP --peerport $PORT --no-portmap --foreground

    保存并关闭 vim。（Escape，然后键入:wq）。再次打开 vim：

    sudo vim /etc/init/transmission-up.conf

    并粘贴这个：

    description "Script to create firewall and routing rules for transmission-daemon"

start on transmission-vpn-up

# This includes the information from OpenVPN into this environment
export VPN_GATEWAY
export LOCAL_IP
env PORT=51413

task

script
    # Set up IP route, firewall rules
    # It doesn't matter if they already exist, they will be skipped
    /sbin/ip route add default via $VPN_GATEWAY dev tap1 table 200
    /sbin/ip rule add from $LOCAL_IP table 200
    /sbin/ip route flush cache
    /usr/sbin/ufw insert 1 reject out on eth0 from any port $PORT
    /usr/sbin/ufw insert 1 reject in on eth0 to any port $PORT
    /usr/sbin/ufw insert 1 deny in on tap1 to any
    /usr/sbin/ufw insert 1 allow in on tap1 to any port $PORT proto udp
    
    # Start the actual transmission-daemon process, in a separate task so that unprivileged user/group can be set
    /sbin/initctl emit transmission-daemon-start LOCAL_IP=$LOCAL_IP
    
end script

    再次保存并关闭 vim。（Escape，然后键入:wq）。最后：

    sudo vim /etc/init/transmission-down.conf

    粘贴这个：

    description "Script to remove firewall rules for transmission-daemon"

start on runlevel [!2345] or stopping openvpn-transmission
env PORT=51413

task

script
    # Take down IP route, firewall rules
    # It doesn't really matter if they don't get taken down, but this will be cleaner
    /usr/sbin/ufw delete reject out on eth0 from any port $PORT
    /usr/sbin/ufw delete reject in on eth0 to any port $PORT
    /usr/sbin/ufw delete deny in on tap1 to any
    /usr/sbin/ufw delete allow in on tap1 to any port $PORT proto udp

    /sbin/ip route flush cache
    
end script

    These scripts tell Upstart to listen for the "transmission-vpn-up" signal. The "transmission-up.conf" script then sets up the required routing rules to send traffic from the local VPN address via the VPN interface, and sets the firewall to allow in traffic from the VPN to the listening port for Transmission. Traffic directed to Transmission's listening port from the normal LAN interface is blocked. The "transmission-daemon.conf" script then starts transmission-daemon with the required settings to bind it to the VPN IP address. Note that this command will also ensure UPnP/NAT-PMP is disabled - see my note at the top about port forwarding. The "nice -15" sets Transmission to have a lower priority, which I found useful when using the lower spec'd BeagleBone - sometimes Transmission can hog resources, which slows the system down. At least with a low priority, more important system tasks can still run. The "transmission-down.conf" script will remove the firewall rules when the VPN is stopped. Three different scripts are used so that transmission-daemon can be run as an unprivileged user, but the firewall rules can be run as root.

    Now let's go back to the OpenVPN settings, and edit the "route-up" and "down" scripts to trigger starting and stopping our Transmission script.

    sudo vim /opt/ibVPN/route-up.sh

    Paste this into vim:

    #! /bin/bash

/sbin/initctl emit transmission-vpn-up VPN_GATEWAY=$route_vpn_gateway LOCAL_IP=$ifconfig_local

    All this script does is say to Upstart that transmission-daemon should start, and gives it the information it needs to attach to the VPN connection.

    sudo vim /opt/ibVPN/down.sh

    Again, more pasting:

    #! /bin/bash

/sbin/initctl emit transmission-vpn-down

    This script is even more simple - it signals for transmission-daemon to stop.

    At this point, it is probably a good idea to make sure that the owner of the entire VPN config folder is the root user - since these scripts run as root, anyone who could change them could run anything they wanted to as the root user.

    sudo chown root:root -R /opt/ibVPN
sudo chmod 700 -R /opt/ibVPN
sudo chmod 400 /opt/ibVPN/pass

    This now means that only the root user can modify or view the VPN connection settings.

    OK, we're nearly done! Let's test if our setup is working so far:

    sudo openvpn --cd /opt/ibVPN --config config.ovpn

    Connect again to the Transmission web GUI, and resume the existing torrent or add a new one. It should be able to download, maybe after a few minutes of waiting for peers. A nifty way I found of testing whether or not it is working is to look at iftop. Install iftop, and run:

    sudo apt-get install iftop
sudo iftop -i tap1

    This screen will be showing all connections running through the VPN. If your torrent is downloading and is correctly using the VPN, there will be lots of IP addresses and host names here. Also look at iftop for the LAN connection:

    sudo iftop -i eth0

    Here you should see a large amount of traffic to a single IP address, being the VPN server, and then only minimal traffic to other LAN devices - assuming that you aren't running other services on your BeagleBone.

    You can confirm that the VPN is working by following these instructions.
    This site lets you download a torrent to see the IP address other peers use to connect to you - if everything is working this will be the VPN IP address and not your own WAN IP address.

    If you are experiencing issues, you can see the Upstart error log by doing:

    sudo tail -f /var/log/upstart/transmission-daemon.log

    In a separate terminal/SSH window, try running the tail command while starting the VPN connection as above and look for any error messages. Hopefully you can resolve the issue from seeing the error messages, if not have a dig around on the Internet, or post a comment.

    Configure it all to start automatically

    If you are happy with manually issuing the command to start the OpenVPN tunnel, or you want to do it with your own script, then you are done. But I wanted it to start on boot, so I made another Upstart script to launch OpenVPN.

    sudo vim /etc/init/openvpn-transmission.conf

    This is the last thing we have to paste!

    description "OpenVPN client, with attached transmission-daemon"

start on started networking
stop on runlevel [!2345] or stopped networking

# Give time for Transmission to send info to trackers, wait for graceful close
kill timeout 45

# Start the OpenVPN tunnel again if it stops for some reason
respawn
# If it stops 5 times in a minute, give up trying to respawn it
respawn limit 5 60


exec openvpn --cd /opt/ibVPN --config config.ovpn

post-stop script
    # Pause for a few seconds, before exiting
    /bin/sleep 3s
end script

    All this does is wait for the system to signal that the network is ready, and then it will start the OpenVPN tunnel - which will in turn start Transmission. When the system is turned off, or if networking is shut down for some reason, Upstart will remove the firewall rules and close transmission-daemon. Simple! This will continue to work after a reboot too, so now you're all set.

    To interact with Transmission, use the web GUI as we did during the setup phase. It is also possible to make the GUI accessible over the Internet, by setting up port forwarding. There are lots of tutorials on how to do this, so I won't repeat it here.

    As for getting the completed downloads off the BeagleBone, I'm using NFS. I can get speeds of about 8 MB/s copying over the LAN from the BeagleBone to my desktop computer - which is pretty good for such a low-powered device. Ubuntu provides some handy information for setting this up.

    • 24

  2. Just got this working using SystemD so I thought I'd share. I have placed all of my scripts, configs, and certificates in the same directory which I will refer to as /etc/openvpn/myprovider

    OpenVPN config

    This depends on your specific VPN, but one difference from @seanlano's config is that I only use a route-up script. So the things you need in addition to your working provided config, are these lines:

    route-noexec
route-up "/etc/openvpn/myprovider/transmission-route-up.sh"

    Where you place the transmission-route-up.sh script wherever you like. Note the absence of a down script. (My VPN was already using a custom down script so it would have conflicted anyway).

    /etc/openvpn/myprovider/transmission-route-up.sh:

    #!/bin/sh

# Print environment variables for transmission's benefit
printenv > /etc/openvpn/myprovider/vpn.env


# Set up VPN routes
ip route add default via $route_vpn_gateway dev $dev table 10

ip rule add from $ifconfig_local/32 table 10
ip rule add to $route_vpn_gateway/32 table 10

ip route flush cache


# Add firewall rules
iptables -A INPUT -i $dev -p udp --dport 24328 -j ACCEPT
iptables -A INPUT -i $dev -p tcp --dport 24328 -j ACCEPT

iptables -A OUTPUT -o $dev -p udp --sport 24328 -j ACCEPT
iptables -A OUTPUT -o $dev -p tcp --sport 24328 -j ACCEPT

    The first line, the printenv, is important. Place it wherever you like, it is used in the SystemD service later. I place it in the same directory as my vpn config.

    Replace 24328 with whatever port your transmission-daemon should listen on. I use iptables (using Debian), so you can probably replace those lines with the ufw lines from @seanlano's config.

    SystemD VPN service

    This is the service which auto starts the VPN for us. Verify that the path to openvpn is correct on your machine, and that the path to the config file is correct as well. You must specify full paths in SystemD services.

    /etc/systemd/system/my-vpn.service:

    [Unit]
Description=VPN connection
After=network.target

[Service]
Type=forking
PIDFile=/var/run/openvpn/vpn.pid
ExecStart=/usr/sbin/openvpn --cd /etc/openvpn/myprovider --config /etc/openvpn/myprovider/myconfig.ovpn --daemon --writepid /var/run/openvpn/vpn.pid

[Install]
WantedBy=multi-user.target

    Enable the VPN service with:

    systemctl enable my-vpn.service

    And test it with:

    systemctl start my-vpn.service
systemctl status my-vpn.service

    If it's started/running, you're good.

    SystemD transmission-daemon.service

    This script requires the vpn-service, so if the vpn goes down, transmission-daemon also goes down. This is handy if the vpn is restarted, and you get a new IP-address, because transmission will need to restart and re-bind then, which should be handled automatically. Note that we make use of the environment variables we printed in the route-up script earlier.

    /etc/systemd/system/transmission-daemon.service:

    [Unit]
Description=Transmission BitTorrent Daemon Under VPN
After=network.target my-vpn.service
Requires=my-vpn.service

[Service]
User=debian-transmission
Type=notify
EnvironmentFile=/etc/openvpn/vpn.env
ExecStart=/usr/bin/transmission-daemon -f --log-error --bind-address-ipv4 $ifconfig_local --rpc-bind-address 0.0.0.0 --no-portmap
ExecReload=/bin/kill -s HUP $MAINPID

[Install]
WantedBy=multi-user.target

    Enable it

    systemctl enable transmission-daemon.service

    And start it

    systemctl start transmission-daemon.service

    When you reboot, it should all start automatically (in order!). Note that using Type=simple in the vpn service causes some problems for the timing of script ordering, hence I recommend using forking instead.

    You can specify an actual ip-address for the rpc-bind-address if you want to be more restrictive (this is the web GUI listening address, which should not be your VPN-ip). And if you want to run transmission with nice, just change the ExecStart line and add /usr/bin/nice -n15 to the beginning.

    Handling address changes

    One thing I've noted over time is that if the vpn-connection for some reason gets a new ip-address, transmission will still be bound to the old address and stop working. And simply doing systemctl restart transmission-daemon.servicedoesn't cut it. It needs to stop fully, and then start fresh.

    No idea why, but for that reason I have added the following lines to my root crontab (sudo crontab -e):

    # m h  dom mon dow   command
0 6 * * * /bin/systemctl stop my-vpn.service; /bin/systemctl start my-vpn.service
1 6 * * * /bin/systemctl stop transmission-daemon.service; /bin/systemctl start transmission-daemon.service
    • 7

  3. I noticed you mentioned that Transmission does not goes through the VPN for UPnP/NAT-PMP. I noticed this as well and created a patch for Transmission so it honors the bind-address-ipv4 setting for UPnP. NAT-PMP is a bit harder to implement since you need to determine the default gateway. UPnP is the main one that is being used these days, though, so it is probably good enough. I logged this as a bug on the trac.transmissionbt site and provided the patch. Hopefully it will be incorporated in a future release. https://trac.transmissionbt.com/ticket/5990

    Another option for right now if you don't want to recompile is to manually run upnpc from the miniupnpc package. E.g.

    sudo apt-get install miniupnpc
upnpc -m 10.10.10.51 -a 10.10.10.51 51515 51515 TCP
upnpc -m 10.10.10.51 -a 10.10.10.51 51515 51515 UDP

    Where 10.10.10.51 is your VPN IP and 51515 is your requested TCP/UDP port.

    I'm not sure how long the forwarding is good for. Also you might want to use the '-d' option to remove your port when disconnecting. I found that if I don't, I can't get I same port again if I relogin into the VPN.

    Cheers

    • 3

  4. On top what its already written regarding SystemD service... it would make more sense to bound VPN service with Transmission serivce - so when You will restart VPN then Transmission should also be restarted... to achieve this You need to edit VPN serice file 

    vi /etc/systemd/system/my-vpn.service

    and add those lines:

    PartOf=transmission-daemon
ExecStartPost=/bin/sleep 30

    Into the [Service] section.

    PartOf will make one direction dependency - If VPN will be restarted then restart metioned those service as well. (documentation)

    In my case - VPN needed few seconds more to setup and immediate start of Transmission caused that Transmission daemon was using "old" env file - therefore I have added extra "wait" time 30s (ExecStartPost=/bin/sleep 30) after VPN has started just to make sure.

    Im in the testing phase right now - so this is not yet "home production server" yes - so I often yet put on sleep my PC. after that my VPN connection does not work. So I didnt yet make it but it would be nice to have some kind of watchdog functionality to test if VPN connection is still alive - but this is on my TO DO list yet...

    Additionally, to test if Your setup actually works then You may use this service torguard.net where You can "download" torrent file and open it in Your remote Transmission and verify what error / comment is returned from Tracker - it should return Your VPN/masked IP and on same page You can track current connections to check if this works at all.

    • 0
  5. Best Answer

    New approach in 2022: Network Namespaces

    In the years since I first attempted this, there's been some developments that make setting up Transmission to run over a VPN easier and more reliable – using a "Network Namespace". This doesn't just apply to Transmission, it could be for any systemd service. It no longer relies on the application correctly binding to the appropriate network interface, instead systemd will force all network traffic to use the configured namespace – which in our case will mean sending it though the VPN.

    1. Configure networking

    There's many ways that networking might be configured, in my case I was already using Netplan to create a bridge. It's probably not necessary to create one if you aren't also using it for other reasons (instead use the NAT option), but for reference here is my Netplan config which I'm using in this example. You'll need to adjust as appropriate, or configure the network interfaces with another tool of your choosing.

    Example Netplan config:

    network:
  version: 2
  renderer: networkd
  ethernets:
    enp1s0:
      dhcp4: no
      dhcp6: no
  bridges:
    br0:
      interfaces: [enp1s0]
      dhcp4: no
      dhcp6: yes
      dhcp6-overrides:
       use-dns: yes
       use-ntp: yes
       send-hostname: yes
       use-hostname: no
      addresses:
        - 192.168.64.200/24
        - "aaaa:bbbb:cccc::200:1/64"
      ipv6-privacy: yes
      gateway4: 192.168.64.1

    2. Install and configure systemd-named-netns scripts

    Although systemd supports network namespaces, it doesn't have much in the way of configuration for them. Fortunately, a helpful fella called James Swineson has made a set of scripts which create systemd services for various network namespace configurations.

    Download the repository:

    git clone https://github.com/Jamesits/systemd-named-netns.git

    Install the scripts:

    cd systemd-named-netns/
sudo make install

    3. Configure systemd-named-netns

    The exact configuration you need will depend on your network setup. I'm using a bridge, but a NAT option is also available. See the wiki page for more information.

    The rest of this guide assumes that you're using a bridge. I'm using the name torrentvpn for the namespace, it will come up in a few places. If you decide to use a different name, make sure it only contains alphanumeric characters and is not longer than 12 characters.

    Create a resolv.conf file for the DNS settings to use inside the network namespace:

    sudo mkdir -p /etc/netns/torrentvpn/
sudo touch /etc/netns/torrentvpn/resolv.conf

    Then edit the file /etc/netns/torrentvpn/resolv.conf to this:

    nameserver 8.8.8.8

    This will use Google's DNS service for anything that runs inside the network namespace, feel free to use another if you prefer – NextDNS is a good alternative.

    Now let's configure the namespace bridge, edit the file /etc/default/netns-torrentvpn to this:

    # Bridge name
BRIDGE=br0

# If you need DHCP
DHCPV4=1

# Set a static MAC, helpful with DHCP
MACADDR=02:00:00:aa:bb:01

# Device name outside netns
DEVNAME_OUTSIDE=veth0
# Device name inside netns
DEVNAME_INSIDE=veth1

    At this point we can test our network namespace setup, start the namespace with this command:

    sudo systemctl start [email protected]
sudo systemctl enable [email protected]

    Then try to ping something from inside the namespace, and make sure it works:

    sudo chnetns torrentvpn ping google.com

    4. Set up OpenVPN

    There's a crazy number of VPN service providers out there, so the steps might be slightly different for you. Ideally you should confirm you can get an OpenVPN tunnel set up using the config files from your provider, possibly using a graphical interface first if that's easier. In theory it doesn't even have to be OpenVPN, it can be any VPN that you can get running through systemd.

    I have an account with ProtonVPN, who provide OpenVPN configuration files which have the necessary certificates and keys embedded inline. The config file is saved at /etc/openvpn/client/protonvpn.conf and I've modified it to have the username and password read from the file at /etc/openvpn/client/protonvpn.pass (with the auth-user-pass config option). You'll need to adapt this to suit your provider.

    The OpenVPN package provides systemd scripts for managing a client connection, although we want to add an extra couple of lines so that our connection uses the network namespace. Run this command:

    sudo systemctl edit [email protected]

    and add the following lines:

    [Unit]
[email protected] [email protected]
[email protected] [email protected]
[email protected]

[Service]
PrivateNetwork=yes
ExecStartPre=/sbin/sysctl net.ipv6.conf.all.disable_ipv6=1

    This creates a "drop-in" override file at /etc/systemd/system/[email protected]/override.conf, which lets us add our extra settings without needing to edit the config from the package maintainer. It also disables IPv6 inside the namespace, since my VPN provider doesn't support it and I don't want to accidentally end up using my non-VPN Internet connection.

    Restart the systemctl daemon, then try to start the VPN:

    sudo systemctl daemon-reload
sudo systemctl start [email protected]
sudo systemctl enable [email protected]

    Test again with a ping through the namespace, this time the response time should be slower than before because of the extra distance the packets now have to travel to reach the VPN endpoint:

    sudo chnetns torrentvpn ping google.com

    5. Set up Transmission Daemon

    There's lots of information about configuring Transmission, and you might have different desires, so read the documentation. I'll quickly show the main steps here.

    Install Transmission:

    sudo apt install transmission-daemon

    Stop the daemon (systemd seems to start it after being installed)

    sudo systemctl stop transmission-daemon.service

    Edit the configuration file at /var/lib/transmission-daemon/.config/transmission-daemon/settings.json. In particular, you'll probably want to change download-dir to somewhere with sufficient storage, and also allow access from your LAN in rpc-whitelist (for me this meant adding 192.168.64.*). You will also need to set a password through rpc-password to log into the web UI.

    Don't forget to set the correct permissions for your downloads directory:

    sudo chown debian-transmission:debian-transmission /home/torrents/

    6. Set Transmission to use the VPN

    Similarly to how we edited the systemd config for OpenVPN with an override, we will do the same with Transmission:

    sudo systemctl edit transmission-daemon.service

    Add the following lines, and save:

    [Unit]
[email protected] [email protected]
[email protected] [email protected] [email protected]
[email protected]
[email protected]

[Service]
PrivateNetwork=yes

    Reload systemd, then start the service:

    sudo systemctl daemon-reload
sudo systemctl start transmission-daemon.service
sudo systemctl reenable transmission-daemon.service

    Because of the namespace, Transmission's web UI won't be accessible from the IP of the host machine, but rather from the IP of the virtual device inside the namespace which is attached to the bridge we set up. To find that IP address, run:

    sudo chnetns torrentvpn ip ad

    and find the address of the veth device – for me it was 192.168.64.46. The Transmission UI is then accessible at http://192.168.64.46:9091 , using the username and password you set in the configuration file.

    7. Testing it out

    Everything should all be up and running now. The best way I've found to confirm that the torrents really do use the VPN to download is to use the handy checker that Torguard provide (thanks to @lemonek for introducing me to this!) – it gives you a special torrent to download, and shows which IP addresses attempted to share it. Compare the IP that shows up with your Internet IP, and make sure it is not the same. You can also check the IP seen by servers for anything using the VPN by running:

    sudo chnetns torrentvpn curl http://ip.42.pl/raw

    This will show the IP address seen by the server at ip.42.pl, which should be the same IP shown by the Torguard tool.

    Weird behaviour in Ubuntu 18.04

    Frustratingly, I found that on reboot the network namespace setup seemed to play up slightly on Ubuntu 18.04 (but not on 20.04), leaving me unable to test out shell commands inside the namespace with the chnetns command. Strangely though the namespace worked fine for services within systemd jobs, Transmission was still running just fine.

    I tried a bunch of things but couldn't figure it out, but I did at least realise that by stopping and restarting everything it could all be made to work:

    sudo systemctl stop [email protected]
sudo systemctl start transmission-daemon.service
    • 0

相关问题