The book "Linux in action"

Hello, habrozhiteli! In the book, David Clinton describes 12 real-world projects, including automating a backup and recovery system, setting up a personal Dropbox-style file cloud, and creating your own MediaWiki server. With interesting examples, you will learn about virtualization, disaster recovery, security, backup, deploying DevOps, and troubleshooting system problems. Each chapter ends with a review of practical recommendations, a glossary of new terms, and exercises.

Excerpt "10.1. Creating an OpenVPN Tunnel »

In this book, I have already talked a lot about encryption. SSH and SCP can protect data transmitted through remote connections (chapter 3), file encryption allows you to protect data when stored on the server (chapter 8), and TLS / SSL certificates can protect data during transmission between sites and client browsers (chapter 9). But sometimes your data requires protection in a wider range of connections. For example, it’s possible that some members of your team have to work on the road, connecting to the network via Wi-Fi through public access points. You should definitely not assume that all such access points are safe, but your people really need a way to connect to company resources - in which case a VPN will help.

A properly designed VPN tunnel provides a direct connection between remote clients and the server in such a way as to hide data when it is transmitted over an insecure network. So what? You have already seen many tools that can do this with encryption. The real value of a VPN is that by opening the tunnel, you can connect remote networks as if they were all together local. In a sense, you are using a bypass.
')
Using such an extended network, administrators can do their work on their servers from anywhere. But, more importantly, a company with resources distributed across several branches can make them all visible and accessible to all groups that need them, wherever they are (Fig. 10.1).

The tunnel itself does not guarantee security. But one of the encryption standards can be included in the network structure, which significantly increases the level of security. Tunnels created using the OpenVPN open source package use the same TLS / SSL encryption that you already read about. OpenVPN is not the only option available for tunneling, but one of the most famous. It is believed to be slightly faster and safer than an alternative layer 2 tunneling protocol that uses IPsec encryption.

Do you want everyone in your team to communicate safely with each other while on the road or working in different buildings? To do this, you must create an OpenVPN server to allow application sharing and access to the server’s local network environment. For this to work, it is enough to start two virtual machines or two containers: one for acting as a server / host, and the other for the client. Creating a VPN is not an easy process, so it’s probably worth spending a few minutes to get the big picture.

10.1.1. Configuring OpenVPN Server

Before you begin, I will give you useful advice. If you are going to do everything yourself (and I highly recommend it to you), you will probably find that you are working with several terminal windows open on the Desktop, each of which is connected to its machine. There is a risk that at some point you will enter the wrong command in the window. To avoid this, you can use the hostname command to change the machine name displayed on the command line to something that will clearly tell you where you are. As soon as you do this, you will need to exit the server and log in again for the new settings to take effect. Here's what it looks like:


Adhering to this approach and assigning the corresponding names to each of the machines you work with, you can easily track where you are.

After using hostname, you may encounter annoying Unable to Resolve Host OpenVPN-Server messages when you run the following commands. Updating the / etc / hosts file with the corresponding new host name should fix the problem.

Preparing Your Server for OpenVPN

Installing OpenVPN on your server requires two packages: openvpn and easy-rsa (to control the process of generating the encryption key). If necessary, CentOS users must first install the epel-release repository, as you did in chapter 2. To be able to check access to the server application, you can also install the Apache web server (apache2 for Ubuntu and httpd on CentOS).

While you are setting up the server, I advise you to activate a firewall that blocks all ports except 22 (SSH) and 1194 (the default OpenVPN port). This example illustrates how ufw will work on Ubuntu, but I'm sure you still remember the firewall CentOS program from chapter 9:

# ufw enable # ufw allow 22 # ufw allow 1194 

To allow internal routing between network interfaces on the server, you need to uncomment one line (net.ipv4.ip_forward = 1) in the /etc/sysctl.conf file. This will allow you to redirect remote clients as needed after they connect. To make the new parameter work, run sysctl -p:

 # nano /etc/sysctl.conf # sysctl -p 

Now the server environment is fully configured, but there is something else to be done before you are ready: you will have to complete the following steps (we will consider them in more detail below).

