Добавлены новые разделы:

- Раздел 22: Балансировщик: мониторинг и диагностика - Раздел 23: Распознавание протоколов (DPI Engine) - Раздел 24: Траблшутинг Каждый раздел включает команды, описания и практические примеры для диагностики и мониторинга работы балансировщика и системы фильтрации.
2026-02-20 13:59:30 +01:00
parent f1d391ccf3
commit 10fb7f4e18
25 changed files with 801 additions and 68 deletions
--- a/README.md
+++ b/README.md
@@ -4,21 +4,21 @@

 ## Оглавление

-### [1. Введение и общая архитектура АСБИ](/01.md)
+### [1. Введение и общая архитектура АСБИ](chapters/01.md)

 - 1.1. Что такое АСБИ (Автоматизированная система обеспечения безопасности интернета)
 - 1.2. Закон о суверенном интернете и участники проекта (ГУП ГРЧЦ, АО ДЦА, RDP.ru)
 - 1.3. Что такое ТСПУ — комплекс оборудования у операторов связи
 - 1.4. Общая схема: байпасы, балансировщики, фильтры, сегмент управления

-### [2. Прохождение трафика через ТСПУ](/02.md)
+### [2. Прохождение трафика через ТСПУ](chapters/02.md)

 - 2.1. Стык оператора связи: типы инкапсуляции (VLAN, QinQ, MPLS, PPPoE)
 - 2.2. Разделение на LAN-порты (абоненты) и WAN-порты (интернет)
 - 2.3. Простейший вариант ТСПУ (один байпас, один фильтр)
 - 2.4. Типовая схема ТСПУ

-### [3. Байпас (Bypass)](/03.md)
+### [3. Байпас (Bypass)](chapters/03.md)

 - 3.1. Назначение и роль байпаса в ТСПУ
 - 3.2. Байпасы Silicom (федеральный проект)
@@ -34,7 +34,7 @@
 - 3.4. Мониторинг каналов: Heartbeat-пакеты байпаса
 - 3.5. Автоматическое переключение в TAP/Active Bypass при потере канала

-### [4. Балансировщик (EcoFilter Balancer)](/04.md)
+### [4. Балансировщик (EcoFilter Balancer)](chapters/04.md)

 - 4.1. Назначение: распределение трафика по фильтрам
 - 4.2. Аппаратная платформа: 32-портовый, 1U, пропускная способность 3.2 Тбит/с
@@ -56,7 +56,7 @@
 - 4.7. Работа с различными инкапсуляциями (VLAN, MPLS)
 - 4.8. Обработка HTTP-редиректов и TCP Reset через фильтры

-### [5. Фильтр (EcoFilter)](/05.md)
+### [5. Фильтр (EcoFilter)](chapters/05.md)

 - 5.1. Путь пакета через фильтр
  - 5.1.1. Проверка: IP-пакет или нет
@@ -66,7 +66,7 @@
  - 5.1.5. Решение: пропустить или заблокировать (drop)
 - 5.2. Работа на уровне L2: фильтр как «прозрачный провод»

-### [6. Места установки ТСПУ в сети оператора](/06.md)
+### [6. Места установки ТСПУ в сети оператора](chapters/06.md)

 - 6.1. До BRAS/BPE/BNG (между абонентами и терминацией сессий)
  - 6.1.1. Особенность: PPPoE-трафик
@@ -79,7 +79,7 @@
  - 6.4.2. Разделение по VLAN для обработки трафика одного направления
  - 6.4.3. Проблемы двойной обработки и best practice

-### [7. Эшелонированная система (ТСПУ тип Б)](/07.md)
+### [7. Эшелонированная система (ТСПУ тип Б)](chapters/07.md)

 - 7.1. Назначение: обработка трафика, не прошедшего через ТСПУ тип А
 - 7.2. Проблема асимметричного трафика у крупных операторов
@@ -97,7 +97,7 @@
 - 7.6. Отсутствие логирования на Eco Highway (только real-time)
 - 7.7. Прозрачный пропуск трафика, уже обработанного ТСПУ тип А

-### [8. Формирование протокольных списков (двухстадийная блокировка)](/08.md)
+### [8. Формирование протокольных списков (двухстадийная блокировка)](chapters/08.md)

 - 8.1. Первый этап: распознавание протоколов на фильтрах (ТСПУ тип А)
 - 8.2. Отправка логов на SPFS (сервер предварительного формирования списков)
@@ -106,7 +106,7 @@
 - 8.5. Загрузка очищенных списков обратно на фильтры (HTTP) и на Eco Highway (BGP)
 - 8.6. Время полного цикла блокировки: ~5–15 минут

-### [9. Центральная система управления (ЦСУ)](/09.md)
+### [9. Центральная система управления (ЦСУ)](chapters/09.md)

 - 9.1. Архитектура: две независимые площадки (основная и резервная)
 - 9.2. Связь с ТСПУ через VPN (криптошлюз «Континент»)
@@ -114,14 +114,14 @@
 - 9.4. Подсистемы ЦСУ: формирование списков, мониторинг, логирование, картография
 - 9.5. Новая ЦСУ для федерального проекта (замена уральской)

-### [10. Сегмент управления ТСПУ](/10.md)
+### [10. Сегмент управления ТСПУ](chapters/10.md)

 - 10.1. Адресация: 10.<регион>.<площадка>.0/24
 - 10.2. Распределение адресов: байпасы, балансировщики, BMC, фильтры, IPMI, SPFS, СПХД
 - 10.3. Шлюз по умолчанию — криптошлюз «Континент»
 - 10.4. Подсеть логирования (единая для всех ТСПУ)

-### [11. Фильтр: аппаратная платформа](/11.md)
+### [11. Фильтр: аппаратная платформа](chapters/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.md)
+### [12. Сессии и трансляции на фильтре](chapters/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.md)
+### [13. Фильтр: первоначальная настройка и CLI](chapters/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.md)
+### [14. Фильтр: конфигурация подсистем](chapters/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.md)
+### [15. Фильтр: настройка интерфейсов и общих параметров](chapters/15.md)

 - 15.1. Интерфейсы: enable/disable, description (LACP не используется)
 - 15.2. NAT Defaults — общие параметры устройства
@@ -194,7 +194,7 @@
 - 15.3. Тайм-ауты сессий и трансляций
 - 15.4. IPv6: включение, диапазон адресов для обработки

-### [16. Фильтр: ACL и пулы — запуск трафика на обработку](/16.md)
+### [16. Фильтр: ACL и пулы — запуск трафика на обработку](chapters/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.md)
+### [17. Фильтр: настройка DPI](chapters/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.md)
+### [18. Фильтр: мониторинг и диагностика](chapters/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.md)
+### [19. Фильтр: обновление прошивки](chapters/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.md)
+### [20. Балансировщик: аппаратная платформа](chapters/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.md)
+### [21. Балансировщик: конфигурация](chapters/21.md)

 - 21.1. CLI: операционный режим / конфигурационный режим (`edit`)
  - 21.1.1. Интерфейс похож на Juniper CLI
@@ -311,7 +311,7 @@
 - 21.8. Настройка Heartbeat для GL Sun (пилотный проект)
 - 21.9. Management-интерфейс: IP, маска, default gateway

-### 22. Балансировщик: мониторинг и диагностика
+### [22. Балансировщик: мониторинг и диагностика](chapters/22.md)

 - 22.1. `show hardware info` — CPU, память, вентиляторы, БП, температура
 - 22.2. `show mng if` — management-интерфейс
@@ -323,7 +323,7 @@
  - 22.6.2. Time of pass — время прохождения keep-alive пакета
 - 22.7. Программный байпас: индивидуально для каждой группы портов

-### 23. Распознавание протоколов (DPI Engine)
+### [23. Распознавание протоколов (DPI Engine)](chapters/23.md)

 - 23.1. Многофакторный анализ сессий
  - 23.1.1. Размеры пакетов и их вариации
@@ -334,7 +334,7 @@
 - 23.3. Двухстадийная блокировка: распознавание → очистка в ЦСУ → блокировка
 - 23.4. Обфускация и борьба с обходом блокировок

-### 24. Траблшутинг
+### [24. Траблшутинг](chapters/24.md)

 - 24.1. Общий подход к диагностике проблем доступности
 - 24.2. Поиск сессии абонента: обход фильтров площадки
