docker version limited to LAN ?

[vigilian]

Hi,

 

2.5.13

It seems that the docker version is limited to LAN when not used with --net host argument? is that correct? 

I guess that's not a docker limitation since i can run a webserver from docker without using this argument and it's not a firewall problem nor a router problem... So did you code Sync like that? Why would it not link primarly with one of your relay server then look for others on the subnet ?

 

So I've consulted your FAQ about your network protocol:

Quote

 

1. First Sync needs to learn addresses of tracker and relay servers. For that it must be able download and parse sync.conf file.  Discovery of tracker and relay IPs: 
 - HTTP, port 80: access to config file https://config.resilio.com/sync.conf via DNS name.
 

2. Once tracker and relay are known, Sync must be able to connect to tracker so as to communicate its own IP address (public and local) to it and learn IP addresses of other peers from it.
- Connecting to the tracker server for automatic peer discovery: TCP and UDP, relevant port and addresses are here

3. Once Sync learns addresses of other peers, it will attempt to connect by these addresses directly, using both TCP and UDP. To make it possible, Sync's listening port, as defined in settings, must be opened and forwarded on all firewalls, NATs and routers between the peers.

4. If direct connection is not possible, Sync will switch to indirect connection through relay server. 
- Connecting to relay server to transfer data if direct connection is not possible: TCP, relevant port and addresses are here.

 

So if I'm following this. For docker it's a bit broken since you force users to use port 55555 for TCP data transmission (I do'nt know even why you enforce such a thing since on desktop app we can change the port and I don't see why we couldn't be able to change the prot besides the fact that you didn't resolve the permission to write to a file under linux between a webserver and the OS permission's system). 

Because the container instance, will contact the tracker with the 55555 port in its contact information but the tracker won't be able to contact him if we diverted the port to another one in the docker command. So it won't never be able to contact the relay, correct? at least that's what seems to happen to me. 

What I can't understand is that, when I filter the data stream between my different subnets, and if I let through only the port for web ui and for the data stream, it won't be able to connect between point A and point B  unless I configured for each sharing folder the specific ip and port. But If I let a free access between point A and point B, then the auto discovery works because both will be detected without a problem. 

 

So which port is used for the transaction? a random port and that's why it is impossible to filter efficiently the traffic?

Would it be a bit more easier to let the possibility to change the listening port on docker or linux instances? 

Edited June 3, 2018 by vigilian