Secure server management without VPN complexity(wormhole.network)
wormhole.network
Secure server management without VPN complexity
https://wormhole.network/
6 comments
I am curious regarding the security model. I could not find anything about its architecture and technology on the website.
Hi,
First of all, I should have added "Show HN:" in front of the post (if any mod can change it, please do). Secondly, thank you for your time looking at it! :)
I'm one of the people behind this and I'll be happy to answer your questions and hear any feedback, especially criticism as there's room for improvement.
As per the architecture, we basically deploy SoftEther (https://www.softether.org) servers on different datacentres around the world, that are actually the central servers to any hub created. These servers are reachable on a variety of ports as supported by SoftEther, but our system creates config files to use port 443/TCP to make sure Wormhole works on as many sites as possible.
When you deploy the agent (i.e. SoftEther client) with the provided config files, your server will establish a VPN connection to your chosen server and receive an IP address from our DHCP server. Again to make sure we work on as many places as possible "out of the box", you'll get an IP address from 100.64.0.0/24 range by default (the whole /16 is reserved for carrier-grade NAT). Every other machine you join to this network will have L2 and L3 visibility over this virtual network.
The agent creates a virtual interface on your machine, so reaching other machines in the network is as transparent as possible for you and your applications.
As all the connections from your machines are outbound, there's no need to expose any ports on your servers for them to be reachable through a Wormhole network.
As an example, some time ago I released a Docker image running a Minecraft server that also joins a Wormhole network (you just need to provide the config files). This server would be reachable from inside your Wormhole network, but it won't be exposed to external connections, so only whoever joins your Wormhole network can connect to the server. https://github.com/pjperez/docker-whminecraft
We haven't done a good job on communicating all the above, which is something I take on board and add to the backlog. I'll also be extremely happy to hear more feedback.
Thank you!
First of all, I should have added "Show HN:" in front of the post (if any mod can change it, please do). Secondly, thank you for your time looking at it! :)
I'm one of the people behind this and I'll be happy to answer your questions and hear any feedback, especially criticism as there's room for improvement.
As per the architecture, we basically deploy SoftEther (https://www.softether.org) servers on different datacentres around the world, that are actually the central servers to any hub created. These servers are reachable on a variety of ports as supported by SoftEther, but our system creates config files to use port 443/TCP to make sure Wormhole works on as many sites as possible.
When you deploy the agent (i.e. SoftEther client) with the provided config files, your server will establish a VPN connection to your chosen server and receive an IP address from our DHCP server. Again to make sure we work on as many places as possible "out of the box", you'll get an IP address from 100.64.0.0/24 range by default (the whole /16 is reserved for carrier-grade NAT). Every other machine you join to this network will have L2 and L3 visibility over this virtual network.
The agent creates a virtual interface on your machine, so reaching other machines in the network is as transparent as possible for you and your applications.
As all the connections from your machines are outbound, there's no need to expose any ports on your servers for them to be reachable through a Wormhole network.
As an example, some time ago I released a Docker image running a Minecraft server that also joins a Wormhole network (you just need to provide the config files). This server would be reachable from inside your Wormhole network, but it won't be exposed to external connections, so only whoever joins your Wormhole network can connect to the server. https://github.com/pjperez/docker-whminecraft
We haven't done a good job on communicating all the above, which is something I take on board and add to the backlog. I'll also be extremely happy to hear more feedback.
Thank you!
Just want to add another vote to "document that". Right now it sounds a bit too much like magic, which technical people always are skeptical of, and in security "we are using $establishedProject" is better than suspecting you cobbled something together yourself.
Makes a lot of sense, we will work on communicating that properly.
Thanks for the response. Emailing the mods might get the title changed.
For a lot of products, who cares how it is built? For security related products, the slightly counter-intuitive idea of greater openness seems to be a potential marketing advantage...and as it slides toward peer review perhaps a technical one.
Hiding the technical sausage factory from the call to action and the install and operation is a good thing. But clearly it is an important part of who your company is and expressing it, as here, may be as important over the long term as the non-technical. I mean anyone who understands "VPN" enough to want one and select one, is going to be at least a little technical.
For a lot of products, who cares how it is built? For security related products, the slightly counter-intuitive idea of greater openness seems to be a potential marketing advantage...and as it slides toward peer review perhaps a technical one.
Hiding the technical sausage factory from the call to action and the install and operation is a good thing. But clearly it is an important part of who your company is and expressing it, as here, may be as important over the long term as the non-technical. I mean anyone who understands "VPN" enough to want one and select one, is going to be at least a little technical.
Thank you for the follow up, I appreciate you putting some time apart to reply.
I think you've raised very good points, we will work on getting this communications right.
Thanks
I think you've raised very good points, we will work on getting this communications right.
Thanks