Суверенный рунет 2026: новые требования к ТСПУ для корпоративных сетей

В начале года мы уже писали про новые требования ФСТЭК по КИИ - там фокус был на мониторинге и сегрегации. Сейчас параллельный трек: Роскомнадзор методично расширяет периметр закона о суверенном рунете. С весны в нескольких волнах разъяснений и приказов появилось требование об установке ТСПУ не только у классических операторов связи, но и у организаций, самостоятельно подключённых к интернету через собственные AS или через прямые договоры с магистральными провайдерами. Для части наших клиентов это оказалось неожиданностью - они всегда считали, что ТСПУ это «проблема Ростелекома», а не их.

Кого это касается

Граница проходит не по размеру организации, а по архитектуре подключения. Если организация:

• имеет собственный автономный номер (ASN) и анонсирует свои префиксы в BGP;
• подключена к нескольким транзитным провайдерам напрямую, минуя единую точку обмена трафиком под ТСПУ;
• эксплуатирует точку обмена трафиком или IX-подключение на своей стороне.

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

Большинство средних компаний, которые подключены через одного-двух интернет-провайдеров в пассивном режиме, под требования не попадают - трафик проходит через ТСПУ провайдера. Но среди наших managed-клиентов несколько организаций имеют именно такую «продвинутую» топологию - их кто-то когда-то убедил взять собственный ASN ради независимости от провайдера.

Что конкретно меняется

Практика пока складывается неравномерно. По нашим наблюдениям - и по тому, что слышим от коллег - технические требования к оборудованию на стыке с интернетом такие:

• Место установки. ТСПУ должно стоять на всех точках подключения к сетям связи общего пользования. Если у организации два аплинка от разных провайдеров - на каждом.
• Управление. Оборудование должно принимать сигналы управления от Роскомнадзора в автоматическом режиме. Это означает наличие отдельного управляющего интерфейса и стабильного канала до систем РКН.
• Логирование. Журналы трафика через ТСПУ - отдельный болезненный вопрос по срокам хранения и доступу.

Что происходит с VPN-туннелями до облаков

Здесь самое интересное с операционной точки зрения. У нескольких клиентов инфраструктура частично размещена в отечественных IaaS-облаках, и связность между корпоративной сетью и облаком организована через IPsec или WireGuard поверх интернета.

ТСПУ - это DPI-оборудование. Оно инспектирует трафик. IPsec в туннельном режиме непрозрачен для DPI - с точки зрения фильтра это зашифрованный поток между двумя точками. На практике это порождает несколько сценариев:

Туннель работает, но регулятор видит его как непрозрачный трафик. Пока это не является поводом для блокировки - легитимные IPsec-сессии между организацией и её облачными ресурсами не входят в перечень запрещённого трафика. При этом процедура согласования сложнее: регулятор может запросить подтверждение, что туннель идёт именно в отечественный ЦОД.

Использование VPN-продуктов из стоп-листа. Ряд VPN-решений, особенно западных вендоров, уже попал или может попасть под ограничения. Если организация использует такой продукт для связи с облаком - придётся мигрировать на альтернативу. На практике для корпоративных IPsec-туннелей это решается заменой клиентского ПО на сертифицированные отечественные аналоги или на нативные средства операционной системы.

Производительность. ТСПУ добавляет задержку. Незначительную - обычно единицы миллисекунд, но для приложений, чувствительных к latency, это стоит замерить до и после.

Для туннелей до облаков мы рекомендуем переходить на прямое L3-подключение к облачному провайдеру там, где это доступно, - минуя публичный интернет. Это снимает вопрос и с ТСПУ, и с DPI, и заодно даёт более предсказуемую производительность.

Конфигурация пограничных маршрутизаторов

На нескольких проектах нам пришлось пересматривать конфигурацию BGP-сессий на пограничных маршрутизаторах. Несколько практических наблюдений:

• Анонсы и фильтрация. ТСПУ стоит между маршрутизатором и провайдером - это влияет на видимость управляющего канала. Нужно явно проверить, что out-of-band управление маршрутизатором не зависит от туннелей, которые могут быть прерваны при применении правил фильтрации.
• Failover-логика. Если ТСПУ выходит из строя или применяет некорректное правило, трафик может упасть. Схему failover стоит протестировать отдельно - убедиться, что secondary-аплинк действительно подхватывает нагрузку.
• Документация топологии. На аудитах ФСТЭК, которые мы сопровождали в марте, инспекторы фиксировали замечания за несоответствие схемы реальной топологии. С ТСПУ ситуация аналогичная: оборудование появляется в схеме, его нужно отразить в документации и включить в процесс управления изменениями.

Где сейчас неопределённость

Честно: нормативная база ещё не устоялась. Разъяснения РКН выходят неравномерно, правоприменительная практика по корпоративным сетям только формируется. Мы видим расхождения между тем, что написано в письмах регулятора, и тем, что реально требуют при проверках.

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

История с ТСПУ для корпоративных сетей ещё не дописана - это точно не финальная версия требований.