Сертификаты и микропрактикум по OpenSSL

Для работы OpenVPN потребуются сертификаты: сертификат удостоверяющего центра (УЦ, CA), сертификат узла доступа, по одному сертификату для каждого клиента. В принципе, дистрибутив OpenVPN содержит пакет скриптов, позволяющих сгенерировать все нужные сертификаты и ключи при помощи OpenSSL. Использование скриптов описано в документации.

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

В этот раз станем суперпользователем:

$ sudo su

Создаём базовую директорию, в которой будет работать наш удостоверяющий центр (УЦ). (Нужно, впрочем, понимать, что настоящие, большие удостоверяющие центры не должны быть устроены таким образом; хотя, в реальности на это остаётся только надеяться. А для наших целей – использование инструментария OpenSSL по описанному сценарию вполне подходит.)

Итак, базовая директория:

# mkdir -m 755 /etc/VPNCA

Внутри неё – структура директорий, необходимых для работы OpenSSL в режиме УЦ (CA):

# mkdir -m 0755 \
/etc/VPNCA/CA \
/etc/VPNCA/CA/private \
/etc/VPNCA/CA/certs \
/etc/VPNCA/CA/newcerts \
/etc/VPNCA/CA/crl

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

# cp /etc/pki/tls/openssl.cnf /etc/VPNCA/CA/openssl.vpn.cnf

Установим права доступа безопасным образом (впрочем, на отдельном виртуальном сервере это может показаться избыточным):

# chmod 0600 /etc/VPNCA/CA/openssl.vpn.cnf

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

####################################################################
[ ca ]
default_ca = CA_default # The default ca section

####################################################################
[ CA_default ]

dir =. #!!! - базовая директория.

certs = $dir/certs # Where the issued certs are kept
crl_dir = $dir/crl #!!! - путь к директории отзывов.
database = $dir/index.txt # database index file.

#unique_subject = no # Set to 'no' to allow creation of
# several ctificates with same subject.

new_certs_dir = $dir/newcerts # default place for new certs.

certificate = $dir/certs/vpnca.crt #!!! - файл сертификата УЦ.

serial = $dir/serial # The current serial number
crlnumber = $dir/crlnumber #!!! - файл с номером для списка отзывов сертификатов.

crl = $dir/crl.pem #!!! - файл с действующим списком отзывов.

private_key = $dir/private/vpnca.key #!!! - файл секретного ключа УЦ.
RANDFILE = $dir/private/.rand # private random number file

###

Нужно задать начальный серийный номер для сертификатов и для списка отзывов:

# echo ’1001′ > /etc/VPNCA/CA/serial
# echo ’01′ > /etc/VPNCA/CA/crlnumber

После этого можно переходить к генерации сертификата удостоверяющего центра. Это самоподписанный сертификат, что является нормальным положением дел для корневого сертификата. Возвращаемся (если ушли) в базовую директорию:

# cd /etc/VPNCA/CA/

Генерируем сертификат и секретный ключ:

# openssl req -config openssl.vpn.cnf -new -x509 -extensions v3_ca -keyout private/vpnca.key -out certs/vpnca.crt -days 731

OpenSSL потребует ввести некоторое количество параметров, относящихся к создаваемому корневому сертификату. Самое важное: секретный ключ будет сохранён в зашифрованном виде, для этого OpenSSL запросит пароль, который не нужно терять – он потребуется всякий раз, когда вы задумаете подписать или отозвать очередной сертификат.

Обратите внимание, использование -x509 обозначает, что генерируется самоподписанный сертификат удостоверяющего центра (в терминологии OpenSSL – CA), а -days – задаёт период валидности: 731 день, примерно два года.

В результате мы получили пару важных файлов: vpnca.key – секретный ключ удостовряющего центра, именно с его помощью подписываются сертификаты, это самый важный элемент, поэтому установим для него соответствующие уровни доступа:

# chmod 0400 /etc/VPNCA/CA/private/vpnca.key

Второй файл – vpnca.crt – является публичным и представляет собой корневой сертификат нашей системы. Он потребуется для работы OpenVPN, как на сервере, так и на всех клиентах.

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

# cd /etc/VPNCA/CA

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

# openssl req -config openssl.vpn.cnf -new -nodes -keyout private/vpn-node.key -out vpn-node.csr -days 365

Здесь указана опция -nodes, то есть, секретный ключ сохраняется в открытом виде и пароль запрашиваться не будет. Срок действия сертификата – 365 дней. Имя vpn-node указываем и в качестве параметра CN (Common Name) сертификата, это важно и связано с корректной работой клиентов. Выпускам сертификат, используя только что сгенерированный запрос:

# openssl ca -config openssl.vpn.cnf -policy policy_anything -out certs/vpn-node.crt -infiles vpn-node.csr

Ключ -policy – задаёт политику, применяемую к данным сертификатов. Policy_anything – самая свободная политика, допускающая запросы, содержащие, например, отличные от корневого сертификата значения в полях Country Name, Locality Name и др. Политики задаются в файле с конфигурацией OpenSSL, в нашем случае – openssl.vpn.cnf.

