mirror of
https://github.com/DanielLavrushin/tspu-docs.git
synced 2026-10-13 09:28:11 +03:00
Новая нумерация и оглавление по частям, раздел 22 объединён, заглушки по старым адресам
This commit is contained in:
Daniel Lavrushin
+41
-41
@@ -1,16 +1,16 @@
|
||||
# 5. Фильтр (EcoFilter)
|
||||
# 10. Фильтр: принцип работы
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 4: Балансировщик](04.md)
|
||||
[← Оглавление](../README.md) · [← Раздел 9: Балансировщик: мониторинг и диагностика](balancer-monitoring.md)
|
||||
|
||||
---
|
||||
|
||||
Фильтр — основное устройство ТСПУ: он анализирует трафик и применяет к нему политики блокировки. Это сервер 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)).
|
||||
Фильтр — основное устройство ТСПУ: он анализирует трафик и применяет к нему политики блокировки. Это сервер EcoFilter на платформе RDP.ru EcoSGE. Программный комплекс фильтра вырос из CGNAT-устройства, и трафик на нём обрабатывает процесс **EcoNAT** — на всех ядрах процессора, кроме одного сервисного ([раздел 6.5.2](balancer.md)). Из функций платформы (NAT, BRAS, управление качеством сервиса, URL-фильтрация, DPI) в ТСПУ задействованы две: **EcoFilter** — фильтрация по спискам (реестр Роскомнадзора и другие списки) и **EcoDPI** — распознавание протоколов и приложений вплоть до седьмого уровня модели OSI. Происхождением от CGNAT объясняются понятия, с которыми приходится работать на фильтре: пулы, трансляции и сессии, секция общих параметров `nat_defaults` ([разделы 11.6](filter-platform.md), [12](filter-sessions.md), [15.2](filter-interfaces.md) и [16](filter-acl-pools.md)).
|
||||
|
||||
## 5.1. Путь пакета через фильтр
|
||||
## 10.1. Путь пакета через фильтр
|
||||
|
||||
Порты фильтра, через которые идёт трафик, объединены в пары: чётный порт пары — 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)).
|
||||
Порты фильтра, через которые идёт трафик, объединены в пары: чётный порт пары — LAN (сторона абонентов), нечётный — WAN (сторона интернета) ([раздел 11.5](filter-platform.md)). По этой ориентации фильтр определяет, какой адрес сессии локальный (абонентский), а какой удалённый ([раздел 12.5](filter-sessions.md)), поэтому перепутанные LAN и WAN нарушают обработку ([раздел 23.6](troubleshooting.md)). Проходящий через фильтр кадр покидает его только через парный порт. Исключение — пакеты, которые фильтр сам формирует при блокировке: ответ абоненту (перенаправление или TCP Reset) уходит обратно в LAN-порт, через который пришёл запрос. За балансировщиком кадр приходит с 4-байтным служебным заголовком: по нему фильтр выбирает ядро для обработки и с тем же заголовком возвращает кадр на балансировщик ([раздел 6.5.3](balancer.md)).
|
||||
|
||||
Так фильтры подключаются в ТСПУ тип А. В эшелонированной системе (ТСПУ тип Б) фильтр подключён к балансировщику Eco Highway по схеме on-a-stick: порты равноправны, направление обозначает служебный VLAN-тег, который фильтр после обработки меняет на парный, а распознаванием протоколов фильтры там не занимаются ([разделы 7.3.3](07.md) и [7.3.4](07.md)).
|
||||
Так фильтры подключаются в ТСПУ тип А. В эшелонированной системе (ТСПУ тип Б) фильтр подключён к балансировщику Eco Highway по схеме on-a-stick: порты равноправны, направление обозначает служебный VLAN-тег, который фильтр после обработки меняет на парный, а распознаванием протоколов фильтры там не занимаются ([разделы 4.3.3](echelon.md) и [4.3.4](echelon.md)).
|
||||
|
||||
Каждый пакет проходит **цепочку проверок**. Если на каком-то этапе пакет под обработку не подпадает, фильтр сразу передаёт его в парный порт без изменений, и пакет продолжает путь по сети оператора так, будто фильтра в тракте нет. До движка DPI доходит только трафик, прошедший все предварительные проверки:
|
||||
|
||||
@@ -45,9 +45,9 @@
|
||||
перенаправление)
|
||||
```
|
||||
|
||||
Даже первую, самую простую проверку («IP-пакет или нет») выполняет программное ядро фильтра — процесс EcoNAT. Если процесс завис или фильтр перегружен настолько, что перестал обрабатывать трафик, не проходит и она: keep-alive-пакеты балансировщика перестают возвращаться, и балансировщик переводит эту пару портов в программный байпас, а при включённой перебалансировке перераспределяет её трафик по остальным парам портов ([раздел 4.6](04.md)). Поэтому keep-alive проверяют не только физический канал, но и то, что фильтр продолжает обрабатывать трафик. В схеме без балансировщика ту же роль играют heartbeat-пакеты байпаса ([раздел 3.1](03.md)).
|
||||
Даже первую, самую простую проверку («IP-пакет или нет») выполняет программное ядро фильтра — процесс EcoNAT. Если процесс завис или фильтр перегружен настолько, что перестал обрабатывать трафик, не проходит и она: keep-alive-пакеты балансировщика перестают возвращаться, и балансировщик переводит эту пару портов в программный байпас, а при включённой перебалансировке перераспределяет её трафик по остальным парам портов ([раздел 6.6](balancer.md)). Поэтому keep-alive проверяют не только физический канал, но и то, что фильтр продолжает обрабатывать трафик. В схеме без балансировщика ту же роль играют heartbeat-пакеты байпаса ([раздел 5.1](bypass.md)).
|
||||
|
||||
### 5.1.1. Проверка: IP-пакет или нет
|
||||
### 10.1.1. Проверка: IP-пакет или нет
|
||||
|
||||
Сначала фильтр ищет в кадре IP-пакет. Инкапсуляция на стыке оператора зависит от его технологий и от места установки ТСПУ, и вариантов много:
|
||||
|
||||
@@ -57,7 +57,7 @@
|
||||
- PPPoE-трафик, в том числе с двумя VLAN-тегами и внутри MPLS;
|
||||
- и другие комбинации.
|
||||
|
||||
Фильтр не снимает эти заголовки, а разбирает стек, чтобы добраться до IP-пакета: MPLS-метки он просматривает до конца стека, а сколько VLAN-тегов разбирать, задаёт параметр `vlan_mode` (VLAN Mode) в секции `nat_defaults` ([раздел 15.2.1](15.md)):
|
||||
Фильтр не снимает эти заголовки, а разбирает стек, чтобы добраться до IP-пакета: MPLS-метки он просматривает до конца стека, а сколько VLAN-тегов разбирать, задаёт параметр `vlan_mode` (VLAN Mode) в секции `nat_defaults` ([раздел 15.2.1](filter-interfaces.md)):
|
||||
|
||||
| Значение `vlan_mode` | Где фильтр ищет IP-пакет |
|
||||
| ------------------------- | -------------------------------------------------------------------------- |
|
||||
@@ -72,17 +72,17 @@
|
||||
В документации производителя описаны ещё две настройки этого этапа:
|
||||
|
||||
- `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)), её стоит проверить.
|
||||
- `pppoe_analyzer` — обработка трафика PPPoE (по умолчанию выключена). При установке ТСПУ до BRAS, где идёт PPPoE-трафик ([раздел 3.1.1](placement.md)), её стоит проверить.
|
||||
|
||||
У фильтра ограничений на типы инкапсуляции больше, чем у балансировщика ([раздел 4.7](04.md)): например, балансировщик разбирает до трёх VLAN-тегов, а фильтр — не больше двух. Кадр, в котором фильтр IP-пакет не нашёл, проходит через него прозрачно, без анализа.
|
||||
У фильтра ограничений на типы инкапсуляции больше, чем у балансировщика ([раздел 6.7](balancer.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)).
|
||||
Кадры без IP-пакета фильтр передаёт в парный порт на этой же проверке. За балансировщиком до фильтра доходят практически только keep-alive-пакеты балансировщика — прочие не-IP-кадры балансировщик пропускает сам, не отправляя на фильтры ([раздел 6.7](balancer.md)). Keep-alive возвращаются на балансировщик, который по времени их прохождения контролирует путь через фильтр ([раздел 6.6.1](balancer.md)). В схеме без балансировщика через фильтр прозрачно проходят и служебные кадры сети оператора — например, ARP или LACP, а heartbeat-кадры байпаса Silicom, подключённого к фильтру напрямую, тоже проходят в парный порт без обработки ([раздел 5.4](bypass.md)).
|
||||
|
||||
### 5.1.2. Проверка по ACL (привязка к пулу)
|
||||
### 10.1.2. Проверка по ACL (привязка к пулу)
|
||||
|
||||
Найденный IP-пакет фильтр проверяет на принадлежность к **пулу**. Пул — понятие из CGNAT: там он задаёт тип трансляции и набор внешних адресов, а привязанный к пулу **ACL** (Access Control List) определяет, какой трафик этот пул обслуживает. DPI обрабатывает только трафик, попавший в какой-либо пул, поэтому пул нужен и там, где адреса не транслируются. В ТСПУ используются пулы типа **fake**: трансляции в них нет — что пришло, то и ушло.
|
||||
|
||||
Минимальная рабочая настройка — включённый (`enable`) пул типа `fake` с привязанным ACL. Новый пул создаётся с типом `cgnat`, поэтому тип `fake` задаётся явно ([раздел 16](16.md)).
|
||||
Минимальная рабочая настройка — включённый (`enable`) пул типа `fake` с привязанным ACL. Новый пул создаётся с типом `cgnat`, поэтому тип `fake` задаётся явно ([раздел 16](filter-acl-pools.md)).
|
||||
|
||||
Правило ACL состоит из:
|
||||
|
||||
@@ -98,15 +98,15 @@
|
||||
- совпало правило `deny` — этот пул для пакета больше не рассматривается, проверяются следующие;
|
||||
- не совпало ни одно правило — тоже переход к следующему пулу.
|
||||
|
||||
Если подходящего пула не нашлось, пакет прозрачно уходит в парный порт. Назначать нескольким пулам одинаковый приоритет не следует: по документации производителя тогда будет задействован только один из них. IPv6-трафик отбирается собственными настройками пула: обработку IPv6 нужно включить, иначе сессии по IPv6 не заводятся и этот трафик проходит через фильтр прозрачно ([разделы 15.4](15.md) и [16.6](16.md)).
|
||||
Если подходящего пула не нашлось, пакет прозрачно уходит в парный порт. Назначать нескольким пулам одинаковый приоритет не следует: по документации производителя тогда будет задействован только один из них. IPv6-трафик отбирается собственными настройками пула: обработку IPv6 нужно включить, иначе сессии по IPv6 не заводятся и этот трафик проходит через фильтр прозрачно ([разделы 15.4](filter-interfaces.md) и [16.6](filter-acl-pools.md)).
|
||||
|
||||
Пул выбирается при создании сессии — по первому пакету потока; следующие пакеты фильтр находит в таблице сессий, и вся дальнейшая обработка ведётся в рамках сессий ([раздел 12](12.md)). Здесь фильтр может и отбросить пакет ещё до DPI: по умолчанию TCP-сессия заводится только по пакету с флагом SYN, а TCP-пакет без SYN, для которого сессии нет, отбрасывается. В ТСПУ такое поведение отключают параметром `permit_invalid_flow` ([раздел 5.2](#52-работа-на-уровне-l2-фильтр-как-прозрачный-провод)).
|
||||
Пул выбирается при создании сессии — по первому пакету потока; следующие пакеты фильтр находит в таблице сессий, и вся дальнейшая обработка ведётся в рамках сессий ([раздел 12](filter-sessions.md)). Здесь фильтр может и отбросить пакет ещё до DPI: по умолчанию TCP-сессия заводится только по пакету с флагом SYN, а TCP-пакет без SYN, для которого сессии нет, отбрасывается. В ТСПУ такое поведение отключают параметром `permit_invalid_flow` ([раздел 10.2](#102-работа-на-уровне-l2-фильтр-как-прозрачный-провод)).
|
||||
|
||||
> **Важно:** в заводской конфигурации фильтра пулов и ACL нет. Пока они не созданы, фильтр пропускает весь трафик прозрачно, какие бы DPI-листы ни были настроены. Признак такой ситуации — нулевая скорость создания сессий в `show cps` при идущем через фильтр трафике ([раздел 18.9](18.md)).
|
||||
> **Важно:** в заводской конфигурации фильтра пулов и ACL нет. Пока они не созданы, фильтр пропускает весь трафик прозрачно, какие бы DPI-листы ни были настроены. Признак такой ситуации — нулевая скорость создания сессий в `show cps` при идущем через фильтр трафике ([раздел 18.9](filter-monitoring.md)).
|
||||
|
||||
### 5.1.3. Проверка по DPI-листу (IP-подсети)
|
||||
### 10.1.3. Проверка по DPI-листу (IP-подсети)
|
||||
|
||||
Следующий этап — **DPI-листы**. DPI-лист объединяет настройки одной политики фильтрации: на какой трафик она распространяется, что в нём ищется (загружаемый список IP-адресов, доменов и URL, распознаваемые протоколы) и что делать при совпадении ([раздел 5.1.5](#515-решение-пропустить-или-заблокировать-drop)). Подробно настройки DPI-листов описаны в [разделе 17.4](17.md).
|
||||
Следующий этап — **DPI-листы**. DPI-лист объединяет настройки одной политики фильтрации: на какой трафик она распространяется, что в нём ищется (загружаемый список IP-адресов, доменов и URL, распознаваемые протоколы) и что делать при совпадении ([раздел 10.1.5](#1015-решение-пропустить-или-заблокировать-drop)). Подробно настройки DPI-листов описаны в [разделе 17.4](filter-dpi.md).
|
||||
|
||||
Набор листов задан прошивкой: это листы с номерами 0–16 — лист 0 и шестнадцать листов 1–16. Каждый лист включается и выключается независимо. В более поздних версиях ПО, по документации производителя, листы создаются по мере необходимости командой `create dpilist N` — в стандартной конфигурации с номерами 0–24, по запросу заказчика — до 1000.
|
||||
|
||||
@@ -119,17 +119,17 @@
|
||||
| `no_ip_remote` | удалённые адреса (серверов), исключённые из обработки листом |
|
||||
| `ipv6` / `no_ipv6` | то же для IPv6 |
|
||||
|
||||
Исключения проверяются первыми: адрес из `no_ip` листом не обрабатывается, даже если входит в `ip`. Штатно в `ip` задаётся сеть `0.0.0.0/0` для всех VLAN — тогда лист действует на весь трафик, дошедший до DPI. Добавить адрес абонента в `no_ip` — удобный способ диагностики: если у абонента после этого что-то изменилось (например, заработало приложение), этот лист на его трафик действительно влиял ([раздел 17.4.8](17.md)).
|
||||
Исключения проверяются первыми: адрес из `no_ip` листом не обрабатывается, даже если входит в `ip`. Штатно в `ip` задаётся сеть `0.0.0.0/0` для всех VLAN — тогда лист действует на весь трафик, дошедший до DPI. Добавить адрес абонента в `no_ip` — удобный способ диагностики: если у абонента после этого что-то изменилось (например, заработало приложение), этот лист на его трафик действительно влиял ([раздел 17.4.8](filter-dpi.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)).
|
||||
В ТСПУ фильтрация по реестру Роскомнадзора выполняется в листе 0. В ранних версиях ПО настройки реестра находятся прямо в листе 0; в более поздних они вынесены в отдельный раздел, лист для реестра выбирается параметром `list_number` (по умолчанию 0; в руководстве EcoSGE 3.1.8 значение по умолчанию не задано, и лист указывают явно), а все листы устроены одинаково ([раздел 17.2](filter-dpi.md)). Действие (`behaviour`) задаётся для листа целиком, а лист 0 блокирует по реестру, поэтому распознавание протоколов (`ignore`) и блокировку по очищенным спискам из ЦСУ (`block`, например в листе 5) настраивают в других листах ([раздел 22](protocol-blocking.md)).
|
||||
|
||||
### 5.1.4. Обработка движком DPI
|
||||
### 10.1.4. Обработка движком DPI
|
||||
|
||||
Трафик, прошедший предварительные проверки, анализирует **движок DPI**. Он сверяет трафик со списками фильтрации — IP-адресами, доменами и URL (для HTTP — по запрошенному URL, для HTTPS — по имени сервера в SNI, [раздел 17.5](17.md)) — и распознаёт протоколы и приложения.
|
||||
Трафик, прошедший предварительные проверки, анализирует **движок DPI**. Он сверяет трафик со списками фильтрации — IP-адресами, доменами и URL (для HTTP — по запрошенному URL, для HTTPS — по имени сервера в SNI, [раздел 17.5](filter-dpi.md)) — и распознаёт протоколы и приложения.
|
||||
|
||||
Распознавание — это **многофакторный анализ сессии**, а не отдельного пакета: движку нужно несколько пакетов сессии в обоих направлениях. Кроме очевидных полей — адресов и портов источника и назначения — учитывается не один десяток признаков, например:
|
||||
|
||||
@@ -137,11 +137,11 @@
|
||||
- частота прохождения пакетов;
|
||||
- частота появления тех или иных ключевых слов внутри пакетов.
|
||||
|
||||
У трафика, который шифруется и намеренно скрывает свою природу (протоколы мессенджеров, обфусцированные VPN), явных полей, указывающих на протокол, нет, поэтому он распознаётся по косвенным признакам. Такое распознавание **не стопроцентно**: другой шифрованный трафик может быть принят, например, за Telegram, и его блокировка задела бы полезные ресурсы. Поэтому для блокировки таких протоколов применяется двухэтапная схема: сначала фильтры только распознают трафик и отправляют логи, а блокируют уже по спискам, очищенным от ложных срабатываний в ЦСУ ([разделы 8](08.md) и [23](23.md)). Распознавание можно обойти — например, протоколом, который маскируется под другой. Если протокол в новой версии перестал распознаваться, нужна новая сигнатура ([раздел 23.4](23.md)).
|
||||
У трафика, который шифруется и намеренно скрывает свою природу (протоколы мессенджеров, обфусцированные VPN), явных полей, указывающих на протокол, нет, поэтому он распознаётся по косвенным признакам. Такое распознавание **не стопроцентно**: другой шифрованный трафик может быть принят, например, за Telegram, и его блокировка задела бы полезные ресурсы. Поэтому для блокировки таких протоколов применяется двухстадийная схема: сначала фильтры только распознают трафик и отправляют логи, а блокируют уже по спискам, очищенным от ложных срабатываний в ЦСУ ([раздел 22](protocol-blocking.md)). Распознавание можно обойти — например, протоколом, который маскируется под другой. Если протокол в новой версии перестал распознаваться, нужна новая сигнатура ([раздел 22.3](protocol-blocking.md)).
|
||||
|
||||
Модуль DPI можно выключить целиком — тогда весь трафик проходит через фильтр прозрачно, без анализа. Так проверяют, связана ли проблема абонента с обработкой на фильтре вообще ([раздел 17.1.1](17.md)).
|
||||
Модуль DPI можно выключить целиком — тогда весь трафик проходит через фильтр прозрачно, без анализа. Так проверяют, связана ли проблема абонента с обработкой на фильтре вообще ([раздел 17.1.1](filter-dpi.md)).
|
||||
|
||||
### 5.1.5. Решение: пропустить или заблокировать (drop)
|
||||
### 10.1.5. Решение: пропустить или заблокировать (drop)
|
||||
|
||||
По результату анализа фильтр решает судьбу пакета: в общем случае — пропустить его в парный порт или отбросить (drop), если трафик попадает под запрещающую политику. Что делать при срабатывании, задаёт параметр `behaviour` DPI-листа:
|
||||
|
||||
@@ -157,39 +157,39 @@
|
||||
**Блокировка (`block`)** — основной режим для реестра Роскомнадзора и для очищенных протокольных списков:
|
||||
|
||||
- **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)).
|
||||
- **HTTPS** — содержимое зашифровано, и подменить ответ нельзя: ресурс определяется по домену в SNI, а соединение разрывается пакетами TCP Reset. Блокируется домен целиком ([раздел 17.5.3](filter-dpi.md)). По документации производителя проверяется и сертификат сервера, если он передаётся открыто (до TLS 1.3), а соединение без SNI пропускается;
|
||||
- **трафик с MPLS-метками** — ответ абоненту фильтр сам сформировать не может: MPLS-путь однонаправлен, и стек меток обратного направления фильтру неизвестен. Поэтому запрос абонента пропускается к серверу, фильтр дожидается ответного пакета в той же сессии и подменяет его содержимое на перенаправление или TCP Reset, сохраняя метки ([раздел 6.8](balancer.md));
|
||||
- **протоколы, блокировка которых включена в DPI-листе** (указаны в `protocols` листа с `behaviour block`) — пакеты заблокированной сессии отбрасываются, TCP Reset при этом не отправляется (см. ниже про send RST). Вместо полной блокировки протокол можно «деградировать»: параметры деградации (protocols capacity) задают для протокола значение от 0 до 100 в условных единицах (это не проценты): 0 — полная блокировка, 100 — полный пропуск, промежуточные значения — сброс части пакетов сессии с вероятностью, зависящей от значения. Сама по себе настройка деградации — даже значение 0 — ничего не блокирует: она действует только на протоколы, блокировка которых включена в DPI-листе, и не затрагивает лист распознавания с `ignore` ([раздел 17.3](filter-dpi.md)).
|
||||
|
||||
**Распознавание (`ignore`)** — первая стадия двухэтапной блокировки: лист со списком распознаваемых протоколов срабатывает, но трафик не трогает, а логи о распознанных сессиях уходят на SPFS и далее в ЦСУ ([разделы 8](08.md) и [14.10](14.md)). ЦСУ отсеивает ложные срабатывания и загружает очищенные списки в **другой** DPI-лист — с `behaviour block`.
|
||||
**Распознавание (`ignore`)** — первая стадия двухстадийной блокировки: лист со списком распознаваемых протоколов срабатывает, но трафик не трогает, а логи о распознанных сессиях уходят на SPFS и далее в ЦСУ ([разделы 22](protocol-blocking.md) и [14.10](filter-subsystems.md)). ЦСУ отсеивает ложные срабатывания и загружает очищенные списки в **другой** DPI-лист — с `behaviour block`.
|
||||
|
||||
**Белый список.** Параметр `whitelist_mode` переключает лист из режима чёрного списка (по умолчанию: совпавшее блокируется, остальное пропускается) в режим белого: пропускается только совпавшее, всё остальное блокируется. В ТСПУ этот режим не используется — ошибка в таком листе может отрезать абонентам весь трафик; он нужен в других сценариях, например вместе с функциями BRAS.
|
||||
|
||||
**TCP Reset при блокировке протоколов (send RST).** Приложение (например, Telegram), получив TCP Reset в ответ на попытку соединения, тут же пытается соединиться снова — непрерывно и очень быстро, порождая огромное число сессий; наблюдались случаи, когда мобильные устройства абонентов из-за этого начинали тормозить. Поэтому отправку TCP Reset при блокировке протоколов можно отключить общим параметром модуля DPI send RST, и в ТСПУ он **всегда `off`**: попытка соединения просто отбрасывается, соединение висит и обрывается по тайм-ауту, и лавины новых сессий не возникает ([раздел 17.1.2](17.md)). В руководствах пользователя EcoSGE такого общего параметра нет; в более поздних версиях ПО блокировку без TCP Reset и без перенаправления задают для отдельного листа значением `behaviour drop`.
|
||||
**TCP Reset при блокировке протоколов (send RST).** Приложение (например, Telegram), получив TCP Reset в ответ на попытку соединения, тут же пытается соединиться снова — непрерывно и очень быстро, порождая огромное число сессий; наблюдались случаи, когда мобильные устройства абонентов из-за этого начинали тормозить. Поэтому отправку TCP Reset при блокировке протоколов можно отключить общим параметром модуля DPI send RST, и в ТСПУ он **всегда `off`**: попытка соединения просто отбрасывается, соединение висит и обрывается по тайм-ауту, и лавины новых сессий не возникает ([раздел 17.1.2](filter-dpi.md)). В руководствах пользователя EcoSGE такого общего параметра нет; в более поздних версиях ПО блокировку без TCP Reset и без перенаправления задают для отдельного листа значением `behaviour drop`.
|
||||
|
||||
## 5.2. Работа на уровне L2: фильтр как «прозрачный провод»
|
||||
## 10.2. Работа на уровне L2: фильтр как «прозрачный провод»
|
||||
|
||||
Хотя фильтр анализирует трафик вплоть до седьмого уровня модели OSI, в топологии сети он работает на **уровне L2**. Для оператора и его оборудования фильтр — **прозрачный провод**: кадры входят в один порт пары и выходят из парного, а изменения вносятся только в пакеты блокируемых сессий. Это обеспечивают несколько свойств и настроек; описание относится к подключению парами портов в ТСПУ тип А (о схеме on-a-stick — в [разделе 7.3.3](07.md)).
|
||||
Хотя фильтр анализирует трафик вплоть до седьмого уровня модели OSI, в топологии сети он работает на **уровне L2**. Для оператора и его оборудования фильтр — **прозрачный провод**: кадры входят в один порт пары и выходят из парного, а изменения вносятся только в пакеты блокируемых сессий. Это обеспечивают несколько свойств и настроек; описание относится к подключению парами портов в ТСПУ тип А (о схеме on-a-stick — в [разделе 4.3.3](echelon.md)).
|
||||
|
||||
**Нет L3-интерфейсов в тракте.** В ОС Linux, на которой построен фильтр, виден только management-интерфейс. Порты тракта, как и лог-интерфейсы, отданы под управление **DPDK** (Data Plane Development Kit) и процессу EcoNAT, который обрабатывает пакеты напрямую, минуя сетевой стек ОС. IP-адресов у портов тракта нет: ping и traceroute с фильтра выполняются только через management-интерфейс ([раздел 18.14](18.md)), а собственного трафика в тракт фильтр (при выключенном LLDP — см. ниже) не инициирует. Исключение — пакеты, которые он вставляет в блокируемые сессии: перенаправление и TCP Reset, адресованные участникам сессии.
|
||||
**Нет L3-интерфейсов в тракте.** В ОС Linux, на которой построен фильтр, виден только management-интерфейс. Порты тракта, как и лог-интерфейсы, отданы под управление **DPDK** (Data Plane Development Kit) и процессу EcoNAT, который обрабатывает пакеты напрямую, минуя сетевой стек ОС. IP-адресов у портов тракта нет: ping и traceroute с фильтра выполняются только через management-интерфейс ([раздел 18.14](filter-monitoring.md)), а собственного трафика в тракт фильтр (при выключенном LLDP — см. ниже) не инициирует. Исключение — пакеты, которые он вставляет в блокируемые сессии: перенаправление и TCP Reset, адресованные участникам сессии.
|
||||
|
||||
**Заголовки инкапсуляции сохраняются.** VLAN-теги, MPLS-метки и другие заголовки фильтр не снимает и не меняет: он разбирает их только для того, чтобы найти IP-пакет, и все манипуляции выполняет с IP-пакетом. Кадр выходит из фильтра с тем же стеком заголовков, с каким вошёл, — включая 4-байтный заголовок балансировщика.
|
||||
|
||||
**Пересылка включена.** Параметр `forward_traffic` в `nat_defaults` (по умолчанию `on`) разрешает пересылку кадров через фильтр; значение `off` нужно, только когда фильтр анализирует зеркалированный трафик и обратно от него ничего не ждут. В ТСПУ фильтр стоит в разрыв, поэтому `forward_traffic` всегда `on`, а режим работы модуля DPI (`functionality_mode`) — обычный, для схемы «в разрыв», а не для зеркалированного трафика ([разделы 15.2.3](15.md) и [17.1.3](17.md)).
|
||||
**Пересылка включена.** Параметр `forward_traffic` в `nat_defaults` (по умолчанию `on`) разрешает пересылку кадров через фильтр; значение `off` нужно, только когда фильтр анализирует зеркалированный трафик и обратно от него ничего не ждут. В ТСПУ фильтр стоит в разрыв, поэтому `forward_traffic` всегда `on`, а режим работы модуля DPI (`functionality_mode`) — обычный, для схемы «в разрыв», а не для зеркалированного трафика ([разделы 15.2.3](filter-interfaces.md) и [17.1.3](filter-dpi.md)).
|
||||
|
||||
**LLDP выключен.** По документации производителя LLDP на платформе по умолчанию включён: устройство периодически (в разных редакциях документации — раз в 30 или 60 секунд) рассылает LLDP-сообщения через все задействованные интерфейсы, и соседнее оборудование видит его в своей топологии. В ТСПУ LLDP выключают (`lldp off` в `nat_defaults`) по просьбе операторов связи: оборудование должно оставаться невидимым и не появляться на схемах их сети ([раздел 15.2.5](15.md)).
|
||||
**LLDP выключен.** По документации производителя LLDP на платформе по умолчанию включён: устройство периодически (в разных редакциях документации — раз в 30 или 60 секунд) рассылает LLDP-сообщения через все задействованные интерфейсы, и соседнее оборудование видит его в своей топологии. В ТСПУ LLDP выключают (`lldp off` в `nat_defaults`) по просьбе операторов связи: оборудование должно оставаться невидимым и не появляться на схемах их сети ([раздел 15.2.5](filter-interfaces.md)).
|
||||
|
||||
**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 — 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 портов балансировщика — это согласуют при проектировании ([раздел 6.5.3](balancer.md)).
|
||||
|
||||
**`permit_invalid_flow` включён.** По умолчанию параметр выключен: TCP-сессия заводится только по пакету с флагом SYN, а TCP-пакеты без SYN, для которых сессии нет, считаются ошибочными или вредоносными и отбрасываются. Для NAT-устройства это нормальное поведение, для фильтра — опасное: он часто видит TCP-сессии не с начала, а «с середины»:
|
||||
|
||||
- **после возврата ТСПУ из байпаса в рабочий режим** — из аппаратного байпаса в Inline или из программного байпаса балансировщика, в том числе отдельной пары портов ([разделы 3.5](03.md) и [4.6.2](04.md)), — а также при первом включении в тракт на фильтры сразу приходит трафик множества уже установленных сессий, SYN которых фильтр не видел. С выключенным параметром фильтр будет его дропать: все эти TCP-сессии абонентов оборвутся по тайм-ауту, и их придётся устанавливать заново;
|
||||
- **при перераспределении трафика** — когда балансировщик перебалансирует нагрузку и сессии переезжают на другой фильтр ([раздел 4.6.3](04.md)), а также после перезапуска фильтра, когда таблица сессий пуста;
|
||||
- **после возврата ТСПУ из байпаса в рабочий режим** — из аппаратного байпаса в Inline или из программного байпаса балансировщика, в том числе отдельной пары портов ([разделы 5.5](bypass.md) и [6.6.2](balancer.md)), — а также при первом включении в тракт на фильтры сразу приходит трафик множества уже установленных сессий, SYN которых фильтр не видел. С выключенным параметром фильтр будет его дропать: все эти TCP-сессии абонентов оборвутся по тайм-ауту, и их придётся устанавливать заново;
|
||||
- **при перераспределении трафика** — когда балансировщик перебалансирует нагрузку и сессии переезжают на другой фильтр ([раздел 6.6.3](balancer.md)), а также после перезапуска фильтра, когда таблица сессий пуста;
|
||||
- **при несимметричном трафике** — когда исходящий трафик сессии прошёл через одну площадку или один фильтр, а ответный — через другой: второй фильтр не видел SYN, с которого абонент начал соединение, и сессия там не заведётся;
|
||||
- **для долго молчащих TCP-соединений** (по документации производителя): когда сессия на фильтре удалена по тайм-ауту неактивности, следующий пакет соединения приходит уже без SYN.
|
||||
|
||||
Поэтому в ТСПУ параметр **всегда включён**: фильтр принимает пакеты «с середины» и заводит для них сессии. Параметр глобальный — действует на всё устройство и в пулах не переопределяется; изменение применяется командой `apply` ([раздел 15.2.6](15.md)).
|
||||
Поэтому в ТСПУ параметр **всегда включён**: фильтр принимает пакеты «с середины» и заводит для них сессии. Параметр глобальный — действует на всё устройство и в пулах не переопределяется; изменение применяется командой `apply` ([раздел 15.2.6](filter-interfaces.md)).
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 4: Балансировщик](04.md) · [Раздел 6: Места установки ТСПУ →](06.md)
|
||||
[← Оглавление](../README.md) · [← Раздел 9: Балансировщик: мониторинг и диагностика](balancer-monitoring.md) · [Раздел 11: Фильтр: аппаратная платформа →](filter-platform.md)
|
||||
|
||||
Reference in New Issue
Block a user