From f1d391ccf3da3a8495dfeb3772a7070212408425 Mon Sep 17 00:00:00 2001 From: Daniel Lavrushin Date: Fri, 20 Feb 2026 13:48:19 +0100 Subject: [PATCH] =?UTF-8?q?=D0=94=D0=BE=D0=B1=D0=B0=D0=B2=D0=BB=D0=B5?= =?UTF-8?q?=D0=BD=D1=8B=20=D1=80=D0=B0=D0=B7=D0=B4=D0=B5=D0=BB=D1=8B=2019,?= =?UTF-8?q?=2020=20=D0=B8=2021:=20=D0=BE=D0=B1=D0=BD=D0=BE=D0=B2=D0=BB?= =?UTF-8?q?=D0=B5=D0=BD=D0=B8=D0=B5=20=D0=BF=D1=80=D0=BE=D1=88=D0=B8=D0=B2?= =?UTF-8?q?=D0=BA=D0=B8=20=D1=84=D0=B8=D0=BB=D1=8C=D1=82=D1=80=D0=B0,=20?= =?UTF-8?q?=D0=B0=D0=BF=D0=BF=D0=B0=D1=80=D0=B0=D1=82=D0=BD=D0=B0=D1=8F=20?= =?UTF-8?q?=D0=BF=D0=BB=D0=B0=D1=82=D1=84=D0=BE=D1=80=D0=BC=D0=B0=20=D0=B1?= =?UTF-8?q?=D0=B0=D0=BB=D0=B0=D0=BD=D1=81=D0=B8=D1=80=D0=BE=D0=B2=D1=89?= =?UTF-8?q?=D0=B8=D0=BA=D0=B0=20=D0=B8=20=D0=B5=D0=B3=D0=BE=20=D0=BA=D0=BE?= =?UTF-8?q?=D0=BD=D1=84=D0=B8=D0=B3=D1=83=D1=80=D0=B0=D1=86=D0=B8=D1=8F.?= =?UTF-8?q?=20=D0=92=D0=BA=D0=BB=D1=8E=D1=87=D0=B5=D0=BD=D1=8B=20=D0=BA?= =?UTF-8?q?=D0=BE=D0=BC=D0=B0=D0=BD=D0=B4=D1=8B=20=D0=B4=D0=BB=D1=8F=20?= =?UTF-8?q?=D1=83=D0=BF=D1=80=D0=B0=D0=B2=D0=BB=D0=B5=D0=BD=D0=B8=D1=8F=20?= =?UTF-8?q?=D0=BF=D1=80=D0=BE=D1=88=D0=B8=D0=B2=D0=BA=D0=B0=D0=BC=D0=B8,?= =?UTF-8?q?=20=D0=BD=D0=B0=D1=81=D1=82=D1=80=D0=BE=D0=B9=D0=BA=D0=B8=20?= =?UTF-8?q?=D0=BF=D0=BE=D1=80=D1=82=D0=BE=D0=B2,=20=D0=BB=D0=B8=D0=BD?= =?UTF-8?q?=D0=BA=D0=BE=D0=B2=20=D0=B8=20=D1=84=D0=B8=D0=BB=D1=8C=D1=82?= =?UTF-8?q?=D1=80=D0=BE=D0=B2,=20=D0=B0=20=D1=82=D0=B0=D0=BA=D0=B6=D0=B5?= =?UTF-8?q?=20=D0=BE=D0=BF=D0=B8=D1=81=D0=B0=D0=BD=D0=B8=D0=B5=20=D0=B2?= =?UTF-8?q?=D0=BD=D1=83=D1=82=D1=80=D0=B5=D0=BD=D0=BD=D0=B5=D0=B9=20=D0=B0?= =?UTF-8?q?=D1=80=D1=85=D0=B8=D1=82=D0=B5=D0=BA=D1=82=D1=83=D1=80=D1=8B=20?= =?UTF-8?q?=D0=B8=20=D0=BF=D1=80=D0=B8=D0=BD=D1=86=D0=B8=D0=BF=D0=BE=D0=B2?= =?UTF-8?q?=20=D1=80=D0=B0=D0=B1=D0=BE=D1=82=D1=8B=20=D0=B1=D0=B0=D0=BB?= =?UTF-8?q?=D0=B0=D0=BD=D1=81=D0=B8=D1=80=D0=BE=D0=B2=D1=89=D0=B8=D0=BA?= =?UTF-8?q?=D0=B0.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- 10.md | 90 ++++++++++ 11.md | 140 ++++++++++++++++ 12.md | 191 +++++++++++++++++++++ 13.md | 178 ++++++++++++++++++++ 14.md | 232 ++++++++++++++++++++++++++ 15.md | 123 ++++++++++++++ 16.md | 198 ++++++++++++++++++++++ 17.md | 310 ++++++++++++++++++++++++++++++++++ 18.md | 326 ++++++++++++++++++++++++++++++++++++ 19.md | 120 ++++++++++++++ 20.md | 175 ++++++++++++++++++++ 21.md | 486 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ README.md | 24 +-- 13 files changed, 2581 insertions(+), 12 deletions(-) create mode 100644 10.md create mode 100644 11.md create mode 100644 12.md create mode 100644 13.md create mode 100644 14.md create mode 100644 15.md create mode 100644 16.md create mode 100644 17.md create mode 100644 18.md create mode 100644 19.md create mode 100644 20.md create mode 100644 21.md diff --git a/10.md b/10.md new file mode 100644 index 0000000..832f131 --- /dev/null +++ b/10.md @@ -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) diff --git a/11.md b/11.md new file mode 100644 index 0000000..fdc5196 --- /dev/null +++ b/11.md @@ -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) diff --git a/12.md b/12.md new file mode 100644 index 0000000..c409279 --- /dev/null +++ b/12.md @@ -0,0 +1,191 @@ +# 12. Сессии и трансляции на фильтре + +[← Оглавление](README.md) · [← Раздел 11: Фильтр: аппаратная платформа](11.md) + +--- + +## 12.1. Понятие сессии: local IP:port + global IP:port + remote IP:port + +Вся обработка трафика на фильтре построена на понятии **сессии**. Сессия — это запись, описывающая конкретное соединение между абонентом и удалённым ресурсом. Каждая сессия содержит следующие поля: + +```text + <направление> <протокол> : : : <время> <тайм-аут> +``` + +| Поле | Описание | +| ----------------- | ----------------------------------------------------------- | +| **Направление** | 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 + : ↔ : +``` + +В отличие от сессии, трансляция **не содержит** 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@ "show session local 10.0.0.1" +``` + +Соединение с фильтром устанавливается, команда выполняется, результат возвращается на терминал. Дальнейшая обработка выполняется средствами операционной системы (bash-скрипты, grep и т.д.). Внутренние pipe-операторы фильтра при удалённом вызове через SSH могут **не работать** — в этом случае следует использовать внешние средства обработки вывода. + +--- + +[← Оглавление](README.md) · [← Раздел 11: Фильтр: аппаратная платформа](11.md) · [Раздел 13: Фильтр: первоначальная настройка и CLI →](13.md) diff --git a/13.md b/13.md new file mode 100644 index 0000000..3205983 --- /dev/null +++ b/13.md @@ -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 | +| `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) diff --git a/14.md b/14.md new file mode 100644 index 0000000..e6f377e --- /dev/null +++ b/14.md @@ -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 secret 0 <пароль>` | Создать пользователя (пароль в открытом виде) | +| `create user <имя> level 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) diff --git a/15.md b/15.md new file mode 100644 index 0000000..a15c5d8 --- /dev/null +++ b/15.md @@ -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) diff --git a/16.md b/16.md new file mode 100644 index 0000000..79d3569 --- /dev/null +++ b/16.md @@ -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 <протокол> [vlan |] +``` + +Структура правила: + +| Элемент | Описание | Примеры | +| ---------------- | ---------------------------------------------------------------- | ------------------------------ | +| **Номер** | Порядковый номер правила (рекомендуется с зазором: 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) diff --git a/17.md b/17.md new file mode 100644 index 0000000..2a89db5 --- /dev/null +++ b/17.md @@ -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 + 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) diff --git a/18.md b/18.md new file mode 100644 index 0000000..8a86fc3 --- /dev/null +++ b/18.md @@ -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 ` — содержимое DPI-листа + +Команда `show dpi records ` выводит **содержимое** загруженного 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 ` — ручная загрузка списка + +Команда `dpi load ` принудительно загружает 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) diff --git a/19.md b/19.md new file mode 100644 index 0000000..3c4eb44 --- /dev/null +++ b/19.md @@ -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 на устройство. + +### Этап 2: Установка + +```text + firmware install +``` + +Команда устанавливает скачанный образ на **неактивный раздел** (тот, который сейчас не используется). После установки значение **boot** автоматически переключается на раздел с новой прошивкой. + +**Важные ограничения:** + +- Установка выполняется быстро (~5 секунд), но в этот момент фильтр может **не реагировать** на команды в CLI; +- После установки, пока устройство не перезагружено, **повторная установка невозможна** — для установки новой прошивки значения cur и boot должны совпадать; +- Для применения новой прошивки необходима **перезагрузка** устройства (из конфигурационного режима, с подтверждением). + +### Полная последовательность обновления + +```text + # 1. Проверить текущее состояние + firmware status + + # 2. Скачать новую прошивку + firmware download + + # 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) diff --git a/20.md b/20.md new file mode 100644 index 0000000..efff6f2 --- /dev/null +++ b/20.md @@ -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) diff --git a/21.md b/21.md new file mode 100644 index 0000000..0952f9f --- /dev/null +++ b/21.md @@ -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 и сохраняет его на устройстве под указанным именем. + +### Этап 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 + set management mask <маска_подсети> + set management default-gateway +``` + +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) diff --git a/README.md b/README.md index c2c12f3..e4637bb 100644 --- a/README.md +++ b/README.md @@ -114,14 +114,14 @@ - 9.4. Подсистемы ЦСУ: формирование списков, мониторинг, логирование, картография - 9.5. Новая ЦСУ для федерального проекта (замена уральской) -### 10. Сегмент управления ТСПУ +### [10. Сегмент управления ТСПУ](/10.md) - 10.1. Адресация: 10.<регион>.<площадка>.0/24 - 10.2. Распределение адресов: байпасы, балансировщики, BMC, фильтры, IPMI, SPFS, СПХД - 10.3. Шлюз по умолчанию — криптошлюз «Континент» - 10.4. Подсеть логирования (единая для всех ТСПУ) -### 11. Фильтр: аппаратная платформа +### [11. Фильтр: аппаратная платформа](/11.md) - 11.1. Младшая линейка: EcoFilter 2020/2040 - 11.2. Старшая линейка: EcoFilter 4080/4120/4160 @@ -134,7 +134,7 @@ - 11.5. Разделение интерфейсов: LAN (чётные) / WAN (нечётные) - 11.6. История платформы: от CGNAT (2013) к DPI-фильтру -### 12. Сессии и трансляции на фильтре +### [12. Сессии и трансляции на фильтре](/12.md) - 12.1. Понятие сессии: local IP:port + global IP:port + remote IP:port - 12.2. Понятие трансляции: local IP:port ↔ global IP:port @@ -145,7 +145,7 @@ - 12.7. Тайм-ауты сессий и трансляций - 12.8. Команды: `show session`, `show xl`, фильтрация по `local`/`remote`, pipe и count -### 13. Фильтр: первоначальная настройка и CLI +### [13. Фильтр: первоначальная настройка и CLI](/13.md) - 13.1. Подключение: консоль (115200 8N1) и SSH (порт 22) - 13.2. Логин по умолчанию: admin / econat @@ -159,7 +159,7 @@ - 13.8. «Мышеловка» (trap mode) при незакрытой скобке - 13.9. Ключевое слово `ls` для быстрого просмотра -### 14. Фильтр: конфигурация подсистем +### [14. Фильтр: конфигурация подсистем](/14.md) - 14.1. Консольный порт: скорость, тайм-аут неактивности - 14.2. Management-интерфейс: IP, gateway, DNS, allowed IP @@ -181,7 +181,7 @@ - 14.10.1. Выбор протоколов (all / конкретные) - 14.10.2. Количество пакетов на протокол (по умолчанию 30, рекомендуется 3) -### 15. Фильтр: настройка интерфейсов и общих параметров +### [15. Фильтр: настройка интерфейсов и общих параметров](/15.md) - 15.1. Интерфейсы: enable/disable, description (LACP не используется) - 15.2. NAT Defaults — общие параметры устройства @@ -194,7 +194,7 @@ - 15.3. Тайм-ауты сессий и трансляций - 15.4. IPv6: включение, диапазон адресов для обработки -### 16. Фильтр: ACL и пулы — запуск трафика на обработку +### [16. Фильтр: ACL и пулы — запуск трафика на обработку](/16.md) - 16.1. Создание ACL: `create acl`, правила (allow/deny), протоколы, source/destination, VLAN - 16.2. Создание пула: `create pool`, тип = fake (без NAT) @@ -203,7 +203,7 @@ - 16.5. Connection logging в пуле - 16.6. IPv6 в пуле -### 17. Фильтр: настройка DPI +### [17. Фильтр: настройка DPI](/17.md) - 17.1. Общие настройки модуля DPI - 17.1.1. Включение/выключение DPI @@ -235,7 +235,7 @@ - 17.5.2. HTTP: блокировка конкретного URL - 17.5.3. HTTPS: блокировка только по домену (SNI/Client Hello) -### 18. Фильтр: мониторинг и диагностика +### [18. Фильтр: мониторинг и диагностика](/18.md) - 18.1. `show version` — версия ПО, серийный номер (= MAC management) - 18.2. `show ip if` — параметры management-интерфейса @@ -263,7 +263,7 @@ - 18.13.5. `show dpi match <ресурс>` — проверка ресурса по всем DPI-листам - 18.14. Ping и Traceroute (из конфигурационного режима) -### 19. Фильтр: обновление прошивки +### [19. Фильтр: обновление прошивки](/19.md) - 19.1. Два раздела: prim1 и prim2 (равнозначные) + FB (заводская) - 19.2. `firmware status` — текущее состояние (cur / boot) @@ -271,7 +271,7 @@ - 19.4. `firmware rollback` / `firmware reset` - 19.5. Централизованное обновление через ЦСУ -### 20. Балансировщик: аппаратная платформа +### [20. Балансировщик: аппаратная платформа](/20.md) - 20.1. Одноюнитовый (32 порта QSFP28) и двухюнитовый (65 портов) - 20.2. Скорости портов: 10G / 25G / 100G @@ -284,7 +284,7 @@ - 20.4.5. Console MUX — переключение консоли между компонентами - 20.5. Передняя панель: Console, Management Ethernet, USB -### 21. Балансировщик: конфигурация +### [21. Балансировщик: конфигурация](/21.md) - 21.1. CLI: операционный режим / конфигурационный режим (`edit`) - 21.1.1. Интерфейс похож на Juniper CLI