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