В результате выполнения команд мы получили пару файлов, требуемых для идентификации сервера VPN: vpn-node.crt – сертификат, который требуется распространить на всех клиентов; vpn-node.key – секретный ключ сервера, этот файл сохраняется только на сервере (за исключением, разве что, резервной копии). Разумной практикой является использование ограничений на доступ для файлов секретных ключей:

# chmod 0400 /etc/VPNCA/CA/private/vpn-node.key

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

Ещё раз напомню, что мы установили имя сервера vpn-node, которое является частью сертификата. Именно по этому имени, в нашей конфигурации, клиенты будут узнавать о том, что узел является сервером (а не другим авторизованным клиентом нашей сети, проводящим перехват сессии). Это важный момент! Не менее важно использовать правильную политику именования серверов и клиентов. В нашем случае имена клиентов начинаются с префикса “client-”.

Выпускаем сертификаты для каждого из узлов (не обязательно сразу все выпускать). Например, для узла под названием client-pqr, имя указываем в поле Common Name (CN):

# openssl req -config openssl.vpn.cnf -new -nodes -keyout private/client-pqr.key -out client-pqr.csr -days 365
# openssl ca -config openssl.vpn.cnf -policy policy_anything -out certs/client-pqr.crt -infiles client-pqr.csr

Можно взглянуть на то, что получается:

# less./certs/client-pqr.crt

Файлы.csr – после выпуска сертификата не требуются, их можно удалить.

Настройка OpenVPN

Теперь всё готово для того, чтобы поднять инфраструктуру OpenVPN. Управляющие файлы размещаются в директории /etc/openvpn. Для начала создаём внутри неё директорию pki, где разместим все необходимые для аутентификации данные.

# mkdir /etc/openvpn/pki

Копируем ключи и сертификаты, нужные для работы сервера:

# cp /etc/VPNCA/CA/certs/vpn-node.crt /etc/openvpn/pki/vpn-node.crt
# cp /etc/VPNCA/CA/private/vpn-node.key /etc/openvpn/pki/vpn-node.key

- сертификат и секретный ключ сервера.

# cp /etc/VPNCA/CA/certs/vpnca.crt /etc/openvpn/pki/vpnca.crt

- корневой сертификат или сертификат удостоверяющего центра.

Создаём файл конфигурации /etc/openvpn/openvpn.conf – привожу типовой файл, который работает у меня, с небольшими комментариями:

###

# Порт, тип соединения tcp-server, туннелирование - tun.
port 1194
proto tcp-server
dev tun

# Криптографические файлы для аутентификации.
ca pki/vpnca.crt
cert pki/vpn-node.crt
key pki/vpn-node.key

# Список отзывов сертификатов
crl-verify /etc/VPNCA/CA/crl.pem

# данные для генерации ключа шифрования с использованием протокола Диффи-Хелмана (см. ниже).
dh pki/dh2048.pem

# адресация в виртуальной сети, соответствует настройкам BIND
server 192.168.2.0 255.255.255.0

# опции маршрутизации и DHCP - установка DNS
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 192.168.2.1"

# параметры соединения
keepalive 10 120
comp-lzo
max-clients 10
persist-key
persist-tun

# пользователь/группа для рабочего потока OpenVPN
user nobody
group nobody

# логирование
status openvpn-status.log
log-append openvpn.log
verb 3

###

Осталось сгенерировать исходные данные для файла dh2048.pem и разобраться с отзывом сертификатов. Генерация dh2048.pem:

$ openssl dhparam -out pki/dh2048.pem 2048

Параметр 2048 – обозначает число битов, как несложно догадаться.

Механизм отзыва сертификатов требуется для того, чтобы в случае компрометации какого-либо выпущенного клиентского сертификата можно было его заблокировать до истечения срока действия. В противном случае, завладевшая сертификатом сторона получит доступ к использованию нашего VPN (без возможности перехвата, конечно, но всё равно неприятно).

OpenSSL позволяет создавать списки отзыва при помощи ключа -gencrl. Для начала можно создать пустой список (без него OpenVPN в указанной конфигурации работать не станет):

# cd /etc/VPNCA/CA
# openssl ca -config openssl.vpn.cnf -gencrl -out crl.pem

Отзыв сертификата (вовсе необязательно выполнять при начальной настройке, привожу как пример):

# openssl ca -config openssl.vpn.cnf -revoke certs/client-abc.crt

Вообще, возможно запустить OpenVPN без поддержки списка отзывов, в таком случае удалите директиву crl-verify. Однако, если потребуется заблокировать сертификат (например, потеряли авторизованное устройство), то директиву нужно вернуть и сгенерировать список crl.pem.

Маршруты и NAT

Пакеты, приходящие от узлов-клиентов, подключенных через VPN к серверу, должны ходить наружу, а ответы, поступившие из Интернета, попадать обратно к клиентам – иначе мы получим локальную сеть, не более того. То есть, нужен NAT на сервере. Он настраивается штатными средствами, несколькими командами.

