port 28967 must be configurable if needed (in case of vpn use)

[jimpapi]

i would like to use vpn to connect my storagenode docker installation. But as most vpn providers go not permit to select port it is a problem to map port 28967. The possibily to have local port>container port different under vpn is not always true. Some vpn providers permit the port to open only if same number and usually in random number of ports So it is necessary to have the ability to adapt the container port in other than 28967

[tempestb]

Hi Jim,

I run a node under PIA VPN and only need to configure the listening port of the node and not change the docker port. This works fine. The port can be randomized by the VPN and I change the listening port to match. Can you explain why you would need to change the docker port?

[jimpapi]

ok i my setup is: synologydocker in synologydocker container gluetun wich is a vpn client to connect to  airvpn

the gluetun connects to the vpn and gets the ip but only connected containers to it have the same ipSo i connect storagenode container to gluetun (network_mode:container gluetun) and then , i can't use anymore the local port/container port setting because all ports must be coming from gluetun port mapping but.....gluetun CAN'T map different number of ports in setup (local port/container port must be the same)must be the same number or else doesn't pass the port to storagenodeex - 28967:28967/tcpif i change the first port to the random port that vpn opens then the storj container doesn't listen ex in gluetun - 45234:28967 /tcp I have tried and other vpn containers and i have the same problemAirvpn doesn't give me port 28967 (always taken by someone else)So the only solution would be to been able to change the storagenode container internal port to the same port vpn gives me randomly But ofcourse you could ask ! And why do this vpn trick and don't run storage node normaly in docker I already have 2 storage nodes in my docker and the traffic is extremely slow (egress-ingress)but if i coud use vpn with different ip for every node it would be awsome becaude i could have more storagenodes working toghether and traffic would increase as storj could treat them as different geolocation nodes I have figured to pass the traffic through Http Proxy but i am not sure that storj packets would pass this way thank you in advance Στις Δευτέρα 6 Μαρτίου 2023 στις 04:49:34 μ.μ. EET, ο χρήστης Kevin J Baird @.***> έγραψε:

Hi Jim,

I run a node under PIA VPN and only need to configure the listening port of the node and not change the docker port. This works fine. The port can be randomized by the VPN and I change the listening port to match. Can you explain why you would need to change the docker port?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[tempestb]

Hi Jim,

Well, the subnet selection process is there to prevent centralization of the data. By you working out a way to bypass this, while interesting, it goes against the Storj terms of service. While I realize that users will find ways to utilize masking tools to get around these barriers at times, it's not in Storj's interest to make this work. Otherwise, we would just remove the subnet selection criteria and allow segments to centralize to the fastest and largest nodes.

Good luck with your endeavor, it does sound like an interesting solution if you can get it to work.

[jimpapi]

I am so sorry..i didn't understand that this is against storj rules...but think a littlei am not an IT guy...i am a doctor. And i have no knowledge of how to bypass itI suppose many people already working that way ....just look around vpn providers...the port 28967 is occupied everywhere....and it doesn't look hard to make it work...I have the 2 nodes for 7 months now...my earnings are about 24 dollars...really not worthing i think unless the traffic grows up at least in double or tripple Στις Δευτέρα 6 Μαρτίου 2023 στις 09:22:36 μ.μ. EET, ο χρήστης Kevin J Baird @.***> έγραψε:

Hi Jim,

Well, the subnet selection process is there to prevent centralization of the data. By you working out a way to bypass this, while interesting, it goes against the Storj terms of service. While I realize that users will find ways to utilize masking tools to get around these barriers at times, it's not in Storj's interest to make this work. Otherwise, we would just remove the subnet selection criteria and allow segments to centralize to the fastest and largest nodes.

Good luck with your endeavor, it does sound like an interesting solution if you can get it to work.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[tempestb]

It takes a long time to gain data as this is real customer data and there are a lot of nodes already out there taking parts of that data. If we increase the amount node operators make, there will simply be a lot more nodes and you will get even less data than you have now. There are many people using VPN's because they are behind CGNat like devices that prevent them from opening a port on their router, so they use the VPN to bypass this issue. However, the VPN's are crowded with users and the subnet masking will reduce the amount of data they get versus have a dedicated IP in a non-occupied range.