🥇Linux in action book

Hello Habrites! In the book, David Clinton describes 12 real-life projects, including automating a backup and restore system, setting up a Dropbox-style personal file cloud, and building your own MediaWiki server. Use interesting case studies to learn about virtualization, disaster recovery, security, backup, DevOps implementation, and system troubleshooting. Each chapter ends with an overview of practical advice, 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 in transit over remote connections (Chapter 3), file encryption can protect data while it is stored on the server (Chapter 8), and TLS/SSL certificates can protect data in transit between sites and client browsers (Chapter 9). But sometimes your data needs to be protected across a wider range of connections. For example, maybe some of your team members have to work on the road, connecting to a Wi-Fi network through public hotspots. You definitely shouldn't assume that all these hotspots are secure, 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 a server in a way that hides data as it travels 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 a tunnel, you can connect remote networks as if they were all local networks together. In a sense, you are using a bypass.

With this extended network, administrators can do their work on their servers from anywhere. But more importantly, a company with resources spread across multiple locations can make them all visible and available to all the groups that need them, no matter where they are (Figure 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 open source OpenVPN package use the same TLS/SSL encryption that you have already read about. OpenVPN is not the only tunneling option available, but one of the most well-known. It is considered to be slightly faster and more secure than the alternative layer 2 tunneling protocol using IPsec encryption.

Do you want everyone on your team to communicate securely with each other while on the road or working in different buildings? To do this, you need to 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 run two virtual machines or two containers: one for the role of the server / host, and the other for the client. Building a VPN is not an easy process, so it's probably worth taking a few minutes to get the big picture.

10.1.1. Configuring the OpenVPN Server

Before we get started, I'll give you some helpful advice. If you're going to do it yourself (and I strongly recommend that you do), you'll probably find yourself working with multiple terminal windows open on your desktop, each connected to a different machine. There is a risk that at some point you will enter the wrong command into the window. To avoid this, you can use the hostname command to change the machine name displayed on the command line to something that clearly tells you where you are. Once you do this, you will need to log out of the server and log back in for the new settings to take effect. Here's what it looks like:

By following this approach and giving appropriate names to each of the machines you work with, you can easily keep track of where you are.

After using hostname, you may encounter annoying Unable to Resolve Host OpenVPN-Server messages when you run subsequent commands. Updating the /etc/hosts file with the appropriate new hostname should resolve the issue.

Preparing your server for OpenVPN

Installing OpenVPN on your server requires two packages: openvpn and easy-rsa (to manage the encryption key generation process). CentOS users should optionally first install the epel-release repository, as you did in Chapter 2. To be able to test access to the server application, you can also install the Apache web server (apache2 on 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 would work on Ubuntu, but I'm sure you still remember the CentOS firewalld program from Chapter 9:

# ufw enable
# ufw allow 22
# ufw allow 1194

To enable 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 remote clients to be redirected as needed after they connect. To make the new setting work, run sysctl -p:

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

Now the server environment is fully configured, but there is one more thing to do before you are ready: you will need to complete the following steps (we will go over them in detail later).

Create a public key infrastructure (PKI) encryption keyring on the server using the scripts provided with the easy-rsa package. Essentially, the OpenVPN server also acts as its own certificate authority (CA).
Prepare the appropriate keys for the client
Configure the server.conf file for the server
Set up your OpenVPN client
Check Your VPN

Encryption Key Generation

To keep things simple, you can set up your key infrastructure on the same machine where the OpenVPN server is running. However, security best practices generally suggest using a separate CA server for production deployments. The process of generating and distributing encryption key resources for use in OpenVPN is illustrated in Figure 10.2. XNUMX.

When you installed OpenVPN, the /etc/openvpn/ directory 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 table. 10.1 lists the tools you will use to generate keys.

The above operations require root privileges, so you need to become root via sudo su.

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 defaults that are already there. Here is what my file will look like (Listing 10.1).

Listing 10.1. 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="[email protected]"
export KEY_OU="IT"

Running the vars file will allow its values to be passed to the shell environment, from where they will be included in the contents of your new keys. Why doesn't the sudo command by itself work? Because in the first step we edit the script called vars and then we apply it. Applying and means that the vars file passes its values to the shell environment, from where they will be included in the contents of your new keys.

Be sure to run the file again using a new shell to end the pending 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 generate the root certificate. You will be asked to confirm the identity 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 a new root certificate, you will see the same questions to confirm key pair creation. The keys will be named based on the arguments you pass in, which, unless you're running multiple VPNs on this machine, will typically 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 Diffie-Hellman generated parameters (using build-dh) to negotiate authentication for new connections. The file created here does not need to 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 end up in the /etc/openvpn/easy-rsa/keys/ directory, but OpenVPN doesn't 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 matching key pairs: one 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 we need for this. In this example, when we run the program in the /etc/openvpn/easy-rsa/ directory, we pass it the client argument to generate files called client.crt and client.key:

# ./pkitool client

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

But anyone can cut and paste. Instead, think like an administrator because you won't always have access to a 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 ownership of the files from root to a regular non-root user so that the remote scp action can be performed. Make sure all your files are currently installed and available. You will move them to the client a little 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 full set of encryption keys ready to go, you need to tell the server how you want to create the VPN. This is done using the server.conf file.

Reducing the number of keystrokes

Too much to type? Bracket expansion will help reduce these six commands to just two. I'm sure you can study these two examples and understand what's going on. More importantly, you will be able to 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}}

