«Суверенный Рунет» часто звучит как большой политический термин. На практике это проще: в сетях операторов есть узлы, где трафик анализируют и где к нему применяют правила доступа. В российской модели эту роль выполняют ТСПУ.
Сразу о главном. ТСПУ не «одна коробка, которая выключает интернет». Это узлы DPI и контуры управления политиками, встроенные в инфраструктуру операторов и работающие как часть реальной топологии. Поэтому последствия не сводятся к сценарию «сайт не открывается». Иногда все выглядит хуже: растут задержки, рвутся видеозвонки, VPN начинает сбоить на переподключениях, а страницы грузятся бесконечно и без внятной ошибки.
Дальше будет инженерный разбор: что именно в этой теме называют «суверенизацией», где обычно размещают ТСПУ и что они делают с трафиком. Затем перейдем к прикладной части: какие признаки характерны для разных режимов воздействия и какие метрики стоит собирать, чтобы опираться на измерения, а не на впечатления.
Суверенный Рунет для технаря: управляемость и единые политики
Если убрать риторику, «суверенный Рунет» в практической плоскости это про управляемость и устойчивость российского сегмента сети в разных сценариях. В том числе в аварийных режимах, при проблемах с маршрутизацией, при точечных ограничениях отдельных ресурсов и сервисов. Нормативная база, к которой обычно отсылают, это закон № 90-ФЗ. Он закрепил подход с техническими средствами и централизованным управлением при угрозах. Текст закона доступен на сайте Президента РФ, в 90-ФЗ.
До появления ТСПУ все было заметно разнороднее. Регулятор публиковал перечни доменов и IP, а дальше каждый оператор реализовывал ограничения своим набором инструментов. Где-то ограничивали через DNS, где-то на маршрутизаторах ставили «маршрут в черную дыру» и просто «роняли» трафик на нужные адреса, где-то держали DPI на стыках. Итог был предсказуемым: разный уровень исполнения, разные побочные эффекты и вечный вопрос пользователей, почему у них не работает, а у соседей все нормально.
ТСПУ меняют именно этот слой. Они дают более унифицированную точку применения политик, потому что заметная часть трафика должна проходить через узлы, где эти политики включаются. Для пользователей это часто выглядит как похожие проблемы у разных операторов. Для инженеров это означает еще один важный элемент в цепочке доставки трафика, со своими рисками и узкими местами.
Централизованное управление в официальных документах описывается не только как «заблокировать». Речь также про режимы, когда сеть должна оставаться работоспособной и управляемой при угрозах. Правила централизованного управления в актуальной редакции закреплены постановлением правительства № 1667. Оно опубликовано на портале правовой информации, в № 1667.
Поэтому «суверенный Рунет» на практике это история про изменение архитектуры ответственности. Оператору важно думать не только о пропускной способности и резервировании, но и о соблюдении согласованной схемы пропуска трафика. Любая ошибка в политике или перегрузка узла становятся заметнее, потому что затрагивают больше потоков и больше сервисов.
Где стоят ТСПУ и что реально умеет DPI
ТСПУ обычно размещают там, где сходятся большие объемы трафика. Это стыки с магистральными провайдерами, крупные узлы агрегации, региональные точки концентрации. Логика проста: чтобы управлять трафиком, он должен проходить через место, где его можно классифицировать и где можно вмешаться в сессию.
По способу включения в тракт обычно встречаются два подхода. Первый это включение «в разрыв», когда узел действительно пропускает трафик через себя. Такой режим дает максимум контроля, но требует аккуратного проектирования отказоустойчивости. Если узел падает или начинает просаживать производительность, это быстро превращается в заметную деградацию у абонентов. Второй подход это работа через зеркалирование и активное воздействие на сессии, когда узел видит трафик, но вмешивается точечно. На практике бывают и гибридные схемы, плюс разные включения для разных направлений.
Что именно «видит» DPI? На уровне L3 и L4 все довольно прямолинейно: IP, порты, протоколы, частоты соединений. Интерес начинается выше, когда система распознает приложения и классы трафика по сигнатурам и поведенческим признакам. Даже в мире HTTPS остаются метаданные, по которым можно многое понять. Например, параметры TLS-рукопожатия, SNI (если он не скрыт), характер первых пакетов в сессии, тайминги обмена. Поэтому иногда сервис не выглядит «заблокированным», но начинает вести себя странно и нестабильно.
Показательный кейс последних лет это QUIC и HTTP/3. Когда сервис переходит на QUIC, а инфраструктура контроля настроена консервативно или не успевает за изменениями, появляются эффекты «то работает, то нет». У одного абонента приложение открывается, у другого висит на загрузке, у третьего падают только звонки. Маршрут при этом может быть вполне живым, но в статистике всплывают повторы передач, нестабильные задержки и провалы качества.
Еще одна практическая история это CDN, то есть сети доставки контента, и эйникаст-адресация (anycast). Один и тот же сервис может раздаваться с разных IP и из разных точек присутствия. Попытка ограничить его по подсетям нередко задевает соседей по адресу или по инфраструктуре доставки. Отсюда и ситуации, когда целились в один ресурс, а жалобы приходят по другому, просто потому что они «соседи» по тем же узлам доставки.
Как проявляются ограничения и как их разбирать по метрикам
Для пользователя обычно есть три сценария: «не открывается», «открывается через раз» и «вроде работает, но пользоваться невозможно». Первый ближе к прямой фильтрации, когда соединение не устанавливается, пакеты не доходят или TCP-сессия обрывается. Второй часто связан с динамикой IP, балансировкой и тем, что правила применяются не везде одинаково. Третий самый неприятный, потому что это деградация: сервис не падает, но качество заметно ухудшается.
Прямая фильтрация часто выглядит как тайм-аут или быстрый разрыв соединения. В TCP можно увидеть внезапные RST, особенно если вмешательство идет на уровне управления сессией. В UDP и QUIC чаще встречается «тишина»: приложение просто повторяет попытки, потому что подтверждения не приходят. И здесь легко ошибиться с диагнозом: один пинг до публичного DNS может быть идеальным, потому что вы тестируете другой тип трафика и иногда другой путь.
При деградации картина другая. Растет RTT, появляется джиттер, увеличиваются потери, растет число повторов передач. Видеозвонок начинает «квадратить», VPN уходит в переподключения, веб открывается, но тяжелые элементы не догружаются. Часто это проявляется не постоянно, а в конкретные часы, на пике нагрузки, или только на отдельных направлениях, где политики применяются активнее.
Чтобы быстрее ориентироваться в симптомах, удобно держать под рукой простую матрицу: что происходит, как это выглядит, что проверить первым делом и где обычно прячется побочный эффект. Это не заменяет полноценный разбор, но помогает не распыляться на хаотичные проверки.
| Режим воздействия | Как выглядит | Что проверить | Типичный побочный эффект |
|---|---|---|---|
| Прямая фильтрация | тайм-ауты, разрывы соединений | сравнение из разных сетей, проверка по портам, захват трафика | цепляет соседние IP и CDN |
| Разрыв сессии | RST в TCP, внезапные отключения | тайминги разрыва, повторяемость, длительные сессии | ломаются VoIP (телефония по IP), видеосвязь и VPN |
| Деградация | работает, но тормозит и нестабильно | RTT, джиттер, потери, повторы передач, тесты в пике | похоже на проблемы магистрали, хотя источник ближе |
Практический минимум, который стоит собирать в инциденте, выглядит так. Делайте не один тест, а короткие серии измерений из разных сетей и в разные часы. Очень помогают «контрольные» точки: домашний интернет одного оператора, мобильный другого, корпоративный канал, облачная ВМ в другом ASN. Когда есть сравнение, быстрее видно, где именно проявляется проблема.
-
Снимайте mtr, утилитой трассировки с потерями и задержками, сериями и обязательно фиксируйте время. Одна трасса почти никогда ничего не доказывает.
-
Для веба проверяйте отдельно TCP 443 и QUIC, если сервис его использует. Разница между ними часто подсказывает сценарий.
-
Смотрите потери и повторы передач на стороне клиента. Если они растут без ваших локальных причин, это сильный сигнал.
-
Держите синтетические проверки именно на бизнес-сервисы, а не только на «интернет в целом». Видеозвонок и сайт это разные классы трафика.
-
Собирайте ошибки приложений и временные метки. Это часто точнее, чем усредненные графики по сети.
И главный вывод. ТСПУ и «суверенный Рунет» в инженерной реальности это дополнительный слой инфраструктуры и политик рядом с маршрутизацией, балансировкой и CDN. Он повышает управляемость со стороны регулятора, но одновременно увеличивает цену ошибок и делает наблюдаемость критически важной. Если вы отвечаете за сервисы или за сеть, лучше заранее иметь простой диагностический чек-лист и набор контрольных точек. Тогда «не работает» превращается в понятный тикет с метриками и фактами, а не в бесконечную переписку.
Если нужен официальный контекст, удобнее начинать с первоисточников: закон № 90-ФЗ на kremlin.ru ( 90-ФЗ) и постановление № 1667 на портале правовой информации ( № 1667).
