From 3101ce52e8833861ffaf4920cfc2500f6f0e5860 Mon Sep 17 00:00:00 2001 From: Daniel Lavrushin Date: Fri, 4 Sep 2026 09:52:45 +0200 Subject: [PATCH] Refactor chapter 2 for clarity and detail, enhancing explanations of traffic flow, encapsulation, and filtering processes --- chapters/02.md | 215 ++++++++++++++++++++++++++----------------------- 1 file changed, 114 insertions(+), 101 deletions(-) diff --git a/chapters/02.md b/chapters/02.md index e52f77d..cba466f 100644 --- a/chapters/02.md +++ b/chapters/02.md @@ -3,12 +3,16 @@ [← Оглавление](../README.md) · [← Раздел 1: Введение и общая архитектура АСБИ](01.md) --- - + +Путь пакета через ТСПУ можно разбить на четыре участка: стык оператора связи (1), байпас (2), балансировщик (3) и фильтры (4). Ниже они рассмотрены по порядку — на упрощённой, но достаточной для понимания типовой схеме. Число байпасов на площадке определяется количеством разрываемых каналов оператора: каждый канал занимает на байпасе свою четвёрку портов Net0/Net1/Mon0/Mon1, а один байпас может обслуживать один или несколько каналов. + image +_Типовая схема ТСПУ: 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)). image +_Стык оператора: адреса и порты в прямом и обратном пакетах; внизу — структура кадра с полем дополнительной инкапсуляции («???») и примеры его содержимого (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. image +_Байпас: порты 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). image +_Логика балансировщика: порты в сторону оператора (сверху, 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-пакеты балансировщика — и балансировщик переводит трафик этой группы портов в программный байпас. image +_Путь пакета через фильтр: вход через 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). ---