Як захистити мережеві підключення за допомогою OpenVPN

Вони говорять нам, що ми живемо у гіпермобільному світі. Не те, що б я знав: я рідко виходжу з домашнього офісу. Але, звичайно, я насолоджуюсь лише зручностями свого домашнього офісу, оскільки всі серверні ресурси, які мені могли б знадобитися, доступні віддалено.

Мабуть, я не одна. Майже кожен, чия робота стосується ІТ, час від часу отримуватиме доступ до своїх професійних інструментів з віддалених місць. А враховуючи те, що загальнодоступні мережі, через які ви отримуєте доступ до цих віддалених місць, за своєю природою небезпечні, ви захочете ретельно контролювати ці зв’язки.

Шифрування веб-сайту полягає в тому, щоб переконатися, що дані, що споживаються вашими віддаленими клієнтами, надійно передаються і невидимі для всіх, хто може ховатися в підключній мережі. VPN, завдяки різкій контрастності, зосереджуються на тому, щоб дані, що споживаються вашими віддаленими клієнтами, були надійно передані та невидимі для тих, хто може ховатися в підключній мережі. Ви бачите різницю? Як і я.

Насправді існують всі види технологій, присвячених захисту мережевого зв'язку, і принцип _захисту в глибині_ вчить нас, що ніколи не слід покладатися лише на одну. Ось тут ви дізнаєтесь про додавання нових шарів захисту для віддалених дій. Зокрема, використання шифрування для побудови тунелю віртуальної приватної мережі (VPN) для забезпечення безпечних і невидимих ​​віддалених з'єднань.

Побудова тунелю OpenVPN

У моїй книзі про Linux у дії - з якої витягнута ця стаття - багато розповідається про шифрування. SSH і SCP можуть захищати дані, передані за допомогою віддалених з'єднань (глава 3), шифрування файлів - дані, що перебувають у стані спокою (глава 8), а сертифікати TLS / SSL можуть захищати дані, що передаються між веб-сайтами та клієнтськими браузерами (глава 9). Але іноді ваші вимоги вимагають захисту у більш широкому діапазоні зв’язків, оскільки іноді у вас є різні види роботи.

F'instance? Деяким членам вашої команди потрібно працювати з дороги, використовуючи загальнодоступні точки доступу WiFi. Безумовно, не розумно вважати, що випадкові точки доступу WiFi є безпечними, але вашим людям потрібен спосіб зв’язку з ресурсами компанії. VPN на допомогу.

Правильно розроблений тунель VPN забезпечує прямий зв’язок між віддаленими клієнтами та сервером таким чином, що приховує дані під час їх передачі через незахищену мережу. Але що? Ви вже бачили безліч інструментів, які можуть це зробити за допомогою шифрування. Справжнє значення VPN полягає в тому, що як тільки ви відкрили тунель, можна підключати віддалені мережі так, ніби вони всі разом локально. У певному сенсі ви обійдете цю гарячу точку кав’ярні.

Використовуючи таку розширену мережу, адміністратори можуть виконувати свою роботу на своїх серверах незалежно від того, де вони можуть опинитися. Але що ще важливіше, як ви можете бачити на малюнку, компанія з ресурсами, розподіленими по декількох філіях, може зробити їх як видимими, так і доступними для всіх команд, які вони потребують ... де б вони не знаходились.

Одне лише існування тунелю не гарантує безпеки. Але один із ряду стандартів шифрування може бути включений у дизайн, що робить речі набагато кращими. У тунелях, побудованих із пакетом OpenVPN з відкритим кодом, використовується те саме шифрування TLS / SSL, яке ви вже бачили в інших місцях. OpenVPN - не єдиний доступний вибір для тунелювання, але він є одним з найвідоміших, і вважається, що він є дещо швидшим і, ймовірно, більш безпечним, ніж альтернативний протокол тунелю рівня 2 із використанням шифрування IPsec.

Щоб ваша команда могла безпечно зв’язуватися між собою з дороги або між кількома кампусами, ви збираєтеся створити сервер OpenVPN, щоб дозволити спільний доступ як до програм, так і до доступу до локального мережевого середовища сервера. Щоб це працювало, достатньо запустити дві віртуальні машини або контейнери. Один грати роль сервера / хоста, а інший - клієнта.

