tspu-docs/chapters/05.md

5. Фильтр (EcoFilter)

← Оглавление · ← Раздел 4: Балансировщик

---

5.1. Путь пакета через фильтр

Фильтр (EcoFilter) — это основное устройство ТСПУ, непосредственно выполняющее анализ и обработку трафика. Каждый пакет, поступающий на фильтр от балансировщика (или напрямую от байпаса в простейшей конфигурации), проходит через последовательную цепочку проверок. На каждом этапе пакет может быть либо пропущен дальше по цепочке, либо прозрачно возвращён обратно оператору без какой-либо обработки.

Общая схема пути пакета:

    Пакет от балансировщика
              │
              ▼
    ┌─────────────────────┐
    │  1. IP-пакет или нет │
    └────────┬────────────┘
             │                    Не IP → прозрачный пропуск ──►
             ▼
    ┌─────────────────────┐
    │  2. Проверка по ACL  │
    │  (привязка к пулу)   │
    └────────┬────────────┘
             │                    Не попал в ACL → прозрачный пропуск ──►
             ▼
    ┌─────────────────────┐
    │  3. Проверка по       │
    │  DPI-листу (IP/сети)  │
    └────────┬────────────┘
             │                    Не попал в DPI-лист → прозрачный пропуск ──►
             ▼
    ┌─────────────────────┐
    │  4. Обработка         │
    │  движком DPI          │
    └────────┬────────────┘
             │
        ┌────┴────┐
        ▼              ▼
    Пропустить     Заблокировать
    (pass)           (drop)

На каждом этапе, если пакет не удовлетворяет условиям для дальнейшей обработки, он прозрачно возвращается через парный интерфейс обратно в сеть оператора — как будто фильтра в тракте нет.

Важно понимать, что даже самая первая проверка (является ли пакет IP-пакетом) выполняется программным ядром фильтра — процессом EcoNAT. Если «мозг» фильтра не работает (процесс завис или перегружен), даже эта простейшая проверка не будет пройдена, и keep-alive пакеты от балансировщика не вернутся. Именно поэтому keep-alive пакеты балансировщика проверяют не только физическую связность канала, но и работоспособность процесса обработки на фильтре (подробнее — в разделе 4.6.1).

5.1.1. Проверка: IP-пакет или нет

Первый этап — определение того, содержит ли входящий кадр (Ethernet-фрейм) IP-пакет. Фильтр разбирает стек заголовков инкапсуляции и ищет IP-заголовок.

В операторских сетях трафик может приходить в самых различных инкапсуляциях:

• чистый IP-пакет (нетегированный);
• пакет с одним VLAN-тегом;
• пакет с двумя VLAN-тегами (QinQ);
• пакет с MPLS-метками;
• пакет с MPLS-метками и VLAN-тегами;
• PPPoE-пакет, дополнительно инкапсулированный в MPLS;
• и другие комбинации.

Глубина поиска IP-заголовка определяется параметром VLAN Mode (подробнее — в разделе 15.2.1):

Значение 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).

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

Режим ignore — используется для распознавания протоколов без блокировки. Фильтр определяет тип трафика и отправляет логи на SPFS, но сам трафик пропускает. Это первая стадия двухступенчатой блокировки: на этом этапе собираются данные для ЦСУ, которая формирует очищенные от ложных срабатываний списки и загружает их в другой DPI-лист, уже работающий в режиме block (подробнее — в разделе 8).

Каждый DPI-лист также поддерживает переключение режима blacklist / whitelist (параметр WH list mode):

• Blacklist (по умолчанию) — всё, что совпало со списком, блокируется; всё остальное пропускается;
• Whitelist — пропускается только совпавший трафик; всё остальное блокируется.

Режим whitelist в проекте АСБИ не используется из-за риска случайной блокировки всего трафика.

Отдельная проблема — отправка TCP Reset при блокировке протоколов. Если приложение абонента (например, мессенджер) получает TCP Reset при попытке установить соединение, оно немедленно пытается установить новое соединение — и делает это непрерывно с высокой частотой. Количество генерируемых сессий может быть огромным, создавая избыточную нагрузку на фильтр. Для решения этой проблемы предусмотрен параметр send RST off, отключающий отправку TCP Reset при блокировке протоколов (подробнее — в разделе 17.1.2).

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

Сохранение всех заголовков инкапсуляции. Фильтр не снимает и не модифицирует 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).

---

← Оглавление · ← Раздел 4: Балансировщик · Раздел 6: Места установки ТСПУ →