Добавлены новые разделы:
- Раздел 22: Балансировщик: мониторинг и диагностика - Раздел 23: Распознавание протоколов (DPI Engine) - Раздел 24: Траблшутинг Каждый раздел включает команды, описания и практические примеры для диагностики и мониторинга работы балансировщика и системы фильтрации.
This commit is contained in:
Daniel Lavrushin
130
chapters/01.md
Normal file
130
chapters/01.md
Normal file
@@ -0,0 +1,130 @@
|
||||
# 1. Введение и общая архитектура АСБИ
|
||||
|
||||
[← Оглавление](../README.md)
|
||||
|
||||
---
|
||||
|
||||
## 1.1. Что такое АСБИ
|
||||
|
||||
**АСБИ** (Автоматизированная система обеспечения безопасности интернета) — это государственная система, создаваемая в рамках реализации закона о суверенном интернете. Её основная задача — обеспечить возможность анализа, фильтрации и управления интернет-трафиком на уровне операторов связи на всей территории Российской Федерации.
|
||||
|
||||
АСБИ представляет собой распределённую иерархическую систему, состоящую из:
|
||||
|
||||
- **ТСПУ** (технические средства противодействия угрозам) — комплексы оборудования, устанавливаемые непосредственно у операторов связи;
|
||||
- **Центральная система управления (ЦСУ)** — централизованная платформа для управления всеми ТСПУ, развёрнутая на двух физически независимых площадках с резервированием.
|
||||
|
||||
Все ТСПУ связаны с ЦСУ и управляются через неё. Именно через центральную систему управления выполняются основные операции по конфигурированию, мониторингу и обновлению оборудования ТСПУ.
|
||||
|
||||
## 1.2. Закон о суверенном интернете и участники проекта
|
||||
|
||||
Проект АСБИ реализуется в рамках **закона о суверенном интернете** (Федеральный закон № 90-ФЗ). В реализации проекта участвуют несколько ключевых организаций:
|
||||
|
||||
| Роль | Организация | Описание |
|
||||
| -------------------------- | --------------------------------------- | --------------------------------------------------------------------------------------------------------------- |
|
||||
| **Заказчик** | ГУП ГРЧЦ (Главный радиочастотный центр) | Представляет интересы государства |
|
||||
| **Генеральный подрядчик** | АО «ДЦА» | Осуществляет общее руководство проектом |
|
||||
| **Поставщик оборудования** | RDP.ru | Поставляет два типа устройств: **балансировщики** и **фильтры**, а также разрабатывает часть системы управления |
|
||||
|
||||
Проект развивался поэтапно:
|
||||
|
||||
- **Пилотный проект** — развёрнут на Урале, включает ограниченное количество площадок. Использует байпасы GL Sun и раннюю версию ЦСУ;
|
||||
- **Федеральный проект** — масштабное развёртывание по всей стране. Включает байпасы Silicom, новое оборудование фильтров (модели 2020 года), новую версию ЦСУ и эшелонированную систему фильтрации. На данном этапе предполагается порядка **350 площадок** и суммарно около **5 000 устройств**.
|
||||
|
||||
## 1.3. Что такое ТСПУ — комплекс оборудования у операторов связи
|
||||
|
||||
**ТСПУ** (Технические средства противодействия угрозам) — это комплекс оборудования, который устанавливается **в разрыв каналов связи оператора**. ТСПУ перехватывает проходящий трафик, анализирует его и при необходимости выполняет блокировку или деградацию определённых типов соединений.
|
||||
|
||||
Ключевой принцип работы ТСПУ — **прозрачность для оператора**. С точки зрения сетевой топологии оператора, ТСПУ представляет собой «прозрачный провод»: трафик, вошедший через определённый канал связи, обязательно возвращается в тот же канал. Оператор не должен вносить изменения в свою маршрутизацию при установке ТСПУ.
|
||||
|
||||
ТСПУ может устанавливаться в нескольких различных местах сети оператора (подробнее — в [разделе 6](06.md)), и на одной площадке оператора может быть развёрнуто различное количество оборудования в зависимости от объёма трафика и количества каналов связи.
|
||||
|
||||
Существует два типа ТСПУ:
|
||||
|
||||
- **ТСПУ тип А** (первый эшелон) — основной тип, устанавливается у большинства операторов. Когда говорят просто «ТСПУ» без уточнения, подразумевают именно тип А;
|
||||
- **ТСПУ тип Б** (второй эшелон, эшелонированная система) — устанавливается на уровне ядра сети крупных операторов для обработки трафика, который не прошёл через ТСПУ тип А (подробнее — в [разделе 7](07.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 в зависимости от модели.
|
||||
|
||||
### Типовая схема ТСПУ
|
||||
|
||||
В типовой конфигурации присутствуют все компоненты: несколько байпасов (по количеству каналов оператора), один или несколько балансировщиков и множество фильтров. Балансировщик принимает трафик от всех байпасов, распределяет его по фильтрам для обработки, после чего обработанный трафик возвращается через балансировщик и байпас обратно в сеть оператора.
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](../README.md) · [Раздел 2: Прохождение трафика через ТСПУ →](02.md)
|
||||
248
chapters/02.md
Normal file
248
chapters/02.md
Normal file
@@ -0,0 +1,248 @@
|
||||
# 2. Прохождение трафика через ТСПУ
|
||||
|
||||
[← Оглавление](../README.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-редирект или разрыв соединения срабатывает штатно.
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 1: Введение и общая архитектура АСБИ](01.md) · [Раздел 3: Байпас →](03.md)
|
||||
216
chapters/03.md
Normal file
216
chapters/03.md
Normal file
@@ -0,0 +1,216 @@
|
||||
# 3. Байпас (Bypass)
|
||||
|
||||
[← Оглавление](../README.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, в зависимости от настроек)
|
||||
```
|
||||
|
||||
Такое автоматическое переключение обеспечивает **защиту трафика оператора** без ручного вмешательства: если что-то случится с балансировщиком или фильтрами, каналы оператора будут замкнуты напрямую, и связность сети сохранится.
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 2: Прохождение трафика через ТСПУ](02.md) · [Раздел 4: Балансировщик →](04.md)
|
||||
248
chapters/04.md
Normal file
248
chapters/04.md
Normal file
@@ -0,0 +1,248 @@
|
||||
# 4. Балансировщик (EcoFilter Balancer)
|
||||
|
||||
[← Оглавление](../README.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 (так как содержимое зашифровано и подмена невозможна). В обоих случаях механизм одинаков: дождаться ответа сервера и подменить пакет.
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 3: Байпас](03.md) · [Раздел 5: Фильтр →](05.md)
|
||||
180
chapters/05.md
Normal file
180
chapters/05.md
Normal file
@@ -0,0 +1,180 @@
|
||||
# 5. Фильтр (EcoFilter)
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 4: Балансировщик](04.md)
|
||||
|
||||
---
|
||||
|
||||
## 5.1. Путь пакета через фильтр
|
||||
|
||||
Фильтр (EcoFilter) — это основное устройство ТСПУ, непосредственно выполняющее анализ и обработку трафика. Каждый пакет, поступающий на фильтр от балансировщика (или напрямую от байпаса в простейшей конфигурации), проходит через **последовательную цепочку проверок**. На каждом этапе пакет может быть либо пропущен дальше по цепочке, либо прозрачно возвращён обратно оператору без какой-либо обработки.
|
||||
|
||||
Общая схема пути пакета:
|
||||
|
||||
```text
|
||||
Пакет от балансировщика
|
||||
│
|
||||
▼
|
||||
┌─────────────────────┐
|
||||
│ 1. IP-пакет или нет │
|
||||
└────────┬────────────┘
|
||||
│ Не IP → прозрачный пропуск ──►
|
||||
▼
|
||||
┌─────────────────────┐
|
||||
│ 2. Проверка по ACL │
|
||||
│ (привязка к пулу) │
|
||||
└────────┬────────────┘
|
||||
│ Не попал в ACL → прозрачный пропуск ──►
|
||||
▼
|
||||
┌─────────────────────┐
|
||||
│ 3. Проверка по │
|
||||
│ DPI-листу (IP/сети) │
|
||||
└────────┬────────────┘
|
||||
│ Не попал в DPI-лист → прозрачный пропуск ──►
|
||||
▼
|
||||
┌─────────────────────┐
|
||||
│ 4. Обработка │
|
||||
│ движком DPI │
|
||||
└────────┬────────────┘
|
||||
│
|
||||
┌────┴────┐
|
||||
▼ ▼
|
||||
Пропустить Заблокировать
|
||||
(pass) (drop)
|
||||
```
|
||||
|
||||
На каждом этапе, если пакет не удовлетворяет условиям для дальнейшей обработки, он **прозрачно возвращается** через парный интерфейс обратно в сеть оператора — как будто фильтра в тракте нет.
|
||||
|
||||
Важно понимать, что даже самая первая проверка (является ли пакет IP-пакетом) выполняется **программным ядром фильтра** — процессом EcoNAT. Если «мозг» фильтра не работает (процесс завис или перегружен), даже эта простейшая проверка не будет пройдена, и keep-alive пакеты от балансировщика не вернутся. Именно поэтому keep-alive пакеты балансировщика проверяют не только физическую связность канала, но и работоспособность процесса обработки на фильтре (подробнее — в [разделе 4.6.1](04.md)).
|
||||
|
||||
### 5.1.1. Проверка: IP-пакет или нет
|
||||
|
||||
Первый этап — определение того, содержит ли входящий кадр (Ethernet-фрейм) IP-пакет. Фильтр разбирает стек заголовков инкапсуляции и ищет IP-заголовок.
|
||||
|
||||
В операторских сетях трафик может приходить в самых различных инкапсуляциях:
|
||||
|
||||
- чистый IP-пакет (нетегированный);
|
||||
- пакет с одним VLAN-тегом;
|
||||
- пакет с двумя VLAN-тегами (QinQ);
|
||||
- пакет с MPLS-метками;
|
||||
- пакет с MPLS-метками и VLAN-тегами;
|
||||
- PPPoE-пакет, дополнительно инкапсулированный в MPLS;
|
||||
- и другие комбинации.
|
||||
|
||||
Глубина поиска IP-заголовка определяется параметром **VLAN Mode** (подробнее — в [разделе 15.2.1](15.md)):
|
||||
|
||||
| Значение VLAN Mode | Поведение |
|
||||
| ------------------ | ------------------------------------------------------------ |
|
||||
| **untag** | IP-заголовок ищется только в нетегированных фреймах |
|
||||
| **vlan** | Поиск в нетегированных фреймах и фреймах с одним VLAN-тегом |
|
||||
| **QinQ** | Поиск во фреймах с любым количеством VLAN-тегов (0, 1 или 2) |
|
||||
|
||||
В проекте АСБИ параметр VLAN Mode **всегда должен быть установлен в QinQ**. Если установлено другое значение, часть трафика может проходить через фильтр прозрачно, без обработки — что приведёт к неработоспособности фильтрации.
|
||||
|
||||
Если IP-заголовок не обнаружен (например, пакет содержит только ARP, служебный протокол или keep-alive балансировщика), пакет **немедленно возвращается** через парный интерфейс. Именно по этому пути проходят keep-alive пакеты балансировщика — они не являются IP-пакетами и заворачиваются на первой же проверке, что позволяет измерить время прохождения через фильтр.
|
||||
|
||||
### 5.1.2. Проверка по ACL (привязка к пулу)
|
||||
|
||||
Если пакет содержит IP-заголовок, следующий этап — проверка по **ACL** (Access Control List), привязанному к **пулу**.
|
||||
|
||||
Пул — это логическая сущность на фильтре, в которую попадает трафик для дальнейшей обработки. В проекте АСБИ используются пулы типа **fake** — это означает, что реальная трансляция адресов (NAT) не выполняется: что пришло, то и ушло. Тем не менее пул должен быть создан и включён, поскольку без пула трафик не может попасть на обработку DPI.
|
||||
|
||||
К каждому пулу привязывается ACL — список правил, определяющих, какой трафик должен обрабатываться. Правила ACL могут матчить пакеты по:
|
||||
|
||||
- **протоколу** — IP, TCP, UDP, ICMP и др.;
|
||||
- **source/destination** — хост, подсеть или ключевое слово `any` (любой адрес);
|
||||
- **номеру VLAN** — если не указан, подразумеваются все VLAN (0–4095).
|
||||
|
||||
Каждое правило содержит действие **allow** (permit) или **deny**. Правила обрабатываются по порядку номеров, рекомендуется задавать номера с зазором (например, 10, 20, 30) для удобства последующего редактирования.
|
||||
|
||||
Если пакет **попал** (замэтчился) в ACL привязанного пула — он переходит на следующий этап проверки. Если **не попал** ни в один ACL ни одного пула — пакет прозрачно пропускается обратно в сеть оператора.
|
||||
|
||||
При наличии нескольких пулов трафик попадает в пул с **наивысшим приоритетом**, ACL которого совпал первым.
|
||||
|
||||
> **Важно:** при заводской (дефолтной) конфигурации фильтра пулы и ACL **отсутствуют**. Их необходимо создать при первоначальной настройке. Без созданного пула и привязанного ACL фильтр будет прозрачно пропускать весь трафик — какие бы настройки DPI-листов ни были заданы, обработка не произойдёт.
|
||||
|
||||
### 5.1.3. Проверка по DPI-листу (IP-подсети)
|
||||
|
||||
После прохождения ACL и попадания в пул пакет проверяется на уровне **DPI-листа**. DPI-лист — это набор правил фильтрации, содержащий списки IP-адресов, подсетей и URL для обработки. На фильтре может быть настроено **до 16 DPI-листов** (номера 0–15), каждый из которых может быть включён или выключен независимо.
|
||||
|
||||
В рамках DPI-листа определены **параметры IP**, которые задают, какой именно трафик подлежит обработке данным листом:
|
||||
|
||||
| Параметр | Описание |
|
||||
| ---------------------- | ----------------------------------------------------------------- |
|
||||
| **IP** | Подсети и адреса, которые должны обрабатываться данным DPI-листом |
|
||||
| **No IP** | Локальные адреса абонентов, исключённые из обработки |
|
||||
| **No IP Remote** | Удалённые адреса (серверы), исключённые из обработки |
|
||||
| **IPv6** / **No IPv6** | Аналогичные параметры для IPv6-трафика |
|
||||
|
||||
По умолчанию параметр IP должен содержать сеть `0.0.0.0/0` для всех VLAN — тогда весь трафик, попавший в DPI, будет обрабатываться данным листом. Параметр **No IP** используется, в частности, для диагностики: можно исключить конкретного абонента из обработки DPI-листом, чтобы проверить, влияет ли данный лист на его трафик.
|
||||
|
||||
Если пакет **не попал** в обработку ни одного активного DPI-листа (его адреса не совпали с заданными подсетями, или он исключён через No IP), он **прозрачно пропускается** дальше без какого-либо анализа.
|
||||
|
||||
Нулевой DPI-лист (`dpi list 0`) в проекте АСБИ всегда используется для **фильтрации по реестру Роскомнадзора**. Остальные листы (1–15) могут использоваться для других задач — например, для блокировки по очищенным протокольным спискам, загружаемым из ЦСУ (подробнее — в [разделе 8](08.md)).
|
||||
|
||||
### 5.1.4. Обработка движком DPI
|
||||
|
||||
Если пакет прошёл все предварительные проверки (IP → ACL/пул → DPI-лист), он передаётся на **движок DPI** (Deep Packet Inspection) для анализа. На платформе EcoFilter используется движок **ecDPI**, обеспечивающий фильтрацию по спискам и распознавание приложений вплоть до седьмого уровня модели OSI.
|
||||
|
||||
Движок DPI выполняет **многофакторный анализ сессий** по целому ряду параметров:
|
||||
|
||||
- **адреса и порты** — source IP, destination IP, source/destination port;
|
||||
- **размеры пакетов** и их вариации в рамках сессии;
|
||||
- **частота прохождения** пакетов;
|
||||
- **ключевые слова и паттерны** внутри пакетов;
|
||||
- **косвенные признаки** для шифрованного трафика (где очевидные поля протокола недоступны).
|
||||
|
||||
Анализ выполняется не над отдельным пакетом, а над **сессией** в целом — движок накапливает информацию о нескольких пакетах в рамках одного соединения и на основе совокупности признаков определяет тип трафика. Для шифрованного трафика (например, VPN-протоколы, мессенджеры) прямое определение по заголовкам невозможно, поэтому используются косвенные признаки: характерные размеры пакетов, частотные паттерны, статистические аномалии.
|
||||
|
||||
Результатом работы движка DPI является **определение протокола/приложения** и проверка по спискам фильтрации (URL, домены, IP-адреса). Дальнейшая судьба пакета определяется параметром **behavior** DPI-листа.
|
||||
|
||||
### 5.1.5. Решение: пропустить или заблокировать (drop)
|
||||
|
||||
По результатам анализа движком DPI фильтр принимает решение о судьбе пакета. Поведение задаётся параметром **behavior** в настройках каждого DPI-листа:
|
||||
|
||||
| Значение behavior | Описание |
|
||||
| ----------------- | ------------------------------------------------------------------------------ |
|
||||
| **block** | Трафик, совпавший со списком, блокируется (дропается) |
|
||||
| **ignore** | Совпадение регистрируется и логируется, но никаких действий не предпринимается |
|
||||
| **color** | Совпавший трафик «окрашивается» (в проекте АСБИ не используется) |
|
||||
| **redirect** | Трафик перенаправляется (в проекте АСБИ не используется) |
|
||||
|
||||
В рамках проекта АСБИ используются преимущественно два режима:
|
||||
|
||||
**Режим block** — основной рабочий режим для блокировки по реестру Роскомнадзора и по очищенным протокольным спискам. При срабатывании блокировки:
|
||||
|
||||
- Для **HTTP**-трафика абоненту отправляется **HTTP-редирект** (код 302) на страницу-заглушку оператора, информирующую о блокировке ресурса. URL страницы-заглушки задаётся параметром **redirect URL** в настройках DPI-листа.
|
||||
- Для **HTTPS**-трафика содержимое зашифровано, поэтому подмена ответа невозможна. Вместо этого абоненту и серверу отправляется **TCP Reset**, разрывающий соединение.
|
||||
- При наличии MPLS-меток или сложной инкапсуляции фильтр не может самостоятельно сгенерировать ответный пакет с корректными заголовками. Поэтому используется особая логика: пакет от абонента пропускается к серверу, фильтр **дожидается ответного пакета** в той же сессии, а затем **подменяет** его содержимое на редирект или TCP Reset, сохраняя оригинальные заголовки инкапсуляции (подробнее — в [разделе 4.8](04.md)).
|
||||
|
||||
**Режим ignore** — используется для **распознавания протоколов** без блокировки. Фильтр определяет тип трафика и отправляет логи на SPFS, но сам трафик пропускает. Это первая стадия двухступенчатой блокировки: на этом этапе собираются данные для ЦСУ, которая формирует очищенные от ложных срабатываний списки и загружает их в другой DPI-лист, уже работающий в режиме block (подробнее — в [разделе 8](08.md)).
|
||||
|
||||
Каждый DPI-лист также поддерживает переключение режима **blacklist / whitelist** (параметр **WH list mode**):
|
||||
|
||||
- **Blacklist** (по умолчанию) — всё, что совпало со списком, блокируется; всё остальное пропускается;
|
||||
- **Whitelist** — пропускается только совпавший трафик; всё остальное блокируется.
|
||||
|
||||
Режим whitelist в проекте АСБИ **не используется** из-за риска случайной блокировки всего трафика.
|
||||
|
||||
Отдельная проблема — **отправка TCP Reset при блокировке протоколов**. Если приложение абонента (например, мессенджер) получает TCP Reset при попытке установить соединение, оно немедленно пытается установить новое соединение — и делает это непрерывно с высокой частотой. Количество генерируемых сессий может быть огромным, создавая избыточную нагрузку на фильтр. Для решения этой проблемы предусмотрен параметр **send RST off**, отключающий отправку TCP Reset при блокировке протоколов (подробнее — в [разделе 17.1.2](17.md)).
|
||||
|
||||
## 5.2. Работа на уровне L2: фильтр как «прозрачный провод»
|
||||
|
||||
Несмотря на то, что фильтр анализирует IP-трафик вплоть до седьмого уровня модели OSI, с точки зрения **сетевой топологии** он работает на **уровне L2** (канальном уровне). Для внешнего наблюдателя — оператора связи, маршрутизаторов, коммутаторов — фильтр представляет собой **прозрачный провод**: пакет входит через один интерфейс и выходит через парный, без каких-либо видимых изменений на сетевом уровне.
|
||||
|
||||
Ключевые характеристики L2-работы фильтра:
|
||||
|
||||
**Отсутствие L3-интерфейсов в тракте данных.** На пути прохождения трафика у фильтра нет IP-интерфейсов. Если посмотреть на интерфейсы ОС Linux, на которой основано устройство, там виден только **management-интерфейс** (используемый для удалённого управления). Все остальные интерфейсы отданы под управление **DPDK** (Data Plane Development Kit) и процессу EcoNAT, который обрабатывает трафик напрямую, минуя сетевой стек операционной системы.
|
||||
|
||||
**Невозможность генерации трафика.** Фильтр — это L2-устройство, у которого нет IP-интерфейсов для инициирования трафика. Нельзя, например, выполнить ping с фильтра в сторону оператора через LAN/WAN-интерфейсы. Ping и traceroute возможны только через management-интерфейс (подробнее — в [разделе 18.14](18.md)).
|
||||
|
||||
**Сохранение всех заголовков инкапсуляции.** Фильтр не снимает и не модифицирует VLAN-теги, MPLS-метки и любые другие заголовки инкапсуляции. Все манипуляции выполняются **только с IP-пакетом** внутри стека заголовков. Пакет выходит из фильтра с теми же тегами и метками, с которыми он вошёл.
|
||||
|
||||
**Отключение LLDP.** Протокол LLDP (Link Layer Discovery Protocol) на фильтрах **выключен** по требованию операторов связи. Операторы не хотят видеть устройства ТСПУ в своей сетевой топологии — оборудование должно быть полностью прозрачным и невидимым. Если LLDP включён, устройство «появляется» на схемах сети оператора, что нежелательно.
|
||||
|
||||
**Максимальный L2 MTU.** Для обеспечения прозрачности параметр L2 MTU на фильтрах устанавливается в **максимально возможное значение — 9216 байт** (по RFC). Аналогичные значения (около 9000) выставляются на интерфейсах балансировщиков. Это позволяет полностью закрыть проблему с MTU и не возвращаться к ней в процессе эксплуатации.
|
||||
|
||||
**Параметр permit invalid flow.** В проекте АСБИ этот параметр должен быть **всегда включён**. Он разрешает заведение TCP-сессий без наличия начального TCP SYN-пакета. Это критически важно при переключении ТСПУ из режима TAP в рабочий режим (Inline): в момент переключения на фильтры хлынет трафик множества уже установленных TCP-сессий, для которых SYN-пакет был отправлен ранее. Без параметра permit invalid flow фильтр будет **дропать** все такие сессии, что приведёт к массовому разрыву соединений абонентов. С включённым параметром фильтр принимает пакеты «с середины» сессии и заводит для них сессионные записи (подробнее — в [разделе 15.2.6](15.md)).
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 4: Балансировщик](04.md) · [Раздел 6: Места установки ТСПУ →](06.md)
|
||||
161
chapters/06.md
Normal file
161
chapters/06.md
Normal file
@@ -0,0 +1,161 @@
|
||||
# 6. Места установки ТСПУ в сети оператора
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 5: Фильтр](05.md)
|
||||
|
||||
---
|
||||
|
||||
ТСПУ устанавливается **в разрыв каналов связи** оператора и может располагаться в нескольких различных точках его сети. Выбор точки установки влияет на тип трафика, который проходит через ТСПУ, на возможности диагностики и на общую нагрузку на оборудование.
|
||||
|
||||
Если рассматривать сеть оператора связи от абонентов в сторону выхода в интернет, можно выделить три основных места установки, а также особый режим подключения — on-a-stick.
|
||||
|
||||
```text
|
||||
Абоненты
|
||||
│
|
||||
│ ← (1) До BRAS: PPPoE-трафик
|
||||
│
|
||||
┌───┴───┐
|
||||
│ BRAS │ (BPE / BNG / GGSN / PGW)
|
||||
└───┬───┘
|
||||
│
|
||||
│ ← (2) До CGNAT: серые IP, наиболее удобная точка
|
||||
│
|
||||
┌───┴───┐
|
||||
│ CGNAT │
|
||||
└───┬───┘
|
||||
│
|
||||
│ ← (3) После CGNAT: только белые IP
|
||||
│
|
||||
Интернет
|
||||
```
|
||||
|
||||
Каждая точка имеет свои особенности с точки зрения инкапсуляции трафика и возможностей траблшутинга. Некоторые точки более предпочтительны, другие — менее, но все они допустимы для установки ТСПУ.
|
||||
|
||||
Инкапсуляция на стыке оператора, в разрыв которого встаёт ТСПУ, зависит от технологий конкретного оператора и от места установки в его сети. Это могут быть чистые IP-пакеты, пакеты с VLAN-тегами (одним или двумя — QinQ), пакеты с MPLS-метками, PPPoE-пакеты и различные комбинации. ТСПУ должно уметь разбираться со всеми этими заголовками, чтобы добраться до IP-трафика и выполнить его обработку.
|
||||
|
||||
## 6.1. До BRAS/BPE/BNG (между абонентами и терминацией сессий)
|
||||
|
||||
Первая возможная точка установки — **между абонентами и устройствами терминации абонентских сессий**. Такими устройствами могут быть:
|
||||
|
||||
| Тип сети | Устройства терминации сессий |
|
||||
| -------------------- | ------------------------------------ |
|
||||
| **Широкополосный доступ** | BRAS, BPE, BNG |
|
||||
| **Мобильные сети** | GGSN, PGW |
|
||||
|
||||
Все эти устройства выполняют одну функцию — **терминируют абонентские сессии**. В дальнейшем они обобщённо именуются «BRAS» (условный BRAS).
|
||||
|
||||
При установке в этой точке ТСПУ располагается максимально близко к абонентам — до того, как трафик пройдёт через какую-либо обработку на стороне оператора.
|
||||
|
||||
### 6.1.1. Особенность: PPPoE-трафик
|
||||
|
||||
Основная особенность установки **до BRAS** — наличие **PPPoE-трафика**. Широкополосные абоненты подключаются к BRAS по протоколу PPPoE, и этот трафик представляет собой дополнительный уровень инкапсуляции, который необходимо обрабатывать.
|
||||
|
||||
Важно: PPPoE-трафик существует **только на участке до BRAS**. Выше BRAS (то есть ближе к интернету) PPPoE-трафика в нормально функционирующих сетях не бывает — BRAS терминирует PPPoE-сессии и дальше передаёт обычные IP-пакеты.
|
||||
|
||||
Наличие PPPoE не является критической проблемой — фильтры умеют работать с этой инкапсуляцией. Однако это дополнительная сложность, которую необходимо учитывать при настройке. Параметр **VLAN Mode** на фильтрах должен быть установлен в **QinQ**, чтобы обеспечить корректный поиск IP-заголовка внутри PPPoE-инкапсуляции (подробнее — в [разделе 5.1.1](05.md)).
|
||||
|
||||
## 6.2. До CGNAT (после BRAS) — наиболее удобная точка
|
||||
|
||||
Вторая точка установки — **между BRAS и CGNAT**. На этом участке BRAS уже терминировал абонентские сессии, но трафик ещё не прошёл трансляцию адресов (NAT).
|
||||
|
||||
Это, вероятно, **наиболее удобная точка** для установки ТСПУ по двум причинам:
|
||||
|
||||
1. **Отсутствие PPPoE** — трафик PPPoE уже терминирован на BRAS, что означает меньшее количество заголовков инкапсуляции для обработки;
|
||||
2. **Видимость абонентских адресов** — серые (частные) IP-адреса абонентов ещё не прошли через NAT-трансляцию и доступны для анализа.
|
||||
|
||||
### 6.2.1. Видимость серых абонентских IP-адресов
|
||||
|
||||
На участке до CGNAT фильтры ТСПУ видят **серые** (частные) IP-адреса абонентов — те самые адреса, которые непосредственно назначены абонентским устройствам. Это даёт существенные преимущества при диагностике:
|
||||
|
||||
- Можно найти сессию **конкретного абонента** на фильтрах по его IP-адресу;
|
||||
- Можно определить, что именно происходит с трафиком данного абонента;
|
||||
- Можно исключить конкретного абонента из обработки DPI-листом (через параметр **No IP**) для диагностики проблем.
|
||||
|
||||
Эта возможность особенно ценна при траблшутинге — прямая связь между физическим абонентом и его сессиями на ТСПУ значительно ускоряет поиск и устранение проблем.
|
||||
|
||||
## 6.3. После CGNAT (ближе к выходу в интернет)
|
||||
|
||||
Третья точка установки — **после CGNAT**, ближе к выходу в общую сеть интернет. На этом участке трафик уже прошёл трансляцию адресов.
|
||||
|
||||
### 6.3.1. Только белые адреса, сложности траблшутинга
|
||||
|
||||
После CGNAT серых абонентских адресов **больше не видно** — на фильтрах ТСПУ будут присутствовать только **белые** (публичные) IP-адреса из NAT-пула оператора.
|
||||
|
||||
Это создаёт существенное неудобство при траблшутинге:
|
||||
|
||||
- **Невозможно напрямую связать** конкретного физического абонента с его сессией на ТСПУ — адрес источника в пакете является транслированным (белым), а не оригинальным (серым) адресом абонента;
|
||||
- Для идентификации абонента необходимо **взаимодействовать с оператором** — запрашивать у него информацию о том, в какие порты и IP-адреса был транслирован конкретный абонент на CGNAT;
|
||||
- Процесс диагностики становится **значительно более длительным** и требует координации между командой ТСПУ и оператором связи.
|
||||
|
||||
С точки зрения самой фильтрации (блокировки, распознавания протоколов) размещение после CGNAT не вносит каких-либо ограничений — функциональность ТСПУ остаётся полной. Неудобство касается исключительно диагностики и траблшутинга.
|
||||
|
||||
> **Примечание:** в ряде случаев подсистемы BRAS и CGNAT могут быть **совмещены в одном устройстве**. В этом случае участок «между BRAS и CGNAT» (наиболее удобная точка установки) попросту отсутствует — ТСПУ может быть установлено либо до этого комбинированного устройства, либо после него.
|
||||
|
||||
## 6.4. Режим On-a-stick (BRAS/CGNAT подключены петлёй)
|
||||
|
||||
Помимо трёх линейных точек установки, существует особый вариант размещения ТСПУ — когда сервисное оборудование оператора (BRAS и/или CGNAT) подключено **в режиме on-a-stick** (петлёй).
|
||||
|
||||
В режиме on-a-stick BRAS или CGNAT подключается к оператору **одним агрегированным каналом**, через который трафик уходит к устройству и возвращается обратно. Если ТСПУ установлено на этом участке, трафик **проходит через него дважды**.
|
||||
|
||||
```text
|
||||
Абоненты Интернет
|
||||
│ │
|
||||
│ ┌────────────┐ │
|
||||
└─────────┤ ТСПУ ├──────────────────────┘
|
||||
└──────┬─────┘
|
||||
│ ↕ (трафик проходит дважды)
|
||||
┌──────┴─────┐
|
||||
│BRAS / CGNAT│
|
||||
│(on-a-stick)│
|
||||
└────────────┘
|
||||
```
|
||||
|
||||
Возможны три варианта подключения on-a-stick:
|
||||
|
||||
| Вариант | Что проходит через ТСПУ дважды |
|
||||
| -------------------------- | ----------------------------------------------------------- |
|
||||
| **BRAS on-a-stick** | Трафик до BRAS + трафик после BRAS (сегменты 1 + 2) |
|
||||
| **CGNAT on-a-stick** | Трафик до CGNAT + трафик после CGNAT (сегменты 2 + 3) |
|
||||
| **BRAS + CGNAT on-a-stick**| Трафик до обоих устройств + трафик после обоих (сегменты 1 + 3) |
|
||||
|
||||
### 6.4.1. Двойное прохождение трафика через ТСПУ
|
||||
|
||||
При подключении on-a-stick трафик проходит через ТСПУ **дважды**:
|
||||
|
||||
1. **Первый проход** — трафик от абонентов идёт через ТСПУ к BRAS/CGNAT;
|
||||
2. **Второй проход** — после обработки на BRAS/CGNAT трафик возвращается через ТСПУ в сторону интернета (или обратно к абонентам — в зависимости от направления).
|
||||
|
||||
Это означает, что каждая абонентская сессия потенциально **видна фильтрам дважды**, причём на втором проходе адреса могут быть уже другими (после NAT-трансляции на CGNAT). Без дополнительных мер это приводит к удвоению количества сессий и удвоению нагрузки на ТСПУ.
|
||||
|
||||
### 6.4.2. Разделение по VLAN для обработки трафика одного направления
|
||||
|
||||
**Наиболее удобная конфигурация** при подключении on-a-stick — когда оператор чётко разделяет трафик по VLAN:
|
||||
|
||||
- **Один VLAN** несёт трафик **до** BRAS/CGNAT (от абонентов к сервисному оборудованию);
|
||||
- **Другой VLAN** несёт трафик **после** BRAS/CGNAT (от сервисного оборудования в сторону интернета).
|
||||
|
||||
В этом случае на ТСПУ можно настроить обработку **только нужного VLAN** (например, трафика до CGNAT, где видны серые абонентские адреса), а второй VLAN — **прозрачно пропустить** на уровне балансировщика, даже не отправляя его на фильтры.
|
||||
|
||||
Это достигается через **flow rules** балансировщика (подробнее — в [разделе 4.4](04.md)):
|
||||
|
||||
- Правило с действием `balancing` — для VLAN, который нужно обрабатывать (трафик отправляется на фильтры);
|
||||
- Правило с действием `bypass` — для VLAN, который нужно пропустить (трафик прозрачно проходит через балансировщик).
|
||||
|
||||
В результате фильтры обрабатывают трафик **только один раз**, каждый абонент виден единожды, путаницы с сессиями не возникает.
|
||||
|
||||
### 6.4.3. Проблемы двойной обработки и best practice
|
||||
|
||||
Если оператор **не может** чётко отделить трафик до и после BRAS/CGNAT (например, оба направления идут в одном VLAN), возникает ситуация **двойной обработки**. Её последствия:
|
||||
|
||||
- **Удвоение количества сессий** — одна и та же абонентская сессия видна фильтру дважды, причём с разными IP-адресами (до и после NAT-трансляции);
|
||||
- **Путаница при траблшутинге** — сложно определить, какая из двух записей сессии соответствует реальному состоянию;
|
||||
- **Двойная нагрузка на ТСПУ** — запас производительности должен быть рассчитан исходя из удвоенного объёма трафика.
|
||||
|
||||
Эта ситуация **нежелательна** и её следует избегать при проектировании. В лучшем варианте необходимо добиться от оператора информации о разделении трафика по VLAN и выбрать для обработки только нужное направление.
|
||||
|
||||
> **Пример из практики:** на пилотном проекте (Урал) один из операторов подключён по принципу on-a-stick к CGNAT (сегменты 2 + 3 на схеме). Оператор предоставил информацию о том, какие VLAN несут трафик до CGNAT, а какие — после. На балансировщике были отобраны только нужные VLAN и отправлены на фильтры. В результате фильтры видят нормальные абонентские сессии до CGNAT (с серыми адресами) и не обрабатывают транслированный трафик после CGNAT. Это — **best practice** подключения on-a-stick.
|
||||
|
||||
Возможен и **обратный подход**: вместо явного указания обрабатываемых VLAN можно исключить ненужные VLAN из обработки, а всё остальное — обрабатывать. Выбор подхода — вопрос удобства настройки для конкретной площадки.
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 5: Фильтр](05.md) · [Раздел 7: Эшелонированная система →](07.md)
|
||||
215
chapters/07.md
Normal file
215
chapters/07.md
Normal file
@@ -0,0 +1,215 @@
|
||||
# 7. Эшелонированная система (ТСПУ тип Б)
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 6: Места установки ТСПУ](06.md)
|
||||
|
||||
---
|
||||
|
||||
## 7.1. Назначение: обработка трафика, не прошедшего через ТСПУ тип А
|
||||
|
||||
Эшелонированная система (ТСПУ тип Б, второй эшелон) предназначена для **обработки трафика, который не прошёл через стандартные ТСПУ** (тип А, первый эшелон).
|
||||
|
||||
Когда в тексте упоминается просто «ТСПУ» без уточнения типа, подразумевается **ТСПУ тип А** — именно этот тип рассматривался во всех предыдущих разделах. ТСПУ тип А устанавливается у большинства операторов и покрывает основную массу трафика. Однако у крупных операторов связи существуют ситуации, когда часть трафика не может быть обработана стандартными средствами — для таких случаев создана эшелонированная система.
|
||||
|
||||
Идея эшелонирования возникла как способ **сократить общее количество ТСПУ**, развёртываемых по стране. Вместо установки ТСПУ тип А у каждого мелкого оператора на уровне доступа, можно у нескольких крупных операторов в ключевых точках установить двухстадийную систему фильтрации, что позволяет снизить затраты на реализацию проекта.
|
||||
|
||||
## 7.2. Проблема асимметричного трафика у крупных операторов
|
||||
|
||||
Сеть крупного оператора связи, если идти от абонентов к выходу в интернет, делится на несколько сегментов:
|
||||
|
||||
```text
|
||||
┌─────────────────────────────────────────────────────────┐
|
||||
│ Сегмент доступа и распределения │
|
||||
│ • Абоненты │
|
||||
│ • Небольшие операторы (single-home) │
|
||||
│ • Корпоративные заказчики с одним подключением │
|
||||
│ │
|
||||
│ → Обрабатывается ТСПУ тип А (без проблем) │
|
||||
└────────────────────────┬────────────────────────────────┘
|
||||
│
|
||||
┌────────────────────────┴────────────────────────────────┐
|
||||
│ Уровень ядра и пиринга │
|
||||
│ • Крупные операторы связи │
|
||||
│ • Крупные корпоративные заказчики │
|
||||
│ • Несколько выходов в интернет │
|
||||
│ │
|
||||
│ → Возможен асимметричный трафик │
|
||||
│ → Требуется ТСПУ тип Б (эшелон) │
|
||||
└─────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
На уровне доступа и распределения подключены абоненты и небольшие операторы с единственным каналом связи (single-home). У них нет собственной автономной системы и собственной IP-адресации — адреса выделяет крупный оператор. Весь их трафик проходит через одну точку и обрабатывается стандартным **ТСПУ тип А** без каких-либо проблем.
|
||||
|
||||
На уровне ядра и пиринга подключаются **крупные операторы** и заказчики, которые могут иметь **несколько выходов в интернет** — через разных провайдеров. Их трафик может:
|
||||
|
||||
- выходить через одного оператора, а **возвращаться через другого**;
|
||||
- проходить через ТСПУ только в одном направлении.
|
||||
|
||||
В таких случаях традиционная схема фильтрации **не работает**: на фильтре ТСПУ тип А сессия «не соберётся», потому что одна сторона сессии проходит через ТСПУ, а ответная — возвращается иным путём, минуя его. Для обработки такого **асимметричного трафика** и предназначен ТСПУ тип Б.
|
||||
|
||||
## 7.3. Балансировщик Eco Highway
|
||||
|
||||
Эшелонированная система, как и ТСПУ тип А, состоит из балансировщика и фильтров, но с существенными отличиями. Балансировщик эшелона называется **Eco Highway** (в отличие от **EcoFilter Balancer** в ТСПУ тип А). Аппаратная платформа **одинакова** — это тот же одноюнитовый 32-портовый коммутатор на базе чипа **Barefoot Tofino**. Различается только **программное обеспечение**.
|
||||
|
||||
Ключевое отличие Eco Highway: он **сам выполняет фильтрацию трафика** на основе заголовков L3/L4 (IP-адреса, порты), а не просто распределяет трафик по фильтрам.
|
||||
|
||||
### 7.3.1. BGP-загрузка списков фильтрации из ЦСУ
|
||||
|
||||
В отличие от EcoFilter Balancer, где правила фильтрации (flow rules) задаются вручную и исчисляются единицами, на Eco Highway списки фильтрации:
|
||||
|
||||
- загружаются автоматически по протоколу **BGP** из центральной системы управления;
|
||||
- содержат **десятки и сотни тысяч правил**;
|
||||
- **не могут быть заданы вручную** — это не предусмотрено конструкцией.
|
||||
|
||||
Списки организованы в виде нескольких таблиц, каждая из которых фильтрует по-своему:
|
||||
|
||||
| Тип таблицы | Критерий фильтрации |
|
||||
| --------------------- | ----------------------------------------- |
|
||||
| IPv4 адрес + порт | IP-адрес, маска и порт TCP/UDP |
|
||||
| IPv4 адрес | Только IP-адрес (без порта) |
|
||||
| IPv6 | Аналогичные таблицы для IPv6-трафика |
|
||||
| Белый список | Ресурсы, исключённые из фильтрации |
|
||||
| Port redirect | Трафик, подлежащий отправке на фильтры |
|
||||
|
||||
### 7.3.2. Блокировка по IP-адресам на уровне балансировщика (Telegram, реестр РКН)
|
||||
|
||||
Eco Highway самостоятельно блокирует трафик, который можно идентифицировать по IP-адресам и портам — **без отправки на фильтры**:
|
||||
|
||||
- **Реестр Роскомнадзора** (в части IP-адресов) — все правила блокировки по IP загружаются на балансировщик, что снижает нагрузку на фильтры;
|
||||
- **Блокировка протоколов** (например, Telegram) — очищенные списки IP-адресов и портов загружаются из ЦСУ по BGP.
|
||||
|
||||
Принципиальное отличие от ТСПУ тип А: на первом эшелоне блокировка протоколов (Telegram и др.) выполняется **на фильтрах** с помощью DPI. На втором эшелоне эта блокировка выполняется **на самом балансировщике** по IP-спискам. Более того, в прошивке фильтров, предназначенных для эшелонированной системы, возможности блокировки протоколов (например, Telegram) **отсутствуют** — они просто не нужны, поскольку этим занимается Eco Highway.
|
||||
|
||||
### 7.3.3. Фильтры в режиме On-a-stick, VLAN-разделение LAN/WAN
|
||||
|
||||
Фильтры в эшелонированной системе подключены **иначе**, чем в ТСПУ тип А:
|
||||
|
||||
| Параметр | ТСПУ тип А (EcoFilter Balancer) | ТСПУ тип Б (Eco Highway) |
|
||||
| ------------------- | ------------------------------- | -------------------------------------- |
|
||||
| **Подключение** | Пары портов LAN + WAN | Режим on-a-stick (все порты равноправны) |
|
||||
| **Разделение LAN/WAN** | На уровне физических портов | На уровне VLAN-тегов |
|
||||
| **Чётность портов** | Чётные = LAN, нечётные = WAN | Не соблюдается |
|
||||
|
||||
В режиме on-a-stick каждый физический порт фильтра **равноправен**. Разделение между LAN и WAN происходит на уровне специального VLAN-заголовка:
|
||||
|
||||
1. Eco Highway при отправке пакета на фильтр добавляет **VLAN-тег**, обозначающий направление (LAN);
|
||||
2. Фильтр после обработки **меняет** этот VLAN-тег на другой (WAN);
|
||||
3. Eco Highway по VLAN-тегу определяет направление и отправляет пакет дальше.
|
||||
|
||||
Таким образом, логическое разделение LAN/WAN сохраняется, но на уровне физики все интерфейсы фильтра однотипные.
|
||||
|
||||
### 7.3.4. Фильтры занимаются только URL-фильтрацией по реестру РКН
|
||||
|
||||
Поскольку блокировка по IP-адресам и протоколам выполняется самим Eco Highway, фильтры в эшелонированной системе занимаются **исключительно URL-фильтрацией** по реестру Роскомнадзора — той частью блокировки, которая требует глубокого анализа содержимого пакетов (DPI) и не может быть выполнена на уровне балансировщика.
|
||||
|
||||
Это означает, что на фильтры отправляется **минимально возможный** объём трафика — только тот, который требует проверки по URL. Всё остальное обрабатывается или пропускается балансировщиком.
|
||||
|
||||
Благодаря упрощённому функционалу (нет распознавания протоколов, нет логирования соединений) производительность фильтров на эшелоне **несколько выше**, чем на ТСПУ тип А — примерно на 15%. Однако разница невелика, и при проектировании рекомендуется использовать те же расчётные цифры производительности, что и для ТСПУ тип А.
|
||||
|
||||
## 7.4. Два конвейера (Pipeline) в Eco Highway
|
||||
|
||||
Внутри чипа Barefoot Tofino, на котором построен балансировщик, существуют **два независимых конвейера** (Pipeline 1 и Pipeline 2) — логические структуры, обрабатывающие входящий трафик на высокой скорости. Каждый конвейер обладает собственным **независимым набором ресурсов**: памятью и вычислительной мощностью.
|
||||
|
||||
На обычном балансировщике (EcoFilter Balancer) оба конвейера **настроены идентично** — в какой бы конвейер ни попал пакет, обработка будет одинаковой. На Eco Highway конвейеры **настраиваются по-разному** — это позволяет в два раза увеличить доступное количество правил фильтрации.
|
||||
|
||||
### 7.4.1. Разделение портов между конвейерами
|
||||
|
||||
Все физические порты балансировщика **жёстко привязаны** к одному из двух конвейеров на заводском уровне — примерно половина портов обслуживается Pipeline 1, половина — Pipeline 2.
|
||||
|
||||
На Eco Highway это разделение используется целенаправленно:
|
||||
|
||||
- **LAN-порты** (в сторону оператора связи) прикрепляются к **одному конвейеру**;
|
||||
- **WAN-порты** (в сторону интернета) прикрепляются к **другому конвейеру**.
|
||||
|
||||
Принцип чётных/нечётных портов, используемый на EcoFilter Balancer, на эшелоне **не соблюдается** и не имеет значения.
|
||||
|
||||
### 7.4.2. Физическая перемычка между конвейерами
|
||||
|
||||
Поскольку конвейеры **логически изолированы** друг от друга внутри чипа (прямой связи между ними нет), для передачи пакета из одного конвейера в другой используется **физическая перемычка** (jumper) — кабель, соединяющий порт одного конвейера с портом другого.
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────┐
|
||||
│ Eco Highway │
|
||||
│ │
|
||||
│ Pipeline 1 Pipeline 2 │
|
||||
│ ┌────────────┐ ┌────────────┐ │
|
||||
│ │ Таблицы │ │ Таблицы │ │
|
||||
│ │ фильтрации │ │ фильтрации │ │
|
||||
│ │ (набор A) │ │ (набор B) │ │
|
||||
│ └──────┬─────┘ └──────┬─────┘ │
|
||||
│ │ │ │
|
||||
│ P41 ←┼── LAN-порты WAN-порты ──┼→ P91 │
|
||||
│ P42 ←┘ ┌─┼→ P92 │
|
||||
│ │ ┌──────────────┐ │ │
|
||||
│ └─────┤ Перемычка ├─────────┘ │
|
||||
│ └──────────────┘ │
|
||||
│ │ │ │
|
||||
│ Порты к фильтрам Порты к фильтрам │
|
||||
└──────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
Перемычка должна быть рассчитана на **весь объём трафика**, проходящего через балансировщик. В худшем случае весь трафик может пройти через перемычку, поэтому она не должна стать узким местом. При большом количестве высокоскоростных каналов может потребоваться несколько перемычек.
|
||||
|
||||
### 7.4.3. Прохождение пакета: drop / отправка на фильтр / переход на второй конвейер
|
||||
|
||||
Когда пакет попадает на вход Eco Highway, он проходит следующий путь:
|
||||
|
||||
**Шаг 1: Pipeline 1.** Пакет, вошедший через LAN-порт, попадает в конвейер, к которому этот порт привязан. Пакет проходит через все таблицы фильтрации данного конвейера. По результатам возможны **три исхода**:
|
||||
|
||||
1. **Drop** — пакет совпал с запрещающим правилом (например, IP-адрес Telegram) и **дропается**. Дальнейшая обработка не происходит;
|
||||
2. **Отправка на фильтр** — пакет совпал с правилом перенаправления на фильтры (port redirect). Пакет отправляется на фильтр для URL-фильтрации, обрабатывается и **возвращается напрямую** оператору, минуя второй конвейер;
|
||||
3. **Переход на Pipeline 2** — пакет не совпал ни с одним правилом первого конвейера. Пакет выходит через порт, принадлежащий Pipeline 1, проходит через **физическую перемычку** и попадает на вход Pipeline 2.
|
||||
|
||||
**Шаг 2: Pipeline 2.** На втором конвейере пакет проходит через **другой набор правил** (отличающийся от первого). Результат аналогичен — drop, отправка на фильтр или пропуск дальше к оператору.
|
||||
|
||||
Важно: после отправки на фильтр пакет **не проходит** через второй конвейер повторно. Обработанный фильтром пакет сразу отправляется оператору через нужный порт. Это было исправлено после первоначальной реализации, где пакет мог дважды попасть на фильтры.
|
||||
|
||||
Также важно: хотя порты привязаны к конвейерам на входе, на **выходе** пакет может быть отправлен через **любой порт** — это логическая сущность обработки, а не жёсткая привязка входа к выходу. Пакет, пришедший через определённый LAN-порт, всё равно вернётся через **парный** ему WAN-порт (сохраняется привязка к линку оператора), но маршрут внутри балансировщика может быть произвольным.
|
||||
|
||||
### 7.4.4. Удвоение количества правил фильтрации
|
||||
|
||||
Разделение правил между двумя конвейерами позволяет **в два раза увеличить** общее количество правил фильтрации на Eco Highway. Память внутри чипа Barefoot Tofino, хранящая эти правила, является **очень быстрой** (работает на скорости провода), но крайне ограниченной по объёму — это, по сути, программируемый TCAM (Content-Addressable Memory). Каждое дополнительное правило — на вес золота.
|
||||
|
||||
На обычном EcoFilter Balancer, где оба конвейера идентичны, удвоение невозможно — один и тот же набор правил дублируется. На Eco Highway каждый конвейер несёт **свой уникальный набор**, удваивая суммарную ёмкость.
|
||||
|
||||
## 7.5. Отличия EcoFilter Balancer от Eco Highway
|
||||
|
||||
| Характеристика | EcoFilter Balancer (тип А) | Eco Highway (тип Б) |
|
||||
| --------------------------- | -------------------------- | ------------------------------------------- |
|
||||
| **Аппаратная платформа** | Одинаковая | Одинаковая |
|
||||
| **Программное обеспечение** | Одно | Другое |
|
||||
| **Назначение** | Балансировка трафика | Балансировка + самостоятельная фильтрация |
|
||||
| **Правила фильтрации** | Вручную, единицы | По BGP из ЦСУ, десятки/сотни тысяч |
|
||||
| **Собственная фильтрация** | Нет (только bypass/balance)| Да (drop по L3/L4-заголовкам) |
|
||||
| **Конвейеры (Pipeline)** | Настроены идентично | Настроены по-разному (удвоение правил) |
|
||||
| **Перемычка** | Не требуется | Обязательна (физический кабель) |
|
||||
| **Подключение фильтров** | Пары LAN/WAN | On-a-stick (VLAN-разделение) |
|
||||
| **Связь с ЦСУ** | Только management | BGP для загрузки списков |
|
||||
| **Логирование** | Через фильтры | Отсутствует (только real-time) |
|
||||
|
||||
Разрабатываются обе платформы **одной группой программистов**, и код во многом пересекается. Решения, созданные в рамках реализации Eco Highway, нередко переносятся на EcoFilter Balancer (например, команды программного байпаса), и наоборот.
|
||||
|
||||
## 7.6. Отсутствие логирования на Eco Highway (только real-time)
|
||||
|
||||
На Eco Highway **не ведётся логирование** — информация о дропнутых и перенаправленных пакетах **не отправляется** на серверы логирования. Доступен только **просмотр в реальном времени** (real-time) на самом устройстве, без сохранения истории.
|
||||
|
||||
Причина: объём трафика, проходящего через эшелон, **значительно больше**, чем через ТСПУ тип А. Если ТСПУ тип А обрабатывает трафик конкретного набора абонентов, то ТСПУ тип Б может пропускать через себя трафик множества операторов на уровне ядра сети. Логирование такого объёма потребовало бы несоразмерных ресурсов.
|
||||
|
||||
Протокольные логи (для формирования очищенных списков блокировки) по-прежнему отправляются **только с фильтров первого эшелона** (ТСПУ тип А) через SPFS.
|
||||
|
||||
Для диагностики на Eco Highway доступны следующие возможности:
|
||||
|
||||
- **Просмотр списков в ЦСУ** — можно проверить, содержит ли конкретный IP-адрес или порт в загруженных списках;
|
||||
- **Программный байпас** — можно перевести Eco Highway в режим полного программного байпаса и проверить, восстанавливается ли доступность у оператора;
|
||||
- **Проверка на фильтрах** — убедиться, что нужная сессия не обрабатывается и на фильтрах второго эшелона.
|
||||
|
||||
## 7.7. Прозрачный пропуск трафика, уже обработанного ТСПУ тип А
|
||||
|
||||
Eco Highway должен уметь **различать** трафик, уже обработанный ТСПУ тип А на первом эшелоне, и трафик, который первый эшелон не видел.
|
||||
|
||||
Трафик, который **уже прошёл** через ТСПУ тип А (на нижнем уровне, на уровне доступа), **не должен обрабатываться повторно** на втором эшелоне. Для этого на Eco Highway предусмотрена возможность **прозрачного пропуска** такого трафика — он просто «пролетает насквозь» без фильтрации.
|
||||
|
||||
Это позволяет избежать двойной обработки и связанных с ней проблем (удвоение сессий, ложные срабатывания, избыточная нагрузка), аналогичных проблемам двойного прохождения при on-a-stick подключении (подробнее — в [разделе 6.4.3](06.md)).
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 6: Места установки ТСПУ](06.md) · [Раздел 8: Формирование протокольных списков →](08.md)
|
||||
156
chapters/08.md
Normal file
156
chapters/08.md
Normal file
@@ -0,0 +1,156 @@
|
||||
# 8. Формирование протокольных списков (двухстадийная блокировка)
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 7: Эшелонированная система](07.md)
|
||||
|
||||
---
|
||||
|
||||
## 8.1. Первый этап: распознавание протоколов на фильтрах (ТСПУ тип А)
|
||||
|
||||
Блокировка протоколов (Telegram, WhatsApp, Viber и др.) в системе ТСПУ реализована **в два этапа** — так называемая двухстадийная блокировка. Необходимость двухстадийного подхода обусловлена природой распознавания шифрованного трафика: фильтр анализирует сессию по множеству косвенных признаков (размеры пакетов, частота прохождения, вариации размеров, ключевые слова внутри пакетов), и такое распознавание **не является стопроцентным**. Возможны ложноположительные срабатывания — когда другой шифрованный трафик по тем же критериям ошибочно распознаётся как, например, Telegram. Прямая блокировка по результатам DPI на фильтре привела бы к случайной блокировке легитимных ресурсов.
|
||||
|
||||
На **первом этапе** фильтры ТСПУ тип А выполняют только **распознавание** протоколов, но **не блокируют** их:
|
||||
|
||||
1. Трафик проходит через фильтр и обрабатывается движком DPI;
|
||||
2. DPI-движок анализирует каждую сессию по множеству параметров (многофакторный анализ) и определяет, к какому протоколу она относится;
|
||||
3. Фильтр фиксирует результат распознавания в виде **протокольного лога** — записи о том, что конкретная сессия предварительно опознана как сессия определённого протокола;
|
||||
4. Сессия при этом **не блокируется** — трафик продолжает проходить без ограничений.
|
||||
|
||||
Распознавание выполняется в рамках DPI-листа (например, DPI-лист 0), на котором установлен режим **behavior: ignore** — это означает, что срабатывание правил фиксируется, но никаких блокирующих действий не предпринимается.
|
||||
|
||||
## 8.2. Отправка логов на SPFS (сервер предварительного формирования списков)
|
||||
|
||||
Протокольные логи с результатами распознавания отправляются с фильтров на **SPFS** (сервер предварительного формирования списков), расположенный на той же площадке ТСПУ.
|
||||
|
||||
Отправка настраивается в секции **debug logger** конфигурации фильтра:
|
||||
|
||||
- **Включение отправки** — секция активируется для нужных протоколов;
|
||||
- **Выбор протоколов** — по умолчанию `all` (все распознаваемые протоколы), но можно указать только конкретные (Telegram, WhatsApp и т.д.);
|
||||
- **Количество пакетов на протокол** — определяет, сколько пакетов из каждой распознанной сессии будет отправлено в лог. По умолчанию значение 0 (без ограничения, что соответствует первым 30 пакетам). На практике для корректного анализа достаточно **3 пакетов** — это значение было подтверждено в ходе тестов на Урале. Значение 30 генерирует избыточный объём лог-трафика;
|
||||
- **Лог-интерфейс** — по умолчанию используется выделенный лог-интерфейс (DPDK). Возможно переключение на management-интерфейс, однако это **не рекомендуется**, так как производительность отправки логов значительно снизится;
|
||||
- **Адрес и порт назначения** — указываются координаты сервера SPFS на площадке.
|
||||
|
||||
SPFS занимается **накоплением** поступающих протокольных логов со всех фильтров площадки и их **предварительной обработкой** перед отправкой в центральную систему управления.
|
||||
|
||||
## 8.3. Передача логов по GRPC в центральную систему управления
|
||||
|
||||
Накопленные и предварительно обработанные логи SPFS передаёт в **центральную систему управления (ЦСУ)** по протоколу **gRPC**.
|
||||
|
||||
```text
|
||||
ТСПУ тип А (площадка) Центральная система управления
|
||||
┌──────────────────────┐ ┌──────────────────────────┐
|
||||
│ │ │ │
|
||||
│ Фильтр 1 ──┐ │ │ Подсистема формирования │
|
||||
│ Фильтр 2 ──┼→ SPFS ├── gRPC ───→│ списков фильтрации │
|
||||
│ Фильтр N ──┘ │ │ │
|
||||
│ │ VPN │ • Сбор логов со всех │
|
||||
└──────────────────────┘ (Континент)│ площадок ТСПУ тип А │
|
||||
│ • Сохранение в БД │
|
||||
ТСПУ тип А (площадка) │ • Периодический анализ │
|
||||
┌──────────────────────┐ │ • Формирование списков │
|
||||
│ │ │ │
|
||||
│ Фильтр 1 ──┐ │ └──────────────────────────┘
|
||||
│ Фильтр 2 ──┼→ SPFS ├── gRPC ───→
|
||||
│ Фильтр N ──┘ │
|
||||
│ │
|
||||
└──────────────────────┘
|
||||
```
|
||||
|
||||
ЦСУ представляет собой **многокомпонентную распределённую систему**, развёрнутую на двух независимых площадках. Связь между площадками ТСПУ и ЦСУ осуществляется через **VPN** (криптошлюз «Континент»). Данные поступают со **всех площадок** ТСПУ тип А по всей стране — это порядка 350 площадок и около 5 000 устройств.
|
||||
|
||||
Протокольные логи отправляются **только с фильтров ТСПУ тип А** (первого эшелона). Фильтры ТСПУ тип Б (эшелон) протокольных логов **не генерируют** — на них отсутствует функционал распознавания протоколов, поскольку блокировка протоколов на эшелоне выполняется самим балансировщиком Eco Highway по уже готовым спискам.
|
||||
|
||||
## 8.4. Анализ, очистка от ложных срабатываний, формирование списков
|
||||
|
||||
Внутри ЦСУ за обработку протокольных логов отвечает **подсистема формирования списков фильтрации**. Эта подсистема выполняет несколько ключевых функций:
|
||||
|
||||
**Сбор и хранение.** Логи со всех площадок ТСПУ тип А сохраняются в базе данных ЦСУ. Система агрегирует данные с множества фильтров, что даёт ей **значительно более полную картину**, чем та, которую видит каждый отдельный фильтр.
|
||||
|
||||
**Периодический анализ.** С заданной периодичностью подсистема проводит анализ накопленных данных. Периодичность анализа — **настраиваемый параметр**: можно запускать анализ раз в минуту, раз в 5 минут и т.д. Более частый анализ требует большей производительности серверов.
|
||||
|
||||
**Очистка от ложных срабатываний.** Ключевое преимущество централизованного анализа — возможность проведения **более глубокого анализа**, чем на отдельном фильтре:
|
||||
|
||||
- **Сопоставление сессий с различных устройств** — ЦСУ видит данные с множества фильтров на разных площадках, а не только с одного конкретного. Это позволяет выявлять закономерности, недоступные на уровне единичного фильтра;
|
||||
- **Статистический анализ** — использование накопленных статистических данных для верификации результатов распознавания;
|
||||
- **Обогащение данных** — дополнение результатов распознавания сторонней информацией для повышения точности;
|
||||
- **Выделение конкретных адресов** — на примере Telegram: из всех сессий, распознанных как Telegram, формируется список IP-адресов и портов, на которых были обнаружены серверы Telegram или его прокси различных типов.
|
||||
|
||||
**Формирование очищенных списков.** По результатам анализа создаются **очищенные списки**, в которых вероятность ложноположительного срабатывания **крайне низка**. Эти списки содержат конкретные IP-адреса и порты (для каждого протокола — свой список), которые система с высокой степенью уверенности идентифицировала как принадлежащие блокируемому протоколу.
|
||||
|
||||
## 8.5. Загрузка очищенных списков обратно на фильтры (HTTP) и на Eco Highway (BGP)
|
||||
|
||||
Сформированные очищенные списки загружаются обратно на оборудование ТСПУ двумя путями:
|
||||
|
||||
### Загрузка на фильтры ТСПУ тип А (по HTTP)
|
||||
|
||||
Очищенные списки загружаются на фильтры по протоколу **HTTP** в **отдельный DPI-лист**, отличный от того, в котором выполняется распознавание:
|
||||
|
||||
| DPI-лист | Назначение | Behavior |
|
||||
|----------|-----------|----------|
|
||||
| DPI-лист 0 | Распознавание протоколов (первый этап) | **ignore** — срабатывание фиксируется, но не блокируется |
|
||||
| DPI-лист 5 (пример) | Блокировка по очищенным спискам из ЦСУ | **block** — трафик блокируется |
|
||||
|
||||
Таким образом, на одном фильтре **одновременно работают два процесса**:
|
||||
- в DPI-листе 0 продолжается распознавание новых сессий и отправка логов;
|
||||
- в DPI-листе 5 выполняется блокировка по уже проверенным и очищенным спискам.
|
||||
|
||||
### Загрузка на Eco Highway (по BGP)
|
||||
|
||||
Те же очищенные списки, но в **несколько ином формате**, загружаются по протоколу **BGP** на балансировщики **Eco Highway** (ТСПУ тип Б). На эшелоне блокировка протоколов выполняется **самим балансировщиком** по IP-адресам и портам — без участия фильтров.
|
||||
|
||||
```text
|
||||
Центральная система управления
|
||||
┌──────────────────────────────┐
|
||||
│ Очищенные списки │
|
||||
│ (IP + порт для каждого │
|
||||
│ протокола) │
|
||||
└───────┬──────────┬──────────┘
|
||||
│ │
|
||||
HTTP │ │ BGP
|
||||
│ │
|
||||
▼ ▼
|
||||
┌───────────┐ ┌───────────┐
|
||||
│ Фильтры │ │ Eco │
|
||||
│ ТСПУ А │ │ Highway │
|
||||
│ │ │ ТСПУ Б │
|
||||
│ DPI-лист 5│ │ │
|
||||
│ behavior: │ │ Блокировка│
|
||||
│ block │ │ по L3/L4 │
|
||||
└───────────┘ └───────────┘
|
||||
```
|
||||
|
||||
Фильтры ТСПУ тип Б получают от Eco Highway только тот трафик, который требует URL-фильтрации по реестру РКН. Блокировка протоколов в прошивке фильтров эшелона **отсутствует** — она не нужна, поскольку этим занимается сам балансировщик.
|
||||
|
||||
## 8.6. Время полного цикла блокировки: ~5–15 минут
|
||||
|
||||
Полный цикл двухстадийной блокировки — от момента появления нового, ранее неизвестного сервера блокируемого протокола до его фактической блокировки — составляет **от 5 до 15 минут**.
|
||||
|
||||
```text
|
||||
┌────────────────────────────────────────────────────────────────┐
|
||||
│ Полный цикл блокировки │
|
||||
│ │
|
||||
│ 1. Абонент подключается к новому серверу ─┐ │
|
||||
│ (например, новая Telegram-прокси) │ │
|
||||
│ │ ~5–15 мин │
|
||||
│ 2. Фильтр распознаёт протокол (DPI) │ │
|
||||
│ 3. Лог отправляется на SPFS │ │
|
||||
│ 4. SPFS передаёт в ЦСУ (gRPC) │ │
|
||||
│ 5. ЦСУ анализирует и формирует список │ │
|
||||
│ 6. Список загружается на фильтры (HTTP) │ │
|
||||
│ и Eco Highway (BGP) │ │
|
||||
│ 7. Блокировка активируется ─┘ │
|
||||
└────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
Эти данные получены в ходе тестирования эшелонированной системы в тестовой зоне в Сургуте. Время полного цикла **зависит от настроек**:
|
||||
|
||||
- **Периодичность анализа на ЦСУ** — чем чаще запускается анализ базы данных (например, раз в минуту вместо раз в 5 минут), тем быстрее формируются списки, но тем выше нагрузка на серверы;
|
||||
- **Настройки SPFS** — параметры накопления и предварительной обработки логов;
|
||||
- **Количество сессий по данному протоколу** — при большом количестве сессий (много абонентов используют блокируемый протокол) блокировка срабатывает быстрее, так как данных для анализа больше.
|
||||
|
||||
**Важно:** до момента обновления списка фильтр **не обрывает** существующие сессии блокируемого протокола. Например, если появилась новая Telegram-прокси, которая ранее нигде не была зафиксирована, абонент может свободно работать через неё до тех пор, пока фильтр не получит обновлённый список, содержащий адрес этой прокси.
|
||||
|
||||
Поскольку проект подобного масштаба реализуется впервые, текущие параметры основаны на эмпирических данных из тестовых сегментов. Не исключена корректировка параметров в ту или иную сторону по мере накопления опыта эксплуатации. Если серверы будут перегружаться, можно снизить частоту анализа — это увеличит время блокировки, но позволит существующим серверам справляться с нагрузкой.
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 7: Эшелонированная система](07.md) · [Раздел 9: Центральная система управления →](09.md)
|
||||
95
chapters/09.md
Normal file
95
chapters/09.md
Normal file
@@ -0,0 +1,95 @@
|
||||
# 9. Центральная система управления (ЦСУ)
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 8: Формирование протокольных списков](08.md)
|
||||
|
||||
---
|
||||
|
||||
## 9.1. Архитектура: две независимые площадки (основная и резервная)
|
||||
|
||||
Центральная система управления (ЦСУ) — это централизованная платформа, через которую осуществляется управление всеми ТСПУ, развёрнутыми по стране. ЦСУ располагается в **двух независимых ЦОДах**:
|
||||
|
||||
- **Основная площадка** — основной центр обработки данных;
|
||||
- **Резервная площадка** — дублирующий центр, обеспечивающий отказоустойчивость.
|
||||
|
||||
```text
|
||||
┌───────────────────┐ ┌───────────────────┐
|
||||
│ Основная площадка │◄───────►│ Резервная площадка │
|
||||
│ ЦСУ │ Канал │ ЦСУ │
|
||||
│ │ связи │ │
|
||||
└────────┬──────────┘ └──────────┬────────┘
|
||||
│ │
|
||||
│ VPN (криптошлюз «Континент») │
|
||||
│ │
|
||||
┌────────┴───────────────────────────────┴────────┐
|
||||
│ │
|
||||
│ Интернет (публичные каналы) │
|
||||
│ │
|
||||
└──┬──────┬──────┬──────┬──────┬──────┬──────┬──┘
|
||||
│ │ │ │ │ │ │
|
||||
ТСПУ ТСПУ ТСПУ ТСПУ ТСПУ ТСПУ ...
|
||||
площ.1 площ.2 площ.3 площ.4 площ.5 площ.6
|
||||
```
|
||||
|
||||
Обе площадки **связаны между собой** выделенным каналом связи, по которому осуществляется репликация данных и обеспечивается отказоустойчивость. Пользователи (инженеры эксплуатации) также попадают на ЦСУ через **шифрованные VPN-каналы**.
|
||||
|
||||
## 9.2. Связь с ТСПУ через VPN (криптошлюз «Континент»)
|
||||
|
||||
Связь между площадками ТСПУ и центральной системой управления осуществляется через **VPN**, построенный на криптошлюзах **«Континент»** (модель IPC-3000 или аналогичная).
|
||||
|
||||
На каждой площадке ТСПУ установлен криптошлюз, который через **публичные интернет-каналы** устанавливает VPN-соединение с более мощной моделью криптошлюза на стороне ЦСУ. Через этот VPN-канал обеспечивается:
|
||||
|
||||
- **Управление устройствами** — доступ к CLI фильтров, балансировщиков, байпасов;
|
||||
- **Сбор данных** — протокольные логи (gRPC от SPFS), системные логи (syslog), данные мониторинга (SNMP);
|
||||
- **Распространение списков** — загрузка очищенных списков на фильтры (HTTP) и на Eco Highway (BGP);
|
||||
- **Обновление ПО** — централизованная загрузка прошивок на оборудование.
|
||||
|
||||
Каждая площадка ТСПУ связана **как с основной, так и с резервной** площадкой ЦСУ, что обеспечивает непрерывность управления при выходе из строя одной из площадок.
|
||||
|
||||
Криптошлюз «Континент» на площадке ТСПУ выступает **шлюзом по умолчанию** для всех устройств сегмента управления (адрес .254 в подсети управления — подробнее в [разделе 10](10.md)).
|
||||
|
||||
## 9.3. Масштаб: ~350 площадок, ~5000 устройств
|
||||
|
||||
На текущем этапе федерального проекта ЦСУ обслуживает:
|
||||
|
||||
| Параметр | Значение |
|
||||
| --------------------------- | --------------- |
|
||||
| **Количество площадок ТСПУ** | ~350 |
|
||||
| **Суммарное количество устройств** | ~5 000 |
|
||||
| **Типы устройств** | Фильтры, балансировщики, байпасы, SPFS, СПХД |
|
||||
|
||||
Предполагается дальнейшее расширение по мере развития проекта.
|
||||
|
||||
## 9.4. Подсистемы ЦСУ: формирование списков, мониторинг, логирование, картография
|
||||
|
||||
ЦСУ представляет собой **многокомпонентную распределённую систему**, состоящую из нескольких подсистем, каждая из которых выполняет свою задачу:
|
||||
|
||||
| Подсистема | Назначение |
|
||||
| ----------------------------------- | ------------------------------------------------------------------------------------------- |
|
||||
| **Формирование списков фильтрации** | Сбор протокольных логов с SPFS на площадках ТСПУ, анализ, формирование очищенных списков и их распространение на фильтры (HTTP) и Eco Highway (BGP) |
|
||||
| **Мониторинг** | Наблюдение за состоянием оборудования ТСПУ на всех площадках |
|
||||
| **Логирование** | Сбор и хранение системных журналов с устройств |
|
||||
| **Картография** | Визуализация размещения оборудования и его состояния |
|
||||
| **Отчётность (Reports)** | Формирование отчётов о работе системы |
|
||||
|
||||
Архитектура каждой подсистемы, схемы обмена данными и внутренние процессы подробно описаны в отдельном документе — **«Системная архитектура центральной системы управления»**.
|
||||
|
||||
Поддержкой и настройкой ЦСУ занимается **команда DevOps**. Инженеры, обслуживающие ТСПУ, являются **пользователями** ЦСУ — они используют её интерфейсы для мониторинга и управления, но не занимаются настройкой самой системы. Заливка программного обеспечения на ЦСУ также выполняется командой DevOps, тогда как заливка ПО на оборудование ТСПУ выполняется совместно инженерами площадки и разработчиками (ДЦА готовит конфигурации и новое ПО, инженеры на местах выполняют установку).
|
||||
|
||||
## 9.5. Новая ЦСУ для федерального проекта (замена уральской)
|
||||
|
||||
В ходе развития проекта АСБИ существовали **две версии** ЦСУ:
|
||||
|
||||
| Параметр | Уральская ЦСУ (пилот) | Федеральная ЦСУ (новая) |
|
||||
| ------------------------ | ---------------------------------------- | -------------------------------------------- |
|
||||
| **Охват** | Уральский регион (пилотный проект) | Вся страна (федеральный проект) |
|
||||
| **Статус** | Тупиковая ветвь развития | Активная разработка |
|
||||
| **Функционал** | Ограниченный | Полный (все подсистемы) |
|
||||
| **Подключение площадок** | Только уральские площадки | Все площадки, включая переподключение Урала |
|
||||
|
||||
ЦСУ, работавшая на уральском пилотном проекте, является **тупиковой ветвью развития** — она не будет развиваться дальше. Для федерального проекта разрабатывается **полностью новая ЦСУ**, к которой будут подключены все площадки ТСПУ по всей стране, включая переподключение уральских площадок с пилотной системы.
|
||||
|
||||
Новая ЦСУ на момент проведения лекции находилась **в процессе разработки** — планировалось, что она начнёт функционировать к ноябрю и будет сдана в декабре. До момента запуска новой ЦСУ мониторинг и управление площадками осуществлялись через существующую (уральскую) систему в ограниченном объёме.
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 8: Формирование протокольных списков](08.md) · [Раздел 10: Сегмент управления ТСПУ →](10.md)
|
||||
90
chapters/10.md
Normal file
90
chapters/10.md
Normal file
@@ -0,0 +1,90 @@
|
||||
# 10. Сегмент управления ТСПУ
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 9: Центральная система управления](09.md)
|
||||
|
||||
---
|
||||
|
||||
## 10.1. Адресация: 10.<регион>.<площадка>.0/24
|
||||
|
||||
Каждая площадка ТСПУ имеет собственный **сегмент управления** — выделенную подсеть для management-интерфейсов всех устройств. Адресация сегмента управления построена по единой схеме:
|
||||
|
||||
```text
|
||||
10.<регион>.<площадка>.0/24
|
||||
```
|
||||
|
||||
Где:
|
||||
|
||||
| Октет | Значение | Пример |
|
||||
| -------- | ------------------------------------- | --------------------------- |
|
||||
| Первый | Всегда `10` (частная адресация) | `10` |
|
||||
| Второй | Номер региона (всего ~88 в стране) | `77` (Москва) |
|
||||
| Третий | Номер площадки в данном регионе | `1`, `2`, `3`... |
|
||||
| Четвёртый | Адрес устройства в подсети /24 (256 адресов) | `0`–`254` |
|
||||
|
||||
Таким образом, для площадки в Москве management-адрес будет выглядеть как `10.77.<номер_площадки>.0/24`.
|
||||
|
||||
## 10.2. Распределение адресов: байпасы, балансировщики, BMC, фильтры, IPMI, SPFS, СПХД
|
||||
|
||||
Все 256 адресов подсети /24 распределяются между устройствами площадки по фиксированной схеме:
|
||||
|
||||
```text
|
||||
10.<регион>.<площадка>.0/24
|
||||
|
||||
┌────────────────────────────────────────────────────────────┐
|
||||
│ .1 – .128 │ Управление байпасами (128 шт.) │
|
||||
├─────────────────┼─────────────────────────────────────────┤
|
||||
│ .131 – .140 │ Управление балансировщиками (10 шт.) │
|
||||
├─────────────────┼─────────────────────────────────────────┤
|
||||
│ .141 – .150 │ BMC балансировщиков (10 шт.) │
|
||||
├─────────────────┼─────────────────────────────────────────┤
|
||||
│ .151 – .190 │ Управление фильтрами (40 шт.) │
|
||||
├─────────────────┼─────────────────────────────────────────┤
|
||||
│ .191 – .230 │ IPMI фильтров (40 шт.) │
|
||||
├─────────────────┼─────────────────────────────────────────┤
|
||||
│ .231 – .235 │ SPFS (management + IPMI) (5 шт.) │
|
||||
├─────────────────┼─────────────────────────────────────────┤
|
||||
│ .241 – .245 │ СПХД (management + IPMI) (5 шт.) │
|
||||
├─────────────────┼─────────────────────────────────────────┤
|
||||
│ .254 │ Шлюз по умолчанию (криптошлюз) │
|
||||
└────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
Основные группы устройств:
|
||||
|
||||
- **Байпасы** (.1–.128) — наибольший диапазон, поскольку количество байпасов определяется количеством каналов связи оператора и может быть значительным;
|
||||
- **Балансировщики** (.131–.140) — management-интерфейсы балансировщиков (микросервер);
|
||||
- **BMC балансировщиков** (.141–.150) — BMC (Baseboard Management Controller) — аналог IPMI у фильтров, позволяет управлять аппаратной частью балансировщика даже при выходе из строя основного управляющего модуля;
|
||||
- **Фильтры** (.151–.190) — management-интерфейсы фильтров;
|
||||
- **IPMI фильтров** (.191–.230) — интерфейсы IPMI (Intelligent Platform Management Interface) для аппаратного управления серверами фильтров;
|
||||
- **SPFS** (.231–.235) — серверы предварительного формирования списков;
|
||||
- **СПХД** (.241–.245) — серверы предварительного хранения данных (syslog-серверы), используемые для хранения системных журналов со всех устройств площадки.
|
||||
|
||||
## 10.3. Шлюз по умолчанию — криптошлюз «Континент»
|
||||
|
||||
Адрес **.254** в подсети управления закреплён за **криптошлюзом «Континент»**, который является **шлюзом по умолчанию** для всех устройств площадки.
|
||||
|
||||
```text
|
||||
Устройства площадки ТСПУ
|
||||
┌──────────────────────────┐
|
||||
│ Байпасы │
|
||||
│ Балансировщики │──── .254 ────► Криптошлюз ──── VPN ────► ЦСУ
|
||||
│ Фильтры │ «Континент»
|
||||
│ SPFS, СПХД │
|
||||
└──────────────────────────┘
|
||||
```
|
||||
|
||||
Криптошлюз устанавливает **VPN-соединение** через публичные интернет-каналы с аналогичным (но более мощным) криптошлюзом на стороне ЦСУ. Через этот VPN осуществляется весь management-трафик: доступ к устройствам, сбор логов, мониторинг, обновление ПО и загрузка списков фильтрации.
|
||||
|
||||
Каждая площадка ТСПУ связана **с обеими площадками ЦСУ** (основной и резервной), что обеспечивает отказоустойчивость управления.
|
||||
|
||||
## 10.4. Подсеть логирования (единая для всех ТСПУ)
|
||||
|
||||
Помимо основной подсети управления (/24), в сегменте управления присутствует **отдельная подсеть логирования**. Эта подсеть используется для лог-интерфейсов фильтров — выделенных высокопроизводительных интерфейсов (DPDK), через которые передаются журналы соединений (connection log).
|
||||
|
||||
Ключевая особенность: подсеть логирования **единая и одинаковая** для всех площадок ТСПУ по всей стране. Это допустимо, поскольку данная подсеть **не выходит за пределы** конкретной площадки — нет необходимости обращаться извне к лог-интерфейсам устройств. Лог-интерфейсы не имеют полноценного IP-стека и не обрабатывают входящие пакеты (невозможно их «пропинговать»), что сделано для повышения производительности.
|
||||
|
||||
Системное логирование (syslog) при этом отправляется **через management-интерфейс**, а не через лог-интерфейс. Журналы соединений (connection log) — напротив, по умолчанию отправляются через **лог-интерфейс** (DPDK). Все системные логи с устройств площадки сохраняются на **СПХД** (серверы предварительного хранения данных), что обеспечивает возможность ретроспективного анализа событий на фильтрах, балансировщиках и байпасах.
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 9: Центральная система управления](09.md) · [Раздел 11: Фильтр: аппаратная платформа →](11.md)
|
||||
140
chapters/11.md
Normal file
140
chapters/11.md
Normal file
@@ -0,0 +1,140 @@
|
||||
# 11. Фильтр: аппаратная платформа
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 10: Сегмент управления ТСПУ](10.md)
|
||||
|
||||
---
|
||||
|
||||
## 11.1. Младшая линейка: EcoFilter 2020/2040
|
||||
|
||||
Фильтры выпускаются в двух линейках. **Младшая линейка** включает модели:
|
||||
|
||||
| Модель | Количество 10G-интерфейсов для трафика |
|
||||
| ---------------- | -------------------------------------- |
|
||||
| **EcoFilter 20** | 2 × 10 Гбит/с |
|
||||
| **EcoFilter 40** | 4 × 10 Гбит/с |
|
||||
|
||||
Модели младшей линейки отличаются от старшей только количеством десятигигабитных интерфейсов для обработки трафика. Внутренняя архитектура, программное обеспечение и принципы работы — одинаковы.
|
||||
|
||||
## 11.2. Старшая линейка: EcoFilter 4080/4120/4160
|
||||
|
||||
**Старшая линейка** включает модели с большим количеством интерфейсов:
|
||||
|
||||
| Модель | Количество 10G-интерфейсов для трафика |
|
||||
| -------------------- | -------------------------------------- |
|
||||
| **EcoFilter 4080** | 8 × 10 Гбит/с |
|
||||
| **EcoFilter 4120** | 12 × 10 Гбит/с |
|
||||
| **EcoFilter 4160** | 16 × 10 Гбит/с |
|
||||
|
||||
Как видно из названий, номер модели напрямую связан с количеством интерфейсов: **40**80 → **8**×10G, **41**20 → **12**×10G, **41**60 → **16**×10G.
|
||||
|
||||
Все модели обеих линеек:
|
||||
|
||||
- монтируются в 19-дюймовую стойку, форм-фактор **1U**;
|
||||
- оснащены **двумя блоками питания** (постоянного или переменного тока), заменяемыми на горячую;
|
||||
- имеют **вентиляторы**, заменяемые на горячую;
|
||||
- имеют порты **Console**, **Management** и **лог-интерфейсы** на передней панели.
|
||||
|
||||
> **Примечание о производительности.** Маркетинговые материалы указывают производительность до 160 Гбит/с, однако эта цифра относится к функционалу NAT-трансляции, который в проекте ТСПУ не используется. Реальная производительность в режиме DPI-фильтрации существенно ниже и зависит от профиля трафика.
|
||||
|
||||
## 11.3. Модели 2019 года (пилотный проект, Урал)
|
||||
|
||||
Модели 2019 года установлены на **пилотном проекте** (Уральский регион) и продолжают там работать.
|
||||
|
||||
### 11.3.1. Процессоры Intel Xeon 2695/2699, 18/22 ядра, 128/256 ГБ RAM
|
||||
|
||||
| Параметр | EcoFilter 4080 | EcoFilter 4120 / 4160 |
|
||||
| ----------------------- | --------------------------- | --------------------------- |
|
||||
| **Процессор** | Intel Xeon 2695 | Intel Xeon 2699 |
|
||||
| **Количество ядер** | 18 | 22 |
|
||||
| **Оперативная память** | 128 ГБ | 256 ГБ |
|
||||
| **Накопитель** | SSD 32 ГБ | SSD 32 ГБ |
|
||||
| **Блоки питания** | 2 (AC или DC), hot-swap | 2 (AC или DC), hot-swap |
|
||||
|
||||
На передней панели расположены разъёмы Console, Management и лог-интерфейс. На задней панели — два медных логирующих порта и от 8 до 16 десятигигабитных интерфейсов для обработки трафика.
|
||||
|
||||
### 11.3.2. Фиксированные сетевые интерфейсы
|
||||
|
||||
В моделях 2019 года сетевые интерфейсы для обработки трафика **встроены** в платформу — заменить или поменять интерфейсные платы невозможно. Количество и тип портов определяются моделью на этапе производства.
|
||||
|
||||
## 11.4. Модели 2020 года (федеральный проект)
|
||||
|
||||
Модели 2020 года поставляются в рамках **федерального проекта** и имеют ряд улучшений по сравнению с моделями 2019 года.
|
||||
|
||||
### 11.4.1. Процессор Intel Xeon Gold 6212, 24 ядра, 192/384 ГБ RAM
|
||||
|
||||
| Параметр | EcoFilter 4080 | EcoFilter 4120 / 4160 |
|
||||
| ----------------------- | --------------------------- | --------------------------- |
|
||||
| **Процессор** | Intel Xeon Gold 6212 | Intel Xeon Gold 6212 |
|
||||
| **Количество ядер** | 24 | 24 |
|
||||
| **Оперативная память** | 192 ГБ | 384 ГБ |
|
||||
| **Накопитель** | SSD 32 ГБ | SSD 32 ГБ |
|
||||
| **Блоки питания** | 2 (AC или DC), hot-swap | 2 (AC или DC), hot-swap |
|
||||
|
||||
Процессор нового поколения (**Gold 6212** вместо серии 2695/2699) обеспечивает большее количество ядер (24 против 18/22) и поддержку большего объёма оперативной памяти.
|
||||
|
||||
### 11.4.2. Сменные сетевые интерфейсы, 4× SFP+ лог-порта
|
||||
|
||||
Ключевые отличия от моделей 2019 года:
|
||||
|
||||
- **Сменные сетевые интерфейсы** — интерфейсные платы для обработки трафика можно вытаскивать и заменять, что упрощает обслуживание и позволяет адаптировать конфигурацию под конкретную площадку;
|
||||
- **Лог-интерфейсы** — вместо двух медных портов на задней панели теперь **4 порта SFP+ (10 Гбит/с)** для логирования.
|
||||
|
||||
Поставщики аппаратных платформ для федерального проекта могут быть **разными** (например, стандартная «голубая» платформа RDP.ru или чёрные платформы от вендора Lanner), поэтому внешний вид может отличаться. Однако внутренняя аппаратная начинка и принципы работы остаются одинаковыми.
|
||||
|
||||
## 11.5. Разделение интерфейсов: LAN (чётные) / WAN (нечётные)
|
||||
|
||||
Все интерфейсы фильтра, предназначенные для обработки трафика, **строго разделены** на две группы:
|
||||
|
||||
```text
|
||||
Передняя панель фильтра (пример EcoFilter 4160)
|
||||
|
||||
┌──────────────────────────────────────────────────┐
|
||||
│ Console Mgmt Log │
|
||||
│ │
|
||||
│ Интерфейсы для трафика: │
|
||||
│ │
|
||||
│ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ... │
|
||||
│ │ 0 │ │ 1 │ │ 2 │ │ 3 │ │ 4 │ │ 5 │ │
|
||||
│ │LAN │ │WAN │ │LAN │ │WAN │ │LAN │ │WAN │ │
|
||||
│ └────┘ └────┘ └────┘ └────┘ └────┘ └────┘ │
|
||||
│ чёт. нечёт. чёт. нечёт. чёт. нечёт. │
|
||||
└──────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
| Тип порта | Нумерация | Направление |
|
||||
| --------- | ------------- | --------------------------------- |
|
||||
| **LAN** | Чётные (0, 2, 4, 6...) | В сторону абонентов (от балансировщика) |
|
||||
| **WAN** | Нечётные (1, 3, 5, 7...) | В сторону интернета (к балансировщику) |
|
||||
|
||||
Этот принцип чётных/нечётных портов **един** для всех моделей и поколений фильтров. Он же используется на балансировщиках EcoFilter Balancer (но **не соблюдается** на Eco Highway — подробнее в [разделе 7.4.1](07.md)).
|
||||
|
||||
Разделение LAN/WAN прослеживается через всё оборудование ТСПУ — от байпасов через балансировщики до фильтров. Это фундаментальный принцип архитектуры: трафик от абонентов всегда приходит со стороны LAN, трафик из интернета — со стороны WAN.
|
||||
|
||||
## 11.6. История платформы: от CGNAT (2013) к DPI-фильтру
|
||||
|
||||
Платформа фильтра имеет длительную историю развития, начавшуюся **в 2013 году** с устройства **CGNAT** (Carrier-Grade NAT), предназначенного для трансляции адресов у операторов связи. Поскольку платформа изначально создавалась для операторского применения, часть внутренней архитектуры (сессии, трансляции, понятия LAN/WAN) заточена под этот сценарий — что объясняет некоторые особенности, с которыми приходится сталкиваться при эксплуатации в режиме DPI-фильтра.
|
||||
|
||||
```text
|
||||
2013 CGNAT (трансляция адресов)
|
||||
│
|
||||
├──── URL-фильтрация
|
||||
│
|
||||
├──── PPPoE BRAS (не используется в проекте ТСПУ)
|
||||
│
|
||||
├──── Router (параллельная ветка, не используется)
|
||||
│
|
||||
└──── DPI (распознавание протоколов) ◄── используется в проекте ТСПУ
|
||||
```
|
||||
|
||||
Из всего доступного функционала платформы в проекте ТСПУ используются только **два модуля**:
|
||||
|
||||
| Модуль | Назначение |
|
||||
| -------------- | ------------------------------------------------------------- |
|
||||
| **EcoFilter** | Фильтрация трафика по спискам (реестр РКН, DPI-листы) |
|
||||
| **EcoDPI** | Распознавание трафика приложений вплоть до 7-го уровня модели OSI |
|
||||
|
||||
Остальной функционал (NAT, BRAS, QoS, маршрутизация) доступен в прошивке, но **не задействован** в проекте ТСПУ.
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 10: Сегмент управления ТСПУ](10.md) · [Раздел 12: Сессии и трансляции на фильтре →](12.md)
|
||||
191
chapters/12.md
Normal file
191
chapters/12.md
Normal file
@@ -0,0 +1,191 @@
|
||||
# 12. Сессии и трансляции на фильтре
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 11: Фильтр: аппаратная платформа](11.md)
|
||||
|
||||
---
|
||||
|
||||
## 12.1. Понятие сессии: local IP:port + global IP:port + remote IP:port
|
||||
|
||||
Вся обработка трафика на фильтре построена на понятии **сессии**. Сессия — это запись, описывающая конкретное соединение между абонентом и удалённым ресурсом. Каждая сессия содержит следующие поля:
|
||||
|
||||
```text
|
||||
<направление> <протокол> <local IP>:<port> <global IP>:<port> <remote IP>:<port> <время> <тайм-аут>
|
||||
```
|
||||
|
||||
| Поле | Описание |
|
||||
| ----------------- | ----------------------------------------------------------- |
|
||||
| **Направление** | Egress (от абонента) или Ingress (к абоненту) — по первому пакету |
|
||||
| **Протокол** | Протокол L4: TCP, UDP, ICMP |
|
||||
| **Local IP:port** | IP-адрес и порт абонента (серый, до NAT) |
|
||||
| **Global IP:port**| IP-адрес и порт после NAT-трансляции (белый) |
|
||||
| **Remote IP:port**| IP-адрес и порт удалённого ресурса в интернете |
|
||||
| **Время** | Время последнего пакета в рамках данной сессии |
|
||||
| **Тайм-аут** | Время, через которое сессия будет удалена при отсутствии трафика |
|
||||
|
||||
Сессия создаётся автоматически при прохождении первого пакета нового соединения через фильтр. Все последующие пакеты в рамках этого же соединения привязываются к уже существующей сессии.
|
||||
|
||||
## 12.2. Понятие трансляции: local IP:port ↔ global IP:port
|
||||
|
||||
**Трансляция** — это более простая сущность, описывающая связку между локальным (серым) адресом абонента и глобальным (белым) адресом из NAT-пула:
|
||||
|
||||
```text
|
||||
<local IP>:<port> ↔ <global IP>:<port>
|
||||
```
|
||||
|
||||
В отличие от сессии, трансляция **не содержит** remote-адреса. Это внутренняя абстракция фильтра, описывающая, каким образом транслируется адрес конкретного абонента.
|
||||
|
||||
Для просмотра трансляций используется команда `show xl` (в отличие от `show session` для сессий).
|
||||
|
||||
## 12.3. Режим без NAT: local = global
|
||||
|
||||
В проекте ТСПУ **NAT-трансляция не используется** — фильтр работает как прозрачное L2-устройство и не изменяет IP-адреса в пакетах. В этом режиме:
|
||||
|
||||
- **Local IP** всегда **совпадает** с **Global IP**;
|
||||
- Local port всегда совпадает с Global port;
|
||||
- Для IPv6-трафика NAT в принципе отсутствует.
|
||||
|
||||
```text
|
||||
Режим с NAT (не используется в ТСПУ):
|
||||
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
|
||||
│ Local IP │ ──► │ Global IP │ ──► │ Remote IP │
|
||||
│ 10.0.0.1:80 │ │ 203.0.113.5 │ │ 93.184.216.34│
|
||||
└──────────────┘ └──────────────┘ └──────────────┘
|
||||
|
||||
Режим без NAT (используется в ТСПУ):
|
||||
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
|
||||
│ Local IP │ = │ Global IP │ ──► │ Remote IP │
|
||||
│ 10.0.0.1:80 │ │ 10.0.0.1:80 │ │ 93.184.216.34│
|
||||
└──────────────┘ └──────────────┘ └──────────────┘
|
||||
```
|
||||
|
||||
Несмотря на то, что в режиме без NAT поля Local и Global дублируются, структура сессии остаётся прежней — это наследие архитектуры платформы, начинавшейся как CGNAT-устройство (подробнее — в [разделе 11.6](11.md)). На практике это означает, что команды фильтрации с ключевым словом `global` в нашем проекте **не имеют большого смысла** — достаточно использовать `local` и `remote`.
|
||||
|
||||
## 12.4. Направление сессии: Egress (от абонента) / Ingress (к абоненту)
|
||||
|
||||
Каждая сессия имеет **направление**, которое определяется **по первому пакету**, создавшему эту сессию:
|
||||
|
||||
| Направление | Первый пакет пришёл со стороны | Значение |
|
||||
| ----------- | ------------------------------ | --------------------------------- |
|
||||
| **Egress** | LAN-порт (абонент) | Абонент инициировал соединение |
|
||||
| **Ingress** | WAN-порт (интернет) | Соединение инициировано извне |
|
||||
|
||||
Направление фиксируется **один раз** в момент создания сессии и больше не меняется. Никакого другого смысла, кроме указания стороны первого пакета, у направления нет.
|
||||
|
||||
Типичный сценарий: абонент открывает веб-страницу — первый SYN-пакет приходит со стороны LAN, сессия создаётся как **Egress**. Если же к абоненту приходит входящее соединение из интернета — первый пакет приходит со стороны WAN, сессия создаётся как **Ingress**.
|
||||
|
||||
## 12.5. Принцип: локальный IP абонента всегда на первом месте
|
||||
|
||||
Независимо от направления трафика, фильтр **всегда записывает** локальный IP-адрес абонента в поле **Local IP** — первое поле адресов в сессии:
|
||||
|
||||
```text
|
||||
Пакет от абонента (LAN → WAN):
|
||||
┌─────────────────────────────────────────────────────┐
|
||||
│ Source IP: 10.0.0.1 → записывается в Local IP │
|
||||
│ Dest IP: 93.184.216.34 → записывается в Remote IP│
|
||||
└─────────────────────────────────────────────────────┘
|
||||
|
||||
Пакет к абоненту (WAN → LAN):
|
||||
┌─────────────────────────────────────────────────────┐
|
||||
│ Source IP: 93.184.216.34 → записывается в Remote IP│
|
||||
│ Dest IP: 10.0.0.1 → записывается в Local IP │
|
||||
└─────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
То есть для пакетов со стороны LAN: Source IP → Local IP, Destination IP → Remote IP.
|
||||
Для пакетов со стороны WAN: поля **меняются местами** — Destination IP → Local IP, Source IP → Remote IP.
|
||||
|
||||
Это **крайне важный принцип** для траблшутинга. Если при просмотре сессий в поле Local IP появляются интернет-адреса (которые там быть не должны), это признак проблемы на пути прохождения трафика — например, **перепутки LAN/WAN** (подробнее — в [разделе 24.6](24.md)).
|
||||
|
||||
## 12.6. Связь трансляций и сессий: одна трансляция — много сессий
|
||||
|
||||
В рамках одной трансляции может существовать **несколько сессий**:
|
||||
|
||||
```text
|
||||
Трансляция (одна):
|
||||
10.0.0.1:12345 ↔ 10.0.0.1:12345
|
||||
|
||||
Сессия 1: 10.0.0.1:12345 → 93.184.216.34:443
|
||||
Сессия 2: 10.0.0.1:12345 → 151.101.1.69:443
|
||||
Сессия 3: 10.0.0.1:12345 → 104.16.132.229:80
|
||||
...
|
||||
Сессия N: 10.0.0.1:12345 → 8.8.8.8:53
|
||||
```
|
||||
|
||||
Логика жизненного цикла:
|
||||
|
||||
1. Проходит первый пакет нового соединения → создаётся **трансляция** и одновременно с ней первая **сессия**;
|
||||
2. Если с того же локального адреса и порта устанавливаются соединения к другим ресурсам → создаются **новые сессии** в рамках той же трансляции;
|
||||
3. Сессии удаляются индивидуально по своим тайм-аутам;
|
||||
4. Трансляция **удаляется только после того**, как умерла последняя сессия в её рамках.
|
||||
|
||||
Пример: один абонентский порт может иметь одну трансляцию и сотни связанных сессий к различным ресурсам.
|
||||
|
||||
## 12.7. Тайм-ауты сессий и трансляций
|
||||
|
||||
Тайм-ауты для сессий и трансляций задаются **раздельно** в секции NAT Defaults конфигурации фильтра (подробнее — в [разделе 15.3](15.md)):
|
||||
|
||||
- **Тайм-аут сессии** — время с момента последнего пакета, после которого сессия удаляется;
|
||||
- **Тайм-аут трансляции** — время с момента удаления последней связанной сессии, после которого удаляется сама трансляция.
|
||||
|
||||
Параметры тайм-аутов устанавливаются в секции NAT Defaults в качестве значений по умолчанию. При создании конкретного пула эти значения наследуются, но могут быть **переопределены** на уровне пула, если необходимо.
|
||||
|
||||
В выводе команды `show session` для каждой сессии отображаются:
|
||||
- **Время последнего пакета** — когда был последний пакет в рамках данной сессии;
|
||||
- **Оставшееся время жизни** — через сколько сессия будет удалена при отсутствии нового трафика.
|
||||
|
||||
## 12.8. Команды: `show session`, `show xl`, фильтрация по `local`/`remote`, pipe и count
|
||||
|
||||
### Основные команды
|
||||
|
||||
| Команда | Назначение |
|
||||
| ---------------- | ----------------------------------- |
|
||||
| `show session` | Просмотр таблицы сессий |
|
||||
| `show xl` | Просмотр таблицы трансляций |
|
||||
|
||||
### Фильтрация по адресам
|
||||
|
||||
Обе команды поддерживают фильтрацию по ключевым словам:
|
||||
|
||||
| Ключевое слово | Фильтрация по | Пример |
|
||||
| -------------- | ------------------------- | ----------------------------------------- |
|
||||
| `local` | Локальный IP-адрес | `show session local 10.0.0.1` |
|
||||
| `global` | Глобальный IP-адрес | В проекте ТСПУ не имеет смысла (= local) |
|
||||
| `remote` | Удалённый IP-адрес | `show session remote 93.184.216.34` |
|
||||
| `la` | Локальный IP + порт | `show session la 10.0.0.1:12345` |
|
||||
| `ga` | Глобальный IP + порт | В проекте ТСПУ не имеет смысла (= la) |
|
||||
| `ra` | Удалённый IP + порт | `show session ra 93.184.216.34:443` |
|
||||
|
||||
В контексте проекта ТСПУ (без NAT) наиболее полезны фильтры `local` и `remote`, поскольку `global` всегда дублирует `local`.
|
||||
|
||||
### Pipe-операторы
|
||||
|
||||
Результат вывода можно обработать через **pipe** (`|`), поддерживающий несколько операторов:
|
||||
|
||||
| Оператор | Назначение |
|
||||
| ----------- | ------------------------------------------------- |
|
||||
| `include` | Показать только строки, содержащие заданный паттерн |
|
||||
| `exclude` | Исключить строки, содержащие заданный паттерн |
|
||||
| `count` | Подсчитать количество строк в выводе |
|
||||
| `more` | Постраничный вывод |
|
||||
|
||||
Pipe-операторы можно **комбинировать последовательно**. Пример:
|
||||
|
||||
```text
|
||||
show session local 10.0.0.1 | include 6881 | count
|
||||
```
|
||||
|
||||
Эта команда выведет количество сессий абонента `10.0.0.1`, в которых присутствует порт `6881` (характерный для BitTorrent).
|
||||
|
||||
### Удалённый доступ к сессиям
|
||||
|
||||
API для удалённого доступа к данным фильтра отсутствует. Однако можно получить информацию удалённо через **SSH-команду**:
|
||||
|
||||
```text
|
||||
ssh admin@<IP-фильтра> "show session local 10.0.0.1"
|
||||
```
|
||||
|
||||
Соединение с фильтром устанавливается, команда выполняется, результат возвращается на терминал. Дальнейшая обработка выполняется средствами операционной системы (bash-скрипты, grep и т.д.). Внутренние pipe-операторы фильтра при удалённом вызове через SSH могут **не работать** — в этом случае следует использовать внешние средства обработки вывода.
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 11: Фильтр: аппаратная платформа](11.md) · [Раздел 13: Фильтр: первоначальная настройка и CLI →](13.md)
|
||||
178
chapters/13.md
Normal file
178
chapters/13.md
Normal file
@@ -0,0 +1,178 @@
|
||||
# 13. Фильтр: первоначальная настройка и CLI
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 12: Сессии и трансляции на фильтре](12.md)
|
||||
|
||||
---
|
||||
|
||||
## 13.1. Подключение: консоль (115200 8N1) и SSH (порт 22)
|
||||
|
||||
Доступ к фильтру осуществляется двумя способами:
|
||||
|
||||
| Способ | Параметры |
|
||||
| -------------- | ------------------------------------------------ |
|
||||
| **Консоль** | 115200 бод, 8 бит данных, без паритета, 1 стоп-бит (8N1), контроль потока выключен |
|
||||
| **SSH** | Порт 22, стандартный доступ |
|
||||
|
||||
Расположение консольного порта на корпусе **отличается** в зависимости от модели и года выпуска — на каждом устройстве порт подписан. Настройки консоли стандартные и менять их необходимости нет.
|
||||
|
||||
## 13.2. Логин по умолчанию: admin / econat
|
||||
|
||||
При заводской прошивке на фильтре настроена учётная запись по умолчанию:
|
||||
|
||||
- **Логин:** `admin`
|
||||
- **Пароль:** `econat`
|
||||
|
||||
Данного пользователя можно удалить и создать новых (подробнее о настройке пользователей — в [разделе 14.4](14.md)).
|
||||
|
||||
## 13.3. Операционный режим (>) и конфигурационный режим (#)
|
||||
|
||||
CLI фильтра имеет **два режима** работы:
|
||||
|
||||
| Режим | Приглашение | Назначение |
|
||||
| ------------------------ | ----------- | --------------------------------------------------------- |
|
||||
| **Операционный** | `>` | Просмотр информации: команды `show`, мониторинг |
|
||||
| **Конфигурационный** | `#` | Изменение настроек, управление прошивками, перезагрузка |
|
||||
|
||||
Переход из операционного в конфигурационный режим выполняется командой **`config`**.
|
||||
|
||||
В операционном режиме доступны команды просмотра (`show session`, `show interface` и т.д.). В конфигурационном режиме доступны все команды изменения параметров, а также управление прошивками (`firmware`), перезагрузка устройства и другие административные операции.
|
||||
|
||||
## 13.4. Навигация по дереву конфигурации: system, pools, access-lists
|
||||
|
||||
Конфигурация фильтра организована в виде **дерева** с тремя основными разделами:
|
||||
|
||||
```text
|
||||
/ (корень)
|
||||
├── system ← все основные настройки устройства
|
||||
│ ├── mng-if ← management-интерфейс
|
||||
│ ├── serial ← консольный порт
|
||||
│ ├── terminal ← SSH-настройки
|
||||
│ ├── users ← пользователи
|
||||
│ ├── nat-defaults← параметры сессий, тайм-аутов
|
||||
│ ├── dpi ← настройки DPI
|
||||
│ └── ...
|
||||
├── pools ← пулы обработки трафика
|
||||
└── access-lists ← списки контроля доступа (ACL)
|
||||
```
|
||||
|
||||
При заводской прошивке в дефолтной конфигурации **отсутствуют** пулы и access-листы — их необходимо создавать вручную.
|
||||
|
||||
### 13.4.1. Переход в раздел, exit (..), root (/)
|
||||
|
||||
Навигация по дереву конфигурации выполняется следующим образом:
|
||||
|
||||
| Действие | Команда / клавиша | Пример |
|
||||
| ------------------------------- | ----------------- | -------------------------- |
|
||||
| Перейти в раздел | Имя раздела | `system` → переход в system |
|
||||
| Перейти на уровень выше | `..` или `exit` | Из mng-if → обратно в system |
|
||||
| Вернуться в корень конфигурации | `/` или `root` | Из любого уровня → в корень |
|
||||
|
||||
Пример навигации:
|
||||
|
||||
```text
|
||||
# system ← перешли в system
|
||||
# (system) mng-if ← перешли в management-интерфейс
|
||||
# (mng-if) .. ← вернулись в system
|
||||
# (system) serial ← перешли в serial
|
||||
# (serial) / ← вернулись в корень
|
||||
#
|
||||
```
|
||||
|
||||
На практике наиболее удобны **`..`** (на уровень выше) и **`/`** (в корень).
|
||||
|
||||
### 13.4.2. Автодополнение (Tab), история команд (↑↓), справка (?)
|
||||
|
||||
CLI поддерживает стандартный набор средств навигации:
|
||||
|
||||
| Клавиша / команда | Действие |
|
||||
| --------------------- | --------------------------------------------------------- |
|
||||
| **Tab** | Автодополнение команды (если единственный вариант) |
|
||||
| **↑ / ↓** | Переход по истории введённых команд |
|
||||
| **?** | Показать все доступные команды на текущем уровне |
|
||||
| **часть_команды + ?** | Показать команды, начинающиеся с введённого текста |
|
||||
| **!** | Показать доступные ветки конфигурации на текущем уровне |
|
||||
|
||||
## 13.5. Применение конфигурации: `apply`, сохранение: `wr`
|
||||
|
||||
Изменения в конфигурации **не применяются немедленно**. Процесс состоит из двух шагов:
|
||||
|
||||
```text
|
||||
Внесение изменений ──► apply ──► wr
|
||||
│ │ │
|
||||
│ │ └─ Сохранение в startup-config
|
||||
│ │ (переживёт перезагрузку)
|
||||
│ │
|
||||
│ └─ Применение к running-config
|
||||
│ (проверка синтаксиса, активация)
|
||||
│
|
||||
└─ Изменения только в буфере
|
||||
(не активны, не сохранены)
|
||||
```
|
||||
|
||||
| Команда | Действие |
|
||||
| --------- | --------------------------------------------------------------------------- |
|
||||
| **`apply`** | Проверяет синтаксическую корректность и применяет конфигурацию. Выдаёт сообщение об успехе или ошибке. Конфигурация становится активной, но **не сохраняется** при перезагрузке |
|
||||
| **`wr`** | Сохраняет текущую конфигурацию в **startup-config**. После перезагрузки устройство загрузится с сохранённой конфигурацией |
|
||||
|
||||
Если после `apply` не выполнить `wr` и перезагрузить устройство — оно вернётся к предыдущей сохранённой конфигурации.
|
||||
|
||||
## 13.6. Управление конфигурациями: save, load, copy, clear config
|
||||
|
||||
На фильтре существуют несколько предопределённых конфигураций:
|
||||
|
||||
| Конфигурация | Описание |
|
||||
| ------------------- | ----------------------------------------------------------- |
|
||||
| **Startup config** | Конфигурация, с которой устройство загружается |
|
||||
| **Effective config**| Текущая активная конфигурация (после последнего `apply`) |
|
||||
| **Factory config** | Заводская конфигурация по умолчанию (неизменяемая) |
|
||||
|
||||
Команды управления:
|
||||
|
||||
| Команда | Действие |
|
||||
| --------------------------- | ----------------------------------------------------------- |
|
||||
| `save <имя>` | Сохранить текущую конфигурацию на диск под указанным именем |
|
||||
| `load <имя>` | Загрузить ранее сохранённую конфигурацию |
|
||||
| `load effective` | Загрузить текущую активную конфигурацию (полезно, если кто-то изменил конфиг параллельно) |
|
||||
| `copy <URL>` | Скопировать конфигурацию на внешний сервер по URL |
|
||||
| `clear config` | Сбросить текущую конфигурацию до заводской |
|
||||
|
||||
> **Осторожно с `clear config`:** после выполнения `apply` management-адрес сменится на заводской. Если вы подключены по SSH — **потеряете доступ** к устройству. Останется только возможность подключения через физическую консоль.
|
||||
|
||||
## 13.7. Одновременная работа двух пользователей: ограничения
|
||||
|
||||
Одновременная настройка фильтра двумя пользователями **не рекомендуется**. Механизма совместного редактирования конфигурации на текущий момент не реализовано.
|
||||
|
||||
Проблема: последний, кто выполнит команду `apply`, **полностью перезаписывает** конфигурацию. Все изменения, внесённые другим пользователем и ранее применённые, будут **затёрты**.
|
||||
|
||||
Если вы обнаружили, что на устройстве работает кто-то ещё и вносит изменения, можно периодически выполнять команду `load effective` — это загрузит в ваш буфер текущую активную конфигурацию (с изменениями, внесёнными коллегой).
|
||||
|
||||
## 13.8. «Мышеловка» (trap mode) при незакрытой скобке
|
||||
|
||||
В CLI фильтра существует режим многострочного ввода для списков значений (DNS-серверы, IP-адреса и т.д.). Этот режим активируется, когда вы открываете **скобку**, но **не закрываете** её перед нажатием Enter.
|
||||
|
||||
В результате вы попадаете в особый режим (неофициально называемый **«мышеловкой»**), в котором:
|
||||
|
||||
- невозможно выйти командой `exit` или `..`;
|
||||
- невозможно перейти в корень конфигурации командой `/`;
|
||||
- никакие стандартные команды навигации не работают.
|
||||
|
||||
Способ выхода: **поставить закрывающую скобку**. После этого введённые данные применятся, и CLI вернётся на предыдущий уровень конфигурации.
|
||||
|
||||
Это **не баг, а особенность** (feature) — режим предназначен для построчного ввода списков значений. Если вы попали в него случайно, просто введите закрывающую скобку `)`.
|
||||
|
||||
## 13.9. Ключевое слово `ls` для быстрого просмотра
|
||||
|
||||
При переходе в любую ветку конфигурации можно добавить ключевое слово **`ls`** в конце команды. Это приведёт к тому, что вы не просто перейдёте в указанный раздел, а сразу **увидите его содержимое** на экране.
|
||||
|
||||
```text
|
||||
# system ls ← перейти в system и сразу показать всё содержимое
|
||||
# system mng-if ls ← перейти в mng-if и сразу показать настройки
|
||||
```
|
||||
|
||||
Это удобное сокращение, экономящее время при просмотре конфигурации — вместо двух действий (переход + просмотр) выполняется одно.
|
||||
|
||||
Аналогично, при вводе описаний (description) для интерфейсов и других сущностей значения вводятся **в кавычках**, если они содержат спецсимволы (например, дефис `-` может быть воспринят как оператор, а не как часть строки).
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 12: Сессии и трансляции на фильтре](12.md) · [Раздел 14: Фильтр: конфигурация подсистем →](14.md)
|
||||
232
chapters/14.md
Normal file
232
chapters/14.md
Normal file
@@ -0,0 +1,232 @@
|
||||
# 14. Фильтр: конфигурация подсистем
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 13: Фильтр: первоначальная настройка и CLI](13.md)
|
||||
|
||||
---
|
||||
|
||||
## 14.1. Консольный порт: скорость, тайм-аут неактивности
|
||||
|
||||
В секции настройки консольного порта (`system / serial`) доступны два параметра:
|
||||
|
||||
| Параметр | Описание | Рекомендация |
|
||||
| ---------------------- | ----------------------------------------------- | --------------------------- |
|
||||
| **Скорость порта** | Скорость консольного соединения (по умолчанию 115200) | Не менять |
|
||||
| **Тайм-аут неактивности** | Время до автоматического отключения неактивного пользователя | 5–30 минут (не `never`) |
|
||||
|
||||
По умолчанию тайм-аут неактивности составляет **5 минут**. Можно увеличить до 15 или 30 минут. Значение `never` **не рекомендуется** — при его установке пользователь не будет отключаться по тайм-ауту, что может привести к проблемам (аналогично проблеме SSH-сессий — см. [раздел 14.3.1](#1431-лимит-сессий-20-опасность-never-для-auto-logout)).
|
||||
|
||||
## 14.2. Management-интерфейс: IP, gateway, DNS, allowed IP
|
||||
|
||||
В секции management-интерфейса (`system / mng-if`) настраиваются параметры удалённого доступа к фильтру:
|
||||
|
||||
| Параметр | Описание |
|
||||
| --------------- | ----------------------------------------------------------------- |
|
||||
| **IP-адрес** | Адрес management-интерфейса в подсети управления |
|
||||
| **Gateway** | Шлюз по умолчанию (обычно .254 — криптошлюз «Континент») |
|
||||
| **Name servers**| Список DNS-серверов (можно указать несколько через пробел) |
|
||||
| **Allowed IP** | Список адресов/подсетей, которым разрешён удалённый доступ |
|
||||
|
||||
> **Осторожно:** изменение IP-адреса или allowed IP с последующим `apply` может привести к **потере удалённого доступа** к устройству, если вы подключены по SSH. Единственным способом восстановления в таком случае будет подключение через физическую консоль.
|
||||
|
||||
### 14.2.1. Добавление/удаление записей: `+=` и `-=`
|
||||
|
||||
Для параметров, принимающих списки значений (DNS-серверы, allowed IP и др.), доступны операторы поэлементного изменения:
|
||||
|
||||
| Оператор | Действие | Пример |
|
||||
| -------- | --------------------------------- | ----------------------------------- |
|
||||
| `+=` | Добавить запись к существующему списку | `nameservers += 8.8.8.8` |
|
||||
| `-=` | Удалить запись из списка | `nameservers -= 8.8.8.8` |
|
||||
|
||||
Альтернативный способ — задать весь список одной строчкой через пробел:
|
||||
|
||||
```text
|
||||
nameservers 192.168.1.45 8.8.8.8 8.8.4.4
|
||||
```
|
||||
|
||||
Также можно использовать режим многострочного ввода через скобки (см. [раздел 13.8 — «мышеловка»](13.md)).
|
||||
|
||||
## 14.3. Терминал (SSH): auto-logout, prompt, нумерация строк
|
||||
|
||||
В секции терминала (`system / terminal`) настраиваются параметры SSH-доступа:
|
||||
|
||||
| Параметр | Описание |
|
||||
| --------------------- | ------------------------------------------------------ |
|
||||
| **auto-logout** | Время автоматического отключения неактивной SSH-сессии |
|
||||
| **prompt** | Текст приглашения командной строки |
|
||||
| **Нумерация строк** | Отображение номера введённой команды (инкрементируется с каждым вводом) |
|
||||
|
||||
При вводе значения prompt необходимо использовать **кавычки**, если значение содержит спецсимволы (дефис `-` и др.).
|
||||
|
||||
### 14.3.1. Лимит сессий (20), опасность `never` для auto-logout
|
||||
|
||||
Значение `never` для auto-logout **категорически не рекомендуется**. Причина:
|
||||
|
||||
1. При нестабильном соединении SSH-сессии **обрываются**, но не закрываются на стороне фильтра;
|
||||
2. «Мёртвые» сессии **накапливаются**, не удаляясь по тайм-ауту;
|
||||
3. При достижении лимита в **20 сессий** вы **не сможете** подключиться к устройству по SSH;
|
||||
4. Единственный способ восстановления — подключение через физическую консоль.
|
||||
|
||||
Рекомендуется оставлять auto-logout со значением по умолчанию или устанавливать разумный тайм-аут.
|
||||
|
||||
## 14.4. Пользователи: создание, удаление, уровни доступа, пароли (secret 0 / 15)
|
||||
|
||||
Управление пользователями осуществляется в секции `system / users`:
|
||||
|
||||
| Команда | Действие |
|
||||
| ------------------------------------------ | --------------------------- |
|
||||
| `create user <имя> level <N> secret 0 <пароль>` | Создать пользователя (пароль в открытом виде) |
|
||||
| `create user <имя> level <N> secret 15 <хэш>` | Создать пользователя (пароль в виде хэша) |
|
||||
| `no user <имя>` | Удалить пользователя |
|
||||
|
||||
Параметры пароля:
|
||||
|
||||
| Формат | Описание |
|
||||
| ------------ | ----------------------------------------------------- |
|
||||
| **secret 0** | Пароль задаётся в открытом виде (plain text) |
|
||||
| **secret 15**| Ожидается хэш пароля |
|
||||
|
||||
В конфигурации пароли **хранятся в хэшированном виде** — при просмотре конфигурации открытые пароли не отображаются.
|
||||
|
||||
Пользователь по умолчанию (`admin` / `econat`) может быть удалён. Рекомендуется создать новых пользователей и удалить дефолтного.
|
||||
|
||||
## 14.5. TACACS+: авторизация, fallback на локальную базу
|
||||
|
||||
Фильтр поддерживает внешнюю авторизацию через **TACACS+**. Через TACACS+ работает только **авторизация** (и, возможно, аккаунтинг).
|
||||
|
||||
Ключевые параметры:
|
||||
|
||||
| Параметр | Описание | Важность |
|
||||
| --------------------- | -------------------------------------------------------------- | -------- |
|
||||
| **Fallback (fb on)** | При недоступности TACACS+ авторизовать через локальную базу | **Критично** |
|
||||
| **Service type** | Тип сервиса (shell) — должен совпадать с настройкой на TACACS-сервере | Важно |
|
||||
| **Protocol** | Протокол — должен совпадать с настройкой на TACACS-сервере | Важно |
|
||||
| **Серверы** | IP-адрес/доменное имя + secret для каждого сервера TACACS+ | — |
|
||||
|
||||
> **Важно:** параметр **`fb on`** (fallback) должен быть **включён**. Если он выключен и пользователь отсутствует на TACACS-сервере (или сервер недоступен), авторизация через CLI будет **невозможна**.
|
||||
|
||||
## 14.6. NTP: до 3 серверов, период обновления
|
||||
|
||||
В секции NTP (`system / ntp`) настраивается синхронизация времени:
|
||||
|
||||
- Можно указать до **3 NTP-серверов**;
|
||||
- Настраивается **период обновления** времени.
|
||||
|
||||
Для проверки статуса синхронизации используется команда `show ntp`. Вывод команды может быть не вполне интуитивным — значение `0x24` в статусе указывает на успешную синхронизацию.
|
||||
|
||||
> **Примечание:** в будущих прошивках логика работы со временем планируется к изменению. Вместо задания временного сдвига в отдельных подсистемах будет единая настройка временной зоны для всего устройства, а в подсистемах — выбор между UTC и локальным временем.
|
||||
|
||||
## 14.7. SNMP: community (read-only), traps, allow-ip
|
||||
|
||||
Настройки SNMP (`system / snmp`) стандартны:
|
||||
|
||||
| Параметр | Описание |
|
||||
| --------------- | ----------------------------------------------------------- |
|
||||
| **Community** | Строка community, работает **только на чтение** (read-only). Задавать параметры через SNMP нельзя |
|
||||
| **Traps** | Включение/выключение отправки SNMP-трапов |
|
||||
| **Allow IP** | Список адресов/подсетей, которым разрешён SNMP-доступ (по умолчанию — отовсюду) |
|
||||
| **Description** | Описание устройства |
|
||||
| **Hostname** | Имя устройства |
|
||||
| **Contact** | Контактная информация |
|
||||
|
||||
## 14.8. Системное журналирование (syslog)
|
||||
|
||||
Системное журналирование настраивается в секции `system / syslog` и позволяет отправлять события с фильтра на внешние серверы (СПХД).
|
||||
|
||||
### 14.8.1. Внешние лог-серверы (до 2), hostname, time shift
|
||||
|
||||
| Параметр | Описание |
|
||||
| ----------------- | ------------------------------------------------------------ |
|
||||
| **Enable/disable**| Включение/выключение системного логирования |
|
||||
| **Серверы** | До **2 внешних серверов** (IP-адрес + порт) |
|
||||
| **Hostname** | Имя устройства, которое будет отображаться в syslog-сообщениях на внешнем сервере |
|
||||
| **Time shift** | Временной сдвиг относительно UTC (в минутах) для логов |
|
||||
|
||||
В рамках **пилотного проекта** (Урал) системные логи на внешний сервер не сохранялись. В **федеральном проекте** они должны сохраняться на **СПХД** (серверы предварительного хранения данных), обеспечивая ретроспективный анализ событий на всех устройствах площадки — это крайне полезная возможность, которой часто не хватало на пилоте.
|
||||
|
||||
> **Примечание:** в будущих прошивках параметр time shift планируется заменить на выбор между UTC и локальным временем, а временная зона будет настраиваться единообразно для всего устройства.
|
||||
|
||||
### 14.8.2. Уровни логирования по подсистемам (1=ошибки, 2=предупреждения, 3=информация)
|
||||
|
||||
Для каждой подсистемы фильтра можно индивидуально настроить **уровень подробности** журналирования:
|
||||
|
||||
| Уровень | Название | Содержимое | Рекомендация |
|
||||
| ------- | -------------- | --------------------------------------------------- | ------------------------- |
|
||||
| **1** | Ошибки | Ошибки и критически важные сообщения | По умолчанию, достаточно для большинства случаев |
|
||||
| **2** | Предупреждения | Предупреждения + всё из уровня 1 | Включать при траблшутинге |
|
||||
| **3** | Информация | Информационные сообщения + всё из уровней 1–2 | Только при диагностике |
|
||||
|
||||
По умолчанию для всех подсистем установлен **уровень 1**. Повышать уровень (2 или 3) рекомендуется **только на время диагностики**, поскольку:
|
||||
|
||||
- объём логов при уровне 2–3 **очень большой**;
|
||||
- внутренние логи на устройстве **забиваются быстро**;
|
||||
- разбираться в детальных логах **сложно**.
|
||||
|
||||
Не все подсистемы, указанные в конфигурации, реально существуют в прошивке проекта ТСПУ (например, BRAS отсутствует) — для несуществующих подсистем настройка не имеет эффекта.
|
||||
|
||||
### 14.8.3. Подсистема `all` — максимальный уровень для всех
|
||||
|
||||
Условная подсистема **`all`** позволяет быстро установить уровень логирования для **всех** подсистем одновременно:
|
||||
|
||||
```text
|
||||
verbose all 3 ← установить максимальный уровень для всех подсистем
|
||||
```
|
||||
|
||||
Правило выбора уровня: для каждой подсистемы выбирается **наибольший** из двух значений — установленного для `all` и установленного индивидуально. Например, если `all = 2` и для конкретной подсистемы задано `3`, будет использоваться `3`.
|
||||
|
||||
### 14.8.4. Логирование команд пользователя (уровень fatal)
|
||||
|
||||
Все команды, введённые пользователем, логируются с уровнем **fatal**. Это не означает, что происходит что-то критическое — уровень fatal выбран специально, чтобы команды пользователя **всегда записывались** в логи, независимо от текущих настроек подробности.
|
||||
|
||||
Это полезно для ретроспективного анализа: можно посмотреть, кто, когда и что настраивал на устройстве.
|
||||
|
||||
### 14.8.5. SNMP traps: только уровень fatal
|
||||
|
||||
В SNMP отправляются трапы **только уровня fatal**. События уровней 1–3 (ошибки, предупреждения, информация) в SNMP-трапы **не попадают**.
|
||||
|
||||
## 14.9. Журналирование соединений (connection log) — через лог-интерфейс (DPDK)
|
||||
|
||||
Журналирование соединений (connection log, в терминологии фильтра — «NAT translation log») позволяет логировать каждую создаваемую на устройстве сессию: какой абонент, на какой ресурс, по какому порту обращался.
|
||||
|
||||
Ключевые особенности:
|
||||
|
||||
- Логи отправляются на внешний сервер в специальном формате;
|
||||
- В отличие от syslog, connection log по умолчанию отправляется через **лог-интерфейс** (DPDK), а не через management-интерфейс;
|
||||
- Лог-интерфейс **не имеет IP-адреса** в традиционном смысле — адрес генерируется программно. Пропинговать лог-интерфейс извне **невозможно**: на нём нет сущности, обрабатывающей входящие пакеты. Это сделано для **повышения производительности** — интерфейс отдан под управление DPDK;
|
||||
- Формат логирования настраивается в соответствующей секции конфигурации.
|
||||
|
||||
> **Примечание:** в проекте ТСПУ журналирование соединений в текущей конфигурации может не использоваться.
|
||||
|
||||
## 14.10. Журналирование протоколов (debug logger) — отправка на SPFS
|
||||
|
||||
Секция **debug logger** (несмотря на название «debug», это штатная функциональность) отвечает за отправку **протокольных логов** — результатов распознавания протоколов движком DPI — на серверы **SPFS** для дальнейшего формирования очищенных списков блокировки (подробнее о полном цикле — в [разделе 8](08.md)).
|
||||
|
||||
### 14.10.1. Выбор протоколов (all / конкретные)
|
||||
|
||||
| Параметр | Описание |
|
||||
| ----------------- | ----------------------------------------------------------- |
|
||||
| **Enable** | Включение секции debug logger |
|
||||
| **Protocols** | Список протоколов для логирования: `all` (все) или конкретные (Telegram, WhatsApp и др.) |
|
||||
| **Server + port** | Адрес и порт SPFS-сервера |
|
||||
| **Gateway** | Шлюз по умолчанию для отправки |
|
||||
| **Source port** | Порт источника, с которого отправляются логи |
|
||||
| **Log interface** | Интерфейс для отправки: `log` (по умолчанию) или `management` |
|
||||
|
||||
По умолчанию протоколы установлены в **`all`** — логируются все распознаваемые протоколы. Можно указать только конкретные протоколы, если требуется сузить объём логирования.
|
||||
|
||||
Лог-интерфейс для отправки по умолчанию — **log** (DPDK). Переключение на management **не рекомендуется**, так как производительность отправки значительно снизится.
|
||||
|
||||
### 14.10.2. Количество пакетов на протокол (по умолчанию 30, рекомендуется 3)
|
||||
|
||||
Параметр **количества пакетов** определяет, сколько пакетов из каждой распознанной сессии отправляется в лог:
|
||||
|
||||
| Значение | Описание | Рекомендация |
|
||||
| ------------- | ------------------------------------------------- | ------------------- |
|
||||
| **0** | Без ограничения (отправляются первые 30 пакетов) | По умолчанию |
|
||||
| **3** | Отправляются первые 3 пакета | **Рекомендуется** |
|
||||
| **30** | Максимальное количество | Избыточно |
|
||||
|
||||
Значение **30** (фактически — значение по умолчанию при параметре 0) генерирует **избыточный объём** лог-трафика. По результатам тестирования на Урале, для корректного распознавания достаточно **3 пакетов** — это значение рекомендуется для production-эксплуатации.
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 13: Фильтр: первоначальная настройка и CLI](13.md) · [Раздел 15: Фильтр: настройка интерфейсов и общих параметров →](15.md)
|
||||
123
chapters/15.md
Normal file
123
chapters/15.md
Normal file
@@ -0,0 +1,123 @@
|
||||
# 15. Фильтр: настройка интерфейсов и общих параметров
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 14: Фильтр: конфигурация подсистем](14.md)
|
||||
|
||||
---
|
||||
|
||||
## 15.1. Интерфейсы: enable/disable, description (LACP не используется)
|
||||
|
||||
Фильтр обрабатывает трафик на **уровне L2** — для внешнего наблюдателя устройство представляет собой «прозрачный провод». На пути прохождения трафика **нет L3-интерфейсов**. Если посмотреть на интерфейсы в операционной системе Linux (на которой основано устройство), виден **только management-интерфейс** — все остальные интерфейсы отданы под управление **DPDK** и обрабатываются специализированным программным обеспечением.
|
||||
|
||||
Настройки интерфейсов для пропуска трафика **минимальны**:
|
||||
|
||||
| Действие | Команда |
|
||||
| ------------------ | ------------------------------ |
|
||||
| Включить интерфейс | `enable` |
|
||||
| Выключить интерфейс| `disable` |
|
||||
| Задать описание | `description "текст"` |
|
||||
|
||||
Лог-интерфейсы **жёстко привязаны** к конкретным физическим портам и не могут быть переназначены.
|
||||
|
||||
В конфигурации могут присутствовать настройки протокола **LACP** — в проекте ТСПУ он **не используется**. Эти параметры существуют по умолчанию, их не нужно изменять или удалять.
|
||||
|
||||
## 15.2. NAT Defaults — общие параметры устройства
|
||||
|
||||
Секция `nat-defaults` содержит общие параметры, влияющие на работу всего устройства. Название секции — наследие от CGNAT-платформы, однако параметры применяются ко всему функционалу фильтра, включая DPI.
|
||||
|
||||
### 15.2.1. VLAN Mode: untag / vlan / QinQ — глубина поиска IP-заголовка (всегда QinQ)
|
||||
|
||||
Параметр **VLAN Mode** определяет, насколько глубоко фильтр ищет IP-заголовок внутри Ethernet-фрейма:
|
||||
|
||||
| Значение | Поведение | Применение в ТСПУ |
|
||||
| ------------ | ----------------------------------------------------------------- | ------------------ |
|
||||
| **untag** | IP-заголовок ищется только в нетегированных фреймах. Пакеты с VLAN-тегами пропускаются прозрачно | Нет |
|
||||
| **vlan** | IP-заголовок ищется в пакетах без тегов и с одним VLAN-тегом | Нет |
|
||||
| **QinQ** | IP-заголовок ищется при любом количестве VLAN-тегов: 0, 1 или 2 | **Всегда** |
|
||||
|
||||
В проекте ТСПУ параметр **всегда должен быть установлен в `QinQ`**. При любом другом значении часть трафика (с VLAN-тегами) будет **прозрачно пропускаться** без обработки, что недопустимо.
|
||||
|
||||
### 15.2.2. Sessions per Translation (по умолчанию 4096)
|
||||
|
||||
Параметр задаёт **максимальное количество сессий** в рамках одной трансляции. Значение по умолчанию — **4096**. В проекте ТСПУ менять его не требуется — этого значения достаточно для всех сценариев.
|
||||
|
||||
### 15.2.3. Forward Traffic: всегда ON
|
||||
|
||||
Параметр **Forward Traffic** управляет пересылкой трафика через устройство:
|
||||
|
||||
| Значение | Поведение |
|
||||
| -------- | ------------------------------------------------------------ |
|
||||
| **on** | Трафик проходит через фильтр и отправляется дальше |
|
||||
| **off** | Трафик принимается, но не отправляется (режим зеркала) |
|
||||
|
||||
В проекте ТСПУ параметр **всегда должен быть `on`** (значение по умолчанию). Режим `off` используется только при работе с зеркалированным трафиком, что в данном проекте не применяется.
|
||||
|
||||
### 15.2.4. L2 MTU: максимум 9216 (по RFC)
|
||||
|
||||
Параметр **L2 MTU** определяет максимальный размер кадра на уровне L2. По умолчанию установлено значение **1522**.
|
||||
|
||||
В проекте ТСПУ рекомендуется устанавливать **максимально возможное значение — 9216** (максимум по RFC). Это позволяет полностью исключить проблемы с MTU:
|
||||
|
||||
```text
|
||||
nat-defaults
|
||||
l2-mtu 9216
|
||||
```
|
||||
|
||||
На балансировщиках MTU на интерфейсах также выставляется в районе **9000**, что позволяет закрыть проблему MTU на всей цепочке оборудования ТСПУ.
|
||||
|
||||
### 15.2.5. LLDP: выключен (требование операторов — прозрачность)
|
||||
|
||||
Протокол **LLDP** (Link Layer Discovery Protocol) на фильтрах **должен быть выключен**. Это сделано по требованию операторов связи, которые не хотят видеть оборудование ТСПУ в своей сети.
|
||||
|
||||
Принцип прозрачности: оператор ожидает, что ТСПУ — это «невидимый провод». Если LLDP включён, устройство начинает анонсировать себя в сети оператора, что нарушает эту прозрачность. Например, МТС потребовал отключить LLDP, поскольку устройства ТСПУ появлялись на их схемах сети.
|
||||
|
||||
### 15.2.6. Permit Invalid Flow: всегда ON — приём TCP-сессий без SYN
|
||||
|
||||
Параметр **Permit Invalid Flow** — один из **наиболее критичных** параметров конфигурации. Он **всегда должен быть включён** в проекте ТСПУ.
|
||||
|
||||
**Что он делает:**
|
||||
|
||||
| Значение | Поведение |
|
||||
| -------- | --------------------------------------------------------------- |
|
||||
| **off** | TCP-сессия заводится **только** по TCP SYN-пакету. Пакеты без SYN-флага дропаются |
|
||||
| **on** | TCP-сессия заводится по **любому** TCP-пакету, включая пакеты без SYN |
|
||||
|
||||
**Почему `off` опасен в контексте ТСПУ:**
|
||||
|
||||
1. **Переключение режимов.** При переключении ТСПУ из режима байпаса обратно в рабочий режим (inline) на фильтры мгновенно поступает большой объём трафика — уже установленных TCP-сессий. SYN-пакеты для этих сессий давно прошли. Если `permit invalid flow` выключен, фильтр **дропнет** весь этот трафик. Для абонентов это означает, что **все их TCP-сессии** отвалятся по тайм-ауту и потребуют переустановки;
|
||||
|
||||
2. **Асимметричный трафик.** Если исходящий трафик уходит через один фильтр, а входящий приходит через другой — на одном из фильтров сессия не будет установлена (нет SYN-флага), и трафик будет дропаться.
|
||||
|
||||
С этой проблемой сталкивались **неоднократно** на практике.
|
||||
|
||||
## 15.3. Тайм-ауты сессий и трансляций
|
||||
|
||||
В секции `nat-defaults` также настраиваются **тайм-ауты** для сессий и трансляций (подробнее о сессиях и трансляциях — в [разделе 12](12.md)):
|
||||
|
||||
- Тайм-ауты для **трансляций** и **сессий** задаются **раздельно**;
|
||||
- Параметры различаются по типу протокола (TCP, UDP, ICMP);
|
||||
- Значения в `nat-defaults` являются **значениями по умолчанию**, которые наследуются каждым создаваемым пулом;
|
||||
- При необходимости тайм-ауты могут быть **переопределены** на уровне конкретного пула.
|
||||
|
||||
В секции также присутствует параметр **limiter** — ограничения на количество выделяемых портов для одного пользователя. Этот параметр актуален **только для NAT** и в проекте ТСПУ **не используется**.
|
||||
|
||||
## 15.4. IPv6: включение, диапазон адресов для обработки
|
||||
|
||||
Поддержка IPv6 была добавлена в прошивку позднее основного функционала. Настройка расположена в отдельном разделе:
|
||||
|
||||
| Параметр | Описание |
|
||||
| --------------------- | ------------------------------------------------------------ |
|
||||
| **Enable/disable** | Включение или выключение обработки IPv6-трафика |
|
||||
| **Тайм-ауты** | Отдельные тайм-ауты для IPv6-сессий (по умолчанию можно не менять) |
|
||||
| **Диапазон адресов** | Список IPv6-адресов и VLAN, которые будут обрабатываться |
|
||||
|
||||
В проекте ТСПУ IPv6 должен быть **включён**. По умолчанию в диапазон обработки включены **все IPv6-адреса во всех VLAN** — менять это значение, как правило, не требуется.
|
||||
|
||||
При необходимости можно:
|
||||
|
||||
- **Включить** в обработку только конкретные диапазоны IPv6-адресов;
|
||||
- **Исключить** определённые диапазоны из обработки;
|
||||
- Полностью **отключить** обработку IPv6-трафика (тогда DPI-фильтрация по IPv6 выполняться не будет, трафик пройдёт прозрачно).
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 14: Фильтр: конфигурация подсистем](14.md) · [Раздел 16: Фильтр: ACL и пулы →](16.md)
|
||||
198
chapters/16.md
Normal file
198
chapters/16.md
Normal file
@@ -0,0 +1,198 @@
|
||||
# 16. Фильтр: ACL и пулы — запуск трафика на обработку
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 15: Фильтр: настройка интерфейсов и общих параметров](15.md)
|
||||
|
||||
---
|
||||
|
||||
Чтобы фильтр начал обрабатывать трафик, необходимо выполнить два действия: **создать пул** и **привязать к нему ACL**. Без этих настроек — какие бы DPI-листы ни были сконфигурированы — весь трафик будет прозрачно пропускаться через устройство без какой-либо обработки.
|
||||
|
||||
Это одна из ключевых стадий в пути прохождения пакета через фильтр (подробнее — в [разделе 5.1](05.md)): IP-пакет должен попасть в ACL и в пул, чтобы далее передаваться на обработку движком DPI.
|
||||
|
||||
> **Важно:** при заводской (дефолтной) конфигурации фильтра пулы и ACL **отсутствуют**. Их необходимо создать вручную при первоначальной настройке.
|
||||
|
||||
## 16.1. Создание ACL: `create acl`, правила (allow/deny), протоколы, source/destination, VLAN
|
||||
|
||||
ACL (Access Control List) — это набор правил, определяющих, какой трафик подлежит обработке. Изначально на фильтре нет ни одного ACL — его нужно создать.
|
||||
|
||||
### Создание и переход в ACL
|
||||
|
||||
| Действие | Команда | Пример |
|
||||
| ---------------------- | ------------------------------ | ------------------------- |
|
||||
| Создать ACL | `create acl <имя>` | `create acl aclfake` |
|
||||
| Перейти в ACL | `go to acl<имя>` | `go to aclaclfake` |
|
||||
| Удалить ACL | `no acl <имя>` | `no acl aclfake` |
|
||||
|
||||
> **Обратите внимание:** команда перехода `go to acl<имя>` пишется **слитно** — `aclaclfake`, а не `acl aclfake`. Здесь `acl` — это часть пути, а `aclfake` — название списка.
|
||||
|
||||
### Создание правил
|
||||
|
||||
Внутри ACL создаются правила, каждое из которых определяет, какой трафик разрешить (`allow`) или запретить (`deny`) для обработки:
|
||||
|
||||
```text
|
||||
<номер> allow|deny <протокол> <source> <destination> [vlan <N>|<N-M>]
|
||||
```
|
||||
|
||||
Структура правила:
|
||||
|
||||
| Элемент | Описание | Примеры |
|
||||
| ---------------- | ---------------------------------------------------------------- | ------------------------------ |
|
||||
| **Номер** | Порядковый номер правила (рекомендуется с зазором: 10, 20, 30) | `10`, `20`, `30` |
|
||||
| **Действие** | `allow` (или `permit`) / `deny` — разрешить или запретить | `allow`, `deny` |
|
||||
| **Протокол** | IP, TCP, UDP, ICMP и др. | `ip`, `tcp`, `udp` |
|
||||
| **Source** | Источник: хост, подсеть или `any` (любой) | `any`, `10.0.0.0/8`, `host 1.2.3.4` |
|
||||
| **Destination** | Назначение: хост, подсеть или `any` | `any`, `192.168.0.0/16` |
|
||||
| **VLAN** | Номер или диапазон VLAN (необязательно) | `vlan 100`, `vlan 100-200` |
|
||||
|
||||
Ключевые слова `allow` и `permit` — **синонимы**, можно использовать любое из них.
|
||||
|
||||
### Поведение VLAN по умолчанию
|
||||
|
||||
Если номер VLAN **не указан**, правило автоматически применяется ко **всем VLAN** (0–4095). Это поведение по умолчанию подходит для большинства сценариев в проекте ТСПУ.
|
||||
|
||||
При необходимости можно указать:
|
||||
|
||||
- конкретный VLAN: `vlan 100`
|
||||
- диапазон VLAN: `vlan 100-200`
|
||||
|
||||
### Управление правилами
|
||||
|
||||
| Действие | Команда |
|
||||
| --------------------- | ------------------------ |
|
||||
| Удалить правило | `no <номер>` |
|
||||
| Просмотреть ACL | `ls` (в контексте ACL) |
|
||||
|
||||
Номера правил рекомендуется задавать **с зазором** (10, 20, 30...) — это позволяет вставлять новые правила между существующими без перенумерации.
|
||||
|
||||
### Типовой ACL для проекта ТСПУ
|
||||
|
||||
В проекте ТСПУ, как правило, используется простейший ACL, пропускающий весь IP-трафик на обработку:
|
||||
|
||||
```text
|
||||
create acl aclfake
|
||||
go to aclaclfake
|
||||
10 allow ip any any
|
||||
apply
|
||||
```
|
||||
|
||||
Правила обрабатываются **по порядку номеров** — первое совпавшее правило определяет судьбу пакета. Это аналогично работе ACL на маршрутизаторах: если пакет совпал с правилом `allow`, он направляется в пул; если с правилом `deny` — прозрачно пропускается мимо пула.
|
||||
|
||||
## 16.2. Создание пула: `create pool`, тип = fake (без NAT)
|
||||
|
||||
Пул — логическая сущность, в которую попадает трафик, отобранный ACL, для дальнейшей обработки. В проекте ТСПУ тип пула **всегда** должен быть **fake**.
|
||||
|
||||
### Создание пула
|
||||
|
||||
```text
|
||||
create pool poolfake
|
||||
go to poolpoolfake
|
||||
```
|
||||
|
||||
### Тип пула: fake
|
||||
|
||||
| Тип пула | Описание | Применение в ТСПУ |
|
||||
| ---------- | ----------------------------------------------------------- | ------------------ |
|
||||
| **fake** | «Фейковый» пул — трансляция адресов не выполняется: что пришло, то и ушло | **Всегда** |
|
||||
| Другие типы | Реальная трансляция адресов (NAT) | Не используется |
|
||||
|
||||
Тип `fake` означает, что фильтр **не изменяет** IP-адреса в проходящих пакетах. Это наследие CGNAT-платформы: механизм пулов изначально создавался для трансляции адресов, но в проекте ТСПУ трансляция не нужна. Тем не менее пул **должен быть создан** — без него трафик не попадёт на обработку DPI.
|
||||
|
||||
### Минимальные настройки пула
|
||||
|
||||
| Параметр | Значение | Описание |
|
||||
| ----------- | ------------- | --------------------------------------- |
|
||||
| **type** | `fake` | Тип пула — без трансляции адресов |
|
||||
| **enable** | Включён | Пул должен быть активен |
|
||||
| **acl** | `<имя ACL>` | Привязка ACL к пулу |
|
||||
|
||||
Этих трёх настроек **достаточно** для запуска трафика на обработку.
|
||||
|
||||
## 16.3. Привязка ACL к пулу
|
||||
|
||||
Привязка ACL к пулу выполняется командой `acl` внутри контекста пула:
|
||||
|
||||
```text
|
||||
go to poolpoolfake
|
||||
acl aclfake
|
||||
type fake
|
||||
enable
|
||||
apply
|
||||
```
|
||||
|
||||
Именно привязка ACL к пулу определяет, **какой именно трафик** будет попадать на обработку DPI. Без привязанного ACL пул не будет отбирать трафик, и обработка не начнётся.
|
||||
|
||||
Полная последовательность создания минимальной рабочей конфигурации:
|
||||
|
||||
```text
|
||||
# 1. Создаём ACL
|
||||
create acl aclfake
|
||||
go to aclaclfake
|
||||
10 allow ip any any
|
||||
exit
|
||||
|
||||
# 2. Создаём пул и привязываем ACL
|
||||
create pool poolfake
|
||||
go to poolpoolfake
|
||||
type fake
|
||||
acl aclfake
|
||||
enable
|
||||
exit
|
||||
|
||||
# 3. Применяем и сохраняем
|
||||
apply
|
||||
wr
|
||||
```
|
||||
|
||||
## 16.4. Приоритет пулов
|
||||
|
||||
При наличии нескольких пулов на фильтре трафик может совпасть с ACL **разных пулов**. В этом случае пакет попадёт в пул с **наивысшим приоритетом**.
|
||||
|
||||
| Параметр | Описание |
|
||||
| ------------- | ----------------------------------------------------------- |
|
||||
| **priority** | Числовое значение приоритета пула (чем выше — тем приоритетнее) |
|
||||
|
||||
На практике в проекте ТСПУ обычно используется **один пул**, поэтому настройка приоритета, как правило, не требуется. Однако при необходимости разделения трафика на разные пулы (например, для разных DPI-листов или разных политик обработки) приоритеты позволяют контролировать порядок отбора.
|
||||
|
||||
## 16.5. Connection logging в пуле
|
||||
|
||||
Параметр **connection log** в пуле управляет журналированием соединений (NAT translation log) — записью информации о каждой создаваемой сессии: какой абонент, на какой ресурс, по какому порту обращался.
|
||||
|
||||
| Значение | Описание |
|
||||
| -------- | ------------------------------------------------------- |
|
||||
| **on** | Журналирование соединений для данного пула включено |
|
||||
| **off** | Журналирование отключено |
|
||||
|
||||
По умолчанию connection logging **включён**. В проекте ТСПУ этот параметр может быть как задействован, так и не использоваться — зависит от конкретной площадки и требований DevOps-команды.
|
||||
|
||||
Помимо connection log, в пуле присутствуют:
|
||||
|
||||
- **Тайм-ауты** — наследуются из секции `nat-defaults` при создании пула (подробнее — в [разделе 15.3](15.md)). При необходимости могут быть переопределены на уровне пула;
|
||||
- **Ограничения на пользователей (limiter)** — актуальны только для NAT, в проекте ТСПУ **не используются**;
|
||||
- **Параметр PIN** — по умолчанию включён, актуален для режима с трансляцией адресов. В проекте ТСПУ менять не требуется.
|
||||
|
||||
## 16.6. IPv6 в пуле
|
||||
|
||||
Поддержка IPv6 в пуле настраивается аналогично глобальным настройкам IPv6 (подробнее — в [разделе 15.4](15.md)):
|
||||
|
||||
| Параметр | Описание |
|
||||
| --------------------- | ------------------------------------------------------------ |
|
||||
| **Enable/disable** | Включение или выключение обработки IPv6-трафика в данном пуле |
|
||||
| **Тайм-ауты** | Отдельные тайм-ауты для IPv6-сессий (можно не менять) |
|
||||
| **Диапазон адресов** | Список IPv6-адресов и VLAN для обработки |
|
||||
|
||||
В проекте ТСПУ IPv6 в пуле должен быть **включён**. По умолчанию в диапазон обработки включены **все IPv6-адреса во всех VLAN** — менять это значение, как правило, не требуется.
|
||||
|
||||
При необходимости можно:
|
||||
|
||||
- включить в обработку только конкретные диапазоны IPv6-адресов;
|
||||
- исключить определённые диапазоны из обработки;
|
||||
- полностью отключить обработку IPv6-трафика в рамках данного пула.
|
||||
|
||||
---
|
||||
|
||||
### Диагностическая заметка: `show cps` показывает ноль
|
||||
|
||||
Если команда `show cps` показывает нулевое количество создаваемых сессий, одна из возможных причин — трафик **не попадает в пул**. Это может означать, что ACL не отбирает трафик: через фильтр могут идти гигабиты и десятки гигабит, но если пакеты не совпадают с правилами ACL привязанного пула, сессии создаваться не будут (подробнее — в [разделе 18.9](18.md)).
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 15: Фильтр: настройка интерфейсов и общих параметров](15.md) · [Раздел 17: Фильтр: настройка DPI →](17.md)
|
||||
310
chapters/17.md
Normal file
310
chapters/17.md
Normal file
@@ -0,0 +1,310 @@
|
||||
# 17. Фильтр: настройка DPI
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 16: Фильтр: ACL и пулы](16.md)
|
||||
|
||||
---
|
||||
|
||||
Модуль DPI (Deep Packet Inspection) — ключевая подсистема фильтра, отвечающая за анализ и фильтрацию трафика. Настройки DPI включают общие параметры модуля, конфигурацию работы с реестром Роскомнадзора, параметры деградации протоколов и индивидуальные настройки DPI-листов.
|
||||
|
||||
> **Примечание:** формат секции DPI различается между пилотным проектом (Урал) и федеральным проектом. В пилотном проекте настройки реестра Роскомнадзора находятся внутри DPI-листа 0. В федеральном проекте они вынесены в отдельную секцию, а все DPI-листы (0–15) стали абсолютно идентичными по структуре.
|
||||
|
||||
## 17.1. Общие настройки модуля DPI
|
||||
|
||||
Общие настройки расположены в корне секции `dpi` конфигурации фильтра.
|
||||
|
||||
### 17.1.1. Включение/выключение DPI
|
||||
|
||||
| Значение | Поведение |
|
||||
| ----------- | --------------------------------------------------------- |
|
||||
| **enable** | Модуль DPI активен, трафик анализируется и обрабатывается |
|
||||
| **disable** | Модуль DPI выключен, весь трафик пропускается прозрачно |
|
||||
|
||||
В рабочем режиме DPI должен быть **включён**. Выключение модуля DPI может использоваться для **диагностики**: если выключить DPI и убедиться, что фильтр больше не влияет на трафик — значит, проблема была именно в DPI-обработке.
|
||||
|
||||
### 17.1.2. Send RST off: отключение TCP Reset при блокировке протоколов
|
||||
|
||||
Параметр **send RST off** — важная настройка, определяющая поведение фильтра при блокировке распознанных протоколов.
|
||||
|
||||
| Значение | Поведение |
|
||||
| -------- | -------------------------------------------------------- |
|
||||
| **off** | TCP Reset при блокировке протоколов **не отправляется** |
|
||||
| **on** | TCP Reset отправляется абоненту и серверу при блокировке |
|
||||
|
||||
В проекте ТСПУ параметр **всегда должен быть в режиме `off`**.
|
||||
|
||||
**Почему отправка TCP Reset опасна:**
|
||||
|
||||
Когда приложение абонента (например, Telegram) пытается установить TCP-соединение и получает в ответ TCP Reset, оно воспринимает это как временный сбой и **немедленно** пытается установить новое соединение. Этот цикл повторяется непрерывно и с высокой частотой:
|
||||
|
||||
1. Приложение отправляет TCP SYN;
|
||||
2. Фильтр распознаёт протокол и отправляет TCP Reset;
|
||||
3. Приложение мгновенно пытается установить новое соединение;
|
||||
4. Цикл повторяется бесконечно.
|
||||
|
||||
На практике наблюдались случаи, когда мобильные устройства начинали **тормозить** из-за того, что Telegram непрерывно пытался переустановить заблокированную сессию. Количество генерируемых сессий создаёт **избыточную нагрузку** на фильтр.
|
||||
|
||||
При отключённой отправке Reset соединение **отбрасывается молча** — приложение пытается установить сессию, сессия «висит» и обрывается только по **тайм-ауту**. Это значительно снижает количество повторных попыток и нагрузку на фильтр.
|
||||
|
||||
### 17.1.3. Functionality mode: normal (не double mirror traffic)
|
||||
|
||||
| Значение | Описание | Применение в ТСПУ |
|
||||
| ------------------------- | -------------------------------------------- | ----------------- |
|
||||
| **normal** | Стандартный режим работы фильтра | **Всегда** |
|
||||
| **double mirror traffic** | Режим для работы с копией (зеркалом) трафика | Не используется |
|
||||
|
||||
Параметр **всегда должен быть `normal`**. Режим `double mirror traffic` предназначен для сценариев, когда фильтр получает зеркалированную копию трафика, что в проекте ТСПУ не применяется.
|
||||
|
||||
В секции DPI также присутствует устаревшая команда `extra analysis off` — она не используется и не требует внимания.
|
||||
|
||||
## 17.2. Настройка реестра РКН
|
||||
|
||||
Секция настройки реестра Роскомнадзора определяет параметры скачивания и обработки списков блокировки, предоставляемых Роскомнадзором.
|
||||
|
||||
> **Примечание:** в федеральном проекте эта секция вынесена в отдельный раздел конфигурации. В пилотном проекте (Урал) настройки находятся внутри DPI-листа 0.
|
||||
|
||||
### 17.2.1. Источник: RKN или ГРФЦ
|
||||
|
||||
| Источник | Описание |
|
||||
| -------- | ----------------------------------------------------------------------- |
|
||||
| **RKN** | Оригинальный формат выгрузки с серверов Роскомнадзора |
|
||||
| **ГРФЦ** | Новый формат выгрузки (оптимизированная база данных, уменьшенный объём) |
|
||||
|
||||
Роскомнадзор предложил новый источник списков — **ГРФЦ**. По сравнению с оригинальным форматом RKN, база данных ГРФЦ оптимизирована и уменьшена в объёме. Рекомендуется переключаться на выгрузку с ГРФЦ.
|
||||
|
||||
### 17.2.2. Логин/пароль для доступа к серверу РКН
|
||||
|
||||
Для скачивания реестра с сервера Роскомнадзора требуется **авторизация**. Логин и пароль задаются в секции настройки реестра. Учётные данные выдаются Роскомнадзором.
|
||||
|
||||
### 17.2.3. Привязка к DPI-листу (list number)
|
||||
|
||||
Параметр **list number** определяет, к какому DPI-листу будет привязан реестр Роскомнадзора. По умолчанию — **0**. В текущей конфигурации проекта ТСПУ фильтрация по реестру Роскомнадзора осуществляется в **DPI-листе 0**.
|
||||
|
||||
### 17.2.4. Proxy-сервер, dump server
|
||||
|
||||
| Параметр | Описание |
|
||||
| ---------------- | --------------------------------------------------------------------------------- |
|
||||
| **Proxy server** | Промежуточный сервер для доступа к реестру РКН, если прямое соединение невозможно |
|
||||
| **Dump server** | Сервер, на который фильтр выгружает скачанный реестр для внешнего анализа |
|
||||
|
||||
**Proxy server** используется, когда фильтр не может напрямую подключиться к серверу Роскомнадзора.
|
||||
|
||||
**Dump server** полезен для диагностики: можно получить копию того же дампа, который скачал фильтр, и проанализировать его на внешнем сервере. Фильтр скачивает реестр, а затем выгружает его на указанный dump server.
|
||||
|
||||
### 17.2.5. Проблемы скачивания: минимальная скорость ~10 Мбит/с
|
||||
|
||||
Сервер Роскомнадзора настроен таким образом, что **разрывает соединение** при низкой скорости скачивания. Эмпирически установлено, что минимальная скорость загрузки для успешного скачивания реестра составляет **~10 Мбит/с**. При более низкой скорости сервер Роскомнадзора обрывает соединение через некоторое время.
|
||||
|
||||
**Типичные причины проблем со скачиванием:**
|
||||
|
||||
- Недостаточная скорость management-интерфейса;
|
||||
- Ошибки на интерфейсе фильтра (в одном случае проблема решилась перезагрузкой фильтра);
|
||||
- Проблемы на стороне коммутатора или промежуточного оборудования.
|
||||
|
||||
При диагностике проблем скачивания следует обращать внимание на скорость и ошибки на management-интерфейсе. Команда `dpi run` позволяет принудительно инициировать обновление всех DPI-листов (подробнее — в [разделе 18.13.4](18.md)).
|
||||
|
||||
> **Примечание:** запуск `dpi run` не гарантирует, что реестр будет скачан — сервер РКН может ответить, что обновлений нет, и в этом случае ничего скачано не будет.
|
||||
|
||||
## 17.3. Деградация протоколов (protocols capacity)
|
||||
|
||||
Механизм деградации протоколов позволяет **частично ухудшить** работу распознанного протокола вместо полной блокировки. Настройка выполняется в секции DPI для каждого протокола индивидуально.
|
||||
|
||||
### 17.3.1. Шкала 0–100: 0 = полная блокировка, 100 = полный пропуск
|
||||
|
||||
Для каждого протокола задаётся значение **capacity** в условных единицах от 0 до 100:
|
||||
|
||||
| Значение | Поведение |
|
||||
| -------- | ------------------------------------------------- |
|
||||
| **0** | Полная блокировка — ничего не пропускается |
|
||||
| **100** | Полное пропускание — трафик не затрагивается |
|
||||
| **1–99** | Деградация — дроп пакетов с заданной вероятностью |
|
||||
|
||||
### 17.3.2. Дроп пакетов с заданной вероятностью
|
||||
|
||||
Механизм деградации работает просто: с определённой вероятностью, зависящей от параметра capacity, фильтр **дропает пакеты** в рамках сессии распознанного протокола. Чем ниже значение capacity, тем больше пакетов отбрасывается.
|
||||
|
||||
### 17.3.3. Эффективная деградация: 2–10% пропускания
|
||||
|
||||
На практике деградация становится **заметной для пользователя** только при значениях capacity в диапазоне **2–10**. Это объясняется свойствами TCP:
|
||||
|
||||
- TCP обладает встроенным механизмом **повторной передачи** потерянных пакетов;
|
||||
- При низкой степени деградации (высоких значениях capacity) TCP успешно компенсирует потери, и пользователь практически ничего не замечает;
|
||||
- Только при высокой степени деградации (capacity ~2–10) потери становятся настолько значительными, что TCP не успевает их компенсировать.
|
||||
|
||||
При значении capacity около **5** задержка отправки сообщений в приложениях может достигать **десятков секунд**.
|
||||
|
||||
### 17.3.4. Влияние на голосовые вызовы и мессенджеры
|
||||
|
||||
Деградация протоколов особенно эффективна для **голосовых вызовов** и **видеозвонков**, где потеря пакетов непосредственно влияет на качество:
|
||||
|
||||
- **Заикание** голоса и пропадание звука;
|
||||
- **Рассинхронизация** аудио и видео;
|
||||
- **Невозможность разговаривать** при высокой степени деградации;
|
||||
- Для текстовых сообщений — значительные **задержки доставки**.
|
||||
|
||||
Деградация является альтернативой полной блокировке: вместо немедленного и очевидного отключения сервиса пользователь получает **постепенное ухудшение** качества связи.
|
||||
|
||||
## 17.4. Настройка DPI-листов (0–16)
|
||||
|
||||
На фильтре может быть настроено до **16 DPI-листов** (номера 0–15). В будущих прошивках это количество может быть расширено — планируется возможность генерации DPI-листов по необходимости на уровне конфигурации.
|
||||
|
||||
Все DPI-листы имеют **одинаковую структуру** настроек (в федеральном проекте). Каждый лист настраивается индивидуально.
|
||||
|
||||
### 17.4.1. Enable/disable каждого листа
|
||||
|
||||
Каждый DPI-лист может быть **включён или выключен** независимо от остальных:
|
||||
|
||||
```text
|
||||
dpi list <N>
|
||||
enable ← включить лист
|
||||
disable ← выключить лист
|
||||
```
|
||||
|
||||
### 17.4.2. BitTorrent UTP detection
|
||||
|
||||
| Значение | Описание |
|
||||
| -------- | ----------------------------------------------- |
|
||||
| **on** | Включено распознавание протокола BitTorrent UTP |
|
||||
| **off** | Распознавание BitTorrent UTP выключено |
|
||||
|
||||
Если требуется распознавание и блокировка BitTorrent, параметр должен быть включён (`on`).
|
||||
|
||||
### 17.4.3. WH List Mode: blacklist (по умолчанию) / whitelist
|
||||
|
||||
Параметр **WH list mode** определяет логику работы DPI-листа:
|
||||
|
||||
| Режим | Поведение | Применение в ТСПУ |
|
||||
| ------------- | ----------------------------------------------------------------- | ----------------- |
|
||||
| **blacklist** | Всё, что совпало со списком — блокируется; остальное пропускается | **По умолчанию** |
|
||||
| **whitelist** | Пропускается только совпавший трафик; всё остальное блокируется | Не используется |
|
||||
|
||||
В проекте ТСПУ режим whitelist **не используется** из-за риска **случайной блокировки всего трафика**. Этот режим применяется в других сценариях, например, при использовании BRAS-функциональности на устройстве.
|
||||
|
||||
### 17.4.4. Behavior: block / ignore / color / redirect
|
||||
|
||||
Параметр **behavior** определяет, что происходит с трафиком, совпавшим со списком данного DPI-листа:
|
||||
|
||||
| Значение | Описание | Применение в ТСПУ |
|
||||
| ------------ | -------------------------------------------------------- | ---------------------------- |
|
||||
| **block** | Трафик блокируется (дропается) | Основной рабочий режим |
|
||||
| **ignore** | Совпадение фиксируется и логируется, трафик пропускается | Для распознавания протоколов |
|
||||
| **color** | Совпавший трафик «окрашивается» | Не используется |
|
||||
| **redirect** | Трафик перенаправляется | Не используется |
|
||||
|
||||
**Режим block** — основной для блокировки по реестру Роскомнадзора и по очищенным протокольным спискам. При срабатывании блокировки:
|
||||
|
||||
- Для **HTTP**: абоненту отправляется HTTP-редирект (302) на страницу-заглушку;
|
||||
- Для **HTTPS**: абоненту и серверу отправляется TCP Reset, разрывающий соединение (поскольку содержимое зашифровано и подмена ответа невозможна).
|
||||
|
||||
**Режим ignore** — используется для **первой стадии двухстадийной блокировки**: фильтр распознаёт протоколы и отправляет логи на SPFS, но сам трафик не блокирует. Данные передаются в ЦСУ для формирования очищенных списков (подробнее — в [разделе 8](08.md)).
|
||||
|
||||
Также в секции DPI-листа присутствует параметр **logs on/off** — включение журналирования срабатываний данного списка. В проекте ТСПУ эта функциональность, как правило, используется.
|
||||
|
||||
### 17.4.5. Redirect URL — страница-заглушка для заблокированных HTTP-ресурсов
|
||||
|
||||
Параметр **redirect URL** задаёт адрес страницы-заглушки, на которую перенаправляется абонент при блокировке **HTTP-ресурса** по реестру Роскомнадзора.
|
||||
|
||||
Типичное содержимое страницы-заглушки: уведомление абонента о том, что запрошенный ресурс заблокирован в соответствии с требованиями законодательства.
|
||||
|
||||
> **Важно:** redirect URL работает **только для HTTP-трафика**. Для HTTPS-трафика перенаправление невозможно (содержимое зашифровано), поэтому используется TCP Reset.
|
||||
|
||||
Также в секции DPI-листа присутствуют параметры, связанные с redirect behavior (redirect interval и др.) — в проекте ТСПУ они **не используются**.
|
||||
|
||||
### 17.4.6. Download URL — источник списков, update schedule
|
||||
|
||||
| Параметр | Описание |
|
||||
| ------------------- | -------------------------------------------------------------------- |
|
||||
| **Download URL** | URL, откуда фильтр скачивает список фильтрации для данного DPI-листа |
|
||||
| **Update schedule** | Интервал обновления списка (например, 30 минут) |
|
||||
|
||||
Download URL задаёт источник списков для DPI-листов, **не связанных** с реестром Роскомнадзора (скачивание реестра РКН настраивается отдельно — см. [раздел 17.2](#172-настройка-реестра-ркн)). Типичный источник — ресурс в **центральной системе управления** (ЦСУ), откуда загружаются очищенные протокольные списки.
|
||||
|
||||
**Update schedule** определяет частоту обновления:
|
||||
|
||||
| Значение | Поведение |
|
||||
| ------------ | -------------------------------------------------- |
|
||||
| Время (мин.) | Список обновляется с заданным интервалом |
|
||||
| **never** | Список **никогда не обновляется** и не скачивается |
|
||||
|
||||
> **Внимание:** значение `never` — частая причина проблем. Если всё настроено корректно, но update schedule установлен в `never`, списки просто не будут скачиваться. Необходимо задать конкретный интервал обновления.
|
||||
|
||||
### 17.4.7. Protocols — список распознаваемых протоколов
|
||||
|
||||
В секции **protocols** каждого DPI-листа указываются протоколы, по которым будет осуществляться распознавание и последующее действие (блокировка, игнорирование и т.д.).
|
||||
|
||||
Список протоколов задаётся перечислением названий: Telegram, WhatsApp, Viber, BitTorrent и др. Набор поддерживаемых протоколов определяется версией прошивки фильтра.
|
||||
|
||||
### 17.4.8. No IP / IP — исключение/включение адресов для обработки
|
||||
|
||||
Параметры **IP** и **No IP** определяют, какой трафик подлежит обработке данным DPI-листом:
|
||||
|
||||
| Параметр | Описание |
|
||||
| ---------------------- | --------------------------------------------------------------------- |
|
||||
| **IP** | Подсети и адреса, которые **должны обрабатываться** данным DPI-листом |
|
||||
| **No IP** | Локальные адреса абонентов, **исключённые** из обработки |
|
||||
| **No IP Remote** | Удалённые адреса (серверы), **исключённые** из обработки |
|
||||
| **IPv6** / **No IPv6** | Аналогичные параметры для IPv6-трафика |
|
||||
|
||||
По умолчанию параметр **IP** должен содержать сеть `0.0.0.0/0` для всех VLAN — тогда весь трафик, попавший в DPI, будет обрабатываться данным листом.
|
||||
|
||||
**Использование No IP для диагностики:**
|
||||
|
||||
Параметр **No IP** — ключевой инструмент траблшутинга. Чтобы проверить, влияет ли данный DPI-лист на конкретного абонента:
|
||||
|
||||
1. Добавить локальный IP-адрес абонента в **No IP** данного DPI-листа;
|
||||
2. Выполнить `apply`;
|
||||
3. Проверить, изменилось ли поведение у абонента;
|
||||
4. Если приложение у абонента **заработало** — данный DPI-лист действительно блокировал его трафик;
|
||||
5. Если **ничего не изменилось** — проблема не в данном DPI-листе.
|
||||
|
||||
Параметр **No IP Remote** работает аналогично, но исключает из обработки удалённый IP-адрес (адрес сервера).
|
||||
|
||||
### 17.4.9. QUIC list
|
||||
|
||||
Параметр **QUIC list** определяет список ресурсов, для которых должен распознаваться протокол **QUIC** (Quick UDP Internet Connections) — протокол, разработанный Google для оптимизации доставки контента.
|
||||
|
||||
Фильтр **умеет распознавать** QUIC, но для этого необходимо внести ресурсы, которые планируется обрабатывать, в QUIC list.
|
||||
|
||||
## 17.5. Формат списков фильтрации
|
||||
|
||||
Списки фильтрации (кроме реестра Роскомнадзора, который скачивается в специальном формате) представляют собой **текстовые файлы**, где на каждой строке перечислены ресурсы для обработки.
|
||||
|
||||
### 17.5.1. IP-адреса, подсети, диапазоны, URL
|
||||
|
||||
Поддерживаемые форматы записей в списках:
|
||||
|
||||
| Формат | Пример | Описание |
|
||||
| ------------------- | ------------------------- | ---------------------- |
|
||||
| IP-адрес | `1.2.3.4` | Конкретный IP-адрес |
|
||||
| Подсеть | `10.0.0.0/8` | Подсеть в CIDR-нотации |
|
||||
| Диапазон IP | `1.2.3.4-1.2.3.10` | Диапазон адресов |
|
||||
| URL | `http://example.com/page` | Конкретный URL (HTTP) |
|
||||
| Домен | `example.com` | Домен (HTTP и HTTPS) |
|
||||
| Домен с поддоменами | `*.example.com` | Домен и все поддомены |
|
||||
|
||||
Если в начале URL стоит **звёздочка** (`*`), обрабатываются **все протоколы** (HTTP и HTTPS) и **все поддомены** данного домена. Если протокол **не указан явно**, обрабатываются и HTTP, и HTTPS.
|
||||
|
||||
### 17.5.2. HTTP: блокировка конкретного URL
|
||||
|
||||
Для **HTTP**-трафика возможна блокировка **конкретного URL** — вплоть до отдельной страницы. Это обусловлено тем, что при HTTP-соединении URL передаётся **в открытом виде** в заголовке запроса, и фильтр может его проанализировать.
|
||||
|
||||
Пример: запись `http://example.com/specific/page.html` в списке заблокирует **только эту конкретную страницу**, остальные страницы на `example.com` останутся доступными.
|
||||
|
||||
### 17.5.3. HTTPS: блокировка только по домену (SNI/Client Hello)
|
||||
|
||||
Для **HTTPS**-трафика блокировка возможна **только на уровне домена**. Это фундаментальное ограничение, связанное с механизмом установления HTTPS-соединения:
|
||||
|
||||
1. При установлении HTTPS-соединения клиент отправляет **Client Hello**;
|
||||
2. В Client Hello содержится поле **SNI** (Server Name Indication), указывающее доменное имя сервера;
|
||||
3. Поле SNI содержит **только домен** (например, `ru.wikipedia.org`) — **без пути и URL**;
|
||||
4. Всё остальное содержимое HTTPS-соединения **зашифровано** и недоступно для анализа.
|
||||
|
||||
**Практическое следствие:** если в списке указана строка вида `https://ru.wikipedia.org/wiki/Конкретная_статья`, фильтр заблокирует **весь домен** `ru.wikipedia.org` целиком, а не конкретную страницу. Поле SNI не содержит пути URL, поэтому фильтр видит только домен и блокирует все обращения к нему.
|
||||
|
||||
| Протокол | Точность блокировки | Причина |
|
||||
| --------- | --------------------------- | ------------------------------------- |
|
||||
| **HTTP** | До конкретного URL/страницы | URL виден в открытом виде в заголовке |
|
||||
| **HTTPS** | Только весь домен целиком | В SNI (Client Hello) только домен |
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 16: Фильтр: ACL и пулы](16.md) · [Раздел 18: Фильтр: мониторинг и диагностика →](18.md)
|
||||
326
chapters/18.md
Normal file
326
chapters/18.md
Normal file
@@ -0,0 +1,326 @@
|
||||
# 18. Фильтр: мониторинг и диагностика
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 17: Фильтр: настройка DPI](17.md)
|
||||
|
||||
---
|
||||
|
||||
Фильтр предоставляет обширный набор команд мониторинга и диагностики, позволяющих оценить состояние аппаратной части, загрузку ресурсов, статистику обработки трафика и работу модуля DPI. Все команды мониторинга выполняются в **операционном режиме** (приглашение `>`), за исключением ping и traceroute, которые доступны из **конфигурационного режима**.
|
||||
|
||||
## 18.1. `show version` — версия ПО, серийный номер (= MAC management)
|
||||
|
||||
Команда `show version` отображает информацию о текущей версии программного обеспечения фильтра:
|
||||
|
||||
| Параметр | Описание |
|
||||
| --------------------- | ----------------------------------------------------------- |
|
||||
| **Версия ПО** | Основной номер версии (например, `3.14.040 BP`) |
|
||||
| **Серийный номер** | Серийный номер платформы — необходим при обращении в техподдержку |
|
||||
|
||||
Команда `show version detail` дополнительно выводит хэши сборки, указывающие на конкретный коммит в сборочной системе (полезно для разработчиков).
|
||||
|
||||
> **Важно:** серийный номер платформы **совпадает** с MAC-адресом management-интерфейса. Это можно проверить через команду `show ip if`.
|
||||
|
||||
## 18.2. `show ip if` — параметры management-интерфейса
|
||||
|
||||
Команда отображает параметры management-интерфейса:
|
||||
|
||||
- **MAC-адрес** (совпадает с серийным номером);
|
||||
- **IP-адрес**;
|
||||
- **Маска подсети**;
|
||||
- **Default gateway**.
|
||||
|
||||
## 18.3. `show time` — текущее время (UTC / local)
|
||||
|
||||
Команда выводит текущее время в двух форматах:
|
||||
|
||||
- **UTC** — всемирное координированное время;
|
||||
- **Local** — локальное время (с учётом настроенного сдвига).
|
||||
|
||||
Оба значения отображаются всегда, даже если они совпадают.
|
||||
|
||||
## 18.4. `show uptime` — время работы платформы и процесса EcoNAT
|
||||
|
||||
Команда показывает **два значения** времени работы:
|
||||
|
||||
| Параметр | Описание |
|
||||
| ----------------------- | --------------------------------------------------------- |
|
||||
| **Uptime платформы** | Время с момента включения/перезагрузки аппаратной платформы |
|
||||
| **Uptime EcoNAT** | Время с момента запуска процесса обработки трафика |
|
||||
|
||||
Эти два значения могут отличаться на **небольшую величину** (обычно до 1 минуты): сначала стартует платформа, затем — процесс EcoNAT, который инициализирует интерфейсы и начинает обработку трафика.
|
||||
|
||||
> **Примечание:** после старта EcoNAT обновляет время по NTP. В некоторых случаях это приводит к тому, что в выводе `show uptime` отображаются **некорректные значения**. Например, если в BIOS было установлено неверное время, после синхронизации по NTP вывод uptime может показывать аномальные цифры. Это нормальная ситуация — значения восстановятся после следующей перезагрузки. Тем не менее, подобные аномалии следует исследовать.
|
||||
|
||||
## 18.5. Аппаратная часть: `show power`, `show fan`, `show temperature`
|
||||
|
||||
### show power
|
||||
|
||||
Отображает состояние **источников питания**: `OK` или `FAIL`. В будущих версиях прошивки планируется более подробный вывод — напряжение на входе, мощность блоков питания, внутренние параметры (вольты, ватты, амперы).
|
||||
|
||||
### show fan
|
||||
|
||||
Отображает **скорость вращения вентиляторов**:
|
||||
|
||||
- **Системные вентиляторы** — обычно 4 штуки, каждый с двумя датчиками;
|
||||
- **Вентиляторы на сетевых картах** — отдельные показания.
|
||||
|
||||
### show temperature
|
||||
|
||||
Отображает **температуру ядер процессора** (не крышки и не внешнего сенсора):
|
||||
|
||||
| Диапазон | Оценка |
|
||||
| ------------- | --------------------------------------------------------- |
|
||||
| **40–50 °C** | Нормальные значения |
|
||||
| **~70 °C** | Платформа начинает перегреваться — необходимо проверить условия охлаждения на площадке |
|
||||
|
||||
При обнаружении повышенной температуры следует запросить у оператора информацию о состоянии окружающей среды на площадке (кондиционирование, вентиляция).
|
||||
|
||||
## 18.6. Интерфейсы: `show interface brief`, traffic monitor, трансиверы (DDM)
|
||||
|
||||
### show interface brief
|
||||
|
||||
Выводит **краткую информацию** по всем интерфейсам:
|
||||
|
||||
| Поле | Описание |
|
||||
| --------------- | ----------------------------------------------- |
|
||||
| **Состояние** | Up / Down |
|
||||
| **MTU** | Текущее значение MTU на интерфейсе |
|
||||
| **MAC** | MAC-адрес интерфейса |
|
||||
| **Скорость** | Скорость линка |
|
||||
| **Loading** | Условная загрузка интерфейса в процентах |
|
||||
| **Description** | Описание интерфейса (если задано) |
|
||||
|
||||
### Traffic monitor
|
||||
|
||||
Команда `show interface <имя|all> traffic monitor` выводит **ежесекундно обновляемую таблицу** с текущей нагрузкой на интерфейсы:
|
||||
|
||||
- Количество **байт** — принятых и переданных за последнюю секунду;
|
||||
- Количество **пакетов** — на вход и на выход;
|
||||
- **Ошибки** — всегда должны быть нулевыми.
|
||||
|
||||
Для выхода из режима мониторинга — `Ctrl+C`.
|
||||
|
||||
Команда `show interface all traffic` (без слова `monitor`) показывает **суммарные счётчики** в байтах и пакетах с момента последней очистки или перезагрузки.
|
||||
|
||||
### Трансиверы (DDM)
|
||||
|
||||
Фильтр позволяет просмотреть информацию о подключённых **трансиверах** и уровни оптических сигналов (**DDM** — Digital Diagnostic Monitoring):
|
||||
|
||||
- Информация доступна для **оптических модулей**;
|
||||
- Для **медных модулей** и **direct-attach кабелей** DDM не поддерживается;
|
||||
- Поддерживаются трансиверы **любых производителей**, совместимых с чипами Intel на сетевых картах фильтра. Программных ограничений на вендора нет, однако совместимость может быть ограничена самим чипом Intel.
|
||||
|
||||
## 18.7. Ресурсы: `show resources`
|
||||
|
||||
Команда `show resources` — **основная команда** для оценки загрузки фильтра. Выводит загрузку процессора, ресурсных таблиц и DPI.
|
||||
|
||||
### 18.7.1. Таблицы сессий/трансляций: не более 20% загрузки
|
||||
|
||||
Загрузка ресурсных таблиц (сессий, трансляций, IPv6-сессий) отображается в **процентах** от максимального объёма. Критический порог — **20%**.
|
||||
|
||||
| Загрузка | Оценка |
|
||||
| ------------ | ----------------------------------------------------------- |
|
||||
| **< 20%** | Нормальная работа |
|
||||
| **> 20%** | Превышена оптимальная загрузка — поиск по таблице замедляется |
|
||||
|
||||
Превышение порога в 20% приводит к **существенному росту задержек** при обработке трафика. Это связано с внутренней архитектурой хэш-таблиц: при высокой заполненности поиск по ним становится значительно дольше, и часть трафика может не успевать обрабатываться.
|
||||
|
||||
**Что делать при превышении 20%:**
|
||||
|
||||
- Обратиться в техподдержку;
|
||||
- Вероятная причина — на фильтр попало **больше трафика**, чем планировалось (таблицы рассчитаны на определённую полосу пропускания);
|
||||
- Возможная причина — **DDoS-атака**: маленькие пакеты генерируют огромное количество сессий при небольшом объёме трафика;
|
||||
- Запросить у оператора информацию о состоянии трафика.
|
||||
|
||||
> **Примечание:** таблица абонентов (subscribers) также отображается в `show resources`, но в проекте ТСПУ **не используется** — это функционал BRAS.
|
||||
|
||||
### 18.7.2. Свободные буферы: не должны уходить в ноль
|
||||
|
||||
Значение **свободных буферов** не имеет конкретного «правильного» числа. Важно следить за **динамикой**:
|
||||
|
||||
- Буферы могут увеличиваться и уменьшаться в зависимости от нагрузки;
|
||||
- На графике они должны **колебаться** вокруг средней линии;
|
||||
- Если в течение **недели и более** буферы постепенно **уменьшаются** — это признак **утечки памяти**, и необходимо открывать кейс в техподдержке;
|
||||
- Буферы **не должны уходить в ноль**.
|
||||
|
||||
### 18.7.3. DPI-ресурсы: не более 100%
|
||||
|
||||
Загрузка DPI-ресурсов отображается отдельно. Порог — **100%**:
|
||||
|
||||
| Загрузка | Оценка |
|
||||
| -------------- | -------------------------- |
|
||||
| **< 100%** | Нормальная работа |
|
||||
| **≥ 100%** | Ресурсы DPI исчерпаны |
|
||||
|
||||
### 18.7.4. CPU Load — условный параметр обработки трафика
|
||||
|
||||
Параметр **CPU Load** в `show resources` — это **не** стандартная загрузка CPU в понимании Linux. Это **условный параметр**, рассчитываемый процессом EcoFilter, отражающий долю времени, затрачиваемую на обработку трафика.
|
||||
|
||||
| Загрузка | Оценка |
|
||||
| -------------- | -------------------------------------------------------- |
|
||||
| **< 80%** | Нормальная работа |
|
||||
| **80–90%** | Повод для анализа — выяснить причину высокой загрузки |
|
||||
| **~100%** | Критическая ситуация — фильтр не справляется |
|
||||
|
||||
Значения 80–90% и выше — повод обратиться в техподдержку или провести собственное расследование причин.
|
||||
|
||||
## 18.8. Память: Control Plane vs Data Plane
|
||||
|
||||
Память фильтра условно разделена на **две области**:
|
||||
|
||||
| Область | Назначение |
|
||||
| -------------------- | ------------------------------------------------------------- |
|
||||
| **Control Plane** | ОС Linux, CLI, сервисные функции (syslog, управление и т.д.) |
|
||||
| **Data Plane** | Процесс EcoNAT — обработка трафика, ресурсные таблицы |
|
||||
|
||||
### 18.8.1. Data Plane выделяется при старте, не должна расти
|
||||
|
||||
Память Data Plane выделяется **один раз при старте** процесса EcoNAT. В ней создаются ресурсные таблицы (сессии, трансляции и пр.).
|
||||
|
||||
После старта объём занятой Data Plane памяти **не должен расти**. На графике мониторинга это должна быть **ровная линия** с незначительными отклонениями. Если наблюдается постоянный рост — это признак утечки памяти.
|
||||
|
||||
### 18.8.2. Пороги: 5–10% свободной памяти — повод для тревоги
|
||||
|
||||
| Свободная память | Оценка |
|
||||
| ---------------- | --------------------------------------------------------- |
|
||||
| **> 10%** | Нормально |
|
||||
| **5–10%** | Повод для тревоги — рекомендуется настроить алерт в системе мониторинга |
|
||||
| **< 5%** | Критическая ситуация |
|
||||
|
||||
Если свободная память составляет 5%, но **не уменьшается** со временем — это нормальная ситуация. На современных платформах памяти достаточно, и свободной памяти обычно остаётся много.
|
||||
|
||||
> **Примечание:** на некоторых площадках (например, МТС) используется другой принцип расчёта свободной памяти, и в мониторинге могут отображаться небольшие значения (~5%). Это нормально для данных прошивок.
|
||||
|
||||
## 18.9. `show cps` — скорость создания новых сессий
|
||||
|
||||
Команда `show cps` (Connections Per Second) показывает **скорость создания новых сессий** и трансляций в секунду.
|
||||
|
||||
| Значение | Интерпретация |
|
||||
| ----------- | ----------------------------------------------------------- |
|
||||
| **> 0** | Новые сессии создаются, трафик обрабатывается |
|
||||
| **0** | Новые сессии не создаются — требуется диагностика |
|
||||
|
||||
**Нулевое значение** может означать:
|
||||
|
||||
1. **Трафик не проходит** через фильтр вообще;
|
||||
2. **Трафик проходит, но не попадает в пул** — ACL не отбирает трафик, сессии не создаются. Через фильтр могут идти гигабиты и десятки гигабит, но `show cps` будет показывать ноль (подробнее — в [разделе 16](16.md)).
|
||||
|
||||
## 18.10. `show statistic` — статистика сессий и пулов, значение Optimal (= 20%)
|
||||
|
||||
Команда `show statistic` отображает статистику по сессиям и загрузке пула:
|
||||
|
||||
| Параметр | Описание |
|
||||
| ------------ | ----------------------------------------------------------- |
|
||||
| **Total** | Максимальный размер таблицы |
|
||||
| **Used** | Количество используемых записей |
|
||||
| **Optimal** | 20% от Total — оптимальный максимум загрузки |
|
||||
|
||||
Значение **Optimal** — это те же 20%, что и в `show resources`, но отображённые **в абсолютных числах**, а не в процентах. Количество используемых записей (Used) **не должно превышать** значение Optimal.
|
||||
|
||||
Загрузка пула: поскольку пул в проекте ТСПУ всегда типа **fake**, его загрузка будет **нулевой** — на неё можно не обращать внимания.
|
||||
|
||||
## 18.11. Счётчики: `show counters all` / `show counters div` (дельта за секунду)
|
||||
|
||||
На фильтре существует **большое количество** счётчиков — практически на каждую операцию.
|
||||
|
||||
| Команда | Описание |
|
||||
| ---------------------- | ---------------------------------------------------------- |
|
||||
| `show counters all` | Значения счётчиков с момента последнего обнуления (или перезагрузки) |
|
||||
| `show counters div` | Дельта за последнюю секунду — какие счётчики увеличились и на сколько |
|
||||
|
||||
**`show counters div`** — наиболее полезная команда для оперативной диагностики. Она показывает только те счётчики, которые **изменились за последнюю секунду**. Если счётчик не появился в выводе — значит, за последнюю секунду он не увеличился.
|
||||
|
||||
Примеры счётчиков:
|
||||
|
||||
- Распознанные пакеты по протоколам (WhatsApp Voice, Telegram и т.д.);
|
||||
- Отправленные логи;
|
||||
- Счётчики L2-протоколов (PPPoE, MPLS);
|
||||
- Нераспознанные протоколы;
|
||||
- И многие другие (сотни счётчиков).
|
||||
|
||||
Как правило, из названия счётчика понятно, за что он отвечает. Наиболее важные счётчики выведены в **систему мониторинга**. На разных площадках набор активных счётчиков может различаться в зависимости от типа трафика и инкапсуляций.
|
||||
|
||||
> **Подсказка:** для оценки нераспознанного трафика можно сравнить **общее количество пакетов** с суммой распознанных — разница покажет объём нераспознанного трафика.
|
||||
|
||||
## 18.12. Системный журнал: `show syslog`, ротация двух файлов
|
||||
|
||||
Помимо логирования на внешний сервер (см. [раздел 14.8](14.md)), логи хранятся **внутри устройства** на локальном разделе.
|
||||
|
||||
Особенности внутреннего хранения:
|
||||
|
||||
- Раздел для логов **небольшой**;
|
||||
- Используются **два файла**, которые **ротируются**: сначала пишется в один, затем в другой, и наоборот;
|
||||
- При большом объёме логов файлы **быстро перезатираются** — если с момента проблемы прошло пару суток, логи, скорее всего, уже утрачены;
|
||||
- Именно для решения этой проблемы в федеральном проекте добавлено **внешнее логирование** на СПХД.
|
||||
|
||||
Команда `show syslog` выводит записи из внутреннего журнала, начиная с **самых свежих**.
|
||||
|
||||
## 18.13. DPI-мониторинг
|
||||
|
||||
### 18.13.1. `show dpi records <N>` — содержимое DPI-листа
|
||||
|
||||
Команда `show dpi records <N>` выводит **содержимое** загруженного DPI-листа с номером N, включая реестр Роскомнадзора (лист 0).
|
||||
|
||||
> **Предупреждение:** содержимое реестра Роскомнадзора (лист 0) **очень велико**. Вывод может продолжаться несколько минут. Для прерывания — `Ctrl+C`.
|
||||
|
||||
### 18.13.2. `show dpi state` — количество записей, дата последнего дампа
|
||||
|
||||
Команда `show dpi state` — **основная диагностическая команда** для анализа состояния DPI. Отображает:
|
||||
|
||||
| Параметр | Описание |
|
||||
| ------------------------- | --------------------------------------------------------- |
|
||||
| **Количество IP-записей** | Число загруженных IP-адресов и подсетей |
|
||||
| **Количество URL-записей**| Число загруженных URL |
|
||||
| **Last time** | Время последнего скачивания дампа |
|
||||
| **Actual date for delta** | Временная метка последней записи в реестре Роскомнадзора |
|
||||
| **DPI-ресурсы** | Загрузка ресурсов DPI (аналогично `show resources`) |
|
||||
|
||||
**Интерпретация дат:**
|
||||
|
||||
Реестр Роскомнадзора формируется **итерационно**: Роскомнадзор периодически обновляет реестр, выпуская основные дампы и дельты. Если Роскомнадзор **не вносил обновлений** в течение длительного времени (например, суток), то:
|
||||
|
||||
- Фильтр продолжает запрашивать обновления с периодичностью update schedule (обычно 30 минут);
|
||||
- Сервер РКН отвечает, что обновлений нет;
|
||||
- Дата последнего скачивания **не обновляется**;
|
||||
- В системе мониторинга может появиться алерт «дамп не скачивался более 24 часов».
|
||||
|
||||
Это **не обязательно означает проблему** — возможно, Роскомнадзор просто не обновлял реестр. Однако если дата не обновляется длительное время, следует проверить скорость скачивания и доступность сервера РКН.
|
||||
|
||||
Команда `dpi list` показывает файлы на диске: все дампы, дельты и сформированные DPI-листы. Например, реестр Роскомнадзора после парсинга хранится в файле `list_0.dpi`.
|
||||
|
||||
### 18.13.3. `dpi load <N>` — ручная загрузка списка
|
||||
|
||||
Команда `dpi load <N>` принудительно загружает DPI-лист с номером N с URL, указанного в конфигурации данного листа (или с URL, заданного в команде). Используется для диагностики проблем с загрузкой списков.
|
||||
|
||||
### 18.13.4. `dpi run` — принудительное обновление всех списков
|
||||
|
||||
Команда `dpi run` принудительно запускает обновление **всех** настроенных DPI-листов. В штатной эксплуатации обычно не требуется — используется при диагностике проблем с обновлением списков.
|
||||
|
||||
> **Примечание:** `dpi run` инициирует запрос к серверам, но не гарантирует скачивание — если обновлений нет, ничего скачано не будет.
|
||||
|
||||
### 18.13.5. `show dpi match <ресурс>` — проверка ресурса по всем DPI-листам
|
||||
|
||||
Команда `show dpi match <ресурс>` проверяет указанный ресурс (IP-адрес или URL) по **всем загруженным DPI-листам** и выводит:
|
||||
|
||||
- В каком DPI-листе найдено **совпадение**;
|
||||
- Какое **поведение** (behavior) задано для этого листа.
|
||||
|
||||
Если совпадений нет — вывод будет пустым.
|
||||
|
||||
> **Примечание:** в версии прошивки пилотного проекта (Урал) эта команда может быть **недоступна**. Она появилась в более новых версиях для федерального проекта.
|
||||
|
||||
Команда крайне полезна для диагностики: если абонент жалуется на блокировку ресурса, можно быстро проверить, присутствует ли ресурс в каком-либо DPI-листе и с каким действием.
|
||||
|
||||
## 18.14. Ping и Traceroute (из конфигурационного режима)
|
||||
|
||||
Команды `ping` и `traceroute` доступны из **конфигурационного режима** (не из операционного).
|
||||
|
||||
| Команда | Описание |
|
||||
| --------------- | ----------------------------------------------------------- |
|
||||
| `ping <адрес>` | Бесконечный пинг до указанного хоста (прервать — `Ctrl+C`) |
|
||||
| `traceroute <адрес>` | Трассировка маршрута до хоста |
|
||||
|
||||
> **Важно:** ping и traceroute работают **только через management-интерфейс**. Фильтр — это L2-устройство без IP-интерфейсов в тракте данных, поэтому инициировать трафик через LAN/WAN-интерфейсы **невозможно** (подробнее — в [разделе 5.2](05.md)).
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 17: Фильтр: настройка DPI](17.md) · [Раздел 19: Фильтр: обновление прошивки →](19.md)
|
||||
120
chapters/19.md
Normal file
120
chapters/19.md
Normal file
@@ -0,0 +1,120 @@
|
||||
# 19. Фильтр: обновление прошивки
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 18: Фильтр: мониторинг и диагностика](18.md)
|
||||
|
||||
---
|
||||
|
||||
Обновление программного обеспечения фильтра выполняется через CLI из конфигурационного режима. Система хранения прошивок построена на принципе **двух равнозначных разделов**, что позволяет безопасно обновляться и при необходимости откатываться на предыдущую версию.
|
||||
|
||||
## 19.1. Два раздела: prim1 и prim2 (равнозначные) + FB (заводская)
|
||||
|
||||
На SSD-накопителе фильтра расположены **три раздела** для программного обеспечения:
|
||||
|
||||
| Раздел | Описание |
|
||||
| --------- | ---------------------------------------------------------------- |
|
||||
| **FB** | Заводская прошивка — минимальный образ, предоставляющий только доступ к management-интерфейсу и возможность загрузить нормальную прошивку |
|
||||
| **prim1** | Первый рабочий раздел для полноценной прошивки |
|
||||
| **prim2** | Второй рабочий раздел для полноценной прошивки |
|
||||
|
||||
Разделы **prim1** и **prim2** — **абсолютно равнозначные**. Нет «основного» и «второстепенного» — оба раздела одинаковы. На каждом может быть загружен свой образ ПО, и между ними можно свободно переключаться (с перезагрузкой).
|
||||
|
||||
## 19.2. `firmware status` — текущее состояние (cur / boot)
|
||||
|
||||
Команда `firmware status` (из конфигурационного режима) выводит информацию о разделах прошивки:
|
||||
|
||||
| Поле | Описание |
|
||||
| --------- | ----------------------------------------------------------- |
|
||||
| **cur** | Активная версия — та, с которой устройство работает сейчас |
|
||||
| **boot** | Версия, которая будет загружена при следующей перезагрузке |
|
||||
|
||||
Пример вывода: активная версия — `4031` (cur), после перезагрузки загрузится `4038` (boot). Это означает, что новая прошивка была установлена, но устройство ещё не перезагружено.
|
||||
|
||||
В нормальном рабочем состоянии значения **cur** и **boot** указывают на один и тот же раздел. После установки новой прошивки **boot** автоматически переключается на раздел с новой версией.
|
||||
|
||||
## 19.3. `firmware download` — скачивание, `firmware install` — установка
|
||||
|
||||
Обновление прошивки выполняется в **два этапа**:
|
||||
|
||||
### Этап 1: Скачивание
|
||||
|
||||
```text
|
||||
firmware download <URL>
|
||||
```
|
||||
|
||||
Команда скачивает образ прошивки с указанного URL на устройство.
|
||||
|
||||
### Этап 2: Установка
|
||||
|
||||
```text
|
||||
firmware install
|
||||
```
|
||||
|
||||
Команда устанавливает скачанный образ на **неактивный раздел** (тот, который сейчас не используется). После установки значение **boot** автоматически переключается на раздел с новой прошивкой.
|
||||
|
||||
**Важные ограничения:**
|
||||
|
||||
- Установка выполняется быстро (~5 секунд), но в этот момент фильтр может **не реагировать** на команды в CLI;
|
||||
- После установки, пока устройство не перезагружено, **повторная установка невозможна** — для установки новой прошивки значения cur и boot должны совпадать;
|
||||
- Для применения новой прошивки необходима **перезагрузка** устройства (из конфигурационного режима, с подтверждением).
|
||||
|
||||
### Полная последовательность обновления
|
||||
|
||||
```text
|
||||
# 1. Проверить текущее состояние
|
||||
firmware status
|
||||
|
||||
# 2. Скачать новую прошивку
|
||||
firmware download <URL>
|
||||
|
||||
# 3. Установить на неактивный раздел
|
||||
firmware install
|
||||
|
||||
# 4. Проверить, что boot указывает на новый раздел
|
||||
firmware status
|
||||
|
||||
# 5. Перезагрузить устройство
|
||||
reload
|
||||
```
|
||||
|
||||
## 19.4. `firmware rollback` / `firmware reset`
|
||||
|
||||
Для управления разделами загрузки доступны две команды:
|
||||
|
||||
| Команда | Действие |
|
||||
| --------------------- | ----------------------------------------------------------- |
|
||||
| **firmware rollback** | Переключает **boot** на неактивный раздел (откат на другую версию) |
|
||||
| **firmware reset** | Возвращает **boot** обратно на текущий активный раздел (отмена rollback) |
|
||||
|
||||
### firmware rollback
|
||||
|
||||
Команда `firmware rollback` меняет значение boot с активного раздела на неактивный. Это позволяет:
|
||||
|
||||
- **Откатиться** на предыдущую версию прошивки (если на другом разделе сохранена рабочая версия);
|
||||
- **Отменить** запланированное обновление (если после `firmware install` вы решили не обновляться).
|
||||
|
||||
### firmware reset
|
||||
|
||||
Команда `firmware reset` выполняет обратное действие — возвращает boot на текущий активный раздел. Используется, если rollback был выполнен по ошибке.
|
||||
|
||||
> **Примечание:** обе команды изменяют только указатель boot — фактического переключения не происходит до перезагрузки.
|
||||
|
||||
## 19.5. Централизованное обновление через ЦСУ
|
||||
|
||||
В промышленной эксплуатации обновление прошивок выполняется **централизованно** через центральную систему управления (ЦСУ):
|
||||
|
||||
- Оператор инициирует обновление через интерфейс ЦСУ;
|
||||
- ЦСУ автоматически скачивает и устанавливает прошивку на фильтры;
|
||||
- По завершении формируется **отчёт** об успешности или неуспешности обновления;
|
||||
- Перезагрузка фильтров также инициируется через ЦСУ.
|
||||
|
||||
Ручное обновление через CLI остаётся важным навыком для:
|
||||
|
||||
- Диагностики проблем с обновлением;
|
||||
- Обновления единичных устройств;
|
||||
- Работы на площадках, где ЦСУ временно недоступна.
|
||||
|
||||
При массовом обновлении множества фильтров через ЦСУ рекомендуется **последовательная** перезагрузка с проверкой работоспособности каждого устройства после обновления.
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 18: Фильтр: мониторинг и диагностика](18.md) · [Раздел 20: Балансировщик: аппаратная платформа →](20.md)
|
||||
175
chapters/20.md
Normal file
175
chapters/20.md
Normal file
@@ -0,0 +1,175 @@
|
||||
# 20. Балансировщик: аппаратная платформа
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 19: Фильтр: обновление прошивки](19.md)
|
||||
|
||||
---
|
||||
|
||||
Балансировщик (EcoFilter Balancer) — устройство, обеспечивающее распределение трафика между фильтрами и их отказоустойчивость. Аппаратная платформа **одинакова** как для EcoFilter Balancer, так и для Eco Highway (эшелонированная система) — различия только в программной части.
|
||||
|
||||
## 20.1. Одноюнитовый (32 порта QSFP28) и двухюнитовый (65 портов)
|
||||
|
||||
Балансировщик выпускается в двух форм-факторах:
|
||||
|
||||
| Форм-фактор | Количество портов | Применение в ТСПУ |
|
||||
| ------------------ | -------------------- | ------------------ |
|
||||
| **1U** (одноюнитовый) | 32 порта QSFP28 | **Используется** |
|
||||
| **2U** (двухюнитовый) | 65 портов QSFP28 | Не используется |
|
||||
|
||||
В проекте ТСПУ применяются **только одноюнитовые** балансировщики с 32 портами QSFP28.
|
||||
|
||||
Характеристики:
|
||||
|
||||
- **Пропускная способность** — 3,2 Тбит/с на уровне провода (для пакетов более 160 байт);
|
||||
- **Питание** — два блока питания с горячим резервированием (расположены на задней панели);
|
||||
- **Высота** — 1U.
|
||||
|
||||
## 20.2. Скорости портов: 10G / 25G / 100G
|
||||
|
||||
Порты QSFP28 поддерживают работу на различных скоростях в зависимости от конфигурации и типа установленных трансиверов:
|
||||
|
||||
| Скорость | Описание |
|
||||
| ----------- | ------------------------------------------------------------ |
|
||||
| **100G** | Все 4 линии порта QSFP28 объединены (суммарная скорость) |
|
||||
| **25G** | Каждая из 4 линий работает отдельно на 25 Гбит/с |
|
||||
| **10G** | Каждая из 4 линий работает на 10 Гбит/с (с использованием гидры) |
|
||||
|
||||
В проекте ТСПУ типовые скорости — **10G** и **100G**.
|
||||
|
||||
Каждый физический порт QSFP28 разделён на **четыре линии** (lane 0–3), каждая из которых может работать на скорости до 25 Гбит/с. Объединение всех четырёх линий даёт суммарную скорость 100 Гбит/с.
|
||||
|
||||
> **Примечание:** management-интерфейс работает **только** на скорости 1 Гбит/с Ethernet. Скорости 10 и 100 Мбит/с не поддерживаются.
|
||||
|
||||
## 20.3. Гидры (breakout): один QSFP28 → четыре SFP+ (10G)
|
||||
|
||||
Для подключения 10-гигабитных интерфейсов используются **гидры** (breakout-кабели) — разветвители, преобразующие один порт QSFP28 в четыре порта SFP+ (10G):
|
||||
|
||||
```text
|
||||
QSFP28 порт (100G)
|
||||
│
|
||||
┌────┴────┐
|
||||
│ Гидра │
|
||||
└──┬─┬─┬─┬┘
|
||||
│ │ │ │
|
||||
SFP+ SFP+ SFP+ SFP+
|
||||
10G 10G 10G 10G
|
||||
```
|
||||
|
||||
Гидры могут быть:
|
||||
|
||||
- **Оптические** — с оптическими кабелями;
|
||||
- **DAC** (Direct Attach Copper) — с медными кабелями прямого подключения.
|
||||
|
||||
При использовании гидры в одном физическом QSFP28-разъёме появляется **до четырёх** независимых портов по 10 Гбит/с. Каждый из этих портов конфигурируется отдельно с указанием номера линии (lane).
|
||||
|
||||
## 20.4. Внутренняя архитектура
|
||||
|
||||
Внутренняя архитектура балансировщика включает несколько ключевых компонентов, связанных между собой:
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────┐
|
||||
│ Балансировщик │
|
||||
│ │
|
||||
│ ┌──────────┐ PCI-E ┌──────────────────┐ │
|
||||
│ │Микросервер├──────────────►│ Чип Barefoot │ │
|
||||
│ │ (Intel, │ │ Tofino │ │
|
||||
│ │ Linux) │ │ (коммутация) │──── 32× QSFP28
|
||||
│ └─────┬─────┘ └──────────────────┘ │
|
||||
│ │ │
|
||||
│ ┌─────┴─────┐ ┌───────────┐ │
|
||||
│ │ Ethernet │ │ │ │
|
||||
│ │ switch ├─────┤ BMC │ │
|
||||
│ │ (5 портов) │ │ │ │
|
||||
│ └─────┬─────┘ └───────────┘ │
|
||||
│ │ │
|
||||
│ ┌─────┴─────┐ ┌───────────┐ │
|
||||
│ │ Management │ │Console MUX│ │
|
||||
│ │ Ethernet │ │ │ │
|
||||
│ └───────────┘ └───────────┘ │
|
||||
│ │ │
|
||||
│ ┌────┴────┐ │
|
||||
│ │ Console │ │
|
||||
│ └─────────┘ │
|
||||
└──────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### 20.4.1. Микросервер (Intel, Linux) — CLI, конфигурация
|
||||
|
||||
**Микросервер** — основной «мозг» балансировщика, с которым взаимодействует оператор:
|
||||
|
||||
- Небольшая специализированная плата с **процессором Intel**;
|
||||
- Оснащён **памятью** и **SSD-диском** для хранения конфигурации и прошивки;
|
||||
- Работает под управлением **ОС Linux**;
|
||||
- Предоставляет **CLI** для настройки и мониторинга;
|
||||
- Связан с чипом Tofino по шине **PCI Express**;
|
||||
- **Программирует** чип Tofino — задаёт правила обработки и коммутации трафика.
|
||||
|
||||
Микросервер не обрабатывает трафик напрямую — он только управляет чипом коммутации.
|
||||
|
||||
### 20.4.2. Чип Barefoot Tofino — программируемая коммутация
|
||||
|
||||
**Barefoot Tofino** — высокопроизводительный программируемый чип, обеспечивающий коммутацию трафика на скорости провода:
|
||||
|
||||
- Соединён со всеми **32 портами QSFP28**;
|
||||
- Содержит **конвейеры** (pipelines), через которые проходят пакеты;
|
||||
- Программируется микросервером — правила балансировки, фильтрации, bypass загружаются в чип;
|
||||
- Обеспечивает производительность **3,2 Тбит/с**.
|
||||
|
||||
Все операции с трафиком (балансировка между фильтрами, программный байпас, фильтрация по flow rules) выполняются **внутри чипа Tofino** без участия микросервера.
|
||||
|
||||
### 20.4.3. BMC — управление аппаратной частью, сенсоры, блоки питания
|
||||
|
||||
**BMC** (Baseboard Management Controller) — модуль управления аппаратной платформой:
|
||||
|
||||
- **Мониторинг сенсоров** — температура, напряжение, токи;
|
||||
- **Управление блоками питания** — статус, параметры;
|
||||
- **Мониторинг SFP-трансиверов** — диагностическая информация, уровни сигналов (DDM);
|
||||
- **Аварийное управление** — при критических проблемах (например, перегрев) BMC может отключить отдельные компоненты или полностью погасить платформу.
|
||||
|
||||
> **Практический случай:** весной на ряде площадок наблюдались зависания балансировщиков. Причиной оказалось некорректное считывание BMC показаний температурного датчика — BMC ошибочно определял перегрев и выключал микросервер.
|
||||
|
||||
Доступ к BMC возможен:
|
||||
|
||||
- Через **внешнюю консоль** (при определённых настройках Console MUX);
|
||||
- Через **Management Ethernet** (один порт обеспечивает доступ и к микросерверу, и к BMC).
|
||||
|
||||
### 20.4.4. Ethernet switch (5-портовый) — доступ к микросерверу и BMC
|
||||
|
||||
Внутри балансировщика расположен **5-портовый Ethernet-коммутатор**, к которому подключены:
|
||||
|
||||
- **Management Ethernet** (внешний порт на передней панели);
|
||||
- **Микросервер** (CLI, конфигурация);
|
||||
- **BMC** (управление аппаратной частью).
|
||||
|
||||
Благодаря этому коммутатору **один внешний Ethernet-порт** обеспечивает доступ одновременно к микросерверу и BMC — каждый на своём IP-адресе.
|
||||
|
||||
### 20.4.5. Console MUX — переключение консоли между компонентами
|
||||
|
||||
**Console MUX** — мультиплексор консольного порта, позволяющий переключать физическую консоль между различными внутренними компонентами:
|
||||
|
||||
- **Микросервер** — основной режим, доступ к CLI;
|
||||
- **BMC** — для диагностики и восстановления аппаратной части.
|
||||
|
||||
> **Внимание:** скорость консольного порта может различаться в зависимости от того, к какому компоненту вы подключены. Если подключение к BMC — может быть одна скорость, к микросерверу — другая. На новых устройствах иногда приходится **подбирать скорость** консольного соединения.
|
||||
|
||||
## 20.5. Передняя панель: Console, Management Ethernet, USB
|
||||
|
||||
На передней панели балансировщика расположены:
|
||||
|
||||
| Порт / разъём | Описание |
|
||||
| ----------------------- | --------------------------------------------------------- |
|
||||
| **Console** | Консольный порт (через Console MUX переключается между микросервером и BMC) |
|
||||
| **Management Ethernet** | Порт управления (1 Гбит/с), доступ к микросерверу и BMC через внутренний коммутатор |
|
||||
| **USB** | USB-порт, доступен с микросервера и через USB-хаб |
|
||||
| **32× QSFP28** | Порты для подключения трафика (операторские линки и фильтры) |
|
||||
|
||||
Также на панели присутствует **диагностический разъём**, не используемый в эксплуатации.
|
||||
|
||||
**Учётные данные по умолчанию:**
|
||||
|
||||
| Доступ | Логин/пароль |
|
||||
| ---------- | ----------------------- |
|
||||
| **SSH** | `admin` / `admin` |
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 19: Фильтр: обновление прошивки](19.md) · [Раздел 21: Балансировщик: конфигурация →](21.md)
|
||||
486
chapters/21.md
Normal file
486
chapters/21.md
Normal file
@@ -0,0 +1,486 @@
|
||||
# 21. Балансировщик: конфигурация
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 20: Балансировщик: аппаратная платформа](20.md)
|
||||
|
||||
---
|
||||
|
||||
Настройка балансировщика (EcoFilter Balancer) начинается после установки прошивки и конфигурации сегмента управления. В отличие от фильтра, на балансировщике **нет дефолтной конфигурации** — все секции (порты, линки, группы балансировки, фильтры) необходимо создавать вручную.
|
||||
|
||||
## 21.1. CLI: операционный режим / конфигурационный режим (`edit`)
|
||||
|
||||
CLI балансировщика, как и у фильтра, имеет **два режима** работы:
|
||||
|
||||
| Режим | Переход | Назначение |
|
||||
| -------------------- | -------------------- | ----------------------------------------- |
|
||||
| **Операционный** | по умолчанию | Просмотр информации: команды `show` |
|
||||
| **Конфигурационный** | команда **`edit`** | Изменение всех настроек устройства |
|
||||
|
||||
> **Отличие от фильтра:** на фильтре для перехода в конфигурационный режим используется команда `config`, а на балансировщике — **`edit`**.
|
||||
|
||||
### 21.1.1. Интерфейс похож на Juniper CLI
|
||||
|
||||
Интерфейс командной строки балансировщика **очень похож на CLI Juniper**. Настройки задаются с помощью команды `set`:
|
||||
|
||||
```text
|
||||
set <путь> <параметр> <значение>
|
||||
```
|
||||
|
||||
Для тех, кто знаком с оборудованием Juniper, работа с CLI балансировщика не вызовет затруднений.
|
||||
|
||||
### 21.1.2. `apply` — применить, `save` — сохранить в startup
|
||||
|
||||
После внесения изменений их необходимо применить и сохранить:
|
||||
|
||||
```text
|
||||
Внесение изменений ──► apply ──► save
|
||||
│ │ │
|
||||
│ │ └─ Сохранение в startup-config
|
||||
│ │ (переживёт перезагрузку)
|
||||
│ │
|
||||
│ └─ Применение конфигурации
|
||||
│ (изменения вступают в силу)
|
||||
│
|
||||
└─ Изменения только в буфере
|
||||
(не активны, не сохранены)
|
||||
```
|
||||
|
||||
| Команда | Действие |
|
||||
| ----------- | ------------------------------------------------------------------------- |
|
||||
| **`apply`** | Применяет конфигурацию — изменения вступают в силу |
|
||||
| **`save`** | Сохраняет конфигурацию в startup-config (переживёт перезагрузку) |
|
||||
|
||||
> **Важно:** в прошивке пилотного проекта (Урал) команда `apply` одновременно и применяла, и сохраняла конфигурацию в startup-config. В текущих (федеральных) прошивках это поведение изменено: `apply` только применяет, а для сохранения нужна отдельная команда `save`.
|
||||
|
||||
## 21.2. Обновление прошивки: `call rdp firmware download` / `call rdp install`
|
||||
|
||||
Обновление прошивки балансировщика выполняется в **два этапа** — скачивание и установка:
|
||||
|
||||
### Этап 1: Скачивание
|
||||
|
||||
```text
|
||||
call rdp firmware download <URL> <имя_файла>
|
||||
```
|
||||
|
||||
Скачивает образ прошивки с указанного URL и сохраняет его на устройстве под указанным именем.
|
||||
|
||||
### Этап 2: Установка
|
||||
|
||||
```text
|
||||
call rdp install <имя_файла>
|
||||
```
|
||||
|
||||
Устанавливает прошивку из указанного файла. По завершении команда выводит результат — `OK` или сообщение об ошибке.
|
||||
|
||||
### Дополнительные команды
|
||||
|
||||
| Команда | Действие |
|
||||
| -------------------------------- | ------------------------------------------------------ |
|
||||
| `call rdp firmware list` | Показать список файлов прошивок на устройстве |
|
||||
| `call rdp firmware delete` | Удалить файл прошивки |
|
||||
| `call rdp firmware set-active` | Установить активную прошивку на указанный раздел |
|
||||
| `show rdp firmware version` | Показать состояние прошивок (версия, активность, tries) |
|
||||
|
||||
### 21.2.1. Два раздела прошивок (A/B), автоматический rollback (3 попытки / 20 мин)
|
||||
|
||||
Как и на фильтре, балансировщик хранит **два раздела** прошивок — **A** и **B**:
|
||||
|
||||
| Раздел | Описание |
|
||||
| ------ | ---------------------------------------------------------- |
|
||||
| **A** | Первый раздел для прошивки |
|
||||
| **B** | Второй раздел для прошивки |
|
||||
|
||||
Для каждого раздела отображается:
|
||||
|
||||
- **Активность** — активна эта прошивка или нет;
|
||||
- **Версия** — номер версии прошивки;
|
||||
- **Tries** — счётчик попыток загрузки.
|
||||
|
||||
Новая прошивка всегда устанавливается **вместо неактивной** в данный момент.
|
||||
|
||||
**Механизм автоматического rollback:**
|
||||
|
||||
Балансировщик отслеживает **количество неудачных попыток** загрузки с конкретной прошивки. Если устройство **более 3 раз подряд** не смогло загрузиться с определённой прошивки в течение приблизительно **20 минут**, эта прошивка считается **ненадёжной**, и балансировщик автоматически переключается на другой раздел.
|
||||
|
||||
> **Практический совет:** если вам нужно несколько раз перезагрузить балансировщик в короткий промежуток времени (например, для тестирования), помните о лимите в 3 перезагрузки. После третьей перезагрузки за короткий период прошивка будет признана нестабильной. Количество попыток и временной интервал **не настраиваются** — они зашиты в прошивке.
|
||||
|
||||
### 21.2.2. `call rdp firmware reset-tries`
|
||||
|
||||
Для сброса счётчика попыток загрузки используется команда:
|
||||
|
||||
```text
|
||||
call rdp firmware reset-tries
|
||||
```
|
||||
|
||||
Эта команда обнуляет значение **tries**, позволяя продолжить перезагрузки без риска автоматического переключения на другой раздел. В промышленной эксплуатации эта команда практически не требуется, но знать о ней полезно.
|
||||
|
||||
## 21.3. Настройка физических портов
|
||||
|
||||
Настройка физических портов — это **первый шаг** конфигурации балансировщика. Поскольку дефолтной конфигурации нет, все порты необходимо создавать вручную.
|
||||
|
||||
Для каждого порта задаются следующие параметры:
|
||||
|
||||
| Параметр | Описание |
|
||||
| --------------- | ------------------------------------------------------------ |
|
||||
| **Имя порта** | Произвольное имя (рекомендуется формат `P<порт><линия>`) |
|
||||
| **number** | Номер физического интерфейса на лицевой панели (1–32) |
|
||||
| **lane** | Номер линии внутри физического порта (0–3) |
|
||||
| **speed** | Скорость порта: 10G, 25G или 100G |
|
||||
| **mtu** | Максимальный размер кадра |
|
||||
| **description** | Текстовое описание порта |
|
||||
|
||||
Пример конфигурации двух 10-гигабитных портов на одном физическом интерфейсе:
|
||||
|
||||
```text
|
||||
set ports P21 number 2 lane 1 speed 10g
|
||||
set ports P22 number 2 lane 2 speed 10g
|
||||
```
|
||||
|
||||
### 21.3.1. Имя порта, номер физического порта (number), линия (lane), скорость (speed)
|
||||
|
||||
Имя порта может быть **произвольным**, однако рекомендуется придерживаться единообразной схемы именования, отражающей номер физического порта и номер линии:
|
||||
|
||||
```text
|
||||
P<номер_порта><номер_линии>
|
||||
```
|
||||
|
||||
Например:
|
||||
|
||||
| Имя порта | Физический порт | Линия | Скорость | Описание |
|
||||
| --------- | --------------- | ----- | -------- | ------------------------------------ |
|
||||
| `P21` | 2 | 1 | 10G | Порт 2, линия 1 — первый 10G-канал |
|
||||
| `P22` | 2 | 2 | 10G | Порт 2, линия 2 — второй 10G-канал |
|
||||
| `P2` | 2 | — | 100G | Порт 2, все линии — 100G-канал |
|
||||
|
||||
### 21.3.2. 10G: указание lane (0–3), 100G: все lane задействованы
|
||||
|
||||
Поведение параметра **lane** зависит от выбранной скорости:
|
||||
|
||||
**При 10G (или 25G):**
|
||||
|
||||
Каждый физический порт QSFP28 содержит 4 линии. При использовании гидры (breakout-кабеля) каждая линия становится отдельным 10-гигабитным портом. Для каждого такого порта необходимо явно указать номер линии (`lane 0`, `lane 1`, `lane 2`, `lane 3`):
|
||||
|
||||
```text
|
||||
set ports P20 number 2 lane 0 speed 10g
|
||||
set ports P21 number 2 lane 1 speed 10g
|
||||
set ports P22 number 2 lane 2 speed 10g
|
||||
set ports P23 number 2 lane 3 speed 10g
|
||||
```
|
||||
|
||||
В результате из одного физического QSFP28-разъёма получается **4 независимых порта** по 10 Гбит/с.
|
||||
|
||||
**При 100G:**
|
||||
|
||||
Все 4 линии объединены в один канал. Параметр `lane` **не указывается**, так как задействованы все линии:
|
||||
|
||||
```text
|
||||
set ports P2 number 2 speed 100g
|
||||
```
|
||||
|
||||
> **Рекомендация:** все физические порты настраиваются в соответствии со схемой организации связи на конкретной площадке. Единых «стандартных» настроек нет — конфигурация полностью зависит от того, какие устройства и на каких скоростях подключены к балансировщику.
|
||||
|
||||
## 21.4. Настройка линков (объединение двух портов LAN+WAN в сторону оператора)
|
||||
|
||||
**Линк** (link) в терминологии балансировщика — это объединение **двух портов** (LAN и WAN) в сторону оператора связи:
|
||||
|
||||
```text
|
||||
Оператор связи
|
||||
│
|
||||
┌────┴────┐
|
||||
│ Байпас │
|
||||
└──┬───┬──┘
|
||||
│ │
|
||||
LAN WAN ← это один линк
|
||||
│ │
|
||||
┌──┴───┴──┐
|
||||
│Балансир.│
|
||||
└─────────┘
|
||||
```
|
||||
|
||||
Каждый линк всегда содержит **ровно один LAN-порт** и **ровно один WAN-порт**.
|
||||
|
||||
Настройка линка:
|
||||
|
||||
```text
|
||||
set links <имя_линка> lan-port <имя_LAN_порта> wan-port <имя_WAN_порта>
|
||||
set links <имя_линка> description "<описание>"
|
||||
```
|
||||
|
||||
Пример:
|
||||
|
||||
```text
|
||||
set links link1 lan-port P21 wan-port P22
|
||||
set links link1 description "Bypass1-Mon0/Mon1"
|
||||
```
|
||||
|
||||
| Параметр | Описание |
|
||||
| ---------------- | ----------------------------------------------------------- |
|
||||
| **Имя линка** | Произвольное название (рекомендуется единообразная схема) |
|
||||
| **lan-port** | Порт в сторону абонентов (LAN) |
|
||||
| **wan-port** | Порт в сторону интернета (WAN) |
|
||||
| **description** | Описание — к какому байпасу и интерфейсу подключен линк |
|
||||
|
||||
> **Рекомендация:** в описании линка указывайте, к какому конкретно байпасу и к каким его интерфейсам подключён данный линк. Это значительно упрощает диагностику.
|
||||
|
||||
## 21.5. Настройка группы балансировки
|
||||
|
||||
После настройки портов и линков необходимо создать **группу балансировки** (balance group) и привязать к ней группы портов в сторону фильтров.
|
||||
|
||||
```text
|
||||
Линки (оператор) Группа балансировки Фильтры
|
||||
│ │ │
|
||||
┌────┴────┐ ┌──────┴──────┐ ┌─────┴─────┐
|
||||
│ link1 │ │ │ │ Filter │
|
||||
│ link2 │──────► │ Balance │──────│ Group 1 │──► Фильтр 1
|
||||
│ link3 │ Flow │ Group │ │ Group 2 │──► Фильтр 1
|
||||
│ ... │ rules │ │ │ Group 3 │──► Фильтр 2
|
||||
└─────────┘ └──────┬──────┘ │ ... │
|
||||
│ └───────────┘
|
||||
Профиль проверки
|
||||
доступности
|
||||
```
|
||||
|
||||
### 21.5.1. Привязка групп портов в сторону фильтров (filter groups)
|
||||
|
||||
К группе балансировки привязываются **filter groups** — пары портов (LAN + WAN) в сторону фильтров:
|
||||
|
||||
```text
|
||||
set balance-group <имя_группы> filter-group <имя_filter_group> lan-port <порт> wan-port <порт>
|
||||
```
|
||||
|
||||
Количество filter groups определяется количеством пар интерфейсов в сторону фильтров:
|
||||
|
||||
| Конфигурация площадки | Количество filter groups |
|
||||
| -------------------------------------------- | ------------------------ |
|
||||
| 1 фильтр, 16 портов (8 пар LAN/WAN) | 8 |
|
||||
| 10 фильтров, 16 портов каждый (80 пар) | 80 |
|
||||
|
||||
Каждая filter group объединяет один LAN-порт и один WAN-порт, смотрящие в сторону конкретной пары интерфейсов фильтра.
|
||||
|
||||
### 21.5.2. N_UNIT_QA: количество ядер фильтра минус один
|
||||
|
||||
Параметр **N_UNIT_QA** сообщает балансировщику количество ядер на подключённых фильтрах, которые участвуют в обработке трафика:
|
||||
|
||||
```text
|
||||
set balance-group <имя_группы> n-unit-qa <число>
|
||||
```
|
||||
|
||||
Значение **всегда равно общему количеству ядер процессора фильтра минус один**:
|
||||
|
||||
| Модель фильтра | Ядер всего | N_UNIT_QA |
|
||||
| ----------------------------- | ---------- | --------- |
|
||||
| Xeon 2695 (18 ядер) | 18 | 17 |
|
||||
| Xeon 2699 (22 ядра) | 22 | 21 |
|
||||
| Xeon Gold 6212 (24 ядра) | 24 | 23 |
|
||||
|
||||
Причина вычитания единицы: на фильтре **все ядра, кроме одного**, отданы под процесс EcoNAT, который обрабатывает трафик. Одно ядро — **сервисное**: на нём работает Linux, системные логи, управление. Оно не участвует в обработке трафика.
|
||||
|
||||
Этот параметр **напрямую влияет на балансировку** — балансировщик распределяет трафик не только между фильтрами, но и между их ядрами, обеспечивая равномерную нагрузку.
|
||||
|
||||
## 21.6. Профиль проверки доступности (keep-alive)
|
||||
|
||||
К группе балансировки привязывается **профиль проверки доступности** (availability profile), определяющий параметры отправки keep-alive пакетов через группы портов в сторону фильтров.
|
||||
|
||||
```text
|
||||
set balance-group <имя_группы> availability-profile <имя_профиля>
|
||||
```
|
||||
|
||||
Профиль настраивается отдельно:
|
||||
|
||||
```text
|
||||
set availability-profile <имя_профиля> <параметр> <значение>
|
||||
```
|
||||
|
||||
### 21.6.1. Начальная задержка, интервал, порог потерь
|
||||
|
||||
| Параметр | Описание |
|
||||
| -------------------------- | -------------------------------------------------------------------- |
|
||||
| **Начальная задержка** | Время ожидания перед началом отправки keep-alive после поднятия интерфейсов (например, 1000 мс). Необходимо, чтобы фильтр успел полностью инициализировать интерфейсы |
|
||||
| **Интервал** | Периодичность отправки keep-alive пакетов (например, 100 мс) |
|
||||
| **Порог потерь (down)** | Количество последовательно потерянных пакетов, после которых filter group считается **неактивной** (например, 5 пакетов) |
|
||||
| **Порог восстановления (up)** | Количество последовательно полученных ответов, после которых неактивная filter group считается снова **активной** |
|
||||
|
||||
Механизм работы: балансировщик отправляет keep-alive пакет в LAN-порт filter group и ожидает получить его через парный WAN-порт. Время прохождения пакета (time of pass) измеряется в наносекундах и в нормальном состоянии составляет порядка **20–30 микросекунд**.
|
||||
|
||||
При потере заданного количества последовательных пакетов filter group переводится в состояние **bypass** — трафик не отправляется на фильтр, а перекладывается из одного порта в другой на уровне логики балансировщика.
|
||||
|
||||
### 21.6.2. Минимальное количество активных пар
|
||||
|
||||
Параметр **минимальное количество активных пар** (minimum active pairs) определяет, при каком количестве рабочих filter groups вся группа балансировки **целиком** считается активной.
|
||||
|
||||
Пример: если задано значение 8, то группа балансировки будет считаться рабочей, пока хотя бы 8 filter groups активны — неважно, сколько их всего.
|
||||
|
||||
> **Уральский пилотный проект:** минимальное количество активных пар было установлено **равным общему количеству** пар в сторону фильтров. В результате при потере хотя бы одного интерфейса вся группа балансировки переходила в неактивное состояние, и балансировщик включал bypass на всех линках. Весь трафик ТСПУ снимался из-за одного упавшего интерфейса. Такое поведение **не обязательно** — значение можно настроить более гибко.
|
||||
|
||||
### 21.6.3. Перебалансировка: включение/выключение
|
||||
|
||||
Параметр **перебалансировки** (rebalancing) определяет, что происходит при выходе из строя одной из filter groups:
|
||||
|
||||
| Значение | Поведение |
|
||||
| --------------- | ---------------------------------------------------------------------- |
|
||||
| **Включена** | Трафик пересчитывается и распределяется по оставшимся filter groups |
|
||||
| **Выключена** | Для упавшей filter group включается программный bypass, остальные работают без изменений |
|
||||
|
||||
**Перебалансировка** занимает определённое время и вычислительные ресурсы. При пересчёте хэша сессии могут попасть на **другие интерфейсы и другие фильтры**, что в общем случае может быть нежелательным (разрыв DPI-сессий, потеря контекста анализа).
|
||||
|
||||
> **Рекомендация:** в федеральном проекте перебалансировку планируется **отключить**. При потере filter group для конкретной пары интерфейсов включается **программный bypass** — трафик не отправляется на фильтр, а перекладывается из LAN-порта в WAN-порт и наоборот. Последствия минимальны: небольшая часть трафика временно не фильтруется. Это меньшее зло, чем флапание линков или разрыв всех сессий при перебалансировке. Система мониторинга получает уведомления (логи, SNMP traps), и проблема устраняется вручную.
|
||||
|
||||
## 21.7. Настройка фильтров (Flow rules)
|
||||
|
||||
**Фильтры** (flow rules) на балансировщике — это правила, определяющие, что делать с трафиком, поступающим через линки. Каждое правило состоит из двух частей:
|
||||
|
||||
| Часть | Описание |
|
||||
| ---------- | ----------------------------------------------------------- |
|
||||
| **Match** | Условия, по которым отбирается трафик (заголовки пакетов) |
|
||||
| **Action** | Действие с пакетом при совпадении |
|
||||
|
||||
### 21.7.1. Match-условия: VLAN, IPv4 src/dst, L4 port, MAC, MPLS, глубина тегов
|
||||
|
||||
Доступные условия для match-секции:
|
||||
|
||||
| Условие | Описание |
|
||||
| ---------------------- | ------------------------------------------------- |
|
||||
| **VLAN ID** | Номер VLAN-тега (например, `vlan 0 id 1`) |
|
||||
| **IPv4 source** | IP-адрес источника (с маской / префиксом) |
|
||||
| **IPv4 destination** | IP-адрес назначения (с маской / префиксом) |
|
||||
| **L4 port** | Порт транспортного уровня (TCP/UDP) |
|
||||
| **MAC address** | MAC-адрес источника или назначения |
|
||||
| **MPLS labels** | Количество MPLS-меток |
|
||||
| **Глубина VLAN-тегов** | Количество VLAN-тегов (для QinQ) |
|
||||
|
||||
В одном правиле можно комбинировать **несколько условий** одновременно. Например, одновременно проверять VLAN ID и IPv4-подсеть.
|
||||
|
||||
Match-условия можно использовать как для **включения** трафика в обработку, так и для **исключения** определённого трафика.
|
||||
|
||||
### 21.7.2. Actions: `balancing s_mac` → balance group / `bypass`
|
||||
|
||||
Действие (action) определяет, что происходит с пакетом при совпадении:
|
||||
|
||||
| Action | Описание |
|
||||
| ----------------------- | ---------------------------------------------------------------- |
|
||||
| **balancing s_mac** | Отправить трафик на группу балансировки. Балансировка выполняется по хэшу от source IP, destination IP и протокола |
|
||||
| **bypass** | Пропустить трафик прозрачно — переложить из одного порта в другой, не отправляя на фильтры |
|
||||
|
||||
При использовании `balancing s_mac` дополнительно указывается **целевая группа балансировки**:
|
||||
|
||||
```text
|
||||
set filters <имя_фильтра> flows <имя_правила> action balancing s_mac
|
||||
set filters <имя_фильтра> flows <имя_правила> to-balance-group <имя_группы>
|
||||
```
|
||||
|
||||
Пример правила, отправляющего трафик с VLAN ID 1 на фильтры:
|
||||
|
||||
```text
|
||||
set filters main flows traffic-to-filter-1 match vlan 0 id 1
|
||||
set filters main flows traffic-to-filter-1 action balancing s_mac
|
||||
set filters main flows traffic-to-filter-1 to-balance-group group-filter
|
||||
set filters main flows traffic-to-filter-1 priority 100
|
||||
```
|
||||
|
||||
Пример правила bypass для всего остального трафика:
|
||||
|
||||
```text
|
||||
set filters main flows default-bypass action bypass
|
||||
set filters main flows default-bypass priority 1
|
||||
```
|
||||
|
||||
### 21.7.3. Приоритеты правил
|
||||
|
||||
Каждому правилу назначается **приоритет** (priority), определяющий порядок обработки. Пакет проверяется по правилам в порядке убывания приоритета — от **высшего** к **низшему**. Первое совпавшее правило определяет действие.
|
||||
|
||||
Типовая структура правил:
|
||||
|
||||
```text
|
||||
Приоритет Правило Action
|
||||
─────────────────────────────────────────────────────
|
||||
100 VLAN 1 → на фильтр balancing s_mac
|
||||
90 VLAN 2 → на фильтр balancing s_mac
|
||||
80 VLAN 3 → на фильтр balancing s_mac
|
||||
... ... ...
|
||||
1 Всё остальное → bypass bypass
|
||||
```
|
||||
|
||||
Правило с **самым низким приоритетом** и **без match-условий** (совпадает со всем) обычно задаёт action `bypass`. Это означает: всё, что не попало под предыдущие правила, пропускается прозрачно.
|
||||
|
||||
> **Применение для диагностики:** при траблшутинге можно создать правило с высоким приоритетом, которое перехватывает трафик конкретного VLAN и выполняет action `bypass`. Это позволяет исключить конкретный трафик из обработки фильтрами и проверить, влияет ли ТСПУ на проблему. По статистике правила (количество пакетов/байт) можно убедиться, что трафик действительно проходит через это правило.
|
||||
|
||||
### 21.7.4. Привязка фильтров к линкам
|
||||
|
||||
После настройки правил необходимо **привязать фильтр к линкам** — указать, на каких линках (в сторону оператора) данные правила будут действовать:
|
||||
|
||||
```text
|
||||
set filters <имя_фильтра> links [ <линк1> <линк2> ... ]
|
||||
```
|
||||
|
||||
Пример:
|
||||
|
||||
```text
|
||||
set filters main links [ link1 link2 link3 link4 ]
|
||||
```
|
||||
|
||||
Один набор правил (фильтр) может быть привязан к **нескольким линкам** одновременно. Все линки, привязанные к фильтру, используют одни и те же flow rules.
|
||||
|
||||
## 21.8. Настройка Heartbeat для GL Sun (пилотный проект)
|
||||
|
||||
Данная настройка актуальна **только для пилотного проекта на Урале**, где используются байпасы GL Sun. В федеральном проекте с байпасами Silicom эта настройка **не требуется** — Silicom самостоятельно генерирует и проверяет heartbeat-пакеты.
|
||||
|
||||
На Урале балансировщик работает в активном режиме и сам должен отправлять heartbeat-пакеты на байпас GL Sun:
|
||||
|
||||
| Параметр | Описание |
|
||||
| --------------------------- | --------------------------------------------------------------- |
|
||||
| **IPv4-адрес байпаса** | IP-адрес байпаса GL Sun |
|
||||
| **Порт** | Порт для heartbeat-протокола |
|
||||
| **Период отсылки** | Интервал отправки heartbeat (в наносекундах, например, 30 мкс) |
|
||||
| **Группа балансировки** | Группа, для которой работает отправка heartbeat |
|
||||
| **Список линков байпаса** | Идентификаторы сущностей на стороне байпаса GL Sun |
|
||||
| **ToS** | Тип сервиса в IP-заголовке heartbeat-пакетов |
|
||||
| **Автоматический возврат** | Возможность автоматического возврата трафика в режим primary при восстановлении группы балансировки |
|
||||
|
||||
Heartbeat-пакеты отправляются только при условии, что **группа балансировки находится в состоянии Active**. При переходе группы в неактивное состояние отправка прекращается, и связь с байпасом (по TCP) разрывается — состояние переходит в `disconnected`.
|
||||
|
||||
> **Примечание:** с байпасами Silicom логика работы другая — Silicom самостоятельно отсылает heartbeat и проверяет доступность интерфейсов, а балансировщик прозрачно пропускает эти пакеты между своими портами.
|
||||
|
||||
## 21.9. Management-интерфейс: IP, маска, default gateway
|
||||
|
||||
Настройка management-интерфейса балансировщика выполняется аналогично другим сетевым устройствам:
|
||||
|
||||
```text
|
||||
set management ip <IP-адрес>
|
||||
set management mask <маска_подсети>
|
||||
set management default-gateway <IP-шлюза>
|
||||
```
|
||||
|
||||
Management-интерфейс обеспечивает доступ к устройству по SSH и используется для управления, мониторинга и взаимодействия с ЦСУ.
|
||||
|
||||
> **Напоминание:** management Ethernet работает **только** на скорости 1 Гбит/с (см. [раздел 20.2](20.md)).
|
||||
|
||||
---
|
||||
|
||||
## Общий порядок настройки балансировщика
|
||||
|
||||
Для наглядности — последовательность настройки балансировщика «с нуля»:
|
||||
|
||||
```text
|
||||
1. Установить прошивку
|
||||
│
|
||||
2. Настроить management-интерфейс
|
||||
│
|
||||
3. Настроить физические порты (ports)
|
||||
│
|
||||
4. Настроить линки (links) — пары LAN/WAN в сторону оператора
|
||||
│
|
||||
5. Настроить группу балансировки (balance group)
|
||||
└── Создать filter groups (пары портов в сторону фильтров)
|
||||
└── Задать N_UNIT_QA
|
||||
└── Привязать профиль проверки доступности
|
||||
│
|
||||
6. Настроить профиль проверки доступности (availability profile)
|
||||
│
|
||||
7. Настроить фильтры (flow rules) — правила обработки трафика
|
||||
└── Привязать фильтры к линкам
|
||||
│
|
||||
8. apply + save
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 20: Балансировщик: аппаратная платформа](20.md) · [Раздел 22: Балансировщик: мониторинг и диагностика →](22.md)
|
||||
262
chapters/22.md
Normal file
262
chapters/22.md
Normal file
@@ -0,0 +1,262 @@
|
||||
# 22. Балансировщик: мониторинг и диагностика
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 21: Балансировщик: конфигурация](21.md)
|
||||
|
||||
---
|
||||
|
||||
Балансировщик предоставляет набор команд для мониторинга аппаратного состояния, проверки прошивок, диагностики портов, анализа правил фильтрации и контроля групп балансировки. Все команды мониторинга выполняются в **операционном режиме**.
|
||||
|
||||
## 22.1. `show hardware info` — CPU, память, вентиляторы, БП, температура
|
||||
|
||||
Команда `show hardware info` с различными ключевыми словами отображает состояние аппаратных компонентов балансировщика:
|
||||
|
||||
| Команда | Описание |
|
||||
| -------------------------------- | ------------------------------------------- |
|
||||
| `show hardware info cpu` | Нагрузка на процессор (микросервер) |
|
||||
| `show hardware info memory` | Состояние оперативной памяти |
|
||||
| `show hardware info fans` | Состояние вентиляторов |
|
||||
| `show hardware info power` | Состояние блоков питания |
|
||||
| `show hardware info temperature` | Показания температурных датчиков |
|
||||
| **`show hardware info all`** | **Вся информация** по всем компонентам |
|
||||
|
||||
Для быстрой проверки общего состояния платформы удобно использовать `show hardware info all` — команда выводит полную картину по всем аппаратным подсистемам.
|
||||
|
||||
> **Практический случай:** именно через мониторинг температурных датчиков была выявлена проблема с зависаниями балансировщиков весной — BMC некорректно считывал показания датчика, ошибочно определял перегрев и выключал микросервер (подробнее — в [разделе 20.4.3](20.md)).
|
||||
|
||||
## 22.2. `show mng if` — management-интерфейс
|
||||
|
||||
Команда `show mng if` отображает текущее состояние management-интерфейса:
|
||||
|
||||
- **IP-адрес**;
|
||||
- **Маска подсети**;
|
||||
- **Default gateway**;
|
||||
- **Состояние интерфейса** (up/down).
|
||||
|
||||
Команда полезна для быстрой проверки параметров управления после настройки или перезагрузки устройства.
|
||||
|
||||
## 22.3. `show rdp firmware version` — версии прошивок, tries
|
||||
|
||||
Команда `show rdp firmware version` выводит полную информацию о состоянии прошивок:
|
||||
|
||||
```text
|
||||
Current active firmware: A
|
||||
|
||||
Partition A:
|
||||
Status: active
|
||||
Version: 2.4.1
|
||||
Tries: 0
|
||||
|
||||
Partition B:
|
||||
Status: inactive
|
||||
Version: 2.3.8
|
||||
Tries: 0
|
||||
```
|
||||
|
||||
| Параметр | Описание |
|
||||
| ----------------- | --------------------------------------------------------------------- |
|
||||
| **Current active**| Какой раздел (A или B) является текущим активным |
|
||||
| **Status** | `active` или `inactive` для каждого раздела |
|
||||
| **Version** | Номер версии прошивки в разделе |
|
||||
| **Tries** | Счётчик попыток загрузки с данного раздела |
|
||||
|
||||
### Параметр Tries
|
||||
|
||||
В нормальном состоянии **Tries = 0**. Ненулевое значение означает, что балансировщик предпринимал неудачные попытки загрузки с этого раздела.
|
||||
|
||||
Если балансировщик **более 3 раз подряд** за ~20 минут не смог загрузиться с определённого раздела, прошивка считается **ненадёжной** и происходит автоматический rollback на другой раздел (подробнее — в [разделе 21.2.1](21.md)).
|
||||
|
||||
Для сброса счётчика используется команда `call rdp firmware reset-tries`.
|
||||
|
||||
## 22.4. Состояние портов и трансиверов: SFP-информация, DDM, статистика фреймов
|
||||
|
||||
### Информация о трансиверах
|
||||
|
||||
Для каждого порта можно вывести информацию об установленном трансивере:
|
||||
|
||||
```text
|
||||
show port <имя_порта> sfp
|
||||
```
|
||||
|
||||
В выводе отображаются **все четыре линии** (lane) физического порта, даже если задействованы не все. Для каждой линии показаны:
|
||||
|
||||
| Параметр | Описание |
|
||||
| ------------------------- | ---------------------------------------------------------- |
|
||||
| **Тип трансивера** | Оптика, DAC (медный кабель прямого подключения) и т.д. |
|
||||
| **Справочная информация** | Производитель, модель, серийный номер SFP |
|
||||
| **Уровень сигнала (DDM)** | Мощность в децибелах (только для оптических трансиверов) |
|
||||
|
||||
> **Примечание:** для медных DAC-кабелей (гидр) уровень сигнала **не отображается**, так как DDM-мониторинг применяется только к оптике. Если установлена оптическая гидра — значения мощности будут видны для каждой линии.
|
||||
|
||||
### Подробная статистика порта
|
||||
|
||||
Для каждого порта доступна детальная статистика на уровне фреймов:
|
||||
|
||||
```text
|
||||
show port <имя_порта> statistics
|
||||
```
|
||||
|
||||
Вывод содержит подробную информацию:
|
||||
|
||||
- Количество полученных и отправленных фреймов;
|
||||
- Фреймы с ошибками;
|
||||
- Распределение по размерам фреймов;
|
||||
- Счётчики различных типов ошибок.
|
||||
|
||||
Эта статистика полезна при диагностике проблем с физическим подключением — ошибки на уровне фреймов могут указывать на проблемы с кабелями, трансиверами или несовместимость оборудования.
|
||||
|
||||
## 22.5. Статистика правил фильтрации: счётчики пакетов/байт по каждому flow
|
||||
|
||||
По каждому правилу фильтрации (flow rule) балансировщик ведёт **счётчики пакетов и байт**, прошедших через данное правило:
|
||||
|
||||
```text
|
||||
show filters <имя_фильтра> flows <имя_правила>
|
||||
```
|
||||
|
||||
В выводе отображается поле **statistics** с количеством пакетов и байт, которые были заматчены данным правилом.
|
||||
|
||||
### Применение для диагностики
|
||||
|
||||
Статистика правил — мощный инструмент диагностики. Типовые сценарии:
|
||||
|
||||
**Сценарий 1: Проверка наличия трафика**
|
||||
|
||||
Если оператор сообщает, что трафик определённого VLAN проходит через площадку, можно убедиться в этом по счётчикам соответствующего правила. Если счётчики растут — трафик действительно проходит через балансировщик.
|
||||
|
||||
**Сценарий 2: Исключение ТСПУ как причины проблемы**
|
||||
|
||||
Для диагностики можно создать **временное правило** с высоким приоритетом, которое матчит проблемный трафик (например, конкретный VLAN) и выполняет action `bypass`:
|
||||
|
||||
```text
|
||||
1. Создать правило: match VLAN <номер>, action bypass, высокий приоритет
|
||||
2. Применить конфигурацию (apply)
|
||||
3. Проверить: изменилось ли поведение трафика?
|
||||
4. Проверить счётчики правила: трафик проходит?
|
||||
```
|
||||
|
||||
Если после создания bypass-правила проблема исчезла — причина в обработке на фильтрах, и нужно диагностировать дальше. Если проблема осталась, а счётчики показывают, что трафик проходит через правило — ТСПУ не является причиной.
|
||||
|
||||
> **Важно:** после завершения диагностики не забудьте **удалить временное правило** и применить конфигурацию.
|
||||
|
||||
## 22.6. Состояние группы балансировки
|
||||
|
||||
Команда для просмотра состояния группы балансировки:
|
||||
|
||||
```text
|
||||
show balance-group <имя_группы>
|
||||
```
|
||||
|
||||
Вывод показывает общее состояние группы и статус каждой filter group внутри неё.
|
||||
|
||||
### 22.6.1. Статус filter groups: up/bypass
|
||||
|
||||
Каждая filter group (пара портов в сторону фильтра) может находиться в одном из двух состояний:
|
||||
|
||||
| Состояние | Описание |
|
||||
| ------------ | ------------------------------------------------------------------- |
|
||||
| **up** | Пара портов активна, трафик отправляется на фильтр |
|
||||
| **bypass** | Пара портов в режиме программного bypass — трафик перекладывается из LAN в WAN и наоборот, не отправляясь на фильтр |
|
||||
|
||||
В нормальном рабочем состоянии **все filter groups** должны находиться в состоянии `up`.
|
||||
|
||||
Переход в `bypass` происходит автоматически при потере заданного количества последовательных keep-alive пакетов (по умолчанию — 5). Обратный переход в `up` также автоматический — при получении достаточного количества ответных keep-alive пакетов.
|
||||
|
||||
### 22.6.2. Time of pass — время прохождения keep-alive пакета
|
||||
|
||||
Внутри каждой filter group отображается параметр **time of pass** — время прохождения keep-alive пакета через фильтр:
|
||||
|
||||
```text
|
||||
Filter Group fg1:
|
||||
Status: up
|
||||
Time of pass: 27000 ns
|
||||
```
|
||||
|
||||
| Параметр | Описание |
|
||||
| ------------------ | ----------------------------------------------------------------- |
|
||||
| **Time of pass** | Время (в наносекундах) между отправкой keep-alive пакета в LAN-порт и получением его из парного WAN-порта |
|
||||
| **Time of receipt**| Внутренний timestamp — привязан к внутреннему счётчику, практической ценности для эксплуатации не имеет |
|
||||
|
||||
Механизм измерения:
|
||||
|
||||
1. Балансировщик отправляет keep-alive пакет в **LAN-порт** filter group;
|
||||
2. Пакет проходит через фильтр (прозрачно, минуя DPI);
|
||||
3. Балансировщик получает пакет из **WAN-порта** той же filter group;
|
||||
4. Фиксируется разница во времени — это и есть **time of pass**.
|
||||
|
||||
В нормальном состоянии time of pass составляет порядка **20–30 микросекунд** (20 000–30 000 наносекунд).
|
||||
|
||||
> **Важно:** балансировщик **ничего не знает** о работе DPI на фильтрах. Keep-alive пакеты проходят через фильтр прозрачно, без обработки движком DPI. Параметр time of pass отражает исключительно время прохождения пакета через аппаратную часть фильтра.
|
||||
|
||||
Если пакеты начинают теряться — time of pass резко возрастает. После потери **5 последовательных** keep-alive пакетов filter group переводится в состояние `bypass`.
|
||||
|
||||
### Влияние загрузки фильтра на keep-alive
|
||||
|
||||
При высокой загрузке таблиц сессий фильтра (значительно выше рекомендованных 20%) фильтр может начать медленнее обрабатывать трафик и **дропать пакеты**, в том числе keep-alive. Это может привести к «флапингу» filter group — циклическому переключению между `up` и `bypass`.
|
||||
|
||||
В такой ситуации оператор **не почувствует флапов** на физических линках (программный bypass не затрагивает физику), но:
|
||||
|
||||
- Небольшое количество пакетов может теряться при каждом переключении;
|
||||
- Часть трафика временно не фильтруется.
|
||||
|
||||
Система мониторинга должна отслеживать загрузку таблиц на фильтрах и сигнализировать о приближении к пороговым значениям **до** того, как начнутся проблемы с keep-alive.
|
||||
|
||||
## 22.7. Программный байпас: индивидуально для каждой группы портов
|
||||
|
||||
Программный bypass на балансировщике может управляться как **автоматически** (по результатам keep-alive), так и **вручную**:
|
||||
|
||||
```text
|
||||
call balance-group <имя_группы> software-bypass <режим>
|
||||
```
|
||||
|
||||
| Режим | Описание |
|
||||
| ------------ | ------------------------------------------------------------------- |
|
||||
| **bypass** | Принудительно перевести группу в режим программного bypass |
|
||||
| **primary** | Вернуть группу в нормальный режим работы (трафик на фильтры) |
|
||||
|
||||
### Индивидуальный bypass для каждой filter group
|
||||
|
||||
Ключевое преимущество программного bypass — его **гранулярность**. Bypass включается **индивидуально для каждой filter group**, а не для всей группы балансировки целиком:
|
||||
|
||||
```text
|
||||
Filter Group fg1: up ← трафик идёт на фильтр
|
||||
Filter Group fg2: bypass ← трафик байпасится (проблема с этой парой портов)
|
||||
Filter Group fg3: up ← трафик идёт на фильтр
|
||||
Filter Group fg4: up ← трафик идёт на фильтр
|
||||
```
|
||||
|
||||
Это означает, что при проблеме с одним интерфейсом фильтра **не фильтруется** только часть трафика, проходящая через данную пару портов. Весь остальной трафик продолжает нормально обрабатываться.
|
||||
|
||||
### Преимущества перед переключением на байпасе
|
||||
|
||||
| Критерий | Bypass на оптическом байпасе | Программный bypass на балансировщике |
|
||||
| -------------------------- | ------------------------------------- | --------------------------------------- |
|
||||
| **Флап линков оператора** | Да — при каждом переключении | **Нет** — физические линки не затрагиваются |
|
||||
| **Гранулярность** | Вся площадка целиком | **Каждая пара портов** индивидуально |
|
||||
| **Согласование с оператором** | Требуется (работы, окна обслуживания) | **Не требуется** — оператор ничего не замечает |
|
||||
| **Последствия** | Весь трафик не фильтруется | Не фильтруется **только часть** трафика |
|
||||
|
||||
> **Опыт эксплуатации:** такое поведение было опробовано при тестировании эшелонированной системы в Сургуте. Вместо переключения трафика на оптическом байпасе (что вызывает флапы линков и недовольство оператора) использовался программный bypass на балансировщике — одной командой трафик уводился с фильтров без каких-либо видимых последствий для оператора.
|
||||
|
||||
### Автоматическое восстановление
|
||||
|
||||
При автоматическом bypass (по результатам keep-alive):
|
||||
|
||||
- Если filter group потеряла keep-alive — автоматически переводится в `bypass`;
|
||||
- Когда интерфейс восстанавливается и keep-alive снова проходят — filter group **автоматически возвращается** в рабочее состояние (`up`);
|
||||
- Перебалансировки трафика **не происходит** (при выключенной перебалансировке) — остальные filter groups продолжают работать без изменений.
|
||||
|
||||
### Проверка Bypass Watchdog (пилотный проект, Урал)
|
||||
|
||||
Для уральского проекта с байпасами GL Sun доступна дополнительная диагностика связи между балансировщиком и байпасом:
|
||||
|
||||
| Состояние | Описание |
|
||||
| ------------- | ---------------------------------------------------------------- |
|
||||
| **active** | Группа балансировки активна, heartbeat-пакеты отправляются на байпас, байпас отвечает |
|
||||
| **disconnected** | Группа балансировки неактивна или связь с байпасом потеряна — heartbeat-пакеты не отправляются |
|
||||
|
||||
Связь с байпасом GL Sun осуществляется по **протоколу TCP**. При переходе группы балансировки в неактивное состояние отправка heartbeat прекращается.
|
||||
|
||||
> **Примечание:** данная диагностика **не актуальна** для федерального проекта с байпасами Silicom, где heartbeat генерируется и проверяется самим байпасом.
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 21: Балансировщик: конфигурация](21.md) · [Раздел 23: Распознавание протоколов (DPI Engine) →](23.md)
|
||||
165
chapters/23.md
Normal file
165
chapters/23.md
Normal file
@@ -0,0 +1,165 @@
|
||||
# 23. Распознавание протоколов (DPI Engine)
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 22: Балансировщик: мониторинг и диагностика](22.md)
|
||||
|
||||
---
|
||||
|
||||
Распознавание протоколов — одна из ключевых функций фильтра ТСПУ. Внутренний движок DPI анализирует проходящие сессии и определяет, к какому протоколу или приложению они относятся: Telegram, WhatsApp, Viber, OpenVPN, BitTorrent и другие. Распознавание особенно важно для **шифрованного трафика**, где нет очевидных полей, указывающих на конкретный протокол, и идентификация выполняется **косвенным образом**.
|
||||
|
||||
## 23.1. Многофакторный анализ сессий
|
||||
|
||||
DPI-движок фильтра анализирует не отдельные пакеты, а **целые сессии**. Для распознавания необходимо, чтобы в рамках одной сессии прошло **несколько пакетов** в обоих направлениях — одного первого пакета недостаточно.
|
||||
|
||||
Анализ проводится по **множеству параметров одновременно** — их может быть десяток и более. Совокупность этих параметров формирует уникальный «профиль» трафика конкретного протокола.
|
||||
|
||||
### 23.1.1. Размеры пакетов и их вариации
|
||||
|
||||
Один из ключевых параметров анализа — **размеры пакетов** в рамках сессии и их **вариации**:
|
||||
|
||||
- Средний размер пакетов;
|
||||
- Разброс размеров (минимальный, максимальный, стандартное отклонение);
|
||||
- Характерные паттерны размеров (например, первые пакеты одного размера, последующие — другого).
|
||||
|
||||
Разные протоколы и приложения генерируют пакеты с **характерными размерными профилями**. Например, голосовой трафик мессенджера будет иметь иной размерный профиль, чем передача файлов через тот же мессенджер.
|
||||
|
||||
### 23.1.2. Частота прохождения пакетов
|
||||
|
||||
**Частота прохождения пакетов** — ещё один важный параметр:
|
||||
|
||||
- Интервалы между пакетами;
|
||||
- Регулярность или нерегулярность этих интервалов;
|
||||
- Всплески активности и паузы.
|
||||
|
||||
Голосовые вызовы, например, генерируют поток пакетов с **регулярными короткими интервалами**, тогда как обмен текстовыми сообщениями создаёт **нерегулярный** трафик с длительными паузами.
|
||||
|
||||
### 23.1.3. Ключевые слова и паттерны внутри пакетов
|
||||
|
||||
DPI-движок также анализирует **содержимое пакетов** — ищет характерные ключевые слова, последовательности байтов и структурные паттерны:
|
||||
|
||||
- Специфичные заголовки и поля протокола;
|
||||
- Характерные байтовые последовательности (сигнатуры);
|
||||
- Структура данных внутри пакета (порядок полей, длины полей).
|
||||
|
||||
Помимо очевидных параметров (source/destination IP, порты), анализируются **менее очевидные** признаки, которые в совокупности позволяют отнести сессию к конкретному протоколу.
|
||||
|
||||
### 23.1.4. Особенности анализа шифрованного трафика
|
||||
|
||||
Шифрованный трафик представляет **особую сложность** для распознавания:
|
||||
|
||||
- Содержимое пакетов зашифровано — нет очевидных полей, указывающих на протокол;
|
||||
- Ключевые слова и сигнатуры **недоступны** для анализа;
|
||||
- Распознавание выполняется **исключительно косвенными методами** — по размерам пакетов, частоте, вариациям и другим статистическим параметрам.
|
||||
|
||||
Для распознавания шифрованных протоколов (например, Telegram) используется **многофакторный анализ** — математическая модель, которая на основе совокупности косвенных признаков делает вывод о принадлежности сессии к конкретному протоколу. Конкретные алгоритмы и математика этого анализа являются внутренней разработкой и в открытом виде не раскрываются.
|
||||
|
||||
> **Принцип работы:** DPI-движок берёт сессию (не один пакет, а несколько пакетов в обоих направлениях), анализирует их по множеству параметров и принимает решение — например, «данный трафик в этой сессии — это Telegram» или «это WhatsApp».
|
||||
|
||||
## 23.2. Ложноположительные срабатывания
|
||||
|
||||
Многофакторный анализ **не является стопроцентным** — возможны **ложноположительные срабатывания** (false positives), когда один шифрованный трафик по тем же косвенным критериям ошибочно распознаётся как другой протокол.
|
||||
|
||||
Причины ложноположительных срабатываний:
|
||||
|
||||
| Причина | Описание |
|
||||
| -------------------------------------- | ----------------------------------------------------------------- |
|
||||
| **Похожие профили трафика** | Разные протоколы могут генерировать трафик с похожими размерами пакетов и частотой |
|
||||
| **Шифрование скрывает различия** | Без доступа к содержимому пакетов анализ опирается на меньше признаков |
|
||||
| **Новые версии протоколов** | Обновления приложений могут изменить профиль трафика, сделав его похожим на другой протокол |
|
||||
|
||||
**Последствия ложного срабатывания:** если фильтр ошибочно распознал легитимный трафик как блокируемый протокол и сразу заблокировал его — пользователь потеряет доступ к полезному ресурсу. Именно поэтому прямая блокировка по результатам DPI на фильтре **не применяется** для протоколов — вместо этого используется двухстадийная схема.
|
||||
|
||||
## 23.3. Двухстадийная блокировка: распознавание → очистка в ЦСУ → блокировка
|
||||
|
||||
Для минимизации ложноположительных срабатываний блокировка протоколов выполняется **в два этапа** (подробная схема — в [разделе 8](08.md)):
|
||||
|
||||
```text
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ Этап 1: Распознавание (фильтр) │
|
||||
│ │
|
||||
│ • DPI-движок анализирует сессию │
|
||||
│ • Определяет протокол (Telegram, WhatsApp, ...) │
|
||||
│ • Результат записывается в лог │
|
||||
│ • Трафик НЕ БЛОКИРУЕТСЯ (behavior: ignore) │
|
||||
│ • Логи отправляются на SPFS → ЦСУ │
|
||||
└──────────────────────────┬──────────────────────────────────────┘
|
||||
│
|
||||
▼
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ Очистка (ЦСУ) │
|
||||
│ │
|
||||
│ • Сбор логов со ВСЕХ площадок (~350 площадок, ~5000 устройств)│
|
||||
│ • Сопоставление сессий с разных фильтров │
|
||||
│ • Глубокий статистический анализ │
|
||||
│ • Обогащение данных сторонней информацией │
|
||||
│ • Формирование очищенных списков (IP + порт) │
|
||||
│ • Вероятность ложного срабатывания — крайне низка │
|
||||
└──────────────────────────┬──────────────────────────────────────┘
|
||||
│
|
||||
▼
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ Этап 2: Блокировка (фильтр / Eco Highway) │
|
||||
│ │
|
||||
│ • Очищенные списки загружаются на фильтры (HTTP) │
|
||||
│ и на Eco Highway (BGP) │
|
||||
│ • Загрузка в ОТДЕЛЬНЫЙ DPI-лист (не тот, где распознавание) │
|
||||
│ • На этом DPI-листе: behavior: block │
|
||||
│ • Блокировка по проверенным адресам │
|
||||
└─────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### Разделение DPI-листов
|
||||
|
||||
На одном фильтре **одновременно работают два процесса**:
|
||||
|
||||
| DPI-лист | Behavior | Назначение |
|
||||
| --------------------- | ----------- | --------------------------------------------------- |
|
||||
| DPI-лист 0 | **ignore** | Распознавание протоколов, запись логов, без блокировки |
|
||||
| DPI-лист 5 (пример) | **block** | Блокировка по очищенным спискам из ЦСУ |
|
||||
|
||||
Таким образом, распознавание и блокировка выполняются **в разных DPI-листах** — это позволяет независимо управлять каждым процессом.
|
||||
|
||||
### Преимущества централизованного анализа
|
||||
|
||||
ЦСУ видит данные **со всех фильтров на всех площадках**, а не только с одного конкретного устройства. Это даёт принципиально **более полную картину**:
|
||||
|
||||
- Один фильтр видит только «свои» сессии — ЦСУ видит **все сессии** по всей стране;
|
||||
- Статистический анализ на большой выборке **значительно точнее**;
|
||||
- Возможность обогащения данных **сторонней информацией** повышает качество распознавания.
|
||||
|
||||
### Время полного цикла
|
||||
|
||||
От момента появления нового, ранее неизвестного сервера блокируемого протокола до его фактической блокировки проходит **от 5 до 15 минут** (подробнее — в [разделе 8.6](08.md)).
|
||||
|
||||
## 23.4. Обфускация и борьба с обходом блокировок
|
||||
|
||||
Обфускация — это намеренное изменение характеристик протокола, направленное на то, чтобы DPI-движок **не смог его распознать**. Это постоянная «гонка вооружений» между разработчиками средств обхода блокировок и разработчиками систем фильтрации.
|
||||
|
||||
### Принцип «ананасных мальчиков»
|
||||
|
||||
Борьба между системами обхода и системами блокировки описывается как **постоянное противостояние**: одна сторона в какой-то момент имеет преимущество, которое затем нивелируется следующим шагом противоположной стороны.
|
||||
|
||||
### Типы обфускации и возможности распознавания
|
||||
|
||||
| Тип обфускации | Возможность распознавания |
|
||||
| ------------------------------------- | ------------------------------------------------------- |
|
||||
| **Простая** (например, XOR) | Фильтр может «развернуть» обфускацию и распознать протокол |
|
||||
| **Протокол притворяется другим** | Распознавание возможно, но требует разработки новых сигнатур и методик |
|
||||
| **Качественная имитация другого протокола** | Распознать **невозможно** без разработки принципиально нового подхода |
|
||||
|
||||
### Обновление сигнатур
|
||||
|
||||
Когда обнаруживается, что новая версия приложения или протокола **перестала распознаваться** фильтром, это означает необходимость:
|
||||
|
||||
1. **Анализа изменений** — что именно изменилось в новой версии протокола;
|
||||
2. **Разработки новой сигнатуры** — обновление правил распознавания для учёта изменений;
|
||||
3. **Обновления прошивки** — доставка обновлённого DPI-движка на фильтры.
|
||||
|
||||
> **Практический подход:** к этому процессу следует относиться с пониманием — это нормальная и ожидаемая ситуация. Полное и постоянное распознавание всех протоколов **невозможно** в принципе. Задача системы — поддерживать актуальные сигнатуры и оперативно реагировать на изменения.
|
||||
|
||||
### Защита от ложных блокировок при борьбе с обфускацией
|
||||
|
||||
Двухстадийная система блокировки (раздел 23.3) особенно важна в контексте борьбы с обфускацией. Обфусцированный трафик **по определению** имеет нестандартный профиль, что повышает вероятность ложноположительного срабатывания. Централизованная очистка на ЦСУ снижает этот риск, сопоставляя данные с множества источников.
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 22: Балансировщик: мониторинг и диагностика](22.md) · [Раздел 24: Траблшутинг →](24.md)
|
||||
306
chapters/24.md
Normal file
306
chapters/24.md
Normal file
@@ -0,0 +1,306 @@
|
||||
# 24. Траблшутинг
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 23: Распознавание протоколов (DPI Engine)](23.md)
|
||||
|
||||
---
|
||||
|
||||
Диагностика проблем на ТСПУ — комплексная задача, требующая понимания архитектуры системы, принципов прохождения трафика и взаимодействия компонентов. В данном разделе описаны типовые подходы к траблшутингу, которые применяются при обращениях операторов связи и абонентов.
|
||||
|
||||
## 24.1. Общий подход к диагностике проблем доступности
|
||||
|
||||
При обращении оператора или абонента с жалобой на недоступность ресурса необходимо последовательно пройти несколько шагов:
|
||||
|
||||
```text
|
||||
1. Уточнить детали проблемы
|
||||
│
|
||||
2. Определить, есть ли проблема прямо сейчас (или была вчера)
|
||||
│
|
||||
3. Найти сессии абонента на фильтрах
|
||||
│
|
||||
4. Проверить ресурс в DPI-листах
|
||||
│
|
||||
5. Исключить ТСПУ как причину (bypass / No IP)
|
||||
│
|
||||
6. Локализовать проблему
|
||||
```
|
||||
|
||||
### Шаг 1: Уточнение деталей
|
||||
|
||||
Всегда необходимо **выяснять подробности** у абонента или оператора. Формулировка «ресурс недоступен» может означать совершенно разные вещи:
|
||||
|
||||
| Жалоба абонента | Что это может означать на самом деле |
|
||||
| ---------------------------- | --------------------------------------------------------- |
|
||||
| «Сайт не открывается» | Полная блокировка, ошибка DNS, проблема на стороне сервера |
|
||||
| «Всё тормозит» | Деградация протокола, перегрузка канала, проблема на стороне оператора |
|
||||
| «Часть сайта не работает» | Блокировка отдельных ресурсов (CDN, API), проблема с HTTPS |
|
||||
| «Приложение не подключается»| Блокировка протокола, обновление приложения, проблема с обфускацией |
|
||||
|
||||
> **Статистика:** по опыту эксплуатации, примерно в **80% случаев** проблема связана **не с ТСПУ**, а с самим ресурсом, абонентом или оператором связи. Однако всегда необходимо проверять и исключать влияние ТСПУ.
|
||||
|
||||
### Шаг 2: Актуальность проблемы
|
||||
|
||||
**Диагностика постфактум крайне затруднена.** Если абонент сообщает о проблеме, которая была вчера, а сегодня её нет, — возможности анализа ограничены:
|
||||
|
||||
- Если сохранились **логи соединений** за нужный период — можно проанализировать, были ли сессии к проблемному ресурсу;
|
||||
- Если логов нет — восстановить картину практически невозможно.
|
||||
|
||||
**Если проблема существует прямо сейчас** — шансы на успешную диагностику значительно выше. В этом случае важно работать **в реальном времени** совместно с абонентом или оператором.
|
||||
|
||||
## 24.2. Поиск сессии абонента: обход фильтров площадки
|
||||
|
||||
Первый практический шаг — **найти сессии** конкретного абонента к конкретному ресурсу на фильтрах площадки.
|
||||
|
||||
### Поиск по локальному адресу
|
||||
|
||||
Для поиска сессий используется команда `show session` с фильтрацией по локальному адресу абонента:
|
||||
|
||||
```text
|
||||
> show session la <IP-адрес_абонента>:<порт> | more
|
||||
```
|
||||
|
||||
Или для просмотра всех сессий абонента:
|
||||
|
||||
```text
|
||||
> show session la <IP-адрес_абонента> | more
|
||||
```
|
||||
|
||||
Для подсчёта количества сессий:
|
||||
|
||||
```text
|
||||
> show session la <IP-адрес_абонента> | count
|
||||
```
|
||||
|
||||
### Поиск по удалённому адресу
|
||||
|
||||
Если известен IP-адрес ресурса, к которому обращается абонент:
|
||||
|
||||
```text
|
||||
> show session ra <IP-адрес_ресурса> | more
|
||||
```
|
||||
|
||||
### Интерпретация результатов
|
||||
|
||||
| Результат | Интерпретация |
|
||||
| -------------------------------------- | ---------------------------------------------------------- |
|
||||
| Сессии **найдены** | Трафик абонента проходит через фильтр — ТСПУ его видит |
|
||||
| Сессии **не найдены** | Трафик не проходит через данный фильтр — абонент идёт другим путём, либо проблема до ТСПУ |
|
||||
| Сессии есть, но ресурс недоступен | Возможна блокировка на уровне DPI — проверить DPI-листы |
|
||||
|
||||
> **Важно:** при поиске сессий помните принцип «локальный адрес всегда на первом месте» (см. [раздел 12](12.md)). Независимо от направления трафика, IP-адрес абонента записывается в поле local. Если в поле local отображаются адреса, которые не являются абонентскими (интернет-адреса), — это признак перепутки LAN/WAN (см. раздел 24.6).
|
||||
|
||||
### Особенности при установке после CGNAT
|
||||
|
||||
Если ТСПУ установлен **после CGNAT** (см. [раздел 6.3](06.md)), на фильтре видны только белые (транслированные) адреса. Для идентификации конкретного абонента необходимо **взаимодействие с оператором** — оператор должен сообщить, в какие порты и IP-адреса абонент был транслирован.
|
||||
|
||||
## 24.3. Проверка ресурса в DPI-листах: `show dpi match`
|
||||
|
||||
Команда `show dpi match` позволяет проверить, находится ли конкретный ресурс в списках блокировки:
|
||||
|
||||
```text
|
||||
# show dpi match <ресурс>
|
||||
```
|
||||
|
||||
Где `<ресурс>` — это IP-адрес или URL.
|
||||
|
||||
Команда проверяет указанный ресурс **по всем DPI-листам** и выводит информацию о совпадениях:
|
||||
|
||||
| Результат | Значение |
|
||||
| ---------------------------------- | ------------------------------------------------------------ |
|
||||
| Совпадение найдено в DPI-листе N | Ресурс присутствует в списке — указано, в каком именно DPI-листе и какое действие (block/ignore/redirect) |
|
||||
| Совпадений не найдено | Ресурс отсутствует во всех DPI-листах — ТСПУ его не блокирует по спискам |
|
||||
|
||||
> **Примечание:** команда `show dpi match` может быть недоступна в старых версиях прошивки. В актуальных прошивках федерального проекта она присутствует.
|
||||
|
||||
### Проверка через ЦСУ
|
||||
|
||||
Если необходимо проверить наличие ресурса в списках, загруженных на **Eco Highway** (эшелонированная система), проверку следует выполнять **через центральную систему управления** — там хранятся все списки, загружаемые по BGP.
|
||||
|
||||
## 24.4. Программный байпас для исключения ТСПУ как причины проблемы
|
||||
|
||||
Один из ключевых методов диагностики — **исключение ТСПУ** из пути прохождения трафика, чтобы определить, является ли ТСПУ причиной проблемы.
|
||||
|
||||
### Программный bypass на балансировщике
|
||||
|
||||
Наиболее удобный способ — программный bypass на балансировщике (см. [раздел 22.7](22.md)):
|
||||
|
||||
```text
|
||||
call balance-group <группа> software-bypass bypass
|
||||
```
|
||||
|
||||
Преимущества:
|
||||
|
||||
- **Нет флапов линков** — оператор ничего не замечает;
|
||||
- **Гранулярность** — можно байпасить отдельные filter groups;
|
||||
- **Мгновенность** — переключение происходит немедленно.
|
||||
|
||||
### Bypass по правилам фильтрации (flow rules)
|
||||
|
||||
Альтернативный вариант — создать на балансировщике **временное правило** с action `bypass` для конкретного трафика:
|
||||
|
||||
```text
|
||||
set filters main flows diag-bypass match vlan 0 id <номер_VLAN>
|
||||
set filters main flows diag-bypass action bypass
|
||||
set filters main flows diag-bypass priority 200
|
||||
apply
|
||||
```
|
||||
|
||||
Это позволяет исключить из обработки только **конкретный VLAN** или подсеть, не затрагивая остальной трафик. По статистике правила (пакеты/байты) можно убедиться, что трафик действительно проходит (см. [раздел 22.5](22.md)).
|
||||
|
||||
### Bypass на оптическом байпасе
|
||||
|
||||
Переключение оптического байпаса в режим bypass/TAP — более радикальный метод, который **вызывает флапы линков** у оператора. Используется в крайнем случае и, как правило, требует согласования с оператором.
|
||||
|
||||
### Интерпретация результатов
|
||||
|
||||
| После bypass | Интерпретация |
|
||||
| -------------------------------- | ------------------------------------------------------------ |
|
||||
| Проблема **исчезла** | ТСПУ являлось причиной — диагностировать дальше на уровне фильтров/DPI |
|
||||
| Проблема **осталась** | ТСПУ не является причиной — проблема на стороне ресурса, оператора или абонента |
|
||||
|
||||
## 24.5. Исключение абонента из обработки: параметр No IP
|
||||
|
||||
Для точечной диагностики на уровне **конкретного абонента** используется параметр **No IP** в настройках DPI-листа (см. [раздел 17.4.8](17.md)).
|
||||
|
||||
### No IP (исключение по локальному адресу)
|
||||
|
||||
Параметр `No IP` исключает **локальный адрес абонента** из обработки конкретным DPI-листом:
|
||||
|
||||
```text
|
||||
# system dpi lists <N> no-ip <IP-адрес_абонента>
|
||||
# apply
|
||||
```
|
||||
|
||||
Это означает, что трафик данного абонента будет проходить через фильтр, но **конкретный DPI-лист** не будет его обрабатывать.
|
||||
|
||||
### No IP Remote (исключение по удалённому адресу)
|
||||
|
||||
Параметр `No IP Remote` исключает **удалённый IP-адрес** (адрес сервера/ресурса) из обработки:
|
||||
|
||||
```text
|
||||
# system dpi lists <N> no-ip-remote <IP-адрес_ресурса>
|
||||
# apply
|
||||
```
|
||||
|
||||
### Диагностический алгоритм
|
||||
|
||||
```text
|
||||
1. Добавить абонента в No IP конкретного DPI-листа
|
||||
│
|
||||
2. Применить конфигурацию (apply)
|
||||
│
|
||||
3. Попросить абонента повторить действие
|
||||
│
|
||||
┌──────┴──────┐
|
||||
│ │
|
||||
▼ ▼
|
||||
Проблема Проблема
|
||||
исчезла осталась
|
||||
│ │
|
||||
▼ ▼
|
||||
Данный Данный DPI-лист
|
||||
DPI-лист НЕ влияет на
|
||||
ВЛИЯЕТ на абонента —
|
||||
абонента проверить
|
||||
другие листы
|
||||
```
|
||||
|
||||
> **Приоритет:** параметр `No IP` имеет **приоритет** над параметром `IP`. Если адрес указан и в No IP (исключение), и в IP (включение), сработает **исключение** — адрес не будет обрабатываться.
|
||||
|
||||
### Возврат после диагностики
|
||||
|
||||
После завершения диагностики необходимо **удалить** добавленные записи No IP и применить конфигурацию.
|
||||
|
||||
## 24.6. Перепутки LAN/WAN и их диагностика
|
||||
|
||||
**Перепутка LAN/WAN** — ситуация, когда порты LAN и WAN подключены **наоборот**: LAN-порт подключён в сторону интернета, а WAN-порт — в сторону абонентов.
|
||||
|
||||
### Как распознать перепутку
|
||||
|
||||
Основной признак — при просмотре сессий на фильтре в поле **local** отображаются адреса, которые **не являются абонентскими**:
|
||||
|
||||
- Вместо серых (приватных) абонентских адресов в local видны белые интернет-адреса;
|
||||
- Направление сессий (Egress/Ingress) не соответствует ожидаемому.
|
||||
|
||||
Это происходит потому, что фильтр определяет направление трафика по портам: трафик, приходящий в LAN-порт, считается абонентским, а source IP записывается как local. Если LAN и WAN перепутаны, source IP интернет-хоста ошибочно записывается как local.
|
||||
|
||||
> **Ключевой принцип:** локальный (абонентский) IP-адрес **всегда записывается на первое место** в сессии (см. [раздел 12.5](12.md)). Если на первом месте оказался интернет-адрес — порты перепутаны.
|
||||
|
||||
### Где может произойти перепутка
|
||||
|
||||
| Место | Описание |
|
||||
| ------------------------------ | ----------------------------------------------------------- |
|
||||
| **На байпасе** | Кабели LAN и WAN подключены к неправильным портам байпаса |
|
||||
| **На балансировщике** | Порты в линке назначены неверно (LAN вместо WAN и наоборот) |
|
||||
| **На коммутаторе оператора** | Кабели между оператором и байпасом подключены неверно |
|
||||
|
||||
### Последствия перепутки
|
||||
|
||||
При перепутке LAN/WAN:
|
||||
|
||||
- Фильтр **некорректно определяет направление** трафика;
|
||||
- DPI-обработка может работать **неправильно** (блокировка не того, что нужно);
|
||||
- Сессии и трансляции формируются **неверно**;
|
||||
- Connection logging записывает **некорректные данные**.
|
||||
|
||||
### Диагностика
|
||||
|
||||
1. Выполнить `show session` и проверить поле local — должны быть абонентские (серые) адреса;
|
||||
2. Если в local видны белые адреса — вероятна перепутка;
|
||||
3. Проверить физическое подключение кабелей;
|
||||
4. Проверить конфигурацию линков на балансировщике.
|
||||
|
||||
## 24.7. Взаимодействие с оператором связи
|
||||
|
||||
Эффективная диагностика часто требует **совместной работы** с оператором связи и конечным абонентом:
|
||||
|
||||
### Когда необходимо взаимодействие
|
||||
|
||||
| Ситуация | Что нужно от оператора/абонента |
|
||||
| ------------------------------------------ | -------------------------------------------------------- |
|
||||
| Проблема существует **прямо сейчас** | Абонент генерирует трафик, а инженер ТСПУ анализирует сессии в реальном времени |
|
||||
| ТСПУ установлен **после CGNAT** | Оператор сообщает транслированные адреса для поиска сессий |
|
||||
| Проблема с **конкретным ресурсом** | Абонент уточняет URL, IP-адрес, порт, тип приложения |
|
||||
| Подозрение на проблему **на стороне оператора** | Оператор проверяет свою часть сети (маршрутизация, CGNAT, BRAS) |
|
||||
|
||||
### Рекомендации по взаимодействию
|
||||
|
||||
**С корпоративными клиентами:** как правило, корпоративные клиенты заинтересованы в решении проблемы и готовы к сотрудничеству — совместному моделированию ситуации в реальном времени. Это наиболее эффективный сценарий диагностики.
|
||||
|
||||
**С частными абонентами:** частный абонент, столкнувшийся с проблемой, может просто уйти и не возвращаться к ресурсу. Диагностика постфактум без сохранённых логов практически невозможна.
|
||||
|
||||
**С оператором:** при переключениях bypass/primary необходимо **согласовывать работы** с оператором, так как переключение оптического байпаса вызывает флапы линков. Программный bypass на балансировщике не требует такого согласования.
|
||||
|
||||
## 24.8. Ограничения: L2-устройство, невозможность генерации трафика с фильтра
|
||||
|
||||
Фильтр ТСПУ — это устройство **уровня L2** (Layer 2). Это накладывает принципиальные ограничения на возможности диагностики:
|
||||
|
||||
### Невозможность генерации трафика
|
||||
|
||||
На фильтре **нет IP-интерфейсов** в data plane, с которых можно было бы инициировать трафик. Это означает:
|
||||
|
||||
- **Невозможно** отправить тестовый пакет «от имени абонента» через фильтр;
|
||||
- **Невозможно** «скрафтить» пакет с заданными source/destination и пропустить его через DPI;
|
||||
- **Невозможно** повторить ситуацию абонента изнутри фильтра.
|
||||
|
||||
> **Ping и traceroute** доступны на фильтре, но они работают через **management-интерфейс**, а не через data plane. Ping позволяет проверить связь management-интерфейса со шлюзом или с внешними хостами (если есть маршрутизация), но **не моделирует** прохождение абонентского трафика через фильтр.
|
||||
|
||||
### Невозможность перехвата трафика
|
||||
|
||||
Фильтр не может захватить копию трафика (аналог tcpdump) — он только обрабатывает пакеты, проходящие через него, и предоставляет **агрегированную статистику** (сессии, счётчики, DPI-состояние).
|
||||
|
||||
### Практические следствия
|
||||
|
||||
| Что **можно** сделать | Что **нельзя** сделать |
|
||||
| -------------------------------------------- | ---------------------------------------------------- |
|
||||
| Найти сессии абонента (`show session`) | Сгенерировать тестовый трафик через data plane |
|
||||
| Проверить ресурс в DPI-листах (`show dpi match`) | Захватить дамп трафика (tcpdump) |
|
||||
| Исключить абонента из обработки (No IP) | Повторить проблему абонента изнутри фильтра |
|
||||
| Включить программный bypass | Инициировать соединение к ресурсу через фильтр |
|
||||
| Посмотреть статистику и счётчики | Проанализировать содержимое конкретного пакета |
|
||||
| Ping/traceroute через management-интерфейс | Ping/traceroute через data plane |
|
||||
|
||||
Именно поэтому для эффективной диагностики часто необходимо **совместное моделирование** ситуации в реальном времени: абонент генерирует трафик, а инженер ТСПУ анализирует, как этот трафик проходит через систему.
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](../README.md) · [← Раздел 23: Распознавание протоколов (DPI Engine)](23.md)
|
||||
Reference in New Issue
Block a user