feat(extras/scripts): update qBittorrent peer port with optional authentication

[astappiev]

Inspired by #2611 and talks in #1555 created a script to update peer-port of qBittorrent.

Upd: added option to authenticate.

[AndaPlays]

I'm currently working on something similar, but I guess this would be a better solution. 👍

[astappiev]

The only downside of these scripts is that they don't cover a scenario when a client is started after gluetun.

[AndaPlays]

@astappiev Looks good to me. The only thing I would appreciate is if we could add an option for Nmap to check whether the port is actually open. I'm on a couple of private trackers, and if my TCP port is filtered, I could get heat—or in the worst case—have my account banned.

I tried integrating it into my script and controlling the VPN via the control server, but Gluetun doesn't have an API for WireGuard yet.

[astappiev]

I think it should be implemented as another script (as it is not client dependent), or even in the gluetun core.

[qdm12]

Why is this needed?

[astappiev]

It might require some time until qbittorrent is up and listening when I start my compose stack

[qdm12]

Can you add a comment for this? 😉

[qdm12]

See qdm12/gluetun-wiki@55ffd92

We should have a "down" mode to change the port to something else.
Or, maybe better, have it set it to some random port i.e. 9876, and then to the actual port we want, such that there is only an up command to set.

[astappiev]

I'm not sure what's best here; the provider I'm using is always giving a unique port.
For now, I set it to 0 as a "safe" port to reset the setting. If we use any "random" port, there is a minor chance that it might match with an actual port.

[qdm12]

setting it to 0 is a good idea, although that's not done here. Maybe we could do it right before calling the API to set to the desired port?

[qdm12]

this should accept a comma separated list of ports from Gluetun's {{PORTS}} to simplify usage of this script.
And then it should use $(echo {{PORTS}} | cut -d, -f1) to take only the first port just in case, since qbitorrent supports only one port.

[astappiev]

Not sure if I got it right, does it mean we should use it like this bittorrent-port-update.sh --port {{PORTS}}?

E.g. via VPN_PORT_FORWARDING_UP_COMMAND=/bin/sh -c "/scripts/qbittorrent-port-update.sh --port {{PORTS}} --webui-port 9081"

If so, it's already supported, this is exactly how I used it since beggining.

[qdm12]

Correct, but {{PORTS}} can have multiple ports so for convenience and a shorter command, let's cut and use the first port within the script. The flag should be renamed to --ports and indicate that despite the name it only picks the first port

[astappiev]

I think the other way around, let's keep it named as --port to indicate that only one of them is used.

The logic to split and keep the first was already there
https://github.com/astappiev/gluetun/blob/839e318c9c30676c8ecd9f042c524e87a1634f32/extras/scripts/qbittorrent-port-update.sh#L60

[qdm12]

Actually....
Added support for {{PORT}} variable in fcdba0a which takes the first of the ports. No reason to have it supported in scripts!

[qdm12]

@AndaPlays for this nmap command to succeed, I suppose you do need a program listening on the forwarded port right? What I'm thinking is to, when setting up port forwarding:

1. start an ephemeral tcp server on the forwarded port / if the port is used already then don't that's fine too (udp is more complicated and not widely used by users so we'll skip that)
2. check public-ip:port with a tcp dial (same as the nmap command)
3. Report to debug logs it is open and finish the port forwarding setup process (I'm a maniac of logging problems only and avoid logging if things work correctly)

I'm going to mark our comments as off topic, would you please open an issue for this? Thanks!!

[monstermuffin]

Hey guys, I know it's not a native solution but this use case is exactly why I made qSticky. Been working very well and it doesn't matter what order things come up as it's a middleman between the two applications.