# 2. Прохождение трафика через ТСПУ [← Оглавление](../README.md) · [← Раздел 1: Введение и общая архитектура АСБИ](01.md) --- image ## 2.1. Стык оператора связи: типы инкапсуляции ТСПУ устанавливается в разрыв канала связи внутри сети оператора. На стыке, в который врезается ТСПУ, трафик представляет собой поток пакетов между оборудованием оператора — с одной стороны абоненты, с другой стороны интернет. Рассмотрим прохождение пакета с точки зрения абонента. У абонента есть **локальный 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 меняются местами. image ### Инкапсуляция на стыке оператора На стыке оператора связи пакет может иметь различную дополнительную инкапсуляцию. Это зависит от технологий, применяемых конкретным оператором, и от места в сети, куда устанавливается ТСПУ. Общая структура кадра Ethernet с учётом возможных дополнительных заголовков: ```text ┌──────────┬─────────────────┬──────────────┬─────────┬──────┐ │ Ethernet │ Доп. заголовки │ IP-заголовок│ TCP/UDP │ Data │ │ заголовок│ (??? ) │ │ │ │ └──────────┴─────────────────┴──────────────┴─────────┴──────┘ ``` В поле дополнительных заголовков могут встречаться: | Тип инкапсуляции | Описание | | -------------------- | ------------------------------------------------- | | **Без инкапсуляции** | Чистый IP-пакет, дополнительных заголовков нет | | **VLAN (802.1Q)** | Один VLAN-тег (тегированный пакет) | | **QinQ (802.1ad)** | Два VLAN-тега (дважды тегированный пакет) | | **MPLS** | Одна или несколько MPLS-меток | | **MPLS + VLAN** | Комбинация MPLS-меток и VLAN-тегов | | **PPPoE** | PPP-инкапсуляция (характерна для участка до BRAS) | | **PPPoE + MPLS** | PPP внутри MPLS-туннеля | Вариантов инкапсуляции в операторских сетях очень много, и все они не могут быть перечислены исчерпывающим образом. Ключевой момент: **ТСПУ должен уметь разбираться со всеми этими заголовками**, чтобы добраться до IP-пакета и выполнить его анализ и обработку. Всё, что находится «поверх» IP-заголовка, прозрачно пропускается — никакие метки и теги ТСПУ не снимает и не модифицирует. ## 2.2. Разделение на LAN-порты и WAN-порты Фундаментальный принцип организации портов на всех устройствах ТСПУ — разделение на **LAN** и **WAN**: - **LAN-порты** — порты, смотрящие в сторону **абонентов** (внутренняя сторона сети оператора); - **WAN-порты** — порты, смотрящие в сторону **интернета** (внешняя сторона). ```text Абоненты Интернет │ │ ▼ ▼ ┌──────────┐ ┌──────────┐ │ LAN-порт │ ◄── ТСПУ ──► │ WAN-порт │ └──────────┘ └──────────┘ ``` Эта идеология **прослеживается через всё оборудование ТСПУ** — от байпасов до балансировщиков и фильтров. Все порты на любом устройстве ТСПУ можно разделить на две группы: порты в сторону абонентов (LAN) и порты в сторону интернета (WAN). На **фильтрах** разделение реализовано жёстко: все **чётные** порты — LAN, все **нечётные** — WAN. На **балансировщиках** аналогичное разделение принято по договорённости при проектировании схем: чётные порты назначаются LAN-портами, нечётные — WAN-портами. Этот принцип является основой для корректной обработки трафика: пакет, вошедший через определённый LAN-порт, после обработки обязательно выходит через парный ему WAN-порт (и наоборот), что обеспечивает прозрачность ТСПУ для сети оператора. ## 2.3. Простейший вариант ТСПУ (один байпас, один фильтр) В минимальной конфигурации ТСПУ может состоять всего из трёх компонентов: - **один байпас** — для одного-двух каналов связи оператора; - **один фильтр** — для обработки всего проходящего трафика; - **сегмент управления** — SPFS, СПХД, коммутатор, VPN-шлюз. ```text Оборудование Оборудование оператора оператора (LAN) (WAN) │ │ │ ┌───────────┐ │ └────┤ Байпас ├────┘ └─────┬─────┘ │ ┌─────┴─────┐ │ Фильтр │ └───────────┘ ───────────────────────────── Сегмент управления (SPFS, СПХД, VPN) ``` В таком варианте **балансировщик не нужен**, поскольку весь трафик обрабатывается одним фильтром и распределение по нескольким фильтрам не требуется. Каналы от байпаса подключаются непосредственно к портам фильтра. Ограничение: могут быть подключены только каналы **1 Гбит/с** или **10 Гбит/с** Ethernet, поскольку фильтры текущего проекта не поддерживают интерфейсы 100 Гбит/с — только 1G и 10G в зависимости от конкретной модели. ## 2.4. Типовая схема ТСПУ В типовой конфигурации присутствуют все компоненты системы: байпасы, балансировщики и фильтры. Рассмотрим полный путь пакета через ТСПУ. ### Общая схема прохождения трафика ```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 │ └─────┘ └─────┘ ``` ### Этап 1: Байпас Канал связи оператора физически разрывается и заводится на байпас. Байпас обеспечивает защиту канала: в случае аварии он замыкает линки напрямую, минуя остальное оборудование ТСПУ. В штатном режиме (Inline) байпас прозрачно пропускает трафик дальше — в сторону балансировщика. image Подробнее о режимах работы байпаса — в [разделе 3](03.md). ### Этап 2: Балансировщик — фильтрация служебного трафика На входе в балансировщик порты объединяются в **линки** — логические пары LAN + WAN. Трафик, пришедший через конкретный LAN-порт, **обязательно возвращается** через парный ему WAN-порт (и наоборот). Это гарантирует, что ТСПУ не нарушает маршрутизацию оператора. Первым делом трафик проходит через **правила фильтрации** (flow rules) балансировщика. Здесь определяется, какой трафик следует отправить на анализ фильтрами, а какой — сразу вернуть обратно оператору (забайпасить). Байпасятся, как правило: - служебные протоколы (например, BGP — TCP-порт 179); - мультикаст-трафик; - протоколы маршрутизации; - прочий трафик, который не нужно и нежелательно анализировать. В принципе, с таким трафиком на фильтрах ничего плохого не произойдёт, но лучше его не трогать — это снижает нагрузку и исключает потенциальное влияние на служебные протоколы оператора. image ### Этап 3: Балансировщик — распределение по фильтрам Трафик, не попавший под правила байпаса, отправляется в **группу балансировки**. В этой группе подключены все фильтры площадки. Балансировщик распределяет пакеты по фильтрам на основе **хэш-суммы**, вычисляемой по трём параметрам: 1. **Source IP** (адрес источника) 2. **Destination IP** (адрес назначения) 3. **IP-протокол** (TCP, UDP и т.д.) К хэшу также добавляется **количество ядер фильтров**, чтобы пакет не просто попал на конкретный фильтр, но и был распределён на конкретное ядро для обработки. Для передачи информации о балансировке к пакету добавляется **дополнительный 4-байтовый заголовок** (по структуре похож на VLAN-тег, но таковым не является). Этот заголовок сообщает фильтру, на какое ядро направить пакет. После обработки фильтр возвращает пакет с тем же 4-байтовым заголовком, по которому балансировщик определяет, в какой именно операторский линк нужно вернуть пакет. **Симметричность хэша** — ключевое свойство балансировки. При вычислении хэша для обратного пакета (от интернета к абоненту) source и destination меняются местами, но итоговая хэш-сумма совпадает. Благодаря этому: - оба направления одной сессии **всегда попадают на один и тот же фильтр**; - более того — на одно и то же **ядро** этого фильтра; - сессия никогда не распределяется по разным фильтрам, что позволяет корректно собирать и анализировать её на одном устройстве. ### Этап 4: Обработка на фильтре Пакет, попавший на фильтр, проходит через цепочку проверок: 1. **Проверка: IP-пакет или нет.** Если пакет не является IP-пакетом (например, служебный keep-alive от балансировщика), он прозрачно пропускается через парный порт обратно в сеть оператора. 2. **Проверка по ACL.** На фильтре настроены списки контроля доступа (ACL), привязанные к пулам. Если пакет не попадает ни в один ACL — он прозрачно пропускается. 3. **Проверка по DPI-листу.** В DPI-листе указаны IP-подсети и адреса, подлежащие проверке. Если IP-адреса пакета не попадают в обработку DPI-листа — пакет прозрачно пропускается. 4. **Обработка движком DPI.** Только пакеты, прошедшие все предыдущие проверки, попадают на анализ DPI-движком. По результатам анализа принимается решение: пропустить пакет или заблокировать (drop). Фильтр работает на уровне **L2** — он не изменяет Ethernet-кадр и не участвует в маршрутизации. С точки зрения сети оператора, фильтр представляет собой **«прозрачный провод»**: все заголовки инкапсуляции (VLAN-теги, MPLS-метки и т.д.) проходят через фильтр без изменений. Фильтр разбирает стек заголовков только для того, чтобы добраться до IP-пакета и выполнить анализ, после чего пакет (в случае пропуска) передаётся дальше в неизменном виде. image ### Особенность: HTTP-редирект и TCP Reset при наличии MPLS Особый случай возникает, когда фильтру нужно отправить абоненту **HTTP-редирект** (код 302, перенаправление на страницу-заглушку) или **TCP Reset** при блокировке HTTPS-ресурса. Фильтр не может просто сгенерировать ответный пакет, поскольку канал между балансировщиком и фильтром **однонаправленный** с точки зрения сессии — пакет от абонента приходит через LAN-порт, и ответ должен уйти абоненту с корректными заголовками инкапсуляции (в том числе MPLS-метками), которые фильтр сам сгенерировать не может. Поэтому используется следующая логика: 1. Пакет от абонента в сторону интернет-ресурса **пропускается** как есть; 2. Фильтр **ожидает обратный пакет** от интернет-ресурса в рамках той же сессии; 3. Когда обратный пакет приходит (уже с корректными заголовками, включая нужные MPLS-метки), фильтр **подменяет** содержимое этого пакета на HTTP-редирект или TCP Reset; 4. Модифицированный пакет отправляется абоненту с сохранением всей инкапсуляции. Таким образом, пакет доставляется абоненту с корректными сетевыми заголовками, и HTTP-редирект или разрыв соединения срабатывает штатно. --- [← Оглавление](../README.md) · [← Раздел 1: Введение и общая архитектура АСБИ](01.md) · [Раздел 3: Байпас →](03.md)