Редактируем файл /etc/sysctl.conf, изменив значение параметра net.ipv4.ip_forward = 1 (было – 0). Перезапускаем сетевые сервисы:

# service network restart

Временный вариант, который часто используют:

# echo ’1′ > /proc/sys/net/ipv4/ip_forward

Он точно так же разрешает IP-форвардинг, но не переживёт рестарт системы.

Некий NAT настраивается при помощи iptables. Прежде всего, нужно, опять же, скорректировать настройки в файле /etc/sysconfig/iptables-config, включив параметры IPTABLES_SAVE_ON_STOP=”yes” и IPTABLES_SAVE_ON_RESTART=”yes”. Делается это, например, так:

# nano /etc/sysconfig/iptables-config

Создаём файл iptables:

# touch /etc/sysconfig/iptables

Добавляем правило:

# iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -o eth0 -j MASQUERADE

Готово.

Убеждаемся, что все нужные сервисы запустятся после перезагрузки, если такая потребуется:

# chkconfig named on
# chkconfig iptables on
# chkconfig openvpn on

Перезапускаем/запускаем сервисы:

# service iptables restart
# service named start
# service openvpn start

Всё. Сервер готов.

Настройка клиентов

Если сравнивать с серверной вознёй, то настройка клиентов – элементарна. На клиенте должны быть три файла из инфраструктуры сертификатов, которую мы завели: 1) файл корневого сертификата, он содержит открытый ключ удостоверяющего центра, который позволяет проверять подлинность сертификата (сертификатов), предъявляемых сервером; 2) собственный сертификат данного узла – выпускается на сервере, потому что там мы держим УЦ; позволяет аутентифицировать узел-клиент перед сервером при наличии на узле подходящего секретного ключа; 3) файл, содержащий этот секретный ключ – в нашем примере ключ генерировался на сервере, откуда может быть скопирован на клиент при соблюдении разумных мер предосторожности. Вообще, ключ можно генерировать на клиенте, той же самой командой openssl, которая использовалась выше, на сервер в таком случае передаётся только файл.csr, на основе которого выпускается сертификат.

Помимо копирования файлов, для линуксов/юниксов – достаточно установить штатными средствами OpenVPN и прописать конфигурацию в файл, в примерно том же формате, что и на сервере. Например:

###

remote 10.10.7.11 1194
client
tls-remote vpn-node
proto tcp-client
dev tun

ca pki/vpnca.crt
cert pki/client-abc.crt
key pki/client-abc.key

comp-lzo
user nobody
group nobody
persist-key
persist-tun

status openvpn-status.log
log-append openvpn.log

verb 3

###

Здесь 10.10.7.11 – поменяйте на IP-адрес вашего сервера. Всё заработает.

Обратите внимание на директиву tls-remote, задающую имя сервера, указанное в сертификате (vpn-node, в нашем случае). Если не использовать эту директиву, то другие узлы, имеющие валидный сертификат, выданный нашим УЦ VPN, в принципе, могут прикидываться сервером и перехватывать трафик. Конечно, для небольшой закрытой системы VPN эта атака чисто теоретическая, но тем не менее. Самое занятное, что у tls-remote довольно неожиданная “семантика”: эта директива позволяет использовать “префиксы”, поэтому если имя сервера, указанное в сертификате – “vpn-node”, то “vpn-no” также пройдёт авторизацию. (В нашей схеме все клиентские узлы получают имена, начинающиеся со слова client, так что с vpn-node не перепутаются.)

Для запуска на линуксах: service openvpn start или аналогичный метод, в зависимости от дистрибутива.

Обратите внимание и на DNS! К сожалению, далеко не во всех случаях DNS-сервер правильно устанавливается автоматически, по DHCP. Если всё настроено по этой инструкции, то на клиенте должен использоваться сервер с адресом 192.168.2.1. Если автоматом не получилось, укажите адрес вручную, либо в настройках новомодных Network Managers, либо в /etc/resolv.conf. Понятно, что заработает DNS только после того, как установилось соединение VPN (интерфейс tun).

Для Windows существует клиент с графическим интерфейсом. Не могу сказать, работает ли он под Windows 7/Vista: я не использую Windows, поэтому протестировал этот клиент только под XP – и тут всё хорошо, кроме того, что часть DNS-трафика ходит через незащищённый интерфейс. Впрочем, это полечилось при помощи прописывания для незащищённого соединения адреса VPN-овского DNS-сервера вручную (клиент OpenVPN поднимает свой виртуальный интерфейс и создаёт собственное “Сетевое соединение”). Вот конфигурационный файл:

###

remote 10.10.7.11 1194
client
tls-remote vpn-node
dev tun
proto tcp-client
persist-key
persist-tun

ca c:\\vpn\\pki\\vpnca.crt
cert c:\\vpn\\pki\\client-pqr.crt
key c:\\vpn\\pki\\client-pqr.key
comp-lzo
verb 4
mute 20
register-dns

###