Connet.dev – high performance reverse proxy to connect devices privately(connet.dev)
connet.dev
Connet.dev – high performance reverse proxy to connect devices privately
https://connet.dev
4 comments
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.
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.
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).
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.
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.
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.
Full disclosure I work there.
Why route all traffic through a tunnel for a production setup? On-premise solutions will use static IPs from their ISPs.
Full disclosure - I work at https://pinggy.io
Full disclosure - I work at https://pinggy.io
I would say zrok.io is more privacy-focused, particularly with its frontdoor and private sharing features.
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.
In any case, zrok.io is cool, it is certainly more mature and feature rich project.
Ahh, interesting, thanks for making it clear to me. You should check out OpenZiti too, that's what zrok is built on.
I'm a zrok.io fan
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.
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).
In any case, homegrown solutions are great, they offer the most flexibility, but also require the biggest time investment (and knowledge of course).
This reminds me a bit about gsocket[1], except that it seems slightly more configurable and not just intended to be a backdoor.
[1]: https://gsocket.io/
[1]: https://gsocket.io/
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)
[1] https://github.com/connet-dev/connet
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
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...