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