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

Добавлено руководство по фильтру EcoFilter и обновлено оглавление

Browse Source 
- Создан новый файл 05.md с описанием работы фильтра EcoFilter, включая путь пакета через фильтр, проверки по ACL и DPI-листам, а также обработку движком DPI.
- Обновлено оглавление в README.md для включения нового раздела о фильтре EcoFilter.
This commit is contained in:
Daniel Lavrushin
2026-02-20 12:11:45 +01:00
parent cba7581665
commit 7933495487
6 changed files with 247 additions and 67 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
01.md
View File

@@ -1,6 +1,6 @@
# 1. Введение и общая архитектура АСБИ
[← Оглавление](index.md)
[← Оглавление](README.md)
---
@@ -127,4 +127,4 @@
---
[← Оглавление](index.md) · [Раздел 2: Прохождение трафика через ТСПУ →](02.md)
[← Оглавление](README.md) · [Раздел 2: Прохождение трафика через ТСПУ →](02.md)

22
02.md
View File

@@ -1,6 +1,6 @@
# 2. Прохождение трафика через ТСПУ
[← Оглавление](index.md) · [← Раздел 1: Введение и общая архитектура АСБИ](01.md)
[← Оглавление](README.md) · [← Раздел 1: Введение и общая архитектура АСБИ](01.md)
---
@@ -41,15 +41,15 @@
В поле дополнительных заголовков могут встречаться:
| Тип инкапсуляции | Описание |
| -------------------- | ------------------------------------------------------------------- |
| **Без инкапсуляции** | Чистый IP-пакет, дополнительных заголовков нет |
| **VLAN (802.1Q)** | Один VLAN-тег (тегированный пакет) |
| **QinQ (802.1ad)** | Два VLAN-тега (дважды тегированный пакет) |
| **MPLS** | Одна или несколько MPLS-меток |
| **MPLS + VLAN** | Комбинация MPLS-меток и VLAN-тегов |
| **PPPoE** | PPP-инкапсуляция (характерна для участка до BRAS) |
| **PPPoE + MPLS** | PPP внутри MPLS-туннеля |
| Тип инкапсуляции | Описание |
| -------------------- | ------------------------------------------------- |
| **Без инкапсуляции** | Чистый IP-пакет, дополнительных заголовков нет |
| **VLAN (802.1Q)** | Один VLAN-тег (тегированный пакет) |
| **QinQ (802.1ad)** | Два VLAN-тега (дважды тегированный пакет) |
| **MPLS** | Одна или несколько MPLS-меток |
| **MPLS + VLAN** | Комбинация MPLS-меток и VLAN-тегов |
| **PPPoE** | PPP-инкапсуляция (характерна для участка до BRAS) |
| **PPPoE + MPLS** | PPP внутри MPLS-туннеля |
Вариантов инкапсуляции в операторских сетях очень много, и все они не могут быть перечислены исчерпывающим образом. Ключевой момент: **ТСПУ должен уметь разбираться со всеми этими заголовками**, чтобы добраться до IP-пакета и выполнить его анализ и обработку. Всё, что находится «поверх» IP-заголовка, прозрачно пропускается — никакие метки и теги ТСПУ не снимает и не модифицирует.
@@ -245,4 +245,4 @@
---
[← Оглавление](index.md) · [← Раздел 1: Введение и общая архитектура АСБИ](01.md) · [Раздел 3: Байпас →](03.md)
[← Оглавление](README.md) · [← Раздел 1: Введение и общая архитектура АСБИ](01.md) · [Раздел 3: Байпас →](03.md)

22
03.md
View File