Створення VPN передбачає чимало кроків, тому витратити кілька хвилин, щоб подумати про загальну картину того, як це буде працювати, можливо, варто.

Налаштування сервера OpenVPN

Перед початком роботи, ось корисна порада. Якщо ви збираєтеся продовжувати цей процес самостійно - і я настійно рекомендую вам це зробити, - ви, мабуть, опинитесь у роботі з декількома вікнами терміналів, відкритими на вашому робочому столі, кожен з яких входить в іншу машину. Візьміть це від мене: в якийсь момент ви збираєтеся ввести команду в неправильне вікно і повністю зіпсувати своє середовище.

Ви можете використовувати команду hostname, щоб змінити ім'я машини, що відображається в командному рядку, на щось, що візуально нагадуватиме вам, де ви знаходитесь. Після цього вам потрібно буде вийти з сервера та ввійти знову, щоб нова настройка набула чинності.

[email protected]:~# hostname OpenVPN-Server [email protected]:~$ exit $ ssh [email protected] [email protected]:~# 

Дотримання цього підходу для присвоєння відповідних імен кожній машині, з якою ви працюєте, має допомогти вам відстежувати, де ви перебуваєте.

Підготуйте свій сервер до OpenVPN

Для встановлення OpenVPN на вашому сервері потрібні два пакети: openvpn і, щоб керувати процесом генерації ключа шифрування, easy-rsa. Користувачам CentOS слід, за необхідності, спочатку встановити сховище epel-release так, як це було зроблено у розділі 2. Щоб дати вам простий спосіб перевірити доступ до серверної програми, ви також можете встановити веб-сервер Apache (apache2 для Ubuntu та httpd на CentOS).

Поки ви налаштовуєте свій сервер, ви могли б зробити це правильно і активувати брандмауер, який блокує всі порти, крім 22 (SSH) та 1194 (порт OpenVPN за замовчуванням). Цей приклад ілюструє спосіб роботи на ufw Ubuntu, але я впевнений, ви все ще пам’ятаєте брандмауер CentOS з розділу 9.

ufw enable ufw allow 22 ufw allow 1194

Щоб дозволити внутрішню маршрутизацію між мережевими інтерфейсами на сервері, вам потрібно прокоментувати один рядок (net.ipv4.ip_forward = 1) у файлі /etc/sysctl.conf. Це дозволить віддаленим клієнтам перенаправлятись у міру необхідності після їх підключення. Щоб завантажити нову настройку, запустіть sysctl -p.

nano /etc/sysctl.conf sysctl -p

Зараз серверне середовище налаштовано, але є ще один шлях, перш ніж ви будете готові переключити перемикач.

Створення ключів шифрування

Коли ви встановили OpenVPN, каталог / etc / openvpn / був автоматично створений, але в ньому поки що немає багато. Однак як пакети openvpn, так і easy-rsa мають зразки файлів шаблонів, які ви можете використовувати як основу для своєї конфігурації. Щоб розпочати процес сертифікації, скопіюйте каталог шаблону easy-rsa з / usr / share / в / etc / openvpn /, а потім перейдіть на новий каталог easy-rsa /.

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

Перший файл, з яким ви будете працювати, називається просто vars і містить змінні середовища, які easy-rsa використовуватиме, коли генерує свої ключі. Ви захочете відредагувати файл, щоб замінити ваші власні значення типовими типовими значеннями, які вже є. Ось як виглядатиме мій файл:

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”

Запуск файлу vars передасть його значення в середовище оболонки, звідки вони будуть включені до вмісту ваших нових ключів. Коли це буде зроблено, сценарій запропонує вам запустити скрипт очищення всіх для видалення будь-якого наявного вмісту в каталозі / etc / openvpn / easy-rsa / keys /.

cd /etc/openvpn/easy-rsa/ . ./vars NOTE: If you run ./clean-all, I will be doing a rm -rf on /etc/openvpn/easy-rsa/keys

Звичайно, наступним вашим кроком буде запуск цього чистого сценарію ... з подальшим build-ca, який використовуватиме скрипт pkitool для створення вашого кореневого сертифіката. Вас попросять підтвердити налаштування ідентифікації, надані vars.

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

