Миграция межплощадочных IPsec IKEv2-туннелей с pfSense на MikroTik RouterOS 7

Производственный кейс переноса четырёх площадок на IPsec на основе политик: поэтапное переключение, FQDN-адреса узлов, проверка трафика и управляемый откат.

Проверено на: MikroTik RouterOS 7.x · IPsec IKEv2 на основе политик · миграция четырёх площадок по схеме «центр — филиалы»

Контекст

В этом кейсе межплощадочная VPN-связность переносилась с решения под управлением pfSense на шлюзы MikroTik RouterOS 7. В контуре было четыре площадки, топология «центр — филиалы», несколько защищаемых подсетей на каждой стороне и достаточно рабочих зависимостей, чтобы отказаться от единовременного переключения всей сети.

Сложность была не в создании одного соединения IKEv2, а в сохранении всех условий прохождения трафика:

• каждая пара локальной и удалённой подсети должна была получить совпадающие политики IPsec на обеих сторонах;
• исключения из NAT должны были обрабатываться раньше общего masquerade;
• межсетевой экран и FastTrack не должны были обходить проверку политик IPsec;
• обратные маршруты должны были оставаться симметричными;
• удалённое управление должно было пережить каждое изменение;
• старый путь нельзя было убирать до прохождения прикладных тестов.

Об обезличивании. Все названия площадок и роутеров, домены, внешние адреса и внутренние подсети в статье вымышлены. Внешние адреса взяты из документационных диапазонов RFC 5737, домены — из example.net. Данные аутентификации, провайдеры, привязки интерфейсов и аппаратные идентификаторы намеренно исключены.

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

Обезличенная топология

В статье используются следующие условные обозначения:

HQ работает как центральный узел. У каждой удалённой площадки есть собственная IKEv2-связь с HQ; прямых туннелей между филиалами нет. Схема построена на политиках: разрешённые пары подсетей представлены селекторами трафика, а не маршрутизируются через туннельный интерфейс.

Сначала определить границы достоверных данных

Старые VPN-контуры часто описаны фрагментарно: экспорт правил межсетевого экрана, таблица подсетей, DNS-записи и заметки администраторов могут расходиться. Считать любой один источник полным опасно.

До проектирования конфигурации RouterOS была собрана единая матрица селекторов из нескольких источников:

Неизвестные значения так и фиксировались как неизвестные. Их нельзя было копировать с соседней площадки по предположению.

Почему установленного соединения недостаточно

Установленная IKEv2-связь подтверждает только Phase 1. Для рабочего многосетевого туннеля также нужны ожидаемые дочерние SA, совпадающие политики IPsec, корректные маршруты, разрешённая пересылка пакетов и успешный прикладной трафик.

Типичная ложноположительная картина выглядит так:

1. в active-peers есть сессия в состоянии established;
2. установлен только один SA из нескольких селекторов;
3. ping в одну подсеть проходит;
4. другой сервис недоступен из-за отсутствующего селектора, исключения из NAT или обратного маршрута.

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

Стратегия миграции

Четыре площадки переносились отдельными волнами. Сначала переключалась одна связь, затем проходили проверки и период наблюдения, и только после этого начиналась следующая площадка.

Последовательность была такой:

1. сохранить резервную копию, экспорт, состояние DNS, маршруты, политики IPsec, SA и счётчики правил;
2. заранее создать новые объекты RouterOS в состоянии disabled и единообразно их пометить;
3. проверить разрешение DNS-имени и доступность удалённого узла через WAN;
4. войти в Safe Mode и активировать только одну площадку;
5. проверить Phase 1, все ожидаемые селекторы Phase 2, оба направления и прикладные сервисы;
6. выйти из Safe Mode только после выполнения критериев успеха;
7. сохранить старый путь на согласованный период наблюдения;
8. перейти к следующей площадке;
9. удалить устаревшие объекты pfSense только после стабильной работы всех волн.

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

Этап 0: зафиксировать восстанавливаемое состояние

Нужны и бинарная резервная копия RouterOS, и текстовый экспорт. Их следует вынести с роутера и хранить как чувствительные инфраструктурные данные.

/system backup save name=pre-ipsec-migration
/export show-sensitive=no file=pre-ipsec-migration

