DanielLavrushin_tspu-docs/docs/protocol-blocking.md

# 22. Распознавание протоколов и двухстадийная блокировка

[← Оглавление](../README.md) · [← Раздел 21: Центральная система управления](central-management.md)

---

Распознавание протоколов — одна из ключевых функций фильтра ТСПУ. Внутренний движок DPI анализирует проходящие сессии и определяет, к какому протоколу или приложению они относятся: Telegram, WhatsApp, Viber, OpenVPN, BitTorrent и другие. Распознавание особенно важно для **шифрованного трафика**, где нет очевидных полей, указывающих на конкретный протокол, и идентификация выполняется **косвенным образом**.

## 22.1. Многофакторный анализ сессий

DPI-движок фильтра анализирует не отдельные пакеты, а **целые сессии**. Для распознавания необходимо, чтобы в рамках одной сессии прошло **несколько пакетов** в обоих направлениях — одного первого пакета недостаточно.

Анализ проводится по **множеству параметров одновременно** — их может быть десяток и более. Совокупность этих параметров формирует уникальный «профиль» трафика конкретного протокола.

### 22.1.1. Размеры пакетов и их вариации

Один из ключевых параметров анализа — **размеры пакетов** в рамках сессии и их **вариации**:

- Средний размер пакетов;
- Разброс размеров (минимальный, максимальный, стандартное отклонение);
- Характерные паттерны размеров (например, первые пакеты одного размера, последующие — другого).

Разные протоколы и приложения генерируют пакеты с **характерными размерными профилями**. Например, голосовой трафик мессенджера будет иметь иной размерный профиль, чем передача файлов через тот же мессенджер.

### 22.1.2. Частота прохождения пакетов

**Частота прохождения пакетов** — ещё один важный параметр:

- Интервалы между пакетами;
- Регулярность или нерегулярность этих интервалов;
- Всплески активности и паузы.

Голосовые вызовы, например, генерируют поток пакетов с **регулярными короткими интервалами**, тогда как обмен текстовыми сообщениями создаёт **нерегулярный** трафик с длительными паузами.

### 22.1.3. Ключевые слова и паттерны внутри пакетов

DPI-движок также анализирует **содержимое пакетов** — ищет характерные ключевые слова, последовательности байтов и структурные паттерны:

- Специфичные заголовки и поля протокола;
- Характерные байтовые последовательности (сигнатуры);
- Структура данных внутри пакета (порядок полей, длины полей).

Помимо очевидных параметров (source/destination IP, порты), анализируются **менее очевидные** признаки, которые в совокупности позволяют отнести сессию к конкретному протоколу.

### 22.1.4. Особенности анализа шифрованного трафика

Шифрованный трафик представляет **особую сложность** для распознавания:

- Содержимое пакетов зашифровано — нет очевидных полей, указывающих на протокол;
- Ключевые слова и сигнатуры **недоступны** для анализа;
- Распознавание выполняется **исключительно косвенными методами** — по размерам пакетов, частоте, вариациям и другим статистическим параметрам.

Для распознавания шифрованных протоколов (например, Telegram) используется **многофакторный анализ** — математическая модель, которая на основе совокупности косвенных признаков делает вывод о принадлежности сессии к конкретному протоколу. Конкретные алгоритмы и математика этого анализа являются внутренней разработкой и в открытом виде не раскрываются.

> **Принцип работы:** DPI-движок берёт сессию (не один пакет, а несколько пакетов в обоих направлениях), анализирует их по множеству параметров и принимает решение — например, «данный трафик в этой сессии — это Telegram» или «это WhatsApp».

## 22.2. Ложноположительные срабатывания

Многофакторный анализ **не является стопроцентным** — возможны **ложноположительные срабатывания** (false positives), когда один шифрованный трафик по тем же косвенным критериям ошибочно распознаётся как другой протокол.

Причины ложноположительных срабатываний:

| Причина                          | Описание                                                                                    |
| -------------------------------- | ------------------------------------------------------------------------------------------- |
| **Похожие профили трафика**      | Разные протоколы могут генерировать трафик с похожими размерами пакетов и частотой          |
| **Шифрование скрывает различия** | Без доступа к содержимому пакетов анализ опирается на меньше признаков                      |
| **Новые версии протоколов**      | Обновления приложений могут изменить профиль трафика, сделав его похожим на другой протокол |

**Последствия ложного срабатывания:** если фильтр ошибочно распознал легитимный трафик как блокируемый протокол и сразу заблокировал его — пользователь потеряет доступ к полезному ресурсу. Именно поэтому прямая блокировка по результатам DPI на фильтре **не применяется** для протоколов — вместо этого используется двухстадийная схема.

## 22.3. Обфускация и борьба с обходом блокировок

Обфускация — это намеренное изменение характеристик протокола, направленное на то, чтобы DPI-движок **не смог его распознать**. Это постоянная «гонка вооружений» между разработчиками средств обхода блокировок и разработчиками систем фильтрации.

### Принцип «нанайских мальчиков»

Борьба между системами обхода и системами блокировки описывается как **постоянное противостояние**: одна сторона в какой-то момент имеет преимущество, которое затем нивелируется следующим шагом противоположной стороны.

### Типы обфускации и возможности распознавания

