Public Relay List

[UnrelatedWorks]

Is your feature request related to a problem? Please describe. A flag which displays a list of publicly available croc relays. Failover for the default relay.

Describe the solution you'd like A addition to the relay flag command. The relay would send a ping / heartbeat to a central server which manages and displays them. When croc cannot reach the default relay (firewall rules, blocked by country etc) it can automatically failover to another public relay.

Describe alternatives you've considered A text file that contains a "basic" set of proxies. The text file could be edited in git and if the proxies are tested merged into the main repo. A hashtag on twitter where everyone can post the IP address and Port of their proxy. Preferably with location and speed information.

Additional context Some people still have open server resources just laying around (we sure do) and would like to support the project. While it's possible for everyone to announce that they now have their own proxy, for user it'll be hard to find. Integrating it into croc directly would make it easier.

Potential problems A malicious actor could deploy a modified relay.

[Vebryn]

Describe the solution you'd like A addition to the relay flag command. The relay would send a ping / heartbeat to a central server which manages and displays them. When croc cannot reach the default relay (firewall rules, blocked by country etc) it can automatically failover to another public relay.

I agree since defaults ports are blocked :

&cli.StringFlag{Name: "ports", Value: "9009,9010,9011,9012,9013", Usage: "ports of the local relay (optional)"},

defaults ports 80 and 443 should be better to pass through firewall

Best regards.

[lukas-mertens]

One additional use-case would be to use multiple relays in parallel to get more transfer-speed. Especially when you have something like 10G connection, the default relay could get too slow (happened to me today, took me some time to figure out where my bottle-neck was until I switched to a local relay). Combining multiple relays could speed up the transfer drastically.

One additional idea would be to implement "trusted" and "non-trusted" remotes in this scenario. The default-gateway has a bigger trust-level. As far as I understood so far, the biggest attack-vector is an insecure room-code, right? @schollz If the room-code is secure enough, even the relay can not do anything with the data, as it is encrypted securely using the code e2e. When using untrusted remotes, you could always use one room-code over the default-gateway when people choose insecure room-codes and randomly generate secure room-codes for all the other relays which are communicated through the established channel on the default relay, basically using different room-codes in parallel, making all other relays completely trustless. This should increase the total transfer-capacity of croc drastically, as it can now make use of all the publicly hosted relays and the public relay is only for communicating the secure room-codes and coordinating which relays are available and healthy.

[schollz]

bottle-neck was until I switched to a local relay

Local relay is always faster, as it's on LAN. The bottleneck for public relay is likely always the upload speed which depends on your ISP. The upload speed is maximized through parallel tcp connections so I'm pretty sure having parallel relays won't be effective

[lukas-mertens]

@schollz I see. After reading a bit about your PAKE-implementation, I realized that it is probably not necessary to do this "trusted" and "untrusted"-relay stuff I was talking about, as the relay is trustless anyways as it seems and works even with a relatively weak password.

What I said about the local relay being faster is still true though. Here is what I did: I have a file laying around on a windows-machine with tailscale installed and 250MBit/s upload, which is trying to send a file to another (linux)-machine in a different building and network with around 600MBit/s download. I measured the speed at the time when I did my experiments and always got at least the speeds mentioned. In a perfect world this would be around 31MB/s of data-transfer using the --no-compress flag on the receiver to eliminate possible CPU-bottlenecks. Without doing anything with custom parameters, the "out of the box" experience started with around 4MB/s und fluctuated pretty strong, sometimes dropping below 400KB/s. At this point I was sure that not my upload-speed would be the problem, as both machines were connected through tailscale, I was wondering though, why it would need the relay at all, as it had a "direct" connection through a high-performance VPN. After some investigation I figured out that the firewall on my windows-machine was configured in a way which disallowed incoming connections to croc. That means it probably fell back to the public relay instead of being able to host the ad-hoc local relay.

After figuring that out I fixed my firewall-config and used --ip <windows-machine> on the receiving machine and was able to consistently transfer around 28MB/s with a very stable connection. This led me to the conclusion that the public relay might be overloaded and my idea of fixing this by using multiple, community-contributed relays. I have a lot of bandwidth on a bunch of servers left and would be happy to contribute servers for this. A good inspiration could be syncthing: https://docs.syncthing.net/users/strelaysrv.html They use community-contributed relay servers as well.

[schollz]

@lukas-mertens it would be very useful to see what's happening in the sender and receiver using the --debug flag, without the --ip flag.

before croc falls back to the public server entirely it tries the local ip addresses from the public server connections to make a lan connection when it can't obtain them from multicast peer discovery. More info is needed on why this failed on your particular network.

[lukas-mertens]

@schollz

I sent you the logs via e-mail. Here is the summary:

croc with firewall andjj:wq tailscale disabled (meaning through the public relay) averaged at around 10MB/s today, sometimes it went to 16MB/s. The full transfer took about 4:30min.

croc with tailscale enabled and firewall enabled: 4min. The speed fluctuated pretty strong. Sometimes it peaked at around 25MB/s and sometimes it went down as far as 5MB/s.

croc with tailscale enabled averaged at around 20-25MB/s today pretty consistently. The full transfer was about 3min.

Today the differences weren't as big as they were in my last try. And I know that I did a pretty high-throughput transfer over the public relay on another day as well (probably around 40MB/s). But the day I was transfering a few hundred GBs (sorry for that, didn't know it was using a public relay at first, I thought it was going peer to peer) it went pretty bad. Today it was mostly stable but you could clearly see stability-differences, as the speed was fluctuating a lot more when doing the transfer over the public relay.

I think the biggest advantage of some load-balancing between multiple relays would be though, that you don't have to pay for all that traffic. I can easily contribute 10-20TB of traffic every month to the relay-pool if there was one. I think this would reduce your costs, especially if more people would consider donating bandwidth for the project. Additionally this would make the project scalable and we could think about ways to make it more user-friendly for non-tech people.

[schollz]

Thanks @lukas-mertens I'm following up with you via email! I will need your help with some debugging to get to the bottom of it but I have a hypothesis.

[github-actions[bot]]

Stale issue message