DanielLavrushin_tspu-docs/chapters/02.md

2. Прохождение трафика через ТСПУ

← Оглавление · ← Раздел 1: Введение и общая архитектура АСБИ

---

Путь пакета через ТСПУ можно разбить на четыре участка: стык оператора связи (1), байпас (2), балансировщик (3) и фильтры (4). Ниже они рассмотрены по порядку — на упрощённой, но достаточной для понимания типовой схеме. Число байпасов на площадке определяется количеством разрываемых каналов оператора: каждый канал занимает на байпасе свою четвёрку портов Net0/Net1/Mon0/Mon1, а один байпас может обслуживать один или несколько каналов.

Типовая схема ТСПУ: 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).

Абонент → Интернет:
┌─────────────────────────────────────────────┐
│  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).

Стык оператора: адреса и порты в прямом и обратном пакетах; внизу — структура кадра с полем дополнительной инкапсуляции («???») и примеры его содержимого (VLAN, VLAN+VLAN, VLAN+MPLS+MPLS и т. д.).

Инкапсуляция на стыке оператора

На стыке оператора связи пакет может иметь различную дополнительную инкапсуляцию. Она зависит от технологий, применяемых конкретным оператором, от места в сети, куда устанавливается ТСПУ (раздел 6), и от других факторов.

Общая структура кадра Ethernet с учётом возможных дополнительных заголовков:

┌──────────────────┬────────────────────────────────┬──────────────┬───────────┬──────┐
│ 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 (раздел 6.1)
PPPoE + MPLS	PPPoE-кадр, в свою очередь упакованный в MPLS (например, перенос PPPoE до BRAS через псевдопровод)

Вариантов инкапсуляции в операторских сетях очень много, и перечислить их исчерпывающе невозможно — на стыке может встретиться практически что угодно. Ключевой момент: ТСПУ должен уметь разбирать все эти заголовки, чтобы добраться до IP-пакета и выполнить его анализ и обработку. Все манипуляции выполняются только с IP-пакетом; заголовки инкапсуляции, стоящие перед ним (VLAN-теги, MPLS-метки, PPPoE), ни балансировщик, ни фильтр не снимают и не модифицируют — пакет возвращается оператору с тем же стеком заголовков, с которым пришёл. Служебный заголовок, который балансировщик добавляет для передачи пакета фильтру внутри ТСПУ, снимается до возврата пакета оператору (см. 2.4). Если IP-пакета в стеке заголовков не обнаружено, такой трафик пропускается прозрачно и на фильтры не отправляется.

2.2. Разделение на LAN-порты и WAN-порты

Фундаментальный принцип организации портов на всех устройствах ТСПУ — разделение на LAN и WAN. Термины используются условно, как обозначение стороны канала, а не типа сети:

• LAN-порты — порты, смотрящие в сторону абонентов (внутренняя сторона сети оператора);
• WAN-порты — порты, смотрящие в сторону интернета (внешняя сторона — аплинки, пиринг).

                  Абоненты                             Интернет
                     │                                    │
                     ▼                                    ▼
               ┌──────────┐                        ┌──────────┐
               │ LAN-порт │    ◄── ТСПУ ──►        │ WAN-порт │
               └──────────┘                        └──────────┘

Эта идеология прослеживается через всё оборудование ТСПУ — от байпасов до балансировщиков и фильтров. Все порты на любом устройстве ТСПУ можно разделить на две группы: порты в сторону абонентов (LAN) и порты в сторону интернета (WAN). Порты всегда работают парами LAN + WAN: на байпасе это Net0/Net1 и Mon0/Mon1, на балансировщике — линки и группы портов, на фильтре — пары соседних интерфейсов. Ни LAN-, ни WAN-порты не имеют IP-адресов и не участвуют в маршрутизации.

На фильтрах разделение реализовано жёстко: интерфейсы нумеруются с единицы и объединены в пары соседних номеров (te1/te2, te3/te4 …), в каждой паре чётный порт — LAN, нечётный — WAN (раздел 11.5). На балансировщиках жёсткой привязки нет, но такое же разделение принято по договорённости при проектировании схем: чётные порты назначаются LAN-портами, нечётные — WAN-портами, причём как для портов в сторону оператора, так и для портов в сторону фильтров. Для 10-гигабитных портов чётность определяется по второй цифре номера (например, p4-2 — LAN, p4-1 — WAN), для 100-гигабитных — по единственной цифре (p10 — LAN, p9 — WAN); подробнее — в разделе 4.3.

