IKEv2 VPN-клиент на Mikrotik RouterOS

MAATRIX

IKEv2 на Mikrotik — это не один интерфейс, как в WireGuard, а связка из пяти отдельных объектов IPsec-пакета: профиль, proposal, peer, identity и mode-config, каждый со своим набором параметров, которые должны буква в букву совпасть с настройками сервера. Зато взамен вы получаете протокол, который штатно поддерживается корпоративными VPN-шлюзами, умеет переживать смену IP-адреса клиента (MOBIKE) и не требует объяснять безопасникам, что это за незнакомый UDP-порт в логах. Ниже — рабочая последовательность настройки клиента на RouterOS 7 под сервер на strongSwan, с точками, где чаще всего расходится конфигурация клиента и сервера.

Что нужно подготовить до начала

IKEv2-клиент на Mikrotik осмысленно настраивать, когда сервер уже поднят и известны его точные параметры — соединение работает только при полном совпадении набора шифров, режима аутентификации и адресного пространства mode-config на обеих сторонах. Если сервера ещё нет, разверните его сначала: пошаговая установка на strongSwan разобрана в статье про IKEv2 strongSwan на Ubuntu 24.04.

Перед началом настройки клиента нужно иметь под рукой:

• RouterOS версии 7.x — проверить командой /system resource print, строка version. IPsec-стек в шестой ветке заметно отличается по синтаксису от седьмой, эта статья описывает именно RouterOS 7.
• Публичный IP или FQDN сервера и порт — стандартно IKEv2 работает на UDP 500 и UDP 4500 (для NAT-T).
• Способ аутентификации, который использует сервер — сертификаты (наиболее частый вариант для strongSwan) либо EAP с логином и паролем. Схема ниже — под сертификаты, вариант с EAP разобран отдельно в разделе про peer и identity.
• Сами сертификаты: корневой сертификат удостоверяющего центра (CA), которым подписан сертификат сервера, и клиентский сертификат с закрытым ключом — либо выпущенные тем же CA, что на сервере, либо через отдельный Windows CA, если сеть уже построена на нём (процесс выпуска описан в статье про сертификаты для IKEv2/SSTP через Windows CA).
• Набор шифров сервера — какие алгоритмы шифрования, хэширования и группы Diffie-Hellman заданы в ike proposal и esp proposal на стороне strongSwan (файл ipsec.conf или swanctl.conf), чтобы задать точно такие же на Mikrotik.

Сертификаты: подготовка и импорт

Файлы сертификатов и ключ переносятся на роутер через Files (drag-and-drop в Winbox или FTP) в формате PEM. После загрузки на роутер их нужно импортировать в хранилище сертификатов RouterOS:

/certificate import file-name=ca-cert.pem
/certificate import file-name=client-cert.pem
/certificate import file-name=client-key.pem passphrase="ПАРОЛЬ_КЛЮЧА_ЕСЛИ_ЕСТЬ"

RouterOS попросит указать имя, под которым сертификат сохранится в списке (/certificate print) — для примеров ниже условимся, что CA-сертификат сохранён как ca-cert.pem_0, а клиентский — как client-cert.pem_0. Обязательно проверьте, что после импорта у клиентского сертификата в столбце KKK (has private key) стоит K — если приватный ключ не подтянулся автоматически, импортируйте client-key.pem отдельной командой, как показано выше, и RouterOS свяжет его с сертификатом по совпадающему модулю.

Если сервер проверяет CN или SAN клиентского сертификата (типично для многопользовательских конфигураций strongSwan, где identity строится по имени в сертификате — подробнее в статье про multi-user сертификаты IKEv2 на strongSwan) — уточните это заранее у администратора сервера, иначе аутентификация пройдёт на уровне TLS, но сервер откажет уже на этапе идентификации пользователя.

IPsec-профиль и proposal — параметры шифрования

Профиль описывает параметры фазы 1 (IKE) — то, чем защищается сам канал согласования ключей:

/ip ipsec profile
add name=ikev2-client-profile dh-group=modp2048 enc-algorithm=aes-256 hash-algorithm=sha256 lifetime=8h nat-traversal=yes

Proposal описывает параметры фазы 2 (ESP) — то, чем в итоге шифруется полезный трафик:

/ip ipsec proposal
add name=ikev2-client-proposal auth-algorithms=sha256 enc-algorithms=aes-256-cbc pfs-group=modp2048

Здесь нет права на импровизацию: если на сервере в ike proposal задан, скажем, aes256gcm16-prfsha384-ecp384, а на клиенте вы оставите aes-256-cbc/sha256/modp2048, согласование фазы 1 или фазы 2 просто не пройдёт — RouterOS покажет в логе no proposal chosen или no matching proposal found, без более подробной расшифровки, какой именно параметр не совпал. Самый надёжный способ подобрать значения — попросить администратора сервера прислать точный список алгоритмов текстом, а не подбирать вслепую перебором комбинаций.

