Установка OpenVPN-сервера ( Инсталляция и настройка VPN-сервера "OpenVPN". )

OS: "Linux Debian 5/6/7/8/9", "Linux Ubuntu 14/16/18 LTS".
Application: "OpenVPN v2.1/2.4", "EasyRSA", "Bash".

Задача: установить и настроить сервис доступа в сетевую инфраструктуру предприятия удалённых клиентов с шифрованием трафика с аутентификацией посредством индивидуальный x509-сертификатов.

На роль самого удобного и простого в применении на стороне клиента напрашивается протокол L2TP, клиенты которого реализованы для всех современных операционных систем, включая предназначенные для мобильных телефонов. Для использования L2TP не требуется установка дополнительного клиентского программного обеспечения - и это хорошо. Однако в процессе эксплуатации выявляются некоторые проблемы, вроде невозможности автоматически отправить клиенту маршруты на подсети за VPN-соединением, а также существенная трудность настройки IPSec в случае подключения с одного IP-адреса нескольких клиентов. В итоге, для организации доступа к разветвлённой корпоративной сети из хорошо известных и проверенных годами бесплатных решений остаётся только "OpenVPN Community Edition (CE)".

Последовательность дальнейших действий такова:



Установка сервера "OpenVPN".

У проекта "OpenVPN Community" нет официального пакетного репозитория, так что основной способ установки - из исходных кодов, свободно доступных в git-репозитории. В "README" репозитория можно найти ссылки на инструкции по установке и настройке "OpenVPN", которыми мы в дальнейшем и воспользуемся. Кроме того, в Wiki проекта "Linux Debian" есть хорошее описание их подхода к настройке "OpenVPN".

При том, что официально "OpenVPN" в готовой сборке не поставляется, таковые сделаны для всех распространённых систем командами их поддержки. В частности, для "Linux Ubuntu 18.04 LTS" дистрибутивная версия "OpenVPN v2.4.4", а в разделе загрузки на сайте разработчиков последняя стабильная "v.2.4.9" - разбег не шокирующе велик, так что не будем усложнять себе жизнь и воспользуемся готовым APT-пакетом, идущим в комплекте с несущей операционной системой:


Сборки "OpenVPN" для "Linux Debian/Ubuntu" 2019-2020 годов не предусматривают запуск сервиса от имени произвольного непривилегированного пользователя. Можно попробовать это исправить, добавив соответствующую системную учётную запись, раздав разрешения, создав несколько sudo-правил и скриптовых обёрток для обхода недостаточного уровня полномочий при доступе к ресурсам, после чего вполне успешно запустив приложение в нужном контексте. Но за этим потребуется отключить автоматику управления приложения подсистемами "Sys-V/Systemd", написав свою - и вот мы уже потеряли возможность обновлять систему с приложениями встроенными инструментами APT. Я за максимальную совместимость и автоматизацию, и полагаю, что проще вынести VPN-сервис на полностью выделенный сервер, позволив ему там вытворять всё, что угодно.

Создаем директории для отображения статистики и хранения журнальных файлов:


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

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

Создание корневого SSL-сертификата.

Обеспечение конфиденциальности передаваемых данных реализуется сервисом "OpenVPN" посредством инкапсуляции в простейшее SSL-соединения, представляемое для пользователей в виде VPN-туннеля. Совершенно так же, как это случается при обращении к web-сайту по протоколу HTTPS, но в данном случае заверяющие подлинность сетевых узлов SSL-сертификаты выпущены не каким-то внешним центром сертификации, а создаются администратором VPN-сервиса.

Для управления SSL-сертификатам воспользуемся адаптированным для "OpenVPN" набором скриптов "EasyRSA" - это действительно проще, чем написание чего-то подобного самостоятельно:


На случай, если "OpenVPN" будет использоваться не только в роли принимающего подключения пользователей сервиса, но и как клиент для связи со сторонней сетевой инфраструктурой, явно вынесем настраиваемую сейчас конфигурацию в поддиректорию "./server/":


Опишем заранее ряд констант, которые будут использоваться при создании x509-сертификатов, как сервера, так и клиентов:



Зачищаем место для работы (внимательно с этим - удаляются все ранее созданные сертификаты в файловой иерархии "./easy-rsa/") и генерируем первичный корневой "самоподписанный" сертификат:



Проверим срок действия и вообще соответствие ожиданиям публичной части корневого сертификата:


Далее для работы нам понадобится только публичная часть "самоподписанного" корневого сертификата "./pki/ca.crt", а секретный ключ "./pki/private/ca.key" будет использоваться исключительно скриптом "EasyRSA" для создания новых сертификатов и отзыва старых или скомпрометированных.

