Who needs VPN?

As of March 2017, the share of vacancies on work with remote access posted on hh.ru was 1.5% or 13,339 vacancies. During the year their number doubled . In 2014, the number of remote employees was estimated at 600 thousand people or 1% of the economically active population (15–69 years). J'son & Partners Consulting predicts that by 2018, about 20% of all employed Russians will work remotely. For example, by the end of 2017, Beeline plans to transfer from 50% to 70% of staff to remote cooperation.

Why do companies transfer employees to the remote:

• Reducing the cost of the company for the rental and maintenance of jobs.
• The lack of binding to one location makes it possible to assemble a team
  a project that could never be put together within the same city. An additional plus is the possibility of using cheaper labor.
• Satisfying the needs of employees due to their family circumstances.

We discovered the need for VPN more than 10 years ago. For us, the motivator of providing VPN access to employees was the ability to quickly access the corporate network from anywhere in the world and at any time of the day or night.

The way to choose the perfect VPN solution

There are a lot of solutions. Often, the decision should be made on the basis of what equipment and software is already used in the company, the skill of setting which software the system administrator has. I'll start with what we gave up right away, and then tell you what we tried at what we eventually stopped at.

VPN in routers

There are many so-called “Chinese solutions” on the market. Virtually any router has the functionality of a built-in VPN server. This is usually a simple on / off functionality and adding usernames of passwords for users, sometimes integration with the Radius server. Why we did not begin to consider such a decision? First of all, we think about our security and continuity of the service. Similar glands cannot boast of any reliable protection (firmwares are usually very rarely released, or do not come out in principle), and the reliability of work leaves much to be desired.

VPN Enterprise Class

If you look at the Gartner square, then the VPN market has long been a leader among companies that produce network equipment. Juniper, Cisco, Check Point: they all have integrated solutions, which include a VPN service.

There are probably two disadvantages to such decisions. First and foremost - the high cost. Second, the speed of closing vulnerabilities leaves much to be desired, and if you do not pay annual support fees, then you should not wait for security updates. Not so long ago, the third moment appeared - bookmarks embedded in the software of large network vendors.

Microsoft VPN

10 years ago we were a company focused primarily on Windows. Microsoft offers a free solution for those who have the entire infrastructure built on their base. In simple cases, setting up does not cause difficulties even for a novice system administrator. In our case, we wanted to squeeze everything out of the VPN from a security point of view; accordingly, the use of passwords was excluded. We naturally wanted to use certificates instead of passwords and use our Rutoken EDS product to store the key pair. To implement the project, we needed: a domain controller, a radius server, and a properly raised and configured PKI infrastructure. I will not dwell on the settings in detail, there is a lot of information on these issues on the Internet, and the correct setting of the PKI can generally pull a dozen articles. The first protocol we used was PPTP. For a long time, this VPN option suited us, but in the end we had to abandon it for two reasons: PPTP did not work everywhere and we started using not only Windows, but other operating systems as well. Therefore, we began to look for alternatives. I note that the support for PPTP was recently stopped by apple . To begin, we decided to see what else the protocols can offer to Microsoft. SSTP / L2TP. SSTP suited us all, except that it worked only on Windows. L2TP did not have this drawback, but it seemed quite costly to set up and maintain it in our work, and we decided to try alternatives. I wanted a simpler solution for both users and administrators.

Openvpn

We at Aktiv sincerely love open source. Choosing a replacement for Microsoft VPN, we could not ignore the OpenVPN solution. The main advantage for us was that the out-of-the-box solution works on all platforms. To raise the server in a simple case is quite simple. Now, using docker and, for example, a ready image , it can be done in a few minutes. But we wanted more. We wanted to add Microsoft CA integration to the project in order to use the certificates issued earlier. We wanted to add support for the tokens we used. How to configure a bunch of OpenVPN and tokens described for example here in this article . It was more difficult to configure the integration of Microsoft CA and OpenVPN, but in general it is also quite realizable. We used the resulting solution for about three years, but all the while we continued to look for more convenient options. The main opportunity we got by going to OpenVPN was access from any OS. But there are still two complaints: the company’s employees need to go through 7 laps of the Microsoft CA hell to issue a certificate, and the administrators still had to maintain a fairly complex VPN infrastructure.

Rutoken VPN

We have knowledge of how to use tokens in any operating systems, we have an understanding of how to properly prepare the PKI infrastructure, we are able to configure different versions of OpenVPN, and we have technologies that allow you to manage all this convenient for the user from the browser window. So the idea of ​​a new product appeared.

Configure Rutoken VPN

We really tried to make the setting easy and understandable. The entire setup takes only a few minutes and is implemented as an initial setup wizard. In the first step, you need to configure the network settings of the device, I think the comments here will be superfluous.

In the second step, you need to enter the company name and wait a few minutes while the device configures the built-in certification authority.