1. Create a key set on the server for encrypting the public key infrastructure (PKI) using the scripts that come with the easy-rsa package. In essence, the OpenVPN server also acts as its own certification authority (CA).
2. Prepare the appropriate keys for the client
3. Configure the server.conf file for the server
4. Configure your OpenVPN client
5. Check your VPN

Encryption Key Generation

In order not to complicate your life, you can configure your key infrastructure on the same machine where the OpenVPN server is running. However, security recommendations typically suggest using a separate CA server for deployments in a production environment. The process of generating and allocating encryption key resources for use in OpenVPN is illustrated in Fig. 10.2.


When you installed OpenVPN, the directory / etc / openvpn / was automatically created, but there is nothing in it yet. The openvpn and easy-rsa packages come with sample template files that you can use as the basis for your configuration. To start the certification process, copy the easy-rsa template directory from / usr / share / to / etc / openvpn and change to the easy-rsa / directory:

 # cp -r /usr/share/easy-rsa/ /etc/openvpn $ cd /etc/openvpn/easy-rsa 

The easy-rsa directory will now contain quite a few scripts. In the table. 10.1 lists the tools that you will use to create keys.

These operations require root authority, so through sudo su you need to become root.

The first file you will work with is called vars and contains the environment variables that easy-rsa uses when generating keys. You need to edit the file to use your own values ​​instead of the default values ​​that already exist. This is what my file will look like (Listing 10.1).

Listing 10.1. The main fragments of the file / etc / openvpn / easy-rsa / vars

 export KEY_COUNTRY="CA" export KEY_PROVINCE="ON" export KEY_CITY="Toronto" export KEY_ORG="Bootstrap IT" export KEY_EMAIL="info@bootstrap-it.com" export KEY_OU="IT" 

Running the vars file will allow you to transfer its values ​​to the shell environment, from where they will be included in the contents of your new keys. Why doesn't the sudo command alone work? Because at the first stage, we edit the script named vars, and then apply it. Application and means that the vars file transfers its values ​​to the shell environment, from where they will be included in the contents of your new keys.

Be sure to re-run the file using the new shell to complete the unfinished process. When this is done, the script will prompt you to run another script, clean-all, to remove any content in the / etc / openvpn / easy-rsa / keys / directory:


Naturally, the next step is to run the clean-all script, followed by build-ca, which uses the pkitool script to create the root certificate. You will be asked to confirm the authentication settings provided by vars:

 # ./clean-all # ./build-ca Generating a 2048 bit RSA private key 

Next comes the build-key-server script. Since it uses the same pkitool script along with the new root certificate, you will see the same questions to confirm the creation of the key pair. The keys will be given names based on the arguments you pass, which, unless you start several VPNs on this computer, will usually be server, as in the example:

 # ./build-key-server server [...] Certificate is to be certified until Aug 15 23:52:34 2027 GMT (3650 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated 

OpenVPN uses the parameters generated by the Diffie-Hellman algorithm (using build-dh) to negotiate authentication for new connections. The file created here should not be secret, but must be generated using the build-dh script for the RSA keys that are currently active. If you create new RSA keys in the future, you will also need to update the file based on the Diffie-Hellman algorithm:

 # ./build-dh 

Your server-side keys will now be in the / etc / openvpn / easy-rsa / keys / directory, but OpenVPN does not know this. By default, OpenVPN will look for keys in / etc / openvpn /, so copy them:

 # cp /etc/openvpn/easy-rsa/keys/server* /etc/openvpn # cp /etc/openvpn/easy-rsa/keys/dh2048.pem /etc/openvpn # cp /etc/openvpn/easy-rsa/keys/ca.crt /etc/openvpn 

Preparing client encryption keys

As you have already seen, TLS encryption uses pairs of corresponding keys: one is installed on the server, and the other on the remote client. This means that you will need client keys. Our old friend pkitool is exactly what you need for this. In this example, running the program in the directory / etc / openvpn / easy-rsa /, we pass the client argument to it to generate files called client.crt and client.key:

 # ./pkitool client 

