«Переход с устаревающих технологий на современные, это не просто апгрейд инфраструктуры. Это управляемый процесс, где главная задача — сделать изменения невидимыми для конечного пользователя. Разберёмся, как заменить MPLS на SASE, не получив панику отдела продаж или срыв производственного плана.»
Переход от традиционных MPLS-сетей к облачной SASE-архитектуре стал практически обязательным для компаний, работающих с распределённым персоналом, облачными сервисами и удалёнными офисами. Однако сама мысль о такой миграции часто пугает: возникает страх перерывов в работе, потери доступа к критичным системам и снижения производительности. Эти риски управляемы, если подойти к процессу системно.
Основное заблуждение — что переход требует «перерезания кабеля», то есть полного отказа от MPLS в определённый момент времени. На самом деле эффективная миграция почти всегда происходит параллельно, а не последовательно. Старая и новая инфраструктура какое-то время сосуществуют, а нагрузка переносится с одной на другую постепенно, по принципу «отщепления» (peel-off).
Почему именно SASE, и почему сейчас?
Технология MPLS, долгое время бывшая золотым стандартом корпоративной связи, была идеальна для эпохи, когда основная рабочая нагрузка находилась внутри корпоративного дата-центра. Она обеспечивала предсказуемую полосу пропускания, качество обслуживания (QoS) и приватность каналов.
Сейчас же трафик ушёл в интернет. Сотрудники работают удалённо, приложения переехали в облако, а SaaS стал обыденностью. MPLS превращается в дорогую «последнюю милю» до облака, создавая лишний хоп и задержки. SASE отвечает на эти вызовы, объединяя сетевое подключение и безопасность в единую облачную службу, доставляемую точкам присутствия провайдера, которые находятся рядом с пользователями и облачными ресурсами.
Ключевой сдвиг парадигмы: безопасность теперь следует за пользователем и данными, а не наоборот.
Разработка поэтапного плана миграции: ключевые принципы
Успех миграции зависит не от скорости, а от её управляемости. Цель плана — создать безопасную «песочницу» для тестирования и обеспечить контролируемое расширение новой архитектуры.
1. Аудит и картографирование существующей инфраструктуры
Прежде чем что-то менять, нужно точно понимать, что имеется. Это не только список IP-адресов и топология сети. Необходимо выявить:
- Критические зависимости: Какие приложения и сервисы требуют MPLS? Есть ли устаревшие системы (например, банковские терминалы, производственное оборудование), использующие специфические протоколы поверх MPLS? Эта информация определит «последние рубежи» миграции.
- Паттерны трафика: Кто с кем общается? Большая часть трафика уходит в интернет или между филиалами? Карта потоков данных покажет, какие узлы можно переключить первыми с минимальным риском.
- Контрактные обязательства: Сроки действия договоров с MIPS-провайдерами. План миграции может быть привязан к дате окончания контракта, чтобы избежать штрафов.
2. Выбор архитектурной модели внедрения SASE
Есть два основных подхода к интеграции SASE с текущей MPLS-сетью:
- Постепенное замещение филиалов (Hub-and-Spoke через SASE): В этой модели корпоративный дата-центр или хаб (hub) остаётся подключённым к MPLS и новой SASE-платформе одновременно. Филиалы (spokes) по одному переключаются с MPLS на SASE-туннель, который ведёт к тому же хабу. Это упрощает управление политиками безопасности, так как шлюзы остаются в привычном ЦОДе.
- Полноценный облачный SASE: Более радикальная модель, при которой и хаб-функционал (брандмауэр, инспекция трафика) переносится в облако SASE-провайдера. Филиалы и удалённые пользователи подключаются напрямую к ближайшей точке присутствия (PoP). MPLS остаётся лишь для подключения самых критичных систем, не готовых к переходу.
3. Тестовый запуск на «некритичном» сегменте
Первый шаг — не в боевую сеть. Выберите для пилота один небольшой удалённый офис, группу сотрудников ИТ-отдела или даже отдельное тестовое приложение. Цели пилота:
- Проверить работу базовых сервисов (доступ к внутренним ресурсам, интернет, VoIP).
- Настроить и отладить политики безопасности (инспекция TLS, контроль приложений, фильтрация URL).
- Оценить реальную производительность и задержки.
- Отработать процедуру отката на случай сбоев.
Техническая реализация: методы бесшовного переключения
Когда план составлен и пилот успешен, наступает этап массовой миграции. Вот как технически обеспечить непрерывность.
Сосуществование MPLS и SASE: Dual-Stack и динамическая марш2рутизация
Ключ к бесперебойной работе — наличие двух активных каналов одновременно. На маршрутизаторах в филиалах настраиваются оба подключения: MPLS-линк (например, через интерфейс VRF) и SASE-туннель (чаще всего IPsec или WireGuard) поверх обычного интернет-канала.
Далее применяются протоколы динамической маршрутизации. Например, BGP может анонсировать одни и те же префиксы как через MPLS, так и через SASE-туннель, но с разными атрибутами локального предпочтения (Local Preference). Пока MPLS является основным каналом, ему присваивается более высокий приоритет. При необходимости переключения (плановой или аварийной) приоритеты меняются на SASE-туннель, и трафик практически мгновенно перенаправляется.
Контроль за производительностью и быстрый откат
Во время миграции необходим постоянный мониторинг ключевых метрик по каждому каналу: задержка (latency), джиттер, потеря пакетов (packet loss), доступность критичных ресурсов. Инструменты мониторинга должны быть подключены к обеим инфраструктурам.
Важно заранее определить чёткие триггеры для отката. Например: потеря пакетов более 2% в течение 5 минут, недоступность ключевого приложения, увеличение задержки выше заданного порога. Процедура отката должна быть максимально автоматизирована — например, скриптом, который меняет приоритет маршрута обратно на MPLS.
Особенности миграции для удалённых пользователей и облачных сервисов
С MPLS удалённые сотрудники обычно подключались через VPN-шлюзы в корпоративном ЦОДе, создавая лишнюю нагрузку на MPLS-канал. SASE решает эту проблему изящно.
- Тонкие клиенты (Agents): На устройства сотрудников устанавливается лёгкий клиент SASE. Он автоматически находит ближайшую PoP-точку провайдера и устанавливает зашифрованный туннель. Политики безопасности применяются в облаке, трафик к интернет-ресурсам выходит локально, а к корпоративным — направляется через внутреннюю сеть провайдера. Миграция здесь поэтапная: можно включить клиент для тестовой группы, а остальные пока работают через старый VPN.
- Прямой доступ к облаку (Cloud Direct): Многие SASE-провайдеры имеют частные пиринги с крупными облачными платформами. Это позволяет перенаправить трафик из филиала в облако (например, в Яндекс Cloud или VK Cloud Solutions) не через интернет и не через корпоративный ЦОД, а по оптимизированному каналу. Это резко снижает задержки и повышает безопасность. Для миграции нужно лишь изменить маршруты на филиальном маршрутизаторе или в самом SASE-консоли, указав префиксы облака для выхода через этот частный канал.
Типичные риски и как их нивелировать
Даже при идеальном плане что-то может пойти не так. Главное — быть готовым.
| Риск | Причина | Мера нивелирования |
|---|---|---|
| Падение производительности критичных приложений (VoIP, видеоконференции) | Недостаточная пропускная способность интернет-канала или высокий джиттер в SASE-туннеле. | Заранее провести нагрузочное тестирование. Использовать QoS-метки (DSCP) для приоритетного трафика и настроить их передачу через SASE. Рассмотреть локальный прорыв (Local Breakout) для чувствительного к задержкам трафика. |
| Несовместимость со старыми приложениями или устройствами | Устаревшие протоколы (IPX, NetBIOS), широковещательный трафик, специфические требования к MTU могут некорректно работать в инкапсулированном туннеле. | Выявить такие системы на этапе аудита. Для них можно оставить MPLS-подключение как постоянное решение или настроить для них выделенный туннель с особыми параметрами (например, увеличенный MTU, отключение инспекции). |
| Сложность управления политиками безопасности | Переход от простых ACL на периметре к комплексным облачным политикам, управляющим идентичностью, приложениями и данными. | Начинать с простых политик, реплицирующих старые правила доступа. Постепенно внедрять новые возможности (например, Zero Trust Network Access — ZTNA) для отдельных групп ресурсов, не пытаясь охватить всё сразу. |
| Зависимость от интернет-канала | Выход из строя основного интернет-канала филиала лишает его и MPLS, и SASE. | Обязательно иметь резервный интернет-канал от другого провайдера, даже с меньшей ёмкостью. SASE-клиенты и маршрутизаторы могут автоматически переключаться на него. |
Итог: SASE не как замена, а как новая основа
Успешная миграция с MPLS на SASE, это не одномоментный акт, а управляемая трансформация сетевой периферии. Её итогом должна стать не просто более дешёвая сеть, а инфраструктура, которая лучше соответствует современным бизнес-процессам: гибкая, безопасная и ориентированная на облако. MPLS на какое-то время может остаться для поддержки самых консервативных систем, но основным вектором развития становится SASE. Главный результат — сотрудники в филиалах и на удалёнке даже не заметили, как поменялась технология под капотом, но их работа стала стабильнее и быстрее.