The third step is to configure the VPN service itself. Specify the external IP to connect to. Select the type of encryption and network addressing.

The fourth step is to create local users, or add them from AD

At this setting can be considered complete, all other actions can be performed by the employee himself (although the administrator can do everything).

Personal account of the employee

After the administrator has added users, the employee can use the self-service portal.

Depending on the employee’s operating system and browser, you will need to install the plugin and browser extension, which are necessary for working with tokens.

After installing the plug-in / extension, we can only generate a certificate for ourselves on the Rutoken EDS.

And install the client under the desired operating system:

How does all this work?

A little about the hardware. Initially, we thought for a long time what “base” to use for our solution, since it was necessary to keep a balance between cost, convenience, performance. After researching what is offered on the market, we stopped at two options for the implementation and further distribution of the solution:

• x86 (Enterprise) is a software solution that is provided to the end user in the form of an image of a virtual machine that can be deployed within its IT infrastructure.

• Raspberry Pi is already a fairly well-known microcomputer, which has quite good performance at not the highest cost and which can be started to use as a VPN server within 10 minutes after it was literally taken out of the box.

So now let's look at how our solution works. Initially, I want to remind you that we have implemented two-factor authentication. Own-produced tokens are used as carriers of client private keys and certificates, as well as software for working with them.

But initially, we still need to configure the services that are required for the correct operation of the product. The services are currently configured by the specialists of our company in a semi-automatic mode. This means that the process of deployment of software and initial settings is automated, but the initialization of this process is still a human privilege. During the initial configuration, the system packages, python, django, OpenVPN, supervisor, OpenSSL, etc. are installed.

And what next? Next, you need to configure the entire infrastructure, which is actually responsible for the overall security. Namely: CA (certificate authority), PKI (public key infrastructure), write out the necessary keys and certificates.

The creation of PKI and CA, as well as the formation of the configuration file of the OpenVPN server, the generation of keys and the issuance of certificates is carried out after the transfer of the product to the client. But this does not mean that for this you need to have some specific knowledge and direct access to the operating system. Everything is implemented in the back end business logic of the administration system, access to which is provided via the Web interface. The client is only required to enter the minimum set of attributes (described above), after which the process of initializing the PKI and creating the CA starts. It makes no sense to describe the specific calls of the system commands, since everything has long been described and chewed up to us. The main thing that we did was to automate this process, freeing the user from having to have specific administrative knowledge.

To work with keys and certificates, we decided not to reinvent the wheel (although we really wanted and still have the idea to invent it based on our future product development plans) and use easy-rsa.

The longest process in setting up the infrastructure is the generation of the Diffie-Hellman file. We experimented with the parameters for a long time and came to the balance of "quality-performance". Although there were thoughts to get rid of this step altogether, to generate such files in advance, using our server capacities and simply “distribute” them during the initial initialization. Moreover, the data contained in this file are not private. But so far we have left these thoughts for further “research.”

Next, you need to provide the end user with a mechanism for self-creation of key pairs, making requests for issuing a certificate to CA and actually receiving this certificate with a record on a token. A client is also needed to establish a VPN connection with pre-authentication on a token.

We solved the first task thanks to our plug-in that implements the functionality of electronic signature, encryption and two-factor authentication for Web and SaaS services. In order to write out the certificate and write it to the token, the user must install this plugin, follow the link to get into the personal account of the RutokenVPN service, having previously connected the token to the computer (read more about the plugin on our resource )

When initializing the process of issuing a certificate, a request is made for a token to generate a key pair as well as a request for a certificate to be issued to CA. The private key is written to the token, and a certificate statement request is sent to the CA, which in turn writes it out and returns it in the response. After that, the certificate is also written to the token.

Almost everything is ready to establish a VPN connection. There is a lack of a client who “knows” how to work with the server and our tokens.

Our client is implemented on Electron. Who does not know what kind of animal, then, if very briefly - the ability to implement a desktop application using js, css and html. Without going into details, the client is a kind of “wrapper” over the OpenVPN client, allowing it to make calls with the necessary parameters. Why so? In fact, it was more convenient for us, although the chosen solution imposes certain limitations.

Since we use the token as the key information carrier required for authentication when establishing a VPN session, we need to configure the OpenVPN client to work with it. The PKCS # 11 provider is a proprietary library for working with our tokens, the path to which is specified in the settings of the OpenVPN client. Read more about it here .

When a request is made to establish a VPN connection, the PIN code of the key is requested, if entered correctly, a certificate is extracted for client authentication, the client is handed down to the server and the VPN connection is established. Knowledgeable people may argue that not everything is so simple, but the purpose of this description is not to tell all the subtleties of the work of OpenVPN, but only to highlight the main points of our implementation.

A little about our plans. The main thing we are working on now is the implementation of GOST-encryption. A rather large research path has already been passed, which allowed us to come as close as possible to its implementation. In the near future we will be able to satisfy the interest of potential customers in this functionality.