--- a/chapters/01.md
+++ b/chapters/01.md
@@ -1,6 +1,6 @@
 # 1. Введение и общая архитектура АСБИ

-[← Оглавление](README.md)
+[← Оглавление](../README.md)

 ---

@@ -36,12 +36,12 @@

 Ключевой принцип работы ТСПУ — **прозрачность для оператора**. С точки зрения сетевой топологии оператора, ТСПУ представляет собой «прозрачный провод»: трафик, вошедший через определённый канал связи, обязательно возвращается в тот же канал. Оператор не должен вносить изменения в свою маршрутизацию при установке ТСПУ.

-ТСПУ может устанавливаться в нескольких различных местах сети оператора (подробнее — в [разделе 6](06-placement.md)), и на одной площадке оператора может быть развёрнуто различное количество оборудования в зависимости от объёма трафика и количества каналов связи.
+ТСПУ может устанавливаться в нескольких различных местах сети оператора (подробнее — в [разделе 6](06.md)), и на одной площадке оператора может быть развёрнуто различное количество оборудования в зависимости от объёма трафика и количества каналов связи.

 Существует два типа ТСПУ:

 - **ТСПУ тип А** (первый эшелон) — основной тип, устанавливается у большинства операторов. Когда говорят просто «ТСПУ» без уточнения, подразумевают именно тип А;
- **ТСПУ тип Б** (второй эшелон, эшелонированная система) — устанавливается на уровне ядра сети крупных операторов для обработки трафика, который не прошёл через ТСПУ тип А (подробнее — в [разделе 7](07-echelon.md)).
+- **ТСПУ тип Б** (второй эшелон, эшелонированная система) — устанавливается на уровне ядра сети крупных операторов для обработки трафика, который не прошёл через ТСПУ тип А (подробнее — в [разделе 7](07.md)).

 ## 1.4. Общая схема: байпасы, балансировщики, фильтры, сегмент управления

@@ -127,4 +127,4 @@

 ---

-[← Оглавление](README.md) · [Раздел 2: Прохождение трафика через ТСПУ →](02.md)
+[← Оглавление](../README.md) · [Раздел 2: Прохождение трафика через ТСПУ →](02.md)
--- a/chapters/02.md
+++ b/chapters/02.md
@@ -1,6 +1,6 @@
 # 2. Прохождение трафика через ТСПУ

-[← Оглавление](README.md) · [← Раздел 1: Введение и общая архитектура АСБИ](01.md)
+[← Оглавление](../README.md) · [← Раздел 1: Введение и общая архитектура АСБИ](01.md)

 ---

@@ -245,4 +245,4 @@

 ---

-[← Оглавление](README.md) · [← Раздел 1: Введение и общая архитектура АСБИ](01.md) · [Раздел 3: Байпас →](03.md)
+[← Оглавление](../README.md) · [← Раздел 1: Введение и общая архитектура АСБИ](01.md) · [Раздел 3: Байпас →](03.md)
--- a/chapters/03.md
+++ b/chapters/03.md
@@ -1,6 +1,6 @@
 # 3. Байпас (Bypass)

-[← Оглавление](README.md) · [← Раздел 2: Прохождение трафика через ТСПУ](02.md)
+[← Оглавление](../README.md) · [← Раздел 2: Прохождение трафика через ТСПУ](02.md)

 ---

@@ -213,4 +213,4 @@ Heartbeat-пакеты байпаса Silicom — это **не IP-пакеты*

 ---

-[← Оглавление](README.md) · [← Раздел 2: Прохождение трафика через ТСПУ](02.md) · [Раздел 4: Балансировщик →](04.md)
+[← Оглавление](../README.md) · [← Раздел 2: Прохождение трафика через ТСПУ](02.md) · [Раздел 4: Балансировщик →](04.md)
--- a/chapters/04.md
+++ b/chapters/04.md
@@ -1,6 +1,6 @@
 # 4. Балансировщик (EcoFilter Balancer)

-[← Оглавление](README.md) · [← Раздел 3: Байпас](03.md)
+[← Оглавление](../README.md) · [← Раздел 3: Байпас](03.md)

 ---

@@ -245,4 +245,4 @@ Keep-alive пакеты проверяют не только физическу

 ---

-[← Оглавление](README.md) · [← Раздел 3: Байпас](03.md) · [Раздел 5: Фильтр →](05.md)
+[← Оглавление](../README.md) · [← Раздел 3: Байпас](03.md) · [Раздел 5: Фильтр →](05.md)
--- a/chapters/05.md
+++ b/chapters/05.md
@@ -1,6 +1,6 @@
 # 5. Фильтр (EcoFilter)

-[← Оглавление](README.md) · [← Раздел 4: Балансировщик](04.md)
+[← Оглавление](../README.md) · [← Раздел 4: Балансировщик](04.md)

 ---

@@ -177,4 +177,4 @@

 ---

-[← Оглавление](README.md) · [← Раздел 4: Балансировщик](04.md) · [Раздел 6: Места установки ТСПУ →](06.md)
+[← Оглавление](../README.md) · [← Раздел 4: Балансировщик](04.md) · [Раздел 6: Места установки ТСПУ →](06.md)
--- a/chapters/06.md
+++ b/chapters/06.md
@@ -1,6 +1,6 @@
 # 6. Места установки ТСПУ в сети оператора

-[← Оглавление](README.md) · [← Раздел 5: Фильтр](05.md)
+[← Оглавление](../README.md) · [← Раздел 5: Фильтр](05.md)

 ---

@@ -158,4 +158,4 @@

 ---

-[← Оглавление](README.md) · [← Раздел 5: Фильтр](05.md) · [Раздел 7: Эшелонированная система →](07.md)
+[← Оглавление](../README.md) · [← Раздел 5: Фильтр](05.md) · [Раздел 7: Эшелонированная система →](07.md)
--- a/chapters/07.md
+++ b/chapters/07.md
@@ -1,6 +1,6 @@
 # 7. Эшелонированная система (ТСПУ тип Б)

-[← Оглавление](README.md) · [← Раздел 6: Места установки ТСПУ](06.md)
+[← Оглавление](../README.md) · [← Раздел 6: Места установки ТСПУ](06.md)

 ---

@@ -212,4 +212,4 @@ Eco Highway должен уметь **различать** трафик, уже

 ---

-[← Оглавление](README.md) · [← Раздел 6: Места установки ТСПУ](06.md) · [Раздел 8: Формирование протокольных списков →](08.md)
+[← Оглавление](../README.md) · [← Раздел 6: Места установки ТСПУ](06.md) · [Раздел 8: Формирование протокольных списков →](08.md)
--- a/chapters/08.md
+++ b/chapters/08.md
@@ -1,6 +1,6 @@
 # 8. Формирование протокольных списков (двухстадийная блокировка)

-[← Оглавление](README.md) · [← Раздел 7: Эшелонированная система](07.md)
+[← Оглавление](../README.md) · [← Раздел 7: Эшелонированная система](07.md)

 ---

@@ -153,4 +153,4 @@ SPFS занимается **накоплением** поступающих пр

 ---

-[← Оглавление](README.md) · [← Раздел 7: Эшелонированная система](07.md) · [Раздел 9: Центральная система управления →](09.md)
+[← Оглавление](../README.md) · [← Раздел 7: Эшелонированная система](07.md) · [Раздел 9: Центральная система управления →](09.md)
--- a/chapters/09.md
+++ b/chapters/09.md
@@ -1,6 +1,6 @@
 # 9. Центральная система управления (ЦСУ)

-[← Оглавление](README.md) · [← Раздел 8: Формирование протокольных списков](08.md)
+[← Оглавление](../README.md) · [← Раздел 8: Формирование протокольных списков](08.md)

 ---

@@ -92,4 +92,4 @@

 ---

-[← Оглавление](README.md) · [← Раздел 8: Формирование протокольных списков](08.md) · [Раздел 10: Сегмент управления ТСПУ →](10.md)
+[← Оглавление](../README.md) · [← Раздел 8: Формирование протокольных списков](08.md) · [Раздел 10: Сегмент управления ТСПУ →](10.md)
--- a/chapters/10.md
+++ b/chapters/10.md
@@ -1,6 +1,6 @@
 # 10. Сегмент управления ТСПУ