Отдельно сохраняется текущее рабочее состояние:

/ip ipsec peer print detail
/ip ipsec identity print detail
/ip ipsec policy print detail
/ip ipsec active-peers print detail
/ip ipsec installed-sa print detail
/ip firewall nat print detail stats
/ip firewall filter print detail stats
/ip route print detail

Текстовый экспорт удобен для проверки и выборочного восстановления. Бинарная резервная копия полезна для возврата устройства целиком, но её нельзя считать переносимой конфигурацией между произвольными моделями роутеров и версиями RouterOS.

До начала работ также проверяется синхронизация времени. От правильных часов зависят IKE-аутентификация, проверка сертификатов и пригодная для расследования хронология событий.

Этап 1: подготовить отключённый шаблон RouterOS

Имена и комментарии задавались так, чтобы все объекты одной волны можно было быстро отфильтровать и проверить.

Ниже показана только структура связи HQ — BRANCH-A:

/ip ipsec peer
add name=peer-branch-a address=vpn-branch-a.example.net \
    exchange-mode=ike2 profile=s2s-profile-v1 disabled=yes \
    comment="MIGRATION-S2S | BRANCH-A"

/ip ipsec policy
add peer=peer-branch-a tunnel=yes \
    src-address=10.10.10.0/24 dst-address=10.30.10.0/24 \
    proposal=s2s-proposal-v1 disabled=yes \
    comment="MIGRATION-S2S | HQ-10 -> BRANCH-A-10"

Команды создания identity и настройки аутентификации намеренно не приведены. В реальной конфигурации нужно явно задать правильные локальные и удалённые идентификаторы, а ключи или сертификаты получать через утверждённый процесс работы с секретами. Рабочий PSK нельзя помещать в статью, задачу, историю команд или репозиторий.

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

Криптографические настройки из этой или любой другой статьи копировать нельзя. s2s-profile-v1 и s2s-proposal-v1 формируются по принятым требованиям безопасности и реальным возможностям обоих узлов. Одностороннее «усиление», после которого исчезает совместимое пересечение алгоритмов, приводит к недоступности.

Этап 2: аккуратно перейти на FQDN-адреса узлов

RouterOS позволяет указать DNS-имя в качестве адреса удалённого узла. Это избавляет от дублирования адреса провайдера в конфигурации:

:put [:resolve domain-name="vpn-branch-a.example.net"]
/ip ipsec peer print detail where name="peer-branch-a"

FQDN не устраняет зависимость от DNS, а делает её явной. До переключения проверяется:

• роутер разрешает имя через свой настроенный DNS-путь;
• ответ совпадает с согласованной внешней точкой;
• доступны UDP 500 и UDP 4500, а при работе без NAT-T разрешён нативный ESP (IP protocol 50);
• мониторинг и план отката используют то же каноническое имя;
• контролируемая смена DNS и повторное установление IKE проверены в окне работ.

После смены адреса нужно проверить фактический remote-address активного узла. Нельзя считать, что уже установленная сессия немедленно перешла на новую запись DNS.

Этап 3: настроить NAT до включения политик IPsec

Межплощадочный трафик не должен попадать под общее правило masquerade для интернет-трафика. Для каждого направления, представленного на данном роутере, создаётся узкое правило исключения из NAT выше общей исходящей NAT-трансляции.

Пример на HQ:

/ip firewall nat
add chain=srcnat action=accept \
    src-address=10.10.10.0/24 dst-address=10.30.10.0/24 \
    disabled=yes comment="MIGRATION-S2S | HQ -> BRANCH-A | NO-NAT"

Сначала нужно увидеть реальный порядок правил:

/ip firewall nat print detail stats

Во время изменения правило перемещается и включается по конкретному идентификатору элемента. Универсальный рецепт с place-before=0 здесь вреден: правильная позиция зависит от существующих правил входящей и исходящей NAT-трансляции, а также маршрутизации по политикам.

Счётчики NAT служат доказательством. Во время теста счётчик исключения из NAT должен расти, а общее правило masquerade не должно совпадать с этим защищаемым потоком.

Этап 4: учесть IPsec в межсетевом экране и FastTrack

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

Форма правил может выглядеть так:

