Почему команды уходят с зарубежных решений в 2026

Основные причины миграции в 2024–2026 годах, по нашим наблюдениям и по обсуждениям в CISO-сообществах:

Предусловия: что подготовить до старта

До старта миграции желательно собрать три артефакта:

  1. Карта ресурсов. Список доменов и IP, к которым обращаются сотрудники. Получить из журналов существующего VPN за последние 30 дней. Это ускорит настройку split-tunnel и kill-switch.
  2. Реестр пользователей. Активные аккаунты, группы доступа, роли. Источник: Active Directory, LDAP, CSV-выгрузка.
  3. Политика доступа. Документ, описывающий, кому какие ресурсы доступны. Без этого шага переход превращается в «дайте всем всё».

Пошаговый план перехода (5 шагов)

1

Пилот на 5–10 пользователях (1–3 дня)

Берём IT-команду + 2–3 «опытных» сотрудника. Разворачиваем новый VPN параллельно со старым, проверяем базовые сценарии: подключение, доступ к корпоративным ресурсам, скорость, kill-switch, журнал аудита.

2

Расширенный пилот на 50–100 человек (7–14 дней)

Включаем одно подразделение (обычно — разработка или маркетинг). Цель — собрать реальные метрики: время подключения, процент сбоев, NPS от пользователей, нагрузка на серверы.

3

Интеграция с SSO/SIEM (5–10 дней)

Подключаем Active Directory, LDAP, OIDC/SAML. Настраиваем экспорт журнала в SIEM (KUMA, MaxPatrol SIEM, Splunk, ELK). Тестируем политики доступа на разных группах.

4

Обучение и документация (параллельно с шагом 3)

Готовим инструкции для сотрудников: как установить клиент, что делать при сбое подключения, как запросить доступ к новому ресурсу. Объявления в корпоративных чатах.

5

Переключение DNS / профилей по умолчанию

Выкатываем новый VPN-профиль как «по умолчанию». Старый VPN остаётся «запасным» на 30 дней. Через месяц отключаем.

Side-by-side pilot: как запустить без простоя

Ключевая идея — оба VPN-клиента работают одновременно, приоритет определяется на уровне профиля или DNS. По нашему опыту, есть три рабочих подхода:

Подход 1: на уровне ОС (Windows/macOS MDM)

Через MDM-профиль (Microsoft Intune, Jamf, Workspace ONE) выкатываем новый VPN-профиль как «приоритетный». Если он недоступен — fallback на старый. Переключение на 100% пользователей — одна команда в MDM.

Подход 2: на уровне DNS

Старый VPN резолвит через vpn-old.example.com, новый — через vpn.example.com. Разводим по DNS-зонам. Когда приходит время — меняем CNAME на vpn.example.com с одного FQDN на другой.

Подход 3: «двойной клиент» с инструкцией

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

Любой из подходов предполагает, что оба VPN работают параллельно минимум 14 дней. Это время — на стабильность нового решения и на привыкание пользователей. Не торопитесь с переключением.

Переключение DNS и VPN-профилей

Если вы используете DNS-conditioned routing — например, через /etc/resolv.conf или Windows network profile — плана перехода три:

  1. CNAME flip. vpn.example.com CNAME vpn-old.example.com → меняем на vpn.example.com CNAME vpn-new.example.com. Минимум усилий, но переключение атомарное — откатить сложно.
  2. TTL play. За 48 часов до переключения опускаем TTL на записи до 60 секунд. Дальше меняем A-запись. Плавный переход, но возможен флапающий резолв в первые минуты.
  3. GeoDNS. Самый плавный вариант: GeoDNS отдаёт старый IP для 10% клиентов, новый для 90%. Через сутки — 0% / 100%. Подходит для больших команд.

Обучение персонала: что важно донести

Большинство сбоев после перехода — не технические, а организационные. Сотрудник не понимает, почему у него перестал работать Notion или Slack, открывает тикет, IT-команда тушит. Простые правила снижают число тикетов в 3–5 раз по нашему опыту:

Типичные ошибки при миграции

Миграция на российский VPN — это не только технический, но и организационный проект. Самые частые ошибки по нашему опыту:

Ошибка 1. Не сделать аудит текущей инфраструктуры

Прежде чем менять VPN, выгрузите журнал существующего решения за последние 30–60 дней. Какие домены посещают? Какой объём трафика? Где пиковые нагрузки? Без этого вы рискуете настроить новый VPN «по ощущениям» и обнаружить, что третьи сервисы через него не работают.

Ошибка 2. Забыть про DNS-зону

Часть внутренних сервисов привязана к IP-адресам через DNS. Если новый VPN ходит через другой DNS-резолвер — имена внутренних серверов могут перестать резолвиться. Решение — настроить split-DNS или пробросить локальную зону.

Ошибка 3. Пропустить обучение

Большинство сбоев после перехода — не технические, а пользовательские. Человек не нашёл иконку, не понял, как включить, открыл тикет. Детальный онбординг экономит часы работы IT-команды в первую неделю.

Ошибка 4. Переключить всех сразу

Запуск на 100% пользователей в один день — распространённый соблазн. В реальности только 30% пользователей прочитают инструкцию заранее. Остальные 70% узнают о новом клиенте в момент, когда старый перестал работать. Это поток тикетов в IT. Переключайте волнами: 10% → 50% → 100%, между волнами — неделя на «обкатку».

Переход по волнам: как разбить компанию на 1000+ человек

Для крупных компаний миграция идёт волнами по отделам, а не по филиалам. Один из проверенных подходов — «разработка первая».

  1. Волна 1 — IT и DevOps. Самые технически подкованные. Дайте им новый VPN за неделю до общего анонса. Они найдут баги и недочёты до того, как 80% компании узнает о новом решении.
  2. Волна 2 — маркетинг, продажи, customer success. Много внешних сервисов (CRM, Trello, Notion, Slack). Они оценят стабильность и скорость. Если что-то не работает — узнаете быстро.
  3. Волна 3 — финансы, HR, юристы. Работают с 1С, Контур.Диадок, SAP, Oracle. Критично стабильно. Дайте им неделю на привыкание.
  4. Волна 4 — операционные сотрудники, склад, логистика. Обычно меньше всего технически требовательны, но у них часто мобильные устройства и BYOD. Тут хорошо работает обучение в виде коротких видео и QR-кодов.
  5. Волна 5 — руководство. Их подключение идёт последним, но громко — потому что у них нет технических проблем и есть пресс-релизы «мы переехали».

Между волнами — минимум 5–7 рабочих дней. За это время IT-команда собирает обратную связь, вендор фиксит баги, документация обновляется. Без буфера волны накладываются и IT-команда захлёбывается.

Связанные материалы

FAQ

Сколько времени занимает миграция с зарубежного VPN на российский?
По опыту компаний с 100–500 сотрудниками: пилот на 5–10 пользователях — 1 рабочий день, тестовый контур на 50–100 пользователей — 7–14 дней, полный перевод всех сотрудников — 30–60 дней с учётом обучения. Для команд от 1 000 пользователей закладывайте 60–90 дней из-за интеграции с Active Directory и SIEM.
Можно ли запустить оба VPN одновременно, чтобы не было простоя?
Да, этот подход называется side-by-side pilot. Старый VPN работает по умолчанию, новый включается параллельно на тестовой группе. Через 7–14 дней, когда группа подтверждает стабильность, выполняется переключение одной кнопкой (DNS, маршрутизация или VPN-профиль по умолчанию).
Что делать с лицензиями старого провайдера — списывать раньше срока?
Зависит от условий контракта. У ряда зарубежных вендоров есть механизм prorated refund при расторжении. Часть российских вендоров готовы зачесть остаток лицензии в оплату российского решения. Если расторжение невозможно без потерь, обычно запускают новый VPN на подразделении в 50–100 человек и постепенно переводят, пока оплата за старый не дойдёт до конца оплаченного периода.