-[← Оглавление](README.md) · [← Раздел 9: Центральная система управления](09.md)
+[← Оглавление](../README.md) · [← Раздел 9: Центральная система управления](09.md)

 ---

@@ -87,4 +87,4 @@

 ---

-[← Оглавление](README.md) · [← Раздел 9: Центральная система управления](09.md) · [Раздел 11: Фильтр: аппаратная платформа →](11.md)
+[← Оглавление](../README.md) · [← Раздел 9: Центральная система управления](09.md) · [Раздел 11: Фильтр: аппаратная платформа →](11.md)
--- a/chapters/11.md
+++ b/chapters/11.md
@@ -1,6 +1,6 @@
 # 11. Фильтр: аппаратная платформа

-[← Оглавление](README.md) · [← Раздел 10: Сегмент управления ТСПУ](10.md)
+[← Оглавление](../README.md) · [← Раздел 10: Сегмент управления ТСПУ](10.md)

 ---

@@ -137,4 +137,4 @@

 ---

-[← Оглавление](README.md) · [← Раздел 10: Сегмент управления ТСПУ](10.md) · [Раздел 12: Сессии и трансляции на фильтре →](12.md)
+[← Оглавление](../README.md) · [← Раздел 10: Сегмент управления ТСПУ](10.md) · [Раздел 12: Сессии и трансляции на фильтре →](12.md)
--- a/chapters/12.md
+++ b/chapters/12.md
@@ -1,6 +1,6 @@
 # 12. Сессии и трансляции на фильтре

-[← Оглавление](README.md) · [← Раздел 11: Фильтр: аппаратная платформа](11.md)
+[← Оглавление](../README.md) · [← Раздел 11: Фильтр: аппаратная платформа](11.md)

 ---

@@ -188,4 +188,4 @@ API для удалённого доступа к данным фильтра о

 ---

-[← Оглавление](README.md) · [← Раздел 11: Фильтр: аппаратная платформа](11.md) · [Раздел 13: Фильтр: первоначальная настройка и CLI →](13.md)
+[← Оглавление](../README.md) · [← Раздел 11: Фильтр: аппаратная платформа](11.md) · [Раздел 13: Фильтр: первоначальная настройка и CLI →](13.md)
--- a/chapters/13.md
+++ b/chapters/13.md
@@ -1,6 +1,6 @@
 # 13. Фильтр: первоначальная настройка и CLI

-[← Оглавление](README.md) · [← Раздел 12: Сессии и трансляции на фильтре](12.md)
+[← Оглавление](../README.md) · [← Раздел 12: Сессии и трансляции на фильтре](12.md)

 ---

@@ -175,4 +175,4 @@ CLI поддерживает стандартный набор средств н

 ---

-[← Оглавление](README.md) · [← Раздел 12: Сессии и трансляции на фильтре](12.md) · [Раздел 14: Фильтр: конфигурация подсистем →](14.md)
+[← Оглавление](../README.md) · [← Раздел 12: Сессии и трансляции на фильтре](12.md) · [Раздел 14: Фильтр: конфигурация подсистем →](14.md)
--- a/chapters/14.md
+++ b/chapters/14.md
@@ -1,6 +1,6 @@
 # 14. Фильтр: конфигурация подсистем

-[← Оглавление](README.md) · [← Раздел 13: Фильтр: первоначальная настройка и CLI](13.md)
+[← Оглавление](../README.md) · [← Раздел 13: Фильтр: первоначальная настройка и CLI](13.md)

 ---

@@ -229,4 +229,4 @@

 ---

-[← Оглавление](README.md) · [← Раздел 13: Фильтр: первоначальная настройка и CLI](13.md) · [Раздел 15: Фильтр: настройка интерфейсов и общих параметров →](15.md)
+[← Оглавление](../README.md) · [← Раздел 13: Фильтр: первоначальная настройка и CLI](13.md) · [Раздел 15: Фильтр: настройка интерфейсов и общих параметров →](15.md)
--- a/chapters/15.md
+++ b/chapters/15.md
@@ -1,6 +1,6 @@
 # 15. Фильтр: настройка интерфейсов и общих параметров

-[← Оглавление](README.md) · [← Раздел 14: Фильтр: конфигурация подсистем](14.md)
+[← Оглавление](../README.md) · [← Раздел 14: Фильтр: конфигурация подсистем](14.md)

 ---

@@ -120,4 +120,4 @@

 ---

-[← Оглавление](README.md) · [← Раздел 14: Фильтр: конфигурация подсистем](14.md) · [Раздел 16: Фильтр: ACL и пулы →](16.md)
+[← Оглавление](../README.md) · [← Раздел 14: Фильтр: конфигурация подсистем](14.md) · [Раздел 16: Фильтр: ACL и пулы →](16.md)
--- a/chapters/16.md
+++ b/chapters/16.md
@@ -1,6 +1,6 @@
 # 16. Фильтр: ACL и пулы — запуск трафика на обработку

-[← Оглавление](README.md) · [← Раздел 15: Фильтр: настройка интерфейсов и общих параметров](15.md)
+[← Оглавление](../README.md) · [← Раздел 15: Фильтр: настройка интерфейсов и общих параметров](15.md)

 ---

@@ -195,4 +195,4 @@ ACL (Access Control List) — это набор правил, определяю

 ---

-[← Оглавление](README.md) · [← Раздел 15: Фильтр: настройка интерфейсов и общих параметров](15.md) · [Раздел 17: Фильтр: настройка DPI →](17.md)
+[← Оглавление](../README.md) · [← Раздел 15: Фильтр: настройка интерфейсов и общих параметров](15.md) · [Раздел 17: Фильтр: настройка DPI →](17.md)
--- a/chapters/17.md
+++ b/chapters/17.md
@@ -1,6 +1,6 @@
 # 17. Фильтр: настройка DPI

-[← Оглавление](README.md) · [← Раздел 16: Фильтр: ACL и пулы](16.md)
+[← Оглавление](../README.md) · [← Раздел 16: Фильтр: ACL и пулы](16.md)

 ---

@@ -307,4 +307,4 @@ Download URL задаёт источник списков для DPI-листо

 ---

-[← Оглавление](README.md) · [← Раздел 16: Фильтр: ACL и пулы](16.md) · [Раздел 18: Фильтр: мониторинг и диагностика →](18.md)
+[← Оглавление](../README.md) · [← Раздел 16: Фильтр: ACL и пулы](16.md) · [Раздел 18: Фильтр: мониторинг и диагностика →](18.md)
--- a/chapters/18.md
+++ b/chapters/18.md
@@ -1,6 +1,6 @@
 # 18. Фильтр: мониторинг и диагностика

-[← Оглавление](README.md) · [← Раздел 17: Фильтр: настройка DPI](17.md)
+[← Оглавление](../README.md) · [← Раздел 17: Фильтр: настройка DPI](17.md)

 ---

@@ -323,4 +323,4 @@

 ---

-[← Оглавление](README.md) · [← Раздел 17: Фильтр: настройка DPI](17.md) · [Раздел 19: Фильтр: обновление прошивки →](19.md)
+[← Оглавление](../README.md) · [← Раздел 17: Фильтр: настройка DPI](17.md) · [Раздел 19: Фильтр: обновление прошивки →](19.md)
--- a/chapters/19.md
+++ b/chapters/19.md
@@ -1,6 +1,6 @@
 # 19. Фильтр: обновление прошивки

-[← Оглавление](README.md) · [← Раздел 18: Фильтр: мониторинг и диагностика](18.md)
+[← Оглавление](../README.md) · [← Раздел 18: Фильтр: мониторинг и диагностика](18.md)

 ---

@@ -117,4 +117,4 @@

 ---

-[← Оглавление](README.md) · [← Раздел 18: Фильтр: мониторинг и диагностика](18.md) · [Раздел 20: Балансировщик: аппаратная платформа →](20.md)
+[← Оглавление](../README.md) · [← Раздел 18: Фильтр: мониторинг и диагностика](18.md) · [Раздел 20: Балансировщик: аппаратная платформа →](20.md)
--- a/chapters/20.md
+++ b/chapters/20.md
@@ -1,6 +1,6 @@
 # 20. Балансировщик: аппаратная платформа