Этот принцип является основой для корректной обработки трафика: пакет, вошедший через определённый LAN-порт, после обработки обязательно выходит через парный ему WAN-порт (и наоборот). Устройства ТСПУ не изучают MAC-адреса и не ведут таблиц коммутации — кадр всегда передаётся строго в парный порт, поэтому для оборудования оператора ТСПУ неотличим от отрезка кабеля.

2.3. Простейший вариант ТСПУ (один байпас, один фильтр)

В минимальной конфигурации (см. также раздел 1.4) ТСПУ состоит всего из трёх компонентов:

• один байпас — для одного-двух каналов связи оператора;
• один фильтр — для обработки всего проходящего трафика;
• сегмент управления — VPN-шлюз, коммутатор, серверы SPFS и СПХД.

    Оборудование оператора           Оборудование оператора
    (сторона абонентов, LAN)         (сторона интернета, WAN)
               │                                │
          ┌────┴────────────────────────────────┴────┐
          │ Net0              Байпас              Net1│
          │ Mon0                                  Mon1│
          └────┬────────────────────────────────┬────┘
               │ LAN                            │ WAN
          ┌────┴────────────────────────────────┴────┐
          │ te2 (LAN)         Фильтр         te1 (WAN)│
          └──────────────────────────────────────────┘

    ───────────────────────────────────────────────────
       Сегмент управления (VPN-шлюз, SPFS, СПХД)

В таком варианте балансировщик не нужен, поскольку весь трафик обрабатывается одним фильтром и распределение по нескольким фильтрам не требуется. Порты байпаса Mon0 и Mon1 подключаются непосредственно к паре портов фильтра: Mon0 — к LAN-порту, Mon1 — к WAN-порту. Heartbeat-пакеты, которыми байпас проверяет канал до фильтра, в этой схеме доходят до фильтра; это не IP-пакеты, поэтому фильтр без обработки передаёт их в парный порт, и контур проверки замыкается.

Ограничения этой схемы: могут быть подключены только каналы 1 Гбит/с или 10 Гбит/с Ethernet, поскольку фильтры проекта (модели 2020/2040 и 4080/4120/4160 — раздел 11) не имеют интерфейсов 100 Гбит/с — только 1G и 10G в зависимости от конкретной модели; пропускная способность ограничена одним фильтром, а при его отказе байпас замыкает канал, и трафик проходит без анализа. По техническому описанию производителя 2024 года интерфейсы 100GE (2 × QSFP28) есть только у более поздней старшей модели EcoFilter 5200 (см. указатель оборудования).

2.4. Типовая схема ТСПУ

В типовой конфигурации присутствуют все компоненты системы: байпасы, балансировщики и фильтры. Рассмотрим полный путь пакета через ТСПУ.

Общая схема прохождения трафика

      Оборудование оператора                   Оборудование оператора
      (сторона абонентов, 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 пилотного проекта таких режимов не имеют и переключаются с флапом линка — раздел 3.3).

Байпас контролирует доступность канала до балансировщика служебными heartbeat-пакетами, которые отправляются из Mon0 и должны вернуться в Mon1 (и наоборот); до фильтров эти пакеты не доходят — балансировщик прозрачно заворачивает их обратно. Если heartbeat-пакеты перестают проходить, байпас автоматически переключает канал в режим TAP или Active Bypass.

Байпас: порты NET0/NET1 в сторону оператора, MON0/MON1 в сторону балансировщика, режимы passive/active bypass, TAP и Inline, контуры heartbeat MON0 → MON1 и MON1 → MON0 через балансировщик.

Подробнее о режимах работы байпаса — в разделе 3.

Этап 2: Балансировщик — линки и исключение служебного трафика

Все порты балансировщика делятся на две группы: порты, подключённые через байпасы к оборудованию оператора, и порты, к которым подключены фильтры; и те и другие организованы парами LAN/WAN. По умолчанию никакой конфигурации в балансировщике нет — номера и назначение портов выбираются при проектировании конкретного узла, поэтому номера портов в примерах условны.

На входе в балансировщик порты в сторону оператора объединяются в линки — логические пары LAN + WAN. Пакет, вошедший в LAN-порт линка, после обработки всегда выходит через WAN-порт того же линка (и наоборот) и ни в какой другой порт попасть не может. Так ТСПУ не меняет прохождение пакетов по каналам оператора: пакет, отправленный оператором в конкретный канал, выходит из ТСПУ в продолжение того же канала, и трафик разных линков никогда не смешивается. Соблюдается также правило проектирования: все каналы одного агрегированного линка (LAG) оператора заводятся на один и тот же балансировщик — иначе прямое и обратное направления одной сессии, разнесённые оператором по разным каналам агрегата, могут попасть на разные балансировщики и, следовательно, на разные фильтры.

