IPsec Site-to-Site на MikroTik: выбор IKE и профиля

IPsec Site-to-Site на MikroTik объединяет две сети через защищённый туннель. Выбор начинается с возможностей обеих сторон: версии IKE, способа аутентификации, алгоритмов и требований к адресации.

Для новых совместимых конфигураций обычно рассматривают IKEv2. Конкретный набор алгоритмов зависит от политики безопасности, оборудования и второй стороны; универсального proposal для всех сетей нет.

• Аутентификация
• Выбор параметров шифрования
• Установка безопасного канала (ISAKMP SA)

Вторая фаза — После установки доверия в первой фазе, пиры договариваются о параметрах для шифрования пользовательского трафика:

• Создание IPsec SA (Security Association)
• Выбор PFS (Perfect Forward Secrecy)
• Определение интересующего трафика (Proxy-ID)

Первая фаза IPsec: понятный и современный подход

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

К счастью, первая фаза IPsec устанавливается один раз (или повторно — при разрыве соединения), и криптографические операции в ней не столь частые. Поэтому можно позволить себе более надёжные, но ресурсоёмкие алгоритмы.

Exchange Mode: выбираем правильно

Настройка туннеля начинается с определения режима обмена ключами — exchange-mode. Это критически важный этап, от которого зависит безопасность всей системы.

IKEv1: варианты, которые стоит избегать

Base Mode

Base Mode — это атавизм. Устаревший, слабо задокументированный режим, который практически не поддерживается современными системами. Идентификаторы передаются до установления общего ключа — это значит, что они в открытом виде. Отличная цель для офлайн-атак и перебора паролей.

❌ Не использовать ни при каких условиях.

Aggressive Mode

Работает быстрее, но делает это за счёт безопасности. Здесь тоже идентификаторы передаются в открытом виде, что делает возможным офлайн-брутфорс pre-shared key. Именно поэтому данный режим часто сравнивают с перехватом WPA-хэша в Wi-Fi.

❌ Избегать. Только если иного варианта нет (например, на стороне клиента нет поддержки Main Mode).

Main Mode

Классический и наиболее безопасный вариант в IKEv1. Использует 6 сообщений (3 раунда) для установки соединения. Идентификаторы передаются в зашифрованном виде, что значительно снижает риск перехвата и анализа.

✅ Использовать, если вы по каким-то причинам остались на IKEv1 и обе стороны имеют статические IP.

IKEv2: современный выбор

В отличие от IKEv1, IKEv2 использует всего 4 сообщения, быстрее устанавливает соединение, и в нём встроены механизмы защиты от MITM и Replay-атак.

Особенности:

• Поддержка MOBIKE — автоматическое восстановление соединения при смене IP-адреса.
• NAT-T (NAT Traversal) работает «из коробки».
• Чёткая структура, упрощённая реализация.

✅ Использовать по умолчанию в любых современных сценариях.

Профиль шифрования (Profile)

/ip/ipsec/profile add name=transport dh-group=x25519 enc-algorithm=aes-256 hash-algorithm=sha512 prf-algorithm=sha512

hash-algorithm

Используется для формирования контрольных сумм сообщений при обмене. Обеспечивает целостность данных в процессе установления фазы.

prf-algorithm

PRF — это функция, которая на основе HMAC и выбранного хеш-алгоритма генерирует псевдослучайные данные (например, для ключей). В RouterOS при выборе auto, используется то же значение, что и hash-algorithm. Чем надёжнее хеш-функция — тем надёжнее PRF.

enc-algorithm

Алгоритм шифрования для первой фазы. Так как фаза устанавливается нечасто — можно позволить себе сильные и даже ресурсоёмкие алгоритмы (если есть аппаратная поддержка).

❌ Не используем 3DES и Blowfish — это устаревшие и ненадёжные алгоритмы.

dh-group

Группы Диффи-Хеллмана:

• modp**** — основаны на модульной арифметике. Чем больше число — тем выше безопасность и нагрузка. Например, modp2048 — базовый уровень, modp4096 — уже хороший уровень.
• ecp**** — эллиптические кривые. Быстрее и легче для CPU. Цифра означает битность поля, например, ecp256 — кривая над полем 256 бит.
• x25519 — кривая Монтгомери, оптимизированная только под координату X. Простой, безопасный и быстрый выбор. Сообщество считает его более надёжным, так как реализация проще и прозрачнее, чем у NIST-кривых (secp256r1).