Next, the build-key-server script, since it uses the same pkitool script along with the new root certificate, will ask you the same confirmation questions to generate a key pair. The keys will be given names based on the argument you pass — which, unless you’re running multiple VPNs on this machine, would normally be server, as in this 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 will use parameters generated using the Diffie-Hellman algorithm (by running build-dh) to negotiate authentication for new connections. The file that will be created here does not need to remain secret, but must have been generated using the build-dh script against the RSA keys that are currently active. If you create new RSA keys at some time in the future, you’ll also need to update the Diffie-Hellman file.

build-dh

Your server-side keys will now have been written to the /etc/openvpn/easy-rsa/keys/ directory, but OpenVPN doesn’t know that. By default OpenVPN will lookfor them in /etc/openvpn/, so copy them over.

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

Prepare client encryption keys

As you’ve already seen, TLS encryption uses matching key pairs, one installed on the server and the other on a remote client. That means you’re going to need client keys, and our old friend pkitool is just the thing to cook some up. This example, run while still in the /etc/openvpn/easy-rsa/ directory, passes client as an argument to generate files called client.crt and client.key.

./pkitool client

The two client files, along with the original ca.crt file that’s still in the keys/ directory, will now have to be securely transferred to your client. Because of their ownership and permissions, this might be a bit complicated. The simplest approach is to manually copy the contents of the source file (and nothing but those contents) in a terminal running on your PC’s desktop (by highlighting the text, right-clicking over it, and selecting copy from the menu) and then pasting it into a new file of the same name you create in a second terminal logged into your client.

But anyone can cut and paste. Instead, think like an admin — especially since you won’t always have access to a GUI where cutting and pasting is possible. Instead, copy the files to your user’s home directory (so a remote scp operation can access them) and then use chown to change the ownership of the files from root to your regular, non-root user so that remote scp action can work. Make sure your files are all settled and comfy for now…you’ll move them over 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 full set of encryption keys ready for action, you’ll need to tell your server how you want to build your VPN. That’s done using the server.conf file.

Configure server.conf file

How are you supposed to know what the server.conf file should look like? Well, remember the easy-rsa directory template you copied over from /usr/share/? Well there are more goodies where that came from. The OpenVPN installation left a compressed template configuration file which you can copy over to /etc/openvpn/.

I’ll use the fact that the template is compressed to introduce you to a useful tool: zcat. You’re already know about printing a file’s text contents to the screen with cat, but what if the file is compressed using gzip? Of course, you could always decompress the file and cat will then be happy to print it, but that’s one or two steps too many. Instead, as you’ve probably already guessed, you can use zcat to load the decompressed text into memory all in one step. In our case, rather than print it to the screen, you’ll redirect the text 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

Leaving out the extensive and helpful documentation that comes with the file, here’s how it might look once you’re done editing. Note that a semicolon (;) tells OpenVPN _not_ to read and execute the line that follows.

port 1194 # TCP or UDP server? proto tcp ;proto udp ;dev tap dev tun ca ca.crt cert server.crt key server.key # This file should be kept secret dh dh2048.pem server 10.8.0.0 255.255.255.0 ifconfig-pool-persist ipp.txt push “route 10.0.3.0 255.255.255.0” keepalive 10 120 comp-lzo port-share localhost 80 user nobody group nogroup persist-key persist-tun status openvpn-status.log log openvpn.log ;log-append openvpn.log verb 3 

Let’s work through some of those one at a time.

  • By default, OpenVPN works over port 1194. You can change that — perhaps to further obscure your activities, or avoid conflicts with other active tunnels. But, because it will require the least coordination between clients, 1194 is normally your best choice.
  • OpenVPN can use either the Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) for data transmissions. TCP might be a little bit slower, but it’s more reliable and more likely to get along with applications running at either end of the tunnel.
  • You specify dev tun when you want to create a simpler and more efficient IP tunnel that transfers data content and nothing much else. If, on the other hand, you’ll need to connect multiple network interfaces (and the networks they represent) by creating an _ethernet bridge_, then you’ll have to select dev tap. If you haven’t a clue what all that means, go with tun.
  • The next four lines pass OpenVPN the names of the three server authentication files and the dh2048 parameters file you created earlier.
  • The server line sets the subnet range and netmask that will be used for assigning IP addresses to clients when they log in.
  • The optional push “route 10.0.3.0 255.255.255.0” setting will allow remote clients to access private subnets “behind” the server. Making this work will also require network configuration on to server itself to ensure that the private subnet is aware of the OpenVPN subnet (10.8.0.0).
  • port-share localhost 80 allows client traffic coming in on port 1194 to be rerouted to a local web server listening on port 80. This will be useful in our case since we’re going to use a web server to test our VPN. This will only work when proto is set to tcp.
  • The user nobody and group nogroup lines should be enabled by removing the semicolons. Forcing remote clients to work as nobody and nogroup ensures that their sessions on the server will be unprivileged.
  • log sets current log entries to overwrite old entries every time OpenVPN starts up, while log-append appends new entries to the existing log file. The openvpn.log itself will be written to the /etc/openvpn/ directory.