@@ -1,6 +1,6 @@
# 3. Байпас (Bypass)
[← Оглавление](index.md) · [← Раздел 2: Прохождение трафика через ТСПУ](02.md)
[← Оглавление](README.md) · [← Раздел 2: Прохождение трафика через ТСПУ](02.md)
---
@@ -14,9 +14,9 @@
В проекте АСБИ используются два типа байпасов:
| Проект | Производитель | Особенности |
| ------------------- | ------------- | ------------------------------------------------ |
| **Федеральный** | Silicom | Полный набор режимов, безфлаповое переключение |
| Проект | Производитель | Особенности |
| ------------------- | ------------- | ----------------------------------------------------- |
| **Федеральный** | Silicom | Полный набор режимов, безфлаповое переключение |
| **Пилотный (Урал)** | GL Sun | Только Power-off Bypass, флап линков при переключении |
## 3.2. Байпасы Silicom (федеральный проект)
@@ -125,12 +125,12 @@
Сводная таблица режимов:
| Режим | Трафик оператора | Копия на ТСПУ | Влияние на оператора при переключении |
| ---------------- | --------------------- | ------------- | ------------------------------------- |
| **Inline** | Через ТСПУ | Да (полная) | — |
| **TAP** | Замкнут напрямую | Да (копия) | Безболезненно |
| **Active Bypass**| Замкнут напрямую | Нет | Безболезненно |
| **Power-off** | Замкнут напрямую | Нет | Флапы линков, перерыв трафика |
| Режим | Трафик оператора | Копия на ТСПУ | Влияние на оператора при переключении |
| ----------------- | ---------------- | ------------- | ------------------------------------- |
| **Inline** | Через ТСПУ | Да (полная) | — |
| **TAP** | Замкнут напрямую | Да (копия) | Безболезненно |
| **Active Bypass** | Замкнут напрямую | Нет | Безболезненно |
| **Power-off** | Замкнут напрямую | Нет | Флапы линков, перерыв трафика |
## 3.3. Байпасы GL Sun (пилотный проект, Урал)
@@ -213,4 +213,4 @@ Heartbeat-пакеты байпаса Silicom — это **не IP-пакеты*
---
[← Оглавление](index.md) · [← Раздел 2: Прохождение трафика через ТСПУ](02.md) · [Раздел 4: Балансировщик →](04.md)
[← Оглавление](README.md) · [← Раздел 2: Прохождение трафика через ТСПУ](02.md) · [Раздел 4: Балансировщик →](04.md)

84
04.md
View File

