Basically a re-invention of the early 2000's Hamachi app?
I think I might have used Hamachi once or twice to play a network version of Age of Empires over_the_internet long before this was a standard function in games :)
I just Ducked for Hamachi VPN and it still exists, see https://vpn.net
I believe Hamachi was mainly a level 2 VPN, perfect for transporting IPX, which was really mainstream for LAN games of the 90s.
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.
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.
Yes I use tinc too. The only problem I have with it is that it's not very performant. For example video streaming through it always causes hiccups.
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 :(
IMO tinc is really awesome. I've been using it for years to connect my servers, laptops and desktops into a VPN.
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 [email protected]` 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.
This implements a novel cryptosystem. Default to not trusting novel cryptosystems until you have sufficient reason to begin believing that they are trustworthy.
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.
It is great, I totally agree. The fact that it's OSS is awesome even if just from a learning standpoint.
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 :)
The problem with these kind of things is that now I need to ask around some IPs to connect to, as I see there's no automatic peer discovery.
Sounds awesome nonetheless.
What would automatic discovery even do? Add you to some worldwide IP overlay on top of internet? What would be the use of that?
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.
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.
Yes, wireguard is a point-to-point transport layer. VPNCloud includes a management layer about that. And for example deals with NATs, network management etc.
"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."
[+] [-] janandonly|5 years ago|reply
I just Ducked for Hamachi VPN and it still exists, see https://vpn.net
[+] [-] Galanwe|5 years ago|reply
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.
[+] [-] ivanstegic|5 years ago|reply
[+] [-] nh2|5 years ago|reply
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.
[+] [-] GekkePrutser|5 years ago|reply
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 :(
[+] [-] rkeene2|5 years ago|reply
[0] https://news.ycombinator.com/item?id=19304624
[+] [-] CloselyChunky|5 years ago|reply
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 [email protected]` 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.
[+] [-] Black101|5 years ago|reply
[+] [-] linsomniac|5 years ago|reply
I've been playing with ZeroTier and liking it quite a lot.
[+] [-] sneak|5 years ago|reply
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.
[+] [-] lwhsiao|5 years ago|reply
https://blog.tonari.no/introducing-innernet
[+] [-] aloknnikhil|5 years ago|reply
[+] [-] canada_dry|5 years ago|reply
The "CIDR" peer grouping is bloody brilliant.
[+] [-] kenmacd|5 years ago|reply
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.
[+] [-] ensignavenger|5 years ago|reply
[+] [-] Anunayj|5 years ago|reply
[+] [-] ohmyblock|5 years ago|reply
[+] [-] meibo|5 years ago|reply
I'm not super averse to Google SSO but I would not tie my critical infrastructure to it in any way.
[+] [-] jsilence|5 years ago|reply
[+] [-] jsilence|5 years ago|reply
Wondering whether there is business opportunity in offering beacons as a service.
[+] [-] njacobs5074|5 years ago|reply
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 :)
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] ranguna|5 years ago|reply
[+] [-] Galanwe|5 years ago|reply
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.
[+] [-] dividuum|5 years ago|reply
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.
[+] [-] unixhero|5 years ago|reply
[+] [-] robert_foss|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] skanga|5 years ago|reply
[+] [-] guerby|5 years ago|reply
"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."
[+] [-] janandonly|5 years ago|reply