«Переход с MPLS на SASE, это не просто смена технологии, а фундаментальный сдвиг в архитектуре корпоративной сети. Главная задача — сделать это так, чтобы пользователи не заметили изменений, а бизнес-процессы не прервались ни на секунду. Это требует не столько технической виртуозности, сколько стратегического планирования и понимания, что мы меняем саму логику подключения.»
Почему MPLS больше не монополист
Долгое время MPLS был синонимом надёжной корпоративной связи. Он предлагал гарантированную полосу пропускания, предсказуемую задержку и изоляцию трафика — качества, за которые ИТ-директора были готовы платить и ждать месяцы на подключение новой точки. Однако эта модель строилась вокруг физической сети оператора и централизованного трафика.
Современный бизнес ломает эти рамки. Сотрудники работают из дома, офисы открываются в регионах, а облачные приложения находятся где угодно, только не в корпоративном ЦОДе. Гнать весь трафик, включая доступ к публичным облакам, через центральный узел по дорогому MPLS-туннелю, это как ехать в соседний магазин через центр города в час пик. Задержки растут, стоимость мегабита становится неоправданной, а гибкость стремится к нулю.
SASE предлагает иную парадигму: безопасность и сеть как услуга, доставляемые из облака. Вместо маршрутизации трафика к центральному «замку» с межсетевыми экранами, трафик пользователя или филиала направляется на ближайший PoP (точку присутствия) провайдера SASE. Там применяются политики безопасности, а затем трафик идёт кратчайшим путём к цели — будь то корпоративный ресурс или SaaS-приложение. MPLS не отмирает мгновенно, но его роль сужается до критически важных, предсказуемых каналов, в то время как SASE становится магистралью для всего остального.
Стратегия миграции: не рвать, а переплетать
Ключевая ошибка — пытаться совершить «большой скачок», отключив MPLS в один день и включив SASE в другой. Это гарантированно приведёт к остановке бизнеса. Правильный подход — фазированный, где сети какое-то время сосуществуют и дополняют друг друга.
Этап 1: Аудит и проектирование
Прежде чем что-то менять, нужно понять, что есть. Картирование трафика — первый шаг. Какие приложения используются в филиалах? Сколько трафика идёт в интернет, а сколько — в центральный офис или ЦОД? Каковы требования к задержке для VoIP или видеоконференций? Этот анализ покажет кандидатов на первую волну миграции — например, филиалы с высоким объёмом интернет-трафика.
Параллельно проектируется политика безопасности в SASE. Она должна зеркалировать или улучшать существующие правила межсетевого экрана. Здесь важно не просто перенести тысячи ACL-правил, а пересмотреть их, возможно, перейдя на модель Zero Trust, где доступ определяется идентичностью пользователя и устройства, а не просто IP-адресом сети филиала.
Этап 2: Пилот и наращивание доверия
Миграция начинается не с самого важного филиала, а с наименее критичного, или даже с группы удалённых сотрудников. Настраивается подключение по SASE параллельно с существующим MPLS-каналом. Сначала через SASE направляется только интернет-трафик, а внутренний корпоративный остаётся на MPLS. Это позволяет:
- Протестировать работу политик безопасности.
- Оценить реальную производительность и задержки.
- Отработать процедуры подключения и устранения неполадок.
- Наработать статистику и доказать эффективность решения бизнесу и ИТ-команде.
В этот момент часто используется схема «холодного» резервирования: SASE, это основной канал для интернета, а MPLS — резервный для него и основной для внутреннего трафика.
Этап 3: Поэтапный перенос трафика и точек
После успешного пилота начинается волновая миграция. Для каждой новой группы филиалов или пользователей процесс повторяется. Постепенно через SASE начинают пропускать и внутренний трафик, оставляя MPLS в качестве резервного канала. Современные SD-WAN контроллеры, часто являющиеся частью SASE-решения, позволяют интеллектуально распределять трафик по нескольким каналам (MPLS, SASE, локальный интернет) на основе политик: критичный ERP — по MPLS, YouTube — по локальному breakout через SASE, Teams — по лучшему из доступных каналов.
Именно здесь происходит основная экономия: дорогой MPLS-канал можно не расширять, а в перспективе — уменьшить его пропускную способность, так как он теперь обслуживает только специфичные приложения.
Этап 4: Финальный переход и отказ от MPLS
Когда SASE-инфраструктура обрабатывает 90-95% трафика всех филиалов стабильно и в течение нескольких месяцев, а MPLS-каналы простаивают, наступает время для финального шага. Отключение MPLS становится технической формальностью. Бизнес-процессы уже давно работают через новую инфраструктуру. Старые контракты с операторами связи не продлеваются.
Технические нюансы беспрерывного перехода
Чтобы миграция была действительно незаметной, нужно решить несколько нетривиальных задач.
Сохранение IP-адресации
В MPLS-сети филиалы часто используют приватные IP-адреса из единого пула. При переходе на SASE, где трафик идёт через интернет с наложенными туннелями, эти адреса должны сохраняться. Иначе «сломаются» все ACL, правила брандмауэров и системы мониторинга. Решение — использование overlay-сетей (например, на базе IPsec или WireGuard) в рамках SASE, которые инкапсулируют оригинальные IP-пакеты. Для внутренних систем ничего не меняется.
Маршрутизация в гибридный период
Пока MPLS и SASE сосуществуют, одна и та же корпоративная сеть доступна по двум путям. Нужно избегать асимметричной маршрутизации, когда пакет на сервер идёт через SASE, а ответ возвращается через MPLS (или наоборот), что может сбрасываться системами безопасности. Для этого используются технологии отслеживания состояния сессии (Stateful Inspection) на границах сети и/или настройка политик маршрутизации, которые для конкретного потока данных выбирают один постоянный путь.
Безопасность без пробелов
В модели MPLS безопасность часто была централизована в ЦОД. В SASE она распределена по облачным точкам. Ключевой вопрос — консистентность политик. Запрет на доступ к определённому сайту должен работать одинаково для сотрудника в московском офисе на MPLS и для коллеги в кафе на SASE. Этого добиваются за счёт централизованного облачного управления политиками в SASE-платформе, которые мгновенно применяются на всех точках присутствия.
Чего не видит бизнес, но должен видеть архитектор
Помимо технического плана, успех определяют организационные моменты.
- Изменение модели затрат: MPLS, это Capex/Opex за аренду канала фиксированной ширины. SASE, это подписка (SaaS) на пользователя или устройство. Финансовому департаменту нужно показать долгосрочную экономию и переход от фиксированных издержек к операционным.
- Новая компетенция команды: Сетевикам, привыкшим к CLI маршрутизаторов, придётся осваивать облачные панели управления, политики на основе идентификации. Близость к DevOps-практикам становится необходимостью.
- Выбор партнёра: В России SASE-услуги часто предоставляются крупными телеком-операторами или ИТ-интеграторами. Важно оценить не только функционал, но и географию PoP-точек (они должны быть близко к вашим пользователям), возможность гибридного подключения и уровень техподдержки.
Миграция с MPLS на SASE, это путь от статичной, аппаратно-зависимой сети к динамичной, программно-определяемой и облачно-центричной. Сделав этот переход поэтапно, переплетая старую и новую инфраструктуру, можно не просто избежать остановки бизнеса, но и получить сеть, которая не ограничивает рост, а становится его активным драйвером.