OpenVPN-сервер на MikroTik RouterOS 7: пошаговая настройка

OpenVPN на MikroTik нужен, когда удалённому сотруднику требуется безопасно попасть во внутреннюю сеть, а на ноутбуке уже есть стандартный клиент OpenVPN. Такой туннель удобен в неоднородной среде Windows, Linux и macOS, проходит через большинство NAT и позволяет использовать сертификат вместе с индивидуальным логином и паролем. За это приходится платить более сложной PKI, большим количеством файлов и меньшей производительностью по сравнению с WireGuard.

Ниже настроен routed VPN в режиме ip: клиент получает адрес из сети 10.77.0.0/24 и видит только сервер приложений 10.20.0.25 и внутренний DNS 10.20.0.53. Публичное имя шлюза — vpn.example.ru, транспорт — UDP 1194. Значения <...> являются обязательными заполнителями; команда с ними не предназначена для выполнения. Статья рассчитана на RouterOS 7.17 и новее, потому что с 7.17 конфигурация OpenVPN server стала списком именованных серверов. Для RouterOS 7.14–7.16 синтаксис сервера отличается.

Как устроено подключение и что именно защищает OpenVPN

Клиент сначала устанавливает транспортное TCP- или UDP-соединение с публичным адресом MikroTik. Затем TLS проверяет сертификат сервера и, в нашем варианте, клиентский сертификат. После этого PPP проверяет индивидуальное имя и пароль, создаёт динамический OVPN-интерфейс и выдаёт адрес из пула. Маршруты сообщают клиенту, какие сети отправлять в туннель, а firewall разрешает только требуемые направления.

Сертификат не заменяет учётную запись PPP: RouterOS требует корректный PPP user даже при require-client-certificate=yes. И наоборот, один пароль без проверки сертификата оставляет защиту только на уровне учётных данных. В данном руководстве используются оба механизма.

Подготовить адреса, DNS и внешний доступ

До ввода команд проверьте четыре условия. У MikroTik должен быть публично достижимый адрес либо проброс UDP 1194 на внешнем маршрутизаторе. Имя vpn.example.ru должно разрешаться в этот адрес. Время на роутере должно быть точным, иначе сертификат окажется «ещё не действителен» или «просрочен». Подсеть VPN не должна пересекаться с офисными и домашними сетями клиентов.

/system resource print
/system package print
/system clock print
/system ntp client print
/ip address print
/ip route print
/ip firewall filter print stats
/ip firewall nat print
/export hide-sensitive file=before-openvpn
/system backup save name=before-openvpn password=<BACKUP_PASSWORD>

Если соединение приходит через CGNAT оператора, запись DNS и настройка MikroTik не откроют входящий порт. Потребуется белый адрес, проброс у вышестоящего маршрутизатора или внешний VPN-концентратор. Проверьте UDP 1194 с другой сети после включения сервера; проверка из того же LAN может дать ложный результат из-за hairpin NAT.

Настроить время до выпуска сертификатов

Сертификаты содержат даты начала и окончания действия. Если часы MikroTik отстают, RouterOS подпишет сертификаты с неправильным периодом, а клиент отвергнет их. Включите NTP и убедитесь, что время стало правильным до создания CA.

/system ntp client set enabled=yes
/system ntp client servers add address=time.cloudflare.com
/system ntp client servers add address=time.google.com
/system ntp client print
/system clock print

Если в вашей политике разрешены только корпоративные NTP-серверы, используйте их адреса. После команды print статус должен показывать синхронизацию, а дата — соответствовать текущей. Не выпускайте сертификаты на устройстве, которое ещё показывает дату после сброса питания.

Создать собственный CA и сертификат сервера

Для небольшого стенда CA можно хранить на MikroTik. В корпоративной системе правильнее выпускать серверный и клиентские сертификаты из действующей PKI, а закрытый ключ корневого CA держать вне маршрутизатора. Команды ниже создают локальный CA, затем серверный сертификат с SAN vpn.example.ru.

/certificate add name=ovpn-ca-template \
    common-name="AVG-IT OpenVPN CA" \
    key-usage=key-cert-sign,crl-sign days-valid=3650
/certificate sign ovpn-ca-template name=ovpn-ca

/certificate add name=ovpn-server-template \
    common-name=vpn.example.ru \
    subject-alt-name=DNS:vpn.example.ru \
    key-usage=digital-signature,key-encipherment,tls-server \
    days-valid=825
