Over the past couple of months, I've been working on connet. At this point, it is working pretty smoothly (in what I use it for), so I wanted to share it with more people and see what they think.
I know many other similar/reverse proxy solutions exist - like https://github.com/fatedier/frp, https://github.com/rapiz1/rathole, and a bunch more you can find at https://github.com/anderspitman/awesome-tunneling. However, I wanted to try and put my own little peer-to-peer twist on it.
Thanks for checking it out, and sharing any feedback you might have!
This looks great!
Have you seen the libp2p project? Might help get you pluggable NAT traversal and transport strategies plus peer discovery. We’ve been using rust-libp2p for building an overlay network and have had decent success.
Also take a look at iroh [0]. It doesn't come with the bloat of ipfs, provides robust core building blocks. They really figured out NAT traversal.
Thanks!
No, I wasn't aware of libp2p. Looks very relevant to what I'm doing, and I'll definitely take a closer look. Thanks for pointing it out!
Nice. I really like the config format regarding the services available/exposed.
Any particular reasons you haven't built upon wireguard that would handle encryption/security for you?
Thanks for taking a look!
Initially, I did think I'll be using wireguard. What stopped me at the time (as far as I remember) was that I couldn't just use the protocol part of the official golang library (e.g. https://git.zx2c4.com/wireguard-go/about/). Another thought I had at the time, was that I would had to use the user-space wireguard implementation, which everyone claimed was slow (I should have probably looked into how slow it is).
Another thought I had was to use the noise protocol (which wiregruard also uses) for security and building on top of that. Which meant I would have to implement most of what QUIC (and wireguard) does to make UDP a reliable protocol - retries, ordering, streams, etc. So, eventually, I just settled on using QUIC for the first version - later we can always add more ways for peers to connect to each other.
Suggestion for the quickstart: refer to the clients as either D,S or a,b throughout - I found the mixture a bit confusing.
Thanks for checking it out and pointing this inconsistency! I've updated the readme, hopefully it is less confusing now.
You can do this with SSH alone.
https://tenshidev.medium.com/ngrok-you-might-not-need-it-de4...
But with SSH you won't get NAT traversal and then the direct connection, right? You will forward through a server. Or am I missing something?
Can I use this to host a Minecraft server? I’ve used hamachi and zero tier in the past, and the former USED to work but stopped recently for some reason
While I haven’t tested it with Minecraft (I was planning to) I believe it should basically work. Let me know how it went if you decide to try it!
I have been using autossh in production for the past decade without problems. Does frp/ngrok/connet, etc. have any advantage that I don't know about?
At first I was confused as how autossh was relevant here, since it seemed like a supervisor for the ssh process (from https://github.com/Autossh/autossh). Then I realized that you are probably running ssh (reverse) tunnels. If that works for you, I don't think you should change!
With others, I think its a mixed bag, in no particular order:
* in my experience, opening up new connections in SSH is somewhat slow (compared to QUIC and ngrok). I believe this was due to how SSH verifies each new stream.
* connet (and others that use UDP based protocols) don't experience the TCP head of line blocking issue. This might not be an issue necessarily, especially if you have a good, consistent connection between peers.
* some of the other tools provide much richer interface (compared to raw SSH), like traffic inspection and modification, different security properties, etc
* connet (and others) does allow multiple destinations and sources binding on the same name, so you can have multiple clients talking to a clustered service
This is it off the top of my mind. Thanks for checking connet out!
So if I understand correctly, this should be comparable to what Tailscale is doing?
You can achieve a similar effect with both, yes. However, they fundamentally work differently.
Tailscale (e.g. wireguard) is a way to create a virtual private network between two (or more) machines. This means they can pretend they are on the same network, even if they are physically on different networks. Now, having them on the same (virtual) network, means you can open up the firewall on the target machine (for that specific network), and access services that are running there. You'll still need to use the other machine's IP address/name on that network to access it.
connet on the other hand is more like a projection (or tunnel) - it opens up a TCP listener on your local machine, and internally forwards all connections and traffic to the TCP listener that is running on the remote machine. At your local machine, it looks like you are running the target service locally, and you access it via localhost.
I hope this explains how is connet different from Tailscale, thanks for checking it out!
Spent 2 years working on the same problem. Ended up designing a library that does:
- direct connect
- reverse connect
- tcp hole punching
- turn support
Has other features too like:
- multi-interface
- duel-stack
- port forwarding and pin holes
Show some love cause its at 64 stars and is IMO, objectively better for direct peer-to-peer networking than OPs library that only supports direct, reverse, and relay, and which doesn't seem to do anything to open ports or firewalls. It does make me salty that I try so hard with my own work but what seems to make people successful is their ability to get lucky on sites like this or game them.
No offense to OP. Here's my project: https://github.com/robertsdotpm/p2pd
≥- duel-stack
dual-stack
unless they have sabers
connet is a young project, and draws inspiration from many great projects like yours. Thanks for sharing it, I starred it!