this post was submitted on 07 Dec 2023
57 points (98.3% liked)

Piracy: ꜱᴀɪʟ ᴛʜᴇ ʜɪɢʜ ꜱᴇᴀꜱ

54716 readers
219 users here now

⚓ Dedicated to the discussion of digital piracy, including ethical problems and legal advancements.

Rules • Full Version

1. Posts must be related to the discussion of digital piracy

2. Don't request invites, trade, sell, or self-promote

3. Don't request or link to specific pirated titles, including DMs

4. Don't submit low-quality posts, be entitled, or harass others

Loot, Pillage, & Plunder

📜 c/Piracy Wiki (Community Edition):

💰 Please help cover server costs.

Ko-Fi Liberapay
Ko-fi Liberapay

founded 1 year ago
MODERATORS
db0@lemmy.dbzer0.com
sunbrothersco@lemmy.dbzer0.com
dataprolet@lemmy.dbzer0.com
Flatworm7591@lemmy.dbzer0.com
RandomLegend@lemmy.dbzer0.com
57
How to make sure transmission is using my vpn? (programming.dev)
submitted 11 months ago by Rizoid@programming.dev to c/piracy@lemmy.dbzer0.com
25 comments fedilink hide all child comments
 

I have transmission running on my server in a docker container that is supposed to go through gluetun. If I run test with ipleak and other torrent ip testers it shows my vpn's ip address. However transmission is running way faster download speeds than deluge or qbit were with the same configuration. It makes me wonder if all the traffic isn't going through the vpn somehow and I can't think of any other way to check things other than ipleak tests. I'm probably being over paranoid but a few months ago qbit leaked and I got a letter from my isp. I really don't need that happening again. Any help would be appreciated.

you are viewing a single comment's thread
view the rest of the comments
[–] ben@lef.li 8 points 11 months ago* (last edited 11 months ago)

Use a firewall to block all outgoing packages through all interfaces but lo and tun (or wg for Wireguard). Like this for iptables:

-A FORWARD -j REJECT --reject-with icmp-port-unreachable
-A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -d 1.2.3.4/32 -p udp -j ACCEPT #replace with public IP of your VPN you try to connect
-A OUTPUT -p icmp -j ACCEPT
-A OUTPUT -o tun+ -j ACCEPT #replace with wg+ for Wireguard
-A OUTPUT -j REJECT --reject-with icmp-port-unreachable

If you are paranoid you could mess with INPUT table as well but if OUTPUT is configured properly nobody well ever know your real IP address.

Not sure how well this works with Docker and such, I use LXC containers.

The funny thing is that I am actually seeding Linux ISOs (yes, real ones). The reason I am using a VPN to seed those is because the ISP is complaining about random peers hitting (non-existing obviously) addresses in private IPv4 ranges (like 172.16.1.1) and instead if simply dropping those packages at the switch ... oh well. I guess some people have multiple peers connected to each other via private networks but external peers don't know about these connections and simply try to reach them on their private addresses over public internet.

Anyway yeah I could mess with routing table on my server and null-route those ranges but I have an active VPN contract already so why not using it?