-[← Оглавление](README.md) · [← Раздел 19: Фильтр: обновление прошивки](19.md)
+[← Оглавление](../README.md) · [← Раздел 19: Фильтр: обновление прошивки](19.md)

 ---

@@ -172,4 +172,4 @@

 ---

-[← Оглавление](README.md) · [← Раздел 19: Фильтр: обновление прошивки](19.md) · [Раздел 21: Балансировщик: конфигурация →](21.md)
+[← Оглавление](../README.md) · [← Раздел 19: Фильтр: обновление прошивки](19.md) · [Раздел 21: Балансировщик: конфигурация →](21.md)
--- a/chapters/21.md
+++ b/chapters/21.md
@@ -1,6 +1,6 @@
 # 21. Балансировщик: конфигурация

-[← Оглавление](README.md) · [← Раздел 20: Балансировщик: аппаратная платформа](20.md)
+[← Оглавление](../README.md) · [← Раздел 20: Балансировщик: аппаратная платформа](20.md)

 ---

@@ -483,4 +483,4 @@ Management-интерфейс обеспечивает доступ к устр

 ---

-[← Оглавление](README.md) · [← Раздел 20: Балансировщик: аппаратная платформа](20.md) · [Раздел 22: Балансировщик: мониторинг и диагностика →](22.md)
+[← Оглавление](../README.md) · [← Раздел 20: Балансировщик: аппаратная платформа](20.md) · [Раздел 22: Балансировщик: мониторинг и диагностика →](22.md)
--- a/chapters/22.md
+++ b/chapters/22.md
@@ -0,0 +1,262 @@
+# 22. Балансировщик: мониторинг и диагностика
+
+[← Оглавление](../README.md) · [← Раздел 21: Балансировщик: конфигурация](21.md)
+
+---
+
+Балансировщик предоставляет набор команд для мониторинга аппаратного состояния, проверки прошивок, диагностики портов, анализа правил фильтрации и контроля групп балансировки. Все команды мониторинга выполняются в **операционном режиме**.
+
+## 22.1. `show hardware info` — CPU, память, вентиляторы, БП, температура
+
+Команда `show hardware info` с различными ключевыми словами отображает состояние аппаратных компонентов балансировщика:
+
+| Команда                          | Описание                                    |
+| -------------------------------- | ------------------------------------------- |
+| `show hardware info cpu`         | Нагрузка на процессор (микросервер)         |
+| `show hardware info memory`      | Состояние оперативной памяти                |
+| `show hardware info fans`        | Состояние вентиляторов                      |
+| `show hardware info power`       | Состояние блоков питания                    |
+| `show hardware info temperature` | Показания температурных датчиков            |
+| **`show hardware info all`**     | **Вся информация** по всем компонентам      |
+
+Для быстрой проверки общего состояния платформы удобно использовать `show hardware info all` — команда выводит полную картину по всем аппаратным подсистемам.
+
+> **Практический случай:** именно через мониторинг температурных датчиков была выявлена проблема с зависаниями балансировщиков весной — BMC некорректно считывал показания датчика, ошибочно определял перегрев и выключал микросервер (подробнее — в [разделе 20.4.3](20.md)).
+
+## 22.2. `show mng if` — management-интерфейс
+
+Команда `show mng if` отображает текущее состояние management-интерфейса:
+
+- **IP-адрес**;
+- **Маска подсети**;
+- **Default gateway**;
+- **Состояние интерфейса** (up/down).
+
+Команда полезна для быстрой проверки параметров управления после настройки или перезагрузки устройства.
+
+## 22.3. `show rdp firmware version` — версии прошивок, tries
+
+Команда `show rdp firmware version` выводит полную информацию о состоянии прошивок:
+
+```text
+    Current active firmware: A
+
+    Partition A:
+      Status:  active
+      Version: 2.4.1
+      Tries:   0
+
+    Partition B:
+      Status:  inactive
+      Version: 2.3.8
+      Tries:   0
+```
+
+| Параметр          | Описание                                                              |
+| ----------------- | --------------------------------------------------------------------- |
+| **Current active**| Какой раздел (A или B) является текущим активным                      |
+| **Status**        | `active` или `inactive` для каждого раздела                           |
+| **Version**       | Номер версии прошивки в разделе                                       |
+| **Tries**         | Счётчик попыток загрузки с данного раздела                            |
+
+### Параметр Tries
+
+В нормальном состоянии **Tries = 0**. Ненулевое значение означает, что балансировщик предпринимал неудачные попытки загрузки с этого раздела.
+
+Если балансировщик **более 3 раз подряд** за ~20 минут не смог загрузиться с определённого раздела, прошивка считается **ненадёжной** и происходит автоматический rollback на другой раздел (подробнее — в [разделе 21.2.1](21.md)).
+
+Для сброса счётчика используется команда `call rdp firmware reset-tries`.
+
+## 22.4. Состояние портов и трансиверов: SFP-информация, DDM, статистика фреймов
+
+### Информация о трансиверах
+
+Для каждого порта можно вывести информацию об установленном трансивере:
+
+```text
+    show port <имя_порта> sfp
+```
+
+В выводе отображаются **все четыре линии** (lane) физического порта, даже если задействованы не все. Для каждой линии показаны:
+
+| Параметр                  | Описание                                                   |
+| ------------------------- | ---------------------------------------------------------- |
+| **Тип трансивера**        | Оптика, DAC (медный кабель прямого подключения) и т.д.     |
+| **Справочная информация** | Производитель, модель, серийный номер SFP                  |
+| **Уровень сигнала (DDM)** | Мощность в децибелах (только для оптических трансиверов)   |
+
+> **Примечание:** для медных DAC-кабелей (гидр) уровень сигнала **не отображается**, так как DDM-мониторинг применяется только к оптике. Если установлена оптическая гидра — значения мощности будут видны для каждой линии.
+
+### Подробная статистика порта
+
+Для каждого порта доступна детальная статистика на уровне фреймов:
+
+```text
+    show port <имя_порта> statistics
+```
+
+Вывод содержит подробную информацию:
+
+- Количество полученных и отправленных фреймов;
+- Фреймы с ошибками;
+- Распределение по размерам фреймов;
+- Счётчики различных типов ошибок.
+
+Эта статистика полезна при диагностике проблем с физическим подключением — ошибки на уровне фреймов могут указывать на проблемы с кабелями, трансиверами или несовместимость оборудования.
+
+## 22.5. Статистика правил фильтрации: счётчики пакетов/байт по каждому flow
+
+По каждому правилу фильтрации (flow rule) балансировщик ведёт **счётчики пакетов и байт**, прошедших через данное правило:
+
+```text
+    show filters <имя_фильтра> flows <имя_правила>
+```
+
+В выводе отображается поле **statistics** с количеством пакетов и байт, которые были заматчены данным правилом.
+
+### Применение для диагностики
+
+Статистика правил — мощный инструмент диагностики. Типовые сценарии:
+
+**Сценарий 1: Проверка наличия трафика**
+
+Если оператор сообщает, что трафик определённого VLAN проходит через площадку, можно убедиться в этом по счётчикам соответствующего правила. Если счётчики растут — трафик действительно проходит через балансировщик.
+
+**Сценарий 2: Исключение ТСПУ как причины проблемы**
+
+Для диагностики можно создать **временное правило** с высоким приоритетом, которое матчит проблемный трафик (например, конкретный VLAN) и выполняет action `bypass`:
+
+```text
+    1. Создать правило: match VLAN <номер>, action bypass, высокий приоритет
+    2. Применить конфигурацию (apply)
+    3. Проверить: изменилось ли поведение трафика?
+    4. Проверить счётчики правила: трафик проходит?
+```
+
+Если после создания bypass-правила проблема исчезла — причина в обработке на фильтрах, и нужно диагностировать дальше. Если проблема осталась, а счётчики показывают, что трафик проходит через правило — ТСПУ не является причиной.
+
+> **Важно:** после завершения диагностики не забудьте **удалить временное правило** и применить конфигурацию.
+
+## 22.6. Состояние группы балансировки
+
+Команда для просмотра состояния группы балансировки:
+
+```text
+    show balance-group <имя_группы>
+```
+
+Вывод показывает общее состояние группы и статус каждой filter group внутри неё.
+
+### 22.6.1. Статус filter groups: up/bypass
+
+Каждая filter group (пара портов в сторону фильтра) может находиться в одном из двух состояний:
+
+| Состояние    | Описание                                                            |
+| ------------ | ------------------------------------------------------------------- |
+| **up**       | Пара портов активна, трафик отправляется на фильтр                  |
+| **bypass**   | Пара портов в режиме программного bypass — трафик перекладывается из LAN в WAN и наоборот, не отправляясь на фильтр |
+
+В нормальном рабочем состоянии **все filter groups** должны находиться в состоянии `up`.
+
+Переход в `bypass` происходит автоматически при потере заданного количества последовательных keep-alive пакетов (по умолчанию — 5). Обратный переход в `up` также автоматический — при получении достаточного количества ответных keep-alive пакетов.
+
+### 22.6.2. Time of pass — время прохождения keep-alive пакета
+
+Внутри каждой filter group отображается параметр **time of pass** — время прохождения keep-alive пакета через фильтр:
+
+```text
+    Filter Group fg1:
+      Status:        up
+      Time of pass:  27000 ns
+```
+
+| Параметр           | Описание                                                          |
+| ------------------ | ----------------------------------------------------------------- |
+| **Time of pass**   | Время (в наносекундах) между отправкой keep-alive пакета в LAN-порт и получением его из парного WAN-порта |
+| **Time of receipt**| Внутренний timestamp — привязан к внутреннему счётчику, практической ценности для эксплуатации не имеет |
+
+Механизм измерения:
+
+1. Балансировщик отправляет keep-alive пакет в **LAN-порт** filter group;
+2. Пакет проходит через фильтр (прозрачно, минуя DPI);
+3. Балансировщик получает пакет из **WAN-порта** той же filter group;
+4. Фиксируется разница во времени — это и есть **time of pass**.
+
+В нормальном состоянии time of pass составляет порядка **20–30 микросекунд** (20 000–30 000 наносекунд).
+
+> **Важно:** балансировщик **ничего не знает** о работе DPI на фильтрах. Keep-alive пакеты проходят через фильтр прозрачно, без обработки движком DPI. Параметр time of pass отражает исключительно время прохождения пакета через аппаратную часть фильтра.
+
+Если пакеты начинают теряться — time of pass резко возрастает. После потери **5 последовательных** keep-alive пакетов filter group переводится в состояние `bypass`.
+
+### Влияние загрузки фильтра на keep-alive
+
+При высокой загрузке таблиц сессий фильтра (значительно выше рекомендованных 20%) фильтр может начать медленнее обрабатывать трафик и **дропать пакеты**, в том числе keep-alive. Это может привести к «флапингу» filter group — циклическому переключению между `up` и `bypass`.
+
+В такой ситуации оператор **не почувствует флапов** на физических линках (программный bypass не затрагивает физику), но:
+
+- Небольшое количество пакетов может теряться при каждом переключении;
+- Часть трафика временно не фильтруется.
+
+Система мониторинга должна отслеживать загрузку таблиц на фильтрах и сигнализировать о приближении к пороговым значениям **до** того, как начнутся проблемы с keep-alive.
+
+## 22.7. Программный байпас: индивидуально для каждой группы портов
+
+Программный bypass на балансировщике может управляться как **автоматически** (по результатам keep-alive), так и **вручную**:
+
+```text
+    call balance-group <имя_группы> software-bypass <режим>
+```
+
+| Режим        | Описание                                                            |
+| ------------ | ------------------------------------------------------------------- |
+| **bypass**   | Принудительно перевести группу в режим программного bypass          |
+| **primary**  | Вернуть группу в нормальный режим работы (трафик на фильтры)       |
+
+### Индивидуальный bypass для каждой filter group
+
+Ключевое преимущество программного bypass — его **гранулярность**. Bypass включается **индивидуально для каждой filter group**, а не для всей группы балансировки целиком:
+
+```text
+    Filter Group fg1: up        ← трафик идёт на фильтр
+    Filter Group fg2: bypass    ← трафик байпасится (проблема с этой парой портов)
+    Filter Group fg3: up        ← трафик идёт на фильтр
+    Filter Group fg4: up        ← трафик идёт на фильтр
+```
+
+Это означает, что при проблеме с одним интерфейсом фильтра **не фильтруется** только часть трафика, проходящая через данную пару портов. Весь остальной трафик продолжает нормально обрабатываться.
+
+### Преимущества перед переключением на байпасе
+
+| Критерий                   | Bypass на оптическом байпасе          | Программный bypass на балансировщике    |
+| -------------------------- | ------------------------------------- | --------------------------------------- |
+| **Флап линков оператора**  | Да — при каждом переключении          | **Нет** — физические линки не затрагиваются |
+| **Гранулярность**          | Вся площадка целиком                  | **Каждая пара портов** индивидуально    |
+| **Согласование с оператором** | Требуется (работы, окна обслуживания) | **Не требуется** — оператор ничего не замечает |
+| **Последствия**            | Весь трафик не фильтруется            | Не фильтруется **только часть** трафика |
+
+> **Опыт эксплуатации:** такое поведение было опробовано при тестировании эшелонированной системы в Сургуте. Вместо переключения трафика на оптическом байпасе (что вызывает флапы линков и недовольство оператора) использовался программный bypass на балансировщике — одной командой трафик уводился с фильтров без каких-либо видимых последствий для оператора.
+
+### Автоматическое восстановление
+
+При автоматическом bypass (по результатам keep-alive):
+
+- Если filter group потеряла keep-alive — автоматически переводится в `bypass`;
+- Когда интерфейс восстанавливается и keep-alive снова проходят — filter group **автоматически возвращается** в рабочее состояние (`up`);
+- Перебалансировки трафика **не происходит** (при выключенной перебалансировке) — остальные filter groups продолжают работать без изменений.
+
+### Проверка Bypass Watchdog (пилотный проект, Урал)
+
+Для уральского проекта с байпасами GL Sun доступна дополнительная диагностика связи между балансировщиком и байпасом:
+
+| Состояние     | Описание                                                         |
+| ------------- | ---------------------------------------------------------------- |
+| **active**    | Группа балансировки активна, heartbeat-пакеты отправляются на байпас, байпас отвечает |
+| **disconnected** | Группа балансировки неактивна или связь с байпасом потеряна — heartbeat-пакеты не отправляются |
+
+Связь с байпасом GL Sun осуществляется по **протоколу TCP**. При переходе группы балансировки в неактивное состояние отправка heartbeat прекращается.
+
+> **Примечание:** данная диагностика **не актуальна** для федерального проекта с байпасами Silicom, где heartbeat генерируется и проверяется самим байпасом.
+
+---
+
+[← Оглавление](../README.md) · [← Раздел 21: Балансировщик: конфигурация](21.md) · [Раздел 23: Распознавание протоколов (DPI Engine) →](23.md)
--- a/chapters/23.md
+++ b/chapters/23.md
@@ -0,0 +1,165 @@
+# 23. Распознавание протоколов (DPI Engine)
+
+[← Оглавление](../README.md) · [← Раздел 22: Балансировщик: мониторинг и диагностика](22.md)
+
+---
+
+Распознавание протоколов — одна из ключевых функций фильтра ТСПУ. Внутренний движок DPI анализирует проходящие сессии и определяет, к какому протоколу или приложению они относятся: Telegram, WhatsApp, Viber, OpenVPN, BitTorrent и другие. Распознавание особенно важно для **шифрованного трафика**, где нет очевидных полей, указывающих на конкретный протокол, и идентификация выполняется **косвенным образом**.
+
+## 23.1. Многофакторный анализ сессий
+
+DPI-движок фильтра анализирует не отдельные пакеты, а **целые сессии**. Для распознавания необходимо, чтобы в рамках одной сессии прошло **несколько пакетов** в обоих направлениях — одного первого пакета недостаточно.
+
+Анализ проводится по **множеству параметров одновременно** — их может быть десяток и более. Совокупность этих параметров формирует уникальный «профиль» трафика конкретного протокола.
+
+### 23.1.1. Размеры пакетов и их вариации
+
+Один из ключевых параметров анализа — **размеры пакетов** в рамках сессии и их **вариации**:
+
+- Средний размер пакетов;
+- Разброс размеров (минимальный, максимальный, стандартное отклонение);
+- Характерные паттерны размеров (например, первые пакеты одного размера, последующие — другого).
+
+Разные протоколы и приложения генерируют пакеты с **характерными размерными профилями**. Например, голосовой трафик мессенджера будет иметь иной размерный профиль, чем передача файлов через тот же мессенджер.
+
+### 23.1.2. Частота прохождения пакетов
+
+**Частота прохождения пакетов** — ещё один важный параметр:
+
+- Интервалы между пакетами;
+- Регулярность или нерегулярность этих интервалов;
+- Всплески активности и паузы.
+
+Голосовые вызовы, например, генерируют поток пакетов с **регулярными короткими интервалами**, тогда как обмен текстовыми сообщениями создаёт **нерегулярный** трафик с длительными паузами.
+
+### 23.1.3. Ключевые слова и паттерны внутри пакетов
+
+DPI-движок также анализирует **содержимое пакетов** — ищет характерные ключевые слова, последовательности байтов и структурные паттерны:
+
+- Специфичные заголовки и поля протокола;
+- Характерные байтовые последовательности (сигнатуры);
+- Структура данных внутри пакета (порядок полей, длины полей).
+
+Помимо очевидных параметров (source/destination IP, порты), анализируются **менее очевидные** признаки, которые в совокупности позволяют отнести сессию к конкретному протоколу.
+
+### 23.1.4. Особенности анализа шифрованного трафика
+
+Шифрованный трафик представляет **особую сложность** для распознавания:
+
+- Содержимое пакетов зашифровано — нет очевидных полей, указывающих на протокол;
+- Ключевые слова и сигнатуры **недоступны** для анализа;
+- Распознавание выполняется **исключительно косвенными методами** — по размерам пакетов, частоте, вариациям и другим статистическим параметрам.
+
+Для распознавания шифрованных протоколов (например, Telegram) используется **многофакторный анализ** — математическая модель, которая на основе совокупности косвенных признаков делает вывод о принадлежности сессии к конкретному протоколу. Конкретные алгоритмы и математика этого анализа являются внутренней разработкой и в открытом виде не раскрываются.
+
+> **Принцип работы:** DPI-движок берёт сессию (не один пакет, а несколько пакетов в обоих направлениях), анализирует их по множеству параметров и принимает решение — например, «данный трафик в этой сессии — это Telegram» или «это WhatsApp».
+
+## 23.2. Ложноположительные срабатывания
+
+Многофакторный анализ **не является стопроцентным** — возможны **ложноположительные срабатывания** (false positives), когда один шифрованный трафик по тем же косвенным критериям ошибочно распознаётся как другой протокол.
+
+Причины ложноположительных срабатываний:
+
+| Причина                               | Описание                                                          |
+| -------------------------------------- | ----------------------------------------------------------------- |
+| **Похожие профили трафика**            | Разные протоколы могут генерировать трафик с похожими размерами пакетов и частотой |
+| **Шифрование скрывает различия**       | Без доступа к содержимому пакетов анализ опирается на меньше признаков |
+| **Новые версии протоколов**            | Обновления приложений могут изменить профиль трафика, сделав его похожим на другой протокол |
+
+**Последствия ложного срабатывания:** если фильтр ошибочно распознал легитимный трафик как блокируемый протокол и сразу заблокировал его — пользователь потеряет доступ к полезному ресурсу. Именно поэтому прямая блокировка по результатам DPI на фильтре **не применяется** для протоколов — вместо этого используется двухстадийная схема.
+
+## 23.3. Двухстадийная блокировка: распознавание → очистка в ЦСУ → блокировка
+
+Для минимизации ложноположительных срабатываний блокировка протоколов выполняется **в два этапа** (подробная схема — в [разделе 8](08.md)):
+
+```text
+    ┌─────────────────────────────────────────────────────────────────┐
+    │  Этап 1: Распознавание (фильтр)                                │
+    │                                                                 │
+    │  • DPI-движок анализирует сессию                               │
+    │  • Определяет протокол (Telegram, WhatsApp, ...)               │
+    │  • Результат записывается в лог                                │
+    │  • Трафик НЕ БЛОКИРУЕТСЯ (behavior: ignore)                    │
+    │  • Логи отправляются на SPFS → ЦСУ                             │
+    └──────────────────────────┬──────────────────────────────────────┘
+                               │
+                               ▼
+    ┌─────────────────────────────────────────────────────────────────┐
+    │  Очистка (ЦСУ)                                                  │
+    │                                                                 │
+    │  • Сбор логов со ВСЕХ площадок (~350 площадок, ~5000 устройств)│
+    │  • Сопоставление сессий с разных фильтров                      │
+    │  • Глубокий статистический анализ                               │
+    │  • Обогащение данных сторонней информацией                      │
+    │  • Формирование очищенных списков (IP + порт)                  │
+    │  • Вероятность ложного срабатывания — крайне низка              │
+    └──────────────────────────┬──────────────────────────────────────┘
+                               │
+                               ▼
+    ┌─────────────────────────────────────────────────────────────────┐
+    │  Этап 2: Блокировка (фильтр / Eco Highway)                     │
+    │                                                                 │
+    │  • Очищенные списки загружаются на фильтры (HTTP)              │
+    │    и на Eco Highway (BGP)                                      │
+    │  • Загрузка в ОТДЕЛЬНЫЙ DPI-лист (не тот, где распознавание)   │
+    │  • На этом DPI-листе: behavior: block                          │
+    │  • Блокировка по проверенным адресам                           │
+    └─────────────────────────────────────────────────────────────────┘
+```
+
+### Разделение DPI-листов
+
+На одном фильтре **одновременно работают два процесса**:
+
+| DPI-лист              | Behavior    | Назначение                                          |
+| --------------------- | ----------- | --------------------------------------------------- |
+| DPI-лист 0            | **ignore**  | Распознавание протоколов, запись логов, без блокировки |
+| DPI-лист 5 (пример)   | **block**   | Блокировка по очищенным спискам из ЦСУ              |
+
+Таким образом, распознавание и блокировка выполняются **в разных DPI-листах** — это позволяет независимо управлять каждым процессом.
+
+### Преимущества централизованного анализа
+
+ЦСУ видит данные **со всех фильтров на всех площадках**, а не только с одного конкретного устройства. Это даёт принципиально **более полную картину**:
+
+- Один фильтр видит только «свои» сессии — ЦСУ видит **все сессии** по всей стране;
+- Статистический анализ на большой выборке **значительно точнее**;
+- Возможность обогащения данных **сторонней информацией** повышает качество распознавания.
+
+### Время полного цикла
+
+От момента появления нового, ранее неизвестного сервера блокируемого протокола до его фактической блокировки проходит **от 5 до 15 минут** (подробнее — в [разделе 8.6](08.md)).
+
+## 23.4. Обфускация и борьба с обходом блокировок
+
+Обфускация — это намеренное изменение характеристик протокола, направленное на то, чтобы DPI-движок **не смог его распознать**. Это постоянная «гонка вооружений» между разработчиками средств обхода блокировок и разработчиками систем фильтрации.
+
+### Принцип «ананасных мальчиков»
+
+Борьба между системами обхода и системами блокировки описывается как **постоянное противостояние**: одна сторона в какой-то момент имеет преимущество, которое затем нивелируется следующим шагом противоположной стороны.
+
+### Типы обфускации и возможности распознавания
+
+| Тип обфускации                        | Возможность распознавания                               |
+| ------------------------------------- | ------------------------------------------------------- |
+| **Простая** (например, XOR)           | Фильтр может «развернуть» обфускацию и распознать протокол |
+| **Протокол притворяется другим**      | Распознавание возможно, но требует разработки новых сигнатур и методик |
+| **Качественная имитация другого протокола** | Распознать **невозможно** без разработки принципиально нового подхода |
+
+### Обновление сигнатур
+
+Когда обнаруживается, что новая версия приложения или протокола **перестала распознаваться** фильтром, это означает необходимость:
+
+1. **Анализа изменений** — что именно изменилось в новой версии протокола;
+2. **Разработки новой сигнатуры** — обновление правил распознавания для учёта изменений;
+3. **Обновления прошивки** — доставка обновлённого DPI-движка на фильтры.
+
+> **Практический подход:** к этому процессу следует относиться с пониманием — это нормальная и ожидаемая ситуация. Полное и постоянное распознавание всех протоколов **невозможно** в принципе. Задача системы — поддерживать актуальные сигнатуры и оперативно реагировать на изменения.
+
+### Защита от ложных блокировок при борьбе с обфускацией
+
+Двухстадийная система блокировки (раздел 23.3) особенно важна в контексте борьбы с обфускацией. Обфусцированный трафик **по определению** имеет нестандартный профиль, что повышает вероятность ложноположительного срабатывания. Централизованная очистка на ЦСУ снижает этот риск, сопоставляя данные с множества источников.
+
+---
+
+[← Оглавление](../README.md) · [← Раздел 22: Балансировщик: мониторинг и диагностика](22.md) · [Раздел 24: Траблшутинг →](24.md)
--- a/chapters/24.md
+++ b/chapters/24.md
@@ -0,0 +1,306 @@
+# 24. Траблшутинг
+
+[← Оглавление](../README.md) · [← Раздел 23: Распознавание протоколов (DPI Engine)](23.md)
+
+---
+
+Диагностика проблем на ТСПУ — комплексная задача, требующая понимания архитектуры системы, принципов прохождения трафика и взаимодействия компонентов. В данном разделе описаны типовые подходы к траблшутингу, которые применяются при обращениях операторов связи и абонентов.
+
+## 24.1. Общий подход к диагностике проблем доступности
+
+При обращении оператора или абонента с жалобой на недоступность ресурса необходимо последовательно пройти несколько шагов:
+
+```text
+    1. Уточнить детали проблемы
+           │
+    2. Определить, есть ли проблема прямо сейчас (или была вчера)
+           │
+    3. Найти сессии абонента на фильтрах
+           │
+    4. Проверить ресурс в DPI-листах
+           │
+    5. Исключить ТСПУ как причину (bypass / No IP)
+           │
+    6. Локализовать проблему
+```
+
+### Шаг 1: Уточнение деталей
+
+Всегда необходимо **выяснять подробности** у абонента или оператора. Формулировка «ресурс недоступен» может означать совершенно разные вещи:
+
+| Жалоба абонента              | Что это может означать на самом деле                      |
+| ---------------------------- | --------------------------------------------------------- |
+| «Сайт не открывается»       | Полная блокировка, ошибка DNS, проблема на стороне сервера |
+| «Всё тормозит»              | Деградация протокола, перегрузка канала, проблема на стороне оператора |
+| «Часть сайта не работает»   | Блокировка отдельных ресурсов (CDN, API), проблема с HTTPS |
+| «Приложение не подключается»| Блокировка протокола, обновление приложения, проблема с обфускацией |
+
+> **Статистика:** по опыту эксплуатации, примерно в **80% случаев** проблема связана **не с ТСПУ**, а с самим ресурсом, абонентом или оператором связи. Однако всегда необходимо проверять и исключать влияние ТСПУ.
+
+### Шаг 2: Актуальность проблемы
+
+**Диагностика постфактум крайне затруднена.** Если абонент сообщает о проблеме, которая была вчера, а сегодня её нет, — возможности анализа ограничены:
+
+- Если сохранились **логи соединений** за нужный период — можно проанализировать, были ли сессии к проблемному ресурсу;
+- Если логов нет — восстановить картину практически невозможно.
+
+**Если проблема существует прямо сейчас** — шансы на успешную диагностику значительно выше. В этом случае важно работать **в реальном времени** совместно с абонентом или оператором.
+
+## 24.2. Поиск сессии абонента: обход фильтров площадки
+
+Первый практический шаг — **найти сессии** конкретного абонента к конкретному ресурсу на фильтрах площадки.
+
+### Поиск по локальному адресу
+
+Для поиска сессий используется команда `show session` с фильтрацией по локальному адресу абонента:
+
+```text
+    > show session la <IP-адрес_абонента>:<порт> | more
+```
+
+Или для просмотра всех сессий абонента:
+
+```text
+    > show session la <IP-адрес_абонента> | more
+```
+
+Для подсчёта количества сессий:
+
+```text
+    > show session la <IP-адрес_абонента> | count
+```
+
+### Поиск по удалённому адресу
+
+Если известен IP-адрес ресурса, к которому обращается абонент:
+
+```text
+    > show session ra <IP-адрес_ресурса> | more
+```
+
+### Интерпретация результатов
+
+| Результат                              | Интерпретация                                              |
+| -------------------------------------- | ---------------------------------------------------------- |
+| Сессии **найдены**                     | Трафик абонента проходит через фильтр — ТСПУ его видит     |
+| Сессии **не найдены**                  | Трафик не проходит через данный фильтр — абонент идёт другим путём, либо проблема до ТСПУ |
+| Сессии есть, но ресурс недоступен      | Возможна блокировка на уровне DPI — проверить DPI-листы    |
+
+> **Важно:** при поиске сессий помните принцип «локальный адрес всегда на первом месте» (см. [раздел 12](12.md)). Независимо от направления трафика, IP-адрес абонента записывается в поле local. Если в поле local отображаются адреса, которые не являются абонентскими (интернет-адреса), — это признак перепутки LAN/WAN (см. раздел 24.6).
+
+### Особенности при установке после CGNAT
+
+Если ТСПУ установлен **после CGNAT** (см. [раздел 6.3](06.md)), на фильтре видны только белые (транслированные) адреса. Для идентификации конкретного абонента необходимо **взаимодействие с оператором** — оператор должен сообщить, в какие порты и IP-адреса абонент был транслирован.
+
+## 24.3. Проверка ресурса в DPI-листах: `show dpi match`
+
+Команда `show dpi match` позволяет проверить, находится ли конкретный ресурс в списках блокировки:
+
+```text
+    # show dpi match <ресурс>
+```
+
+Где `<ресурс>` — это IP-адрес или URL.
+
+Команда проверяет указанный ресурс **по всем DPI-листам** и выводит информацию о совпадениях:
+
+| Результат                          | Значение                                                     |
+| ---------------------------------- | ------------------------------------------------------------ |
+| Совпадение найдено в DPI-листе N   | Ресурс присутствует в списке — указано, в каком именно DPI-листе и какое действие (block/ignore/redirect) |
+| Совпадений не найдено              | Ресурс отсутствует во всех DPI-листах — ТСПУ его не блокирует по спискам |
+
+> **Примечание:** команда `show dpi match` может быть недоступна в старых версиях прошивки. В актуальных прошивках федерального проекта она присутствует.
+
+### Проверка через ЦСУ
+
+Если необходимо проверить наличие ресурса в списках, загруженных на **Eco Highway** (эшелонированная система), проверку следует выполнять **через центральную систему управления** — там хранятся все списки, загружаемые по BGP.
+
+## 24.4. Программный байпас для исключения ТСПУ как причины проблемы
+
+Один из ключевых методов диагностики — **исключение ТСПУ** из пути прохождения трафика, чтобы определить, является ли ТСПУ причиной проблемы.
+
+### Программный bypass на балансировщике
+
+Наиболее удобный способ — программный bypass на балансировщике (см. [раздел 22.7](22.md)):
+
+```text
+    call balance-group <группа> software-bypass bypass
+```
+
+Преимущества:
+
+- **Нет флапов линков** — оператор ничего не замечает;
+- **Гранулярность** — можно байпасить отдельные filter groups;
+- **Мгновенность** — переключение происходит немедленно.
+
+### Bypass по правилам фильтрации (flow rules)
+
+Альтернативный вариант — создать на балансировщике **временное правило** с action `bypass` для конкретного трафика:
+
+```text
+    set filters main flows diag-bypass match vlan 0 id <номер_VLAN>
+    set filters main flows diag-bypass action bypass
+    set filters main flows diag-bypass priority 200
+    apply
+```
+
+Это позволяет исключить из обработки только **конкретный VLAN** или подсеть, не затрагивая остальной трафик. По статистике правила (пакеты/байты) можно убедиться, что трафик действительно проходит (см. [раздел 22.5](22.md)).
+
+### Bypass на оптическом байпасе
+
+Переключение оптического байпаса в режим bypass/TAP — более радикальный метод, который **вызывает флапы линков** у оператора. Используется в крайнем случае и, как правило, требует согласования с оператором.
+
+### Интерпретация результатов
+
+| После bypass                     | Интерпретация                                                |
+| -------------------------------- | ------------------------------------------------------------ |
+| Проблема **исчезла**             | ТСПУ являлось причиной — диагностировать дальше на уровне фильтров/DPI |
+| Проблема **осталась**            | ТСПУ не является причиной — проблема на стороне ресурса, оператора или абонента |
+
+## 24.5. Исключение абонента из обработки: параметр No IP
+
+Для точечной диагностики на уровне **конкретного абонента** используется параметр **No IP** в настройках DPI-листа (см. [раздел 17.4.8](17.md)).
+
+### No IP (исключение по локальному адресу)
+
+Параметр `No IP` исключает **локальный адрес абонента** из обработки конкретным DPI-листом:
+
+```text
+    # system dpi lists <N> no-ip <IP-адрес_абонента>
+    # apply
+```
+
+Это означает, что трафик данного абонента будет проходить через фильтр, но **конкретный DPI-лист** не будет его обрабатывать.
+
+### No IP Remote (исключение по удалённому адресу)
+
+Параметр `No IP Remote` исключает **удалённый IP-адрес** (адрес сервера/ресурса) из обработки:
+
+```text
+    # system dpi lists <N> no-ip-remote <IP-адрес_ресурса>
+    # apply
+```
+
+### Диагностический алгоритм
+
+```text
+    1. Добавить абонента в No IP конкретного DPI-листа
+           │
+    2. Применить конфигурацию (apply)
+           │
+    3. Попросить абонента повторить действие
+           │
+    ┌──────┴──────┐
+    │             │
+    ▼             ▼
+  Проблема     Проблема
+  исчезла      осталась
+    │             │
+    ▼             ▼
+  Данный       Данный DPI-лист
+  DPI-лист     НЕ влияет на
+  ВЛИЯЕТ на    абонента —
+  абонента     проверить
+               другие листы
+```
+
+> **Приоритет:** параметр `No IP` имеет **приоритет** над параметром `IP`. Если адрес указан и в No IP (исключение), и в IP (включение), сработает **исключение** — адрес не будет обрабатываться.
+
+### Возврат после диагностики
+
+После завершения диагностики необходимо **удалить** добавленные записи No IP и применить конфигурацию.
+
+## 24.6. Перепутки LAN/WAN и их диагностика
+
+**Перепутка LAN/WAN** — ситуация, когда порты LAN и WAN подключены **наоборот**: LAN-порт подключён в сторону интернета, а WAN-порт — в сторону абонентов.
+
+### Как распознать перепутку
+
+Основной признак — при просмотре сессий на фильтре в поле **local** отображаются адреса, которые **не являются абонентскими**:
+
+- Вместо серых (приватных) абонентских адресов в local видны белые интернет-адреса;
+- Направление сессий (Egress/Ingress) не соответствует ожидаемому.
+
+Это происходит потому, что фильтр определяет направление трафика по портам: трафик, приходящий в LAN-порт, считается абонентским, а source IP записывается как local. Если LAN и WAN перепутаны, source IP интернет-хоста ошибочно записывается как local.
+
+> **Ключевой принцип:** локальный (абонентский) IP-адрес **всегда записывается на первое место** в сессии (см. [раздел 12.5](12.md)). Если на первом месте оказался интернет-адрес — порты перепутаны.
+
+### Где может произойти перепутка
+
+| Место                          | Описание                                                    |
+| ------------------------------ | ----------------------------------------------------------- |
+| **На байпасе**                 | Кабели LAN и WAN подключены к неправильным портам байпаса   |
+| **На балансировщике**          | Порты в линке назначены неверно (LAN вместо WAN и наоборот) |
+| **На коммутаторе оператора**   | Кабели между оператором и байпасом подключены неверно       |
+
+### Последствия перепутки
+
+При перепутке LAN/WAN:
+
+- Фильтр **некорректно определяет направление** трафика;
+- DPI-обработка может работать **неправильно** (блокировка не того, что нужно);
+- Сессии и трансляции формируются **неверно**;
+- Connection logging записывает **некорректные данные**.
+
+### Диагностика
+
+1. Выполнить `show session` и проверить поле local — должны быть абонентские (серые) адреса;
+2. Если в local видны белые адреса — вероятна перепутка;
+3. Проверить физическое подключение кабелей;
+4. Проверить конфигурацию линков на балансировщике.
+
+## 24.7. Взаимодействие с оператором связи
+
+Эффективная диагностика часто требует **совместной работы** с оператором связи и конечным абонентом:
+
+### Когда необходимо взаимодействие
+
+| Ситуация                                   | Что нужно от оператора/абонента                          |
+| ------------------------------------------ | -------------------------------------------------------- |
+| Проблема существует **прямо сейчас**        | Абонент генерирует трафик, а инженер ТСПУ анализирует сессии в реальном времени |
+| ТСПУ установлен **после CGNAT**            | Оператор сообщает транслированные адреса для поиска сессий |
+| Проблема с **конкретным ресурсом**          | Абонент уточняет URL, IP-адрес, порт, тип приложения     |
+| Подозрение на проблему **на стороне оператора** | Оператор проверяет свою часть сети (маршрутизация, CGNAT, BRAS) |
+
+### Рекомендации по взаимодействию
+
+**С корпоративными клиентами:** как правило, корпоративные клиенты заинтересованы в решении проблемы и готовы к сотрудничеству — совместному моделированию ситуации в реальном времени. Это наиболее эффективный сценарий диагностики.
+
+**С частными абонентами:** частный абонент, столкнувшийся с проблемой, может просто уйти и не возвращаться к ресурсу. Диагностика постфактум без сохранённых логов практически невозможна.
+
+**С оператором:** при переключениях bypass/primary необходимо **согласовывать работы** с оператором, так как переключение оптического байпаса вызывает флапы линков. Программный bypass на балансировщике не требует такого согласования.
+
+## 24.8. Ограничения: L2-устройство, невозможность генерации трафика с фильтра
+
+Фильтр ТСПУ — это устройство **уровня L2** (Layer 2). Это накладывает принципиальные ограничения на возможности диагностики:
+
+### Невозможность генерации трафика
+
+На фильтре **нет IP-интерфейсов** в data plane, с которых можно было бы инициировать трафик. Это означает:
+
+- **Невозможно** отправить тестовый пакет «от имени абонента» через фильтр;
+- **Невозможно** «скрафтить» пакет с заданными source/destination и пропустить его через DPI;
+- **Невозможно** повторить ситуацию абонента изнутри фильтра.
+
+> **Ping и traceroute** доступны на фильтре, но они работают через **management-интерфейс**, а не через data plane. Ping позволяет проверить связь management-интерфейса со шлюзом или с внешними хостами (если есть маршрутизация), но **не моделирует** прохождение абонентского трафика через фильтр.
+
+### Невозможность перехвата трафика
+
+Фильтр не может захватить копию трафика (аналог tcpdump) — он только обрабатывает пакеты, проходящие через него, и предоставляет **агрегированную статистику** (сессии, счётчики, DPI-состояние).
+
+### Практические следствия
+
+| Что **можно** сделать                        | Что **нельзя** сделать                               |
+| -------------------------------------------- | ---------------------------------------------------- |
+| Найти сессии абонента (`show session`)        | Сгенерировать тестовый трафик через data plane        |
+| Проверить ресурс в DPI-листах (`show dpi match`) | Захватить дамп трафика (tcpdump)                 |
+| Исключить абонента из обработки (No IP)       | Повторить проблему абонента изнутри фильтра          |
+| Включить программный bypass                   | Инициировать соединение к ресурсу через фильтр       |
+| Посмотреть статистику и счётчики              | Проанализировать содержимое конкретного пакета        |
+| Ping/traceroute через management-интерфейс    | Ping/traceroute через data plane                     |
+
+Именно поэтому для эффективной диагностики часто необходимо **совместное моделирование** ситуации в реальном времени: абонент генерирует трафик, а инженер ТСПУ анализирует, как этот трафик проходит через систему.
+
+---
+
+[← Оглавление](../README.md) · [← Раздел 23: Распознавание протоколов (DPI Engine)](23.md)