AllInfo
Main: Info Blog Temp Mail


news 2019-02-08 10-21-33

Настройка MikroTik в качестве OVPN-сервера с использованием клиентских сертификатов и списка отзыва

Криптография
Из песочницы
Передо мной возникла задача настроить MikroTik в качестве OVPN сервера с использованием клиентских сертификатов и возможностью их отзыва. В интернетах на данную тему чёткого How-To я не нашёл, поэтому решил изобрести свой собственный велосипед. В этой статье я опишу схему настройки данного чуда, получившуюся и работающую у меня.

Использование PKI ROS

Касательно PKI есть два варианта:

1. С использованием встроенного в ROS PKI:

+ можем выдавать и отзывать сертификаты непосредственно на микротике, иначе нам придётся после каждого отзыва вручную обновлять crl на нём
— случайное удаление с микротика CA-сертификата, используемого для подписи и отзыва сертификатов — фатально, импорт ранее выгруженных сертификата и ключа CA не поможет, а дальнейшее использование будет возможно только с использованием openssl и ручной загрузкой crl после каждого отзыва (конечно, если у вас есть актуальный бэкап всего этого)
+ если мы бэкапим весь конфиг микротика, то вместе с ним бэкапится и CA

2. С использованием стороннего PKI — openssl, или windows server PKI (НЕ используйте доверенные CA типа StartSSL, они выдают клиентские сертификаты не только вам):

+ защищены от недостатка первого варианта
— в случае openssl необходимо вручную загружать crl на микротик после каждого отозванного сертификата
+ в случае windows server PKI теоретически можно реализовать проверку подлинности через механизм SCEP, но пока не проверял
— в случае windows server PKI нужен домен, без него этот самый PKI работать не будет

Я буду рассматривать только первый вариант, т.к., во-первых, он мне подходит, во-вторых, он более гибкий. Так же я не буду подробно останавливаться на параметрах сертификатов и прочих разных параметрах стандартных инструментов ROS, т.к. их исчерпывающее описание есть на официальной MikroTik Wiki.

Настраиваем OVPN-сервер на ROS

1. Настройка PKI

1.1. Сертификат CA:

/certificate add name=template-CA country="" state="" locality="" organization="" unit="" common-name="test-CA" key-size=4096 days-valid=3650 key-usage=crl-sign,key-cert-sign


/certificate sign template-CA ca-crl-host=127.0.0.1 name="test-CA"


Примечание: ca-crl-host= — обязательный параметр, иначе список отзыва не будет создан; полный путь к списку отзыва будет указан в параметрах сертификата, графа "[1]Точка распределения списка отзыва (CRL)"; в принципе, можно указать любой из ip-адресов нашего микротика, тот что укажем — и будет прописан в сертификате. Доменные имена параметром не поддерживаются, к сожалению.

1.2. Сертификат сервера:

/certificate add name=template-SRV country="" state="" locality="" organization="" unit="" common-name="test-srv-OVPN" key-size=4096 days-valid=1095 key-usage=digital-signature,key-encipherment,tls-server


/certificate sign template-SRV ca="test-CA" name="test-srv-OVPN"


Примечание: для сертификата сервера key-usage лучше не менять, почему так — описано здесь (а если очень хотим поменять — то там же написано что нужно прописать в конфиге клиента для этого).

Примечание: в отличие от SSTP — OVPN не проверяет соответствие common-name сертификата сервера fqdn'у этого сервера.

1.3. Шаблон для сертификатов клиентов:

/certificate add name=template-CL country="" state="" locality="" organization="" unit="" common-name="test-client-ovpn-template" key-size=4096 days-valid=365 key-usage=tls-client


1.3.1 Сертификат первого клиента:

/certificate add name=template-CL-to-issue copy-from="template-CL" common-name="test-client-ovpn-1"


/certificate sign template-CL-to-issue ca="test-CA" name="test-client-ovpn-1"


1.3.2. Сертификат второго и последующих клиентов:

См. п. 3.1, но меняем значение параметров.

common-name="test-client-ovpn-1"


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

name="test-client-ovpn-1"

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

1.4 В будущем, для отзыва сертификатов используем команду:

certificate issued-revoke %cert-name%


Где %cert-name% — поле name= подписанного сертификата, то есть отображаемое PKI микротика.

2. Настройка OVPN сервера

Примечание: можно настроить в режиме tun («ip» в ROS), а можно в режиме tap («ethernet» в ROS). Режим tun — обычный туннель. Режим tap — эмуляция полноценного ethernet, в частности в режиме tap клиентов можно объединить в режим моста и они будут прекрасно друг друга видеть. В теории в режиме tap можно запустить DHCP-сервер, но в текущей версии ROS это не реализовано.

2tun. Режим tun

2tun.1. Задаём пул адресов для OVPN-клиентов (можно задать непосредственно в PPP-profile):

/ip pool add name=OVPN_srv_pool ranges=192.168.100.2-192.168.254


2tun.2. Создаём PPP-profile для OVPN-сервера:

/ppp profile add name=OVPN_server local-address=192.168.100.1 remote-address=OVPN_srv_pool


Опционально! Остальные параметры по вашему вкусу и в соответствии с вашими целями. Например: dns=192.168.100.1 use-ipv6=no

2tun.3. Настраиваем режим аутентификации пользователей:

/ppp aaa set accounting=yes


2tun.4. Добавляем пользователей:

/ppp secret add name=test-user-1 password=P@ssword1 service=ovpn profile=OVPN_server


/ppp secret add name=test-user-2 password=P@ssword2 service=ovpn profile=OVPN_server


2tun.5. Включаем OVPN-сервер:

/interface ovpn-server server set auth=sha1 cipher=blowfish128 default-profile=OVPN_server mode=ip netmask=24 require-client-certificate=yes certificate=test-srv-OVPN enabled=yes


2tap. Режим tap

2tap.1. Задаём пул адресов для OVPN-клиентов (можно задать непосредственно в PPP-profile):

/ip pool add name=OVPN_srv_pool ranges=192.168.100.2-192.168.254


2tap.1+. Создаём мост для OVPN-подключений:

/interface bridge add name=OVPN_bridge arp=enabled


Примечание: IP для моста назначать совершенно не обязательно, он и так имеется в PPP-profile (кроме того если указать адрес для моста, но не указать local-address= в PPP-profile, то клиент не подключится).

Примечание: arp должен быть включён, иначе клиенты друг-друга не увидят.

2tun.2. Создаём PPP-profile для OVPN-сервера:

/ppp profile add name=OVPN_server local-address=192.168.100.1 remote-address=OVPN_srv_pool bridge=OVPN_bridge


Опционально! Остальные параметры по вашему вкусу и в соответствии с вашими целями. Например: dns=192.168.100.1 use-ipv6=no

2tap.3. Настраиваем режим аутентификации пользователей:

/ppp aaa set accounting=yes


2tap.4. Добавляем пользователей:

/ppp secret add name=test-user-1 password=P@ssword1 service=ovpn profile=OVPN_server


/ppp secret add name=test-user-2 password=P@ssword2 service=ovpn profile=OVPN_server


2tap.5. Включаем OVPN-сервер:

/interface ovpn-server server set auth=sha1 cipher=blowfish128 default-profile=OVPN_server mode=ethernet netmask=24 require-client-certificate=yes certificate=test-srv-OVPN enabled=yes


Примечания для обоих режимов:

1. Наличие пользователя является обязательным, даже не смотря на авторизацию по сертификатам; можно создать одного пользователя на всех клиентов и прописать один и тот же логин/пароль в конфигах клиентов, но это лишает возможности отследить подключение и действия конкретного пользователя — неудобно, несколько небезопасно.

2. RADIUS-аутентификацию я не рассматриваю просто потому, что не тестировал. Могу лишь предположить, что работать она будет только для username/password, а сертификаты будут всё так же проверяться на микротике.

3. Следите за тем, что бы пул адресов соответствовал подсети, указываемой в настройках OVPN-сервера. ROS'овский OVPN-сервер не будет разбираться принадлежат ли одной сети local-address= сервера и назначаемый из пула адрес клиента, более того, если, к примеру, использовать маску 29, а в качестве пула прописать ranges=192.168.100.0/29, клиенту может быть в лёгкую назначен броадкастовый 192.168.100.7, как это было у меня. Точно такая же ситуация может возникнуть, если указанный пул больше, чем подразумевает маска — только проблема выявится не сразу, а чуть погодя.

3. Экспорт сертификатов для настройки клиентов

3.1. Экспорт сертификата CA:

/certificate export-certificate test-CA export-passphrase=""


Примечание: Нам нужен только сам сертификат, закрытый ключ НЕ нужен, поэтому параметр export-passphrase="" должен быть пустым.

3.2. Экспорт сертификатов клиентов:

/certificate export-certificate test-client-ovpn-1 export-passphrase=private-key-password1


/certificate export-certificate test-client-ovpn-2 export-passphrase=private-key-password2


Примечание: export-passphrase= — обязательный параметр для экспорта закрытых ключей; используем для каждого клиента свой пароль; НЕ используем тот же самый пароль, который указывали в пунктах 2.4 для пользователей!

3.3. Извлекаем полученные файлы сертификатов и ключей из микротика любым удобным способом (как правило, я таскаю туда-сюда файлы прямо из винбокса).

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

1. Получаем OVPN-дистрибутив с openvpn.net.
2. Устанавливаем, все опции оставляем по-умолчанию, в том числе tap-интерфейс, который понадобится для любого режима настройки.
3. Идём в OpenVPN\config (по-умолчанию C:\Program Files\OpenVPN\config) и создаём там файл client.ovpn (или копируем из OpenVPN\sample-config).
4. Создаём конфигурацию клиента, или вносим правки с sample-config.

https://habr.com/ru/post/269679/

18.119.108.9 / 2024-12-21_14-45-51 UTC.