[Support] binhex - Nicotine+

[binhex]

11 minutes ago, rikdegraaff said:

I forwarded it through my binhex-qBittorrentVPN container, and when opening local url 192.168.x.x:5900/6080, or cloudflare url it gives me now the following error: The connection has timed out.

In the log now the warning:

 

2024-06-12 15:26:48,276 DEBG 'start' stdout output:
[12/06/24 15:26:48] You need to specify a username and password before connecting…

2024-06-12 15:33:58,760 DEBG 'start' stderr output:

Wed Jun 12 15:33:58 2024
 Connections: accepted: 172.17.0.1::46436

2024-06-12 15:33:58,788 DEBG 'start' stderr output:
 VNCSConnST:  closing 172.17.0.1::46436: reading version failed: not an RFB
              client?
 EncodeManager: Framebuffer updates: 0
 EncodeManager:   Total: 0 rects, 0 pixels
 EncodeManager:          0 B (1:-nan ratio)
 Connections: closed: 172.17.0.1::46436
 ComparingUpdateTracker: 0 pixels in / 0 pixels out
 ComparingUpdateTracker: (1:-nan ratio)

2024-06-12 15:33:59,281 DEBG 'start' stderr output:

Wed Jun 12 15:33:59 2024
 Connections: accepted: 172.17.0.1::46442

2024-06-12 15:33:59,317 DEBG 'start' stderr output:
 VNCSConnST:  closing 172.17.0.1::46442: reading version failed: not an RFB
              client?
 EncodeManager: Framebuffer updates: 0
 EncodeManager:   Total: 0 rects, 0 pixels
 EncodeManager:          0 B (1:-nan ratio)
 Connections:
2024-06-12 15:33:59,317 DEBG 'start' stderr output:
 closed: 172.17.0.1::46442
 ComparingUpdateTracker: 0 pixels in / 0 pixels out
 ComparingUpdateTracker: (1:-nan ratio)

 

Check you have followed all steps to network share, Please see Q24 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md also for now i would advise ignore cloudflare, get it working locally.

[rikdegraaff]

53 minutes ago, binhex said:

Check you have followed all steps to network share, Please see Q24 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md also for now i would advise ignore cloudflare, get it working locally.

The folders and ports exist only on the VPN container.

I followed all the steps in your link Q24.
But that didn't help at all.

 

Here an overview of those dockers.

 

 

EDIT: I have removed the cloudflare options, so it is only accessible from inside the home network.

And I've edited LAN_NETWORK to the right ip address, now it gives me "RFB 003.008" in plain text.

Edited June 12 by rikdegraaff
See EDIT

[rikdegraaff]

It is working now.
Updated the CNAME record on Cloudflare and its working now locally and on the WWW.

 

Thanks for all the effort and support, @binhex!!!

[JonathanM]

10 hours ago, binhex said:

In a word, no, instead network sharing is where I'm trying to go with any future docker images, maintaining VPN enabled docker images is hard work so i would prefer to keep the workload as light as possible and leverage existing VPN connectivity instead, as mentioned above I am working on a solution to read in the incoming port from a VPN enabled docker container, the tricky part is reconfiguring Nicotine+ when the port changes.

So in the eventual future, do you see independent VPN and application containers as the norm? Not to get too far ahead of you, but I'd love to see the possibility of multiple VPN endpoint containers, each able to support multiple of your application containers.

 

For example, VPN1 with a PIA port forwarded connection, torrent and other file sharing containers pointed there, VPN2, a PIA or whatever, with various downloader apps assigned there.

 

Some downloader apps get upset with out of area connections, it would be nice to easily set up 2 tunnels, one foreign, one local.

[binhex]

12 hours ago, JonathanM said:

So in the eventual future, do you see independent VPN and application containers as the norm? Not to get too far ahead of you, but I'd love to see the possibility of multiple VPN endpoint containers, each able to support multiple of your application containers.

So if i had my time again i would produce one image similar if not the same to privoxyvpn, then document the crap out of it on how to connect any other container to it, it would mean smaller image sizes in that way (no need to bake in vpn clients to multiple images) and less complexity for me (single vpn image to deal with), but we are where we are, if I deprecated the use of delugevpn, sabnzbdvpn and qbittorrentvpn i think i would have a riot on my hands :-), so i will maintain them for the foreseeable. 

12 hours ago, JonathanM said:

For example, VPN1 with a PIA port forwarded connection, torrent and other file sharing containers pointed there, VPN2, a PIA or whatever, with various downloader apps assigned there.

 

Some downloader apps get upset with out of area connections, it would be nice to easily set up 2 tunnels, one foreign, one local.

Yeah i don't know if what you are suggesting is running multiple tunnels in a single container, or the idea of having multiple containers each connecting to a different vpn endpoint, the latter is a lot easier to code than the former, in my 'if i had my time again' model i would suggest multiple privoxyvpn (or whatever name) containers, each going to a different locations, that would be the most logical approach in my opinion, and of course would not consume much additional space, only config differences.

[JonathanM]

2 hours ago, binhex said:

multiple containers each connecting to a different vpn endpoint

This.

 

2 hours ago, binhex said:

