Почему централизованная система даёт разный результат в разных сетях

Когда смотришь на блокировки трафика со стороны пользователя, картина выглядит противоречиво: один и тот же сервис в разных сетях работает по‑разному — где‑то не открывается вовсе, где‑то нестабилен, а где‑то продолжает частично функционировать. При этом известно, что управление ограничениями централизовано. Возникает естественный вопрос: если политика едина, почему результат отличается? Причина в том, что речь идёт не об одной точке контроля, а о распределённой системе, где итоговое поведение формируется на пересечении трёх слоёв — централизованного управления, DPI/ТСПУ как контура распознавания и сети оператора как среды исполнения. Именно эта многослойность и объясняет наблюдаемую неравномерность.

Упрощённая модель и её пределы

Распространённая упрощённая модель выглядит примерно так: регулятор вводит ограничения, у операторов установлены технические средства противодействия угрозам (ТСПУ), управляемые централизованно, — следовательно, результат должен быть одинаковым во всех сетях и регионах. Закон и официальные разъяснения действительно описывают централизованный контур управления. Однако централизованная политика не означает физически одинаковое поведение системы в каждой точке. В инженерных системах один control plane не гарантирует идентичный результат на всех узлах data plane — особенно под нагрузкой и при различиях в среде исполнения. Именно здесь и возникает расхождение между ожидаемой и наблюдаемой картиной.

Слой 1 — управление (Control Plane)

Первый слой системы — управление. Центр мониторинга и управления сетью связи общего пользования (ЦМУ ССОП) официально описан как единый узел, через который реализуется государственная политика ограничений интернет-трафика и осуществляется централизованное управление системой ТСПУ. Именно отсюда в модели появляется единый контур управления блокировками. На этом уровне определяется не «как именно разобрать пакет», а скорее «какие классы трафика и какие ресурсы должны быть ограничены».

Слой 2 — DPI / ТСПУ (Detection Engine)

Второй слой — технический: устройства ТСПУ/DPI. Именно здесь решается самая ресурсоёмкая часть задачи — распознать в потоке трафика не только IP‑адрес, но и транспортный протокол (L4), порт, признаки приложения (L5–L7), сигнатуры, попытки маскировки и поведенческие характеристики. В случае зашифрованного или обфусцированного трафика задача усложняется и требует более сложных методов анализа.

Поэтому публичные планы модернизации ТСПУ обычно сосредоточены на трёх направлениях: расширение и актуализация сигнатур, рост пропускной способности и усложнение аналитики — вплоть до применения методов машинного обучения. Иначе говоря, сама по себе команда «заблокировать» не даёт результата: без достаточного качества распознавания и вычислительных ресурсов система не сможет стабильно выделять нужный трафик в общем потоке.

Слой 3 — оператор связи (Execution Environment)

Третий слой — сеть оператора. Это часто недооцениваемый элемент системы. Оператор не формирует централизованную политику и не определяет её содержание. Закон допускает, что провайдер не обязан самостоятельно ограничивать доступ, если это делает ТСПУ в рамках централизованного управления (хотя и не исключает такой возможности).

При этом именно оператор отвечает за то, чтобы трафик в принципе проходил через этот контур: за размещение и питание оборудования, удалённый доступ к нему регулятора, схему пропуска и фактическое прохождение трафика через ТСПУ. В этом смысле оператор — не автор политики, а среда её исполнения. И именно свойства этой среды — топология сети, полнота охвата трафика, особенности маршрутизации — начинают напрямую влиять на итоговый результат.

В отличие от control plane, где формируется и транслируется единая политика, execution environment по определению неоднороден — и именно эта неоднородность приводит к различиям в фактическом поведении системы.

Почему блокировки работают неравномерно

Именно на уровне среды исполнения возникает неравномерность. Любой stateful‑контур анализа чувствителен к маршрутизации, полноте охвата трафика и нагрузке. Например, если нисходящий и восходящий потоки проходят по разным путям (асимметричная маршрутизация), если часть трафика обходит нужный узел, если сегменты сети различаются по степени упорядоченности и согласованности, если отдельные узлы приближаются к пределу мощности — одна и та же команда сверху начинает давать различимый результат снизу.

Поэтому различия между сетями не опровергают централизованный характер системы; напротив, они указывают на то, что результат формируется в распределённой инженерной среде, где одинаковая политика проходит через неоднородные условия исполнения.

Где в этой модели операторский DPI

Отдельный вопрос — есть ли в государственной системе контроля трафика место для собственного операторского DPI помимо ТСПУ. По открытым данным, такое наложение возможно. У операторов есть коммерческие DPI‑платформы для задач уровня BRAS, QoS/QoE‑аналитики, CG‑NAT, anti‑DDoS и выполнения отдельных регуляторных требований.

Кроме того, в отраслевых источниках обсуждалась логика, когда от операторов может требоваться дублирование части ограничений собственными средствами — например, как механизм страховки на случай сбоев или деградации ТСПУ. В результате пользователь местами наблюдает эффект не одного, а нескольких контуров фильтрации: централизованного и локального операторского.

Это, однако, не меняет базовой архитектуры: по открытым признакам, ключевой сигнатурный контур и логика централизованных ограничений находятся вне периметра рядового оператора и реализуются на уровне ТСПУ.

Итоговая модель

Пожалуй, на сегодня самая точная итоговая модель выглядит так: регулятор как контур управления отвечает за «что ограничивать», ТСПУ/DPI — за «как распознать и применить правило», операторская сеть — за «как именно это правило реализуется в конкретной инфраструктуре и маршрутизации».

Как только смотришь на систему в этих трёх измерениях, исчезает главный парадокс. Становится понятно, почему система выглядит централизованной, но на практике даёт разный результат.