The container connects to the VPN and only the VPN, now you can route whatever docker containers you want through that container as a network. Now that one VPN connection can serve any container you want.
I use gluetun to route traffic from some of my containers that need a VPN. qBittorrent, Jackett etc. Some containers dont have the option to configure a proxy so you’d have to setup a VPN client within a container which isn’t ideal. With gluetun its easy to attach a container to it and it just works
Why isn’t it ideal? I’m currently using this setup with containers routed through a gluetun container connected to a vpn via wireguard, and it seems to be working fine. I’ve verified using curl inside the relevant containers to query an IP checker and I’ve also used a torrent IP checker to confirm my torrent client isn’t leaking my IP.
Also the biggest benefit; You only need 1 VPN connection and 1 key pair for gluetun to connect everything. Most VPN providers limit the amount of active simultaneous connections. If you have lots of containers that need it then it’s not possible
My recommendation would be to give up on the port forwarding.
If maintaining a ratio is important to you then just rent a seedbox once in a while. 1 month with a seedbox gives me enough upload credit to last me several years.
Thereafter I just download torrents, I may be unconnectable but no big deal.
Does it not impact downloading? I thought the lack of port forwarding on my VPN was what was causing me to not connect to seeders even though qBittorrent shows them
My (possibly mistaken) understanding is that during the download phase your client is contacting seeds requesting parts. Although the data is going to be incoming it’s still an outbound connection because your client initiated it, so you don’t need to be connectable for that.
It’s the seeding phase which is problematic because downloaders can’t contact you to request parts. That said your client will still contact downloaders and offer parts, which again is an outbound connection so you don’t need to be contactable.
In summary download speeds are uneffected, but seeding rates will be diminished. With most private trackers you can still satisfy seeding requirements just by keeping the torrent available for however long.
As an aside I use mullvad & wireguard. I’ve found wireguard dramatically easier to configure, particularly in a docker environment.
I’m not on any private trackers. I’d be interested, but not until I have a more dedicated setup; I’m still very much a casual torrenter.
It’s good news then if port forwarding won’t affect my downloads, because that was the only reason I wanted it, but I saw others online say that lacking that feature is what was causing me not to connect to peers shown in my torrent client. Any idea what’s up with that?
Not really. Either my explanation is wrong or theirs is. Honestly could be either.
There’s so much misunderstanding and misinformation around torrenting.
All I know is that I’ve never had any problems downloading without being connectable. Never ever. It’s just not an issue.
Additionally, the vast majority of people torrenting in 2023 are using a vpn and none (very few) of them will forward ports so it can’t be a big deal.
Thirdly, there’s a lot of piracy purists / elitists who just can’t abide the idea that your set up may not have the best possible configuration for seeding. IMO, seeding on a residential connection is just a waste of time - download on a residential connection, seed on a VPS / seedbox.
There are two low level tricks that make a huge difference for seeding, even if you can’t open ports. These are generic Linux tweaks, you may have to adapt them for QNAP depending on how customized it is. Ask me if you need help. As far as I can tell you need to ssh to the “admin” acount, so open a command line and type ssh admin@your-nas.
To make both tweaks permanent you need to edit /etc/sysctl.conf. you can try editing them with nano. If you don’t have nano you’ll have to try with vi, but vi is not intuitive at all to use.
The first tweak makes you a lot more effective to peers that are on unstable connections and on wi-fi. Google uses it for most of their infrastructure, originally on YouTube. You can read their article for more info on how it works.
Add this line to /etc/sysctl.conf, close nano with ctrl-X, and reboot:
The second tweak decides how fast you can upload to people far away from you. If you calculate 2 * this value / your latency to them, you get the max speed you can upload to them. For simplicity I set it to be the same as my upload speed: let’s say you have 10 MB/s upload, that’s 10000000 bytes / second:
Add this line to /etc/sysctl.conf, close nano with ctrl-X, and reboot:
This way even someone in Australia with 500 ms of latency can download at 10 MB/s from you, (2 * 10000000 bytes / 0.500s = 10 MB/s)
After rebooting you can check if the setting stuck with the command sysctl net.ipv4.tcp_congestion_control and sysctl net.core.wmem_max respectively.
For any of this to make a difference you should disable µTP in your torrent client, or make it prefer TCP over µTP.
To me it makes an enormous difference, from barely any upload at all to 100 GB per day. And I’m sure it’s nice for whoever is downloading on the other side to get what they’re looking for super fast.
For any of this to make a difference you should disable µTP in your torrent client, or make it prefer TCP over µTP.
Just as a caveat, people disabling/throttling µTP may want to manually set appropriate global rate limits (upload/download bandwidth) otherwise it’s possible the torrent client will actually hit the maximum upload/download limits of the ISP or router forcing everything else on the network to slow down/time out during other internet usage. You’re obviously more advanced so you already know all this :)
Mainly it’s extra info for noobs messing around with their settings, often times noobs mess around with settings, disable things, etc. & then wonder why their torrent client keeps “crashing” their internet :P Making changes to µTP should be more of a last resort IMO.
µTP itself is a pretty big topic, there are a fair amount of people testing different settings in the qBittorrent / Libtorrent Github Issues but I’m not sure there’s even a consensus on a proper default setting. e.g. qBittorrent’s devs specifically chose different µTP defaults vs the Libtorrent library’s own defaults. qBittorrent defaults to having µTP enabled with preferring TCP (throttles µTP), Libtorrent defaults to having µTP enabled with peer_proportional (does not throttle µTP). The qBittorrent default is reasonable though I wonder if the Libtorrent default is the more “correct” approach but that’s certainly up to much debate. In both cases µTP is never disabled completely.
With my own testing I tend to keep settings at Libtorrent defaults just to observe behavior, with mainly private tracker peers I’ve noticed at least ~60% of my incoming connections are from µTP peers so at least for me it seems reasonable to keep it enabled.
The big problem with disabling µTP is that because it uses UDP, under some kinds of NAT you can get incoming connections despite being NATted. So you will loose some peers if you’re behind a NAT. If you’re not NATted there’s no connectability advantage, because every client that implements µTP can fall back to TCP.
The big advantage to disabling it that you can tweak these things. I don’t know of any client that lets you choose which congestion control algorithm that µTP uses. They all use one called LEDBAT that’s one of the first attempts to design one that avoids “bufferbloat”, i.e. that problem where the torrents fill up the buffers in routers and “clog up the Internet”. That’s nice however it doesn’t work well with networks with a lot of jitter like wi-fi, and it “loses” to algorithms that do fill up the buffer like the default TCP CUBIC. BBR avoids bufferbloat and is designed to keep working well with high jitter—Google’s intention was to make YouTube load faster on mobile phones. It also it wins over CUBIC, which is why almost every seedbox comes configured with no µTP and BBR congestion control. However, because it wins over CUBIC it will “clog up the Internet” in a different way: you may get lower speeds on everything else but don’t lose interactivity.
Linux comes with a different version of BBR that’s tuned to always yield to other traffic called lp. You enable it with net.ipv4.tcp_congestion_control = lp. I think lp is the optimal choice for seeding public torrents: you give full speed to faraway peers, but only when there’s nobody else that can do it.
What is your toreenting “signal chain”, so to say? Normally when you download things through qBittorrent, are you generally running bare? Do you use a VPN? Is your torrent client configured to use a specific NIC? If so, is that NIC active and passing traffic? There are so many variables that play into this.
No VPN because I live on the wild side and I use pretty stock settings. I resolved my issue but should I look into my NIC settings? Thank you for your help.
The NIC thing was more for if you were using a VPN. You can lock down your client to just use the virtual NIC your VPN client creates, so that’s always recommended when setting up your client.
Can someone explain to me what port forwarding in the context of torrenting is about? I use qbittorrent and nordvpn in docker containers and have never exposed/forwarded a port but get more than adequate upload/download speeds.
Port forwarding allows you to bypass your NAT firewall which will naturally block all unsolicited traffic on a closed port. What that means for a torrent download is peers cannot introduce themselves to you and create a new connection, you can only connect to active peers who have their ports open.
Just to add more background to that, before your torrent can begin downloading pieces from various peers, you need to know the address of the peers sharing the pieces you need. Typically that is handled by the tracker and/or DHT. A tracker acts as sort of a logistics middle-man. It helps facilitate efficient transmission between peers by tracking what each peer has and needs. If peer B needs piece X, the tracker will supply peer B with the address to peer A who has piece X. Assuming peer A has their incoming port open, they will accept the request for piece X and send it to peer B. If their port is closed, the request will simply be denied and no traffic will be shared between the peers. The tracker’s address, as well as the data hash and some other misc data is coded into the torrent file. DHT is a little more unique and complicated. It is a fully distributed hash table on a P2P network and does not rely on a tracker at all, it’s strictly P2P. The only little catch to that is to initially introduce yourself into the network you need to bootstrap your connection using some hardcoded addresses, often from a very centralized source. Port forwarding becomes much more important for DHT because after the initial bootstrap, there is no middle-man, it’s strictly peer to peer and by having your ports closed, your client can’t effectively communicate across the network. Without two-way communication across peers, your client will generally be stuck with a very limited pool of peers it can communicate with. Magnet links as well as most torrent clients utilize DHT.
One reason it’s not so noticeable these days when ports are closed is because many torrent peers exist in big data centers with virtually unlimited bandwidth. When torrents were still young, most if not all peers were hosted on consumer grade hardware at a residence so you needed every connection you could get.
If your torrent download happens to be a well-known Linux ISO, chances are very likely that there will be at least two or three peers you’ll connect to that exist in a data center, they will most likely account for 80%+ of your download speed.
Blocking ports ultimately hurts seeding the most which can effect the overall “health” of a torrent. Say a peer labeled A can’t connect to those giant data center peers for whatever reason, they now have to seek out other peers that may have the data they are looking for. If all the other peers have their ports closed, well then the torrent is essentially dead for peer A and they’ll have to either wait for someone with open ports to come online and start seeding or search for an entirely new torrent.
Sorry, this was a bit of an on-the-go mind dump so please anyone correct me if I’m wrong anywhere here but that’s pretty much the gist of port forwarding in the context of torrenting.
When torrenting your client should be “Connectable” which means fully accessible from others. You can use the guides others have posted to achieve that but basically, an unconnectable client can still seed to those who are connectable, but two unconnectable clients cant connect to each other. Or at least this is how it has been described to me by a private tracker.
I wouldn’t trust anything from a P2P site that purports to be:
A cracked game / application for desktop and mobile platforms. Maybe it’s legit but assume it is malware.
A serial number generator. If you absolutely must run one of these do it from a throwaway VM, or via WINE emulation to mitigate what it might do.
An encrypted archive with a README. It’s a scam designed to make people sign up to other scams to release a non-existent password.
A movie / audio with an extension such as .scr, .wma, .com, .exe etc. It’s malware.
Movies, audio & books are generally safe providing they use a recognized extension - mp3, mp4, pdf, mkv, aac, flac, epub etc. Stuff that runs under emulation like console games is generally safe. I say “generally” because an exploit could still be crafted to escape a popular media player or emulator and cause actual harm to your computer.
All the ads and 3rd party scripts should be considered malicious too and should be erased with an adblocker, or even better use Tor.
So basically use some common sense and if you really want some game or app, just buy the damned thing or wait for it to go on sale.
Read their own FAQ. It’s not an emulator in the classic sense of emulating the OS. It is however emulating the API of Windows. I quoted the pertinent line of the FAQ elsewhere and made my point clearer
There is a storied history in computing to use tongue in cheek self referential acronyms to denote some humor and finality in distinguishing things that purposely fill a niche in the world of competing, often pricey, commercial software and other hackable reasons.
So I bet you’re rubbing wrong those of us who remember that gnu is not unix, and more specifically wine is not an emulator. Because they really aren’t.
What software/OS are you running on your NAS? If you’re running some goofy software on a private tracker your client might not be whitelisted.
Besides that - this NAS is attached to your home network I assume? Is it behind a router? Are the ports you’re using for torrenting port-forwarded?
What tracker are you testing this on? A bunch of trackers will have a “Connectivity check” that will tell you whether or not your client is connectable
I be sailin’ the digital seas with a trusty QNAP OS and the mighty QBittorrent, but I be a greenhorn in this life on the high seas. Me heart’s desire be to contribute to our pirate brotherhood by becoming a proper seederman.
Be ye privy to a treasure map, a definitive guide, that can steer me in the right direction to turn me NAS into a fearsome seedin’ contraption fit for the high seas?
But yeah, I also have a QNAP NAS that I just finished getting set up! And it is indeed seeding out, I’m almost at 0.49 for my all-time share ratio after downloading some stuff over the last few days. It’s taking longer to get my share ratio up than I expected, but idk, I’m new here.
Anyway, from reading a couple of strongly-worded posts on Reddit it seems that you need to have port forwarding enabled on your VPN to really seed effectively. Did you look at that when picking your VPN?
Basically I’m using AirVPN with binhex’s arch-qbittorrentvpn docker container to get it all set up. Binhex has lots of helpful pages on their GitHub for getting things working properly.
I don’t know if there’s a “definitive guide” - it’s not that complicated to get a torrent client up and running. What kind of content are you looking for? Movies, Series, Music, Games, Books…?
Best is probably to try to get access to a decent private tracker, and an “easy” one - one with a bonus point system for seeding and uptime - that makes it much easier to keep a good ratio with a NAS, if you’re just permanently seeding everything you download, you’ll get points and “rise the ranks” of that tracker.
Once you’re a high enough rank on that tracker, you’ll get access to their “Invite Forums” where other private trackers advertise and give out invites to their trackers
Was to lazy to change instances even though .world was always down. Actively censoring made me finally pull the plug. Thanks for helping me out I guess
piracy
Aktywne
Magazyn ze zdalnego serwera może być niekompletny. Zobacz więcej na oryginalnej instancji.