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

Архивное переиздание с актуализацией. Оригинал опубликован на Habr (≈2015), автор — Ziptar (Ziptar). оригинал скрыт на Habr (HTTP 403/451), доступен только через Wayback Machine Снимок: Wayback Machine. Ниже — редакция ноября 2026: что работает сейчас, что изменилось и как правильно повторить рецепт сегодня. Полный текст оригинала — в конце, без купюр.

TL;DR — версия 2026

OpenVPN для обхода блокировок в 2026 не годится — сигнатуры известны DPI. Но как корпоративный remote-access за TLS-фронтендом или на порту 443/tcp он жив и поддерживается.

Оригинал был написан, когда OpenVPN был синонимом слова «VPN». В 2026 у него узкая, но честная роль: корпоративный доступ, там, где обфускация не нужна, а нужна зрелость — PKI, MFA, аудиты, клиент под каждую платформу. Для обхода цензуры он проигрывает по всем пунктам: ТСПУ (DPI-боксы) стоят у всех крупных российских провайдеров и умеют резать VPN-хендшейки WireGuard, OpenVPN и «голый» Shadowsocks, а классический OpenVPN-хендшейк — первый в их списке: Египет, Иран, Китай и РФ режут его годами. фактическим стандартом антицензурного туннелирования в 2026 стал VLESS + REALITY (Xray-core): он маскируется под обычный HTTPS-трафик к крупному сайту и не требует собственного домена и сертификата.

Статус оригинала

URL: https://habr.com/ru/post/269679/
Статус на Habr: СКРЫТА (403)
Снимок: http://web.archive.org/web/20250725164503/https://habr.com/ru/articles/269679/
Картинки: 0/0 сохранено локально

Что оставить из оригинального гайда

Всё про PKI честно и сейчас: корневой CA, сертификаты сервера/клиента, CRL — та же связка easy-rsa 3, что и в статье. tls-crypt вместо tls-auth (скрывает сам факт OpenVPN на порту), data-ciphers AES-256-GCM:CHACHA20-POLY1305, топология subnet, push "block-outside-dns" для Windows-клиентов — базовый скелет 2026 тот же.

Что менять срочно

UDP/1194 → TCP/443 за nginx/stunnel, либо shared secret в cloaking;
tls-auth → tls-crypt (метаданные рукопожатия больше не видны);
директивы cipher в старых конфигах игнорируются OpenVPN 2.6+ — всё задаётся data-ciphers;
добавьте MFA (pam + TOTP или Keycloak), парольные фразы сертификатов в 2026 не защита;
Docker-сети из «админ удаленку облегчал»-статей — проверяйте --cap-add NET_ADMIN и подсеть не конфликтует с k8s CNI.

Что изменилось с ≈2015 года

OpenVPN 2.6/2.7: data-ciphers, tls-crypt по умолчанию ожидаемо, поддержка DCO (ускорение в ядре)
EasyRSA 3.2, /etc/openvpn/easy-rsa переехал — пути из старых статей не совпадают
провайдеры VPS массово закрывают 1194/udp для новых аккаунтов
старые клиенты OpenVPN Connect не понимают современные конфиги без обновления
в тексте оригинала: классический OpenVPN легко детектится DPI (используется в корпсредах, но не для обхода блокировок)

Чек-лист 2026

TCP/443 + tls-crypt
data-ciphers без устаревших CBC
MFA на подключение
CRL и автоматический отзыв
логи — минимум, и не в РФ-юрисдикцию

Вердикт

Если вы читаете это, чтобы «настроить VPN как в статье» — не надо: берите WireGuard/AWG или VLESS. Если вы админ и вам нужен remote-access с PKI и аудитом — оригинальная статья после микро-правок выше всё ещё рабочий документ.

ОРИГИНАЛ СТАТЬИ (без изменений)

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

[]

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

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

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

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

С использованием стороннего 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

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

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

Наличие пользователя является обязательным, даже не смотря на авторизацию по сертификатам; можно создать одного пользователя на всех клиентов и прописать один и тот же логин/пароль в конфигах клиентов, но это лишает возможности отследить подключение и действия конкретного пользователя — неудобно, несколько небезопасно.
RADIUS-аутентификацию я не рассматриваю просто потому, что не тестировал. Могу лишь предположить, что работать она будет только для username/password, а сертификаты будут всё так же проверяться на микротике.
Следите за тем, что бы пул адресов соответствовал подсети, указываемой в настройках 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-клиента

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

Содержимое client.ovpn с небольшими комментариями# Режим, в котором работает OVPN сервис

client

Внимание! Указываем только один параметр из двух

Для режима tup указываем параметр

dev tun

Для режима tap указываем параметр

dev tap

Этот параметр указываем только в случае использования режима tap, а вместо MyTap подставляем имя tap интерфейса в windows (ipconfig /all, или сетевые подключения в панели управления)

dev-node MyTap