✅ Используйте x25519, если обе стороны поддерживают. Это лучший баланс безопасности и производительности.

📌 Если вы используете IKEv2 — выбирайте сильные параметры, нагрузка минимальна.

Аутентификация (Identity)

/ip/ipsec/identity 
add peer=transport-R2 auth-method=pre-shared-key secret=SgThOrp4N6HCpKAw9DnQNxNS1JEZHZJ72UB0dA7g

pre-shared-key

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

digital-signature (сертификаты)

Более безопасный вариант. Подпись проверяется через инфраструктуру доверия (CA), невозможно подобрать вручную. Но требует настройки и поддержки PKI: выпуск, хранение, отзыв (CRL) и т.п.

✅ Если готовы внедрять CA — лучше использовать сертификаты.

Минимальный конфиг для двух роутеров

R1

/ip ipsec profile 
add name=transport dh-group=x25519 enc-algorithm=aes-256 hash-algorithm=sha512 prf-algorithm=sha512
/ip ipsec peer 
add name=transport-R2 address=2.2.2.2/32 exchange-mode=ike2 local-address=1.1.1.2 profile=transport
/ip ipsec identity 
add peer=transport-R2 auth-method=pre-shared-key secret=SgThOrp4N6HCpKAw9DnQNxNS1JEZHZJ72UB0dA7g

R2

/ip ipsec profile 
add name=transport dh-group=x25519 enc-algorithm=aes-256 hash-algorithm=sha512 prf-algorithm=sha512
/ip ipsec peer 
add name=transport-R2 address=1.1.1.2/32 exchange-mode=ike2 local-address=2.2.2.2 profile=transport
/ip ipsec identity 
add peer=transport-R2 auth-method=pre-shared-key secret=SgThOrp4N6HCpKAw9DnQNxNS1JEZHZJ72UB0dA7g

Заключение

Мы разобрали первую фазу IPsec: от выбора режима обмена до криптографии и аутентификации. Это фундамент, на котором строится безопасность соединения. В современных реалиях IKEv2 + x25519 + AES-256 + SHA-512 — это золотой стандарт.

Сертификаты — лучше, чем ключи, но на первых порах pre-shared-key тоже подойдёт. Главное — не использовать устаревшие алгоритмы и режимы.

Вторая фаза IPsec (Phase 2): политики и трафик-селекторы

Если в первой фазе устанавливается защищённый канал между пирующими сторонами, то во второй фазе начинается шифрование самого трафика.

И вот здесь ошибки выбора параметров шифрования приводят к серьёзным последствиям. Если вы выберете алгоритм, который не поддерживается аппаратно, маршрутизатор будет шифровать всё на процессоре, что моментально приведёт к 100% загрузке CPU, троттлингу, обрывам соединений, реконам и прочим «радостям». А учитывая, что IPsec работает на critical path всего трафика, это убивает весь маршрутизатор.

Аппаратная поддержка

Перед настройкой всегда сверяйтесь с таблицей аппаратно поддерживаемых алгоритмов на официальной странице MikroTik:
👉 IPsec Hardware Acceleration

❗ Не стоит искать информацию по другим источникам. Даже если ваш процессор в теории поддерживает какой-то тип аппаратного шифрования, это не значит, что RouterOS умеет его использовать. Всё должно быть реализовано в коде RouterOS, и это — далеко не всегда так.

Также обращайте внимание на сноски (*), таблица регулярно обновляется. Пояснять её смысла нет — всё там достаточно наглядно.

Proposal — параметры шифрования

/ip ipsec proposal
add name=proposal-transport auth-algorithms=sha256 enc-algorithms=aes-256-cbc lifetime=30m pfs-group=ecp256

🔐 auth-algorithms

Алгоритм подписи пакета — защита от MITM. Чем выше битность — тем надёжнее, но тем длиннее заголовок пакета и меньше полезная нагрузка. Это напрямую влияет на MTU канала.

null можно использовать только в случае работы с -gsm, иначе открывается возможность атак типа Bitflip.

🔁 pfs-group — Perfect Forward Secrecy

PFS означает, что для шифрования во второй фазе будет сформирован новый ключ, независимо от ключей первой фазы. Это важно:

