souce/tspu-docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Обновлено оглавление и добавлены новые разделы о эшелонированной системе и формировании протокольных списков

Browse Source
This commit is contained in:
Daniel Lavrushin
2026-02-20 12:45:12 +01:00
parent a4a7802ce8
commit f0cfc45844
4 changed files with 375 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
01.md
View File

@@ -127,4 +127,4 @@
---
[← Оглавление](README.md) · [Раздел 2: Прохождение трафика через ТСПУ →](02-traffic-path.md)
[← Оглавление](README.md) · [Раздел 2: Прохождение трафика через ТСПУ →](02.md)

215
07.md Normal file
View File

@@ -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)

157
08.md Normal file
View File

@@ -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)

4
README.md
View File

@@ -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 (сервер предварительного формирования списков)