tspu-docs/chapters/08.md

8. Формирование протокольных списков (двухстадийная блокировка)

← Оглавление · ← Раздел 7: Эшелонированная система

---

8.1. Первый этап: распознавание протоколов на фильтрах (ТСПУ тип А)

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

На первом этапе фильтры ТСПУ тип А выполняют только распознавание протоколов, но не блокируют их:

1. Трафик проходит через фильтр и обрабатывается движком DPI;
2. DPI-движок анализирует каждую сессию по множеству параметров (многофакторный анализ) и определяет, к какому протоколу она относится;
3. Фильтр фиксирует результат распознавания в виде протокольного лога — записи о том, что конкретная сессия предварительно опознана как сессия определённого протокола;
4. Сессия при этом не блокируется — трафик продолжает проходить без ограничений.

Распознавание выполняется в рамках DPI-листа (например, DPI-лист 0), на котором установлен режим behavior: ignore — это означает, что срабатывание правил фиксируется, но никаких блокирующих действий не предпринимается.

8.2. Отправка логов на SPFS (сервер предварительного формирования списков)

Протокольные логи с результатами распознавания отправляются с фильтров на SPFS (сервер предварительного формирования списков), расположенный на той же площадке ТСПУ.

Отправка настраивается в секции debug logger конфигурации фильтра:

• Включение отправки — секция активируется для нужных протоколов;
• Выбор протоколов — по умолчанию all (все распознаваемые протоколы), но можно указать только конкретные (Telegram, WhatsApp и т.д.);
• Количество пакетов на протокол — определяет, сколько пакетов из каждой распознанной сессии будет отправлено в лог. По умолчанию значение 0 (без ограничения, что соответствует первым 30 пакетам). На практике для корректного анализа достаточно 3 пакетов — это значение было подтверждено в ходе тестов на Урале. Значение 30 генерирует избыточный объём лог-трафика;
• Лог-интерфейс — по умолчанию используется выделенный лог-интерфейс (DPDK). Возможно переключение на management-интерфейс, однако это не рекомендуется, так как производительность отправки логов значительно снизится;
• Адрес и порт назначения — указываются координаты сервера SPFS на площадке.

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

8.3. Передача логов по GRPC в центральную систему управления

Накопленные и предварительно обработанные логи SPFS передаёт в центральную систему управления (ЦСУ) по протоколу gRPC.

    ТСПУ тип А (площадка)               Центральная система управления
    ┌──────────────────────┐             ┌──────────────────────────┐
    │                      │             │                          │
    │  Фильтр 1 ──┐       │             │  Подсистема формирования │
    │  Фильтр 2 ──┼→ SPFS ├── gRPC ───→│  списков фильтрации      │
    │  Фильтр N ──┘       │             │                          │
    │                      │    VPN      │  • Сбор логов со всех   │
    └──────────────────────┘  (Континент)│    площадок ТСПУ тип А  │
                                         │  • Сохранение в БД       │
    ТСПУ тип А (площадка)               │  • Периодический анализ  │
    ┌──────────────────────┐             │  • Формирование списков  │
    │                      │             │                          │
    │  Фильтр 1 ──┐       │             └──────────────────────────┘
    │  Фильтр 2 ──┼→ SPFS ├── gRPC ───→
    │  Фильтр N ──┘       │
    │                      │
    └──────────────────────┘

ЦСУ представляет собой многокомпонентную распределённую систему, развёрнутую на двух независимых площадках. Связь между площадками ТСПУ и ЦСУ осуществляется через VPN (криптошлюз «Континент»). Данные поступают со всех площадок ТСПУ тип А по всей стране — это порядка 350 площадок и около 5 000 устройств.

Протокольные логи отправляются только с фильтров ТСПУ тип А (первого эшелона). Фильтры ТСПУ тип Б (эшелон) протокольных логов не генерируют — на них отсутствует функционал распознавания протоколов, поскольку блокировка протоколов на эшелоне выполняется самим балансировщиком Eco Highway по уже готовым спискам.

8.4. Анализ, очистка от ложных срабатываний, формирование списков

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

Сбор и хранение. Логи со всех площадок ТСПУ тип А сохраняются в базе данных ЦСУ. Система агрегирует данные с множества фильтров, что даёт ей значительно более полную картину, чем та, которую видит каждый отдельный фильтр.

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

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

• Сопоставление сессий с различных устройств — ЦСУ видит данные с множества фильтров на разных площадках, а не только с одного конкретного. Это позволяет выявлять закономерности, недоступные на уровне единичного фильтра;
• Статистический анализ — использование накопленных статистических данных для верификации результатов распознавания;
• Обогащение данных — дополнение результатов распознавания сторонней информацией для повышения точности;
• Выделение конкретных адресов — на примере Telegram: из всех сессий, распознанных как Telegram, формируется список IP-адресов и портов, на которых были обнаружены серверы Telegram или его прокси различных типов.