/ip firewall filter
add chain=forward action=accept ipsec-policy=in,ipsec \
    src-address=10.30.10.0/24 dst-address=10.10.10.0/24 \
    disabled=yes comment="MIGRATION-S2S | BRANCH-A -> HQ"

add chain=forward action=accept ipsec-policy=out,ipsec \
    src-address=10.10.10.0/24 dst-address=10.30.10.0/24 \
    disabled=yes comment="MIGRATION-S2S | HQ -> BRANCH-A"

До изменения проверяются существующие правила фильтрации и положение FastTrack:

/ip firewall filter print detail stats
/ip firewall filter print detail stats where action=fasttrack-connection

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

Этап 5: переключить одну площадку в Safe Mode

До активации волны нужен независимый путь управления или контакт ответственного сотрудника на площадке. После этого оператор входит в Safe Mode и меняет только объекты выбранной связи.

Контрольный список одной волны:

1. определить точные идентификаторы объектов peer, identity, политик IPsec, NAT и правил фильтрации;
2. отключить прежний путь этой связи, не удаляя его;
3. включить новые правила NAT и фильтрации на проверенных позициях;
4. включить полный набор селекторов и объекты peer/identity;
5. инициировать трафик с узла, представляющего защищаемую сеть;
6. проверить состояние IKE/IPsec, прохождение трафика и бизнес-сервисы;
7. выйти из Safe Mode только после успешных проверок.

Использование точных идентификаторов объектов принципиально. Команда наподобие [find comment~"MIGRATION"] удобна в лаборатории, но на рабочем маршрутизаторе может затронуть объекты следующих волн.

Матрица проверок

Нужны три независимых слоя доказательств.

1. Состояние IKE/IPsec

/ip ipsec active-peers print detail
/ip ipsec installed-sa print detail
/ip ipsec policy print detail where comment~"BRANCH-A"
/log print where topics~"ipsec"

Проверяется, что:

• активный удалённый узел использует ожидаемые локальный и удалённый адреса;
• состояние IKEv2 — established, без циклических ошибок согласования;
• набор дочерних SA совпадает с матрицей селекторов;
• активные политики IPsec показывают ожидаемое состояние Phase 2;
• счётчики байтов и пакетов растут во время теста.

2. Прохождение трафика

Каждая пара селекторов проверяется в обоих направлениях с подходящих узлов. Дополнительной проверкой может быть команда ping с роутера, если её исходный адрес входит в политику IPsec:

/ping 10.30.10.10 src-address=10.10.10.1 count=5

Одновременно проверяются счётчики NAT и правил фильтрации:

/ip firewall nat print stats where comment~"BRANCH-A"
/ip firewall filter print stats where comment~"BRANCH-A"

Ping не является полным приёмочным тестом. ICMP может быть запрещён при рабочем приложении или, наоборот, проходить при неработающих DNS, TCP, базе данных, SMB, VoIP либо другом обязательном сервисе.

3. Бизнес-сервисы

Для каждого селектора заранее фиксируется хотя бы один согласованный владельцем тест:

Изменение успешно только после всех обязательных тестов. «Соединение установлено» — диагностическое наблюдение, а не критерий приёмки.

Multi-WAN и обратные маршруты

Если на площадке несколько каналов связи, IPsec нужно рассматривать вместе с выбором исходного адреса, маршрутизацией по политикам, NAT и входящими правилами межсетевого экрана. Соединение может установиться через один WAN, а ответ уйти через другой; отдельная таблица маршрутизации может перехватить защищаемый трафик до совпадения с политикой IPsec.

Маршрутизация подробнее разобрана в статье MikroTik RouterOS 7: Multi-WAN, маршрутизация по политикам и отказоустойчивость VLAN.

В каждой волне отдельно проверялись:

• ожидаемый исходный WAN-адрес для IKE и ESP/NAT-T;
• маршрут до внешнего адреса удалённого узла;
• исключения для внутренних направлений раньше общих правил маршрутизации интернет-трафика;
• симметричный обратный путь для каждой защищаемой подсети;
• переключение на резервный канал только после стабилизации основного пути.

Не стоит совмещать непроверенное резервирование WAN и перенос IPsec в одном шаге. Сначала стабилизируется один механизм, затем добавляется другой.

План отката

Откат проектировался до первого переключения и выполнялся для одной площадки, а не для всей сети.

