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!
Any particular reasons you haven't built upon wireguard that would handle encryption/security for you?
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.
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.
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!
You'll waste your time on Libp2p because it already works almost exactly like your own project. It uses a network of relays as a fallback. It does add in hole punching but no one at Protocol Labs understands how a NAT works. So it only works for a subset of NATs (full cone; restrict; specifically with source port preserving delta behaviours.)
Protocol Labs is filled with big egos and midwits. In 2025, I have zero time for bullshitters and I'm going to call them out for it.
The rust-libp2p project has worked really well for me and I’m in the guts of it constantly.
Everything has been pluggable in the right ways so far. Adding new behaviors is straightforward. I can plug and play behaviors, or feature flag them, to pump out purpose built binaries.
It seems like a solid foundation for p2p research and productionizing that research. When I want to experiment with a new protocol, I can plug it in as a behavior without having to solve the rest of the stack.
I have a suspicion that in 2025 imma have to rip open the guts of swarm again to tweak connection management (we are aggressive with connections) but that isn’t daunting.
The only gripe I have with rust-libp2p right now is the learning curve (this was my first rust project - which is probably most of it).
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!
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!
- 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
dual-stack
unless they have sabers
there ain't no god damn way, bro
https://tenshidev.medium.com/ngrok-you-might-not-need-it-de4...