Формирование очищенных списков. По результатам анализа создаются очищенные списки, в которых вероятность ложноположительного срабатывания крайне низка. Эти списки содержат конкретные IP-адреса и порты (для каждого протокола — свой список), которые система с высокой степенью уверенности идентифицировала как принадлежащие блокируемому протоколу.

8.5. Загрузка очищенных списков обратно на фильтры (HTTP) и на Eco Highway (BGP)

Сформированные очищенные списки загружаются обратно на оборудование ТСПУ двумя путями:

Загрузка на фильтры ТСПУ тип А (по HTTP)

Очищенные списки загружаются на фильтры по протоколу HTTP в отдельный DPI-лист, отличный от того, в котором выполняется распознавание:

DPI-лист	Назначение	Behavior
DPI-лист 0	Распознавание протоколов (первый этап)	ignore — срабатывание фиксируется, но не блокируется
DPI-лист 5 (пример)	Блокировка по очищенным спискам из ЦСУ	block — трафик блокируется

Таким образом, на одном фильтре одновременно работают два процесса:

• в DPI-листе 0 продолжается распознавание новых сессий и отправка логов;
• в DPI-листе 5 выполняется блокировка по уже проверенным и очищенным спискам.

Загрузка на Eco Highway (по BGP)

Те же очищенные списки, но в несколько ином формате, загружаются по протоколу BGP на балансировщики Eco Highway (ТСПУ тип Б). На эшелоне блокировка протоколов выполняется самим балансировщиком по IP-адресам и портам — без участия фильтров.

    Центральная система управления
    ┌──────────────────────────────┐
    │  Очищенные списки            │
    │  (IP + порт для каждого     │
    │   протокола)                │
    └───────┬──────────┬──────────┘
            │          │
        HTTP │          │ BGP
            │          │
            ▼          ▼
    ┌───────────┐  ┌───────────┐
    │  Фильтры  │  │   Eco     │
    │  ТСПУ А   │  │  Highway  │
    │           │  │  ТСПУ Б   │
    │ DPI-лист 5│  │           │
    │ behavior: │  │ Блокировка│
    │   block   │  │ по L3/L4  │
    └───────────┘  └───────────┘

Фильтры ТСПУ тип Б получают от Eco Highway только тот трафик, который требует URL-фильтрации по реестру РКН. Блокировка протоколов в прошивке фильтров эшелона отсутствует — она не нужна, поскольку этим занимается сам балансировщик.

8.6. Время полного цикла блокировки: ~5–15 минут

Полный цикл двухстадийной блокировки — от момента появления нового, ранее неизвестного сервера блокируемого протокола до его фактической блокировки — составляет от 5 до 15 минут.

    ┌────────────────────────────────────────────────────────────────┐
    │                    Полный цикл блокировки                     │
    │                                                               │
    │  1. Абонент подключается к новому серверу       ─┐            │
    │     (например, новая Telegram-прокси)             │            │
    │                                                   │ ~5–15 мин │
    │  2. Фильтр распознаёт протокол (DPI)             │            │
    │  3. Лог отправляется на SPFS                     │            │
    │  4. SPFS передаёт в ЦСУ (gRPC)                   │            │
    │  5. ЦСУ анализирует и формирует список           │            │
    │  6. Список загружается на фильтры (HTTP)         │            │
    │     и Eco Highway (BGP)                          │            │
    │  7. Блокировка активируется                     ─┘            │
    └────────────────────────────────────────────────────────────────┘

Эти данные получены в ходе тестирования эшелонированной системы в тестовой зоне в Сургуте. Время полного цикла зависит от настроек:

• Периодичность анализа на ЦСУ — чем чаще запускается анализ базы данных (например, раз в минуту вместо раз в 5 минут), тем быстрее формируются списки, но тем выше нагрузка на серверы;
• Настройки SPFS — параметры накопления и предварительной обработки логов;
• Количество сессий по данному протоколу — при большом количестве сессий (много абонентов используют блокируемый протокол) блокировка срабатывает быстрее, так как данных для анализа больше.

Важно: до момента обновления списка фильтр не обрывает существующие сессии блокируемого протокола. Например, если появилась новая Telegram-прокси, которая ранее нигде не была зафиксирована, абонент может свободно работать через неё до тех пор, пока фильтр не получит обновлённый список, содержащий адрес этой прокси.

Поскольку проект подобного масштаба реализуется впервые, текущие параметры основаны на эмпирических данных из тестовых сегментов. Не исключена корректировка параметров в ту или иную сторону по мере накопления опыта эксплуатации. Если серверы будут перегружаться, можно снизить частоту анализа — это увеличит время блокировки, но позволит существующим серверам справляться с нагрузкой.

---

← Оглавление · ← Раздел 7: Эшелонированная система · Раздел 9: Центральная система управления →