mirror of
https://github.com/DanielLavrushin/tspu-docs.git
synced 2026-09-29 10:17:58 +03:00
238 lines
42 KiB
Markdown
238 lines
42 KiB
Markdown
# 2. Прохождение трафика через ТСПУ
|
||
|
||
[← Оглавление](../README.md) · [← Раздел 1: Введение и общая архитектура АСБИ](overview.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).
|
||
|
||
```text
|
||
Абонент → Интернет:
|
||
┌─────────────────────────────────────────────┐
|
||
│ Source: local IP : local port │
|
||
│ Destination: remote IP : remote port │
|
||
└─────────────────────────────────────────────┘
|
||
|
||
Интернет → Абонент:
|
||
┌─────────────────────────────────────────────┐
|
||
│ Source: remote IP : remote port │
|
||
│ Destination: local IP : local port │
|
||
└─────────────────────────────────────────────┘
|
||
```
|
||
|
||
В обратном пакете (от ресурса к абоненту) source и destination меняются местами. Эта терминология (local/remote) используется далее во всей документации, в том числе при описании сессий на фильтре ([раздел 12](filter-sessions.md)).
|
||
|
||
<img width="1024" alt="image" src="https://github.com/user-attachments/assets/d4b641db-783f-41de-b94b-3211ec2767a3" />
|
||
|
||
_Стык оператора: адреса и порты в прямом и обратном пакетах; внизу — структура кадра с полем дополнительной инкапсуляции («???») и примеры его содержимого (VLAN, VLAN+VLAN, VLAN+MPLS+MPLS и т. д.)._
|
||
|
||
### Инкапсуляция на стыке оператора
|
||
|
||
На стыке оператора связи пакет может иметь различную дополнительную инкапсуляцию. Она зависит от технологий, применяемых конкретным оператором, от места в сети, куда устанавливается ТСПУ ([раздел 3](placement.md)), и от других факторов.
|
||
|
||
Общая структура кадра Ethernet с учётом возможных дополнительных заголовков:
|
||
|
||
```text
|
||
┌──────────────────┬────────────────────────────────┬──────────────┬───────────┬──────┐
|
||
│ 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 / 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 ([раздел 3.1.1](placement.md)) |
|
||
| **PPPoE + MPLS** | PPPoE-кадр, в свою очередь упакованный в MPLS (например, перенос PPPoE до BRAS через псевдопровод) |
|
||
|
||
Вариантов инкапсуляции в операторских сетях очень много, и перечислить их исчерпывающе невозможно — на стыке может встретиться практически что угодно. Ключевой момент: **ТСПУ должен уметь разбирать все эти заголовки**, чтобы добраться до IP-пакета и выполнить его анализ и обработку. Все манипуляции выполняются только с IP-пакетом; заголовки инкапсуляции, стоящие перед ним (VLAN-теги, MPLS-метки, PPPoE), ни балансировщик, ни фильтр не снимают и не модифицируют — пакет возвращается оператору с тем же стеком заголовков, с которым пришёл. Служебный заголовок, который балансировщик добавляет для передачи пакета фильтру внутри ТСПУ, снимается до возврата пакета оператору (см. [2.4](#24-типовая-схема-тспу)). Если IP-пакета в стеке заголовков не обнаружено, такой трафик пропускается прозрачно и на фильтры не отправляется.
|
||
|
||
## 2.2. Разделение на LAN-порты и WAN-порты
|
||
|
||
Фундаментальный принцип организации портов на всех устройствах ТСПУ — разделение на **LAN** и **WAN**. Термины используются условно, как обозначение стороны канала, а не типа сети:
|
||
|
||
- **LAN-порты** — порты, смотрящие в сторону **абонентов** (внутренняя сторона сети оператора);
|
||
- **WAN-порты** — порты, смотрящие в сторону **интернета** (внешняя сторона — аплинки, пиринг).
|
||
|
||
```text
|
||
Абоненты Интернет
|
||
│ │
|
||
▼ ▼
|
||
┌──────────┐ ┌──────────┐
|
||
│ LAN-порт │ ◄── ТСПУ ──► │ WAN-порт │
|
||
└──────────┘ └──────────┘
|
||
```
|
||
|
||
Эта идеология **прослеживается через всё оборудование ТСПУ** — от байпасов до балансировщиков и фильтров. Все порты на любом устройстве ТСПУ можно разделить на две группы: порты в сторону абонентов (LAN) и порты в сторону интернета (WAN). Порты всегда работают **парами** LAN + WAN: на байпасе это Net0/Net1 и Mon0/Mon1, на балансировщике — линки и группы портов, на фильтре — пары соседних интерфейсов. Ни LAN-, ни WAN-порты не имеют IP-адресов и не участвуют в маршрутизации.
|
||
|
||
На **фильтрах** разделение реализовано жёстко: интерфейсы нумеруются с единицы и объединены в пары соседних номеров (te1/te2, te3/te4 …), в каждой паре **чётный** порт — LAN, **нечётный** — WAN ([раздел 11.5](filter-platform.md)). На **балансировщиках** жёсткой привязки нет, но такое же разделение принято по договорённости при проектировании схем: чётные порты назначаются LAN-портами, нечётные — WAN-портами, причём как для портов в сторону оператора, так и для портов в сторону фильтров. Для 10-гигабитных портов чётность определяется по второй цифре номера (например, p4-2 — LAN, p4-1 — WAN), для 100-гигабитных — по единственной цифре (p10 — LAN, p9 — WAN); подробнее — в [разделе 6.3](balancer.md).
|
||
|
||
Этот принцип является основой для корректной обработки трафика: пакет, вошедший через определённый LAN-порт, после обработки обязательно выходит через парный ему WAN-порт (и наоборот). Устройства ТСПУ не изучают MAC-адреса и не ведут таблиц коммутации — кадр всегда передаётся строго в парный порт, поэтому для оборудования оператора ТСПУ неотличим от отрезка кабеля.
|
||
|
||
## 2.3. Простейший вариант ТСПУ (один байпас, один фильтр)
|
||
|
||
В минимальной конфигурации (см. также [раздел 1.4](overview.md)) ТСПУ состоит всего из трёх компонентов:
|
||
|
||
- **один байпас** — для одного-двух каналов связи оператора;
|
||
- **один фильтр** — для обработки всего проходящего трафика;
|
||
- **сегмент управления** — VPN-шлюз, коммутатор, серверы SPFS и СПХД.
|
||
|
||
```text
|
||
Оборудование оператора Оборудование оператора
|
||
(сторона абонентов, LAN) (сторона интернета, WAN)
|
||
│ │
|
||
┌────┴────────────────────────────────┴────┐
|
||
│ Net0 Байпас Net1│
|
||
│ Mon0 Mon1│
|
||
└────┬────────────────────────────────┬────┘
|
||
│ LAN │ WAN
|
||
┌────┴────────────────────────────────┴────┐
|
||
│ te2 (LAN) Фильтр te1 (WAN)│
|
||
└──────────────────────────────────────────┘
|
||
|
||
───────────────────────────────────────────────────
|
||
Сегмент управления (VPN-шлюз, SPFS, СПХД)
|
||
```
|
||
|
||
В таком варианте **балансировщик не нужен**, поскольку весь трафик обрабатывается одним фильтром и распределение по нескольким фильтрам не требуется. Порты байпаса Mon0 и Mon1 подключаются непосредственно к паре портов фильтра: Mon0 — к LAN-порту, Mon1 — к WAN-порту. Heartbeat-пакеты, которыми байпас проверяет канал до фильтра, в этой схеме доходят до фильтра; это служебные кадры, которые фильтр без обработки передаёт в парный порт, и контур проверки замыкается.
|
||
|
||
Ограничения этой схемы: могут быть подключены только каналы **1 Гбит/с** или **10 Гбит/с** Ethernet, поскольку фильтры проекта (модели 2020/2040 и 4080/4120/4160 — [раздел 11](filter-platform.md)) не имеют интерфейсов 100 Гбит/с — только 1G и 10G в зависимости от конкретной модели; пропускная способность ограничена одним фильтром, а при его отказе байпас замыкает канал, и трафик проходит без анализа. По техническому описанию производителя 2024 года интерфейсы 100GE (2 × QSFP28) есть только у более поздней старшей модели EcoFilter 5200 (см. [указатель оборудования](../tspu-equipment/README.md)).
|
||
|
||
## 2.4. Типовая схема ТСПУ
|
||
|
||
В типовой конфигурации присутствуют все компоненты системы: байпасы, балансировщики и фильтры. Рассмотрим полный путь пакета через ТСПУ.
|
||
|
||
### Общая схема прохождения трафика
|
||
|
||
```text
|
||
Оборудование оператора Оборудование оператора
|
||
(сторона абонентов, 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: Байпас
|
||
|
||
Канал связи оператора физически разрывается и заводится на байпас: порты **Net0/Net1** смотрят в сторону оборудования оператора (LAN и WAN соответственно), порты **Mon0/Mon1** — в сторону балансировщика. В штатном режиме (Inline) байпас прозрачно пропускает трафик насквозь: Net0 → Mon0 в сторону балансировщика и Mon1 → Net1 обратно (и то же самое для другого направления). Байпас обеспечивает защиту канала: при потере heartbeat-контроля до балансировщика, при пропадании линков Mon или при обесточивании он замыкает линки напрямую, минуя остальное оборудование ТСПУ. У байпасов Silicom переключение между режимами Inline, TAP и Active Bypass для оператора безболезненно — теряются лишь пакеты, которые в момент переключения уже ушли в сторону балансировщика, но не успели вернуться (байпасы GL Sun пилотного проекта таких режимов не имеют и переключаются с флапом линка — [раздел 5.3](bypass.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 через балансировщик._
|
||
|
||
Подробнее о режимах работы байпаса — в [разделе 5](bypass.md).
|
||
|
||
### Этап 2: Балансировщик — линки и исключение служебного трафика
|
||
|
||
Все порты балансировщика делятся на две группы: порты, подключённые через байпасы к оборудованию оператора, и порты, к которым подключены фильтры; и те и другие организованы парами LAN/WAN. По умолчанию никакой конфигурации в балансировщике нет — номера и назначение портов выбираются при проектировании конкретного узла, поэтому номера портов в примерах условны.
|
||
|
||
На входе в балансировщик порты в сторону оператора объединяются в **линки** — логические пары LAN + WAN. Пакет, вошедший в LAN-порт линка, после обработки всегда выходит через WAN-порт того же линка (и наоборот) и ни в какой другой порт попасть не может. Так ТСПУ не меняет прохождение пакетов по каналам оператора: пакет, отправленный оператором в конкретный канал, выходит из ТСПУ в продолжение того же канала, и трафик разных линков никогда не смешивается. Соблюдается также правило проектирования: все каналы одного агрегированного линка (LAG) оператора заводятся на один и тот же балансировщик — иначе прямое и обратное направления одной сессии, разнесённые оператором по разным каналам агрегата, могут попасть на разные балансировщики и, следовательно, на разные фильтры ([раздел 6.3.3](balancer.md)).
|
||
|
||
К каждому линку привязаны **правила** (flow rules) балансировщика — они применяются в порядке приоритетов, и возможных действий два: отправить трафик в группу балансировки, то есть на фильтры, или прямо на входе вернуть его оператору через парный порт линка (действие bypass; не путать с устройством «байпас»). Возвращаются без анализа, как правило:
|
||
|
||
- протоколы маршрутизации и сигнализации (например, BGP — TCP-порт 179, OSPF, BFD);
|
||
- мультикаст-трафик;
|
||
- служебный трафик оператора, выделенный, например, в отдельный VLAN;
|
||
- прочий трафик, который не нужно и нежелательно анализировать.
|
||
|
||
С таким трафиком на фильтрах ничего плохого произойти не должно, но лучше его не трогать: анализировать его бессмысленно, а служебные протоколы чувствительны к задержкам и потерям. Условия правил могут включать VLAN-теги, количество MPLS-меток, IP-адреса, L4-порты и MAC-адреса: например, если известно, что в VLAN 1 идёт служебный трафик оператора, его можно вернуть оператору целиком. Отбор по MPLS-меткам технически возможен, но практического смысла не имеет. Сами теги и метки балансировщик при этом не снимает: на фильтр пакет уходит с тем же набором меток. Настройка правил описана в [разделе 8.7](balancer-config.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 и т. д.)
|
||
|
||
Балансировщик разбирает стек заголовков (VLAN, MPLS и т. д.) и вычисляет хэш именно от IP-пакета, найденного под инкапсуляцией. Если IP-пакета в стеке нет, трафик пропускается прозрачно и на фильтры не отправляется.
|
||
|
||
При вычислении хэша учитывается также число обрабатывающих ядер фильтра (все ядра процессора, кроме одного сервисного, — параметр `nat-unit-queues`), поэтому результат однозначно определяет не только пару портов, но и конкретное **ядро фильтра**, которое будет обрабатывать пакет, — трафик сразу равномерно распределяется по всем ядрам ([раздел 6.5.2](balancer.md), [8.5.2](balancer-config.md)). Балансировка выполняется аппаратно, программируемым чипом, и не логируется: узнать, на какой фильтр попала конкретная сессия, можно только поиском на фильтрах ([раздел 23.2](troubleshooting.md)).
|
||
|
||
Для передачи информации о балансировке к пакету добавляется **дополнительный 4-байтовый заголовок** (по структуре похож на VLAN-тег, но таковым не является). Этот заголовок сообщает фильтру, на какое ядро направить пакет. После обработки фильтр возвращает пакет с тем же 4-байтовым заголовком, по нему балансировщик определяет, в какой именно операторский линк вернуть пакет, и снимает заголовок перед отправкой оператору. Так достигается корректное прохождение трафика: пакет, пришедший из конкретного порта оператора, возвращается в тот же порт независимо от того, каким фильтром он был обработан.
|
||
|
||
**Симметричность хэша** — ключевое свойство балансировки. Для обратного пакета (от интернета к абоненту) source и destination меняются местами, но адреса комбинируются так, что итоговая хэш-сумма совпадает. Благодаря этому:
|
||
|
||
- оба направления одной сессии **всегда попадают на один и тот же фильтр**;
|
||
- более того — на одну и ту же пару портов и на одно и то же **ядро** этого фильтра;
|
||
- сессия никогда не распределяется по разным фильтрам, поэтому её всегда можно собрать и проанализировать на одном устройстве.
|
||
|
||
Распределение детерминировано, пока состав группы не меняется; при включённой перебалансировке после отказа группы портов хэш пересчитывается, и часть сессий переезжает на другие фильтры ([раздел 6.6.3](balancer.md)). Обратная сторона принципа: одна сессия не может быть разбалансирована. Если, например, 200 Гбит/с трафика идут с одного адреса источника на один адрес назначения по одному протоколу, весь этот поток попадёт на один порт одного фильтра и даже на одно его ядро. Равномерная балансировка опирается на то, что в операторском трафике огромное количество разных сессий.
|
||
|
||
Отказоустойчивость на этом участке обеспечивает сам балансировщик — это второй, независимый от heartbeat байпаса (этап 1) контур контроля: в каждую пару портов в сторону фильтра он отправляет keep-alive-пакеты (через LAN-порт, с возвратом через WAN-порт), и если они перестают проходить — порт фильтра или сам фильтр перестал обрабатывать трафик, — трафик этой группы портов программно байпасится, то есть возвращается оператору без обработки, либо, в зависимости от настроек, перебалансируется на рабочие группы. В проекте перебалансировку предполагается отключить — тогда на время недоступности группы её трафик проходит без анализа. Подробнее — в [разделе 6.6](balancer.md).
|
||
|
||
### Этап 4: Обработка на фильтре
|
||
|
||
Пакет, попавший на LAN-порт фильтра, проходит через цепочку проверок:
|
||
|
||
1. **Проверка: IP-пакет или нет.** После разбора инкапсуляции фильтр проверяет, есть ли внутри IPv4- или IPv6-пакет. Не-IP кадры без какой-либо обработки выводятся в парный порт; в типовой схеме до фильтра из не-IP трафика доходят практически только keep-alive-пакеты балансировщика, которые таким образом возвращаются балансировщику.
|
||
|
||
2. **Проверка по ACL.** ACL на фильтре задают, какой трафик подлежит анализу, и привязаны к пулу — логической сущности, в которую попадает отобранный трафик для дальнейшей обработки ([раздел 16](filter-acl-pools.md)). Пакет, не попавший ни в один пул (ни одно разрешающее правило ACL его не отобрало), анализу не подлежит и прозрачно передаётся в парный порт.
|
||
|
||
3. **Проверка по DPI-листу.** В DPI-листе указаны IP-подсети и адреса, подлежащие проверке ([раздел 17.4](filter-dpi.md)). Если IP-адреса пакета не попадают в обработку DPI-листа — пакет прозрачно пропускается.
|
||
|
||
4. **Обработка движком DPI.** Только пакеты, прошедшие все предыдущие проверки, попадают на анализ DPI-движком. По результатам анализа принимается решение: пропустить пакет либо отбросить его (drop), если он попадает под запрещающие политики; при блокировке ресурса абоненту дополнительно отправляется HTTP-редирект (для HTTP) или TCP Reset (для HTTPS) ([раздел 17.4.4](filter-dpi.md); особенности для трафика с MPLS — см. ниже).
|
||
|
||
Глубина разбора инкапсуляции на фильтре задаётся настройкой (параметр `vlan_mode`, в проекте всегда `qinq` — [раздел 15.2.1](filter-interfaces.md)); ограничения фильтра по типам инкапсуляции несколько строже, чем у балансировщика.
|
||
|
||
Фильтр работает на уровне **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)._
|
||
|
||
Подробнее путь пакета через фильтр описан в [разделе 10](filter.md).
|
||
|
||
### Особенность: HTTP-редирект и TCP Reset при наличии MPLS
|
||
|
||
Особый случай — блокировка трафика с MPLS-метками, когда фильтру нужно отправить абоненту **HTTP-редирект** (перенаправление на страницу-заглушку; по документации производителя — ответ «307 Temporary Redirect») при блокировке HTTP-ресурса или **TCP Reset** при блокировке HTTPS-ресурса ([раздел 17.4](filter-dpi.md)). Фильтр не может просто сформировать такой пакет сам: MPLS-путь однонаправлен, и метки, с которыми пришёл пакет абонента, действительны только для направления в сторону интернета — стек меток обратного направления фильтру неизвестен.
|
||
|
||
Поэтому для трафика с MPLS-метками фильтр пропускает запрос абонента к ресурсу как есть, дожидается первого ответного пакета той же сессии — он приходит уже с корректными метками обратного направления — и подставляет вместо его содержимого HTTP-редирект (для HTTP) или TCP Reset (для HTTPS: подменить зашифрованный ответ нельзя, ресурс определяется по SNI в ClientHello — [раздел 17.5.3](filter-dpi.md)), сохраняя метки. Модифицированный пакет доставляется абоненту с корректной инкапсуляцией, и блокировка срабатывает штатно. Для QUIC (UDP/443) TCP Reset неприменим — это UDP-протокол; распознавание QUIC на фильтре включается отдельным списком ресурсов ([раздел 17.4.9](filter-dpi.md)). Подробнее механизм описан в [разделе 6.8](balancer.md).
|
||
|
||
---
|
||
|
||
[← Оглавление](../README.md) · [← Раздел 1: Введение и общая архитектура АСБИ](overview.md) · [Раздел 3: Места установки ТСПУ →](placement.md)
|