К каждому линку привязаны правила (flow rules) балансировщика — они применяются в порядке приоритетов, и возможных действий два: отправить трафик в группу балансировки, то есть на фильтры, или прямо на входе вернуть его оператору через парный порт линка (действие bypass; не путать с устройством «байпас»). Возвращаются без анализа, как правило:

• протоколы маршрутизации и сигнализации (например, BGP — TCP-порт 179, OSPF, BFD);
• мультикаст-трафик;
• служебный трафик оператора, выделенный, например, в отдельный VLAN;
• прочий трафик, который не нужно и нежелательно анализировать.

С таким трафиком на фильтрах ничего плохого произойти не должно, но лучше его не трогать: анализировать его бессмысленно, а служебные протоколы чувствительны к задержкам и потерям. Условия правил могут включать VLAN-теги, количество MPLS-меток, IP-адреса, L4-порты и MAC-адреса: например, если известно, что в VLAN 1 идёт служебный трафик оператора, его можно вернуть оператору целиком. Отбор по MPLS-меткам технически возможен, но практического смысла не имеет. Сами теги и метки балансировщик при этом не снимает: на фильтр пакет уходит с тем же набором меток. Настройка правил описана в разделе 21.7.

Логика балансировщика: порты в сторону оператора (сверху, 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-пакета в стеке нет, трафик пропускается прозрачно и на фильтры не отправляется.

При вычислении хэша учитывается также число обрабатывающих ядер фильтра (все ядра процессора, кроме одного сервисного, — параметр N_UNIT_QA), поэтому результат однозначно определяет не только пару портов, но и конкретное ядро фильтра, которое будет обрабатывать пакет, — трафик сразу равномерно распределяется по всем ядрам (раздел 4.5.2, 21.5.2). Балансировка выполняется аппаратно, программируемым чипом, и не логируется: узнать, на какой фильтр попала конкретная сессия, можно только поиском на фильтрах (раздел 24.2).

Для передачи информации о балансировке к пакету добавляется дополнительный 4-байтовый заголовок (по структуре похож на VLAN-тег, но таковым не является). Этот заголовок сообщает фильтру, на какое ядро направить пакет. После обработки фильтр возвращает пакет с тем же 4-байтовым заголовком, по нему балансировщик определяет, в какой именно операторский линк вернуть пакет, и снимает заголовок перед отправкой оператору. Так достигается корректное прохождение трафика: пакет, пришедший из конкретного порта оператора, возвращается в тот же порт независимо от того, каким фильтром он был обработан.

Симметричность хэша — ключевое свойство балансировки. Для обратного пакета (от интернета к абоненту) source и destination меняются местами, но адреса комбинируются так, что итоговая хэш-сумма совпадает. Благодаря этому:

• оба направления одной сессии всегда попадают на один и тот же фильтр;
• более того — на одну и ту же пару портов и на одно и то же ядро этого фильтра;
• сессия никогда не распределяется по разным фильтрам, поэтому её всегда можно собрать и проанализировать на одном устройстве.

Распределение детерминировано, пока состав группы не меняется; при включённой перебалансировке после отказа группы портов хэш пересчитывается, и часть сессий переезжает на другие фильтры (раздел 4.6.3). Обратная сторона принципа: одна сессия не может быть разбалансирована. Если, например, 200 Гбит/с трафика идут с одного адреса источника на один адрес назначения по одному протоколу, весь этот поток попадёт на один порт одного фильтра и даже на одно его ядро. Равномерная балансировка опирается на то, что в операторском трафике огромное количество разных сессий.

Отказоустойчивость на этом участке обеспечивает сам балансировщик — это второй, независимый от heartbeat байпаса (этап 1) контур контроля: в каждую пару портов в сторону фильтра он отправляет keep-alive-пакеты (через LAN-порт, с возвратом через WAN-порт), и если они перестают проходить — порт фильтра или сам фильтр перестал обрабатывать трафик, — трафик этой группы портов программно байпасится, то есть возвращается оператору без обработки, либо, в зависимости от настроек, перебалансируется на рабочие группы. В проекте перебалансировка отключена, и на время недоступности группы её трафик проходит без анализа. Подробнее — в разделе 4.6.

Этап 4: Обработка на фильтре

Пакет, попавший на LAN-порт фильтра, проходит через цепочку проверок:

1. Проверка: IP-пакет или нет. После разбора инкапсуляции фильтр проверяет, есть ли внутри IPv4- или IPv6-пакет. Не-IP кадры без какой-либо обработки выводятся в парный порт; в типовой схеме до фильтра из не-IP трафика доходят практически только keep-alive-пакеты балансировщика, которые таким образом возвращаются балансировщику.

2. Проверка по ACL. ACL на фильтре задают, какой трафик подлежит анализу, и привязаны к пулу — логической сущности, в которую попадает отобранный трафик для дальнейшей обработки (раздел 16). Пакет, не попавший ни в один ACL, анализу не подлежит и прозрачно передаётся в парный порт.

3. Проверка по DPI-листу. В DPI-листе указаны IP-подсети и адреса, подлежащие проверке (раздел 17.4). Если IP-адреса пакета не попадают в обработку DPI-листа — пакет прозрачно пропускается.

4. Обработка движком DPI. Только пакеты, прошедшие все предыдущие проверки, попадают на анализ DPI-движком. По результатам анализа принимается решение: пропустить пакет (pass) либо отбросить (drop), если он попадает под запрещающие политики; при блокировке ресурса абоненту дополнительно отправляется HTTP-редирект (для HTTP) или TCP Reset (для HTTPS) (раздел 17.4.4; особенности для трафика с MPLS — см. ниже).

Глубина разбора инкапсуляции на фильтре задаётся настройкой (параметр VLAN Mode, в проекте всегда QinQ — раздел 15.2.1); ограничения фильтра по типам инкапсуляции несколько строже, чем у балансировщика.

Фильтр работает на уровне L2: в тракте передачи трафика у него нет L3-интерфейсов, он не является ни маршрутизатором, ни коммутатором и всегда передаёт кадр строго в парный порт. С точки зрения сети оператора фильтр представляет собой «прозрачный провод»: все заголовки инкапсуляции (VLAN-теги, MPLS-метки и т. д.) проходят через фильтр без изменений. Фильтр разбирает стек заголовков только для того, чтобы добраться до IP-пакета и выполнить анализ; пропускаемый трафик покидает фильтр в неизменном виде, изменения вносятся только в пакеты блокируемых сессий (drop, подмена на HTTP-редирект или TCP Reset).

Все проверки, включая самую первую («IP-пакет или нет»), выполняются процессором фильтра. Поэтому если фильтр перегружен или «завис», не проходят даже keep-alive-пакеты балансировщика — и балансировщик переводит трафик этой группы портов в программный байпас.

Путь пакета через фильтр: вход через LAN-порт (te2), проверки «IP-пакет?», «попадает в pool/ACL?», «попадает в обработку DPI?», затем DPI с решением pass/drop; выход через парный WAN-порт (te1).

Подробнее путь пакета через фильтр описан в разделе 5.

Особенность: HTTP-редирект и TCP Reset при наличии MPLS

Особый случай — блокировка трафика с MPLS-метками, когда фильтру нужно отправить абоненту HTTP-редирект (код 302, перенаправление на страницу-заглушку) при блокировке HTTP-ресурса или TCP Reset при блокировке HTTPS-ресурса (раздел 17.4). Фильтр не может просто сформировать такой пакет сам: MPLS-путь однонаправлен, и метки, с которыми пришёл пакет абонента, действительны только для направления в сторону интернета — стек меток обратного направления фильтру неизвестен.

Поэтому для трафика с MPLS-метками фильтр пропускает запрос абонента к ресурсу как есть, дожидается первого ответного пакета той же сессии — он приходит уже с корректными метками обратного направления — и подставляет вместо его содержимого HTTP-редирект (для HTTP) или TCP Reset (для HTTPS: подменить зашифрованный ответ нельзя, ресурс определяется по SNI в ClientHello — раздел 17.5.3), сохраняя метки. Модифицированный пакет доставляется абоненту с корректной инкапсуляцией, и блокировка срабатывает штатно. Для QUIC (UDP/443) TCP Reset неприменим — это UDP-протокол; распознавание QUIC на фильтре включается отдельным списком ресурсов (раздел 17.4.9). Подробнее механизм описан в разделе 4.8.

---

← Оглавление · ← Раздел 1: Введение и общая архитектура АСБИ · Раздел 3: Байпас →