Заранее заготовим файл для перечня отозванных сертификатов:


Закрываем доступ посторонним в директорию с сертификатами:


Создание SSL-сертификата для сервера "OpenVPN".

Если делать всё правильно, с выносом секретной части "корневого" сертификата отдельно от VPN-сервера, то для создания подписанного сертификата понадобиться пройти путь создания приватного клуча и CSR-запроса ("easyrsa gen-req"), перемещения запроса в систему с корневым сертификатом ("easyrsa import-req"), создания там сертификата на основе запроса ("easyrsa sign-req"), и перемещение итогового файла на VPN-сервер.

Но, кто так делает, изначально пойдя по самому лёгкому пути с использованием "EasyRSA"? Для VPN-сервиса с количеством пользователей в пару десятков - никто, наверное. Потому, одной командой прогоняем всю цепочку операций создания условно серверного сертификата:


Просмотр содержимого полученного сертификата - всех трёх его компонентов:


Кроме SSL-сертификата серверу "OpenVPN" ещё понадобится служебный файл параметров "Диффи-Хэлмана", предназначающийся для обеспечения более надёжного шифрования соединения сервера и клиента:


Также создаем служебный файл статического ключа "HMAC", обеспечивающего первичную простейшую аутентификацию как дополнительную защиту от DDoS атак:


Клиентскими сертификатами займёмся позже, а пока попробуем запустить сам сервер "OpenVPN".

Настройка и запуск сервера "OpenVPN".

Воспользуемся предоставленным разработчиками шаблоном конфигурационного файла "OpenVPN":




Заранее создаём директорию для размещения клиентских конфигураций, переопределяющих глобальные:


В дистрибутивной поставке для "Linux Debian/Ubuntu" скрипты автоматического запуска "Sys-V/Systemd" принимают на вход сразу все конфигурационные файлы ".conf" в директории "/etc/openvpn", так что обычно достаточно просто запустить или перезапустить сервис.

В "Linux Ubuntu" для "Systemd" наверчена дополнительная конструкция сканирования набора конфигурационных файлов и запуска определённого с указанием имени сервиса, сопоставляемого с именем его конфигурационного файла. В самом простом случае, по умолчанию, имя сервиса будет "server":


Если ошибок при запуске сервиса небыло, то проверяем, начал ли сервер "OpenVPN" прослушивать назначенный ему порт:



Если в системе нет других туннельных виртуальных интерфейсов, то "OpenVPN" по умолчанию задействует имя "tun0":





Если свидетельств успешного запуска сервера посредством "Sys-V/Systemd" не наблюдается, то пробуем сделать это вручную и смотрим сообщения об ошибках в журнале событий:


Разрешение пересылки сетевых пакетов в несущей системе.

В конфигурации выше мы выбрали режим работы сервера "OpenVPN" в роли виртуального маршрутизатора, терминирующего клиентские подключения. Чтобы пакеты пересылались и далее, в соответствии с уже системной таблицей маршрутизации, потребуется явно включить режим "IP forwarding" для несущей системы:



Применяем заготовленную для этапа запуска операционной системы конфигурацию вручную:


Важно иметь в виду то, что в режиме конфигурации "topology net30" ("Layer 3") сервер "OpenVPN" эмулирует работу маршрутизатора, к портам которого подключены как сам сервер, так и его клиенты. При этом, каждому подключению выделяется, из описанного нами выше в конфигурационном файле диапазона, по четыре IP-адреса (подсеть /30, ограничиваемая маской 255.255.255.252), где (например):


Надо отметить, что непосредственно к портам виртуального маршрутизатора обратиться не получится - в частности, на ICMP-запросы они не отвечают.

Начиная с "OpenVPN v2.1" появилась поддержка топологии "subnet" (), когда сервер и клиент находятся в одной подсети, и выделение IP осуществляется по одному, а не блоками из четырёх - это экономнее. Однако до сих пор не все клиенты этот режим поддерживают, да и логику маршрутизации придётся менять, что не всегда возможно с большим производственным наследием и разномастными подсетями, в которых нужно адресовать подключающихся пользователей.

Наладка ротации журналов событий.

В дистрибутивной поставке "OpenVPN" усечение и ротация журналов событий не предусмотрена. Исправим это:



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


Создание SSL-сертификатов для клиентов "OpenVPN".

Создание SSL-сертификатов для клиентов "OpenVPN" рассматривается в отдельной заметке.

Индивидуальная настройка сетевых параметров клиентов "OpenVPN".

Подготовка CCD-конфигурации для клиентов "OpenVPN" рассматривается в отдельной заметке.