10fb7f4e18
- Раздел 22: Балансировщик: мониторинг и диагностика - Раздел 23: Распознавание протоколов (DPI Engine) - Раздел 24: Траблшутинг Каждый раздел включает команды, описания и практические примеры для диагностики и мониторинга работы балансировщика и системы фильтрации.
157 lines
20 KiB
Markdown
157 lines
20 KiB
Markdown
# 8. Формирование протокольных списков (двухстадийная блокировка)
|
||
|
||
[← Оглавление](../README.md) · [← Раздел 7: Эшелонированная система](07.md)
|
||
|
||
---
|
||
|
||
## 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**.
|
||
|
||
```text
|
||
ТСПУ тип А (площадка) Центральная система управления
|
||
┌──────────────────────┐ ┌──────────────────────────┐
|
||
│ │ │ │
|
||
│ Фильтр 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-адресам и портам — без участия фильтров.
|
||
|
||
```text
|
||
Центральная система управления
|
||
┌──────────────────────────────┐
|
||
│ Очищенные списки │
|
||
│ (IP + порт для каждого │
|
||
│ протокола) │
|
||
└───────┬──────────┬──────────┘
|
||
│ │
|
||
HTTP │ │ BGP
|
||
│ │
|
||
▼ ▼
|
||
┌───────────┐ ┌───────────┐
|
||
│ Фильтры │ │ Eco │
|
||
│ ТСПУ А │ │ Highway │
|
||
│ │ │ ТСПУ Б │
|
||
│ DPI-лист 5│ │ │
|
||
│ behavior: │ │ Блокировка│
|
||
│ block │ │ по L3/L4 │
|
||
└───────────┘ └───────────┘
|
||
```
|
||
|
||
Фильтры ТСПУ тип Б получают от Eco Highway только тот трафик, который требует URL-фильтрации по реестру РКН. Блокировка протоколов в прошивке фильтров эшелона **отсутствует** — она не нужна, поскольку этим занимается сам балансировщик.
|
||
|
||
## 8.6. Время полного цикла блокировки: ~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) · [← Раздел 7: Эшелонированная система](07.md) · [Раздел 9: Центральная система управления →](09.md)
|