The two client files, along with the original ca.crt file, which is still in the keys / directory, should now be transferred safely to your client. Due to their affiliation and access rights, this may not be so easy. The easiest approach is to manually copy the contents of the source file (and nothing but this content) to the terminal running on the desktop of your PC (select the text, right-click on it and select Copy from the menu). Then paste this into a new file with the same name that you create in the second terminal connected to your client.

But anyone can cut and paste. Instead, think as an administrator, because you will not always have access to the GUI, where a cut / paste operation is possible. Copy the files to your user's home directory (so that the remote scp operation can access them), and then use chown to change the owner of the files from root to a regular non-root user so that the remote scp action can be performed. Make sure that all of your files are currently installed and accessible. You will move them to the client a bit later:

 # cp /etc/openvpn/easy-rsa/keys/client.key /home/ubuntu/ # cp /etc/openvpn/easy-rsa/keys/ca.crt /home/ubuntu/ # cp /etc/openvpn/easy-rsa/keys/client.crt /home/ubuntu/ # chown ubuntu:ubuntu /home/ubuntu/client.key # chown ubuntu:ubuntu /home/ubuntu/client.crt # chown ubuntu:ubuntu /home/ubuntu/ca.crt 

With a complete set of encryption keys ready for action, you need to tell the server how you want to create a VPN. This is done using the server.conf file.

Reduce the number of keystrokes

Too much to print? An extension with brackets will help reduce these six commands to two. I am sure that you can study these two examples and understand what is happening. More importantly, you can understand how to apply these principles to operations involving dozens or even hundreds of elements:

 # cp /etc/openvpn/easy-rsa/keys/{ca.crt,client.{key,crt}} /home/ubuntu/ # chown ubuntu:ubuntu /home/ubuntu/{ca.crt,client.{key,crt}} 

Setting up the server.conf file

How can you know what the server.conf file should look like? Remember the easy-rsa directory template that you copied from / usr / share /? When installing OpenVPN, a compressed configuration template file remained, which you can copy to / etc / openvpn /. I will build on the fact that the template has been archived and introduce you to a useful tool: zcat.

You already know about displaying the text content of a file using the cat command, but what if the file is compressed using gzip? You can always unzip the file, and then cat will gladly display it, but this is one or two steps more than necessary. Instead, as you probably already guessed, you can enter the zcat command to load the unpacked text into memory in one step. In the following example, instead of printing text on the screen, you redirect it to a new file called server.conf:

 # zcat \ /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz \ > /etc/openvpn/server.conf $ cd /etc/openvpn 

We leave aside the extensive and useful documentation that came with the file and see how it might look when you finish editing. Note that the semicolon (;) tells OpenVPN not to read or execute the next line (Listing 10.2).


Let's go through some of these settings.

• By default, OpenVPN works through port 1194. You can change this, for example, to hide your actions even more or to avoid conflicts with other active tunnels. Since 1194 requires minimal coordination with customers, this is best done.
• OpenVPN uses either the Transmission Control Protocol (TCP) or the User Datagram Protocol (UDP) for data transfer. TCP may be a bit slower, but it is more reliable and more likely to be understood by applications running on both ends of the tunnel.
• You can tell dev tun when you want to create a simpler and more efficient IP tunnel that transmits data contents and nothing more. If, on the other hand, you need to connect several network interfaces (and the networks that they represent) by creating an Ethernet bridge, you will have to select dev tap. If you do not understand what all this means, use the tun argument.
• The next four lines pass the OpenVPN names of the three authentication files on the server and the dh2048 settings file that you created earlier.
• The server line sets the range and subnet mask that will be used to assign IP addresses to clients upon login.
• The optional push parameter “route 10.0.3.0 255.255.255.0” allows remote clients to access private subnets behind the server. To perform this work, you also need to configure the network on the server itself, so that the private subnet knows about the OpenVPN subnet (10.8.0.0).
• The line port-share localhost 80 allows you to redirect client traffic coming through port 1194 to the local web server listening on port 80. (It will be useful if you intend to use the web server to test your VPN.) This only works if when tcp protocol is selected.
• The user nobody and group nogroup lines must be active - to do this, delete the semicolons (;). Forcing remote clients to work under nobody and nogroup ensures that sessions on the server are unprivileged.
• log indicates that current log entries will overwrite old entries each time OpenVPN starts, while log-append adds new entries to an existing log file. The openvpn.log file itself is written to the / etc / openvpn / directory.

