souce/tspu-docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

first commit

Browse Source
This commit is contained in:
Daniel Lavrushin
2026-02-20 11:58:48 +01:00
commit cba7581665
6 changed files with 1193 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
.gitignore vendored Normal file
View File

@@ -0,0 +1 @@
/tspu.txt

130
01.md Normal file
View File

@@ -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)

248
02.md Normal file
View File

@@ -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)

216
03.md Normal file
View File

@@ -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)

248
04.md Normal file
View File

@@ -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)

350
index.md Normal file
View File

@@ -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 <N>` — содержимое DPI-листа
- 18.13.2. `show dpi state` — количество записей, дата последнего дампа
- 18.13.3. `dpi load <N>` — ручная загрузка списка
- 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-устройство, невозможность генерации трафика с фильтра
---
_Документ составлен на основе учебной лекции по архитектуре и эксплуатации ТСПУ (АСБИ)_