OpenVPN: Часть 2 — Как устроен: PKI, сертификаты и базовая настройка

В этой части разобрано, из чего состоит установка OpenVPN Community и как собрать минимальную рабочую конфигурацию: центр сертификации, сертификаты сервера и клиентов, ключ tls-crypt, файлы server.conf и client.ovpn. Примеры рассчитаны на OpenVPN 2.6 и 2.7 на Linux.

Как клиенты и сервер доверяют друг другу

OpenVPN использует инфраструктуру открытых ключей (PKI):

• центр сертификации (CA) — пара ключей, которой подписываются все остальные сертификаты. Закрытый ключ CA — самое ценное в установке, его лучше хранить не на VPN-сервере;
• сертификат сервера — подписан CA и помечен как серверный. Клиент проверяет, что подключается именно к серверу, а не к другому клиенту с похожим сертификатом;
• сертификаты клиентов — по одному на каждого пользователя или устройство;
• список отозванных сертификатов (CRL) — сертификаты уволенных сотрудников и потерянных устройств.

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

Центр сертификации на easy-rsa

Easy-RSA — утилита проекта OpenVPN для управления PKI. В Debian и Ubuntu она ставится пакетом easy-rsa. Минимальный набор команд:

./easyrsa init-pki
./easyrsa build-ca
./easyrsa build-server-full server nopass
./easyrsa build-client-full ivanov

• init-pki создаёт каталог pki;
• build-ca создаёт центр сертификации и спрашивает пароль к его ключу — задайте надёжный;
• build-server-full server nopass выпускает ключ и сертификат сервера без пароля, иначе служба не сможет стартовать без человека;
• build-client-full ivanov выпускает ключ и сертификат клиента; с паролем — если пользователь будет вводить его при подключении, с nopass — если нет.

Результат лежит в каталогах: pki/ca.crt — сертификат CA, pki/issued/ — сертификаты, pki/private/ — закрытые ключи.

Параметры Диффи — Хеллмана (gen-dh) генерировать не обязательно. Документация OpenVPN рекомендует dh none: тогда используется обмен ключами на эллиптических кривых (ECDH), который быстрее и современнее.

Ключ tls-crypt

Параметр tls-crypt шифрует и подписывает весь управляющий канал общим ключом. Это даёт три преимущества: сервер не отвечает на пакеты без ключа, поэтому сканер не видит OpenVPN на порту; сертификаты не передаются в открытом виде; атаки на TLS-стек со стороны посторонних невозможны.

Ключ создаётся командой:

openvpn --genkey tls-crypt tc.key

Файл tc.key копируется на сервер и во все клиентские профили.

UDP или TCP

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

TCP (обычно на порту 443) оправдан, когда UDP закрыт: гостиничные и корпоративные сети иногда пропускают только веб-трафик. Удобная схема — два экземпляра сервера: основной на UDP и запасной на TCP.

Минимальная конфигурация сервера

Файл /etc/openvpn/server/server.conf:

port 1194
proto udp
dev tun
topology subnet
server 10.8.0.0 255.255.255.0

ca ca.crt
cert server.crt
key server.key
dh none
tls-crypt tc.key

keepalive 10 120
persist-tun
user nobody
group nogroup

verb 3
explicit-exit-notify 1

• server 10.8.0.0 255.255.255.0 — подсеть туннеля; сервер получает 10.8.0.1, клиенты — остальные адреса;
• keepalive 10 120 — проверка связи раз в 10 секунд, разрыв после 120 секунд тишины;
• user и group — после запуска служба работает без прав root (в RHEL-совместимых системах группа называется nobody);
• explicit-exit-notify 1 — сервер предупреждает клиентов о перезапуске, и они переподключаются сразу.

Шифр в конфигурации не указан намеренно: версии 2.6 и 2.7 сами согласуют лучший общий из списка data-ciphers.

Чтобы клиенты видели сеть офиса, добавьте маршрут, например push "route 192.168.1.0 255.255.255.0", и включите на сервере пересылку пакетов (net.ipv4.ip_forward = 1). Весь интернет-трафик клиентов через VPN направляет строка push "redirect-gateway def1", но для этого на сервере понадобится ещё и NAT.

Служба запускается так: systemctl enable --now openvpn-server@server (имя после @ — это имя файла конфигурации). Файл состояния с подключёнными клиентами эта служба в Debian и Ubuntu ведёт сама, отдельно указывать status не нужно.

Профиль клиента

Файл ivanov.ovpn:

client
dev tun
proto udp
remote vpn.example.ru 1194
resolv-retry infinite
nobind
persist-tun
remote-cert-tls server
verb 3

<ca>
...содержимое ca.crt...
</ca>
<cert>
...содержимое pki/issued/ivanov.crt...
</cert>
<key>
...содержимое pki/private/ivanov.key...
</key>
<tls-crypt>
...содержимое tc.key...
</tls-crypt>

remote-cert-tls server обязателен: он требует, чтобы сертификат на той стороне был именно серверным. Без него любой клиент с сертификатом того же CA смог бы выдать себя за сервер.

Отзыв сертификата

Когда сотрудник уходит, его сертификат отзывают:

./easyrsa revoke ivanov
./easyrsa gen-crl

Файл pki/crl.pem копируется на сервер, а в server.conf добавляется строка crl-verify crl.pem. CRL имеет срок действия, поэтому gen-crl нужно повторять до его истечения — иначе сервер перестанет пускать всех клиентов.

Типичные ошибки

• Ключ CA на VPN-сервере. При взломе сервера злоумышленник сможет выпускать свои сертификаты. Держите CA на отдельной машине, а на сервер копируйте только ca.crt.
• Нет remote-cert-tls server в профиле. Клиент поверит любому сертификату того же центра.
• TCP «на всякий случай». Без необходимости TCP-транспорт только замедляет туннель.
• Просроченный CRL. Клиенты внезапно перестают подключаться, а в журнале сервера — ошибка проверки CRL.
• Нет пересылки пакетов. Клиент подключился, но не видит офисную сеть: не включён ip_forward или на шлюзе офиса нет обратного маршрута в подсеть туннеля.

Готовые пошаговые примеры: сервер на MikroTik — «Настройка сервера OpenVPN на MikroTik RouterOS», сервер на Ubuntu и клиент на Keenetic — «OpenVPN: настройка Ubuntu-сервера и клиента Keenetic». Развернуть VPN под ключ можно заказать на странице «Настройка VPN».