@@ -1,6 +1,6 @@
# 4. Балансировщик (EcoFilter Balancer)
[← Оглавление](index.md) · [← Раздел 3: Байпас](03.md)
[← Оглавление](README.md) · [← Раздел 3: Байпас](03.md)
---
@@ -21,14 +21,14 @@
Балансировщик представляет собой компактное одноюнитовое (1U) устройство:
| Параметр | Значение |
| ----------------------- | -------------------------------------- |
| **Форм-фактор** | 1U (одноюнитовый) |
| **Количество портов** | 32 порта QSFP28 |
| **Пропускная способность** | 3.2 Тбит/с (на пакетах > 160 байт) |
| **Скорости портов** | 10G / 25G / 100G |
| **Питание** | 2 блока питания, горячее резервирование |
| **Передняя панель** | Консоль, Management Ethernet (1G), USB |
| Параметр | Значение |
| -------------------------- | --------------------------------------- |
| **Форм-фактор** | 1U (одноюнитовый) |
| **Количество портов** | 32 порта QSFP28 |
| **Пропускная способность** | 3.2 Тбит/с (на пакетах > 160 байт) |
| **Скорости портов** | 10G / 25G / 100G |
| **Питание** | 2 блока питания, горячее резервирование |
| **Передняя панель** | Консоль, Management Ethernet (1G), USB |
Существуют также двухюнитовые балансировщики (65 портов), но в проекте АСБИ используются **только одноюнитовые** модели.
@@ -46,23 +46,23 @@
Порты внутри каждой группы объединяются в **пары** LAN + WAN и далее — в логические сущности, называемые **линками**.
```text
Оборудование оператора (через байпасы)
│ │ │ │
P42(L) P41(W) P10(L) P9(W)
└─────┬─────┘ └─────┬─────┘
Линк 1 Линк 2
(10G) (100G)
│ │
┌───────────┴─────────────────────┴──────────┐
│ Балансировщик │
│ │
│ Flow rules → Balance Group │
└───┬─────┬─────┬──────────┬─────┬─────┬─────┘
P21(L) P22(W) P31(L) P32(W) P41(L) P42(W)
└──┬──┘ └──┬──┘ └──┬──┘
Filter Group 1 Filter Group 2 Filter Group 3
│ │ │
Фильтр 1 Фильтр 2 Фильтр N
Оборудование оператора (через байпасы)
│ │ │ │
P42(L) P41(W) P10(L) P9(W)
└─────┬─────┘ └─────┬─────┘
Линк 1 Линк 2
(10G) (100G)
│ │
┌──── ──┴─────────────────────────┴──────────┐
│ Балансировщик │
│ │
│ Flow rules → Balance Group │
└───┬─────┬─────┬─────┬─────┬─────┬─────────┘
P21(L) P22(W) P31(L) P32(W) P41(L) P42(W)
└──┬──┘ └──┬──┘ └──┬──┘
Filter Group 1 Filter Group 2 Filter Group 3
│ │ │
Фильтр 1 Фильтр 2 Фильтр N
```
### 4.3.1. Принцип чётных/нечётных портов
@@ -113,14 +113,14 @@
Условия совпадения (match) могут включать:
| Критерий | Описание |
| --------------- | ------------------------------------------- |
| **VLAN ID** | Номер VLAN-тега (один или несколько) |
| **IPv4 src/dst**| Адрес или подсеть источника/назначения |
| **L4 port** | Порт TCP/UDP |
| **MAC-адрес** | Source или destination MAC |
| **MPLS** | Количество MPLS-меток |
| **Глубина тегов**| Количество VLAN-тегов в пакете |
| Критерий | Описание |
| ----------------- | -------------------------------------- |
| **VLAN ID** | Номер VLAN-тега (один или несколько) |
| **IPv4 src/dst** | Адрес или подсеть источника/назначения |
| **L4 port** | Порт TCP/UDP |
| **MAC-адрес** | Source или destination MAC |
| **MPLS** | Количество MPLS-меток |
| **Глубина тегов** | Количество VLAN-тегов в пакете |
В одном правиле можно комбинировать несколько условий (например, VLAN + IPv4-подсеть). Матчить можно как для включения трафика в обработку, так и наоборот — для исключения.
@@ -182,13 +182,13 @@
Параметры keep-alive настраиваются в **профиле проверки доступности** (availability profile):
| Параметр | Описание |
| ---------------------------- | ---------------------------------------------------------- |
| **Начальная задержка** | Время ожидания после старта перед началом отправки |
| **Интервал** | Периодичность отправки (типично ~100 мс) |
| **Порог потерь** | Число потерянных пакетов для признания группы неактивной (типично 5) |
| **Порог восстановления** | Число успешных пакетов для восстановления активности |
| **Мин. количество активных пар** | Порог, ниже которого вся balance group считается неактивной |
| Параметр | Описание |
| -------------------------------- | -------------------------------------------------------------------- |
| **Начальная задержка** | Время ожидания после старта перед началом отправки |
| **Интервал** | Периодичность отправки (типично ~100 мс) |
| **Порог потерь** | Число потерянных пакетов для признания группы неактивной (типично 5) |
| **Порог восстановления** | Число успешных пакетов для восстановления активности |
| **Мин. количество активных пар** | Порог, ниже которого вся balance group считается неактивной |
Keep-alive пакеты проверяют не только физическую доступность канала, но и **работоспособность фильтра** в целом: если «мозг» фильтра завис или перегружен настолько, что не может обрабатывать даже не-IP-пакеты, keep-alive не вернётся, и балансировщик это обнаружит.
@@ -245,4 +245,4 @@ Keep-alive пакеты проверяют не только физическу
---
[← Оглавление](index.md) · [← Раздел 3: Байпас](03.md) · [Раздел 5: Фильтр →](05.md)
[← Оглавление](README.md) · [← Раздел 3: Байпас](03.md) · [Раздел 5: Фильтр →](05.md)

180
05.md Normal file
View File

@@ -0,0 +1,180 @@
# 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)

2
index.md → README.md
View File

@@ -56,7 +56,7 @@
- 4.7. Работа с различными инкапсуляциями (VLAN, MPLS)
- 4.8. Обработка HTTP-редиректов и TCP Reset через фильтры
### 5. Фильтр (EcoFilter)
### [5. Фильтр (EcoFilter)](/05.md)
- 5.1. Путь пакета через фильтр
- 5.1.1. Проверка: IP-пакет или нет