There is no silver lining!
Once again, popular wisdom is confirmed, but only this time with the help of the dead coronavirus. Everyone was transferred to a remote site, a lot of subscription content was opened and, as a result, an explosive increase in traffic occurred in the telecom. According to various estimates, traffic in user segments has already grown by 80% and does not think to stop. Traffic popped up so hard that in several countries Netflix, Youtube and other streaming services were first asked to restrict, but now they are effectively prohibited from transferring content in HD quality. For users are so actively engaged in work from home that operators simply do not have space for entertainment in the channels.
But who really doesn’t have time to substitute bags under the flood of poured money is the providers of VPN services and all those involved in their maintenance. Fortunately, some of them didn’t have their own VPN and it was easier to buy a ready-made service; for others, it was simply not designed for such a stream of users and died under load on the first day. In a word, VPN is now the most popular word in the telecom world. Probably even more popular than this damned plague.
And here it is worth asking yourself the question – what is the difficulty of taking and organizing a convenient VPN service, and then just supporting it? The technology was invented far from yesterday, all options have long been known, so why is there so much talk around it?
But in order not to write one million the first article about the intricacies of setting up OpenVPN, IPSec and others, let’s approach the other side – does it happen that a VPN is done quickly, conveniently and for free? That’s really a dozen clicks – and it works like a clock. And site-to-site, so that offices can be connected, and site-to-point, so that remote users can quickly and conveniently.
Spoiler – it happens.
Proofs and reasoning – under the cut.
So, all the employers who sent people home thought hard about two things: how to provide employees access to the data they need to work, and how to secure this data. The answer to both questions lies in the plane of the VPN solution used, which means it’s time to consider what options we have for its organization.
The option is commonplace: we compress money into a cam and buy a turnkey solution. Perhaps even with support. Such solutions are delivered as off-the-shelf services. You deploy the application on your network, connect it to the service provider, then the magic of routing happens, and all you have to do is give the employees a link to the application and a short instruction for connecting. The option is very good, but a) it usually costs a lot of money b) nothing depends on your needs, use what they give.
The option is cheaper, but not so simple: we independently deploy the chosen on-premise solution. More recently, almost any sysadmin would point you at Openvpn. It is really good, it can just work stably, but there was a problem – to configure it, a newbie (and not only a newbie, let’s be honest) had to seriously delve into the documentation and scattering of configs, then just spit and implement one of the solutions offered in network. Then followed by writing a complex instruction for the user, issuing him a file with keys and a fascinating conversation on the phone, when the user does not even understand where and what to enter into the OpenVPN client. And on the server side there was an eternal problem with a rather low performance.
But then came to the world Wireguard, and the situation has changed a lot in a positive way. Written from scratch, the protocol easily turned the veteran in performance and scalability, for which it is already included in the 5.6 kernel. And Mr. Torvalds himself hintingly hints that WireGuard will soon become the new standard. True, it works only over UDP, but this is not even a very big minus. But from the real minuses – this is the lack of mechanisms to ensure convenient routing. That is, for home use or for solving problems of the “connect two sites with two subnets” level, it is suitable, but when something large-scale is already required, there can be difficulties. And yet there is no centralized management, but I want to. But the creators directly say that they are not interested in binding around the protocol itself
In 2017, as one of the components Veeam Backup & Replication, namely Veeam Restore to Microsoft Azure, a by-product was written for the automatic organization of communication between sites and the maximum utilization of the capabilities of the communication channel. Subsequently, it will receive its unique name – Veeam PN (short for Powered Network).
To be sure that the restoration of the machines was successful and they can be used as if they are next to the others, you need to organize a VPN to them. That is, go to the car, fill in the certificates, configs, make sure that the client cannot reach the server, slap itself on the forehead, go to reconfigure the server, and so on. In a word, there are a lot of fascinating, but extremely simple automated things that there is no desire to do. Especially if all the same can be done by pressing a few buttons in the Web GUI.
And as is often the case with applications that easily and beautifully solve pressing problems, many people liked the tool and soon began to be used not only within the product framework, and not only for their original purposes. As it turned out, the purely Vimov chip about it just works in the form of Next, Next, Finish helped people organize not just the connection between home and office, but also connect networks on remote sites with clouds, not forgetting to connect a local machine.
In a word, it became clear that we need to develop the product further. But here a problem arose – using OpenVPN under the hood in the first versions, our solution could not produce the necessary level of performance, regardless of the amount of allocated CPU and other resources. The time has come for radical changes.
Veeam PN v2 with WireGuard
Now that the battles between the OpenVPN followers and WireGuard witnesses have already died down, one can confidently say that the future is in the new protocol. It works right in the kernel of the OS, improves security thanks to advanced cryptography capabilities and is much more productive. Trite, it takes 4,000 lines of code instead of 60,000 with OpenVPN.
Therefore, it was decided to introduce a novice into the product and use its capabilities to organize VPN connections between sites. According to our tests, it turned out that depending on the configuration of laboratory machines, you can get an increase in the speed of the connection from 5 to 20 times. This allows you to use it no longer just as a backup communication channel to a remote office or home lab, but as a full-fledged communication channel of several sites, with speeds of hundreds of megabits. For our purposes (transferring large amounts of data during backups and disaster recovery), the solution turned out to be simply fantastic.
But there is a nuance in WireGuard. Not a problem, but a nuance: it works over UDP. For point-to-site communication this is completely not critical, but for communication between sites it is preferable to use TCP. To solve this problem, our developers added encapsulation of WireGuard UDP traffic to TCP. Sounds cumbersome, but tests show the opposite. Yes, and we left the opportunity to choose the transport used.
But for point-to-site communications, we still use OpenVPN, but only because of its much greater prevalence on different platforms. As soon as stable client applications for all platforms appear for WireGuard, we plan its further implementation.
At the core – no matter point-to-site or site-to-site – the connections will lie Veeam PN ServerHe is a network hub. This application is an orchestrator that closes all connections and provides routing, encryption, user work, monitoring and so on. It is a small OVA image (literally 300 Mb) of a Linux machine that can be deployed on any site. And since the historical roots are in Azure, then the image is even right in the Azure Marketplace. And, of course, the AWS Marketplace is not forgotten. And for the most bored, there is an installation option right on your Ubuntu hands or using a script. There, by reference, there is a detailed documentation for all occasions.
So, download the OVA file and deploy the machine in the most usual way. After the deployment, open the IP of the new machine in the browser. If you do this fast enough, you can catch the initialization stage, which will be announced explicitly.
Then the authorization form will be displayed, where you must enter
After that, you will be prompted to immediately change the default password, because it is a sin to not do so.
And the initial setup wizard starts. According to a true tradition, everything set up at this step can be painlessly changed in the future.
Select the Network Hub and go to the step where you need to specify the name of the self-signed certificate and the level of encryption. By default, 2048 is set. And if it suits you, the generation process will start.
Then you need to specify the IP or DNS name by which our server will be available, and enable the necessary access options by selecting ports and protocols. And this is where the initial setup ends.
We are faced with a dashboard with statistics, but for now it is expectedly empty and boring, so let’s add a point-to-site client. Go to Clients> Add and select Standalone computer.
Important: by default, the client will not have access anywhere further than the appliance itself. To enable routing in local networks, you need to add clients with the Hub role for all networks where access is required. In fact, these are the virtual interfaces for which routing will be configured. Appliances in AWS and Azure do this automatically.
We give the client a name that is understandable to us, which will not raise questions in the future, decide whether to act as your default gateway or not to your hub, Next> Finish and that’s all!
Here you will also be shown a link to the latest version of the OpenVPN client and a link to download the finished config for this particular client.
Then, on the client, run the OpenVPN installer, import the downloaded config and that’s it! It is working! Simple and clear.
You do not need any certificates, crawling through the tabs with the settings and carefully squeezing thirty-three checkmarks. It just works.
We return to the dashboard, see our connection and enjoy life.
So that life doesn’t seem like honey and for the sake of honesty, I immediately warn you: we won’t be able to configure your firewall for you, as well as IP address translation. For IP translation, there is a separate tab where you must specify all the necessary transitions.
And here is another important (and possibly unpleasant nuance) – if you later change the settings of your VPN hub (IP, ports or protocols), then all client configs instantly go out, and you will need to distribute them again. So planning is our everything!
What else can be made interesting?
On the Settings> Alerts tab, there are pre-configured alerts for the most important cases in the life of any VPN: the client has joined, disconnected, a lot of CPU load and everything has broken. There are two reaction options for each event: send an email or run a script. If this is not enough, here you can make your own custom triggering options.
For site-to-site, put in a word
And what about the case if we need to organize communication between offices? Or an office and a cloud?
Here a new entity appears – site gateway. This is the same small machine that will establish a connection with your network hub and will act as a gateway for machines within the network.
In the case of several networks (or branches), you will actually build a network with a star topology, where all traffic will always be routed through the network hub.
What about DNS?
Starting from version 2.0, Veeam PN supports redirecting DNS queries. This means that clients will be able to resolve all FQDNs on all networks. To do this, the hub stores all the suffixes of the networks participating in the VPN, and through this we can resolve the names of the machines.
Under the hood, this is dnsmasq running on port 53. And the config, where the IP of the used servers get, can be found at /etc/veeampn/dns/listen_addrs.conf
Important: when using site-to-site, it is necessary to include the IP of the hub on the list of DNS resolvers on client machines. Or configure forwarding on the local DNS server. Of course, we cannot do this automatically.
Of course, if there is no need for such a function, it is disabled with a single click in the WebUI.
Use with pleasure! The solution is absolutely free.
You can download here.
All documentation lies right here.
You can discuss, criticize or express your suggestions for improvement directly with the person responsible for the product, on our forum.