Условия отката:

• соединение с удалённым узлом не установилось за согласованное время;
• отсутствуют ожидаемые дочерние SA;
• управление стало нестабильным;
• не прошёл хотя бы один обязательный бизнес-тест;
• появились потери пакетов, асимметричная маршрутизация или повторяющиеся ошибки смены ключей;
• оставшегося окна работ недостаточно для корректной диагностики.

Последовательность восстановления:

1. не расширять изменение на другие селекторы и площадки;
2. сохранить журналы, активные соединения, установленные SA, состояние политик IPsec и счётчики правил;
3. отключить новые политики IPsec и объект peer выбранной площадки по проверенным идентификаторам;
4. восстановить старые маршруты и правила межсетевого экрана или включить сохранённую связь pfSense;
5. сгенерировать новые соединения и проверить прежний путь тем же набором тестов;
6. задокументировать причину до следующей попытки.

Нельзя удалять старую конфигурацию во время переключения. Удаление превращает контролируемый возврат в восстановление под давлением аварии.

Мониторинг после миграции

На момент миграции все серверы и шлюзы pfSense ещё контролировались в Zabbix через соединения, защищённые TLS PSK. Поэтому именно Zabbix был частью эксплуатационных доказательств во время переключения; более позднюю схему на Prometheus нельзя задним числом переносить на тот проект.

Сейчас зона ответственности Zabbix уже и оставлена осознанно:

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

Период наблюдения должен быть длиннее одного успешного ping. Минимально отслеживаются:

• смену ключей IKE и дочерних SA;
• время работы соединения и неожиданные повторные согласования;
• счётчики политик IPsec по каждому активному селектору;
• загрузку процессора, память, состояние WAN и потери пакетов на роутере;
• независимые проверки приложений через туннель;
• ошибки идентификации, согласования параметров, повторов, тайм-аутов и фрагментации в журналах.

Для нового слоя сетевого мониторинга пригодится мониторинг сетевого оборудования через SNMP exporter. Его нужно дополнить проверками сервисов через защищаемые сети. Исправный роутер и установленная IKE-сессия не доказывают работу каждого прикладного пути.

Если большие пакеты не проходят при успешном коротком ping, до изменения криптографических параметров проверяются MTU, PMTUD, обработка MSS и промежуточная фильтрация.

Условия остановки

Развёртывание нужно остановить, если:

• матрицу селекторов невозможно согласовать с рабочей конфигурацией;
• идентификатор или данные аутентификации удалённого узла не подтверждены;
• результат разрешения DNS-имени на роутере отличается от согласованной записи об изменении;
• исключение из NAT нельзя разместить без воздействия на посторонние рабочие правила;
• поведение FastTrack или маршрутизации по политикам неясно;
• нет независимого пути управления или ответственного сотрудника на площадке;
• старый путь нельзя восстановить в пределах окна работ;
• предыдущая волна не завершила период наблюдения.

Неопределённость — причина остановиться, а не расширять правила до тех пор, пока трафик случайно не пойдёт.

Выводы

Главный результат миграции относится к эксплуатации, а не к конкретному вендору:

• VPN следует моделировать как набор требований к трафику, а не как один объект peer;
• одна связь переносится за одну волну, чтобы ограничить область возможного отказа;
• имена и комментарии объектов должны явно указывать площадку и селектор;
• FQDN-адреса узлов удобны, но DNS становится рабочей зависимостью;
• Phase 1, каждый селектор Phase 2, оба направления и реальные сервисы проверяются отдельно;
• счётчики и фактический путь прохождения пакетов надёжнее зелёного индикатора;
• откат проектируется и репетируется до отключения старого межсетевого экрана.

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

Ссылки

• MikroTik RouterOS IPsec: https://help.mikrotik.com/docs/spaces/ROS/pages/11993097/IPsec
• MikroTik RouterOS packet flow: https://help.mikrotik.com/docs/spaces/ROS/pages/328227/Packet%2BFlow%2Bin%2BRouterOS
• MikroTik RouterOS firewall filter: https://help.mikrotik.com/docs/spaces/ROS/pages/48660574/Filter
• MikroTik RouterOS mangle и обработка MSS: https://help.mikrotik.com/docs/spaces/ROS/pages/48660587/Mangle