mirror of
https://github.com/DanielLavrushin/tspu-docs.git
synced 2026-09-27 01:00:20 +03:00
Refactor documentation for clarity and consistency
- Updated section 6.1 to clarify the handling of PPPoE encapsulation and filter settings. - Revised section 8.1 to specify the use of a separate DPI list for protocol recognition. - Changed references from PPPoE to IPoE in section 11 for accuracy. - Corrected parameter names in CLI documentation in section 13 for consistency. - Standardized naming conventions in section 15 for NAT defaults and VLAN modes. - Clarified ACL processing order and behavior in section 16. - Updated DPI module notes in section 17 to reflect changes in the number of DPI lists. - Enhanced descriptions of DPI list behaviors in section 23 for better understanding.
This commit is contained in:
Daniel Lavrushin
@@ -195,10 +195,10 @@
|
||||
|
||||
- 15.1. Интерфейсы: enable/disable, description (LACP не используется)
|
||||
- 15.2. NAT Defaults — общие параметры устройства
|
||||
- 15.2.1. **VLAN Mode**: untag / vlan / QinQ — глубина поиска IP-заголовка (всегда QinQ)
|
||||
- 15.2.1. **VLAN Mode**: untagged / vlan / qinq — глубина поиска IP-заголовка (всегда qinq)
|
||||
- 15.2.2. Sessions per Translation (по умолчанию 4096)
|
||||
- 15.2.3. **Forward Traffic**: всегда ON
|
||||
- 15.2.4. **L2 MTU**: максимум 9216 (по RFC)
|
||||
- 15.2.4. **L2 MTU**: 9216
|
||||
- 15.2.5. **LLDP**: выключен (требование операторов — прозрачность)
|
||||
- 15.2.6. **Permit Invalid Flow**: всегда ON — приём TCP-сессий без SYN
|
||||
- 15.3. Тайм-ауты сессий и трансляций
|
||||
|
||||
+4
-4
@@ -208,13 +208,13 @@ _Логика балансировщика: порты в сторону опе
|
||||
|
||||
1. **Проверка: IP-пакет или нет.** После разбора инкапсуляции фильтр проверяет, есть ли внутри IPv4- или IPv6-пакет. Не-IP кадры без какой-либо обработки выводятся в парный порт; в типовой схеме до фильтра из не-IP трафика доходят практически только keep-alive-пакеты балансировщика, которые таким образом возвращаются балансировщику.
|
||||
|
||||
2. **Проверка по ACL.** ACL на фильтре задают, какой трафик подлежит анализу, и привязаны к пулу — логической сущности, в которую попадает отобранный трафик для дальнейшей обработки ([раздел 16](16.md)). Пакет, не попавший ни в один ACL, анализу не подлежит и прозрачно передаётся в парный порт.
|
||||
2. **Проверка по ACL.** ACL на фильтре задают, какой трафик подлежит анализу, и привязаны к пулу — логической сущности, в которую попадает отобранный трафик для дальнейшей обработки ([раздел 16](16.md)). Пакет, не попавший ни в один пул (ни одно разрешающее правило ACL его не отобрало), анализу не подлежит и прозрачно передаётся в парный порт.
|
||||
|
||||
3. **Проверка по DPI-листу.** В DPI-листе указаны IP-подсети и адреса, подлежащие проверке ([раздел 17.4](17.md)). Если IP-адреса пакета не попадают в обработку DPI-листа — пакет прозрачно пропускается.
|
||||
|
||||
4. **Обработка движком DPI.** Только пакеты, прошедшие все предыдущие проверки, попадают на анализ DPI-движком. По результатам анализа принимается решение: пропустить пакет (pass) либо отбросить (drop), если он попадает под запрещающие политики; при блокировке ресурса абоненту дополнительно отправляется HTTP-редирект (для HTTP) или TCP Reset (для HTTPS) ([раздел 17.4.4](17.md); особенности для трафика с MPLS — см. ниже).
|
||||
4. **Обработка движком DPI.** Только пакеты, прошедшие все предыдущие проверки, попадают на анализ DPI-движком. По результатам анализа принимается решение: пропустить пакет либо отбросить его (drop), если он попадает под запрещающие политики; при блокировке ресурса абоненту дополнительно отправляется HTTP-редирект (для HTTP) или TCP Reset (для HTTPS) ([раздел 17.4.4](17.md); особенности для трафика с MPLS — см. ниже).
|
||||
|
||||
Глубина разбора инкапсуляции на фильтре задаётся настройкой (параметр VLAN Mode, в проекте всегда QinQ — [раздел 15.2.1](15.md)); ограничения фильтра по типам инкапсуляции несколько строже, чем у балансировщика.
|
||||
Глубина разбора инкапсуляции на фильтре задаётся настройкой (параметр `vlan_mode`, в проекте всегда `qinq` — [раздел 15.2.1](15.md)); ограничения фильтра по типам инкапсуляции несколько строже, чем у балансировщика.
|
||||
|
||||
Фильтр работает на уровне **L2**: в тракте передачи трафика у него нет L3-интерфейсов, он не является ни маршрутизатором, ни коммутатором и всегда передаёт кадр строго в парный порт. С точки зрения сети оператора фильтр представляет собой **«прозрачный провод»**: все заголовки инкапсуляции (VLAN-теги, MPLS-метки и т. д.) проходят через фильтр без изменений. Фильтр разбирает стек заголовков только для того, чтобы добраться до IP-пакета и выполнить анализ; пропускаемый трафик покидает фильтр в неизменном виде, изменения вносятся только в пакеты блокируемых сессий (drop, подмена на HTTP-редирект или TCP Reset).
|
||||
|
||||
@@ -228,7 +228,7 @@ _Путь пакета через фильтр: вход через LAN-порт
|
||||
|
||||
### Особенность: HTTP-редирект и TCP Reset при наличии MPLS
|
||||
|
||||
Особый случай — блокировка трафика с MPLS-метками, когда фильтру нужно отправить абоненту **HTTP-редирект** (код 302, перенаправление на страницу-заглушку) при блокировке HTTP-ресурса или **TCP Reset** при блокировке HTTPS-ресурса ([раздел 17.4](17.md)). Фильтр не может просто сформировать такой пакет сам: MPLS-путь однонаправлен, и метки, с которыми пришёл пакет абонента, действительны только для направления в сторону интернета — стек меток обратного направления фильтру неизвестен.
|
||||
Особый случай — блокировка трафика с MPLS-метками, когда фильтру нужно отправить абоненту **HTTP-редирект** (перенаправление на страницу-заглушку; по документации производителя — ответ «307 Temporary Redirect») при блокировке HTTP-ресурса или **TCP Reset** при блокировке HTTPS-ресурса ([раздел 17.4](17.md)). Фильтр не может просто сформировать такой пакет сам: MPLS-путь однонаправлен, и метки, с которыми пришёл пакет абонента, действительны только для направления в сторону интернета — стек меток обратного направления фильтру неизвестен.
|
||||
|
||||
Поэтому для трафика с MPLS-метками фильтр пропускает запрос абонента к ресурсу как есть, дожидается первого ответного пакета той же сессии — он приходит уже с корректными метками обратного направления — и подставляет вместо его содержимого HTTP-редирект (для HTTP) или TCP Reset (для HTTPS: подменить зашифрованный ответ нельзя, ресурс определяется по SNI в ClientHello — [раздел 17.5.3](17.md)), сохраняя метки. Модифицированный пакет доставляется абоненту с корректной инкапсуляцией, и блокировка срабатывает штатно. Для QUIC (UDP/443) TCP Reset неприменим — это UDP-протокол; распознавание QUIC на фильтре включается отдельным списком ресурсов ([раздел 17.4.9](17.md)). Подробнее механизм описан в [разделе 4.8](04.md).
|
||||
|
||||
|
||||
+1
-1
@@ -280,7 +280,7 @@ Keep-alive проверяют не только физический канал,
|
||||
|
||||
## 4.8. Обработка HTTP-редиректов и TCP Reset через фильтры
|
||||
|
||||
При блокировке ресурса фильтр отправляет абоненту **HTTP-редирект** (код 302, перенаправление на страницу-заглушку) для HTTP или **TCP Reset** для HTTPS: подменить содержимое зашифрованного соединения невозможно, а сам ресурс определяется по SNI в ClientHello ([раздел 17.5.3](17.md)). Для трафика без MPLS-меток фильтр формирует такой пакет сам.
|
||||
При блокировке ресурса фильтр отправляет абоненту **HTTP-редирект** (перенаправление на страницу-заглушку; по документации производителя — ответ «307 Temporary Redirect») для HTTP или **TCP Reset** для HTTPS: подменить содержимое зашифрованного соединения невозможно, а сам ресурс определяется по SNI в ClientHello ([раздел 17.5.3](17.md)). Для трафика без MPLS-меток фильтр формирует такой пакет сам.
|
||||
|
||||
С MPLS-трафиком так не получается. MPLS-путь однонаправлен: метки, с которыми пакет абонента пришёл на фильтр, действительны только для направления в сторону интернета, а стек меток обратного направления фильтру неизвестен — собранный им самим пакет оборудование оператора отбросит или доставит не туда. Поэтому для трафика с MPLS-метками используется другая логика:
|
||||
|
||||
|
||||
+124
-109
@@ -4,176 +4,191 @@
|
||||
|
||||
---
|
||||
|
||||
Фильтр — основное устройство ТСПУ: он анализирует трафик и применяет к нему политики блокировки. Это сервер EcoFilter на платформе RDP.ru EcoSGE. Программный комплекс фильтра вырос из CGNAT-устройства, и трафик на нём обрабатывает процесс **EcoNAT** — на всех ядрах процессора, кроме одного сервисного ([раздел 4.5.2](04.md)). Из функций платформы (NAT, BRAS, управление качеством сервиса, URL-фильтрация, DPI) в ТСПУ задействованы две: **EcoFilter** — фильтрация по спискам (реестр Роскомнадзора и другие списки) и **EcoDPI** — распознавание протоколов и приложений вплоть до седьмого уровня модели OSI. Происхождением от CGNAT объясняются понятия, с которыми приходится работать на фильтре: пулы, трансляции и сессии, секция общих параметров `nat_defaults` ([разделы 11.6](11.md), [12](12.md), [15.2](15.md) и [16](16.md)).
|
||||
|
||||
## 5.1. Путь пакета через фильтр
|
||||
|
||||
Фильтр (EcoFilter) — это основное устройство ТСПУ, непосредственно выполняющее анализ и обработку трафика. Каждый пакет, поступающий на фильтр от балансировщика (или напрямую от байпаса в простейшей конфигурации), проходит через **последовательную цепочку проверок**. На каждом этапе пакет может быть либо пропущен дальше по цепочке, либо прозрачно возвращён обратно оператору без какой-либо обработки.
|
||||
Порты фильтра, через которые идёт трафик, объединены в пары: чётный порт пары — LAN (сторона абонентов), нечётный — WAN (сторона интернета) ([раздел 11.5](11.md)). По этой ориентации фильтр определяет, какой адрес сессии локальный (абонентский), а какой удалённый ([раздел 12.5](12.md)), поэтому перепутанные LAN и WAN нарушают обработку ([раздел 24.6](24.md)). Проходящий через фильтр кадр покидает его только через парный порт. Исключение — пакеты, которые фильтр сам формирует при блокировке: ответ абоненту (перенаправление или TCP Reset) уходит обратно в LAN-порт, через который пришёл запрос. За балансировщиком кадр приходит с 4-байтным служебным заголовком: по нему фильтр выбирает ядро для обработки и с тем же заголовком возвращает кадр на балансировщик ([раздел 4.5.3](04.md)).
|
||||
|
||||
Общая схема пути пакета:
|
||||
Так фильтры подключаются в ТСПУ тип А. В эшелонированной системе (ТСПУ тип Б) фильтр подключён к балансировщику Eco Highway по схеме on-a-stick: порты равноправны, направление обозначает служебный VLAN-тег, который фильтр после обработки меняет на парный, а распознаванием протоколов фильтры там не занимаются ([разделы 7.3.3](07.md) и [7.3.4](07.md)).
|
||||
|
||||
Каждый пакет проходит **цепочку проверок**. Если на каком-то этапе пакет под обработку не подпадает, фильтр сразу передаёт его в парный порт без изменений, и пакет продолжает путь по сети оператора так, будто фильтра в тракте нет. До движка DPI доходит только трафик, прошедший все предварительные проверки:
|
||||
|
||||
```text
|
||||
Пакет от балансировщика
|
||||
│
|
||||
▼
|
||||
┌─────────────────────┐
|
||||
│ 1. IP-пакет или нет │
|
||||
└────────┬────────────┘
|
||||
│ Не IP → прозрачный пропуск ──►
|
||||
▼
|
||||
┌─────────────────────┐
|
||||
│ 2. Проверка по ACL │
|
||||
│ (привязка к пулу) │
|
||||
└────────┬────────────┘
|
||||
│ Не попал в ACL → прозрачный пропуск ──►
|
||||
▼
|
||||
┌─────────────────────┐
|
||||
│ 3. Проверка по │
|
||||
│ DPI-листу (IP/сети) │
|
||||
└────────┬────────────┘
|
||||
│ Не попал в DPI-лист → прозрачный пропуск ──►
|
||||
▼
|
||||
┌─────────────────────┐
|
||||
│ 4. Обработка │
|
||||
│ движком DPI │
|
||||
└────────┬────────────┘
|
||||
│
|
||||
┌────┴────┐
|
||||
▼ ▼
|
||||
Пропустить Заблокировать
|
||||
(pass) (drop)
|
||||
Кадр от балансировщика (или от байпаса)
|
||||
│
|
||||
▼
|
||||
┌──────────────────────────────────┐
|
||||
│ 1. В кадре есть IP-пакет? ├─ нет ─► в парный порт без обработки
|
||||
└─────────────────┬────────────────┘
|
||||
│ да
|
||||
▼
|
||||
┌──────────────────────────────────┐
|
||||
│ 2. Пакет попал в пул ├─ нет ─► в парный порт без обработки
|
||||
│ (совпал с ACL пула)? │
|
||||
└─────────────────┬────────────────┘
|
||||
│ да: сессия найдена или заведена
|
||||
▼
|
||||
┌──────────────────────────────────┐
|
||||
│ 3. Адреса пакета входят ├─ нет ─► в парный порт без обработки
|
||||
│ в обработку DPI-листа? │
|
||||
└─────────────────┬────────────────┘
|
||||
│ да
|
||||
▼
|
||||
┌──────────────────────────────────┐
|
||||
│ 4. Анализ движком DPI │
|
||||
└─────────────────┬────────────────┘
|
||||
┌────────┴────────┐
|
||||
▼ ▼
|
||||
Пропустить Заблокировать
|
||||
(в парный порт) (drop, TCP Reset,
|
||||
перенаправление)
|
||||
```
|
||||
|
||||
На каждом этапе, если пакет не удовлетворяет условиям для дальнейшей обработки, он **прозрачно возвращается** через парный интерфейс обратно в сеть оператора — как будто фильтра в тракте нет.
|
||||
|
||||
Важно понимать, что даже самая первая проверка (является ли пакет IP-пакетом) выполняется **программным ядром фильтра** — процессом EcoNAT. Если «мозг» фильтра не работает (процесс завис или перегружен), даже эта простейшая проверка не будет пройдена, и keep-alive пакеты от балансировщика не вернутся. Именно поэтому keep-alive пакеты балансировщика проверяют не только физическую связность канала, но и работоспособность процесса обработки на фильтре (подробнее — в [разделе 4.6.1](04.md)).
|
||||
Даже первую, самую простую проверку («IP-пакет или нет») выполняет программное ядро фильтра — процесс EcoNAT. Если процесс завис или фильтр перегружен настолько, что перестал обрабатывать трафик, не проходит и она: keep-alive-пакеты балансировщика перестают возвращаться, и балансировщик переводит эту пару портов в программный байпас, а при включённой перебалансировке перераспределяет её трафик по остальным парам портов ([раздел 4.6](04.md)). Поэтому keep-alive проверяют не только физический канал, но и то, что фильтр продолжает обрабатывать трафик. В схеме без балансировщика ту же роль играют heartbeat-пакеты байпаса ([раздел 3.1](03.md)).
|
||||
|
||||
### 5.1.1. Проверка: IP-пакет или нет
|
||||
|
||||
Первый этап — определение того, содержит ли входящий кадр (Ethernet-фрейм) IP-пакет. Фильтр разбирает стек заголовков инкапсуляции и ищет IP-заголовок.
|
||||
Сначала фильтр ищет в кадре IP-пакет. Инкапсуляция на стыке оператора зависит от его технологий и от места установки ТСПУ, и вариантов много:
|
||||
|
||||
В операторских сетях трафик может приходить в самых различных инкапсуляциях:
|
||||
|
||||
- чистый IP-пакет (нетегированный);
|
||||
- пакет с одним VLAN-тегом;
|
||||
- пакет с двумя VLAN-тегами (QinQ);
|
||||
- пакет с MPLS-метками;
|
||||
- пакет с MPLS-метками и VLAN-тегами;
|
||||
- PPPoE-пакет, дополнительно инкапсулированный в MPLS;
|
||||
- IP-пакет без дополнительных заголовков;
|
||||
- пакет с одним или двумя VLAN-тегами (QinQ);
|
||||
- пакет с MPLS-метками — с VLAN-тегами или без них;
|
||||
- PPPoE-трафик, в том числе с двумя VLAN-тегами и внутри MPLS;
|
||||
- и другие комбинации.
|
||||
|
||||
Глубина поиска IP-заголовка определяется параметром **VLAN Mode** (подробнее — в [разделе 15.2.1](15.md)):
|
||||
Фильтр не снимает эти заголовки, а разбирает стек, чтобы добраться до IP-пакета: MPLS-метки он просматривает до конца стека, а сколько VLAN-тегов разбирать, задаёт параметр `vlan_mode` (VLAN Mode) в секции `nat_defaults` ([раздел 15.2.1](15.md)):
|
||||
|
||||
| Значение VLAN Mode | Поведение |
|
||||
| ------------------ | ------------------------------------------------------------ |
|
||||
| **untag** | IP-заголовок ищется только в нетегированных фреймах |
|
||||
| **vlan** | Поиск в нетегированных фреймах и фреймах с одним VLAN-тегом |
|
||||
| **QinQ** | Поиск во фреймах с любым количеством VLAN-тегов (0, 1 или 2) |
|
||||
| Значение `vlan_mode` | Где фильтр ищет IP-пакет |
|
||||
| ------------------------- | -------------------------------------------------------------------------- |
|
||||
| `untagged` (по умолчанию) | только в нетегированных кадрах; кадры с VLAN-тегами проходят без обработки |
|
||||
| `vlan` | в нетегированных кадрах и кадрах с одним VLAN-тегом |
|
||||
| `qinq` | в нетегированных кадрах и кадрах с одним или двумя VLAN-тегами |
|
||||
|
||||
В проекте АСБИ параметр VLAN Mode **всегда должен быть установлен в QinQ**. Если установлено другое значение, часть трафика может проходить через фильтр прозрачно, без обработки — что приведёт к неработоспособности фильтрации.
|
||||
В ТСПУ параметр **всегда должен быть `qinq`**. При другом значении часть тегированного трафика (при `untagged` — весь, при `vlan` — кадры с двумя тегами) проходит через фильтр прозрачно, без обработки, — и внешне это никак не проявляется: трафик идёт, просто не фильтруется.
|
||||
|
||||
Если IP-заголовок не обнаружен (например, пакет содержит только ARP, служебный протокол или keep-alive балансировщика), пакет **немедленно возвращается** через парный интерфейс. Именно по этому пути проходят keep-alive пакеты балансировщика — они не являются IP-пакетами и заворачиваются на первой же проверке, что позволяет измерить время прохождения через фильтр.
|
||||
По документации производителя в режимах `vlan` и `qinq` VLAN-тег не разделяет абонентов: одинаковые IP-адреса в разных VLAN фильтр считает одним и тем же абонентом, и передача трафика может нарушаться. Это стоит учитывать, если адресные пространства в разных VLAN оператора пересекаются.
|
||||
|
||||
В документации производителя описаны ещё две настройки этого этапа:
|
||||
|
||||
- `inner_vlan` и `outer_vlan` — значения TPID внутреннего и внешнего VLAN-тегов (по умолчанию оба 0x8100). Они доступны на платформах с сетевыми контроллерами Intel серий 710/810 и нужны для правильной обработки QinQ: значение задаётся для всего устройства и должно совпадать с тем, как теги формирует оборудование оператора (например, TPID 0x88A8 у внешнего тега по IEEE 802.1ad или встречающийся на старом оборудовании 0x9100);
|
||||
- `pppoe_analyzer` — обработка трафика PPPoE (по умолчанию выключена). При установке ТСПУ до BRAS, где идёт PPPoE-трафик ([раздел 6.1.1](06.md)), её стоит проверить.
|
||||
|
||||
У фильтра ограничений на типы инкапсуляции больше, чем у балансировщика ([раздел 4.7](04.md)): например, балансировщик разбирает до трёх VLAN-тегов, а фильтр — не больше двух. Кадр, в котором фильтр IP-пакет не нашёл, проходит через него прозрачно, без анализа.
|
||||
|
||||
Кадры без IP-пакета фильтр передаёт в парный порт на этой же проверке. За балансировщиком до фильтра доходят практически только keep-alive-пакеты балансировщика — прочие не-IP-кадры балансировщик пропускает сам, не отправляя на фильтры ([раздел 4.7](04.md)). Keep-alive возвращаются на балансировщик, который по времени их прохождения контролирует путь через фильтр ([раздел 4.6.1](04.md)). В схеме без балансировщика через фильтр прозрачно проходят и служебные кадры сети оператора — например, ARP или LACP, а heartbeat-кадры байпаса Silicom, подключённого к фильтру напрямую, тоже проходят в парный порт без обработки ([раздел 3.4](03.md)).
|
||||
|
||||
### 5.1.2. Проверка по ACL (привязка к пулу)
|
||||
|
||||
Если пакет содержит IP-заголовок, следующий этап — проверка по **ACL** (Access Control List), привязанному к **пулу**.
|
||||
Найденный IP-пакет фильтр проверяет на принадлежность к **пулу**. Пул — понятие из CGNAT: там он задаёт тип трансляции и набор внешних адресов, а привязанный к пулу **ACL** (Access Control List) определяет, какой трафик этот пул обслуживает. DPI обрабатывает только трафик, попавший в какой-либо пул, поэтому пул нужен и там, где адреса не транслируются. В ТСПУ используются пулы типа **fake**: трансляции в них нет — что пришло, то и ушло.
|
||||
|
||||
Пул — это логическая сущность на фильтре, в которую попадает трафик для дальнейшей обработки. В проекте АСБИ используются пулы типа **fake** — это означает, что реальная трансляция адресов (NAT) не выполняется: что пришло, то и ушло. Тем не менее пул должен быть создан и включён, поскольку без пула трафик не может попасть на обработку DPI.
|
||||
Минимальная рабочая настройка — включённый (`enable`) пул типа `fake` с привязанным ACL. Новый пул создаётся с типом `cgnat`, поэтому тип `fake` задаётся явно ([раздел 16](16.md)).
|
||||
|
||||
К каждому пулу привязывается ACL — список правил, определяющих, какой трафик должен обрабатываться. Правила ACL могут матчить пакеты по:
|
||||
Правило ACL состоит из:
|
||||
|
||||
- **протоколу** — IP, TCP, UDP, ICMP и др.;
|
||||
- **source/destination** — хост, подсеть или ключевое слово `any` (любой адрес);
|
||||
- **номеру VLAN** — если не указан, подразумеваются все VLAN (0–4095).
|
||||
- **номера** — правила проверяются в порядке возрастания номеров, и решает первое совпавшее; номера удобно задавать с шагом (10, 20, 30), чтобы потом вставлять правила между существующими;
|
||||
- **действия** — `allow` или `permit` (синонимы) либо `deny`;
|
||||
- **протокола** — `ip` (любой), `tcp`, `udp` или `icmp`;
|
||||
- **источника и назначения** — `any`, отдельный адрес, диапазон адресов или подсеть; для TCP и UDP — также порты;
|
||||
- **VLAN** — номер или диапазон; если VLAN не указан, правило действует во всех VLAN.
|
||||
|
||||
Каждое правило содержит действие **allow** (permit) или **deny**. Правила обрабатываются по порядку номеров, рекомендуется задавать номера с зазором (например, 10, 20, 30) для удобства последующего редактирования.
|
||||
Пулы перебираются в порядке приоритета: **чем меньше значение `priority`, тем раньше** проверяется пул. Для каждого пула проверяется его ACL:
|
||||
|
||||
Если пакет **попал** (замэтчился) в ACL привязанного пула — он переходит на следующий этап проверки. Если **не попал** ни в один ACL ни одного пула — пакет прозрачно пропускается обратно в сеть оператора.
|
||||
- совпало правило `allow`/`permit` — пакет обслуживается этим пулом и идёт дальше по цепочке;
|
||||
- совпало правило `deny` — этот пул для пакета больше не рассматривается, проверяются следующие;
|
||||
- не совпало ни одно правило — тоже переход к следующему пулу.
|
||||
|
||||
При наличии нескольких пулов трафик попадает в пул с **наивысшим приоритетом**, ACL которого совпал первым.
|
||||
Если подходящего пула не нашлось, пакет прозрачно уходит в парный порт. Назначать нескольким пулам одинаковый приоритет не следует: по документации производителя тогда будет задействован только один из них. IPv6-трафик отбирается собственными настройками пула: обработку IPv6 нужно включить, иначе сессии по IPv6 не заводятся и этот трафик проходит через фильтр прозрачно ([разделы 15.4](15.md) и [16.6](16.md)).
|
||||
|
||||
> **Важно:** при заводской (дефолтной) конфигурации фильтра пулы и ACL **отсутствуют**. Их необходимо создать при первоначальной настройке. Без созданного пула и привязанного ACL фильтр будет прозрачно пропускать весь трафик — какие бы настройки DPI-листов ни были заданы, обработка не произойдёт.
|
||||
Пул выбирается при создании сессии — по первому пакету потока; следующие пакеты фильтр находит в таблице сессий, и вся дальнейшая обработка ведётся в рамках сессий ([раздел 12](12.md)). Здесь фильтр может и отбросить пакет ещё до DPI: по умолчанию TCP-сессия заводится только по пакету с флагом SYN, а TCP-пакет без SYN, для которого сессии нет, отбрасывается. В ТСПУ такое поведение отключают параметром `permit_invalid_flow` ([раздел 5.2](#52-работа-на-уровне-l2-фильтр-как-прозрачный-провод)).
|
||||
|
||||
> **Важно:** в заводской конфигурации фильтра пулов и ACL нет. Пока они не созданы, фильтр пропускает весь трафик прозрачно, какие бы DPI-листы ни были настроены. Признак такой ситуации — нулевая скорость создания сессий в `show cps` при идущем через фильтр трафике ([раздел 18.9](18.md)).
|
||||
|
||||
### 5.1.3. Проверка по DPI-листу (IP-подсети)
|
||||
|
||||
После прохождения ACL и попадания в пул пакет проверяется на уровне **DPI-листа**. DPI-лист — это набор правил фильтрации, содержащий списки IP-адресов, подсетей и URL для обработки. На фильтре может быть настроено **до 16 DPI-листов** (номера 0–15), каждый из которых может быть включён или выключен независимо.
|
||||
Следующий этап — **DPI-листы**. DPI-лист объединяет настройки одной политики фильтрации: на какой трафик она распространяется, что в нём ищется (загружаемый список IP-адресов, доменов и URL, распознаваемые протоколы) и что делать при совпадении ([раздел 5.1.5](#515-решение-пропустить-или-заблокировать-drop)). Подробно настройки DPI-листов описаны в [разделе 17.4](17.md).
|
||||
|
||||
В рамках DPI-листа определены **параметры IP**, которые задают, какой именно трафик подлежит обработке данным листом:
|
||||
Набор листов задан прошивкой: это листы с номерами 0–16 — лист 0 и шестнадцать листов 1–16. Каждый лист включается и выключается независимо. В более поздних версиях ПО, по документации производителя, листы создаются по мере необходимости командой `create dpilist N` — в стандартной конфигурации с номерами 0–24, по запросу заказчика — до 1000.
|
||||
|
||||
| Параметр | Описание |
|
||||
| ---------------------- | ----------------------------------------------------------------- |
|
||||
| **IP** | Подсети и адреса, которые должны обрабатываться данным DPI-листом |
|
||||
| **No IP** | Локальные адреса абонентов, исключённые из обработки |
|
||||
| **No IP Remote** | Удалённые адреса (серверы), исключённые из обработки |
|
||||
| **IPv6** / **No IPv6** | Аналогичные параметры для IPv6-трафика |
|
||||
Какие адреса обрабатывает лист, задают параметры:
|
||||
|
||||
По умолчанию параметр IP должен содержать сеть `0.0.0.0/0` для всех VLAN — тогда весь трафик, попавший в DPI, будет обрабатываться данным листом. Параметр **No IP** используется, в частности, для диагностики: можно исключить конкретного абонента из обработки DPI-листом, чтобы проверить, влияет ли данный лист на его трафик.
|
||||
| Параметр | Назначение |
|
||||
| ------------------ | ------------------------------------------------------------------------------- |
|
||||
| `ip` | адреса и подсети абонентов (с указанием VLAN), на трафик которых действует лист |
|
||||
| `no_ip` | локальные адреса (абонентов), исключённые из обработки листом |
|
||||
| `no_ip_remote` | удалённые адреса (серверов), исключённые из обработки листом |
|
||||
| `ipv6` / `no_ipv6` | то же для IPv6 |
|
||||
|
||||
Если пакет **не попал** в обработку ни одного активного DPI-листа (его адреса не совпали с заданными подсетями, или он исключён через No IP), он **прозрачно пропускается** дальше без какого-либо анализа.
|
||||
Исключения проверяются первыми: адрес из `no_ip` листом не обрабатывается, даже если входит в `ip`. Штатно в `ip` задаётся сеть `0.0.0.0/0` для всех VLAN — тогда лист действует на весь трафик, дошедший до DPI. Добавить адрес абонента в `no_ip` — удобный способ диагностики: если у абонента после этого что-то изменилось (например, заработало приложение), этот лист на его трафик действительно влиял ([раздел 17.4.8](17.md)).
|
||||
|
||||
Нулевой DPI-лист (`dpi list 0`) в проекте АСБИ всегда используется для **фильтрации по реестру Роскомнадзора**. Остальные листы (1–15) могут использоваться для других задач — например, для блокировки по очищенным протокольным спискам, загружаемым из ЦСУ (подробнее — в [разделе 8](08.md)).
|
||||
В более поздних версиях ПО этих параметров в описании DPI-листа уже нет (в руководстве пользователя EcoSGE 3.1.8 они остались лишь в отдельных примерах конфигурации): вместо них к листу привязывается ACL (`acl`, `aclv6`). Трафик, совпавший с разрешающим правилом, обрабатывается листом, совпавший с запрещающим — передаётся следующему листу; значение по умолчанию `none` равносильно `permit ip any any`, то есть лист действует на весь трафик. Аналог диагностики через `no_ip` здесь — запрещающее правило для адреса абонента в ACL листа.
|
||||
|
||||
Пакет, адреса которого не подпадают ни под один включённый лист, DPI не анализирует — он прозрачно уходит в парный порт. Листы применяются в порядке возрастания номера; если сработали несколько листов, выполняется действие листа с наименьшим номером. Лист с `behaviour ignore` других листов при этом не перекрывает: по руководству EcoSGE 3.1.8 совпавший с ним трафик передаётся на проверку следующему листу.
|
||||
|
||||
В ТСПУ фильтрация по реестру Роскомнадзора выполняется в листе 0. В ранних версиях ПО настройки реестра находятся прямо в листе 0; в более поздних они вынесены в отдельный раздел, лист для реестра выбирается параметром `list_number` (по умолчанию 0; в руководстве EcoSGE 3.1.8 значение по умолчанию не задано, и лист указывают явно), а все листы устроены одинаково ([раздел 17.2](17.md)). Действие (`behaviour`) задаётся для листа целиком, а лист 0 блокирует по реестру, поэтому распознавание протоколов (`ignore`) и блокировку по очищенным спискам из ЦСУ (`block`, например в листе 5) настраивают в других листах ([раздел 8](08.md)).
|
||||
|
||||
### 5.1.4. Обработка движком DPI
|
||||
|
||||
Если пакет прошёл все предварительные проверки (IP → ACL/пул → DPI-лист), он передаётся на **движок DPI** (Deep Packet Inspection) для анализа. На платформе EcoFilter используется движок **ecDPI**, обеспечивающий фильтрацию по спискам и распознавание приложений вплоть до седьмого уровня модели OSI.
|
||||
Трафик, прошедший предварительные проверки, анализирует **движок DPI**. Он сверяет трафик со списками фильтрации — IP-адресами, доменами и URL (для HTTP — по запрошенному URL, для HTTPS — по имени сервера в SNI, [раздел 17.5](17.md)) — и распознаёт протоколы и приложения.
|
||||
|
||||
Движок DPI выполняет **многофакторный анализ сессий** по целому ряду параметров:
|
||||
Распознавание — это **многофакторный анализ сессии**, а не отдельного пакета: движку нужно несколько пакетов сессии в обоих направлениях. Кроме очевидных полей — адресов и портов источника и назначения — учитывается не один десяток признаков, например:
|
||||
|
||||
- **адреса и порты** — source IP, destination IP, source/destination port;
|
||||
- **размеры пакетов** и их вариации в рамках сессии;
|
||||
- **частота прохождения** пакетов;
|
||||
- **ключевые слова и паттерны** внутри пакетов;
|
||||
- **косвенные признаки** для шифрованного трафика (где очевидные поля протокола недоступны).
|
||||
- размеры пакетов и их вариации в рамках сессии;
|
||||
- частота прохождения пакетов;
|
||||
- частота появления тех или иных ключевых слов внутри пакетов.
|
||||
|
||||
Анализ выполняется не над отдельным пакетом, а над **сессией** в целом — движок накапливает информацию о нескольких пакетах в рамках одного соединения и на основе совокупности признаков определяет тип трафика. Для шифрованного трафика (например, VPN-протоколы, мессенджеры) прямое определение по заголовкам невозможно, поэтому используются косвенные признаки: характерные размеры пакетов, частотные паттерны, статистические аномалии.
|
||||
У трафика, который шифруется и намеренно скрывает свою природу (протоколы мессенджеров, обфусцированные VPN), явных полей, указывающих на протокол, нет, поэтому он распознаётся по косвенным признакам. Такое распознавание **не стопроцентно**: другой шифрованный трафик может быть принят, например, за Telegram, и его блокировка задела бы полезные ресурсы. Поэтому для блокировки таких протоколов применяется двухэтапная схема: сначала фильтры только распознают трафик и отправляют логи, а блокируют уже по спискам, очищенным от ложных срабатываний в ЦСУ ([разделы 8](08.md) и [23](23.md)). Распознавание можно обойти — например, протоколом, который маскируется под другой. Если протокол в новой версии перестал распознаваться, нужна новая сигнатура ([раздел 23.4](23.md)).
|
||||
|
||||
Результатом работы движка DPI является **определение протокола/приложения** и проверка по спискам фильтрации (URL, домены, IP-адреса). Дальнейшая судьба пакета определяется параметром **behavior** DPI-листа.
|
||||
Модуль DPI можно выключить целиком — тогда весь трафик проходит через фильтр прозрачно, без анализа. Так проверяют, связана ли проблема абонента с обработкой на фильтре вообще ([раздел 17.1.1](17.md)).
|
||||
|
||||
### 5.1.5. Решение: пропустить или заблокировать (drop)
|
||||
|
||||
По результатам анализа движком DPI фильтр принимает решение о судьбе пакета. Поведение задаётся параметром **behavior** в настройках каждого DPI-листа:
|
||||
По результату анализа фильтр решает судьбу пакета: в общем случае — пропустить его в парный порт или отбросить (drop), если трафик попадает под запрещающую политику. Что делать при срабатывании, задаёт параметр `behaviour` DPI-листа:
|
||||
|
||||
| Значение behavior | Описание |
|
||||
| ----------------- | ------------------------------------------------------------------------------ |
|
||||
| **block** | Трафик, совпавший со списком, блокируется (дропается) |
|
||||
| **ignore** | Совпадение регистрируется и логируется, но никаких действий не предпринимается |
|
||||
| **color** | Совпавший трафик «окрашивается» (в проекте АСБИ не используется) |
|
||||
| **redirect** | Трафик перенаправляется (в проекте АСБИ не используется) |
|
||||
| `behaviour` | Действие | В ТСПУ |
|
||||
| ----------- | -------------------------------------------------------------------------------------------------------------- | ------------------------ |
|
||||
| `block` | блокировка: HTTP — перенаправление на страницу-заглушку (если задан `redirect_url`), HTTPS — разрыв соединения | основной режим |
|
||||
| `ignore` | никаких действий: срабатывание только фиксируется | распознавание протоколов |
|
||||
| `color` | маркировка: в байт ToS IP-заголовка записывается заданное значение | не используется |
|
||||
| `redirect` | перенаправление HTTP, HTTPS пропускается | не используется |
|
||||
|
||||
В рамках проекта АСБИ используются преимущественно два режима:
|
||||
В более поздних версиях ПО, по документации производителя, есть также значения `drop` (блокировка без TCP Reset и без перенаправления), `pass` (пропустить, не проверяя остальными листами) и `ignore_ipv4` (для IPv4 — как `ignore`, IPv6 блокируется).
|
||||
|
||||
**Режим block** — основной рабочий режим для блокировки по реестру Роскомнадзора и по очищенным протокольным спискам. При срабатывании блокировки:
|
||||
**Блокировка (`block`)** — основной режим для реестра Роскомнадзора и для очищенных протокольных списков:
|
||||
|
||||
- Для **HTTP**-трафика абоненту отправляется **HTTP-редирект** (код 302) на страницу-заглушку оператора, информирующую о блокировке ресурса. URL страницы-заглушки задаётся параметром **redirect URL** в настройках DPI-листа.
|
||||
- Для **HTTPS**-трафика содержимое зашифровано, поэтому подмена ответа невозможна. Вместо этого абоненту и серверу отправляется **TCP Reset**, разрывающий соединение.
|
||||
- Для трафика с MPLS-метками фильтр не может самостоятельно сгенерировать ответный пакет: MPLS-путь однонаправлен, и стек меток обратного направления фильтру неизвестен. Поэтому используется особая логика: пакет от абонента пропускается к серверу, фильтр **дожидается ответного пакета** в той же сессии, а затем **подменяет** его содержимое на редирект или TCP Reset, сохраняя метки (подробнее — в [разделе 4.8](04.md)).
|
||||
- **HTTP** — запрос к заблокированному ресурсу не пропускается, а абоненту отправляется ответ с перенаправлением на страницу-заглушку оператора, сообщающую, что ресурс заблокирован. Адрес страницы задаёт параметр `redirect_url`; по документации производителя это ответ «307 Temporary Redirect» с этим адресом в заголовке `Location`. URL передаётся открыто, поэтому блокировать можно конкретную страницу;
|
||||
- **HTTPS** — содержимое зашифровано, и подменить ответ нельзя: ресурс определяется по домену в SNI, а соединение разрывается пакетами TCP Reset. Блокируется домен целиком ([раздел 17.5.3](17.md)). По документации производителя проверяется и сертификат сервера, если он передаётся открыто (до TLS 1.3), а соединение без SNI пропускается;
|
||||
- **трафик с MPLS-метками** — ответ абоненту фильтр сам сформировать не может: MPLS-путь однонаправлен, и стек меток обратного направления фильтру неизвестен. Поэтому запрос абонента пропускается к серверу, фильтр дожидается ответного пакета в той же сессии и подменяет его содержимое на перенаправление или TCP Reset, сохраняя метки ([раздел 4.8](04.md));
|
||||
- **протоколы, блокировка которых включена в DPI-листе** (указаны в `protocols` листа с `behaviour block`) — пакеты заблокированной сессии отбрасываются, TCP Reset при этом не отправляется (см. ниже про send RST). Вместо полной блокировки протокол можно «деградировать»: параметры деградации (protocols capacity) задают для протокола значение от 0 до 100 в условных единицах (это не проценты): 0 — полная блокировка, 100 — полный пропуск, промежуточные значения — сброс части пакетов сессии с вероятностью, зависящей от значения. Сама по себе настройка деградации — даже значение 0 — ничего не блокирует: она действует только на протоколы, блокировка которых включена в DPI-листе, и не затрагивает лист распознавания с `ignore` ([раздел 17.3](17.md)).
|
||||
|
||||
**Режим ignore** — используется для **распознавания протоколов** без блокировки. Фильтр определяет тип трафика и отправляет логи на SPFS, но сам трафик пропускает. Это первая стадия двухступенчатой блокировки: на этом этапе собираются данные для ЦСУ, которая формирует очищенные от ложных срабатываний списки и загружает их в другой DPI-лист, уже работающий в режиме block (подробнее — в [разделе 8](08.md)).
|
||||
**Распознавание (`ignore`)** — первая стадия двухэтапной блокировки: лист со списком распознаваемых протоколов срабатывает, но трафик не трогает, а логи о распознанных сессиях уходят на SPFS и далее в ЦСУ ([разделы 8](08.md) и [14.10](14.md)). ЦСУ отсеивает ложные срабатывания и загружает очищенные списки в **другой** DPI-лист — с `behaviour block`.
|
||||
|
||||
Каждый DPI-лист также поддерживает переключение режима **blacklist / whitelist** (параметр **WH list mode**):
|
||||
**Белый список.** Параметр `whitelist_mode` переключает лист из режима чёрного списка (по умолчанию: совпавшее блокируется, остальное пропускается) в режим белого: пропускается только совпавшее, всё остальное блокируется. В ТСПУ этот режим не используется — ошибка в таком листе может отрезать абонентам весь трафик; он нужен в других сценариях, например вместе с функциями BRAS.
|
||||
|
||||
- **Blacklist** (по умолчанию) — всё, что совпало со списком, блокируется; всё остальное пропускается;
|
||||
- **Whitelist** — пропускается только совпавший трафик; всё остальное блокируется.
|
||||
|
||||
Режим whitelist в проекте АСБИ **не используется** из-за риска случайной блокировки всего трафика.
|
||||
|
||||
Отдельная проблема — **отправка TCP Reset при блокировке протоколов**. Если приложение абонента (например, мессенджер) получает TCP Reset при попытке установить соединение, оно немедленно пытается установить новое соединение — и делает это непрерывно с высокой частотой. Количество генерируемых сессий может быть огромным, создавая избыточную нагрузку на фильтр. Для решения этой проблемы предусмотрен параметр **send RST off**, отключающий отправку TCP Reset при блокировке протоколов (подробнее — в [разделе 17.1.2](17.md)).
|
||||
**TCP Reset при блокировке протоколов (send RST).** Приложение (например, Telegram), получив TCP Reset в ответ на попытку соединения, тут же пытается соединиться снова — непрерывно и очень быстро, порождая огромное число сессий; наблюдались случаи, когда мобильные устройства абонентов из-за этого начинали тормозить. Поэтому отправку TCP Reset при блокировке протоколов можно отключить общим параметром модуля DPI send RST, и в ТСПУ он **всегда `off`**: попытка соединения просто отбрасывается, соединение висит и обрывается по тайм-ауту, и лавины новых сессий не возникает ([раздел 17.1.2](17.md)). В руководствах пользователя EcoSGE такого общего параметра нет; в более поздних версиях ПО блокировку без TCP Reset и без перенаправления задают для отдельного листа значением `behaviour drop`.
|
||||
|
||||
## 5.2. Работа на уровне L2: фильтр как «прозрачный провод»
|
||||
|
||||
Несмотря на то, что фильтр анализирует IP-трафик вплоть до седьмого уровня модели OSI, с точки зрения **сетевой топологии** он работает на **уровне L2** (канальном уровне). Для внешнего наблюдателя — оператора связи, маршрутизаторов, коммутаторов — фильтр представляет собой **прозрачный провод**: пакет входит через один интерфейс и выходит через парный, без каких-либо видимых изменений на сетевом уровне.
|
||||
Хотя фильтр анализирует трафик вплоть до седьмого уровня модели OSI, в топологии сети он работает на **уровне L2**. Для оператора и его оборудования фильтр — **прозрачный провод**: кадры входят в один порт пары и выходят из парного, а изменения вносятся только в пакеты блокируемых сессий. Это обеспечивают несколько свойств и настроек; описание относится к подключению парами портов в ТСПУ тип А (о схеме on-a-stick — в [разделе 7.3.3](07.md)).
|
||||
|
||||
Ключевые характеристики L2-работы фильтра:
|
||||
**Нет L3-интерфейсов в тракте.** В ОС Linux, на которой построен фильтр, виден только management-интерфейс. Порты тракта, как и лог-интерфейсы, отданы под управление **DPDK** (Data Plane Development Kit) и процессу EcoNAT, который обрабатывает пакеты напрямую, минуя сетевой стек ОС. IP-адресов у портов тракта нет: ping и traceroute с фильтра выполняются только через management-интерфейс ([раздел 18.14](18.md)), а собственного трафика в тракт фильтр (при выключенном LLDP — см. ниже) не инициирует. Исключение — пакеты, которые он вставляет в блокируемые сессии: перенаправление и TCP Reset, адресованные участникам сессии.
|
||||
|
||||
**Отсутствие L3-интерфейсов в тракте данных.** На пути прохождения трафика у фильтра нет IP-интерфейсов. Если посмотреть на интерфейсы ОС Linux, на которой основано устройство, там виден только **management-интерфейс** (используемый для удалённого управления). Все остальные интерфейсы отданы под управление **DPDK** (Data Plane Development Kit) и процессу EcoNAT, который обрабатывает трафик напрямую, минуя сетевой стек операционной системы.
|
||||
**Заголовки инкапсуляции сохраняются.** VLAN-теги, MPLS-метки и другие заголовки фильтр не снимает и не меняет: он разбирает их только для того, чтобы найти IP-пакет, и все манипуляции выполняет с IP-пакетом. Кадр выходит из фильтра с тем же стеком заголовков, с каким вошёл, — включая 4-байтный заголовок балансировщика.
|
||||
|
||||
**Невозможность генерации трафика.** Фильтр — это L2-устройство, у которого нет IP-интерфейсов для инициирования трафика. Нельзя, например, выполнить ping с фильтра в сторону оператора через LAN/WAN-интерфейсы. Ping и traceroute возможны только через management-интерфейс (подробнее — в [разделе 18.14](18.md)).
|
||||
**Пересылка включена.** Параметр `forward_traffic` в `nat_defaults` (по умолчанию `on`) разрешает пересылку кадров через фильтр; значение `off` нужно, только когда фильтр анализирует зеркалированный трафик и обратно от него ничего не ждут. В ТСПУ фильтр стоит в разрыв, поэтому `forward_traffic` всегда `on`, а режим работы модуля DPI (`functionality_mode`) — обычный, для схемы «в разрыв», а не для зеркалированного трафика ([разделы 15.2.3](15.md) и [17.1.3](17.md)).
|
||||
|
||||
**Сохранение всех заголовков инкапсуляции.** Фильтр не снимает и не модифицирует VLAN-теги, MPLS-метки и любые другие заголовки инкапсуляции. Все манипуляции выполняются **только с IP-пакетом** внутри стека заголовков. Пакет выходит из фильтра с теми же тегами и метками, с которыми он вошёл.
|
||||
**LLDP выключен.** По документации производителя LLDP на платформе по умолчанию включён: устройство периодически (в разных редакциях документации — раз в 30 или 60 секунд) рассылает LLDP-сообщения через все задействованные интерфейсы, и соседнее оборудование видит его в своей топологии. В ТСПУ LLDP выключают (`lldp off` в `nat_defaults`) по просьбе операторов связи: оборудование должно оставаться невидимым и не появляться на схемах их сети ([раздел 15.2.5](15.md)).
|
||||
|
||||
**Отключение LLDP.** Протокол LLDP (Link Layer Discovery Protocol) на фильтрах **выключен** по требованию операторов связи. Операторы не хотят видеть устройства ТСПУ в своей сетевой топологии — оборудование должно быть полностью прозрачным и невидимым. Если LLDP включён, устройство «появляется» на схемах сети оператора, что нежелательно.
|
||||
**L2 MTU — 9216 байт.** Параметр `l2mtu` задаёт максимальный размер принимаемого Ethernet-кадра — с заголовками, но без контрольной суммы. Кадр длиннее этого значения фильтр не пропускает, а отбрасывает (такие потери видны в выводе `show interface <имя>` как «Packets droped because of L2MTU»). Значение по умолчанию — 1522 байта (в более поздних версиях ПО, по документации производителя, — 9216), максимум — 9692 байта. В ТСПУ ставят 9216 — распространённый предельный размер jumbo-кадра у сетевого оборудования; на портах балансировщиков MTU выставляют около 9000 байт. Для абонентского трафика этого хватает с большим запасом, тогда как при значении 1522 не прошёл бы уже 1500-байтный IP-пакет в QinQ-кадре с заголовком балансировщика (14 + 8 + 4 + 1500 = 1526 байт). Если же оператор передаёт jumbo-кадры, кадр вместе с 4-байтным заголовком должен укладываться и в L2 MTU фильтра, и в MTU портов балансировщика — это согласуют при проектировании ([раздел 4.5.3](04.md)).
|
||||
|
||||
**Максимальный L2 MTU.** Для обеспечения прозрачности параметр L2 MTU на фильтрах устанавливается в **максимально возможное значение — 9216 байт** (по RFC). Аналогичные значения (около 9000) выставляются на интерфейсах балансировщиков. Это позволяет полностью закрыть проблему с MTU и не возвращаться к ней в процессе эксплуатации.
|
||||
**`permit_invalid_flow` включён.** По умолчанию параметр выключен: TCP-сессия заводится только по пакету с флагом SYN, а TCP-пакеты без SYN, для которых сессии нет, считаются ошибочными или вредоносными и отбрасываются. Для NAT-устройства это нормальное поведение, для фильтра — опасное: он часто видит TCP-сессии не с начала, а «с середины»:
|
||||
|
||||
**Параметр permit invalid flow.** В проекте АСБИ этот параметр должен быть **всегда включён**. Он разрешает заведение TCP-сессий без наличия начального TCP SYN-пакета. Это критически важно при переключении ТСПУ из режима TAP в рабочий режим (Inline): в момент переключения на фильтры хлынет трафик множества уже установленных TCP-сессий, для которых SYN-пакет был отправлен ранее. Без параметра permit invalid flow фильтр будет **дропать** все такие сессии, что приведёт к массовому разрыву соединений абонентов. С включённым параметром фильтр принимает пакеты «с середины» сессии и заводит для них сессионные записи (подробнее — в [разделе 15.2.6](15.md)).
|
||||
- **после возврата ТСПУ из байпаса в рабочий режим** — из аппаратного байпаса в Inline или из программного байпаса балансировщика, в том числе отдельной пары портов ([разделы 3.5](03.md) и [4.6.2](04.md)), — а также при первом включении в тракт на фильтры сразу приходит трафик множества уже установленных сессий, SYN которых фильтр не видел. С выключенным параметром фильтр будет его дропать: все эти TCP-сессии абонентов оборвутся по тайм-ауту, и их придётся устанавливать заново;
|
||||
- **при перераспределении трафика** — когда балансировщик перебалансирует нагрузку и сессии переезжают на другой фильтр ([раздел 4.6.3](04.md)), а также после перезапуска фильтра, когда таблица сессий пуста;
|
||||
- **при несимметричном трафике** — когда исходящий трафик сессии прошёл через одну площадку или один фильтр, а ответный — через другой: второй фильтр не видел SYN, с которого абонент начал соединение, и сессия там не заведётся;
|
||||
- **для долго молчащих TCP-соединений** (по документации производителя): когда сессия на фильтре удалена по тайм-ауту неактивности, следующий пакет соединения приходит уже без SYN.
|
||||
|
||||
Поэтому в ТСПУ параметр **всегда включён**: фильтр принимает пакеты «с середины» и заводит для них сессии. Параметр глобальный — действует на всё устройство и в пулах не переопределяется; изменение применяется командой `apply` ([раздел 15.2.6](15.md)).
|
||||
|
||||
---
|
||||
|
||||
|
||||
+1
-1
@@ -35,7 +35,7 @@
|
||||
|
||||
Важно: PPPoE-трафик существует **только на участке до BRAS**. Выше BRAS (то есть ближе к интернету) PPPoE-трафика в нормально функционирующих сетях не бывает — BRAS терминирует PPPoE-сессии и дальше передаёт обычные IP-пакеты.
|
||||
|
||||
Наличие PPPoE не является критической проблемой — фильтры умеют работать с этой инкапсуляцией. Однако это дополнительная сложность, которую необходимо учитывать при настройке. Параметр **VLAN Mode** на фильтрах должен быть установлен в **QinQ**, чтобы обеспечить корректный поиск IP-заголовка внутри PPPoE-инкапсуляции (подробнее — в [разделе 5.1.1](05.md)).
|
||||
Наличие PPPoE не является критической проблемой — это ещё один уровень инкапсуляции, который фильтру нужно разбирать. Однако его необходимо учитывать при настройке: VLAN-теги фильтр разбирает согласно параметру `vlan_mode` (в проекте — `qinq`), а для обработки самого PPPoE в документации производителя описан отдельный параметр `pppoe_analyzer` (по умолчанию выключен; подробнее — в [разделе 5.1.1](05.md)).
|
||||
|
||||
## 6.2. До CGNAT (после BRAS) — наиболее удобная точка
|
||||
|
||||
|
||||
+3
-3
@@ -15,7 +15,7 @@
|
||||
3. Фильтр фиксирует результат распознавания в виде **протокольного лога** — записи о том, что конкретная сессия предварительно опознана как сессия определённого протокола;
|
||||
4. Сессия при этом **не блокируется** — трафик продолжает проходить без ограничений.
|
||||
|
||||
Распознавание выполняется в рамках DPI-листа (например, DPI-лист 0), на котором установлен режим **behavior: ignore** — это означает, что срабатывание правил фиксируется, но никаких блокирующих действий не предпринимается.
|
||||
Распознавание выполняется в отдельном DPI-листе, на котором установлен режим **behavior: ignore** — это означает, что срабатывание правил фиксируется, но никаких блокирующих действий не предпринимается. Лист 0 для этого не используется: в нём по умолчанию работает фильтрация по реестру Роскомнадзора ([раздел 5.1.3](05.md)).
|
||||
|
||||
## 8.2. Отправка логов на SPFS (сервер предварительного формирования списков)
|
||||
|
||||
@@ -86,11 +86,11 @@ SPFS занимается **накоплением** поступающих пр
|
||||
|
||||
| DPI-лист | Назначение | Behavior |
|
||||
|----------|-----------|----------|
|
||||
| DPI-лист 0 | Распознавание протоколов (первый этап) | **ignore** — срабатывание фиксируется, но не блокируется |
|
||||
| Лист распознавания | Распознавание протоколов (первый этап) | **ignore** — срабатывание фиксируется, но не блокируется |
|
||||
| DPI-лист 5 (пример) | Блокировка по очищенным спискам из ЦСУ | **block** — трафик блокируется |
|
||||
|
||||
Таким образом, на одном фильтре **одновременно работают два процесса**:
|
||||
- в DPI-листе 0 продолжается распознавание новых сессий и отправка логов;
|
||||
- в листе распознавания продолжается распознавание новых сессий и отправка логов;
|
||||
- в DPI-листе 5 выполняется блокировка по уже проверенным и очищенным спискам.
|
||||
|
||||
### Загрузка на Eco Highway (по BGP)
|
||||
|
||||
+1
-1
@@ -121,7 +121,7 @@
|
||||
│
|
||||
├──── URL-фильтрация
|
||||
│
|
||||
├──── PPPoE BRAS (не используется в проекте ТСПУ)
|
||||
├──── IPoE BRAS (не используется в проекте ТСПУ)
|
||||
│
|
||||
├──── Router (параллельная ветка, не используется)
|
||||
│
|
||||
|
||||
+1
-1
@@ -48,7 +48,7 @@ CLI фильтра имеет **два режима** работы:
|
||||
│ ├── serial ← консольный порт
|
||||
│ ├── terminal ← SSH-настройки
|
||||
│ ├── users ← пользователи
|
||||
│ ├── nat-defaults← параметры сессий, тайм-аутов
|
||||
│ ├── nat_defaults← параметры сессий, тайм-аутов
|
||||
│ ├── dpi ← настройки DPI
|
||||
│ └── ...
|
||||
├── pools ← пулы обработки трафика
|
||||
|
||||
+14
-14
@@ -22,19 +22,19 @@
|
||||
|
||||
## 15.2. NAT Defaults — общие параметры устройства
|
||||
|
||||
Секция `nat-defaults` содержит общие параметры, влияющие на работу всего устройства. Название секции — наследие от CGNAT-платформы, однако параметры применяются ко всему функционалу фильтра, включая DPI.
|
||||
Секция `nat_defaults` содержит общие параметры, влияющие на работу всего устройства. Название секции — наследие от CGNAT-платформы, однако параметры применяются ко всему функционалу фильтра, включая DPI.
|
||||
|
||||
### 15.2.1. VLAN Mode: untag / vlan / QinQ — глубина поиска IP-заголовка (всегда QinQ)
|
||||
### 15.2.1. VLAN Mode: untagged / vlan / qinq — глубина поиска IP-заголовка (всегда qinq)
|
||||
|
||||
Параметр **VLAN Mode** определяет, насколько глубоко фильтр ищет IP-заголовок внутри Ethernet-фрейма:
|
||||
Параметр **VLAN Mode** (`vlan_mode`) определяет, насколько глубоко фильтр ищет IP-заголовок внутри Ethernet-фрейма:
|
||||
|
||||
| Значение | Поведение | Применение в ТСПУ |
|
||||
| ------------ | ----------------------------------------------------------------- | ------------------ |
|
||||
| **untag** | IP-заголовок ищется только в нетегированных фреймах. Пакеты с VLAN-тегами пропускаются прозрачно | Нет |
|
||||
| **untagged** | IP-заголовок ищется только в нетегированных фреймах. Пакеты с VLAN-тегами пропускаются прозрачно | Нет |
|
||||
| **vlan** | IP-заголовок ищется в пакетах без тегов и с одним VLAN-тегом | Нет |
|
||||
| **QinQ** | IP-заголовок ищется при любом количестве VLAN-тегов: 0, 1 или 2 | **Всегда** |
|
||||
| **qinq** | IP-заголовок ищется при любом количестве VLAN-тегов: 0, 1 или 2 | **Всегда** |
|
||||
|
||||
В проекте ТСПУ параметр **всегда должен быть установлен в `QinQ`**. При любом другом значении часть трафика (с VLAN-тегами) будет **прозрачно пропускаться** без обработки, что недопустимо.
|
||||
В проекте ТСПУ параметр **всегда должен быть установлен в `qinq`**. При любом другом значении часть трафика (с VLAN-тегами) будет **прозрачно пропускаться** без обработки, что недопустимо.
|
||||
|
||||
### 15.2.2. Sessions per Translation (по умолчанию 4096)
|
||||
|
||||
@@ -51,15 +51,15 @@
|
||||
|
||||
В проекте ТСПУ параметр **всегда должен быть `on`** (значение по умолчанию). Режим `off` используется только при работе с зеркалированным трафиком, что в данном проекте не применяется.
|
||||
|
||||
### 15.2.4. L2 MTU: максимум 9216 (по RFC)
|
||||
### 15.2.4. L2 MTU: 9216
|
||||
|
||||
Параметр **L2 MTU** определяет максимальный размер кадра на уровне L2. По умолчанию установлено значение **1522**.
|
||||
Параметр **L2 MTU** (`l2mtu`) определяет максимальный размер принимаемого Ethernet-кадра — с заголовками, но без контрольной суммы. По умолчанию установлено значение **1522** (в более поздних версиях ПО, по документации производителя, — 9216); максимально допустимое значение — 9692.
|
||||
|
||||
В проекте ТСПУ рекомендуется устанавливать **максимально возможное значение — 9216** (максимум по RFC). Это позволяет полностью исключить проблемы с MTU:
|
||||
В проекте ТСПУ устанавливается значение **9216** — распространённый предельный размер jumbo-кадра у сетевого оборудования. Это позволяет полностью исключить проблемы с MTU:
|
||||
|
||||
```text
|
||||
nat-defaults
|
||||
l2-mtu 9216
|
||||
nat_defaults
|
||||
l2mtu 9216
|
||||
```
|
||||
|
||||
На балансировщиках MTU на интерфейсах также выставляется в районе **9000**, что позволяет закрыть проблему MTU на всей цепочке оборудования ТСПУ.
|
||||
@@ -83,7 +83,7 @@
|
||||
|
||||
**Почему `off` опасен в контексте ТСПУ:**
|
||||
|
||||
1. **Переключение режимов.** При переключении ТСПУ из режима байпаса обратно в рабочий режим (inline) на фильтры мгновенно поступает большой объём трафика — уже установленных TCP-сессий. SYN-пакеты для этих сессий давно прошли. Если `permit invalid flow` выключен, фильтр **дропнет** весь этот трафик. Для абонентов это означает, что **все их TCP-сессии** отвалятся по тайм-ауту и потребуют переустановки;
|
||||
1. **Переключение режимов.** При переключении ТСПУ из режима байпаса обратно в рабочий режим (inline) на фильтры мгновенно поступает большой объём трафика — уже установленных TCP-сессий. SYN-пакеты для этих сессий давно прошли. Если `permit_invalid_flow` выключен, фильтр **дропнет** весь этот трафик. Для абонентов это означает, что **все их TCP-сессии** отвалятся по тайм-ауту и потребуют переустановки;
|
||||
|
||||
2. **Асимметричный трафик.** Если исходящий трафик уходит через один фильтр, а входящий приходит через другой — на одном из фильтров сессия не будет установлена (нет SYN-флага), и трафик будет дропаться.
|
||||
|
||||
@@ -91,11 +91,11 @@
|
||||
|
||||
## 15.3. Тайм-ауты сессий и трансляций
|
||||
|
||||
В секции `nat-defaults` также настраиваются **тайм-ауты** для сессий и трансляций (подробнее о сессиях и трансляциях — в [разделе 12](12.md)):
|
||||
В секции `nat_defaults` также настраиваются **тайм-ауты** для сессий и трансляций (подробнее о сессиях и трансляциях — в [разделе 12](12.md)):
|
||||
|
||||
- Тайм-ауты для **трансляций** и **сессий** задаются **раздельно**;
|
||||
- Параметры различаются по типу протокола (TCP, UDP, ICMP);
|
||||
- Значения в `nat-defaults` являются **значениями по умолчанию**, которые наследуются каждым создаваемым пулом;
|
||||
- Значения в `nat_defaults` являются **значениями по умолчанию**, которые наследуются каждым создаваемым пулом;
|
||||
- При необходимости тайм-ауты могут быть **переопределены** на уровне конкретного пула.
|
||||
|
||||
В секции также присутствует параметр **limiter** — ограничения на количество выделяемых портов для одного пользователя. Этот параметр актуален **только для NAT** и в проекте ТСПУ **не используется**.
|
||||
|
||||
+6
-6
@@ -38,7 +38,7 @@ ACL (Access Control List) — это набор правил, определяю
|
||||
| ---------------- | ---------------------------------------------------------------- | ------------------------------ |
|
||||
| **Номер** | Порядковый номер правила (рекомендуется с зазором: 10, 20, 30) | `10`, `20`, `30` |
|
||||
| **Действие** | `allow` (или `permit`) / `deny` — разрешить или запретить | `allow`, `deny` |
|
||||
| **Протокол** | IP, TCP, UDP, ICMP и др. | `ip`, `tcp`, `udp` |
|
||||
| **Протокол** | `ip` (любой), `tcp`, `udp`, `icmp` | `ip`, `tcp`, `udp` |
|
||||
| **Source** | Источник: хост, подсеть или `any` (любой) | `any`, `10.0.0.0/8`, `host 1.2.3.4` |
|
||||
| **Destination** | Назначение: хост, подсеть или `any` | `any`, `192.168.0.0/16` |
|
||||
| **VLAN** | Номер или диапазон VLAN (необязательно) | `vlan 100`, `vlan 100-200` |
|
||||
@@ -74,7 +74,7 @@ ACL (Access Control List) — это набор правил, определяю
|
||||
apply
|
||||
```
|
||||
|
||||
Правила обрабатываются **по порядку номеров** — первое совпавшее правило определяет судьбу пакета. Это аналогично работе ACL на маршрутизаторах: если пакет совпал с правилом `allow`, он направляется в пул; если с правилом `deny` — прозрачно пропускается мимо пула.
|
||||
Правила обрабатываются **по порядку номеров** — первое совпавшее правило определяет судьбу пакета. Это аналогично работе ACL на маршрутизаторах: если пакет совпал с правилом `allow`, он направляется в пул; если с правилом `deny` — этот пул для пакета больше не рассматривается и проверяются следующие пулы; не попав ни в один пул, пакет прозрачно проходит через фильтр ([раздел 5.1.2](05.md)).
|
||||
|
||||
## 16.2. Создание пула: `create pool`, тип = fake (без NAT)
|
||||
|
||||
@@ -144,11 +144,11 @@ ACL (Access Control List) — это набор правил, определяю
|
||||
|
||||
## 16.4. Приоритет пулов
|
||||
|
||||
При наличии нескольких пулов на фильтре трафик может совпасть с ACL **разных пулов**. В этом случае пакет попадёт в пул с **наивысшим приоритетом**.
|
||||
При наличии нескольких пулов на фильтре трафик может совпасть с ACL **разных пулов**. В этом случае пакет попадёт в пул с **наивысшим приоритетом** — с наименьшим значением `priority`: пулы проверяются по возрастанию этого значения.
|
||||
|
||||
| Параметр | Описание |
|
||||
| ------------- | ----------------------------------------------------------- |
|
||||
| **priority** | Числовое значение приоритета пула (чем выше — тем приоритетнее) |
|
||||
| **priority** | Числовое значение приоритета пула (чем меньше — тем раньше проверяется пул) |
|
||||
|
||||
На практике в проекте ТСПУ обычно используется **один пул**, поэтому настройка приоритета, как правило, не требуется. Однако при необходимости разделения трафика на разные пулы (например, для разных DPI-листов или разных политик обработки) приоритеты позволяют контролировать порядок отбора.
|
||||
|
||||
@@ -165,9 +165,9 @@ ACL (Access Control List) — это набор правил, определяю
|
||||
|
||||
Помимо connection log, в пуле присутствуют:
|
||||
|
||||
- **Тайм-ауты** — наследуются из секции `nat-defaults` при создании пула (подробнее — в [разделе 15.3](15.md)). При необходимости могут быть переопределены на уровне пула;
|
||||
- **Тайм-ауты** — наследуются из секции `nat_defaults` при создании пула (подробнее — в [разделе 15.3](15.md)). При необходимости могут быть переопределены на уровне пула;
|
||||
- **Ограничения на пользователей (limiter)** — актуальны только для NAT, в проекте ТСПУ **не используются**;
|
||||
- **Параметр PIN** — по умолчанию включён, актуален для режима с трансляцией адресов. В проекте ТСПУ менять не требуется.
|
||||
- **Параметр `hairpin`** — по умолчанию включён, актуален для режима с трансляцией адресов (позволяет абонентам обмениваться трафиком через NAT, не выходя вовне). В проекте ТСПУ менять не требуется.
|
||||
|
||||
## 16.6. IPv6 в пуле
|
||||
|
||||
|
||||
+4
-4
@@ -6,7 +6,7 @@
|
||||
|
||||
Модуль DPI (Deep Packet Inspection) — ключевая подсистема фильтра, отвечающая за анализ и фильтрацию трафика. Настройки DPI включают общие параметры модуля, конфигурацию работы с реестром Роскомнадзора, параметры деградации протоколов и индивидуальные настройки DPI-листов.
|
||||
|
||||
> **Примечание:** формат секции DPI различается между пилотным проектом (Урал) и федеральным проектом. В пилотном проекте настройки реестра Роскомнадзора находятся внутри DPI-листа 0. В федеральном проекте они вынесены в отдельную секцию, а все DPI-листы (0–15) стали абсолютно идентичными по структуре.
|
||||
> **Примечание:** формат секции DPI различается между пилотным проектом (Урал) и федеральным проектом. В пилотном проекте настройки реестра Роскомнадзора находятся внутри DPI-листа 0. В федеральном проекте они вынесены в отдельную секцию, а все DPI-листы (0–16) стали абсолютно идентичными по структуре.
|
||||
|
||||
## 17.1. Общие настройки модуля DPI
|
||||
|
||||
@@ -145,7 +145,7 @@
|
||||
|
||||
## 17.4. Настройка DPI-листов (0–16)
|
||||
|
||||
На фильтре может быть настроено до **16 DPI-листов** (номера 0–15). В будущих прошивках это количество может быть расширено — планируется возможность генерации DPI-листов по необходимости на уровне конфигурации.
|
||||
На фильтре настраиваются DPI-листы с номерами **0–16** — лист 0 и шестнадцать листов 1–16. В более поздних версиях ПО листы создаются по мере необходимости командой `create dpilist N` (по документации производителя — в стандартной конфигурации с номерами 0–24, по запросу заказчика до 1000).
|
||||
|
||||
Все DPI-листы имеют **одинаковую структуру** настроек (в федеральном проекте). Каждый лист настраивается индивидуально.
|
||||
|
||||
@@ -185,14 +185,14 @@
|
||||
|
||||
| Значение | Описание | Применение в ТСПУ |
|
||||
| ------------ | -------------------------------------------------------- | ---------------------------- |
|
||||
| **block** | Трафик блокируется (дропается) | Основной рабочий режим |
|
||||
| **block** | HTTP — перенаправление на заглушку, HTTPS — TCP Reset | Основной рабочий режим |
|
||||
| **ignore** | Совпадение фиксируется и логируется, трафик пропускается | Для распознавания протоколов |
|
||||
| **color** | Совпавший трафик «окрашивается» | Не используется |
|
||||
| **redirect** | Трафик перенаправляется | Не используется |
|
||||
|
||||
**Режим block** — основной для блокировки по реестру Роскомнадзора и по очищенным протокольным спискам. При срабатывании блокировки:
|
||||
|
||||
- Для **HTTP**: абоненту отправляется HTTP-редирект (302) на страницу-заглушку;
|
||||
- Для **HTTP**: абоненту отправляется HTTP-редирект на страницу-заглушку (по документации производителя — ответ «307 Temporary Redirect»);
|
||||
- Для **HTTPS**: абоненту и серверу отправляется TCP Reset, разрывающий соединение (поскольку содержимое зашифровано и подмена ответа невозможна).
|
||||
|
||||
**Режим ignore** — используется для **первой стадии двухстадийной блокировки**: фильтр распознаёт протоколы и отправляет логи на SPFS, но сам трафик не блокирует. Данные передаются в ЦСУ для формирования очищенных списков (подробнее — в [разделе 8](08.md)).
|
||||
|
||||
+1
-1
@@ -113,7 +113,7 @@ DPI-движок также анализирует **содержимое пак
|
||||
|
||||
| DPI-лист | Behavior | Назначение |
|
||||
| ------------------- | ---------- | ------------------------------------------------------ |
|
||||
| DPI-лист 0 | **ignore** | Распознавание протоколов, запись логов, без блокировки |
|
||||
| Лист распознавания | **ignore** | Распознавание протоколов, запись логов, без блокировки |
|
||||
| DPI-лист 5 (пример) | **block** | Блокировка по очищенным спискам из ЦСУ |
|
||||
|
||||
Таким образом, распознавание и блокировка выполняются **в разных DPI-листах** — это позволяет независимо управлять каждым процессом.
|
||||
|
||||
Reference in New Issue
Block a user