/certificate sign ovpn-server-template ca=ovpn-ca name=ovpn-server

/certificate print detail where name~"ovpn"

У ovpn-ca должны быть признаки CA и trusted, у ovpn-server — закрытый ключ и цепочка, подписанная ovpn-ca. Если CA не отмечен trusted после подписи, задайте доверие явно и снова проверьте вывод:

/certificate set [find where name=ovpn-ca] trusted=yes
/certificate set [find where name=ovpn-server] trusted=yes

Использование DNS-имени в SAN важно: современные клиенты проверяют Subject Alternative Name, а не только Common Name. При смене публичного имени сертификат надо перевыпустить.

Выпустить отдельный клиентский сертификат

Каждому человеку или устройству нужен отдельный сертификат. Общий .p12 нельзя нормально отозвать: при увольнении одного сотрудника придётся менять сертификат у всех. В примере создаётся сертификат для пользователя Иванов.

/certificate add name=ovpn-ivanov-template \
    common-name=ivanov \
    key-usage=tls-client \
    days-valid=365
/certificate sign ovpn-ivanov-template ca=ovpn-ca name=ovpn-ivanov
/certificate set [find where name=ovpn-ivanov] trusted=yes
/certificate print detail where name=ovpn-ivanov

Экспортируйте CA публично, а клиентский сертификат вместе с закрытым ключом — в PKCS#12 с уникальной длинной парольной фразой. Экспорт создаёт файлы в разделе Files. Не оставляйте их на маршрутизаторе после безопасной передачи пользователю.

/certificate export-certificate ovpn-ca type=pem
/certificate export-certificate ovpn-ivanov \
    type=pkcs12 export-passphrase=<UNIQUE_P12_PASSWORD>
/file print where name~"ovpn"

Файл CA не содержит закрытый ключ. Файл .p12 содержит клиентский закрытый ключ и является секретом. Передавайте его отдельно от пароля к контейнеру, удалите с MikroTik после подтверждённого импорта и не прикладывайте к заявке или общему сетевому диску.

Создать пул адресов, PPP-профиль и отдельную учётную запись

Пул не должен пересекаться с LAN и сетями удалённых сотрудников. PPP-профиль задаёт адрес MikroTik, удалённый пул, DNS и обязательное шифрование. Учётная запись ограничивается сервисом ovpn, чтобы пароль нельзя было использовать для PPTP или другого PPP-сервиса.

/ip pool add name=pool-ovpn-rw ranges=10.77.0.10-10.77.0.199

/ppp profile add name=profile-ovpn-rw \
    local-address=10.77.0.1 \
    remote-address=pool-ovpn-rw \
    dns-server=10.20.0.53 \
    change-tcp-mss=yes use-encryption=required

/ppp secret add name=ivanov \
    password=<UNIQUE_LONG_PASSWORD> \
    profile=profile-ovpn-rw service=ovpn \
    comment="Employee Ivanov; ticket <NUMBER>"

/ip pool print detail where name=pool-ovpn-rw
/ppp profile print detail where name=profile-ovpn-rw
/ppp secret print where name=ivanov

Пароль в истории терминала и экспорте show-sensitive виден как секрет. В продуктивной среде задавайте его в доверенном канале, храните в корпоративном менеджере паролей и никогда не вставляйте реальное значение в инструкцию.

Включить именованный OpenVPN server в RouterOS 7.17+

Используем UDP, режим ip, AES-256-GCM, SHA-256, TLS 1.2 и обязательный клиентский сертификат. RouterOS не является полной копией OpenVPN Community Server, поэтому не переносите параметры из Linux-конфига без проверки поддержки.

/interface ovpn-server server add name=ovpn-rw \
    disabled=no protocol=udp port=1194 mode=ip netmask=24 \
    certificate=ovpn-server require-client-certificate=yes \
    auth=sha256 cipher=aes256-gcm tls-version=only-1.2 \
    default-profile=profile-ovpn-rw \
    push-routes="10.20.0.0 255.255.255.0"

/interface ovpn-server server print detail where name=ovpn-rw

push-routes поддерживается с RouterOS 7.14. В примере маршрут охватывает 10.20.0.0/24, но firewall ниже разрешает только конкретные сервисы. Если вы хотите максимально узкий клиентский маршрут, используйте host route 10.20.0.25 255.255.255.255 и отдельный маршрут к DNS 10.20.0.53 255.255.255.255.