In addition, it is also very common to add client-to-client to the config file so multiple clients will be able to see each other in addition to the OpenVPN server.

Once you’re satisfied with your configuration, you’re ready to fire up the OpenVPN server.

systemctl start openvpn

Running ip addr to list your server’s network interfaces should now include a reference to a new interface called tun0. This will have been created by OpenVPN for the use of 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

It is _possible_ that you’ll need to reboot the server before everything will fully function. Next stop: the client computer.

Configuring an OpenVPN client

Traditionally, tunnels are built with at least two ends (otherwise we prefer calling them caves). Having OpenVPN properly configured on the server directs traffic into and out of the tunnel at that end. But you’ll need some kind of software running on the client side as well.

In this section I’m going to focus on manually configuring a Linux computer of one sort or another to act as an OpenVPN client. But that’s not the only way you might want to consume the service. OpenVPN itself maintains client apps that can be installed and used on Windows or Mac desktop/laptops, or Android and iOS smart phones and tablets. See the //openvpn.net web site for details.

The OpenVPN package will need to be installed on the client machine, as it was on the server — although there’s no need for easy-rsa over here, because the keys you’ll use already exist. You will need to copy the client.conf template file over to the /etc/openvpn/ directory that the installation just created. This time, for some reason, the file won’t be compressed, so a regular cp 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 fairly obvious: they’ll need to match the values used by the server. As you can see from the sample file below, one that’s unique is remote 192.168.1.23 1194 — which points the client to the server’s IP address. Again, make sure you use your server’s actual address. You should also force your client to verify the authenticity of the server certificate to prevent a possible man-in-the-middle attack. One way to do this is by adding the remote-cert-tls server line.

client ;dev tap dev tun proto tcp remote 192.168.1.23 1194 resolv-retry infinite nobind user nobody group nogroup persist-key persist-tun ca ca.crt cert client.crt key client.key comp-lzo verb 3 remote-cert-tls server 

Now you can move to the /etc/openvpn/ directory and pull those certification keys from the server. You will obviously substitute your server’s actual IP address or domain name for the one in the example.

cd /etc/openvpn scp [email protected]:/home/ubuntu/ca.crt . scp [email protected]:/home/ubuntu/client.crt . scp [email protected]:/home/ubuntu/client.key .

Nothing exciting is likely to happen until you start up OpenVPN on the client. Because you’ll need to pass a couple of arguments, you’ll pull the trigger from the command line. — tls-client tells OpenVPN that you’ll be acting as a client and connecting via TLS encryption while — config points to your config file.

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

Read the command output carefully to make sure you’re connected properly. If something does go wrong the first time, it’s probably either due to a setting mismatch between the server and client configuration files or perhaps a network connectivity/firewall issue. Here are some troubleshooting steps:

  • Carefully read the output from the OpenVPN operation on the client — it will often contain valuable hints to exactly what it couldn’t do and why.
  • Check for error-related messages in the openvpn.log and openvpn-status.log files in the /etc/openvpn/ directory on the server.
  • Check OpenVPN-related and timely messages in the system logs on both the server and client (journalctl -ce will print out a screenfull of the most recent entries).
  • Confirm that you’ve got an active network connection between the server and client (see chapter 14 for details).

This article is excerpted from my Manning “Linux in Action” book. There’s lots more fun where this came from, including a hybrid course called Linux in Motion that’s made up of more than two hours of video and around 40% of the text of Linux in Action. Who knows…you might also enjoy my Learn Amazon Web Services in a Month of Lunches.