From cba7581665c317f888d5f15054227c4b034b2dd4 Mon Sep 17 00:00:00 2001 From: Daniel Lavrushin Date: Fri, 20 Feb 2026 11:58:48 +0100 Subject: [PATCH] first commit --- .gitignore | 1 + 01.md | 130 ++++++++++++++++++++ 02.md | 248 +++++++++++++++++++++++++++++++++++++ 03.md | 216 +++++++++++++++++++++++++++++++++ 04.md | 248 +++++++++++++++++++++++++++++++++++++ index.md | 350 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 6 files changed, 1193 insertions(+) create mode 100644 .gitignore create mode 100644 01.md create mode 100644 02.md create mode 100644 03.md create mode 100644 04.md create mode 100644 index.md diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..099de52 --- /dev/null +++ b/.gitignore @@ -0,0 +1 @@ +/tspu.txt \ No newline at end of file diff --git a/01.md b/01.md new file mode 100644 index 0000000..b52dd2c --- /dev/null +++ b/01.md @@ -0,0 +1,130 @@ +# 1. Введение и общая архитектура АСБИ + +[← Оглавление](index.md) + +--- + +## 1.1. Что такое АСБИ + +**АСБИ** (Автоматизированная система обеспечения безопасности интернета) — это государственная система, создаваемая в рамках реализации закона о суверенном интернете. Её основная задача — обеспечить возможность анализа, фильтрации и управления интернет-трафиком на уровне операторов связи на всей территории Российской Федерации. + +АСБИ представляет собой распределённую иерархическую систему, состоящую из: + +- **ТСПУ** (технические средства противодействия угрозам) — комплексы оборудования, устанавливаемые непосредственно у операторов связи; +- **Центральная система управления (ЦСУ)** — централизованная платформа для управления всеми ТСПУ, развёрнутая на двух физически независимых площадках с резервированием. + +Все ТСПУ связаны с ЦСУ и управляются через неё. Именно через центральную систему управления выполняются основные операции по конфигурированию, мониторингу и обновлению оборудования ТСПУ. + +## 1.2. Закон о суверенном интернете и участники проекта + +Проект АСБИ реализуется в рамках **закона о суверенном интернете** (Федеральный закон № 90-ФЗ). В реализации проекта участвуют несколько ключевых организаций: + +| Роль | Организация | Описание | +| -------------------------- | --------------------------------------- | --------------------------------------------------------------------------------------------------------------- | +| **Заказчик** | ГУП ГРЧЦ (Главный радиочастотный центр) | Представляет интересы государства | +| **Генеральный подрядчик** | АО «ДЦА» | Осуществляет общее руководство проектом | +| **Поставщик оборудования** | RDP.ru | Поставляет два типа устройств: **балансировщики** и **фильтры**, а также разрабатывает часть системы управления | + +Проект развивался поэтапно: + +- **Пилотный проект** — развёрнут на Урале, включает ограниченное количество площадок. Использует байпасы GL Sun и раннюю версию ЦСУ; +- **Федеральный проект** — масштабное развёртывание по всей стране. Включает байпасы Silicom, новое оборудование фильтров (модели 2020 года), новую версию ЦСУ и эшелонированную систему фильтрации. На данном этапе предполагается порядка **350 площадок** и суммарно около **5 000 устройств**. + +## 1.3. Что такое ТСПУ — комплекс оборудования у операторов связи + +**ТСПУ** (Технические средства противодействия угрозам) — это комплекс оборудования, который устанавливается **в разрыв каналов связи оператора**. ТСПУ перехватывает проходящий трафик, анализирует его и при необходимости выполняет блокировку или деградацию определённых типов соединений. + +Ключевой принцип работы ТСПУ — **прозрачность для оператора**. С точки зрения сетевой топологии оператора, ТСПУ представляет собой «прозрачный провод»: трафик, вошедший через определённый канал связи, обязательно возвращается в тот же канал. Оператор не должен вносить изменения в свою маршрутизацию при установке ТСПУ. + +ТСПУ может устанавливаться в нескольких различных местах сети оператора (подробнее — в [разделе 6](06-placement.md)), и на одной площадке оператора может быть развёрнуто различное количество оборудования в зависимости от объёма трафика и количества каналов связи. + +Существует два типа ТСПУ: + +- **ТСПУ тип А** (первый эшелон) — основной тип, устанавливается у большинства операторов. Когда говорят просто «ТСПУ» без уточнения, подразумевают именно тип А; +- **ТСПУ тип Б** (второй эшелон, эшелонированная система) — устанавливается на уровне ядра сети крупных операторов для обработки трафика, который не прошёл через ТСПУ тип А (подробнее — в [разделе 7](07-echelon.md)). + +## 1.4. Общая схема: байпасы, балансировщики, фильтры, сегмент управления + +ТСПУ состоит из следующих подсистем (устройств): + +```text + Оборудование оператора + │ + ┌───────┴───────┐ + │ Байпасы │ ← защита каналов оператора + └───────┬───────┘ + │ + ┌───────┴───────┐ + │Балансировщики │ ← распределение трафика + └───────┬───────┘ + │ + ┌────────┼──────────┐ + │ │ │ + ┌───┴───┐ ┌─┴─────┐ ┌─┴─────┐ + │Фильтр │ │Фильтр │ │Фильтр │ ← анализ и фильтрация + └───────┘ └───────┘ └───────┘ + + ────────────────────────────────────────── + Сегмент управления (VPN → ЦСУ) +``` + +### Байпасы + +Байпасы — это устройства, обеспечивающие **физическую защиту каналов связи оператора**. Каналы связи оператора разрываются и заворачиваются на байпас. Количество байпасов на площадке определяется количеством линков оператора, в разрыв которых устанавливается ТСПУ. + +Байпасы работают на скоростях **10–100 Гбит/с** (в отдельных случаях — 1 Гбит/с). В случае аварии (например, обесточивания) байпас замыкает каналы напрямую, минуя остальное оборудование ТСПУ, чтобы не нарушить связность сети оператора. + +### Балансировщики + +Балансировщики — это **высокопроизводительные программируемые коммутаторы**, принимающие трафик от байпасов и распределяющие его по подключенным фильтрам. + +Основные характеристики: + +- 32-портовые, одноюнитовые (1U); +- пропускная способность — **3,2 Тбит/с** (на полной скорости при размере пакета более 160 байт); +- количество балансировщиков зависит от количества каналов связи и объёма трафика оператора. + +Все порты балансировщика разделяются на две группы: + +- **LAN-порты** — в сторону оборудования оператора (через байпасы), где находятся абоненты; +- **WAN-порты** — в сторону интернета. + +Эта идеология LAN/WAN прослеживается через всё оборудование ТСПУ — от байпасов до фильтров. + +### Фильтры + +Фильтры — это **основные устройства ТСПУ**, занимающиеся непосредственно анализом и обработкой трафика (DPI — Deep Packet Inspection). Именно на фильтрах выполняется распознавание протоколов, фильтрация по реестру Роскомнадзора, блокировка и деградация трафика. + +Количество фильтров зависит **исключительно от объёма трафика**, который необходимо обрабатывать: + +- У оператора с большим количеством каналов, но небольшим объёмом трафика — может быть мало фильтров; +- У оператора с малым количеством высокоскоростных каналов и большим трафиком — потребуется много фильтров. + +Фильтры подключаются к балансировщикам преимущественно интерфейсами **10 Гбит/с Ethernet** (в отдельных случаях — 1 Гбит/с). Количество интерфейсов между балансировщиком и фильтрами может значительно превышать количество каналов в сторону оператора. + +### Сегмент управления + +Сегмент управления — это набор коммутаторов, VPN-шлюзов и вспомогательных серверов, обеспечивающих связь оборудования ТСПУ с центральной системой управления. Через VPN-канал все устройства площадки подключаются к ЦСУ, что позволяет удалённо управлять каждым компонентом ТСПУ. + +В состав сегмента управления также входят: + +- **SPFS** (сервер предварительного формирования списков) — собирает протокольные логи с фильтров и передаёт их в ЦСУ для формирования списков блокировки; +- **СПХД** (сервер предварительного хранения данных) — используется для хранения системных логов с устройств площадки. + +### Простейший вариант ТСПУ + +В минимальной конфигурации ТСПУ может состоять из: + +- **1 байпас** — для одного-двух каналов связи; +- **1 фильтр** — для обработки всего трафика оператора; +- **Сегмент управления** — SPFS, СПХД, коммутатор, VPN-шлюз. + +В таком варианте балансировщик не требуется, так как весь трафик обрабатывается одним фильтром. Однако могут быть подключены только каналы 1 или 10 Гбит/с Ethernet, поскольку фильтры текущего проекта не поддерживают интерфейсы 100 Гбит/с — только 1G и 10G в зависимости от модели. + +### Типовая схема ТСПУ + +В типовой конфигурации присутствуют все компоненты: несколько байпасов (по количеству каналов оператора), один или несколько балансировщиков и множество фильтров. Балансировщик принимает трафик от всех байпасов, распределяет его по фильтрам для обработки, после чего обработанный трафик возвращается через балансировщик и байпас обратно в сеть оператора. + +--- + +[← Оглавление](index.md) · [Раздел 2: Прохождение трафика через ТСПУ →](02.md) diff --git a/02.md b/02.md new file mode 100644 index 0000000..afce466 --- /dev/null +++ b/02.md @@ -0,0 +1,248 @@ +# 2. Прохождение трафика через ТСПУ + +[← Оглавление](index.md) · [← Раздел 1: Введение и общая архитектура АСБИ](01.md) + +--- + +## 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 меняются местами. + +### Инкапсуляция на стыке оператора + +На стыке оператора связи пакет может иметь различную дополнительную инкапсуляцию. Это зависит от технологий, применяемых конкретным оператором, и от места в сети, куда устанавливается ТСПУ. + +Общая структура кадра 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) байпас прозрачно пропускает трафик дальше — в сторону балансировщика. + +Подробнее о режимах работы байпаса — в [разделе 3](03.md). + +### Этап 2: Балансировщик — фильтрация служебного трафика + +На входе в балансировщик порты объединяются в **линки** — логические пары LAN + WAN. Трафик, пришедший через конкретный LAN-порт, **обязательно возвращается** через парный ему WAN-порт (и наоборот). Это гарантирует, что ТСПУ не нарушает маршрутизацию оператора. + +Первым делом трафик проходит через **правила фильтрации** (flow rules) балансировщика. Здесь определяется, какой трафик следует отправить на анализ фильтрами, а какой — сразу вернуть обратно оператору (забайпасить). Байпасятся, как правило: + +- служебные протоколы (например, BGP — TCP-порт 179); +- мультикаст-трафик; +- протоколы маршрутизации; +- прочий трафик, который не нужно и нежелательно анализировать. + +В принципе, с таким трафиком на фильтрах ничего плохого не произойдёт, но лучше его не трогать — это снижает нагрузку и исключает потенциальное влияние на служебные протоколы оператора. + +### Этап 3: Балансировщик — распределение по фильтрам + +Трафик, не попавший под правила байпаса, отправляется в **группу балансировки**. В этой группе подключены все фильтры площадки. Балансировщик распределяет пакеты по фильтрам на основе **хэш-суммы**, вычисляемой по трём параметрам: + +1. **Source IP** (адрес источника) +2. **Destination IP** (адрес назначения) +3. **IP-протокол** (TCP, UDP и т.д.) + +К хэшу также добавляется **количество ядер фильтров**, чтобы пакет не просто попал на конкретный фильтр, но и был распределён на конкретное ядро для обработки. + +Для передачи информации о балансировке к пакету добавляется **дополнительный 4-байтовый заголовок** (по структуре похож на VLAN-тег, но таковым не является). Этот заголовок сообщает фильтру, на какое ядро направить пакет. После обработки фильтр возвращает пакет с тем же 4-байтовым заголовком, по которому балансировщик определяет, в какой именно операторский линк нужно вернуть пакет. + +**Симметричность хэша** — ключевое свойство балансировки. При вычислении хэша для обратного пакета (от интернета к абоненту) source и destination меняются местами, но итоговая хэш-сумма совпадает. Благодаря этому: + +- оба направления одной сессии **всегда попадают на один и тот же фильтр**; +- более того — на одно и то же **ядро** этого фильтра; +- сессия никогда не распределяется по разным фильтрам, что позволяет корректно собирать и анализировать её на одном устройстве. + +### Этап 4: Обработка на фильтре + +Пакет, попавший на фильтр, проходит через цепочку проверок: + +```text + Пакет + │ + ▼ +┌──────────────────┐ Нет +│ IP-пакет? │──────────► Прозрачный пропуск +└────────┬─────────┘ + │ Да + ▼ +┌──────────────────┐ Нет +│ Попал в ACL? │──────────► Прозрачный пропуск +│ (привязка к │ +│ пулу) │ +└────────┬─────────┘ + │ Да + ▼ +┌──────────────────┐ Нет +│ Попал в │──────────► Прозрачный пропуск +│ DPI-лист? │ +│ (IP-подсети) │ +└────────┬─────────┘ + │ Да + ▼ +┌──────────────────┐ +│ Движок DPI │ +│ (анализ и │ +│ решение) │ +└────────┬─────────┘ + │ + ┌──────┴─────────┐ + ▼ ▼ + Пропустить Заблокировать + (drop) +``` + +1. **Проверка: IP-пакет или нет.** Если пакет не является IP-пакетом (например, служебный keep-alive от балансировщика), он прозрачно пропускается через парный порт обратно в сеть оператора. + +2. **Проверка по ACL.** На фильтре настроены списки контроля доступа (ACL), привязанные к пулам. Если пакет не попадает ни в один ACL — он прозрачно пропускается. + +3. **Проверка по DPI-листу.** В DPI-листе указаны IP-подсети и адреса, подлежащие проверке. Если IP-адреса пакета не попадают в обработку DPI-листа — пакет прозрачно пропускается. + +4. **Обработка движком DPI.** Только пакеты, прошедшие все предыдущие проверки, попадают на анализ DPI-движком. По результатам анализа принимается решение: пропустить пакет или заблокировать (drop). + +Фильтр работает на уровне **L2** — он не изменяет Ethernet-кадр и не участвует в маршрутизации. С точки зрения сети оператора, фильтр представляет собой **«прозрачный провод»**: все заголовки инкапсуляции (VLAN-теги, MPLS-метки и т.д.) проходят через фильтр без изменений. Фильтр разбирает стек заголовков только для того, чтобы добраться до IP-пакета и выполнить анализ, после чего пакет (в случае пропуска) передаётся дальше в неизменном виде. + +### Особенность: HTTP-редирект и TCP Reset при наличии MPLS + +Особый случай возникает, когда фильтру нужно отправить абоненту **HTTP-редирект** (код 302, перенаправление на страницу-заглушку) или **TCP Reset** при блокировке HTTPS-ресурса. + +Фильтр не может просто сгенерировать ответный пакет, поскольку канал между балансировщиком и фильтром **однонаправленный** с точки зрения сессии — пакет от абонента приходит через LAN-порт, и ответ должен уйти абоненту с корректными заголовками инкапсуляции (в том числе MPLS-метками), которые фильтр сам сгенерировать не может. + +Поэтому используется следующая логика: + +1. Пакет от абонента в сторону интернет-ресурса **пропускается** как есть; +2. Фильтр **ожидает обратный пакет** от интернет-ресурса в рамках той же сессии; +3. Когда обратный пакет приходит (уже с корректными заголовками, включая нужные MPLS-метки), фильтр **подменяет** содержимое этого пакета на HTTP-редирект или TCP Reset; +4. Модифицированный пакет отправляется абоненту с сохранением всей инкапсуляции. + +Таким образом, пакет доставляется абоненту с корректными сетевыми заголовками, и HTTP-редирект или разрыв соединения срабатывает штатно. + +--- + +[← Оглавление](index.md) · [← Раздел 1: Введение и общая архитектура АСБИ](01.md) · [Раздел 3: Байпас →](03.md) diff --git a/03.md b/03.md new file mode 100644 index 0000000..32b8249 --- /dev/null +++ b/03.md @@ -0,0 +1,216 @@ +# 3. Байпас (Bypass) + +[← Оглавление](index.md) · [← Раздел 2: Прохождение трафика через ТСПУ](02.md) + +--- + +## 3.1. Назначение и роль байпаса в ТСПУ + +Байпас — это устройство, обеспечивающее **физическую защиту каналов связи оператора** при установке ТСПУ. Каналы связи оператора физически разрываются и заводятся на байпас, который в штатном режиме прозрачно пропускает трафик дальше — в сторону балансировщика и фильтров. + +Основная задача байпаса — гарантировать, что **при любой аварии оборудования ТСПУ** (отказ фильтров, балансировщиков, обесточивание) связность сети оператора не будет нарушена. В аварийной ситуации байпас замыкает каналы оператора напрямую, минуя остальное оборудование ТСПУ. + +Количество байпасов на площадке определяется **количеством линков оператора**, в разрыв которых устанавливается ТСПУ. Байпасы работают на скоростях **10–100 Гбит/с** (в отдельных случаях — 1 Гбит/с). + +В проекте АСБИ используются два типа байпасов: + +| Проект | Производитель | Особенности | +| ------------------- | ------------- | ------------------------------------------------ | +| **Федеральный** | Silicom | Полный набор режимов, безфлаповое переключение | +| **Пилотный (Урал)** | GL Sun | Только Power-off Bypass, флап линков при переключении | + +## 3.2. Байпасы Silicom (федеральный проект) + +Байпасы Silicom устанавливаются в рамках федерального проекта и обладают полным набором режимов работы, обеспечивающих гибкое управление прохождением трафика. + +### 3.2.1. Порты: Net0/Net1 (оператор) и Mon0/Mon1 (балансировщик) + +Для каждого канала связи байпас Silicom имеет **четыре порта**: + +- **Net0** и **Net1** — порты, подключаемые к оборудованию оператора (две стороны разорванного канала); +- **Mon0** и **Mon1** — порты, подключаемые к балансировщику (или напрямую к фильтру в простейшей конфигурации). + +```text + Оборудование Оборудование + оператора оператора + (сторона A) (сторона B) + │ │ + ▼ ▼ + ┌──────────────────────────┐ + │ Байпас Silicom │ + │ │ + │ Net0 Net1 │ + │ │ │ │ + │ │ (логика │ │ + │ │ режимов) │ │ + │ │ │ │ + │ Mon0 Mon1 │ + └────┬──────────────────┬──┘ + │ │ + ▼ ▼ + В сторону балансировщика +``` + +### 3.2.2. Режим Inline — основной рабочий режим + +**Inline** — основной рабочий режим байпаса. В этом режиме трафик прозрачно пропускается насквозь от оборудования оператора к балансировщику и обратно: + +- Net0 → Mon0 (трафик от оператора к балансировщику) +- Mon1 → Net1 (обратный трафик) +- И симметрично для другого направления. + +```text + Net0 ─────────────► Mon0 + ──► к балансировщику + Net1 ◄───────────── Mon1 +``` + +Весь трафик оператора проходит через ТСПУ и подвергается анализу и фильтрации. Это штатный режим работы при нормальном функционировании всего оборудования. + +### 3.2.3. Режим TAP — копирование трафика без влияния на оператора + +**TAP** — режим зеркалирования (копирования) трафика. В этом режиме: + +1. Каналы оператора **замыкаются напрямую** между собой (Net0 ↔ Net1); +2. **Копия трафика** отправляется в сторону балансировщика через порты Mon0/Mon1; +3. Обратный трафик от балансировщика **не принимается**. + +```text + Net0 ◄────────────► Net1 ← канал оператора замкнут + │ │ + └──► Mon0 Mon1 ◄──┘ ← копия трафика + (только отправка) +``` + +В режиме TAP система фильтрации получает **полную копию** всего трафика оператора, но **никаким образом не может на него повлиять** — ни заблокировать, ни модифицировать. Это делает TAP идеальным **режимом отладки**: можно настраивать систему фильтрации, выявлять проблемы, проверять работу DPI — при полной гарантии, что операторский трафик не пострадает. + +### 3.2.4. Режим Active Bypass — замыкание без копирования + +**Active Bypass** — режим чистого обхода. Практически идентичен режиму TAP, за исключением того, что **копия трафика в сторону балансировщика не отправляется**: + +```text + Net0 ◄────────────► Net1 ← канал оператора замкнут + ← трафик к балансировщику НЕ идёт + Mon0 Mon1 + (неактивен) (неактивен) +``` + +Каналы оператора замыкаются напрямую. ТСПУ полностью исключено из пути прохождения трафика. Этот режим используется, когда необходимо полностью отключить ТСПУ от обработки трафика, например, при проведении технических работ на оборудовании фильтрации. + +### 3.2.5. Режим Power-off Bypass — аварийное замыкание при обесточивании + +**Power-off Bypass** — аварийный режим, в который байпас переходит автоматически при **отключении электропитания**. На физическом уровне (вероятно, оптический переключатель внутри оборудования) каналы замыкаются напрямую: + +```text + Net0 ◄═══════════► Net1 ← физическое замыкание + ← оптический переключатель + Mon0 Mon1 + (обесточены) (обесточены) +``` + +Это **последнее средство** защиты трафика оператора. При переключении в этот режим: + +- у оператора **возможны флапы линков** (оптика «моргает»); +- перерыв в трафике более существенный, чем при переключении между другими режимами; +- оператор почувствует переключение — может начать перестраиваться маршрутизация; +- последствия более негативные, но это **аварийный** случай. + +### 3.2.6. Переключение между режимами и влияние на оператора + +Ключевое преимущество байпасов Silicom — переключение между режимами **Inline**, **TAP** и **Active Bypass** происходит **безболезненно для оператора связи**: + +- порты оператора **не флапают** (не падают); +- возможна лишь **кратковременная потеря единичных пакетов** — тех, которые уже ушли в сторону балансировщика, но не успели вернуться в момент переключения; +- такая потеря, как правило, **незаметна** ни для оператора, ни для абонентов — пропадание трафика на доли секунды восстанавливается протоколами верхних уровней модели OSI. + +Сводная таблица режимов: + +| Режим | Трафик оператора | Копия на ТСПУ | Влияние на оператора при переключении | +| ---------------- | --------------------- | ------------- | ------------------------------------- | +| **Inline** | Через ТСПУ | Да (полная) | — | +| **TAP** | Замкнут напрямую | Да (копия) | Безболезненно | +| **Active Bypass**| Замкнут напрямую | Нет | Безболезненно | +| **Power-off** | Замкнут напрямую | Нет | Флапы линков, перерыв трафика | + +## 3.3. Байпасы GL Sun (пилотный проект, Урал) + +Байпасы GL Sun используются в рамках **пилотного проекта на Урале**. По сравнению с Silicom, они значительно проще и имеют ряд существенных ограничений. + +### 3.3.1. Отличие от Silicom: только режим Power-off Bypass + +Байпасы GL Sun поддерживают **только один механизм переключения** — эквивалент режима Power-off Bypass у Silicom. У них нет промежуточных режимов TAP или Active Bypass с безболезненным переключением. + +Фактически GL Sun умеет только: + +- **пропускать трафик** через себя (аналог Inline); +- **замыкать каналы** физически (аналог Power-off Bypass). + +При этом, в отличие от Silicom, байпасы GL Sun не генерируют heartbeat-пакеты самостоятельно. Вместо этого heartbeat-пакеты отправляются **балансировщиком** (или фильтром, если балансировщик отсутствует) в сторону GL Sun. На балансировщике или фильтре настраивается IP-адрес байпаса, интервал отправки heartbeat-пакетов и список линков байпаса, для которых выполняется проверка. + +В федеральном проекте эта схема **не актуальна**, поскольку байпасы Silicom самостоятельно отправляют heartbeat-пакеты и самостоятельно проверяют доступность каналов. + +### 3.3.2. Флап линков при каждом переключении + +Каждое переключение режима работы байпаса GL Sun — это **флап линков оператора**. Оптика «моргает», оператор связи видит падение и восстановление интерфейсов, что может приводить к: + +- перестройке маршрутизации на стороне оператора; +- заметному перерыву в прохождении трафика; +- срабатыванию мониторинга и генерации инцидентов у оператора. + +Это значительное неудобство по сравнению с байпасами Silicom, у которых переключение между режимами Inline, TAP и Active Bypass происходит прозрачно для оператора. + +## 3.4. Мониторинг каналов: Heartbeat-пакеты байпаса + +Байпас осуществляет **постоянный мониторинг доступности каналов** в сторону балансировщика с помощью специальных **heartbeat-пакетов**. + +Принцип работы (для байпасов Silicom): + +1. Байпас отправляет heartbeat-пакет из порта **Mon0**; +2. Пакет проходит через балансировщик (балансировщик пропускает heartbeat-пакеты прозрачно между своими портами); +3. Пакет должен дойти до порта **Mon1** (и аналогично в обратном направлении); +4. Если пакет проходит — байпас считает канал исправным и продолжает работу в текущем режиме. + +```text + Байпас Балансировщик + ┌─────────┐ ┌──────────────────┐ + │ │ heartbeat │ │ + │ Mon0 ─ ┼─────────────► прозрачный │ + │ │ │ пропуск │ + │ Mon1 ◄──┼──────────┤ │ + │ │ heartbeat │ │ + └─────────┘ └──────────────────┘ +``` + +Heartbeat-пакеты байпаса Silicom — это **не IP-пакеты**, а специальные служебные кадры (по умолчанию формат IPX). По запросу RDP.ru формат пакета был изменён на согласованный вариант, который прозрачно проходит через балансировщик и, при необходимости, через фильтр, не вызывая проблем с обработкой (фильтр пропускает не-IP-пакеты прозрачно). + +Важно: heartbeat-пакеты байпаса **не доходят до фильтров** при наличии балансировщика — они заворачиваются обратно на уровне балансировщика. Таким образом, существуют **две независимые стадии** проверки отказоустойчивости: + +1. **Байпас → Балансировщик** — heartbeat-пакеты байпаса проверяют доступность каналов до балансировщика; +2. **Балансировщик → Фильтр** — keep-alive пакеты балансировщика проверяют доступность фильтров (подробнее — в [разделе 4](04.md)). + +## 3.5. Автоматическое переключение в TAP/Active Bypass при потере канала + +Если heartbeat-пакеты, отправленные через Mon0, не доходят до Mon1 в течение определённого времени (настраиваемый порог), байпас считает, что **канал связи до балансировщика неисправен**. + +В этом случае байпас **автоматически переключает** данный канал в безопасный режим: + +- **TAP** — если требуется сохранить копирование трафика для диагностики; +- **Active Bypass** — если требуется полностью исключить ТСПУ из пути трафика. + +Выбор режима зависит от **настроек** конкретного байпаса. + +```text + Штатная работа (Inline): + Net0 ──► Mon0 ──► Балансировщик ──► Mon1 ──► Net1 + heartbeat ✓ + + Потеря канала → автоматическое переключение: + Net0 ◄────────────► Net1 ← замыкание + (± копия на Mon0/Mon1, в зависимости от настроек) +``` + +Такое автоматическое переключение обеспечивает **защиту трафика оператора** без ручного вмешательства: если что-то случится с балансировщиком или фильтрами, каналы оператора будут замкнуты напрямую, и связность сети сохранится. + +--- + +[← Оглавление](index.md) · [← Раздел 2: Прохождение трафика через ТСПУ](02.md) · [Раздел 4: Балансировщик →](04.md) diff --git a/04.md b/04.md new file mode 100644 index 0000000..30eb981 --- /dev/null +++ b/04.md @@ -0,0 +1,248 @@ +# 4. Балансировщик (EcoFilter Balancer) + +[← Оглавление](index.md) · [← Раздел 3: Байпас](03.md) + +--- + +## 4.1. Назначение: распределение трафика по фильтрам + +Балансировщик (EcoFilter Balancer) — это **высокопроизводительный программируемый коммутатор**, основная задача которого — принимать трафик от байпасов и **равномерно распределять** его по подключённым фильтрам для анализа и обработки. + +Помимо балансировки, балансировщик выполняет следующие функции: + +- **фильтрация служебного трафика** — байпас (прозрачный пропуск) трафика, который не нужно отправлять на фильтры; +- **программный байпас** — возможность заворачивать трафик обратно к оператору, минуя фильтры; +- **контроль доступности фильтров** — отправка keep-alive пакетов и автоматическое отключение неисправных фильтров; +- **прозрачный пропуск heartbeat-пакетов** байпаса Silicom между своими портами. + +Количество балансировщиков на площадке определяется количеством каналов связи оператора и объёмом трафика. По умолчанию балансировщик поставляется **без конфигурации** — все порты, линки и правила необходимо создавать вручную при проектировании конкретного узла. + +## 4.2. Аппаратная платформа: 32-портовый, 1U, пропускная способность 3.2 Тбит/с + +Балансировщик представляет собой компактное одноюнитовое (1U) устройство: + +| Параметр | Значение | +| ----------------------- | -------------------------------------- | +| **Форм-фактор** | 1U (одноюнитовый) | +| **Количество портов** | 32 порта QSFP28 | +| **Пропускная способность** | 3.2 Тбит/с (на пакетах > 160 байт) | +| **Скорости портов** | 10G / 25G / 100G | +| **Питание** | 2 блока питания, горячее резервирование | +| **Передняя панель** | Консоль, Management Ethernet (1G), USB | + +Существуют также двухюнитовые балансировщики (65 портов), но в проекте АСБИ используются **только одноюнитовые** модели. + +Для подключения 10-гигабитных интерфейсов используются **гидры** (breakout-кабели): один порт QSFP28 разветвляется на четыре порта SFP+ (10G) с помощью оптических или DAC-кабелей. Таким образом, один физический QSFP28-порт может предоставить до четырёх 10G-портов. + +При работе на скорости 100G все четыре линии (lane) физического порта объединяются и работают совместно. + +## 4.3. Организация портов: пары LAN/WAN, линки + +Все порты балансировщика логически делятся на две группы: + +- **Порты в сторону оператора** (через байпасы) — подключены к каналам связи оператора; +- **Порты в сторону фильтров** — подключены к фильтрам для передачи трафика на обработку. + +Порты внутри каждой группы объединяются в **пары** LAN + WAN и далее — в логические сущности, называемые **линками**. + +```text + Оборудование оператора (через байпасы) + │ │ │ │ + P42(L) P41(W) P10(L) P9(W) + └─────┬─────┘ └─────┬─────┘ + Линк 1 Линк 2 + (10G) (100G) + │ │ + ┌───────────┴─────────────────────┴──────────┐ + │ Балансировщик │ + │ │ + │ Flow rules → Balance Group │ + └───┬─────┬─────┬──────────┬─────┬─────┬─────┘ + P21(L) P22(W) P31(L) P32(W) P41(L) P42(W) + └──┬──┘ └──┬──┘ └──┬──┘ + Filter Group 1 Filter Group 2 Filter Group 3 + │ │ │ + Фильтр 1 Фильтр 2 Фильтр N +``` + +### 4.3.1. Принцип чётных/нечётных портов + +По договорённости, принятой при проектировании, на балансировщике соблюдается тот же принцип, что и на фильтрах: + +- **Чётные** порты — **LAN** (в сторону абонентов); +- **Нечётные** порты — **WAN** (в сторону интернета). + +Например: порт P42 (чётный) — LAN-порт, парный ему P41 (нечётный) — WAN-порт. Для 100-гигабитных портов, у которых нет второй цифры (номера линии), определяющей является единственная цифра: P10 (чётный) — LAN, P9 (нечётный) — WAN. + +Этот принцип распространяется как на порты в сторону операторского оборудования, так и на порты в сторону фильтров. + +### 4.3.2. Жёсткая привязка: трафик возвращается в тот же линк + +Трафик, пришедший через конкретный порт оператора, **обязательно возвращается** через парный порт того же линка. Пакет, вошедший через P42 (LAN), после обработки выйдет только через P41 (WAN) — и никуда больше. Аналогично, пакет из P41 вернётся только в P42. + +Это фундаментальное правило обеспечивает **прозрачность ТСПУ** для сети оператора: если оператор отправил пакет в конкретный канал, ТСПУ вернёт его обратно в тот же канал, независимо от того, каким фильтром пакет был обработан. + +Механизм реализации: при балансировке к пакету добавляется 4-байтовый заголовок, который, помимо информации о ядре фильтра, содержит идентификатор исходного линка. Когда фильтр возвращает обработанный пакет с этим заголовком, балансировщик по нему определяет, в какой операторский линк вернуть пакет. + +## 4.4. Фильтры на балансировщике (Flow rules) + +Перед отправкой трафика на фильтры балансировщик пропускает каждый пакет через **правила фильтрации** (flow rules). Каждое правило состоит из двух частей: + +- **Match** — условие совпадения (по каким критериям определять трафик); +- **Action** — действие (что делать с совпавшим трафиком). + +Правила привязываются к **линкам** в сторону оператора и обрабатываются в порядке **приоритетов**. + +### 4.4.1. Байпас служебного трафика (BGP, мультикаст, маршрутизация) + +Действие `action bypass` позволяет указать, что совпавший трафик должен быть **немедленно возвращён** в сторону оператора, минуя фильтры. Это используется для служебного трафика: + +- **BGP** (TCP-порт 179) — протоколы маршрутизации; +- **Мультикаст-трафик** — групповые рассылки; +- **Другие служебные протоколы**, которые нежелательно пропускать через DPI. + +С таким трафиком на фильтрах ничего плохого не произойдёт (он будет прозрачно пропущен), но лучше его не трогать — это снижает нагрузку на фильтры и исключает потенциальное влияние. + +Типичная конфигурация: все правила для конкретного трафика задаются с высоким приоритетом и действием `bypass`, а в самом конце ставится правило-«заглушка» с самым низким приоритетом, без условий совпадения и с действием `bypass`. Таким образом, **всё, что не попало** под явные правила отправки на фильтры, **байпасится**. + +### 4.4.2. Отправка трафика на группу балансировки + +Действие `action balancing s_mac` отправляет совпавший трафик в указанную **группу балансировки** (balance group) для распределения по фильтрам. Параметр `s_mac` означает балансировку по source IP, destination IP и протоколу. + +Пример правила: «все пакеты с VLAN ID = 1 отправить на группу балансировки `group_filter`». Трафик конкретного VLAN будет обработан фильтрами, а весь остальной трафик, не попавший под это правило, — байпасится. + +Условия совпадения (match) могут включать: + +| Критерий | Описание | +| --------------- | ------------------------------------------- | +| **VLAN ID** | Номер VLAN-тега (один или несколько) | +| **IPv4 src/dst**| Адрес или подсеть источника/назначения | +| **L4 port** | Порт TCP/UDP | +| **MAC-адрес** | Source или destination MAC | +| **MPLS** | Количество MPLS-меток | +| **Глубина тегов**| Количество VLAN-тегов в пакете | + +В одном правиле можно комбинировать несколько условий (например, VLAN + IPv4-подсеть). Матчить можно как для включения трафика в обработку, так и наоборот — для исключения. + +## 4.5. Балансировка трафика + +### 4.5.1. Хэш-сумма: source IP + destination IP + протокол + +Балансировка трафика по фильтрам выполняется на основе **хэш-суммы**, вычисляемой по трём параметрам IP-пакета: + +1. **Source IP** — адрес источника; +2. **Destination IP** — адрес назначения; +3. **IP-протокол** — номер протокола (TCP, UDP и т.д.). + +Для вычисления хэша балансировщик разбирает стек заголовков инкапсуляции (VLAN-теги, MPLS-метки) и добирается до IP-заголовка. Если IP-пакет не обнаружен, трафик **прозрачно пропускается** (байпасится), не отправляясь на фильтры. + +Балансировка работает эффективно за счёт **огромного количества сессий** в реальном операторском трафике. Произведение количества source IP × destination IP × протоколов даёт число, достаточное для равномерного распределения по всем фильтрам и ядрам. Однако одну единственную сессию (один source IP, один destination IP, один протокол) **разбалансировать невозможно** — весь её трафик попадёт на один фильтр и одно ядро. + +### 4.5.2. Учёт количества ядер фильтров + +Параметр **N_UNIT_QA** на балансировщике задаёт количество ядер на подключённых фильтрах, которые занимаются обработкой трафика. Это значение **всегда равно общему количеству ядер процессора фильтра минус один**, поскольку одно ядро является сервисным — на нём работает ОС Linux, системные логи, управление. Все остальные ядра отданы процессу EcoNAT для обработки трафика. + +Параметр N_UNIT_QA **напрямую влияет** на балансировку: он учитывается при вычислении хэша, чтобы трафик равномерно распределялся не только между фильтрами, но и между **ядрами** каждого фильтра. + +### 4.5.3. Дополнительный 4-байтный заголовок для фильтров + +В точке балансировки к пакету добавляется **дополнительный 4-байтовый заголовок**. По структуре он похож на VLAN-тег, но VLAN-тегом не является. Этот заголовок выполняет две функции: + +1. **Для фильтра** — сообщает, на какое ядро направить данный пакет для обработки; +2. **Для балансировщика** — при возврате обработанного пакета от фильтра определяет, в какой операторский линк вернуть пакет. + +Фильтр после обработки возвращает пакет **с тем же 4-байтовым заголовком**. Балансировщик считывает заголовок, определяет исходный линк, удаляет заголовок и отправляет пакет обратно оператору. + +### 4.5.4. Симметричность хэша: одна сессия — один фильтр, одно ядро + +Хэш-функция балансировщика **симметрична**: при вычислении хэша для обратного пакета (от интернета к абоненту) source и destination IP меняются местами, но итоговая хэш-сумма совпадает с прямым пакетом. + +Это гарантирует: + +- оба направления одной сессии **всегда попадают на один и тот же фильтр**; +- более того — на одно и то же **ядро** этого фильтра; +- сессия **никогда не распределяется** по разным фильтрам. + +Благодаря этому фильтр всегда видит полную картину сессии (и запрос, и ответ), что критически важно для корректной работы DPI-анализа. Сессию любого абонента можно найти на одном конкретном фильтре. + +Важно: балансировщик **не ведёт логов** о том, куда отправил конкретный пакет — вся обработка происходит на аппаратном уровне. Чтобы найти, на каком фильтре «приземлилась» конкретная сессия, необходимо **обойти все фильтры** площадки. При 2–3 фильтрах это делается вручную; при большем количестве (до 15) — автоматизируется скриптом. + +## 4.6. Отказоустойчивость + +### 4.6.1. Keep-alive пакеты к фильтрам + +Балансировщик непрерывно контролирует доступность фильтров, отправляя **keep-alive пакеты** через каждую пару портов (filter group) в сторону фильтров. + +Принцип работы: + +1. Балансировщик отправляет keep-alive через **LAN-порт** filter group; +2. Пакет проходит через фильтр (заворачивается на первой проверке, т.к. не является IP-пакетом); +3. Пакет возвращается через парный **WAN-порт**; +4. Балансировщик фиксирует **время прохождения** (time of pass) — в штатном режиме порядка 27 микросекунд. + +Параметры keep-alive настраиваются в **профиле проверки доступности** (availability profile): + +| Параметр | Описание | +| ---------------------------- | ---------------------------------------------------------- | +| **Начальная задержка** | Время ожидания после старта перед началом отправки | +| **Интервал** | Периодичность отправки (типично ~100 мс) | +| **Порог потерь** | Число потерянных пакетов для признания группы неактивной (типично 5) | +| **Порог восстановления** | Число успешных пакетов для восстановления активности | +| **Мин. количество активных пар** | Порог, ниже которого вся balance group считается неактивной | + +Keep-alive пакеты проверяют не только физическую доступность канала, но и **работоспособность фильтра** в целом: если «мозг» фильтра завис или перегружен настолько, что не может обрабатывать даже не-IP-пакеты, keep-alive не вернётся, и балансировщик это обнаружит. + +### 4.6.2. Программный байпас при потере группы портов + +При потере keep-alive пакетов для конкретной filter group балансировщик переводит эту группу в состояние **программного байпаса**: трафик, предназначенный для данной пары портов, **не отправляется на фильтр**, а заворачивается обратно с LAN-порта на WAN-порт (и наоборот) непосредственно на балансировщике. + +Ключевые особенности: + +- Программный байпас применяется **индивидуально** к каждой filter group — остальные группы продолжают работать; +- Переключение **не вызывает флапов** линков оператора — оператор ничего не заметит; +- Единственное последствие — часть трафика временно перестаёт фильтроваться; +- При восстановлении доступности фильтра группа **автоматически возвращается** в активное состояние. + +Это значительное улучшение по сравнению с пилотным проектом на Урале, где потеря хотя бы одного интерфейса приводила к переключению **всей площадки** на байпас с флапами линков у оператора. + +Программный байпас можно также включить **вручную** — для диагностики или при проведении технических работ. Существует возможность перевести все фильтры в режим программного байпаса одной командой, полностью исключив ТСПУ из обработки трафика без влияния на оператора. + +### 4.6.3. Перебалансировка трафика (опционально) + +Альтернативой программному байпасу является **перебалансировка** трафика на оставшиеся рабочие filter group. Эта возможность настраивается в профиле проверки доступности, но, как правило, **отключена** по следующим причинам: + +- Перебалансировка **занимает время** и вычислительные ресурсы; +- Происходит **пересчёт хэша** для всех сессий — сессии могут попасть на другие фильтры; +- Существующие сессии на «старых» фильтрах **разрываются** (фильтр теряет контекст сессии); +- В общем случае это может быть **нежелательно**. + +Рекомендуемый подход для федерального проекта: программный байпас на уровне отдельной filter group без перебалансировки. Часть трафика временно не фильтруется — это меньшее зло, чем перерыв в работе всей площадки или разрыв всех сессий. + +## 4.7. Работа с различными инкапсуляциями (VLAN, MPLS) + +Балансировщик **не снимает и не модифицирует** никакие теги, метки и заголовки инкапсуляции. Вся обработка ограничивается **чтением** заголовков: + +- **VLAN-теги** — могут использоваться в условиях match для правил фильтрации (например, байпас служебного VLAN); +- **MPLS-метки** — балансировщик может определить их наличие и количество, но матчить по конкретным значениям MPLS-меток не имеет практического смысла; +- **QinQ** (двойные VLAN-теги) — поддерживается чтение с учётом глубины тегов. + +Для вычисления хэша балансировщик **разбирает весь стек** инкапсуляции и добирается до IP-заголовка. Это облегчает работу фильтра, у которого ограничения на типы инкапсуляции несколько строже. + +Пакет передаётся на фильтр **в неизменном виде** (с добавлением только 4-байтового заголовка балансировки). Все VLAN-теги, MPLS-метки и прочие заголовки сохраняются. + +## 4.8. Обработка HTTP-редиректов и TCP Reset через фильтры + +При блокировке ресурсов фильтру необходимо отправить абоненту **HTTP-редирект** (код 302, перенаправление на страницу-заглушку) или **TCP Reset** (для HTTPS-трафика). Особенность связана с тем, что канал между балансировщиком и фильтром фактически **однонаправленный** с точки зрения конкретного порта. + +Если трафик содержит MPLS-метки или другую инкапсуляцию, фильтр не может самостоятельно сгенерировать ответный пакет с правильными заголовками. Поэтому используется следующая логика: + +1. Пакет от абонента в сторону интернет-ресурса **пропускается** как есть; +2. Фильтр **ожидает обратный пакет** от интернет-ресурса в рамках той же сессии; +3. Когда обратный пакет приходит (уже с корректными MPLS-метками и заголовками), фильтр **подменяет** его содержимое на HTTP-редирект или TCP Reset; +4. Модифицированный пакет отправляется абоненту с сохранением всей инкапсуляции. + +Для **HTTP** — подставляется редирект на страницу-заглушку. Для **HTTPS** — отправляется TCP Reset (так как содержимое зашифровано и подмена невозможна). В обоих случаях механизм одинаков: дождаться ответа сервера и подменить пакет. + +--- + +[← Оглавление](index.md) · [← Раздел 3: Байпас](03.md) · [Раздел 5: Фильтр →](05.md) diff --git a/index.md b/index.md new file mode 100644 index 0000000..ed8e513 --- /dev/null +++ b/index.md @@ -0,0 +1,350 @@ +# ТСПУ: Технические средства противодействия угрозам + +Полное руководство на основе [лекции по архитектуре, настройке и эксплуатации ТСПУ](https://www.youtube.com/watch?v=raNP3IMgwRU) + +## Оглавление + +### [1. Введение и общая архитектура АСБИ](/01.md) + +- 1.1. Что такое АСБИ (Автоматизированная система обеспечения безопасности интернета) +- 1.2. Закон о суверенном интернете и участники проекта (ГУП ГРЧЦ, АО ДЦА, RDP.ru) +- 1.3. Что такое ТСПУ — комплекс оборудования у операторов связи +- 1.4. Общая схема: байпасы, балансировщики, фильтры, сегмент управления + +### [2. Прохождение трафика через ТСПУ](/02.md) + +- 2.1. Стык оператора связи: типы инкапсуляции (VLAN, QinQ, MPLS, PPPoE) +- 2.2. Разделение на LAN-порты (абоненты) и WAN-порты (интернет) +- 2.3. Простейший вариант ТСПУ (один байпас, один фильтр) +- 2.4. Типовая схема ТСПУ + +### [3. Байпас (Bypass)](/03.md) + +- 3.1. Назначение и роль байпаса в ТСПУ +- 3.2. Байпасы Silicom (федеральный проект) + - 3.2.1. Порты: Net0/Net1 (оператор) и Mon0/Mon1 (балансировщик) + - 3.2.2. Режим Inline — основной рабочий режим + - 3.2.3. Режим TAP — копирование трафика без влияния на оператора + - 3.2.4. Режим Active Bypass — замыкание без копирования + - 3.2.5. Режим Power-off Bypass — аварийное замыкание при обесточивании + - 3.2.6. Переключение между режимами и влияние на оператора +- 3.3. Байпасы GL Sun (пилотный проект, Урал) + - 3.3.1. Отличие от Silicom: только режим Power-off Bypass + - 3.3.2. Флап линков при каждом переключении +- 3.4. Мониторинг каналов: Heartbeat-пакеты байпаса +- 3.5. Автоматическое переключение в TAP/Active Bypass при потере канала + +### [4. Балансировщик (EcoFilter Balancer)](/04.md) + +- 4.1. Назначение: распределение трафика по фильтрам +- 4.2. Аппаратная платформа: 32-портовый, 1U, пропускная способность 3.2 Тбит/с +- 4.3. Организация портов: пары LAN/WAN, линки + - 4.3.1. Принцип чётных/нечётных портов + - 4.3.2. Жёсткая привязка: трафик возвращается в тот же линк +- 4.4. Фильтры на балансировщике (Flow rules) + - 4.4.1. Байпас служебного трафика (BGP, мультикаст, маршрутизация) + - 4.4.2. Отправка трафика на группу балансировки +- 4.5. Балансировка трафика + - 4.5.1. Хэш-сумма: source IP + destination IP + протокол + - 4.5.2. Учёт количества ядер фильтров + - 4.5.3. Дополнительный 4-байтный заголовок для фильтров + - 4.5.4. Симметричность хэша: одна сессия — один фильтр, одно ядро +- 4.6. Отказоустойчивость + - 4.6.1. Keep-alive пакеты к фильтрам + - 4.6.2. Программный байпас при потере группы портов + - 4.6.3. Перебалансировка трафика (опционально) +- 4.7. Работа с различными инкапсуляциями (VLAN, MPLS) +- 4.8. Обработка HTTP-редиректов и TCP Reset через фильтры + +### 5. Фильтр (EcoFilter) + +- 5.1. Путь пакета через фильтр + - 5.1.1. Проверка: IP-пакет или нет + - 5.1.2. Проверка по ACL (привязка к пулу) + - 5.1.3. Проверка по DPI-листу (IP-подсети) + - 5.1.4. Обработка движком DPI + - 5.1.5. Решение: пропустить или заблокировать (drop) +- 5.2. Работа на уровне L2: фильтр как «прозрачный провод» + +### 6. Места установки ТСПУ в сети оператора + +- 6.1. До BRAS/BPE/BNG (между абонентами и терминацией сессий) + - 6.1.1. Особенность: PPPoE-трафик +- 6.2. До CGNAT (после BRAS) — наиболее удобная точка + - 6.2.1. Видимость серых абонентских IP-адресов +- 6.3. После CGNAT (ближе к выходу в интернет) + - 6.3.1. Только белые адреса, сложности траблшутинга +- 6.4. Режим On-a-stick (BRAS/CGNAT подключены петлёй) + - 6.4.1. Двойное прохождение трафика через ТСПУ + - 6.4.2. Разделение по VLAN для обработки трафика одного направления + - 6.4.3. Проблемы двойной обработки и best practice + +### 7. Эшелонированная система (ТСПУ тип Б) + +- 7.1. Назначение: обработка трафика, не прошедшего через ТСПУ тип А +- 7.2. Проблема асимметричного трафика у крупных операторов +- 7.3. Балансировщик Eco Highway + - 7.3.1. BGP-загрузка списков фильтрации из ЦСУ + - 7.3.2. Блокировка по IP-адресам на уровне балансировщика (Telegram, реестр РКН) + - 7.3.3. Фильтры в режиме On-a-stick, VLAN-разделение LAN/WAN + - 7.3.4. Фильтры занимаются только URL-фильтрацией по реестру РКН +- 7.4. Два конвейера (Pipeline) в Eco Highway + - 7.4.1. Разделение портов между конвейерами + - 7.4.2. Физическая перемычка между конвейерами + - 7.4.3. Прохождение пакета: drop / отправка на фильтр / переход на второй конвейер + - 7.4.4. Удвоение количества правил фильтрации +- 7.5. Отличия EcoFilter Balancer от Eco Highway +- 7.6. Отсутствие логирования на Eco Highway (только real-time) +- 7.7. Прозрачный пропуск трафика, уже обработанного ТСПУ тип А + +### 8. Формирование протокольных списков (двухстадийная блокировка) + +- 8.1. Первый этап: распознавание протоколов на фильтрах (ТСПУ тип А) +- 8.2. Отправка логов на SPFS (сервер предварительного формирования списков) +- 8.3. Передача логов по GRPC в центральную систему управления +- 8.4. Анализ, очистка от ложных срабатываний, формирование списков +- 8.5. Загрузка очищенных списков обратно на фильтры (HTTP) и на Eco Highway (BGP) +- 8.6. Время полного цикла блокировки: ~5–15 минут + +### 9. Центральная система управления (ЦСУ) + +- 9.1. Архитектура: две независимые площадки (основная и резервная) +- 9.2. Связь с ТСПУ через VPN (криптошлюз «Континент») +- 9.3. Масштаб: ~350 площадок, ~5000 устройств +- 9.4. Подсистемы ЦСУ: формирование списков, мониторинг, логирование, картография +- 9.5. Новая ЦСУ для федерального проекта (замена уральской) + +### 10. Сегмент управления ТСПУ + +- 10.1. Адресация: 10.<регион>.<площадка>.0/24 +- 10.2. Распределение адресов: байпасы, балансировщики, BMC, фильтры, IPMI, SPFS, СПХД +- 10.3. Шлюз по умолчанию — криптошлюз «Континент» +- 10.4. Подсеть логирования (единая для всех ТСПУ) + +### 11. Фильтр: аппаратная платформа + +- 11.1. Младшая линейка: EcoFilter 2020/2040 +- 11.2. Старшая линейка: EcoFilter 4080/4120/4160 +- 11.3. Модели 2019 года (пилотный проект, Урал) + - 11.3.1. Процессоры Intel Xeon 2695/2699, 18/22 ядра, 128/256 ГБ RAM + - 11.3.2. Фиксированные сетевые интерфейсы +- 11.4. Модели 2020 года (федеральный проект) + - 11.4.1. Процессор Intel Xeon Gold 6212, 24 ядра, 192/384 ГБ RAM + - 11.4.2. Сменные сетевые интерфейсы, 4× SFP+ лог-порта +- 11.5. Разделение интерфейсов: LAN (чётные) / WAN (нечётные) +- 11.6. История платформы: от CGNAT (2013) к DPI-фильтру + +### 12. Сессии и трансляции на фильтре + +- 12.1. Понятие сессии: local IP:port + global IP:port + remote IP:port +- 12.2. Понятие трансляции: local IP:port ↔ global IP:port +- 12.3. Режим без NAT: local = global +- 12.4. Направление сессии: Egress (от абонента) / Ingress (к абоненту) +- 12.5. Принцип: локальный IP абонента всегда на первом месте +- 12.6. Связь трансляций и сессий: одна трансляция — много сессий +- 12.7. Тайм-ауты сессий и трансляций +- 12.8. Команды: `show session`, `show xl`, фильтрация по `local`/`remote`, pipe и count + +### 13. Фильтр: первоначальная настройка и CLI + +- 13.1. Подключение: консоль (115200 8N1) и SSH (порт 22) +- 13.2. Логин по умолчанию: admin / econat +- 13.3. Операционный режим (>) и конфигурационный режим (#) +- 13.4. Навигация по дереву конфигурации: system, pools, access-lists + - 13.4.1. Переход в раздел, exit (..), root (/) + - 13.4.2. Автодополнение (Tab), история команд (↑↓), справка (?) +- 13.5. Применение конфигурации: `apply`, сохранение: `wr` +- 13.6. Управление конфигурациями: save, load, copy, clear config +- 13.7. Одновременная работа двух пользователей: ограничения +- 13.8. «Мышеловка» (trap mode) при незакрытой скобке +- 13.9. Ключевое слово `ls` для быстрого просмотра + +### 14. Фильтр: конфигурация подсистем + +- 14.1. Консольный порт: скорость, тайм-аут неактивности +- 14.2. Management-интерфейс: IP, gateway, DNS, allowed IP + - 14.2.1. Добавление/удаление записей: `+=` и `-=` +- 14.3. Терминал (SSH): auto-logout, prompt, нумерация строк + - 14.3.1. Лимит сессий (20), опасность `never` для auto-logout +- 14.4. Пользователи: создание, удаление, уровни доступа, пароли (secret 0 / 15) +- 14.5. TACACS+: авторизация, fallback на локальную базу +- 14.6. NTP: до 3 серверов, период обновления +- 14.7. SNMP: community (read-only), traps, allow-ip +- 14.8. Системное журналирование (syslog) + - 14.8.1. Внешние лог-серверы (до 2), hostname, time shift + - 14.8.2. Уровни логирования по подсистемам (1=ошибки, 2=предупреждения, 3=информация) + - 14.8.3. Подсистема `all` — максимальный уровень для всех + - 14.8.4. Логирование команд пользователя (уровень fatal) + - 14.8.5. SNMP traps: только уровень fatal +- 14.9. Журналирование соединений (connection log) — через лог-интерфейс (DPDK) +- 14.10. Журналирование протоколов (debug logger) — отправка на SPFS + - 14.10.1. Выбор протоколов (all / конкретные) + - 14.10.2. Количество пакетов на протокол (по умолчанию 30, рекомендуется 3) + +### 15. Фильтр: настройка интерфейсов и общих параметров + +- 15.1. Интерфейсы: enable/disable, description (LACP не используется) +- 15.2. NAT Defaults — общие параметры устройства + - 15.2.1. **VLAN Mode**: untag / vlan / QinQ — глубина поиска IP-заголовка (всегда QinQ) + - 15.2.2. Sessions per Translation (по умолчанию 4096) + - 15.2.3. **Forward Traffic**: всегда ON + - 15.2.4. **L2 MTU**: максимум 9216 (по RFC) + - 15.2.5. **LLDP**: выключен (требование операторов — прозрачность) + - 15.2.6. **Permit Invalid Flow**: всегда ON — приём TCP-сессий без SYN +- 15.3. Тайм-ауты сессий и трансляций +- 15.4. IPv6: включение, диапазон адресов для обработки + +### 16. Фильтр: ACL и пулы — запуск трафика на обработку + +- 16.1. Создание ACL: `create acl`, правила (allow/deny), протоколы, source/destination, VLAN +- 16.2. Создание пула: `create pool`, тип = fake (без NAT) +- 16.3. Привязка ACL к пулу +- 16.4. Приоритет пулов +- 16.5. Connection logging в пуле +- 16.6. IPv6 в пуле + +### 17. Фильтр: настройка DPI + +- 17.1. Общие настройки модуля DPI + - 17.1.1. Включение/выключение DPI + - 17.1.2. **Send RST off**: отключение TCP Reset при блокировке протоколов + - 17.1.3. Functionality mode: normal (не double mirror traffic) +- 17.2. Настройка реестра РКН + - 17.2.1. Источник: RKN или GRFЦ + - 17.2.2. Логин/пароль для доступа к серверу РКН + - 17.2.3. Привязка к DPI-листу (list number) + - 17.2.4. Proxy-сервер, dump server + - 17.2.5. Проблемы скачивания: минимальная скорость ~10 Мбит/с +- 17.3. Деградация протоколов (protocols capacity) + - 17.3.1. Шкала 0–100: 0 = полная блокировка, 100 = полный пропуск + - 17.3.2. Дроп пакетов с заданной вероятностью + - 17.3.3. Эффективная деградация: 2–10% пропускания + - 17.3.4. Влияние на голосовые вызовы и мессенджеры +- 17.4. Настройка DPI-листов (0–16) + - 17.4.1. Enable/disable каждого листа + - 17.4.2. BitTorrent UTP detection + - 17.4.3. WH List Mode: blacklist (по умолчанию) / whitelist + - 17.4.4. **Behavior**: block / ignore / color / redirect + - 17.4.5. Redirect URL — страница-заглушка для заблокированных HTTP-ресурсов + - 17.4.6. Download URL — источник списков, update schedule + - 17.4.7. Protocols — список распознаваемых протоколов + - 17.4.8. **No IP** / **IP** — исключение/включение адресов для обработки + - 17.4.9. QUIC list +- 17.5. Формат списков фильтрации + - 17.5.1. IP-адреса, подсети, диапазоны, URL + - 17.5.2. HTTP: блокировка конкретного URL + - 17.5.3. HTTPS: блокировка только по домену (SNI/Client Hello) + +### 18. Фильтр: мониторинг и диагностика + +- 18.1. `show version` — версия ПО, серийный номер (= MAC management) +- 18.2. `show ip if` — параметры management-интерфейса +- 18.3. `show time` — текущее время (UTC / local) +- 18.4. `show uptime` — время работы платформы и процесса EcoNAT +- 18.5. Аппаратная часть: `show power`, `show fan`, `show temperature` +- 18.6. Интерфейсы: `show interface brief`, traffic monitor, трансиверы (DDM) +- 18.7. Ресурсы: `show resources` + - 18.7.1. Таблицы сессий/трансляций: не более 20% загрузки + - 18.7.2. Свободные буферы: не должны уходить в ноль + - 18.7.3. DPI-ресурсы: не более 100% + - 18.7.4. CPU Load — условный параметр обработки трафика +- 18.8. Память: Control Plane vs Data Plane + - 18.8.1. Data Plane выделяется при старте, не должна расти + - 18.8.2. Пороги: 5–10% свободной памяти — повод для тревоги +- 18.9. `show cps` — скорость создания новых сессий +- 18.10. `show statistic` — статистика сессий и пулов, значение Optimal (= 20%) +- 18.11. Счётчики: `show counters all` / `show counters div` (дельта за секунду) +- 18.12. Системный журнал: `show syslog`, ротация двух файлов +- 18.13. DPI-мониторинг + - 18.13.1. `show dpi records ` — содержимое DPI-листа + - 18.13.2. `show dpi state` — количество записей, дата последнего дампа + - 18.13.3. `dpi load ` — ручная загрузка списка + - 18.13.4. `dpi run` — принудительное обновление всех списков + - 18.13.5. `show dpi match <ресурс>` — проверка ресурса по всем DPI-листам +- 18.14. Ping и Traceroute (из конфигурационного режима) + +### 19. Фильтр: обновление прошивки + +- 19.1. Два раздела: prim1 и prim2 (равнозначные) + FB (заводская) +- 19.2. `firmware status` — текущее состояние (cur / boot) +- 19.3. `firmware download` — скачивание, `firmware install` — установка +- 19.4. `firmware rollback` / `firmware reset` +- 19.5. Централизованное обновление через ЦСУ + +### 20. Балансировщик: аппаратная платформа + +- 20.1. Одноюнитовый (32 порта QSFP28) и двухюнитовый (65 портов) +- 20.2. Скорости портов: 10G / 25G / 100G +- 20.3. Гидры (breakout): один QSFP28 → четыре SFP+ (10G) +- 20.4. Внутренняя архитектура + - 20.4.1. Микросервер (Intel, Linux) — CLI, конфигурация + - 20.4.2. Чип Barefoot Tofino — программируемая коммутация + - 20.4.3. BMC — управление аппаратной частью, сенсоры, блоки питания + - 20.4.4. Ethernet switch (5-портовый) — доступ к микросерверу и BMC + - 20.4.5. Console MUX — переключение консоли между компонентами +- 20.5. Передняя панель: Console, Management Ethernet, USB + +### 21. Балансировщик: конфигурация + +- 21.1. CLI: операционный режим / конфигурационный режим (`edit`) + - 21.1.1. Интерфейс похож на Juniper CLI + - 21.1.2. `apply` — применить, `save` — сохранить в startup +- 21.2. Обновление прошивки: `call rdp firmware download` / `call rdp install` + - 21.2.1. Два раздела прошивок (A/B), автоматический rollback (3 попытки / 20 мин) + - 21.2.2. `call rdp firmware reset-tries` +- 21.3. Настройка физических портов + - 21.3.1. Имя порта, номер физического порта (number), линия (lane), скорость (speed) + - 21.3.2. 10G: указание lane (0–3), 100G: все lane задействованы +- 21.4. Настройка линков (объединение двух портов LAN+WAN в сторону оператора) +- 21.5. Настройка группы балансировки + - 21.5.1. Привязка групп портов в сторону фильтров (filter groups) + - 21.5.2. N_UNIT_QA: количество ядер фильтра минус один +- 21.6. Профиль проверки доступности (keep-alive) + - 21.6.1. Начальная задержка, интервал, порог потерь + - 21.6.2. Минимальное количество активных пар + - 21.6.3. Перебалансировка: включение/выключение +- 21.7. Настройка фильтров (Flow rules) + - 21.7.1. Match-условия: VLAN, IPv4 src/dst, L4 port, MAC, MPLS, глубина тегов + - 21.7.2. Actions: `balancing s_mac` → balance group / `bypass` + - 21.7.3. Приоритеты правил + - 21.7.4. Привязка фильтров к линкам +- 21.8. Настройка Heartbeat для GL Sun (пилотный проект) +- 21.9. Management-интерфейс: IP, маска, default gateway + +### 22. Балансировщик: мониторинг и диагностика + +- 22.1. `show hardware info` — CPU, память, вентиляторы, БП, температура +- 22.2. `show mng if` — management-интерфейс +- 22.3. `show rdp firmware version` — версии прошивок, tries +- 22.4. Состояние портов и трансиверов: SFP-информация, DDM, статистика фреймов +- 22.5. Статистика правил фильтрации: счётчики пакетов/байт по каждому flow +- 22.6. Состояние группы балансировки + - 22.6.1. Статус filter groups: up/bypass + - 22.6.2. Time of pass — время прохождения keep-alive пакета +- 22.7. Программный байпас: индивидуально для каждой группы портов + +### 23. Распознавание протоколов (DPI Engine) + +- 23.1. Многофакторный анализ сессий + - 23.1.1. Размеры пакетов и их вариации + - 23.1.2. Частота прохождения пакетов + - 23.1.3. Ключевые слова и паттерны внутри пакетов + - 23.1.4. Особенности анализа шифрованного трафика +- 23.2. Ложноположительные срабатывания +- 23.3. Двухстадийная блокировка: распознавание → очистка в ЦСУ → блокировка +- 23.4. Обфускация и борьба с обходом блокировок + +### 24. Траблшутинг + +- 24.1. Общий подход к диагностике проблем доступности +- 24.2. Поиск сессии абонента: обход фильтров площадки +- 24.3. Проверка ресурса в DPI-листах: `show dpi match` +- 24.4. Программный байпас для исключения ТСПУ как причины проблемы +- 24.5. Исключение абонента из обработки: параметр No IP +- 24.6. Перепутки LAN/WAN и их диагностика +- 24.7. Взаимодействие с оператором связи +- 24.8. Ограничения: L2-устройство, невозможность генерации трафика с фильтра + +--- + +_Документ составлен на основе учебной лекции по архитектуре и эксплуатации ТСПУ (АСБИ)_