10fb7f4e18
- Раздел 22: Балансировщик: мониторинг и диагностика - Раздел 23: Распознавание протоколов (DPI Engine) - Раздел 24: Траблшутинг Каждый раздел включает команды, описания и практические примеры для диагностики и мониторинга работы балансировщика и системы фильтрации.
216 lines
27 KiB
Markdown
216 lines
27 KiB
Markdown
# 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)
|