• Без PFS трафик шифруется с использованием ключей, полученных в Phase 1.
• С PFS — даже если кто-то получит ключи первой фазы, он не сможет расшифровать полезную нагрузку.

ecp256 — лёгкая, надёжная эллиптическая кривая, подходящая для большинства случаев.

Вывод: по возможности используйте PFS.

Policy — какие пакеты шифровать?

/ip ipsec policy
add peer=transport-R2 level=unique proposal=proposal-transport protocol=ipencap

🎯 Селекторы

Определяют, какой трафик шифровать. Здесь можно было бы развернуться в теоретические объяснения разницы между транспортным и туннельным режимами, но не будем — в интернете и так достаточно информации.

Важно:

• Туннельный режим — когда к вам подключаются клиенты, не входящие в вашу зону ответственности.
• Транспортный режим — когда вы соединяете два своих маршрутизатора.

Дополнительно: туннельный режим не создаёт интерфейс, из-за чего нельзя использовать протоколы типа OSPF. А с интерфейсом работать проще — и в фаерволе, и в мониторинге.

🛠 protocol=ipencap

Мы не шифруем весь трафик между пирующими устройствами, а только трафик IPIP-туннеля. Поэтому указываем ipencap.

Почему IPIP, а не GRE?
Потому что у IPIP — самый маленький заголовок (20 байт). Это позволяет сэкономить на MTU и снизить накладные расходы. GRE не даёт нам ничего дополнительного в данном кейсе.

🔐 level=unique

Когда между пирующими сторонами несколько политик, по умолчанию все они шифруются одним ключом. Это может вызвать проблемы, например, с клиентами за NAT.

Если задать unique, то для каждой политики будет создана уникальная связка ключей, что устраняет потенциальные конфликты.

Tunnel

Поднимаем сам туннель. Один нюанс — отключаем fast-path, иначе могут быть проблемы.

/interface ipip
add allow-fast-path=no local-address=1.1.1.2 name=ipip-tunnel1 remote-address=2.2.2.2

Firewall

А вот тут уже интереснее. Без тонкой настройки легко сломать работу туннеля.

Исключение IPsec из NAT

Если у вас multi-WAN или active-backup конфигурация — обязательно исключите IPsec-трафик из NAT.

/ip firewall nat
add chain=srcnat src-address=1.1.1.1 action=accept place-before=0

Исключение IPsec по policy

Если в NAT-правилах вы не используете интерфейсы (что уже само по себе questionable), добавьте исключения по ipsec-policy, чтобы трафик не попал под NAT ни в одну из сторон:

/ip firewall nat
add action=accept chain=srcnat ipsec-policy=out,ipsec place-before=0 
add action=accept chain=dstnat ipsec-policy=in,ipsec place-before=0 

Фаервол: input

Если пир активный, и вы используете connection-state=established, то всё нормально — ответные пакеты примутся без явных правил.

Но:

• Если пир в пассивном режиме — обязательно разрешите входящий трафик (UDP 4500).
• Если трафик между пирующими сторонами редкий, то туннель может сходиться чуть медленнее без явных правил.

Простой пример фильтра:

/ip firewall filter
add action=accept chain=input connection-state=established
add action=accept chain=input in-interface=ipip-tunnel1
add action=accept chain=input dst-port=4500 protocol=udp
add action=drop chain=input

💡 Можно добавить разрешение для протокола ESP:

add action=accept chain=input protocol=ipsec-esp

Это не обязательно, но может ускорить установку туннеля за счёт явного разрешения.

На этом этапе вторая фаза должна быть установлена и иметь статус established. А значит — трафик по IPIP туннелю надёжно шифруется, без перегрузки CPU и с возможностью работы любых протоколов поверх него.

Как проверить результат

• Проверьте active-peers, installed-sa и счётчики policy.
• Запустите трафик между согласованными подсетями и убедитесь, что он попадает в SA.
• Проверьте восстановление туннеля после удаления активной SA на тестовой площадке.

Источники и связанные материалы

• IPsec в RouterOS
• Все статьи
• Аудит MikroTik
• Настройка MikroTik

Команды в статье меняют сетевую конфигурацию. Перед работой сохраните экспорт, подготовьте способ восстановления доступа и применяйте изменения сначала в тестовой среде.