VPNCloud: Open-source peer-to-peer VPN written in rust(vpncloud.ddswd.de) |
VPNCloud: Open-source peer-to-peer VPN written in rust(vpncloud.ddswd.de) |
I just Ducked for Hamachi VPN and it still exists, see https://vpn.net
This seems to handle layer 2/3 since they mention support for TUN/Tap interfaces, but I guess 99% of people will just create IP tunnels, layer 2 is not the hot thing anymore.
Also, Hamachi was not decentralized from what I remember.
What is presented here reminds me a lot of n2n.
It would be great to have a comparison between the two. I've been using Tinc for many years; it's been working quite well, but about once a year I get a segfault (and then it gets restarted). It might be appealing to reduce the chances of that via Rust.
One commonality I found is that both are single-threaded.
I believe I've also heard of the idea of a future version of Tinc potentially using Wireguard as the underlying transport, and building its meshing on top of it. I wonder if that's on the table for VPNCloud as well.
There's other options I've looked at too: Zerotier (discounted it because it uses cloud-based configuration that's hard to self-host). And Nebula. The latter I still have to try.
I have an added requirement of needing a mobile client too (which tinc now has) so I don't think VPNCloud will work for me :(
This sounds weird to me. either there are enough resources available to sustain the bandwidth requirements or not. this changes with time and usage of the machine but just as it does without tinc. Depending on the hardware used it should not be too hard to stream common videos with something like 20mbit at max...
However, i just wanted to say; maybe you had MTU issues?
Including my RPI (running PiHole in my LAN) into the tinc VPN gave me an easy way to access my home network from anywhere in the world. One of my dedicated servers would automatically take care of routing the traffic and I can just `ssh foo@10.0.0.42` to connect to the RPI and be inside my home network.
IIRC tinc implements some tricks like TCP/UDP hole punching. So best case I end up with an actual p2p connection between my remote device and home network after connecting via tinc.
It ALSO supports arbitrary commands for connecting, like ProxyCommand in OpenSSH so you can proxy through any kind of thing manually if you need to.
Tinc is really awesome !
I've been playing with ZeroTier and liking it quite a lot.
https://github.com/dswd/vpncloud/blob/master/src/crypto/comm...
This implements a novel cryptosystem. Default to not trusting novel cryptosystems until you have sufficient reason to begin believing that they are trustworthy.
The "CIDR" peer grouping is bloody brilliant.
Being p2p and using one PSK seems to make firewalling more difficult. ZeroTier's 'capability-based + tagging' rule engine is pretty amazing in that I can easily allow just one peer to connect on a port.
VPNCloud seems to only do UDP hole punching and doesn't have the ability to relay via a third party. At least in theory, ZeroTier should handle cases that VPNCloud doesn't.
For regular nodes behind a single NAT I've personally found it worked remarkable well. Maybe I've been lucky on UPnP support with routers or something though.
I haven't run into any ZeroTier issues in this config.
I'm not super averse to Google SSO but I would not tie my critical infrastructure to it in any way.
Another dealbreaker for me is hosted configuration and access management. I want to be the only one managing it.
Regardless, it would have been nice if you could use your own identity provider.
A fair bit of the client code is also on the repo. Things like role based access control that require a backing store on tailscale side aren't open.
Wondering whether there is business opportunity in offering beacons as a service.
Regarding your latter thought, it seems to me that if I'm running a service like this on my servers, I probably don't want to connect to unknown/untrusted peers. Open to use cases where that make sense, though.
[Edit] Just found the documentation on beacons that explains the trust model. So sounds like there is merit to your idea :)
I did had a use case in the past for peer to peer VPNs, mainly because in the 2000s, most hosting companies would only provide you crappy VMs with a single public interface. If you needed some control over the network, subnets, etc, then you would need some kind of overlay. This, added with the fact that you would typically have dozens of heterogeneous boxes at different providers, made maintaining a traditional host to host ipsec full mesh nightmarish. I used n2n (a peer to peer VPN) to reconciliate these various internet facing boxes in a single private IP network.
Nowadays, cloud providers are much more evolved, and offer you full configuration of multiple public/private interfaces, so recreating subnets over public facing boxes is not really a concern, which is why IMHO peer to peer VPNs do not serve much purpose in 2021.
Actually there is, but it's not immediately obvious: https://vpncloud.ddswd.de/docs/beacons/
It's seems really simple to use as well: The linked implementation in PHP on https://vpncloud.ddswd.de/docs/beacons/php-service/ is only around 80 lines of code and extremely simple and due to the beacon design doesn't compromise the security of your setup if anything goes wrong.
"Help with other platforms: If you are a Rust developer with experience on Windows or MacOS your help on porting VpnCloud to those platforms is very welcome."
Hence it's not possible for almost all to involve a NAT, even if all IPv4 traffic would.
I think you're correct. Thanks. My information was from an old blog post from 2014 [1] but they seems to have added support since then: https://github.com/zerotier/ZeroTierOne/commit/bf193dd3. Edited my post.
[1] https://www.zerotier.com/2014/08/25/the-state-of-nat-travers...
It's only source available: it is licensed under the BSL which is not a free software license. Use of the term open source is not appropriate.
A friend works there and tried to recruit me; I declined because of this sort of fake open source charlatan nonsense.
The software in TFA (VPNCloud) is indeed free software/open source: it is licensed under the GPL, just like Linux.
So, older versions are indeed open source, and new versions will eventually be so as well.
What’s your objection to the BSL? It seems like a great way to provide ongoing funding to open source, and guarantees popular commercially developed software won’t end up as abandonware.
It also makes it hard for a fork to develop traction, as a fork would have to start at a much older version that is Open Source, or the ecosystem would have to forgo the opportunity for third-party hosting services to support it.
The freedom to fork is an essential freedom. Without it, I would not feel comfortable contributing to the project. Nor would I feel comfortable basing critical business infrastructure on it.
Others may be fine with proprietary source-available software, and that is fine for them, but I strongly prefer Open Source for my needs, especially for core infrastructure.
> The Business Source License (this document, or the "License") is not an Open Source license.
https://github.com/zerotier/ZeroTierOne/blob/a7f652781faedfb...
Is the concern simply that governments can only use it to help people?
I know I can self-host even that top management layer (I think they called it "earth" or something). but they make that pretty complicated, probably on purpose.
In the end I just wrote it off in the end as something that has goals not aligned with mine. I'm going to look at Nebula (from Slack) soon. I use tinc at the moment but I wish it was more performant.
There's many options in this arena now so there's no point in sticking with something that doesn't completely fit your needs.
True. The stateless firewall is rather important to me and I haven't found that in anything else (I'll keep an eye on Nebula).
I'm not some free software zealot; I use macOS and the Creative Cloud and a bunch of other proprietary crap on a daily basis. I just don't pretend it respects my freedom. Nonfree licenses are like that.
It's not like it "switches to even more free": it is presently nonfree.
It's free for any use-case I'm concerned with. I can modify the source, self-host it, and run thousands of nodes through it if I want. All I can't do is take their work, slap my name on it, and sell it.
If that was your intent then VPNCloud is even less free. The GPL3 license means you could never host a closed-source version.
It's the AGPL that prohibits this, which is why I consider the AGPL nonfree.
The point being that any license is going to have some amount of:
> restricts the freedoms of the world to build upon, adapt, and use the software for any purpose.
It's just up to if you like the terms or not.