В интернете полно статей о настройке сервера OpenVPN для подключения пользовательских компьютеров к удаленной сети, и создается впечатление, что это его единственное применение. Кто-то даже считает, что с появлением WireGuard он вовсе утратил свою актуальность. Действительно, встроенный роуминг и другие возможности WireGuard создают старым проектам серьезную конкуренцию.

Однако в OpenVPN есть много менее известных возможностей, и он все еще остается одним из самых гибких, многофункциональных и простых в настройке решений.

Я предполагаю, что у вас уже есть опыт настройки OpenVPN, поэтому пропустим основы и сразу перейдем к малоизвестным полезным фичам.

Соединение точка — точка

OpenVPN обычно ассоциируется с настройками типа клиент — сервер. Большинство статей посвящены именно этому варианту, и многие сетевые дистрибутивы вроде OpenWRT и OPNSense предоставляют пользовательский интерфейс только для него. Но это большое упущение! OpenVPN — очень простой способ соединить два хоста или сети безопасным туннелем типа точка — точка.

Еще менее известный факт: в этом режиме OpenVPN может работать со статическими ключами (pre-shared key), без сертификатов. Более того, чтобы сгенерировать такой ключ, вам не понадобится никаких инструментов, кроме самого OpenVPN.

Предположим, что мы хотим постоянное подключение к удаленной машине с адресом 203.0.113.100.

Сгенерируем ключ:

$ openvpn --genkey --secret /etc/openvpn/shared.key

Настроим локальную сторону:

dev-type tun
dev tun0 
ifconfig 192.168.0.2 192.168.0.1
rport 1194
remote 203.0.113.100
secret /etc/openvpn/shared.key

Теперь скопируем файл ключа на удаленную машину и напишем там противоположный конфиг:

dev-type tun
dev tun0 
ifconfig 192.168.0.1 192.168.0.2 
lport 1194
local 203.0.113.100
secret /etc/openvpn/shared.key

По желанию можно добавить туда опции для работы в режиме демона:

daemon openvpn-tun0
writepid /var/run/openvpn-tun0.pid

Осталось сохранить конфиг в файл вроде /etc/openvpn/s2s.conf и запустить openvpn —config /etc/openvpn/s2s.conf.

Идентификация соединений происходит только по ключу, адреса хостов никак не учитываются. Указать опцию remote нужно только на одной стороне — «клиенте». Сторона без опции remote будет ждать подключения. Из-за этого OpenVPN удобен для соединений site to site с хостами, у которых нет статического адреса, и даже хостами за NAT.

Опция local не обязательна, но полезна для маршрутизаторов с несколькими внешними интерфейсами. Если ее не указывать, OpenVPN будет слушать на 0.0.0.0.

OpenVPN работает поверх UDP, если не указано обратное. Если хотите использовать TCP, на стороне «клиента» нужно добавить в конфиг proto tcp-client, а на стороне «сервера» — proto tcp-server.

Насколько плохо использование статических ключей? С одной стороны, утечка такого ключа куда более опасна, поскольку злоумышленник сможет расшифровать весь перехваченный трафик, и в прошлом, и в будущем. TLS решает эту проблему использованием сессионных ключей. Но с другой стороны, такой трафик сложнее идентифицировать как зашифрованный туннель.

Режим site to site можно использовать с TLS и сертификатами, но настройка этого сложнее и требует больше времени. Если вам нужно поднять соединение между двумя машинами с минимальными затратами усилий, OpenVPN site to site со статическим ключом — оптимальный вариант.

Раздача разных настроек разным клиентам в OpenVPN

Динамическая маршрутизация — это здорово, но совершенно непрактично для клиентских соединений. Даже для туннелей к маршрутизаторам это может быть непрактично, если они работают на какой-нибудь OpenWRT, где нет удобного механизма для ее настройки. Вручную настроить FRRouting или BIRD можно на любой UNIX-подобной ОС, но нужно ли?

С OpenVPN решить эту проблему просто. Все слышали про опции push в конфиге самого сервера, вроде push «route 172.16.20.0 255.255.255.0». Меньше людей знают, что эти настройки могут быть не только глобальными. Более того, почти любые опции можно указать на уровне клиентов.

Чтобы иметь возможность задавать настройки отдельным клиентам, нужно указать каталог для файлов с этими настройками:

client-config-dir /etc/openvpn/client-configs/

Для идентификации клиентов используется поле CN (Common Name) из их сертификатов. Предположим, у вас есть клиент с CN=jrandomuser и ему нужен доступ к сети 172.16.19.0/24.

Достаточно создать файл /etc/openvpn/client-configs/jrandomuser и прописать туда опцию

push "route 172.16.19.0 255.255.255.0"

Таким же образом можно избирательно отключить split tunneling для некоторых клиентов, если прописать им push «route 0.0.0.0 0.0.0.0».

Кроме маршрутов, можно раздавать множество других опций. Например, задать клиентам свой сервер DNS: push «dhcp-option DNS 172.16.0.10». Можно указать и сервер WINS, если клиенту нужен доступ к SMB: push «dhcp-option WINS 172.16.0.10».

