diff --git a/chapters/08.md b/chapters/08.md deleted file mode 100644 index fe19b39..0000000 --- a/chapters/08.md +++ /dev/null @@ -1,156 +0,0 @@ -# 8. Формирование протокольных списков (двухстадийная блокировка) - -[← Оглавление](../README.md) · [← Раздел 7: Эшелонированная система](07.md) - ---- - -## 8.1. Первый этап: распознавание протоколов на фильтрах (ТСПУ тип А) - -Блокировка протоколов (Telegram, WhatsApp, Viber и др.) в системе ТСПУ реализована **в два этапа** — так называемая двухстадийная блокировка. Необходимость двухстадийного подхода обусловлена природой распознавания шифрованного трафика: фильтр анализирует сессию по множеству косвенных признаков (размеры пакетов, частота прохождения, вариации размеров, ключевые слова внутри пакетов), и такое распознавание **не является стопроцентным**. Возможны ложноположительные срабатывания — когда другой шифрованный трафик по тем же критериям ошибочно распознаётся как, например, Telegram. Прямая блокировка по результатам DPI на фильтре привела бы к случайной блокировке легитимных ресурсов. - -На **первом этапе** фильтры ТСПУ тип А выполняют только **распознавание** протоколов, но **не блокируют** их: - -1. Трафик проходит через фильтр и обрабатывается движком DPI; -2. DPI-движок анализирует каждую сессию по множеству параметров (многофакторный анализ) и определяет, к какому протоколу она относится; -3. Фильтр фиксирует результат распознавания в виде **протокольного лога** — записи о том, что конкретная сессия предварительно опознана как сессия определённого протокола; -4. Сессия при этом **не блокируется** — трафик продолжает проходить без ограничений. - -Распознавание выполняется в отдельном DPI-листе, на котором установлен режим **behavior: ignore** — это означает, что срабатывание правил фиксируется, но никаких блокирующих действий не предпринимается. Лист 0 для этого не используется: в нём по умолчанию работает фильтрация по реестру Роскомнадзора ([раздел 5.1.3](05.md)). - -## 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 | -|----------|-----------|----------| -| Лист распознавания | Распознавание протоколов (первый этап) | **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-фильтрации по реестру РКН. Блокировка протоколов в прошивке фильтров эшелона **отсутствует** — она не нужна, поскольку этим занимается сам балансировщик. - -## 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) diff --git a/chapters/21.md b/docs/balancer-config.md similarity index 100% rename from chapters/21.md rename to docs/balancer-config.md diff --git a/chapters/22.md b/docs/balancer-monitoring.md similarity index 100% rename from chapters/22.md rename to docs/balancer-monitoring.md diff --git a/chapters/20.md b/docs/balancer-platform.md similarity index 100% rename from chapters/20.md rename to docs/balancer-platform.md diff --git a/chapters/04.md b/docs/balancer.md similarity index 100% rename from chapters/04.md rename to docs/balancer.md diff --git a/chapters/03.md b/docs/bypass.md similarity index 100% rename from chapters/03.md rename to docs/bypass.md diff --git a/chapters/09.md b/docs/central-management.md similarity index 100% rename from chapters/09.md rename to docs/central-management.md diff --git a/chapters/07.md b/docs/echelon.md similarity index 100% rename from chapters/07.md rename to docs/echelon.md diff --git a/chapters/16.md b/docs/filter-acl-pools.md similarity index 100% rename from chapters/16.md rename to docs/filter-acl-pools.md diff --git a/chapters/13.md b/docs/filter-cli.md similarity index 100% rename from chapters/13.md rename to docs/filter-cli.md diff --git a/chapters/17.md b/docs/filter-dpi.md similarity index 100% rename from chapters/17.md rename to docs/filter-dpi.md diff --git a/chapters/19.md b/docs/filter-firmware.md similarity index 100% rename from chapters/19.md rename to docs/filter-firmware.md diff --git a/chapters/15.md b/docs/filter-interfaces.md similarity index 100% rename from chapters/15.md rename to docs/filter-interfaces.md diff --git a/chapters/18.md b/docs/filter-monitoring.md similarity index 100% rename from chapters/18.md rename to docs/filter-monitoring.md diff --git a/chapters/11.md b/docs/filter-platform.md similarity index 100% rename from chapters/11.md rename to docs/filter-platform.md diff --git a/chapters/12.md b/docs/filter-sessions.md similarity index 100% rename from chapters/12.md rename to docs/filter-sessions.md diff --git a/chapters/14.md b/docs/filter-subsystems.md similarity index 100% rename from chapters/14.md rename to docs/filter-subsystems.md diff --git a/chapters/05.md b/docs/filter.md similarity index 100% rename from chapters/05.md rename to docs/filter.md diff --git a/chapters/10.md b/docs/management-segment.md similarity index 100% rename from chapters/10.md rename to docs/management-segment.md diff --git a/chapters/01.md b/docs/overview.md similarity index 100% rename from chapters/01.md rename to docs/overview.md diff --git a/chapters/06.md b/docs/placement.md similarity index 100% rename from chapters/06.md rename to docs/placement.md diff --git a/chapters/23.md b/docs/protocol-blocking.md similarity index 100% rename from chapters/23.md rename to docs/protocol-blocking.md diff --git a/chapters/02.md b/docs/traffic-flow.md similarity index 100% rename from chapters/02.md rename to docs/traffic-flow.md diff --git a/chapters/24.md b/docs/troubleshooting.md similarity index 100% rename from chapters/24.md rename to docs/troubleshooting.md