| Тип обфускации                              | Возможность распознавания                                              |
| ------------------------------------------- | ---------------------------------------------------------------------- |
| **Простая** (например, XOR)                 | Фильтр может «развернуть» обфускацию и распознать протокол             |
| **Протокол притворяется другим**            | Распознавание возможно, но требует разработки новых сигнатур и методик |
| **Качественная имитация другого протокола** | Распознать **невозможно** без разработки принципиально нового подхода  |

### Обновление сигнатур

Когда обнаруживается, что новая версия приложения или протокола **перестала распознаваться** фильтром, это означает необходимость:

1. **Анализа изменений** — что именно изменилось в новой версии протокола;
2. **Разработки новой сигнатуры** — обновление правил распознавания для учёта изменений;
3. **Обновления прошивки** — доставка обновлённого DPI-движка на фильтры.

> **Практический подход:** к этому процессу следует относиться с пониманием — это нормальная и ожидаемая ситуация. Полное и постоянное распознавание всех протоколов **невозможно** в принципе. Задача системы — поддерживать актуальные сигнатуры и оперативно реагировать на изменения.

### Защита от ложных блокировок при борьбе с обфускацией

Двухстадийная система блокировки (раздел 22.4) особенно важна в контексте борьбы с обфускацией. Обфусцированный трафик **по определению** имеет нестандартный профиль, что повышает вероятность ложноположительного срабатывания. Централизованная очистка на ЦСУ снижает этот риск, сопоставляя данные с множества источников.

## 22.4. Двухстадийная блокировка: распознавание → очистка в ЦСУ → блокировка

Для минимизации ложноположительных срабатываний блокировка протоколов выполняется **в два этапа** (этапы подробно описаны ниже — в [разделах 22.5–22.10](#225-первый-этап-распознавание-протоколов-на-фильтрах-тспу-тип-а)):

```text
    ┌─────────────────────────────────────────────────────────────────┐
    │  Этап 1: Распознавание (фильтр)                                │
    │                                                                 │
    │  • DPI-движок анализирует сессию                               │
    │  • Определяет протокол (Telegram, WhatsApp, ...)               │
    │  • Результат записывается в лог                                │
    │  • Трафик НЕ БЛОКИРУЕТСЯ (behavior: ignore)                    │
    │  • Логи отправляются на SPFS → ЦСУ                             │
    └──────────────────────────┬──────────────────────────────────────┘
                               │
                               ▼
    ┌─────────────────────────────────────────────────────────────────┐
    │  Очистка (ЦСУ)                                                  │
    │                                                                 │
    │  • Сбор логов со ВСЕХ площадок (~350 площадок, ~5000 устройств)│
    │  • Сопоставление сессий с разных фильтров                      │
    │  • Глубокий статистический анализ                               │
    │  • Обогащение данных сторонней информацией                      │
    │  • Формирование очищенных списков (IP + порт)                  │
    │  • Вероятность ложного срабатывания — крайне низка              │
    └──────────────────────────┬──────────────────────────────────────┘
                               │
                               ▼
    ┌─────────────────────────────────────────────────────────────────┐
    │  Этап 2: Блокировка (фильтр / Eco Highway)                     │
    │                                                                 │
    │  • Очищенные списки загружаются на фильтры (HTTP)              │
    │    и на Eco Highway (BGP)                                      │
    │  • Загрузка в ОТДЕЛЬНЫЙ DPI-лист (не тот, где распознавание)   │
    │  • На этом DPI-листе: behavior: block                          │
    │  • Блокировка по проверенным адресам                           │
    └─────────────────────────────────────────────────────────────────┘
```

### Разделение DPI-листов

На одном фильтре **одновременно работают два процесса**:

| DPI-лист            | Behavior   | Назначение                                             |
| ------------------- | ---------- | ------------------------------------------------------ |
| Лист распознавания  | **ignore** | Распознавание протоколов, запись логов, без блокировки |
| DPI-лист 5 (пример) | **block**  | Блокировка по очищенным спискам из ЦСУ                 |

Таким образом, распознавание и блокировка выполняются **в разных DPI-листах** — это позволяет независимо управлять каждым процессом.

### Преимущества централизованного анализа

ЦСУ видит данные **со всех фильтров на всех площадках**, а не только с одного конкретного устройства. Это даёт принципиально **более полную картину**:

- Один фильтр видит только «свои» сессии — ЦСУ видит **все сессии** по всей стране;
- Статистический анализ на большой выборке **значительно точнее**;
- Возможность обогащения данных **сторонней информацией** повышает качество распознавания.

### Время полного цикла

От момента появления нового, ранее неизвестного сервера блокируемого протокола до его фактической блокировки проходит **от 5 до 15 минут** (подробнее — в [разделе 22.10](#2210-время-полного-цикла-блокировки-515-минут)).

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

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

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

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

Распознавание выполняется в отдельном DPI-листе, на котором установлен режим **behavior: ignore** — это означает, что срабатывание правил фиксируется, но никаких блокирующих действий не предпринимается. Лист 0 для этого не используется: в нём по умолчанию работает фильтрация по реестру Роскомнадзора ([раздел 10.1.3](filter.md)).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таким образом, на одном фильтре **одновременно работают два процесса**:
- в листе распознавания продолжается распознавание новых сессий и отправка логов;
- в DPI-листе 5 выполняется блокировка по уже проверенным и очищенным спискам.

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

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

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

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

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

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

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

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

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

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

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

---

[← Оглавление](../README.md) · [← Раздел 21: Центральная система управления](central-management.md) · [Раздел 23: Траблшутинг →](troubleshooting.md)