if I deprecated the use of delugevpn, sabnzbdvpn and qbittorrentvpn i think i would have a riot on my hands :-), so i will maintain them for the foreseeable. 

Agree.

 

Maybe your current effort to allow multiple containers access to the forwarded port will be usable with other containers besides this one?

 

Unfortunately I'm not enough of a network guru to know if this is feasible, but how about redirecting the changeable vpn port forward to a static port inside your container network?

[binhex]

21 hours ago, JonathanM said:

Maybe your current effort to allow multiple containers access to the forwarded port will be usable with other containers besides this one?

Absolutely!, it should be applicable to any other container.

 

21 hours ago, JonathanM said:

Unfortunately I'm not enough of a network guru to know if this is feasible, but how about redirecting the changeable vpn port forward to a static port inside your container network?

that sounds like an interesting idea but i don't know if that is possible, in the meantime i am going for a more low level option and that is simply to share the assigned vpn port via a docker volume (not bind mount) as i store the assigned vpn port in a file. As mentioned the really tricky part is to reconfigure the application to use the port and also monitor it for changes, if it changes then reconfigure, and for Nicotine+ this looks like i have two options:-

 

1. disconnect and reconnect to re-read port change from config file

2. restart nicotine+ to force re-read of config file

 

As you can see neither option are ideal.

[JonathanM]

3 hours ago, binhex said:

1. disconnect and reconnect to re-read port change from config file

This looks like the correct option to me, mainly because if the port changes, it's likely that the network is "down" anyway until the application reconnects.

 

While you are playing with all this, I have a current scenario that you may be able to take into consideration. I run a couple downloaders through delugevpn, but when the vpn container restarts or is updated, the downloaders are unable to connect out until I restart them afterwards. I'm unsure whether that's a consequence of how docker networking works, or simply the change in IP not being detected properly.

 

I know restarting and / or updating the master container is much different than it simply detecting a port change, but it's a scenario that would help automation if it were covered.

 

3 hours ago, binhex said:

it should be applicable to any other container.

With that in mind, do you have a method you are looking at to blindly reconnect when needed? Maybe the master vpn container could have variables defined with dependent container names to blindly restart when the connection changes? Can a container manipulate another container like that? Or would there need to be a "helper" script running on the host to monitor and restart things?

 

 

[binhex]

1 hour ago, JonathanM said:

While you are playing with all this, I have a current scenario that you may be able to take into consideration. I run a couple downloaders through delugevpn, but when the vpn container restarts or is updated, the downloaders are unable to connect out until I restart them afterwards. I'm unsure whether that's a consequence of how docker networking works, or simply the change in IP not being detected properly.

this is a known issue, and @ich777 came up with a clever idea of using a socket instead, this then permits the vpn contaner to be restarted and for the container sharing the vpn network to reconnect without issue, its on my to-do list to look at.

 

5 hours ago, binhex said:

if it changes then reconfigure, and for Nicotine+ this looks like i have two options:-

 

1. disconnect and reconnect to re-read port change from config file

2. restart nicotine+ to force re-read of config file

ive come up with a neat solution for this by setting up a statically assigned port forward inside of the container, this then forwards to the dynamic port, the beauty of this is that i dont then need to reconfigure the application as the application is configured to use the static port, if the port changes the port forward is altered without the need for the application to be reconfigured, cool hu!, tested it out earlier and it works!, so with that cracked it is now possible to configure ANY application to use the incoming port, even when the port is dynamically assigned (such as pia and protonvpn).

[JonathanM]

6 minutes ago, binhex said:

it is now possible to configure ANY application to use the incoming port, even when the port is dynamically assigned

That will work for some applications, but based on a brief search I don't think that will work with torrents. From what I read torrent clients embed the port they see in the traffic for returns, so if that port is remapped it won't connect.

 

Hopefully there is some way around that.

[binhex]

1 hour ago, JonathanM said:

That will work for some applications, but based on a brief search I don't think that will work with torrents. From what I read torrent clients embed the port they see in the traffic for returns, so if that port is remapped it won't connect.

 

Hopefully there is some way around that.

How would this be different to doing a traditional port forward on your router, that works right? got any links to articles that state it won't work?.

[binhex]

Hmm so in my very unscientific experiment i switched from incoming port to port forwarded port and yes i did see a decrease in connected seeds and peers, so i think you are correct, but that doesn't stop the use of this for non torrent clients, so i think its still a worthy addition, thanks for bringing that to my attention.

[ich777]

2 hours ago, binhex said:

this is a known issue, and @ich777 came up with a clever idea of using a socket instead, this then permits the vpn contaner to be restarted and for the container sharing the vpn network to reconnect without issue, its on my to-do list to look at.

It seems to work pretty well from what I heard from another user and I just posted a tutorial on how to add a script for Linuxserver based containers to make them also restart (maybe something like this is possible in your containers too?) :

 

On my system it works flawlessly with my OpenVPN-Client container (tested with PIA and hide.me) in combination with Radarr, Sonarr, Lidarr, jDownloader2, SABnzbd,... and even with TVHeadend from Linuxserver with the script.

 

Sorry for hijacking this thread...

 

My method has some edge cases but it works pretty well how it's currently set up.

I hope you can look into this sometime... would be awesome if your containers also support this "feature"...