OpenVPN на Rocky Linux 9: пошаговая установка

MAATRIX

Rocky Linux 9 всё чаще встречается на VPS вместо привычного AlmaLinux — тот же клон RHEL, но с другим сообществом и своей политикой обновлений. Пакеты и команды почти идентичны, но два места ломают типовые мануалы «под CentOS»: SELinux в enforcing-режиме молча режет соединения, а firewalld на голом сервере не настроен под NAT-форвардинг. Разберём установку OpenVPN на Rocky 9 так, чтобы сервис поднялся с первого раза, а не после часа чтения journalctl.

Подготовка сервера и репозитории

Начните с обновления системы и включения EPEL — пакетов openvpn и easy-rsa в базовых репозиториях Rocky нет:

dnf update -y
dnf install -y epel-release
dnf config-manager --set-enabled crb

Репозиторий crb (CodeReady Builder, аналог powertools в AlmaLinux) сам OpenVPN не требует, но иногда нужен для сборочных зависимостей других EPEL-пакетов — включить его один раз безопаснее, чем потом ловить непонятные ошибки при установке чего-то ещё. Проверьте hostname и часовой пояс — они попадут в логи и в имена сертификатов:

hostnamectl set-hostname vpn-rocky9
timedatectl set-timezone Europe/Moscow

Убедитесь, что SELinux активен — на большинстве образов Rocky он включён по умолчанию в режиме enforcing, и дальше это важно:

sestatus

Если видите SELinux status: enabled и Current mode: enforcing — это нормальная конфигурация, ничего отключать не нужно. Отключение SELinux «для простоты» снижает защиту сервера и не даёт ничего, кроме экономии пяти минут на этой статье.

Установка OpenVPN и Easy-RSA

Ставим сам сервис и утилиту для своего Certificate Authority:

dnf install -y openvpn easy-rsa

В Rocky 9 Easy-RSA лежит в /usr/share/easy-rsa/3/, а рабочую директорию PKI традиционно делают в /etc/openvpn/easy-rsa:

mkdir -p /etc/openvpn/easy-rsa
ln -s /usr/share/easy-rsa/3/* /etc/openvpn/easy-rsa/
cd /etc/openvpn/easy-rsa

Дальше вся работа с сертификатами идёт из этой директории — она уже содержит easyrsa, шаблон vars.example и служебные скрипты.

Генерация сертификатов и ключей

Инициализируем PKI и создаём собственный CA:

./easyrsa init-pki
./easyrsa build-ca nopass

nopass убирает пароль с приватного ключа CA — удобно для автоматизации, но храните pki/private/ca.key вне сервера (в менеджере паролей или офлайн), это корень доверия для всех клиентов. Генерируем запрос и подписываем серверный сертификат:

./easyrsa gen-req server nopass
./easyrsa sign-req server server

Параметры Диффи-Хеллмана и ключ для проверки целостности TLS-handshake (замена устаревшего tls-auth):

./easyrsa gen-dh
openvpn --genkey secret ta.key

Сертификат для первого клиента — процедуру повторяете для каждого нового пользователя, меняя только имя:

./easyrsa gen-req client1 nopass
./easyrsa sign-req client client1

Копируем всё нужное в рабочую директорию сервера:

mkdir -p /etc/openvpn/server
cp pki/ca.crt pki/issued/server.crt pki/private/server.key \
   pki/dh.pem ta.key /etc/openvpn/server/

Настройка сервера OpenVPN

Создайте /etc/openvpn/server/server.conf:

port 1194
proto udp
dev tun

ca ca.crt
cert server.crt
key server.key
dh dh.pem
tls-crypt ta.key

server 10.8.0.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 1.1.1.1"

keepalive 10 120
cipher AES-256-GCM
auth SHA256
persist-key
persist-tun

user nobody
group nobody

status /var/log/openvpn/status.log
log-append /var/log/openvpn/openvpn.log
verb 3

Создайте директорию логов и включите IP-форвардинг в ядре — без него сервер не сможет пересылать трафик клиентов дальше в интернет:

mkdir -p /var/log/openvpn
echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn.conf
sysctl --system

Служба в Rocky 9 (как и в других системах на systemd) запускается по шаблону openvpn-server@<имя_конфига>, где имя берётся из server.conf без расширения:

systemctl enable --now openvpn-server@server
systemctl status openvpn-server@server

Если статус active (running), а в journalctl -u openvpn-server@server нет ошибок — сервис поднялся. На этом этапе интерфейс tun0 должен появиться в выводе ip addr, но снаружи к нему всё ещё не достучаться — это встретят firewalld и SELinux.

firewalld: порт, зона и маскарадинг

Rocky Linux 9 использует firewalld по умолчанию, и на свежем сервере он обычно уже запущен. Проверьте активную зону интерфейса:

firewall-cmd --get-active-zones

Откройте UDP-порт OpenVPN и включите NAT-маскарадинг — без него пакеты от клиентов дойдут до сервера, но не смогут выйти дальше в сеть:

firewall-cmd --permanent --zone=public --add-port=1194/udp
firewall-cmd --permanent --zone=public --add-masquerade
firewall-cmd --reload

Если внешний интерфейс сервера называется не eth0, а иначе (проверьте через ip -br a), это не помешает --add-masquerade — правило работает в рамках зоны, а не привязано к конкретному имени интерфейса. Убедитесь, что внешний интерфейс действительно находится в зоне public:

firewall-cmd --get-zone-of-interface=eth0

Если интерфейс в другой зоне (например, nm-shared при NetworkManager с общим доступом) — либо перенесите его в public, либо повторите команды для правильной зоны. Таблица сравнения, если у вас несколько серверов с разными базовыми образами:

SELinux: где стандартные мануалы дают сбой

Это главное отличие от инструкций «для CentOS без SELinux» или для Ubuntu, где подсистемы просто нет. В enforcing-режиме SELinux проверяет не только, кто и что может делать, но и *контекст* файлов и портов. Штатная установка через dnf уже размечает /etc/openvpn правильным контекстом openvpn_etc_t, а порт 1194/udp у типа openvpn_port_t — поэтому конфигурация из предыдущих разделов обычно работает без правок.

Проблемы начинаются в двух случаях:

1. Вы перенесли конфиги или сертификаты из другого места (например, скопировали server.conf из бэкапа или через rsync с сохранением атрибутов). Контекст мог не проставиться — проверьте:

ls -Z /etc/openvpn/server/

Если видите не openvpn_etc_t, а что-то вроде admin_home_t или unlabeled_t — восстановите стандартную разметку:

restorecon -Rv /etc/openvpn/

2. Вы меняете порт с 1194 на нестандартный (частая практика для обхода блокировок по DPI). SELinux не разрешит OpenVPN слушать порт, который не привязан к типу openvpn_port_t, даже если firewalld его пропускает:

semanage port -a -t openvpn_port_t -p udp 41194

Если получаете ошибку port already defined — значит порт уже привязан к другому типу, посмотрите текущую привязку через semanage port -l | grep 41194 и при необходимости используйте -m вместо -a для изменения.

Когда сервис всё же не стартует или клиент не может подключиться без явной причины в логе OpenVPN — почти всегда виноват именно SELinux. Ищите отказы в аудит-логе:

ausearch -m avc -ts recent

Если видите записи type=AVC ... denied, это SELinux, а не firewalld и не сам OpenVPN. Для разового анализа удобен audit2why — он объясняет denial человеческим языком и предлагает готовую команду audit2allow для генерации локального модуля политики. Использовать audit2allow стоит как крайний инструмент: сначала проверьте restorecon и semanage port, и только если проблема нестандартная (кастомный скрипт, нетиповой путь) — генерируйте свой модуль.

Частые вопросы