Возможность указывать все это как глобально, так и для отдельных клиентов позволяет весьма гибко управлять доступом пользователей к внутренней сети без особых усилий.

OpenVPN читает файлы клиентских настроек при каждом их подключении. Перезапускать его, чтобы добавить новых клиентов или поменять настройки, не нужно.

Подключение удаленных сетей в OpenVPN

Режим site to site хорош для небольшого числа соединений. Если у вас десятки или сотни удаленных сетей, настраивать туннель к каждой крайне утомительно. Можно автоматизировать этот процесс с помощью Ansible или чего-то еще, но в OpenVPN есть встроенный механизм для этой задачи.

Предположим, что сеть вашей организации — 10.0.0.0/16, а для удаленных клиентов у вас выделена 10.0.0.0/21. Пусть ваш сервер OpenVPN использует сетевой интерфейс tun0.

Прежде всего нужно создать маршрут ко всей сети через этот интерфейс. В Linux команда будет такой:

$ sudo ip route add 10.0.0.0/21 dev tun0

Тонкий момент: ядро Linux удаляет маршруты, когда интерфейс исчезает или уходит в down. По этой причине нужно сделать, чтобы этот маршрут создавался при перезапуске OpenVPN. Самое чистое решение — использовать демон маршрутизации вроде Quagga/FRRouting или BIRD, который сам следит за состояниями сетевых интерфейсов и пересоздает маршруты по необходимости. Самое простое — добавить команду в скрипт запуска.

Одну подсеть мы выделим для клиентских интерфейсов и укажем ее в опции server. Кроме того, нужно указать в конфиге topology subnet. Чтобы указывать, какая сеть какому клиенту принадлежит, нам снова понадобится client-config-dir.

Разумеется, клиентам потребуется доступ к корпоративной сети, поэтому мы выдадим им маршрут к 10.0.0.0/16 с помощью push.

Добавим следующее в конфиг сервера:

server 10.0.0.0 255.255.255.0
topology subnet
persist-tun
 
client-config-dir /etc/openvpn/client-configs/
 
push "route 10.0.0.0 255.255.0.0"

Теперь создадим конфиг клиента. Предположим, вы хотите подключить офис с сетью 10.0.1.0/24 и вы создали для его маршрутизатора сертификат с CN=my-remote-office.

Пропишите следующее в /etc/openvpn/client-configs/my-remote-office:

iroute 10.0.1.0 255.255.255.0

Теперь, когда этот клиент подключится, OpenVPN ассоциирует сеть 10.0.1.0/24 с его подключением.

Хранение всех настроек клиента в одном файле

Очень часто можно получить от удаленной стороны конфиг OpenVPN для подключения к серверу и отдельные файлы с CA, клиентским сертификатом и ключом. Это приемлемо для админов, но крайне неудобно для конечных пользователей.

К счастью, ключи и сертификаты можно хранить вместе с настройками. Например:

client
dev tun
proto udp
remote 203.0.113.20 1194
 
<ca>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN RSA PRIVATE KEY-----
...
-----END RSA PRIVATE KEY-----
</key>

Пользователю достаточно сохранить этот файл (к примеру, в my-vpn.ovpn) и запустить openvpn —config my-vpn.ovpn или указать этот файл в графическом интерфейсе клиента.

Общение с процессом OpenVPN через сокет

OpenVPN предоставляет интерфейс, через который вы можете просмотреть информацию о подключениях и выполнить ряд административных задач. Взаимодействовать с ним можно через сокет: либо TCP/IP, либо UNIX.

Есть вариант подключаться к сокету IP через Telnet. Это удобно, но нужно следить за безопасностью доступа к этому сокету. Обеспечить безопасность UNIX domain socket куда проще, поэтому мы выберем именно этот способ.

Нужно добавить в конфиг сервера следующее:

management /tmp/openvpn-mgmt unix

Подключиться к этому сокету можно с помощью утилиты socat:

$ sudo socat - UNIX-CONNECT:/tmp/openvpn-mgmt
>INFO:OpenVPN Management Interface Version 1 -- type 'help' for more info

В выводе help вы найдете целый ряд полезных команд. К примеру, kill jrandomuser принудительно разорвет все подключения клиента с CN=jrandomuser. В выводе команды status можно увидеть информацию о всех текущих подключениях.

Если вас интересует именно информация о клиентских туннелях и вы хотите получать ее без необходимости каждый раз подключаться к сокету, можете добавить вот эту опцию в конфиг:

status /tmp/openvpn.status

Данные в файл /tmp/openvpn.status будут писаться в таком же формате, как вывод команды status, вроде:

OpenVPN CLIENT LIST
Updated,Tue Apr 21 12:45:47 2020
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
jrandomuser,192.0.2.57:56422,51036248,505028963,Tue Apr 21 08:04:02 2020

Заключение

В документации к OpenVPN отыщется и много других интересных возможностей. К примеру, если указать несколько опций remote в конфиге клиента, клиент автоматически переключится на следующий адрес сервера, если не сможет подключиться к первому.

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