From f0cfc45844c9b0ca91258918d4eb922f84190c8f Mon Sep 17 00:00:00 2001 From: Daniel Lavrushin Date: Fri, 20 Feb 2026 12:45:12 +0100 Subject: [PATCH] =?UTF-8?q?=D0=9E=D0=B1=D0=BD=D0=BE=D0=B2=D0=BB=D0=B5?= =?UTF-8?q?=D0=BD=D0=BE=20=D0=BE=D0=B3=D0=BB=D0=B0=D0=B2=D0=BB=D0=B5=D0=BD?= =?UTF-8?q?=D0=B8=D0=B5=20=D0=B8=20=D0=B4=D0=BE=D0=B1=D0=B0=D0=B2=D0=BB?= =?UTF-8?q?=D0=B5=D0=BD=D1=8B=20=D0=BD=D0=BE=D0=B2=D1=8B=D0=B5=20=D1=80?= =?UTF-8?q?=D0=B0=D0=B7=D0=B4=D0=B5=D0=BB=D1=8B=20=D0=BE=20=D1=8D=D1=88?= =?UTF-8?q?=D0=B5=D0=BB=D0=BE=D0=BD=D0=B8=D1=80=D0=BE=D0=B2=D0=B0=D0=BD?= =?UTF-8?q?=D0=BD=D0=BE=D0=B9=20=D1=81=D0=B8=D1=81=D1=82=D0=B5=D0=BC=D0=B5?= =?UTF-8?q?=20=D0=B8=20=D1=84=D0=BE=D1=80=D0=BC=D0=B8=D1=80=D0=BE=D0=B2?= =?UTF-8?q?=D0=B0=D0=BD=D0=B8=D0=B8=20=D0=BF=D1=80=D0=BE=D1=82=D0=BE=D0=BA?= =?UTF-8?q?=D0=BE=D0=BB=D1=8C=D0=BD=D1=8B=D1=85=20=D1=81=D0=BF=D0=B8=D1=81?= =?UTF-8?q?=D0=BA=D0=BE=D0=B2?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- 01.md | 2 +- 07.md | 215 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 08.md | 157 +++++++++++++++++++++++++++++++++++++++ README.md | 4 +- 4 files changed, 375 insertions(+), 3 deletions(-) create mode 100644 07.md create mode 100644 08.md diff --git a/01.md b/01.md index b263b73..e681061 100644 --- a/01.md +++ b/01.md @@ -127,4 +127,4 @@ --- -[← Оглавление](README.md) · [Раздел 2: Прохождение трафика через ТСПУ →](02-traffic-path.md) +[← Оглавление](README.md) · [Раздел 2: Прохождение трафика через ТСПУ →](02.md) diff --git a/07.md b/07.md new file mode 100644 index 0000000..6e9d844 --- /dev/null +++ b/07.md @@ -0,0 +1,215 @@ +# 7. Эшелонированная система (ТСПУ тип Б) + +[← Оглавление](README.md) · [← Раздел 6: Места установки ТСПУ](06.md) + +--- + +## 7.1. Назначение: обработка трафика, не прошедшего через ТСПУ тип А + +Эшелонированная система (ТСПУ тип Б, второй эшелон) предназначена для **обработки трафика, который не прошёл через стандартные ТСПУ** (тип А, первый эшелон). + +Когда в тексте упоминается просто «ТСПУ» без уточнения типа, подразумевается **ТСПУ тип А** — именно этот тип рассматривался во всех предыдущих разделах. ТСПУ тип А устанавливается у большинства операторов и покрывает основную массу трафика. Однако у крупных операторов связи существуют ситуации, когда часть трафика не может быть обработана стандартными средствами — для таких случаев создана эшелонированная система. + +Идея эшелонирования возникла как способ **сократить общее количество ТСПУ**, развёртываемых по стране. Вместо установки ТСПУ тип А у каждого мелкого оператора на уровне доступа, можно у нескольких крупных операторов в ключевых точках установить двухстадийную систему фильтрации, что позволяет снизить затраты на реализацию проекта. + +## 7.2. Проблема асимметричного трафика у крупных операторов + +Сеть крупного оператора связи, если идти от абонентов к выходу в интернет, делится на несколько сегментов: + +```text + ┌─────────────────────────────────────────────────────────┐ + │ Сегмент доступа и распределения │ + │ • Абоненты │ + │ • Небольшие операторы (single-home) │ + │ • Корпоративные заказчики с одним подключением │ + │ │ + │ → Обрабатывается ТСПУ тип А (без проблем) │ + └────────────────────────┬────────────────────────────────┘ + │ + ┌────────────────────────┴────────────────────────────────┐ + │ Уровень ядра и пиринга │ + │ • Крупные операторы связи │ + │ • Крупные корпоративные заказчики │ + │ • Несколько выходов в интернет │ + │ │ + │ → Возможен асимметричный трафик │ + │ → Требуется ТСПУ тип Б (эшелон) │ + └─────────────────────────────────────────────────────────┘ +``` + +На уровне доступа и распределения подключены абоненты и небольшие операторы с единственным каналом связи (single-home). У них нет собственной автономной системы и собственной IP-адресации — адреса выделяет крупный оператор. Весь их трафик проходит через одну точку и обрабатывается стандартным **ТСПУ тип А** без каких-либо проблем. + +На уровне ядра и пиринга подключаются **крупные операторы** и заказчики, которые могут иметь **несколько выходов в интернет** — через разных провайдеров. Их трафик может: + +- выходить через одного оператора, а **возвращаться через другого**; +- проходить через ТСПУ только в одном направлении. + +В таких случаях традиционная схема фильтрации **не работает**: на фильтре ТСПУ тип А сессия «не соберётся», потому что одна сторона сессии проходит через ТСПУ, а ответная — возвращается иным путём, минуя его. Для обработки такого **асимметричного трафика** и предназначен ТСПУ тип Б. + +## 7.3. Балансировщик Eco Highway + +Эшелонированная система, как и ТСПУ тип А, состоит из балансировщика и фильтров, но с существенными отличиями. Балансировщик эшелона называется **Eco Highway** (в отличие от **EcoFilter Balancer** в ТСПУ тип А). Аппаратная платформа **одинакова** — это тот же одноюнитовый 32-портовый коммутатор на базе чипа **Barefoot Tofino**. Различается только **программное обеспечение**. + +Ключевое отличие Eco Highway: он **сам выполняет фильтрацию трафика** на основе заголовков L3/L4 (IP-адреса, порты), а не просто распределяет трафик по фильтрам. + +### 7.3.1. BGP-загрузка списков фильтрации из ЦСУ + +В отличие от EcoFilter Balancer, где правила фильтрации (flow rules) задаются вручную и исчисляются единицами, на Eco Highway списки фильтрации: + +- загружаются автоматически по протоколу **BGP** из центральной системы управления; +- содержат **десятки и сотни тысяч правил**; +- **не могут быть заданы вручную** — это не предусмотрено конструкцией. + +Списки организованы в виде нескольких таблиц, каждая из которых фильтрует по-своему: + +| Тип таблицы | Критерий фильтрации | +| --------------------- | ----------------------------------------- | +| IPv4 адрес + порт | IP-адрес, маска и порт TCP/UDP | +| IPv4 адрес | Только IP-адрес (без порта) | +| IPv6 | Аналогичные таблицы для IPv6-трафика | +| Белый список | Ресурсы, исключённые из фильтрации | +| Port redirect | Трафик, подлежащий отправке на фильтры | + +### 7.3.2. Блокировка по IP-адресам на уровне балансировщика (Telegram, реестр РКН) + +Eco Highway самостоятельно блокирует трафик, который можно идентифицировать по IP-адресам и портам — **без отправки на фильтры**: + +- **Реестр Роскомнадзора** (в части IP-адресов) — все правила блокировки по IP загружаются на балансировщик, что снижает нагрузку на фильтры; +- **Блокировка протоколов** (например, Telegram) — очищенные списки IP-адресов и портов загружаются из ЦСУ по BGP. + +Принципиальное отличие от ТСПУ тип А: на первом эшелоне блокировка протоколов (Telegram и др.) выполняется **на фильтрах** с помощью DPI. На втором эшелоне эта блокировка выполняется **на самом балансировщике** по IP-спискам. Более того, в прошивке фильтров, предназначенных для эшелонированной системы, возможности блокировки протоколов (например, Telegram) **отсутствуют** — они просто не нужны, поскольку этим занимается Eco Highway. + +### 7.3.3. Фильтры в режиме On-a-stick, VLAN-разделение LAN/WAN + +Фильтры в эшелонированной системе подключены **иначе**, чем в ТСПУ тип А: + +| Параметр | ТСПУ тип А (EcoFilter Balancer) | ТСПУ тип Б (Eco Highway) | +| ------------------- | ------------------------------- | -------------------------------------- | +| **Подключение** | Пары портов LAN + WAN | Режим on-a-stick (все порты равноправны) | +| **Разделение LAN/WAN** | На уровне физических портов | На уровне VLAN-тегов | +| **Чётность портов** | Чётные = LAN, нечётные = WAN | Не соблюдается | + +В режиме on-a-stick каждый физический порт фильтра **равноправен**. Разделение между LAN и WAN происходит на уровне специального VLAN-заголовка: + +1. Eco Highway при отправке пакета на фильтр добавляет **VLAN-тег**, обозначающий направление (LAN); +2. Фильтр после обработки **меняет** этот VLAN-тег на другой (WAN); +3. Eco Highway по VLAN-тегу определяет направление и отправляет пакет дальше. + +Таким образом, логическое разделение LAN/WAN сохраняется, но на уровне физики все интерфейсы фильтра однотипные. + +### 7.3.4. Фильтры занимаются только URL-фильтрацией по реестру РКН + +Поскольку блокировка по IP-адресам и протоколам выполняется самим Eco Highway, фильтры в эшелонированной системе занимаются **исключительно URL-фильтрацией** по реестру Роскомнадзора — той частью блокировки, которая требует глубокого анализа содержимого пакетов (DPI) и не может быть выполнена на уровне балансировщика. + +Это означает, что на фильтры отправляется **минимально возможный** объём трафика — только тот, который требует проверки по URL. Всё остальное обрабатывается или пропускается балансировщиком. + +Благодаря упрощённому функционалу (нет распознавания протоколов, нет логирования соединений) производительность фильтров на эшелоне **несколько выше**, чем на ТСПУ тип А — примерно на 15%. Однако разница невелика, и при проектировании рекомендуется использовать те же расчётные цифры производительности, что и для ТСПУ тип А. + +## 7.4. Два конвейера (Pipeline) в Eco Highway + +Внутри чипа Barefoot Tofino, на котором построен балансировщик, существуют **два независимых конвейера** (Pipeline 1 и Pipeline 2) — логические структуры, обрабатывающие входящий трафик на высокой скорости. Каждый конвейер обладает собственным **независимым набором ресурсов**: памятью и вычислительной мощностью. + +На обычном балансировщике (EcoFilter Balancer) оба конвейера **настроены идентично** — в какой бы конвейер ни попал пакет, обработка будет одинаковой. На Eco Highway конвейеры **настраиваются по-разному** — это позволяет в два раза увеличить доступное количество правил фильтрации. + +### 7.4.1. Разделение портов между конвейерами + +Все физические порты балансировщика **жёстко привязаны** к одному из двух конвейеров на заводском уровне — примерно половина портов обслуживается Pipeline 1, половина — Pipeline 2. + +На Eco Highway это разделение используется целенаправленно: + +- **LAN-порты** (в сторону оператора связи) прикрепляются к **одному конвейеру**; +- **WAN-порты** (в сторону интернета) прикрепляются к **другому конвейеру**. + +Принцип чётных/нечётных портов, используемый на EcoFilter Balancer, на эшелоне **не соблюдается** и не имеет значения. + +### 7.4.2. Физическая перемычка между конвейерами + +Поскольку конвейеры **логически изолированы** друг от друга внутри чипа (прямой связи между ними нет), для передачи пакета из одного конвейера в другой используется **физическая перемычка** (jumper) — кабель, соединяющий порт одного конвейера с портом другого. + +```text + ┌──────────────────────────────────────────────────┐ + │ Eco Highway │ + │ │ + │ Pipeline 1 Pipeline 2 │ + │ ┌────────────┐ ┌────────────┐ │ + │ │ Таблицы │ │ Таблицы │ │ + │ │ фильтрации │ │ фильтрации │ │ + │ │ (набор A) │ │ (набор B) │ │ + │ └──────┬─────┘ └──────┬─────┘ │ + │ │ │ │ + │ P41 ←┼── LAN-порты WAN-порты ──┼→ P91 │ + │ P42 ←┘ ┌─┼→ P92 │ + │ │ ┌──────────────┐ │ │ + │ └─────┤ Перемычка ├─────────┘ │ + │ └──────────────┘ │ + │ │ │ │ + │ Порты к фильтрам Порты к фильтрам │ + └──────────────────────────────────────────────────┘ +``` + +Перемычка должна быть рассчитана на **весь объём трафика**, проходящего через балансировщик. В худшем случае весь трафик может пройти через перемычку, поэтому она не должна стать узким местом. При большом количестве высокоскоростных каналов может потребоваться несколько перемычек. + +### 7.4.3. Прохождение пакета: drop / отправка на фильтр / переход на второй конвейер + +Когда пакет попадает на вход Eco Highway, он проходит следующий путь: + +**Шаг 1: Pipeline 1.** Пакет, вошедший через LAN-порт, попадает в конвейер, к которому этот порт привязан. Пакет проходит через все таблицы фильтрации данного конвейера. По результатам возможны **три исхода**: + +1. **Drop** — пакет совпал с запрещающим правилом (например, IP-адрес Telegram) и **дропается**. Дальнейшая обработка не происходит; +2. **Отправка на фильтр** — пакет совпал с правилом перенаправления на фильтры (port redirect). Пакет отправляется на фильтр для URL-фильтрации, обрабатывается и **возвращается напрямую** оператору, минуя второй конвейер; +3. **Переход на Pipeline 2** — пакет не совпал ни с одним правилом первого конвейера. Пакет выходит через порт, принадлежащий Pipeline 1, проходит через **физическую перемычку** и попадает на вход Pipeline 2. + +**Шаг 2: Pipeline 2.** На втором конвейере пакет проходит через **другой набор правил** (отличающийся от первого). Результат аналогичен — drop, отправка на фильтр или пропуск дальше к оператору. + +Важно: после отправки на фильтр пакет **не проходит** через второй конвейер повторно. Обработанный фильтром пакет сразу отправляется оператору через нужный порт. Это было исправлено после первоначальной реализации, где пакет мог дважды попасть на фильтры. + +Также важно: хотя порты привязаны к конвейерам на входе, на **выходе** пакет может быть отправлен через **любой порт** — это логическая сущность обработки, а не жёсткая привязка входа к выходу. Пакет, пришедший через определённый LAN-порт, всё равно вернётся через **парный** ему WAN-порт (сохраняется привязка к линку оператора), но маршрут внутри балансировщика может быть произвольным. + +### 7.4.4. Удвоение количества правил фильтрации + +Разделение правил между двумя конвейерами позволяет **в два раза увеличить** общее количество правил фильтрации на Eco Highway. Память внутри чипа Barefoot Tofino, хранящая эти правила, является **очень быстрой** (работает на скорости провода), но крайне ограниченной по объёму — это, по сути, программируемый TCAM (Content-Addressable Memory). Каждое дополнительное правило — на вес золота. + +На обычном EcoFilter Balancer, где оба конвейера идентичны, удвоение невозможно — один и тот же набор правил дублируется. На Eco Highway каждый конвейер несёт **свой уникальный набор**, удваивая суммарную ёмкость. + +## 7.5. Отличия EcoFilter Balancer от Eco Highway + +| Характеристика | EcoFilter Balancer (тип А) | Eco Highway (тип Б) | +| --------------------------- | -------------------------- | ------------------------------------------- | +| **Аппаратная платформа** | Одинаковая | Одинаковая | +| **Программное обеспечение** | Одно | Другое | +| **Назначение** | Балансировка трафика | Балансировка + самостоятельная фильтрация | +| **Правила фильтрации** | Вручную, единицы | По BGP из ЦСУ, десятки/сотни тысяч | +| **Собственная фильтрация** | Нет (только bypass/balance)| Да (drop по L3/L4-заголовкам) | +| **Конвейеры (Pipeline)** | Настроены идентично | Настроены по-разному (удвоение правил) | +| **Перемычка** | Не требуется | Обязательна (физический кабель) | +| **Подключение фильтров** | Пары LAN/WAN | On-a-stick (VLAN-разделение) | +| **Связь с ЦСУ** | Только management | BGP для загрузки списков | +| **Логирование** | Через фильтры | Отсутствует (только real-time) | + +Разрабатываются обе платформы **одной группой программистов**, и код во многом пересекается. Решения, созданные в рамках реализации Eco Highway, нередко переносятся на EcoFilter Balancer (например, команды программного байпаса), и наоборот. + +## 7.6. Отсутствие логирования на Eco Highway (только real-time) + +На Eco Highway **не ведётся логирование** — информация о дропнутых и перенаправленных пакетах **не отправляется** на серверы логирования. Доступен только **просмотр в реальном времени** (real-time) на самом устройстве, без сохранения истории. + +Причина: объём трафика, проходящего через эшелон, **значительно больше**, чем через ТСПУ тип А. Если ТСПУ тип А обрабатывает трафик конкретного набора абонентов, то ТСПУ тип Б может пропускать через себя трафик множества операторов на уровне ядра сети. Логирование такого объёма потребовало бы несоразмерных ресурсов. + +Протокольные логи (для формирования очищенных списков блокировки) по-прежнему отправляются **только с фильтров первого эшелона** (ТСПУ тип А) через SPFS. + +Для диагностики на Eco Highway доступны следующие возможности: + +- **Просмотр списков в ЦСУ** — можно проверить, содержит ли конкретный IP-адрес или порт в загруженных списках; +- **Программный байпас** — можно перевести Eco Highway в режим полного программного байпаса и проверить, восстанавливается ли доступность у оператора; +- **Проверка на фильтрах** — убедиться, что нужная сессия не обрабатывается и на фильтрах второго эшелона. + +## 7.7. Прозрачный пропуск трафика, уже обработанного ТСПУ тип А + +Eco Highway должен уметь **различать** трафик, уже обработанный ТСПУ тип А на первом эшелоне, и трафик, который первый эшелон не видел. + +Трафик, который **уже прошёл** через ТСПУ тип А (на нижнем уровне, на уровне доступа), **не должен обрабатываться повторно** на втором эшелоне. Для этого на Eco Highway предусмотрена возможность **прозрачного пропуска** такого трафика — он просто «пролетает насквозь» без фильтрации. + +Это позволяет избежать двойной обработки и связанных с ней проблем (удвоение сессий, ложные срабатывания, избыточная нагрузка), аналогичных проблемам двойного прохождения при on-a-stick подключении (подробнее — в [разделе 6.4.3](06.md)). + +--- + +[← Оглавление](README.md) · [← Раздел 6: Места установки ТСПУ](06.md) · [Раздел 8: Формирование протокольных списков →](08.md) diff --git a/08.md b/08.md new file mode 100644 index 0000000..962a160 --- /dev/null +++ b/08.md @@ -0,0 +1,157 @@ +# 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) diff --git a/README.md b/README.md index 47792d1..503e68b 100644 --- a/README.md +++ b/README.md @@ -79,7 +79,7 @@ - 6.4.2. Разделение по VLAN для обработки трафика одного направления - 6.4.3. Проблемы двойной обработки и best practice -### 7. Эшелонированная система (ТСПУ тип Б) +### [7. Эшелонированная система (ТСПУ тип Б)](/07.md) - 7.1. Назначение: обработка трафика, не прошедшего через ТСПУ тип А - 7.2. Проблема асимметричного трафика у крупных операторов @@ -97,7 +97,7 @@ - 7.6. Отсутствие логирования на Eco Highway (только real-time) - 7.7. Прозрачный пропуск трафика, уже обработанного ТСПУ тип А -### 8. Формирование протокольных списков (двухстадийная блокировка) +### [8. Формирование протокольных списков (двухстадийная блокировка)](/08.md) - 8.1. Первый этап: распознавание протоколов на фильтрах (ТСПУ тип А) - 8.2. Отправка логов на SPFS (сервер предварительного формирования списков)