[HN Gopher] Show HN: connet - A P2P reverse proxy with NAT trave...
___________________________________________________________________
Show HN: connet - A P2P reverse proxy with NAT traversal
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!
Author : Ingon
Score : 70 points
Date : 2025-01-02 16:27 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| rudasn wrote:
| 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?
| Ingon wrote:
| 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.
| r3trohack3r wrote:
| 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.
| Ingon wrote:
| 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!
| wngr wrote:
| 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.
|
| [0]: https://github.com/n0-computer/iroh
| Ingon wrote:
| Will do, thanks for sharing!
| crtasm wrote:
| Suggestion for the quickstart: refer to the clients as either D,S
| or a,b throughout - I found the mixture a bit confusing.
| Ingon wrote:
| Thanks for checking it out and pointing this inconsistency!
| I've updated the readme, hopefully it is less confusing now.
| valorzard wrote:
| 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
| Ingon wrote:
| 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!
| hailruda wrote:
| So if I understand correctly, this should be comparable to what
| Tailscale is doing?
| Ingon wrote:
| 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!
| nurettin wrote:
| 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?
| Uptrenda wrote:
| 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
| yownie wrote:
| >=- duel-stack
|
| dual-stack
|
| unless they have sabers
| Uptrenda wrote:
| Maybe they do, TCP hole punching is like a duel in a way. You
| are right tho, my spelling is horrible. Hope my message above
| doesn't come off in bad taste. I should be happy for the OP I
| guess.
___________________________________________________________________
(page generated 2025-01-02 23:00 UTC)