[HN Gopher] Show HN: Weron - A Peer-to-Peer VPN Based on WebRTC ...
___________________________________________________________________
Show HN: Weron - A Peer-to-Peer VPN Based on WebRTC Written in Go
Hey HN! I just released weron, a P2P VPN that uses WebRTC for
transport which I've been working on for the last couple of months.
It can create both layer 2/Ethernet and layer 3/IP overlay
networks, and the underlying transport layer can be easily embedded
to write your own P2P apps with Go. Compared to for example
Tailscale, WireGuard and ZeroTier, its much harder to block on a
network level and also significantly easier to set up, while not
sacrifing much performance. I'd love to get your feedback :)
Author : pojntfx
Score : 68 points
Date : 2022-05-07 19:48 UTC (3 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| ianlevesque wrote:
| > Compared to for example Tailscale, WireGuard and ZeroTier, its
| much harder to block on a network level
|
| Tailscale at least bundles in an HTTPS fallback for those
| situations. I'm not sure that claim holds up.
| pojntfx wrote:
| A HTTPS fallback is more or less what weron provides - if you
| want to block the "weron protocol", you either have to block
| access to the signaling service (which runs on 443, and its
| just WebSockets) or block the related protocols, but since Zoom
| etc. use the same protocols that would probably be pretty hard
| to implement without disrupting everyday operations.
| saurik wrote:
| Is what makes this a "P2P" VPN--as opposed to merely VPN software
| that you might choose to use between peers (such as
| Wireguard)--that it supports the group/"community" network
| behavior? When you do that, are you building a fully-connected
| overlay network--where everyone has a separate WebRTC link to
| each of the other participants--or are you building some kind of
| organized P2P network topology out of the participants?
|
| (Note: I work on Orchid, a decentralized market for bandwidth
| built on Ethereum and WebRTC, which has a multi-hop-capable VPN
| client for various platforms available.)
| pojntfx wrote:
| > Is what makes this a "P2P" VPN [...] that it supports the
| group/"community" network behavior?
|
| More or less! Compared to say OpenVPN there is no central
| server that all traffic is routed through (unless you choose to
| activate TURN of course, see the `--force-relay` flag), so
| hosting it is much cheaper as the only public part of the
| infrastructure is the part that exchanges the candidates ^^ Its
| pretty close to how n2n[1] does it, but has proper NAT hole
| punching support due to the WebRTC backend.
|
| > When you do that, are you building a full-connected overlay
| network [...]
|
| Yes! Its a full mesh; it seems to scale pretty well to a fairly
| large number of nodes, although I haven't tested it with more
| than ~100 peers in a single community yet. If the overhead of
| maintaining all of the connections is too much or peering
| between nodes in an issue, TURN can help to connect those peers
| with the rest of the mesh. Orchid looks interesting!
|
| [1] https://github.com/ntop/n2n
| [deleted]
| 1vuio0pswjnm7 wrote:
| Here is some initial feedback: Nice selection of static binaries!
|
| However the choice to hardcode Google as a default STUN server is
| off-putting. IMHO, 2008's n2n would never set a third party
| server as a default. https://luca.ntop.org/n2n.pdf
| pojntfx wrote:
| Thanks for your feedback! Is there a publicly hosted STUN
| server that guarantees better privacy? I'd love to use it if
| there is an alternative. It is of course possible to use any
| other STUN/TURN server by changing the `--ice` flag and host
| your own with i.e. `coturn` ^^
| linsomniac wrote:
| This looks pretty slick, and the WebRTC seems like it might offer
| some choices of traversal that would work where others don't. The
| inbuilt tools for "chat" (seems a useful test), throughput and
| latency also seem nice. I've been running into some weirdnesses
| at times with Nebula and Zero Tier where it's unclear where my
| latency or throughput limits are coming from.
|
| I'm looking forward to doing a lot more with overlay networks in
| the short term, I've been playing with a variety of them over the
| last 18 months or so and just need to pick something and start
| deploying it.
| pojntfx wrote:
| Thank you! From my experience if you can get say Zoom or Meet
| to work in the network you're trying to deploy weron in, you'll
| get weron working as well. And if the traversal still doesn't
| work - just specify a TURN server on the `--ice` flag and it
| will definitely work through relay ^^
| 13415 wrote:
| Can this be used as a library like libp2p, or does it require me
| to run binaries?
| pojntfx wrote:
| You can use every part of it as a library! See
| https://github.com/pojntfx/weron#8-write-your-own-protocol-w...
| and https://pkg.go.dev/github.com/pojntfx/weron ^^
| 13415 wrote:
| That's very cool! Thanks for answering my question so fast!
| a-dub wrote:
| very cool! was recently musing about how the next frontier in
| vpns is steganography, and here we are.
|
| are the webrtc streams running at a constant bitrate or can the
| streams be detected by doing traffic timing analysis?
|
| (i once looked at adding constant bitrate support to wireguard
| but ultimately abandoned it as it was looking to be excessively
| complicated)
| pojntfx wrote:
| Thanks! Its using the Pion library[1] which doesn't seem to be
| using a constant bitrate; that would definitely be an
| interesting addition though. Sending e.g. zeroes when its not
| transmitting packets/frames is totally doable, but atm not
| implemented.
|
| [1] https://github.com/pion/webrtc
| a-dub wrote:
| the other big upshot would be that it would never leak
| anything in the flow characteristics of the stream.
|
| i suspect that it might be possible to identify major
| websites being loaded by simply analyzing packet sizes and
| timings, but maybe not in http/2 world.
| tptacek wrote:
| Why wouldn't you just tunnel WireGuard over WebRTC? There's
| already a very, very good implementation of WireGuard --- one of
| the two major production implementations --- in Go. We tunnel it
| over WebSockets, and it took like an hour to write that code.
| pojntfx wrote:
| You could totally do that! See
| https://github.com/pojntfx/weron#8-write-your-own-
| protocol-w..., but I agree with saurik - if DTLS is secure
| enough for your usecase, that would just add overhead ...
| VWWHFSfQ wrote:
| So that's what, 4 layers of encapsulation now? Yikes.
| saurik wrote:
| That seems like it would offer no advantages, but would result
| in all of worse performance, smaller remaining available packet
| size, and "more code".
| Sean-Der wrote:
| This is so cool! I love the embedded aspect of it, that was a big
| goal of Pion. Really exciting for users to not have to
| setup/configure a service to get connectivity going.
|
| re: concerns about STUN I would love to experiment with adding
| NAT-PMP/PCP support to pion/ice. STUN server usage seems to be a
| major sticking point for people. Talked about it a bit here [0].
| I am all for doing it, just would like to know the code is
| actually wanted before writing it :)
|
| [0] https://mobile.twitter.com/_pion/status/1522365018855165952
| pojntfx wrote:
| Thanks for your work on Pion! I really enjoyed working with it,
| even in other places (STFS[1], a file system for tape drives
| that I wrote in January, uses it to access remote servers
| behind NAT for example). NAT-PMP/PCP support would be awesome!
|
| [1] https://github.com/pojntfx/stfs
___________________________________________________________________
(page generated 2022-05-07 23:00 UTC)