In addition, the client-to-client value is also often added to the configuration file so that several clients can see each other in addition to the OpenVPN server. If you are satisfied with your configuration, then you can start the OpenVPN server:

 # systemctl start openvpn 

Due to the changing nature of the relationship between OpenVPN and systemd, the following syntax may sometimes be required to start a service: systemctl start openvpn @ server.

Running ip addr to display the list of network interfaces of your server should now display a link to a new interface named tun0. OpenVPN will create it to serve incoming clients:

 $ ip addr [...] 4: tun0: mtu 1500 qdisc [...] link/none inet 10.8.0.1 peer 10.8.0.2/32 scope global tun0 valid_lft forever preferred_lft forever 

You may need to restart the server before everything starts working completely. The next stop is the client computer.

10.1.2. OpenVPN Client Configuration

Traditionally, tunnels are built with at least two exits (otherwise we would call them caves). A properly configured OpenVPN on the server directs traffic to and from the tunnel on the one hand. But you also need some kind of client-side software, that is, on the other end of the tunnel.

In this section, I am going to focus on manually configuring a Linux computer of one type or another to work as an OpenVPN client. But this is not the only way in which such an opportunity is available. OpenVPN supports client applications that can be installed and used on desktop computers and laptops with Windows or macOS, as well as on smartphones and tablets based on Android and iOS. See openvpn.net for details.

The OpenVPN package will need to be installed on the client computer, as it was installed on the server, although there is no need for easy-rsa, since the keys you use already exist. You need to copy the client.conf template file to the / etc / openvpn / directory that you just created. This time the file will not be archived, so the regular cp command will do this task perfectly:

 # apt install openvpn # cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf \ /etc/openvpn/ 

Most of the settings in your client.conf file will be pretty straightforward: they should match the values ​​on the server. As you can see from the following sample file, the unique parameter is remote 192.168.1.23 1194, which tells the client the IP address of the server. Again, make sure this is the address of your server. You must also force the client computer to authenticate the server certificate to prevent a possible man-in-the-middle attack. One way to do this is to add the line remote-cert-tls server (Listing 10.3).


Now you can go to the / etc / openvpn / directory and extract the certification keys from the server. Replace the server IP address or domain name in the example with your values:


Nothing exciting is likely to happen until you run OpenVPN on the client. Since you need to pass a couple of arguments, you will do it from the command line. The --tls-client argument tells OpenVPN that you will act as a client and connect using TLS encryption, and --config points to your configuration file:

 # openvpn --tls-client --config /etc/openvpn/client.conf 

Carefully read the output of the command to make sure that you are connected correctly. If for the first time something goes wrong, it may be due to a mismatch between the settings between the server and client configuration files or a network connection / firewall problem. Here are some troubleshooting tips.

• Carefully read the output of the OpenVPN operation on the client. It often contains valuable advice on what exactly cannot be performed and why.
• Check the error messages in the openvpn.log and openvpn-status.log files in the / etc / openvpn / directory on the server.
• Check OpenVPN-related and time-appropriate messages in the system logs on the server and client. (journalctl -ce will display the most recent entries.)
• Make sure you have an active network connection between the server and the client (for more details, see chapter 14).

about the author

David Clinton is a system administrator, teacher and writer. He administered, wrote about it and created training materials for many important technical disciplines, including Linux systems, cloud computing (in particular AWS) and container technologies such as Docker. He wrote the book Learn Amazon Web Services in a Month of Lunches (Manning, 2017). Many of his video tutorials can be found on Pluralsight.com, and links to his other books (on Linux administration and server virtualization) are available at bootstrap-it.com .

»More details on the book can be found on the publisher’s website
» Contents
» Excerpt

25% off coupon for hawkers - Linux
Upon payment of the paper version of the book, an electronic book is sent by e-mail.