tls-crypt и tls-crypt-v2 в документации RouterOS относятся к OVPN client MikroTik. Не добавляйте их в конфигурацию сервера, ожидая поведение Linux OpenVPN server. Совместимость клиента проверяйте отдельным пилотом.

Открыть внешний порт и разрешить только нужный внутренний доступ

Правило input разрешает установку VPN с WAN. Его надо поставить до завершающего drop. В заводском firewall MikroTik такой drop обычно имеет комментарий defconf: drop all not coming from LAN; в собственной политике найдите фактическое правило и укажите его номер.

/ip firewall filter add chain=input action=accept \
    in-interface-list=WAN protocol=udp dst-port=1194 \
    comment="OVPN: accept UDP 1194 from Internet"
/ip firewall filter print

После проверки переместите добавленное правило выше общего запрета WAN. Не удаляйте drop и не разрешайте весь input из VPN. Для клиента нужны DNS на 10.20.0.53 и HTTPS/RDP на 10.20.0.25; пример ниже разрешает DNS, HTTPS и RDP, а затем закрывает остальное направление VPN → LAN.

/ip firewall filter add chain=forward action=accept \
    src-address=10.77.0.0/24 dst-address=10.20.0.53 \
    protocol=udp dst-port=53 comment="OVPN: DNS UDP"
/ip firewall filter add chain=forward action=accept \
    src-address=10.77.0.0/24 dst-address=10.20.0.53 \
    protocol=tcp dst-port=53 comment="OVPN: DNS TCP"
/ip firewall filter add chain=forward action=accept \
    src-address=10.77.0.0/24 dst-address=10.20.0.25 \
    protocol=tcp dst-port=443,3389 comment="OVPN: approved services"
/ip firewall filter add chain=forward action=drop \
    src-address=10.77.0.0/24 dst-address=10.20.0.0/24 \
    comment="OVPN: deny other LAN access"
/ip firewall filter print stats where comment~"OVPN"

Эти правила должны находиться после established,related accept и до широких drop-правил forward. Порты 443 и 3389 приведены как пример политики, а не обязательный набор. Если RDP не нужен, не открывайте его.

Обеспечить обратный маршрут

Когда MikroTik является шлюзом сети 10.20.0.0/24, серверы уже знают обратный путь через него. Если LAN использует другой шлюз, добавьте на основном маршрутизаторе маршрут 10.77.0.0/24 via <LAN-IP-MikroTik>. Это сохраняет реальные VPN-адреса в журналах серверов.

Если изменить основной маршрутизатор невозможно, временно применяют src-nat в сторону LAN. Тогда внутренний сервер видит адрес MikroTik вместо клиента, что ухудшает аудит и затрудняет разные правила для пользователей.

/ip firewall nat add chain=srcnat action=masquerade \
    src-address=10.77.0.0/24 dst-address=10.20.0.0/24 \
    comment="OVPN fallback NAT to LAN"

Не добавляйте этот NAT, если обратный маршрут уже существует. В идеальной корпоративной схеме используйте маршрутизацию, а не маскировку.

Собрать клиентский профиль без секретов в статье

RouterOS 7.26 умеет экспортировать .ovpn, если включён обязательный клиентский сертификат и заранее экспортированы CA, сертификат и ключ. Точные аргументы команды зависят от имён созданных файлов:

/interface ovpn-server server export-client-configuration \
    server=ovpn-rw server-address=vpn.example.ru \
    ca-certificate=cert_export_ovpn-ca.crt \
    client-certificate=cert_export_ovpn-ivanov.crt \
    client-cert-key=cert_export_ovpn-ivanov.key

Для этой команды нужны именно PEM-файлы сертификата и ключа. Если ранее вы сделали только PKCS#12, отдельно экспортируйте клиентские PEM-файлы с временной уникальной фразой и удалите их из Files после формирования профиля:

/certificate export-certificate ovpn-ivanov \
    type=pem export-passphrase=<TEMPORARY_PEM_KEY_PASSWORD>
/file print where name~"ovpn-ivanov"

