Max/DanielLavrushin_tspu-docs
1
0
Fork 0
mirror of https://github.com/DanielLavrushin/tspu-docs.git synced 2026-09-22 22:47:59 +03:00
Code Issues Packages Projects Releases Wiki Activity

Refactor chapter 2 for clarity and detail, enhancing explanations of traffic flow, encapsulation, and filtering processes

Browse Source
This commit is contained in:
Daniel Lavrushin
2026-09-04 09:52:45 +02:00
parent ca2af035a5
commit 3101ce52e8
1 changed files with 114 additions and 101 deletions
Download Patch File Download Diff File Expand all files Collapse all files
chapters/02.md
+114 -101
View File
@@ -3,12 +3,16 @@
[← Оглавление](../README.md) · [← Раздел 1: Введение и общая архитектура АСБИ](01.md)
---
Путь пакета через ТСПУ можно разбить на четыре участка: стык оператора связи (1), байпас (2), балансировщик (3) и фильтры (4). Ниже они рассмотрены по порядку — на упрощённой, но достаточной для понимания типовой схеме. Число байпасов на площадке определяется количеством разрываемых каналов оператора: каждый канал занимает на байпасе свою четвёрку портов Net0/Net1/Mon0/Mon1, а один байпас может обслуживать один или несколько каналов.
<img width="1024" alt="image" src="https://github.com/user-attachments/assets/2aa75f41-b661-4d74-b949-a46b78aa620a" />
_Типовая схема ТСПУ: 1 — стык оператора (N × 10/40/100GE), 2 — байпас, 3 — балансировщик, 4 — фильтры (M × 10GE); справа — сеть управления с VPN-шлюзом, SPFS (на схеме — СПФС) и СПХД._
## 2.1. Стык оператора связи: типы инкапсуляции
ТСПУ устанавливается в разрыв канала связи внутри сети оператора. На стыке, в который врезается ТСПУ, трафик представляет собой поток пакетов между оборудованием оператора — с одной стороны абоненты, с другой стороны интернет.
ТСПУ устанавливается в разрыв канала связи внутри сети оператора: связь между двумя устройствами оператора разрывается, и оба конца канала заводятся на байпас. На таком стыке трафик представляет собой поток пакетов между оборудованием оператора — с одной стороны абоненты (уровень distribution/access, BRAS, CGNAT и т. п.), с другой стороны интернет (маршрутизаторы P/PE).
Рассмотрим прохождение пакета с точки зрения абонента. У абонента есть **локальный IP-адрес** и **локальный порт** (local IP, local port). У интернет-ресурса, к которому обращается абонент, есть **удалённый IP-адрес** и **удалённый порт** (remote IP, remote port).
@@ -26,43 +30,47 @@
└─────────────────────────────────────────────┘
```
При обратном пакете (от ресурса к абоненту) source и destination меняются местами.
В обратном пакете (от ресурса к абоненту) source и destination меняются местами. Эта терминология (local/remote) используется далее во всей документации, в том числе при описании сессий на фильтре ([раздел 12](12.md)).
<img width="1024" alt="image" src="https://github.com/user-attachments/assets/d4b641db-783f-41de-b94b-3211ec2767a3" />
_Стык оператора: адреса и порты в прямом и обратном пакетах; внизу — структура кадра с полем дополнительной инкапсуляции («???») и примеры его содержимого (VLAN, VLAN+VLAN, VLAN+MPLS+MPLS и т. д.)._
### Инкапсуляция на стыке оператора
На стыке оператора связи пакет может иметь различную дополнительную инкапсуляцию. Это зависит от технологий, применяемых конкретным оператором, и от места в сети, куда устанавливается ТСПУ.
На стыке оператора связи пакет может иметь различную дополнительную инкапсуляцию. Она зависит от технологий, применяемых конкретным оператором, от места в сети, куда устанавливается ТСПУ ([раздел 6](06.md)), и от других факторов.
Общая структура кадра Ethernet с учётом возможных дополнительных заголовков:
```text
┌──────────┬─────────────────┬──────────────┬─────────┬──────┐
│ Ethernet │ Доп. заголовки │ IP-заголовок│ TCP/UDP │ Data │
│ заголовок│ (??? ) │ │ │ │
└──────────┴─────────────────┴──────────────┴─────────┴──────┘
┌──────────────────┬────────────────────────────────┬──────────────┬───────────┬──────┐
│ Ethernet │ Дополнительные заголовки │ IP-заголовок │ TCP/UDP │ Data │
│ (MAC-адреса, │ VLAN-теги (0…2), MPLS-метки │ (IPv4/IPv6) │ и другие │ │
│ EtherType) │ (0…N), PPPoE/PPP … │ │ L4 │ │
└──────────────────┴────────────────────────────────┴──────────────┴───────────┴──────┘
```
В поле дополнительных заголовков могут встречаться:
Формально VLAN-теги входят в Ethernet-заголовок (стоят между MAC-адресом источника и EtherType), а MPLS-метки и PPPoE-заголовок следуют за ним; для ТСПУ важно лишь то, что всё это находится **перед** IP-заголовком. В поле дополнительных заголовков могут встречаться:
| Тип инкапсуляции | Описание |
| -------------------- | ------------------------------------------------- |
| **Без инкапсуляции** | Чистый IP-пакет, дополнительных заголовков нет |
| **VLAN (802.1Q)** | Один VLAN-тег (тегированный пакет) |
| **QinQ (802.1ad)** | Два VLAN-тега (дважды тегированный пакет) |
| **MPLS** | Одна или несколько MPLS-меток |
| **MPLS + VLAN** | Комбинация MPLS-меток и VLAN-тегов |
| **PPPoE** | PPP-инкапсуляция (характерна для участка до BRAS) |
| **PPPoE + MPLS** | PPP внутри MPLS-туннеля |
| Тип инкапсуляции | Описание |
| ------------------------------ | -------------------------------------------------------------------------------------------------------------------- |
| **Без инкапсуляции** | Чистый IP-пакет, дополнительных заголовков нет |
| **VLAN (802.1Q)** | Один VLAN-тег (тегированный кадр) |
| **QinQ (802.1ad / Q-in-Q)** | Два VLAN-тега (дважды тегированный кадр); внешний тег может иметь TPID 0x88a8 (802.1ad) или 0x8100 |
| **MPLS** | Одна или несколько MPLS-меток |
| **VLAN + MPLS** | VLAN-тег(и), за ними стек MPLS-меток |
| **Ethernet поверх MPLS** | Внутри MPLS-меток — вложенный Ethernet-кадр со своими VLAN-тегами (псевдопровод EoMPLS, VPLS), и только затем IP |
| **PPPoE** | PPPoE-заголовок и PPP-заголовок перед IP; характерен для участка абонент → BRAS ([раздел 6.1](06.md)) |
| **PPPoE + MPLS** | PPPoE-кадр, в свою очередь упакованный в MPLS (например, перенос PPPoE до BRAS через псевдопровод) |
Вариантов инкапсуляции в операторских сетях очень много, и все они не могут быть перечислены исчерпывающим образом. Ключевой момент: **ТСПУ должен уметь разбираться со всеми этими заголовками**, чтобы добраться до IP-пакета и выполнить его анализ и обработку. Всё, что находится «поверх» IP-заголовка, прозрачно пропускается — никакие метки и теги ТСПУ не снимает и не модифицирует.
Вариантов инкапсуляции в операторских сетях очень много, и перечислить их исчерпывающе невозможно — на стыке может встретиться практически что угодно. Ключевой момент: **ТСПУ должен уметь разбирать все эти заголовки**, чтобы добраться до IP-пакета и выполнить его анализ и обработку. Все манипуляции выполняются только с IP-пакетом; заголовки инкапсуляции, стоящие перед ним (VLAN-теги, MPLS-метки, PPPoE), ни балансировщик, ни фильтр не снимают и не модифицируют — пакет возвращается оператору с тем же стеком заголовков, с которым пришёл. Служебный заголовок, который балансировщик добавляет для передачи пакета фильтру внутри ТСПУ, снимается до возврата пакета оператору (см. [2.4](#24-типовая-схема-тспу)). Если IP-пакета в стеке заголовков не обнаружено, такой трафик пропускается прозрачно и на фильтры не отправляется.
## 2.2. Разделение на LAN-порты и WAN-порты
Фундаментальный принцип организации портов на всех устройствах ТСПУ — разделение на **LAN** и **WAN**:
Фундаментальный принцип организации портов на всех устройствах ТСПУ — разделение на **LAN** и **WAN**. Термины используются условно, как обозначение стороны канала, а не типа сети:
- **LAN-порты** — порты, смотрящие в сторону **абонентов** (внутренняя сторона сети оператора);
- **WAN-порты** — порты, смотрящие в сторону **интернета** (внешняя сторона).
- **WAN-порты** — порты, смотрящие в сторону **интернета** (внешняя сторона — аплинки, пиринг).
```text
Абоненты Интернет
@@ -73,41 +81,40 @@
└──────────┘ └──────────┘
```
Эта идеология **прослеживается через всё оборудование ТСПУ** — от байпасов до балансировщиков и фильтров. Все порты на любом устройстве ТСПУ можно разделить на две группы: порты в сторону абонентов (LAN) и порты в сторону интернета (WAN).
Эта идеология **прослеживается через всё оборудование ТСПУ** — от байпасов до балансировщиков и фильтров. Все порты на любом устройстве ТСПУ можно разделить на две группы: порты в сторону абонентов (LAN) и порты в сторону интернета (WAN). Порты всегда работают **парами** LAN + WAN: на байпасе это Net0/Net1 и Mon0/Mon1, на балансировщике — линки и группы портов, на фильтре — пары соседних интерфейсов. Ни LAN-, ни WAN-порты не имеют IP-адресов и не участвуют в маршрутизации.
На **фильтрах** разделение реализовано жёстко: все **чётные** порты — LAN, все **нечётные** — WAN. На **балансировщиках** аналогичное разделение принято по договорённости при проектировании схем: чётные порты назначаются LAN-портами, нечётные — WAN-портами.
На **фильтрах** разделение реализовано жёстко: интерфейсы нумеруются с единицы и объединены в пары соседних номеров (te1/te2, te3/te4 …), в каждой паре **чётный** порт — LAN, **нечётный** — WAN ([раздел 11.5](11.md)). На **балансировщиках** жёсткой привязки нет, но такое же разделение принято по договорённости при проектировании схем: чётные порты назначаются LAN-портами, нечётные — WAN-портами, причём как для портов в сторону оператора, так и для портов в сторону фильтров. Для 10-гигабитных портов чётность определяется по второй цифре номера (например, p4-2 — LAN, p4-1 — WAN), для 100-гигабитных — по единственной цифре (p10 — LAN, p9 — WAN); подробнее — в [разделе 4.3](04.md).
Этот принцип является основой для корректной обработки трафика: пакет, вошедший через определённый LAN-порт, после обработки обязательно выходит через парный ему WAN-порт (и наоборот), что обеспечивает прозрачность ТСПУ для сети оператора.
Этот принцип является основой для корректной обработки трафика: пакет, вошедший через определённый LAN-порт, после обработки обязательно выходит через парный ему WAN-порт (и наоборот). Устройства ТСПУ не изучают MAC-адреса и не ведут таблиц коммутации — кадр всегда передаётся строго в парный порт, поэтому для оборудования оператора ТСПУ неотличим от отрезка кабеля.
## 2.3. Простейший вариант ТСПУ (один байпас, один фильтр)
В минимальной конфигурации ТСПУ может состоять всего из трёх компонентов:
В минимальной конфигурации (см. также [раздел 1.4](01.md)) ТСПУ состоит всего из трёх компонентов:
- **один байпас** — для одного-двух каналов связи оператора;
- **один фильтр** — для обработки всего проходящего трафика;
- **сегмент управления** — SPFS, СПХД, коммутатор, VPN-шлюз.
- **сегмент управления** — VPN-шлюз, коммутатор, серверы SPFS и СПХД.
```text
Оборудование Оборудование
оператора оператора
(LAN) (WAN)
│ │
│ ┌───────────┐ │
└────┤ Байпас ├────┘
└─────┬─────┘
│
┌─────┴─────┐
│ Фильтр │
└───────────┘
Оборудование оператора Оборудование оператора
(сторона абонентов, LAN) (сторона интернета, WAN)
│ │
┌────┴────────────────────────────────┴────┐
│ Net0 Байпас Net1│
│ Mon0 Mon1│
└────┬────────────────────────────────┬────┘
│ LAN │ WAN
┌────┴────────────────────────────────┴────┐
│ te2 (LAN) Фильтр te1 (WAN)│
└──────────────────────────────────────────┘
─────────────────────────────
Сегмент управления
(SPFS, СПХД, VPN)
───────────────────────────────────────────────────
Сегмент управления (VPN-шлюз, SPFS, СПХД)
```
В таком варианте **балансировщик не нужен**, поскольку весь трафик обрабатывается одним фильтром и распределение по нескольким фильтрам не требуется. Каналы от байпаса подключаются непосредственно к портам фильтра.
В таком варианте **балансировщик не нужен**, поскольку весь трафик обрабатывается одним фильтром и распределение по нескольким фильтрам не требуется. Порты байпаса Mon0 и Mon1 подключаются непосредственно к паре портов фильтра: Mon0 — к LAN-порту, Mon1 — к WAN-порту. Heartbeat-пакеты, которыми байпас проверяет канал до фильтра, в этой схеме доходят до фильтра; это не IP-пакеты, поэтому фильтр без обработки передаёт их в парный порт, и контур проверки замыкается.
Ограничение: могут быть подключены только каналы **1 Гбит/с** или **10 Гбит/с** Ethernet, поскольку фильтры текущего проекта не поддерживают интерфейсы 100 Гбит/с — только 1G и 10G в зависимости от конкретной модели.
Ограничения этой схемы: могут быть подключены только каналы **1 Гбит/с** или **10 Гбит/с** Ethernet, поскольку фильтры проекта (модели 2020/2040 и 4080/4120/4160 — [раздел 11](11.md)) не имеют интерфейсов 100 Гбит/с — только 1G и 10G в зависимости от конкретной модели; пропускная способность ограничена одним фильтром, а при его отказе байпас замыкает канал, и трафик проходит без анализа. По техническому описанию производителя 2024 года интерфейсы 100GE (2 × QSFP28) есть только у более поздней старшей модели EcoFilter 5200 (см. [указатель оборудования](../tspu-equipment/README.md)).
## 2.4. Типовая схема ТСПУ
@@ -116,108 +123,114 @@
### Общая схема прохождения трафика
```text
Оборудование оператора Оборудование оператора
(сторона абонентов, LAN) (сторона интернета, WAN)
│ │ │ │
│ Канал 1 │ │ Канал 1 │
┌────┴───────────┴───┐ ┌────┴───────────┴───┐
│ Байпас 1 │ │ Байпас 1 │
│ Net0 Net1│ │ Mon0 Mon1 │
└────┬───────────┬───┘ └────┬───────────┬───┘
│ │ │ │
┌────┴───────────┴───────────────────┴───────────┴───┐
│ Балансировщик │
│ │
│ ┌─────────┐ ┌──────────────┐ ┌─────────────┐ │
│ │ Фильтры │ │ Группа │ │ Программный │ │
│ │ (Flow │──►│ балансировки │──►│ заголовок │ │
│ │ rules) │ │ (хэш) │ │ (+4 байта) │ │
│ └─────────┘ └──────────────┘ └─────────────┘ │
└───┬────┬────┬──────────────────────┬────┬────┬─────┘
│ │ │ │ │ │
┌──┴──┐ │ ┌──┴──┐ ┌──┴──┐ │ ┌──┴──┐
│Ф-р 1│ │ │Ф-р 2│ │Ф-р 1│ │ │Ф-р 2│
│ LAN │ │ │ LAN │ ... │ WAN │ │ │ WAN │
└─────┘ │ └─────┘ └─────┘ │ └─────┘
│ │
┌──┴──┐ ┌──┴──┐
│Ф-р N│ │Ф-р N│
│ LAN │ │ WAN │
└─────┘ └─────┘
Оборудование оператора Оборудование оператора
(сторона абонентов, LAN) (сторона интернета, WAN)
│ Канал 1 │ Канал 1
┌──────┴──────────────── Байпас ─────────────────┴──────┐
│ Net0 Net1 │
│ Mon0 Mon1 │
└──────┬─────────────────────────────────────────┬──────┘
│ LAN │ WAN
┌──────┴─────────────── Балансировщик ───────────┴──────┐
│ Линк 1 = пара портов LAN + WAN в сторону оператора │
│ │
│ Правила (flow rules): служебный трафик ──► bypass ──► │ обратно в парный порт линка
│ │
│ Группа балансировки: hash(src IP, dst IP, IP proto) │
│ + 4-байтный служебный заголовок │
└──┬─────┬───────────┬─────┬───────────────┬─────┬──────┘
│ LAN │ WAN │ LAN │ WAN │ LAN │ WAN
┌──┴─────┴──┐ ┌──┴─────┴──┐ ┌──┴─────┴──┐
│ Фильтр 1 │ │ Фильтр 2 │ ... │ Фильтр N │
└───────────┘ └───────────┘ └───────────┘
```
Пакет от абонента входит в ТСПУ через порт Net0 байпаса, в режиме Inline передаётся с Mon0 на LAN-порт линка балансировщика, отправляется на LAN-порт одного из фильтров, после обработки возвращается с WAN-порта фильтра на балансировщик, который направляет его в WAN-порт того же линка, — и через Mon1 → Net1 байпаса пакет уходит в сторону интернета. Обратный пакет проходит тот же путь в зеркальном порядке. Операторские линки на балансировщике — как правило, 10G или 100G; порты в сторону фильтров — 10G.
### Этап 1: Байпас
Канал связи оператора физически разрывается и заводится на байпас. Байпас обеспечивает защиту канала: в случае аварии он замыкает линки напрямую, минуя остальное оборудование ТСПУ. В штатном режиме (Inline) байпас прозрачно пропускает трафик дальше — в сторону балансировщика.
Канал связи оператора физически разрывается и заводится на байпас: порты **Net0/Net1** смотрят в сторону оборудования оператора (LAN и WAN соответственно), порты **Mon0/Mon1** — в сторону балансировщика. В штатном режиме (Inline) байпас прозрачно пропускает трафик насквозь: Net0 → Mon0 в сторону балансировщика и Mon1 → Net1 обратно (и то же самое для другого направления). Байпас обеспечивает защиту канала: в случае аварии он замыкает линки напрямую, минуя остальное оборудование ТСПУ. У байпасов Silicom переключение между режимами Inline, TAP и Active Bypass для оператора безболезненно — теряются лишь пакеты, которые в момент переключения уже ушли в сторону балансировщика, но не успели вернуться (байпасы GL Sun пилотного проекта таких режимов не имеют и переключаются с флапом линка — [раздел 3.3](03.md)).
Байпас контролирует доступность канала до балансировщика служебными heartbeat-пакетами, которые отправляются из Mon0 и должны вернуться в Mon1 (и наоборот); до фильтров эти пакеты не доходят — балансировщик прозрачно заворачивает их обратно. Если heartbeat-пакеты перестают проходить, байпас автоматически переключает канал в режим TAP или Active Bypass.
<img width="1024" alt="image" src="https://github.com/user-attachments/assets/4879b23b-1602-4cce-90da-44840b7616ce" />
_Байпас: порты NET0/NET1 в сторону оператора, MON0/MON1 в сторону балансировщика, режимы passive/active bypass, TAP и Inline, контуры heartbeat MON0 → MON1 и MON1 → MON0 через балансировщик._
Подробнее о режимах работы байпаса — в [разделе 3](03.md).
### Этап 2: Балансировщик — фильтрация служебного трафика
### Этап 2: Балансировщик — линки и исключение служебного трафика
На входе в балансировщик порты объединяются в **линки** — логические пары LAN + WAN. Трафик, пришедший через конкретный LAN-порт, **обязательно возвращается** через парный ему WAN-порт (и наоборот). Это гарантирует, что ТСПУ не нарушает маршрутизацию оператора.
Все порты балансировщика делятся на две группы: порты, подключённые через байпасы к оборудованию оператора, и порты, к которым подключены фильтры; и те и другие организованы парами LAN/WAN. По умолчанию никакой конфигурации в балансировщике нет — номера и назначение портов выбираются при проектировании конкретного узла, поэтому номера портов в примерах условны.
Первым делом трафик проходит через **правила фильтрации** (flow rules) балансировщика. Здесь определяется, какой трафик следует отправить на анализ фильтрами, а какой — сразу вернуть обратно оператору (забайпасить). Байпасятся, как правило:
На входе в балансировщик порты в сторону оператора объединяются в **линки** — логические пары LAN + WAN. Пакет, вошедший в LAN-порт линка, после обработки всегда выходит через WAN-порт того же линка (и наоборот) и ни в какой другой порт попасть не может. Так ТСПУ не меняет прохождение пакетов по каналам оператора: пакет, отправленный оператором в конкретный канал, выходит из ТСПУ в продолжение того же канала, и трафик разных линков никогда не смешивается. Соблюдается также правило проектирования: все каналы одного агрегированного линка (LAG) оператора заводятся на один и тот же балансировщик — иначе прямое и обратное направления одной сессии, разнесённые оператором по разным каналам агрегата, могут попасть на разные балансировщики и, следовательно, на разные фильтры.
- служебные протоколы (например, BGP — TCP-порт 179);
К каждому линку привязаны **правила** (flow rules) балансировщика — они применяются в порядке приоритетов, и возможных действий два: отправить трафик в группу балансировки, то есть на фильтры, или прямо на входе вернуть его оператору через парный порт линка (действие bypass; не путать с устройством «байпас»). Возвращаются без анализа, как правило:
- протоколы маршрутизации и сигнализации (например, BGP — TCP-порт 179, OSPF, BFD);
- мультикаст-трафик;
- протоколы маршрутизации;
- служебный трафик оператора, выделенный, например, в отдельный VLAN;
- прочий трафик, который не нужно и нежелательно анализировать.
В принципе, с таким трафиком на фильтрах ничего плохого не произойдёт, но лучше его не трогать — это снижает нагрузку и исключает потенциальное влияние на служебные протоколы оператора.
С таким трафиком на фильтрах ничего плохого произойти не должно, но лучше его не трогать: анализировать его бессмысленно, а служебные протоколы чувствительны к задержкам и потерям. Условия правил могут включать VLAN-теги, количество MPLS-меток, IP-адреса, L4-порты и MAC-адреса: например, если известно, что в VLAN 1 идёт служебный трафик оператора, его можно вернуть оператору целиком. Отбор по MPLS-меткам технически возможен, но практического смысла не имеет. Сами теги и метки балансировщик при этом не снимает: на фильтр пакет уходит с тем же набором меток. Настройка правил описана в [разделе 21.7](21.md).
<img width="1024" alt="image" src="https://github.com/user-attachments/assets/e1640f7b-7bfa-4e79-abc5-0bc126f66b3a" />
_Логика балансировщика: порты в сторону оператора (сверху, 10G и 100G, чётные — LAN, нечётные — WAN) объединены в линки; правила (flow 1, 2 …) либо возвращают трафик (bypass), либо передают его в группу балансировки, где по хэшу (src ip, dst ip, ip proto) с добавлением 4-байтного заголовка пакет уходит в одну из групп портов (group 1 … M) в сторону фильтров._
### Этап 3: Балансировщик — распределение по фильтрам
Трафик, не попавший под правила байпаса, отправляется в **группу балансировки**. В этой группе подключены все фильтры площадки. Балансировщик распределяет пакеты по фильтрам на основе **хэш-суммы**, вычисляемой по трём параметрам:
Трафик, не возвращённый правилами оператору, отправляется в **группу балансировки** — набор пар портов (LAN + WAN) в сторону фильтров. В типовой схеме одна группа объединяет все фильтры, подключённые к данному балансировщику, но в общем случае групп балансировки может быть несколько, и правило указывает, в какую из них направить трафик. Балансировщик распределяет пакеты по парам портов на основе **хэш-суммы**, вычисляемой по трём параметрам IP-пакета:
1. **Source IP** (адрес источника)
2. **Destination IP** (адрес назначения)
3. **IP-протокол** (TCP, UDP и т.д.)
3. **IP-протокол** (TCP, UDP и т. д.)
К хэшу также добавляется **количество ядер фильтров**, чтобы пакет не просто попал на конкретный фильтр, но и был распределён на конкретное ядро для обработки.
Балансировщик разбирает стек заголовков (VLAN, MPLS и т. д.) и вычисляет хэш именно от IP-пакета, найденного под инкапсуляцией. Если IP-пакета в стеке нет, трафик пропускается прозрачно и на фильтры не отправляется.
Для передачи информации о балансировке к пакету добавляется **дополнительный 4-байтовый заголовок** (по структуре похож на VLAN-тег, но таковым не является). Этот заголовок сообщает фильтру, на какое ядро направить пакет. После обработки фильтр возвращает пакет с тем же 4-байтовым заголовком, по которому балансировщик определяет, в какой именно операторский линк нужно вернуть пакет.
При вычислении хэша учитывается также число обрабатывающих ядер фильтра (все ядра процессора, кроме одного сервисного, — параметр N_UNIT_QA), поэтому результат однозначно определяет не только пару портов, но и конкретное **ядро фильтра**, которое будет обрабатывать пакет, — трафик сразу равномерно распределяется по всем ядрам ([раздел 4.5.2](04.md), [21.5.2](21.md)). Балансировка выполняется аппаратно, программируемым чипом, и не логируется: узнать, на какой фильтр попала конкретная сессия, можно только поиском на фильтрах ([раздел 24.2](24.md)).
**Симметричность хэша** — ключевое свойство балансировки. При вычислении хэша для обратного пакета (от интернета к абоненту) source и destination меняются местами, но итоговая хэш-сумма совпадает. Благодаря этому:
Для передачи информации о балансировке к пакету добавляется **дополнительный 4-байтовый заголовок** (по структуре похож на VLAN-тег, но таковым не является). Этот заголовок сообщает фильтру, на какое ядро направить пакет. После обработки фильтр возвращает пакет с тем же 4-байтовым заголовком, по нему балансировщик определяет, в какой именно операторский линк вернуть пакет, и снимает заголовок перед отправкой оператору. Так достигается корректное прохождение трафика: пакет, пришедший из конкретного порта оператора, возвращается в тот же порт независимо от того, каким фильтром он был обработан.
**Симметричность хэша** — ключевое свойство балансировки. Для обратного пакета (от интернета к абоненту) source и destination меняются местами, но адреса комбинируются так, что итоговая хэш-сумма совпадает. Благодаря этому:
- оба направления одной сессии **всегда попадают на один и тот же фильтр**;
- более того — на одно и то же **ядро** этого фильтра;
- сессия никогда не распределяется по разным фильтрам, что позволяет корректно собирать и анализировать её на одном устройстве.
- более того — на одну и ту же пару портов и на одно и то же **ядро** этого фильтра;
- сессия никогда не распределяется по разным фильтрам, поэтому её всегда можно собрать и проанализировать на одном устройстве.
Распределение детерминировано, пока состав группы не меняется; при включённой перебалансировке после отказа группы портов хэш пересчитывается, и часть сессий переезжает на другие фильтры ([раздел 4.6.3](04.md)). Обратная сторона принципа: одна сессия не может быть разбалансирована. Если, например, 200 Гбит/с трафика идут с одного адреса источника на один адрес назначения по одному протоколу, весь этот поток попадёт на один порт одного фильтра и даже на одно его ядро. Равномерная балансировка опирается на то, что в операторском трафике огромное количество разных сессий.
Отказоустойчивость на этом участке обеспечивает сам балансировщик — это второй, независимый от heartbeat байпаса (этап 1) контур контроля: в каждую пару портов в сторону фильтра он отправляет keep-alive-пакеты (через LAN-порт, с возвратом через WAN-порт), и если они перестают проходить — порт фильтра или сам фильтр перестал обрабатывать трафик, — трафик этой группы портов программно байпасится, то есть возвращается оператору без обработки, либо, в зависимости от настроек, перебалансируется на рабочие группы. В проекте перебалансировка отключена, и на время недоступности группы её трафик проходит без анализа. Подробнее — в [разделе 4.6](04.md).
### Этап 4: Обработка на фильтре
Пакет, попавший на фильтр, проходит через цепочку проверок:
Пакет, попавший на LAN-порт фильтра, проходит через цепочку проверок:
1. **Проверка: IP-пакет или нет.** После разбора инкапсуляции фильтр проверяет, есть ли внутри IPv4- или IPv6-пакет. Не-IP кадры без какой-либо обработки выводятся в парный порт; в типовой схеме до фильтра из не-IP трафика доходят практически только keep-alive-пакеты балансировщика, которые таким образом возвращаются балансировщику.
1. **Проверка: IP-пакет или нет.** Если пакет не является IP-пакетом (например, служебный keep-alive от балансировщика), он прозрачно пропускается через парный порт обратно в сеть оператора.
2. **Проверка по ACL.** ACL на фильтре задают, какой трафик подлежит анализу, и привязаны к пулу — логической сущности, в которую попадает отобранный трафик для дальнейшей обработки ([раздел 16](16.md)). Пакет, не попавший ни в один ACL, анализу не подлежит и прозрачно передаётся в парный порт.
2. **Проверка по ACL.** На фильтре настроены списки контроля доступа (ACL), привязанные к пулам. Если пакет не попадает ни в один ACL — он прозрачно пропускается.
3. **Проверка по DPI-листу.** В DPI-листе указаны IP-подсети и адреса, подлежащие проверке ([раздел 17.4](17.md)). Если IP-адреса пакета не попадают в обработку DPI-листа — пакет прозрачно пропускается.
3. **Проверка по DPI-листу.** В DPI-листе указаны IP-подсети и адреса, подлежащие проверке. Если IP-адреса пакета не попадают в обработку DPI-листа — пакет прозрачно пропускается.
4. **Обработка движком DPI.** Только пакеты, прошедшие все предыдущие проверки, попадают на анализ DPI-движком. По результатам анализа принимается решение: пропустить пакет (pass) либо отбросить (drop), если он попадает под запрещающие политики; при блокировке ресурса абоненту дополнительно отправляется HTTP-редирект (для HTTP) или TCP Reset (для HTTPS) ([раздел 17.4.4](17.md); особенности для трафика с MPLS — см. ниже).
4. **Обработка движком DPI.** Только пакеты, прошедшие все предыдущие проверки, попадают на анализ DPI-движком. По результатам анализа принимается решение: пропустить пакет или заблокировать (drop).
Глубина разбора инкапсуляции на фильтре задаётся настройкой (параметр VLAN Mode, в проекте всегда QinQ — [раздел 15.2.1](15.md)); ограничения фильтра по типам инкапсуляции несколько строже, чем у балансировщика.
Фильтр работает на уровне **L2** — он не изменяет Ethernet-кадр и не участвует в маршрутизации. С точки зрения сети оператора, фильтр представляет собой **«прозрачный провод»**: все заголовки инкапсуляции (VLAN-теги, MPLS-метки и т.д.) проходят через фильтр без изменений. Фильтр разбирает стек заголовков только для того, чтобы добраться до IP-пакета и выполнить анализ, после чего пакет (в случае пропуска) передаётся дальше в неизменном виде.
Фильтр работает на уровне **L2**: в тракте передачи трафика у него нет L3-интерфейсов, он не является ни маршрутизатором, ни коммутатором и всегда передаёт кадр строго в парный порт. С точки зрения сети оператора фильтр представляет собой **«прозрачный провод»**: все заголовки инкапсуляции (VLAN-теги, MPLS-метки и т. д.) проходят через фильтр без изменений. Фильтр разбирает стек заголовков только для того, чтобы добраться до IP-пакета и выполнить анализ; пропускаемый трафик покидает фильтр в неизменном виде, изменения вносятся только в пакеты блокируемых сессий (drop, подмена на HTTP-редирект или TCP Reset).
Все проверки, включая самую первую («IP-пакет или нет»), выполняются процессором фильтра. Поэтому если фильтр перегружен или «завис», не проходят даже keep-alive-пакеты балансировщика — и балансировщик переводит трафик этой группы портов в программный байпас.
<img width="1024" alt="image" src="https://github.com/user-attachments/assets/350122b7-0550-4b28-8dc5-acb2bf06319e" />
_Путь пакета через фильтр: вход через LAN-порт (te2), проверки «IP-пакет?», «попадает в pool/ACL?», «попадает в обработку DPI?», затем DPI с решением pass/drop; выход через парный WAN-порт (te1)._
Подробнее путь пакета через фильтр описан в [разделе 5](05.md).
### Особенность: HTTP-редирект и TCP Reset при наличии MPLS
Особый случай возникает, когда фильтру нужно отправить абоненту **HTTP-редирект** (код 302, перенаправление на страницу-заглушку) или **TCP Reset** при блокировке HTTPS-ресурса.
Особый случай — блокировка трафика с MPLS-метками, когда фильтру нужно отправить абоненту **HTTP-редирект** (код 302, перенаправление на страницу-заглушку) при блокировке HTTP-ресурса или **TCP Reset** при блокировке HTTPS-ресурса ([раздел 17.4](17.md)). Фильтр не может просто сформировать такой пакет сам: MPLS-путь однонаправлен, и метки, с которыми пришёл пакет абонента, действительны только для направления в сторону интернета — стек меток обратного направления фильтру неизвестен.
Фильтр не может просто сгенерировать ответный пакет, поскольку канал между балансировщиком и фильтром **однонаправленный** с точки зрения сессии — пакет от абонента приходит через LAN-порт, и ответ должен уйти абоненту с корректными заголовками инкапсуляции (в том числе MPLS-метками), которые фильтр сам сгенерировать не может.
Поэтому используется следующая логика:
1. Пакет от абонента в сторону интернет-ресурса **пропускается** как есть;
2. Фильтр **ожидает обратный пакет** от интернет-ресурса в рамках той же сессии;
3. Когда обратный пакет приходит (уже с корректными заголовками, включая нужные MPLS-метки), фильтр **подменяет** содержимое этого пакета на HTTP-редирект или TCP Reset;
4. Модифицированный пакет отправляется абоненту с сохранением всей инкапсуляции.
Таким образом, пакет доставляется абоненту с корректными сетевыми заголовками, и HTTP-редирект или разрыв соединения срабатывает штатно.
Поэтому для трафика с 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).
---