I would say zrok.io is more privacy-focused, particularly with its frontdoor and private sharing features.
Ingon · 1h ago
connet itself doesn't have a notion of public share at all - you need clients/peers on both ends (destination and source) to "project" a remote service. connet.dev do enhance this, by running the source clients publicly, but you need to specifically enable this, and it is best used as a break-glass option, since obviously makes things less-private.
In any case, zrok.io is cool, it is certainly more mature and feature rich project.
Ingon · 1d ago
Very cool comparison, thank you!
One new feature I haven't highlighted yet, is that you can, in addition, encrypt traffic as it goes through relays (both via tls or noise-inspired protocol, dhxcp). This enhances privacy, even when you are using public (e.g. not owned by you relays), covering a case like https://connet.dev nicely.
PLG88 · 7h ago
Sounds like what zrok.io does ... do you also support completely E2E private shares like it does - https://docs.zrok.io/docs/concepts/sharing-private/. This means the resource does not have a public IP at all (note, zrok also does public shares).
Ingon · 1h ago
If I understand correctly the terminology/case, all shares in connet a private. You access a remote resource as it was local, but that doesn't mean the resource is publicly visible. For example, my local network clients, do not need public IP or special firewall rules to communicate with remote clients.
What I was describing above is a specific way to route traffic - by default if direct connection between clients can be made (e.g. peer-to-peer), connet uses that. However, in cases where this is not possible, connet can use relays to send traffic between peers. In this scenario, you can in addition encrypt traffic end-to-end, so if you are using a public/untrusted relays, the relay itself cannot inspect/see traffic between peers.
Of course, you can also configure peers to never use relays and always communicate directly. A relay (or a third-party) is only used when both peers allow it and no direct route can be used.
srichard16 · 1d ago
Curious: why do you see ngrok as just for testing and dev when thousands of users use ngrok in production?
Full disclosure I work there.
ghoshbishakh · 1d ago
Why route all traffic through a tunnel for a production setup? On-premise solutions will use static IPs from their ISPs.
Interestingly I just did this with my own reverse proxy recently; nginx proxy manager in a container running on the network of a Tailscale container on the same host, connected to a Tailscale exit node on internal network. Will take a look at whether this is better.
Ingon · 19h ago
Thanks, it would be great to hear if you tried connet and how it went!
In any case, homegrown solutions are great, they offer the most flexibility, but also require the biggest time investment (and knowledge of course).
Ingon · 1d ago
Hi All,
This is a hosted version of connet[1]. In addition, it allows users to expose their endpoints directly on the internet (optional and still in progress)
Quick demonstrations & development: ngrok
Low-resource environments (IoT, embedded): rathole
Privacy-focused deployments: connet
Production with active community: FRP
Self-hosting with direct connections: connet
https://gist.github.com/andrewarrow/d0e41dd954485a8574b9ea74...
In any case, zrok.io is cool, it is certainly more mature and feature rich project.
One new feature I haven't highlighted yet, is that you can, in addition, encrypt traffic as it goes through relays (both via tls or noise-inspired protocol, dhxcp). This enhances privacy, even when you are using public (e.g. not owned by you relays), covering a case like https://connet.dev nicely.
What I was describing above is a specific way to route traffic - by default if direct connection between clients can be made (e.g. peer-to-peer), connet uses that. However, in cases where this is not possible, connet can use relays to send traffic between peers. In this scenario, you can in addition encrypt traffic end-to-end, so if you are using a public/untrusted relays, the relay itself cannot inspect/see traffic between peers.
Of course, you can also configure peers to never use relays and always communicate directly. A relay (or a third-party) is only used when both peers allow it and no direct route can be used.
Full disclosure I work there.
Full disclosure - I work at https://pinggy.io
In any case, homegrown solutions are great, they offer the most flexibility, but also require the biggest time investment (and knowledge of course).
This is a hosted version of connet[1]. In addition, it allows users to expose their endpoints directly on the internet (optional and still in progress)
[1] https://github.com/connet-dev/connet