Используемый протокол. ROS’овский OVPN-сервер работает только в режиме tcp

proto tcp

Адрес сервера, к которому будем подключаться, и порт. Вместо ovpn.my.domain — dns-имя или же ip-адрес. Можно указать несколько серверов.

`remote ovpn.my.domain 1194

;remote my-server-2 1194`

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

;remote-random

Тайм аут между попытками определить ip-адрес по указанному DNS-имени сервера, в секундах (или бесконечность — infinite)

resolv-retry infinite

Если указан этот параметр, то клиент будет использовать динамический исходящий порт для подключения

nobind

Разрешают клиенту сохранять настройки туннеля при переподключении, а так же не перечитывать файлы ключей

`persist-key

persist-tun`

Настройки прокси

`;http-proxy-retry # retry on connection failures

;http-proxy [proxy server] [proxy port #]`

Отключает сообщения о повторяющихся пакетах

;mute-replay-warnings

Пути к файлам сертификатов

ca — сертификат CA, которым выданы сертификат клиента И сертификат сервера

cert — сертификат клиента

key — закрытый ключ сертификата клиента

`ca cert_export_test-CA.crt

cert cert_export_test-client-ovpn-1.crt

key cert_export_test-client-ovpn-1.key`

auth-user-pass сообщает клиенту, что он должен использовать имя пользователя и пароль для аутентификации (но не вместо сертификатов, а вместе с сертификатами)

auth-user-pass говорит OVPN-клиенту использовать логин и пароль (но не вместо сертификатов, а вместе с сертификатами)

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

Примечание: В случае использования сертификата с закрытым ключом, к которому и так нужно вводить ключ при каждом подключении, я не считаю необходимым заставлять пользователя помнить ещё и логин с паролем

--auth-user-pass user-pwd.txt

Сообщает клиенту, что он должен проверять сертификат сервера на предмет правильности используемых key-usage

remote-cert-tls server

Ключ для шифрования начала процесса аутентификации (handshake), дополнительная мера безопасности. Имеет смысл при использовании только логина/пароля, без сертификатов.

;tls-auth ta.key 1

Задание особого метода шифрования, по-умолчание используется blowfish128.

;cipher x

Использование lzo-сжатия. Не поддерживается OVPN на ROS.

;comp-lzo

Уровень лога. Чем больше значение — тем подробнее.

verb 3

Блокирование повторяющихся сообщений в логе

;mute 20

Выше были приведены параметры, которые присутствуют в «родном» примере конфига для клиента + 1 необходимый нам параметр

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

Маршрут, устанавливаемый при запуске подключения

Маршрут указывает не на шлюз, а непосредственно на подключение

route 192.168.88.0 255.255.255.0

Пауза перед установкой маршрутов после установления подключения (в секундах)

route-delay 5

Если мы хотим задать OVPN-подключение в качестве основного шлюза

`route-gateway 192.168.100.1

redirect-gateway def1 //Спасибо пользователю @bibliary за правку. Согласно докам этот вариант верен, но протестировать на момент редактирования не имею возможности.

Примечание: для применения параметров маршрутизации, прописанных в конфиге, сам сервис OVPN, или же OVPN GUI должны быть запущены с правами администратора.

Примечание: список большинства параметров здесь но он несколько устаревший.

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

1 Импорт сертификатов

1.1 Кладём в микротик файл сертификата CA и файл сертификата и файл ключа клиента любым удобным способом

1.2 Импортируем сертификат CA

`/certificate import file-name=cert_export_test-CA.crt passphrase=""

1.3 Импортируем сертификат и ключ клиента

`/certificate import file-name=cert_export_test-client-ovpn-1.crt passphrase=""

`/certificate import file-name=cert_export_test-client-ovpn-1.key passphrase=private-key-password1

Настраиваем клиент

`/interface ovpn-client add name=OVPN_client connect-to={ovpn.my.domain|xxx.xxx.xxx.xxx} port=1194 mode={ip|ethernet} user=test-user-1 password=P@ssword1 profile=default certificate=cert_32 auth=sha1 cipher=blowfish128 add-default-route={no|yes} disabled=no

Значения в {} указываете в соответствии с предыдущими настройками и вашими потребностями.

**Для экспериментов использовалось следующее оборудование и ПО:**RouterBoard 2011UiAS-2HnD с RouterOS 6.32.2 на борту — 2 шт., один в качестве сервера, другой в качестве клиента; оба служат пограничными шлюзами — дома и на работе.

Ноутбук с Windows 10 Pro x64 на боту — 1 шт., в качестве клиента; служит для работы и в качестве лаборатории.

Для познания использовались следующие ресурсы:wiki.mikrotik.com

openvpn.net/index.php/open-source/documentation/howto.html

tuxnotes.ru/note/1

www.v13.gr/blog/?p=386

И ещё много по-мелочи из выдачи поиска.

Спасибо за внимание.