Небольшая таблица соответствия распространённых обозначений strongSwan и RouterOS, если параметры сервера присланы в формате ipsec.conf:

GCM-режимы объединяют шифрование и аутентификацию в одном алгоритме — если сервер настроен на aes-*-gcm, поле hash-algorithm в профиле RouterOS фактически не используется для этой части согласования, но оставить в нём валидное значение всё равно нужно.

Peer и identity — настройка клиентского подключения

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

/ip ipsec peer
add name=ikev2-peer address=203.0.113.10/32 exchange-mode=ike2 profile=ikev2-client-profile

exchange-mode=ike2 — ключевой параметр, без него RouterOS попытается согласовать соединение по IKEv1, и сервер, ожидающий только вторую версию протокола, молча отбросит пакеты согласования.

Identity — это уже про то, кто мы и чем подтверждаем свою личность серверу:

/ip ipsec identity
add peer=ikev2-peer auth-method=digital-signature certificate=client-cert.pem_0 \
  remote-certificate=ca-cert.pem_0 generate-policy=port-strict mode-config=ikev2-modecfg

certificate — какой сертификат RouterOS предъявит серверу как свой; remote-certificate — каким CA должен быть подписан сертификат сервера, чтобы Mikrotik его принял (обычно это тот же корневой CA); generate-policy=port-strict избавляет от необходимости вручную прописывать IPsec policy — RouterOS создаёт её автоматически по факту согласованного трафика.

Если сервер вместо сертификатов клиента использует EAP (логин и пароль поверх защищённого сертификатом сервера канала — распространённая схема для мобильных клиентов), identity выглядит иначе, а клиентский сертификат вообще не нужен:

/ip ipsec identity
add peer=ikev2-peer auth-method=eap eap-methods=eap-mschapv2 username=user1 password="ПАРОЛЬ" \
  remote-certificate=ca-cert.pem_0 generate-policy=port-strict mode-config=ikev2-modecfg

В этом случае серверу всё равно нужно предъявить сертификат (проверяется через remote-certificate), а вот клиент подтверждает себя логином и паролем, а не собственным сертификатом.

Mode-config, firewall и NAT-T

Mode-config — механизм, которым сервер выдаёт клиенту адрес внутри VPN-сети (аналог DHCP поверх IKEv2). Для клиента RouterOS создаётся отдельный объект-запрос, а не полноценная выдача:

/ip ipsec mode-config
add name=ikev2-modecfg responder=no

responder=no значит, что RouterOS не раздаёт адреса, а запрашивает адрес у сервера — именно так должен быть настроен клиент; если по ошибке поставить responder=yes, роутер начнёт вести себя как сервер mode-config, и согласование с реальным сервером не состоится.

После успешного согласования RouterOS сам создаёт временный IP-адрес на служебном интерфейсе и IPsec policy по факту трафика (за счёт generate-policy=port-strict на identity) — вручную ни адрес, ни policy прописывать не нужно, в отличие от классической схемы WireGuard, где интерфейс и адрес создаются явными командами (это разобрано в статье про настройку WireGuard-клиента на Mikrotik, если нужно сравнить объём ручной работы).

NAT-T (nat-traversal=yes в профиле) обязателен почти всегда, если Mikrotik сам находится за NAT провайдера — типичная ситуация для домашнего или офисного подключения. Без NAT-T пакеты ESP могут теряться на промежуточных NAT-устройствах, которые не умеют штатно транслировать протокол 50 (ESP) без инкапсуляции в UDP.

Отдельно проверьте, что firewall самого Mikrotik не режет служебный трафик IKEv2 в цепочке input, если на роутере включён строгий firewall по умолчанию:

/ip firewall filter add chain=input protocol=udp dst-port=500,4500 action=accept place-before=0 comment="IKEv2 client"

Это правило нужно, только если стандартная политика input у вас drop, а established/related трафик не пропускается отдельным более общим правилом — на большинстве заводских конфигураций RouterOS ответные пакеты от уже инициированного клиентом соединения проходят по правилу connection-state=established,related без дополнительных исключений.

Проверка подключения и типичные проблемы

Статус согласования фазы 1 (активные peer'ы):

/ip ipsec active-peers print

Если соединение видно в списке, но с пустым state или оно постоянно пересоздаётся — фаза 1 не завершается, почти всегда из-за несовпадения proposal в профиле или ошибки в сертификатах (просроченный сертификат, несовпадающий CA, не импортированный приватный ключ).

Статус фазы 2 (установленные security association, то есть реально работающие туннели):

/ip ipsec installed-sa print

Пустой список при непустом active-peers означает, что фаза 1 прошла, но фаза 2 — нет: чаще всего расхождение в esp proposal (алгоритмы шифрования/аутентификации ESP) или в PFS-группе.

Частые причины отказа и где искать:

Логи полезно смотреть через /log print where topics~"ipsec" — там же обычно виден конкретный этап, на котором согласование остановилось, и это быстрее, чем перебирать варианты по таблице выше.

Частые вопросы