Если используется PKCS#12, импортируйте контейнер в клиент OpenVPN и примените подготовленный шаблон профиля без ключей. В нём нет сертификатов, логина и пароля. Для OpenVPN 2.6 важны data-ciphers AES-256-GCM, auth SHA256, remote-cert-tls server и проверка имени vpn.example.ru.

Подключить клиента и проверить результат

Импортируйте профиль в OpenVPN Connect или OpenVPN GUI, установите сертификат и подключитесь из внешней сети. На MikroTik одновременно смотрите активные PPP-сессии, динамический OVPN-интерфейс, firewall counters и журнал.

/ppp active print detail
/interface ovpn-server print detail
/ip firewall connection print where dst-port=1194
/ip firewall filter print stats where comment~"OVPN"
/log print follow-only where topics~"ovpn|ppp|certificate"

На Windows проверьте не только «Connected», но и адрес, маршрут, DNS и каждую разрешённую/запрещённую цель:

ipconfig /all
route print
Resolve-DnsName internal.example.ru -Server 10.20.0.53
Test-NetConnection 10.20.0.25 -Port 443
Test-NetConnection 10.20.0.25 -Port 3389
Test-NetConnection 10.20.0.30 -Port 445

Первые две проверки приложения должны пройти, а доступ к несогласованному 10.20.0.30:445 — завершиться отказом. Если ping не отвечает, это ещё не означает отказ VPN: ICMP мог быть запрещён firewall сервера. Проверяйте тот прикладной порт, который разрешён политикой.

Разобрать частые ошибки

Ошибка TLS до запроса логина обычно означает неверное время, недоверенный CA, несоответствие имени сертификата или отсутствие подходящего cipher. Сравните дату, SAN, цепочку и параметры клиента. Соединение, которое успешно аутентифицируется и не видит LAN, чаще связано с отсутствием forward-правила или обратного маршрута.

Если подключение устанавливается по TCP, но не по UDP, проверьте проброс, firewall провайдера и порт. Не переключайтесь навсегда на TCP поверх TCP без измерений: при потере пакетов вложенные механизмы повторной передачи могут резко увеличить задержки. TCP 443 оправдан как вариант прохождения ограничивающих сетей, а не как универсально лучший транспорт.

При нестабильной передаче крупных файлов измерьте MTU. change-tcp-mss=yes помогает TCP, но не лечит все UDP-приложения. Уменьшайте max-mtu только после подтверждения фрагментации и повторной проверки скорости.

Отозвать доступ и выполнить откат

Для блокировки одного пользователя выключите PPP secret и отзовите его сертификат. Активную сессию завершите отдельно. После отзыва проверьте, что повторное подключение невозможно.

/ppp secret disable [find where name=ivanov]
/ppp active remove [find where name=ivanov]
/certificate revoke [find where name=ovpn-ivanov]

Полный откат новой службы выполняют в обратном порядке: выключают сервер, удаляют firewall-правила по комментариям, secret/profile/pool и только затем сертификаты, если они больше нигде не используются.

/interface ovpn-server server disable [find where name=ovpn-rw]
/ip firewall filter remove [find where comment~"^OVPN:"]
/ip firewall nat remove [find where comment="OVPN fallback NAT to LAN"]
/ppp secret remove [find where name=ivanov]
/ppp profile remove [find where name=profile-ovpn-rw]
/ip pool remove [find where name=pool-ovpn-rw]

Перед удалением объектов сделайте новый /export hide-sensitive и убедитесь, что комментарии уникальны. Бинарный backup возвращает всю конфигурацию и нужен только при серьёзной ошибке.

Что должно получиться в итоге

Рабочая конфигурация — это не зелёная иконка клиента. MikroTik принимает UDP 1194 только с WAN, проверяет сертификат и индивидуальную PPP-учётную запись, выдаёт отдельный адрес, передаёт только необходимые маршруты и разрешает строго заданные сервисы. Внутренняя сеть имеет обратный маршрут, журнал позволяет связать сеанс с пользователем, а отзыв одного сертификата не ломает доступ остальных.

Для приёмки сохраните заполненный протокол OpenVPN: версии клиента и RouterOS, fingerprint сертификата, тесты маршрута, DNS, разрешённых и запрещённых портов, скорость, MTU, отзыв доступа и откат.

Синтаксис и ограничения сверены с руководством OpenVPN для RouterOS, CLI RouterOS 7.26 для экспорта клиентского профиля и документацией по сертификатам.