10fb7f4e18
- Раздел 22: Балансировщик: мониторинг и диагностика - Раздел 23: Распознавание протоколов (DPI Engine) - Раздел 24: Траблшутинг Каждый раздел включает команды, описания и практические примеры для диагностики и мониторинга работы балансировщика и системы фильтрации.
181 lines
24 KiB
Markdown
181 lines
24 KiB
Markdown
# 5. Фильтр (EcoFilter)
|
||
|
||
[← Оглавление](../README.md) · [← Раздел 4: Балансировщик](04.md)
|
||
|
||
---
|
||
|
||
## 5.1. Путь пакета через фильтр
|
||
|
||
Фильтр (EcoFilter) — это основное устройство ТСПУ, непосредственно выполняющее анализ и обработку трафика. Каждый пакет, поступающий на фильтр от балансировщика (или напрямую от байпаса в простейшей конфигурации), проходит через **последовательную цепочку проверок**. На каждом этапе пакет может быть либо пропущен дальше по цепочке, либо прозрачно возвращён обратно оператору без какой-либо обработки.
|
||
|
||
Общая схема пути пакета:
|
||
|
||
```text
|
||
Пакет от балансировщика
|
||
│
|
||
▼
|
||
┌─────────────────────┐
|
||
│ 1. IP-пакет или нет │
|
||
└────────┬────────────┘
|
||
│ Не IP → прозрачный пропуск ──►
|
||
▼
|
||
┌─────────────────────┐
|
||
│ 2. Проверка по ACL │
|
||
│ (привязка к пулу) │
|
||
└────────┬────────────┘
|
||
│ Не попал в ACL → прозрачный пропуск ──►
|
||
▼
|
||
┌─────────────────────┐
|
||
│ 3. Проверка по │
|
||
│ DPI-листу (IP/сети) │
|
||
└────────┬────────────┘
|
||
│ Не попал в DPI-лист → прозрачный пропуск ──►
|
||
▼
|
||
┌─────────────────────┐
|
||
│ 4. Обработка │
|
||
│ движком DPI │
|
||
└────────┬────────────┘
|
||
│
|
||
┌────┴────┐
|
||
▼ ▼
|
||
Пропустить Заблокировать
|
||
(pass) (drop)
|
||
```
|
||
|
||
На каждом этапе, если пакет не удовлетворяет условиям для дальнейшей обработки, он **прозрачно возвращается** через парный интерфейс обратно в сеть оператора — как будто фильтра в тракте нет.
|
||
|
||
Важно понимать, что даже самая первая проверка (является ли пакет IP-пакетом) выполняется **программным ядром фильтра** — процессом EcoNAT. Если «мозг» фильтра не работает (процесс завис или перегружен), даже эта простейшая проверка не будет пройдена, и keep-alive пакеты от балансировщика не вернутся. Именно поэтому keep-alive пакеты балансировщика проверяют не только физическую связность канала, но и работоспособность процесса обработки на фильтре (подробнее — в [разделе 4.6.1](04.md)).
|
||
|
||
### 5.1.1. Проверка: IP-пакет или нет
|
||
|
||
Первый этап — определение того, содержит ли входящий кадр (Ethernet-фрейм) IP-пакет. Фильтр разбирает стек заголовков инкапсуляции и ищет IP-заголовок.
|
||
|
||
В операторских сетях трафик может приходить в самых различных инкапсуляциях:
|
||
|
||
- чистый IP-пакет (нетегированный);
|
||
- пакет с одним VLAN-тегом;
|
||
- пакет с двумя VLAN-тегами (QinQ);
|
||
- пакет с MPLS-метками;
|
||
- пакет с MPLS-метками и VLAN-тегами;
|
||
- PPPoE-пакет, дополнительно инкапсулированный в MPLS;
|
||
- и другие комбинации.
|
||
|
||
Глубина поиска IP-заголовка определяется параметром **VLAN Mode** (подробнее — в [разделе 15.2.1](15.md)):
|
||
|
||
| Значение VLAN Mode | Поведение |
|
||
| ------------------ | ------------------------------------------------------------ |
|
||
| **untag** | IP-заголовок ищется только в нетегированных фреймах |
|
||
| **vlan** | Поиск в нетегированных фреймах и фреймах с одним VLAN-тегом |
|
||
| **QinQ** | Поиск во фреймах с любым количеством VLAN-тегов (0, 1 или 2) |
|
||
|
||
В проекте АСБИ параметр VLAN Mode **всегда должен быть установлен в QinQ**. Если установлено другое значение, часть трафика может проходить через фильтр прозрачно, без обработки — что приведёт к неработоспособности фильтрации.
|
||
|
||
Если IP-заголовок не обнаружен (например, пакет содержит только ARP, служебный протокол или keep-alive балансировщика), пакет **немедленно возвращается** через парный интерфейс. Именно по этому пути проходят keep-alive пакеты балансировщика — они не являются IP-пакетами и заворачиваются на первой же проверке, что позволяет измерить время прохождения через фильтр.
|
||
|
||
### 5.1.2. Проверка по ACL (привязка к пулу)
|
||
|
||
Если пакет содержит IP-заголовок, следующий этап — проверка по **ACL** (Access Control List), привязанному к **пулу**.
|
||
|
||
Пул — это логическая сущность на фильтре, в которую попадает трафик для дальнейшей обработки. В проекте АСБИ используются пулы типа **fake** — это означает, что реальная трансляция адресов (NAT) не выполняется: что пришло, то и ушло. Тем не менее пул должен быть создан и включён, поскольку без пула трафик не может попасть на обработку DPI.
|
||
|
||
К каждому пулу привязывается ACL — список правил, определяющих, какой трафик должен обрабатываться. Правила ACL могут матчить пакеты по:
|
||
|
||
- **протоколу** — IP, TCP, UDP, ICMP и др.;
|
||
- **source/destination** — хост, подсеть или ключевое слово `any` (любой адрес);
|
||
- **номеру VLAN** — если не указан, подразумеваются все VLAN (0–4095).
|
||
|
||
Каждое правило содержит действие **allow** (permit) или **deny**. Правила обрабатываются по порядку номеров, рекомендуется задавать номера с зазором (например, 10, 20, 30) для удобства последующего редактирования.
|
||
|
||
Если пакет **попал** (замэтчился) в ACL привязанного пула — он переходит на следующий этап проверки. Если **не попал** ни в один ACL ни одного пула — пакет прозрачно пропускается обратно в сеть оператора.
|
||
|
||
При наличии нескольких пулов трафик попадает в пул с **наивысшим приоритетом**, ACL которого совпал первым.
|
||
|
||
> **Важно:** при заводской (дефолтной) конфигурации фильтра пулы и ACL **отсутствуют**. Их необходимо создать при первоначальной настройке. Без созданного пула и привязанного ACL фильтр будет прозрачно пропускать весь трафик — какие бы настройки DPI-листов ни были заданы, обработка не произойдёт.
|
||
|
||
### 5.1.3. Проверка по DPI-листу (IP-подсети)
|
||
|
||
После прохождения ACL и попадания в пул пакет проверяется на уровне **DPI-листа**. DPI-лист — это набор правил фильтрации, содержащий списки IP-адресов, подсетей и URL для обработки. На фильтре может быть настроено **до 16 DPI-листов** (номера 0–15), каждый из которых может быть включён или выключен независимо.
|
||
|
||
В рамках DPI-листа определены **параметры IP**, которые задают, какой именно трафик подлежит обработке данным листом:
|
||
|
||
| Параметр | Описание |
|
||
| ---------------------- | ----------------------------------------------------------------- |
|
||
| **IP** | Подсети и адреса, которые должны обрабатываться данным DPI-листом |
|
||
| **No IP** | Локальные адреса абонентов, исключённые из обработки |
|
||
| **No IP Remote** | Удалённые адреса (серверы), исключённые из обработки |
|
||
| **IPv6** / **No IPv6** | Аналогичные параметры для IPv6-трафика |
|
||
|
||
По умолчанию параметр IP должен содержать сеть `0.0.0.0/0` для всех VLAN — тогда весь трафик, попавший в DPI, будет обрабатываться данным листом. Параметр **No IP** используется, в частности, для диагностики: можно исключить конкретного абонента из обработки DPI-листом, чтобы проверить, влияет ли данный лист на его трафик.
|
||
|
||
Если пакет **не попал** в обработку ни одного активного DPI-листа (его адреса не совпали с заданными подсетями, или он исключён через No IP), он **прозрачно пропускается** дальше без какого-либо анализа.
|
||
|
||
Нулевой DPI-лист (`dpi list 0`) в проекте АСБИ всегда используется для **фильтрации по реестру Роскомнадзора**. Остальные листы (1–15) могут использоваться для других задач — например, для блокировки по очищенным протокольным спискам, загружаемым из ЦСУ (подробнее — в [разделе 8](08.md)).
|
||
|
||
### 5.1.4. Обработка движком DPI
|
||
|
||
Если пакет прошёл все предварительные проверки (IP → ACL/пул → DPI-лист), он передаётся на **движок DPI** (Deep Packet Inspection) для анализа. На платформе EcoFilter используется движок **ecDPI**, обеспечивающий фильтрацию по спискам и распознавание приложений вплоть до седьмого уровня модели OSI.
|
||
|
||
Движок DPI выполняет **многофакторный анализ сессий** по целому ряду параметров:
|
||
|
||
- **адреса и порты** — source IP, destination IP, source/destination port;
|
||
- **размеры пакетов** и их вариации в рамках сессии;
|
||
- **частота прохождения** пакетов;
|
||
- **ключевые слова и паттерны** внутри пакетов;
|
||
- **косвенные признаки** для шифрованного трафика (где очевидные поля протокола недоступны).
|
||
|
||
Анализ выполняется не над отдельным пакетом, а над **сессией** в целом — движок накапливает информацию о нескольких пакетах в рамках одного соединения и на основе совокупности признаков определяет тип трафика. Для шифрованного трафика (например, VPN-протоколы, мессенджеры) прямое определение по заголовкам невозможно, поэтому используются косвенные признаки: характерные размеры пакетов, частотные паттерны, статистические аномалии.
|
||
|
||
Результатом работы движка DPI является **определение протокола/приложения** и проверка по спискам фильтрации (URL, домены, IP-адреса). Дальнейшая судьба пакета определяется параметром **behavior** DPI-листа.
|
||
|
||
### 5.1.5. Решение: пропустить или заблокировать (drop)
|
||
|
||
По результатам анализа движком DPI фильтр принимает решение о судьбе пакета. Поведение задаётся параметром **behavior** в настройках каждого DPI-листа:
|
||
|
||
| Значение behavior | Описание |
|
||
| ----------------- | ------------------------------------------------------------------------------ |
|
||
| **block** | Трафик, совпавший со списком, блокируется (дропается) |
|
||
| **ignore** | Совпадение регистрируется и логируется, но никаких действий не предпринимается |
|
||
| **color** | Совпавший трафик «окрашивается» (в проекте АСБИ не используется) |
|
||
| **redirect** | Трафик перенаправляется (в проекте АСБИ не используется) |
|
||
|
||
В рамках проекта АСБИ используются преимущественно два режима:
|
||
|
||
**Режим block** — основной рабочий режим для блокировки по реестру Роскомнадзора и по очищенным протокольным спискам. При срабатывании блокировки:
|
||
|
||
- Для **HTTP**-трафика абоненту отправляется **HTTP-редирект** (код 302) на страницу-заглушку оператора, информирующую о блокировке ресурса. URL страницы-заглушки задаётся параметром **redirect URL** в настройках DPI-листа.
|
||
- Для **HTTPS**-трафика содержимое зашифровано, поэтому подмена ответа невозможна. Вместо этого абоненту и серверу отправляется **TCP Reset**, разрывающий соединение.
|
||
- При наличии MPLS-меток или сложной инкапсуляции фильтр не может самостоятельно сгенерировать ответный пакет с корректными заголовками. Поэтому используется особая логика: пакет от абонента пропускается к серверу, фильтр **дожидается ответного пакета** в той же сессии, а затем **подменяет** его содержимое на редирект или TCP Reset, сохраняя оригинальные заголовки инкапсуляции (подробнее — в [разделе 4.8](04.md)).
|
||
|
||
**Режим ignore** — используется для **распознавания протоколов** без блокировки. Фильтр определяет тип трафика и отправляет логи на SPFS, но сам трафик пропускает. Это первая стадия двухступенчатой блокировки: на этом этапе собираются данные для ЦСУ, которая формирует очищенные от ложных срабатываний списки и загружает их в другой DPI-лист, уже работающий в режиме block (подробнее — в [разделе 8](08.md)).
|
||
|
||
Каждый DPI-лист также поддерживает переключение режима **blacklist / whitelist** (параметр **WH list mode**):
|
||
|
||
- **Blacklist** (по умолчанию) — всё, что совпало со списком, блокируется; всё остальное пропускается;
|
||
- **Whitelist** — пропускается только совпавший трафик; всё остальное блокируется.
|
||
|
||
Режим whitelist в проекте АСБИ **не используется** из-за риска случайной блокировки всего трафика.
|
||
|
||
Отдельная проблема — **отправка TCP Reset при блокировке протоколов**. Если приложение абонента (например, мессенджер) получает TCP Reset при попытке установить соединение, оно немедленно пытается установить новое соединение — и делает это непрерывно с высокой частотой. Количество генерируемых сессий может быть огромным, создавая избыточную нагрузку на фильтр. Для решения этой проблемы предусмотрен параметр **send RST off**, отключающий отправку TCP Reset при блокировке протоколов (подробнее — в [разделе 17.1.2](17.md)).
|
||
|
||
## 5.2. Работа на уровне L2: фильтр как «прозрачный провод»
|
||
|
||
Несмотря на то, что фильтр анализирует IP-трафик вплоть до седьмого уровня модели OSI, с точки зрения **сетевой топологии** он работает на **уровне L2** (канальном уровне). Для внешнего наблюдателя — оператора связи, маршрутизаторов, коммутаторов — фильтр представляет собой **прозрачный провод**: пакет входит через один интерфейс и выходит через парный, без каких-либо видимых изменений на сетевом уровне.
|
||
|
||
Ключевые характеристики L2-работы фильтра:
|
||
|
||
**Отсутствие L3-интерфейсов в тракте данных.** На пути прохождения трафика у фильтра нет IP-интерфейсов. Если посмотреть на интерфейсы ОС Linux, на которой основано устройство, там виден только **management-интерфейс** (используемый для удалённого управления). Все остальные интерфейсы отданы под управление **DPDK** (Data Plane Development Kit) и процессу EcoNAT, который обрабатывает трафик напрямую, минуя сетевой стек операционной системы.
|
||
|
||
**Невозможность генерации трафика.** Фильтр — это L2-устройство, у которого нет IP-интерфейсов для инициирования трафика. Нельзя, например, выполнить ping с фильтра в сторону оператора через LAN/WAN-интерфейсы. Ping и traceroute возможны только через management-интерфейс (подробнее — в [разделе 18.14](18.md)).
|
||
|
||
**Сохранение всех заголовков инкапсуляции.** Фильтр не снимает и не модифицирует VLAN-теги, MPLS-метки и любые другие заголовки инкапсуляции. Все манипуляции выполняются **только с IP-пакетом** внутри стека заголовков. Пакет выходит из фильтра с теми же тегами и метками, с которыми он вошёл.
|
||
|
||
**Отключение LLDP.** Протокол LLDP (Link Layer Discovery Protocol) на фильтрах **выключен** по требованию операторов связи. Операторы не хотят видеть устройства ТСПУ в своей сетевой топологии — оборудование должно быть полностью прозрачным и невидимым. Если LLDP включён, устройство «появляется» на схемах сети оператора, что нежелательно.
|
||
|
||
**Максимальный L2 MTU.** Для обеспечения прозрачности параметр L2 MTU на фильтрах устанавливается в **максимально возможное значение — 9216 байт** (по RFC). Аналогичные значения (около 9000) выставляются на интерфейсах балансировщиков. Это позволяет полностью закрыть проблему с MTU и не возвращаться к ней в процессе эксплуатации.
|
||
|
||
**Параметр permit invalid flow.** В проекте АСБИ этот параметр должен быть **всегда включён**. Он разрешает заведение TCP-сессий без наличия начального TCP SYN-пакета. Это критически важно при переключении ТСПУ из режима TAP в рабочий режим (Inline): в момент переключения на фильтры хлынет трафик множества уже установленных TCP-сессий, для которых SYN-пакет был отправлен ранее. Без параметра permit invalid flow фильтр будет **дропать** все такие сессии, что приведёт к массовому разрыву соединений абонентов. С включённым параметром фильтр принимает пакеты «с середины» сессии и заводит для них сессионные записи (подробнее — в [разделе 15.2.6](15.md)).
|
||
|
||
---
|
||
|
||
[← Оглавление](../README.md) · [← Раздел 4: Балансировщик](04.md) · [Раздел 6: Места установки ТСПУ →](06.md)
|