Configuring the server.conf file

How can you know what the server.conf file should look like? Remember the easy-rsa directory template you copied from /usr/share/? The OpenVPN installation left a compressed configuration template file that you can copy to /etc/openvpn/. I'll build on the fact that the template is zipped and introduce you to a useful tool: zcat.

You already know about printing the text content of a file to the screen with the cat command, but what if the file is compressed with gzip? You can always decompress the file and cat will happily print it out, but that's one or two steps too long. Instead, as you may have guessed, you can type the zcat command to load the decompressed text into memory in one step. In the following example, instead of printing the text on the screen, you will redirect it to a new file named server.conf:

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

Let's leave aside the extensive and helpful documentation that comes with the file and see what it might look like when you're done editing. Note that the semicolon (;) tells OpenVPN not to read or execute the following line (Listing 10.2-XNUMX).

Let's go through some of these settings.

By default, OpenVPN works on port 1194. You can change this, for example, to further hide your actions or avoid conflicts with other active tunnels. Since 1194 requires minimal coordination with clients, this is the best way to do it.
OpenVPN uses either Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) to transfer data. TCP may be slightly slower, but it is more reliable and more likely to be understood by applications running on both ends of the tunnel.
You can specify dev tun when you want to create a simpler and more efficient IP tunnel that transfers the content of the data and nothing else. If, on the other hand, you need to connect multiple network interfaces (and the networks they represent) by creating an Ethernet bridge, you will have to select dev tap. If you don't understand what all this means, use the tun argument.
The next four lines give OpenVPN the names of the three authentication files on the server and the dh2048 parameter file you created earlier.
The server line sets the range and subnet mask that will be used to assign IP addresses to clients at login.
The optional push parameter "route 10.0.3.0 255.255.255.0" allows remote clients to access private subnets behind the server. Making this work also requires a network setup on the server itself so that the private subnet is aware of the OpenVPN subnet (10.8.0.0).
The line port-share localhost 80 allows you to redirect client traffic on port 1194 to a local web server listening on port 80. (This will be useful if you are going to use a web server to test your VPN.) This only works then when tcp protocol is selected.
The user nobody and group nogroup lines must be active by removing the semicolons (;). Forcing remote clients to run as nobody and nogroup ensures that sessions on the server are unprivileged.
log specifies that current log entries will overwrite old entries each time OpenVPN is started, while log-append appends new entries to an existing log file. The openvpn.log file itself is written to the /etc/openvpn/ directory.

In addition, it is also common to add a client-to-client value to the configuration file so that multiple 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, starting a service may sometimes require the following syntax: systemctl start openvpn@server.

Running ip addr to list your server's network interfaces should now list 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 is fully operational. The next stop is the client computer.

10.1.2. Configuring the OpenVPN Client

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

In this section, I'm going to focus on manually configuring a Linux machine of one type or another to act as an OpenVPN client. But that's not the only way this feature is available. OpenVPN supports client applications that can be installed and used on Windows or macOS desktops and laptops, as well as Android and iOS smartphones and tablets. See openvpn.net for details.

The OpenVPN package will need to be installed on the client machine as it was installed on the server, although there is no need for easy-rsa here as the keys you use already exist. You need to copy the client.conf template file to the /etc/openvpn/ directory that has just been created. This time the file will not be zipped, so the usual cp command will do the job just fine:

# 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 self-explanatory: 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 your server address. You should also force the client computer to authenticate the server's 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-XNUMX).

Now you can go to the /etc/openvpn/ directory and extract the certificate keys from the server. Replace the server IP address or domain name in the example with your own 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 via TLS encryption, while --config points to your configuration file:

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

Read the output of the command carefully to make sure you are properly connected. If something goes wrong the first time, it might be due to a mismatch between the server and client configuration files, or a network connection/firewall issue. Here are some tips on how to troubleshoot.

Read the output of the OpenVPN operation on the client carefully. It often contains valuable advice on exactly what cannot be done and why.
Check for error messages in the openvpn.log and openvpn-status.log files in the /etc/openvpn/ directory on the server.
Check the OpenVPN related and timely 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 (see Chapter 14 for more details).

About the Developer

David Clinton is a system administrator, teacher and writer. He has administered, written about, and created tutorials for many important technical disciplines, including Linux systems, cloud computing (particularly 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 at Pluralsight.com, and links to his other books (on Linux administration and server virtualization) are available at bootstrap-it.com.

» For more information about the book, please visit publisher's website
» Table of contents
» excerpt

For Habitants, a 25% discount on a coupon - Linux
Upon payment of the paper version of the book, an e-book is sent to the e-mail.

Source: habr.com

Linux in Action book