From 10fb7f4e185d569526f97846399417ca67fbc018 Mon Sep 17 00:00:00 2001 From: Daniel Lavrushin Date: Fri, 20 Feb 2026 13:59:30 +0100 Subject: [PATCH] =?UTF-8?q?=D0=94=D0=BE=D0=B1=D0=B0=D0=B2=D0=BB=D0=B5?= =?UTF-8?q?=D0=BD=D1=8B=20=D0=BD=D0=BE=D0=B2=D1=8B=D0=B5=20=D1=80=D0=B0?= =?UTF-8?q?=D0=B7=D0=B4=D0=B5=D0=BB=D1=8B:=20-=20=D0=A0=D0=B0=D0=B7=D0=B4?= =?UTF-8?q?=D0=B5=D0=BB=2022:=20=D0=91=D0=B0=D0=BB=D0=B0=D0=BD=D1=81=D0=B8?= =?UTF-8?q?=D1=80=D0=BE=D0=B2=D1=89=D0=B8=D0=BA:=20=D0=BC=D0=BE=D0=BD?= =?UTF-8?q?=D0=B8=D1=82=D0=BE=D1=80=D0=B8=D0=BD=D0=B3=20=D0=B8=20=D0=B4?= =?UTF-8?q?=D0=B8=D0=B0=D0=B3=D0=BD=D0=BE=D1=81=D1=82=D0=B8=D0=BA=D0=B0=20?= =?UTF-8?q?-=20=D0=A0=D0=B0=D0=B7=D0=B4=D0=B5=D0=BB=2023:=20=D0=A0=D0=B0?= =?UTF-8?q?=D1=81=D0=BF=D0=BE=D0=B7=D0=BD=D0=B0=D0=B2=D0=B0=D0=BD=D0=B8?= =?UTF-8?q?=D0=B5=20=D0=BF=D1=80=D0=BE=D1=82=D0=BE=D0=BA=D0=BE=D0=BB=D0=BE?= =?UTF-8?q?=D0=B2=20(DPI=20Engine)=20-=20=D0=A0=D0=B0=D0=B7=D0=B4=D0=B5?= =?UTF-8?q?=D0=BB=2024:=20=D0=A2=D1=80=D0=B0=D0=B1=D0=BB=D1=88=D1=83=D1=82?= =?UTF-8?q?=D0=B8=D0=BD=D0=B3?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Каждый раздел включает команды, описания и практические примеры для диагностики и мониторинга работы балансировщика и системы фильтрации. --- README.md | 48 +++---- 01.md => chapters/01.md | 8 +- 02.md => chapters/02.md | 4 +- 03.md => chapters/03.md | 4 +- 04.md => chapters/04.md | 4 +- 05.md => chapters/05.md | 4 +- 06.md => chapters/06.md | 4 +- 07.md => chapters/07.md | 4 +- 08.md => chapters/08.md | 4 +- 09.md => chapters/09.md | 4 +- 10.md => chapters/10.md | 4 +- 11.md => chapters/11.md | 4 +- 12.md => chapters/12.md | 4 +- 13.md => chapters/13.md | 4 +- 14.md => chapters/14.md | 4 +- 15.md => chapters/15.md | 4 +- 16.md => chapters/16.md | 4 +- 17.md => chapters/17.md | 4 +- 18.md => chapters/18.md | 4 +- 19.md => chapters/19.md | 4 +- 20.md => chapters/20.md | 4 +- 21.md => chapters/21.md | 4 +- chapters/22.md | 262 ++++++++++++++++++++++++++++++++++ chapters/23.md | 165 ++++++++++++++++++++++ chapters/24.md | 306 ++++++++++++++++++++++++++++++++++++++++ 25 files changed, 801 insertions(+), 68 deletions(-) rename 01.md => chapters/01.md (96%) rename 02.md => chapters/02.md (98%) rename 03.md => chapters/03.md (98%) rename 04.md => chapters/04.md (99%) rename 05.md => chapters/05.md (98%) rename 06.md => chapters/06.md (98%) rename 07.md => chapters/07.md (98%) rename 08.md => chapters/08.md (98%) rename 09.md => chapters/09.md (96%) rename 10.md => chapters/10.md (96%) rename 11.md => chapters/11.md (97%) rename 12.md => chapters/12.md (97%) rename 13.md => chapters/13.md (97%) rename 14.md => chapters/14.md (98%) rename 15.md => chapters/15.md (97%) rename 16.md => chapters/16.md (97%) rename 17.md => chapters/17.md (99%) rename 18.md => chapters/18.md (98%) rename 19.md => chapters/19.md (95%) rename 20.md => chapters/20.md (97%) rename 21.md => chapters/21.md (98%) create mode 100644 chapters/22.md create mode 100644 chapters/23.md create mode 100644 chapters/24.md diff --git a/README.md b/README.md index e4637bb..97843f3 100644 --- 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. Поиск сессии абонента: обход фильтров площадки diff --git a/01.md b/chapters/01.md similarity index 96% rename from 01.md rename to chapters/01.md index e681061..1740aa9 100644 --- a/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) diff --git a/02.md b/chapters/02.md similarity index 98% rename from 02.md rename to chapters/02.md index cbfdf50..59caff3 100644 --- a/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) diff --git a/03.md b/chapters/03.md similarity index 98% rename from 03.md rename to chapters/03.md index 08d76e9..a668fec 100644 --- a/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) diff --git a/04.md b/chapters/04.md similarity index 99% rename from 04.md rename to chapters/04.md index d04f6ef..02c0526 100644 --- a/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) diff --git a/05.md b/chapters/05.md similarity index 98% rename from 05.md rename to chapters/05.md index 9a18a22..c30de72 100644 --- a/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) diff --git a/06.md b/chapters/06.md similarity index 98% rename from 06.md rename to chapters/06.md index 327a21b..cac03b5 100644 --- a/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) diff --git a/07.md b/chapters/07.md similarity index 98% rename from 07.md rename to chapters/07.md index 6e9d844..0b51a13 100644 --- a/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) diff --git a/08.md b/chapters/08.md similarity index 98% rename from 08.md rename to chapters/08.md index f0af588..092846b 100644 --- a/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) diff --git a/09.md b/chapters/09.md similarity index 96% rename from 09.md rename to chapters/09.md index 036d273..b746b1c 100644 --- a/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) diff --git a/10.md b/chapters/10.md similarity index 96% rename from 10.md rename to chapters/10.md index 832f131..510e314 100644 --- a/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) diff --git a/11.md b/chapters/11.md similarity index 97% rename from 11.md rename to chapters/11.md index fdc5196..6df9411 100644 --- a/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) diff --git a/12.md b/chapters/12.md similarity index 97% rename from 12.md rename to chapters/12.md index c409279..169dea7 100644 --- a/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) diff --git a/13.md b/chapters/13.md similarity index 97% rename from 13.md rename to chapters/13.md index 3205983..7710171 100644 --- a/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) diff --git a/14.md b/chapters/14.md similarity index 98% rename from 14.md rename to chapters/14.md index e6f377e..c254753 100644 --- a/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) diff --git a/15.md b/chapters/15.md similarity index 97% rename from 15.md rename to chapters/15.md index a15c5d8..0bc13a5 100644 --- a/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) diff --git a/16.md b/chapters/16.md similarity index 97% rename from 16.md rename to chapters/16.md index 79d3569..5db3619 100644 --- a/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) diff --git a/17.md b/chapters/17.md similarity index 99% rename from 17.md rename to chapters/17.md index 2a89db5..8c8a4aa 100644 --- a/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) diff --git a/18.md b/chapters/18.md similarity index 98% rename from 18.md rename to chapters/18.md index 8a86fc3..efe6cf5 100644 --- a/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) diff --git a/19.md b/chapters/19.md similarity index 95% rename from 19.md rename to chapters/19.md index 3c4eb44..5ee6da5 100644 --- a/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) diff --git a/20.md b/chapters/20.md similarity index 97% rename from 20.md rename to chapters/20.md index efff6f2..6f67834 100644 --- a/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) diff --git a/21.md b/chapters/21.md similarity index 98% rename from 21.md rename to chapters/21.md index 0952f9f..f3fce80 100644 --- a/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) diff --git a/chapters/22.md b/chapters/22.md new file mode 100644 index 0000000..5a52051 --- /dev/null +++ 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) diff --git a/chapters/23.md b/chapters/23.md new file mode 100644 index 0000000..91d8e43 --- /dev/null +++ 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) diff --git a/chapters/24.md b/chapters/24.md new file mode 100644 index 0000000..3f727bf --- /dev/null +++ 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 :<порт> | more +``` + +Или для просмотра всех сессий абонента: + +```text + > show session la | more +``` + +Для подсчёта количества сессий: + +```text + > show session la | count +``` + +### Поиск по удалённому адресу + +Если известен IP-адрес ресурса, к которому обращается абонент: + +```text + > show session ra | 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 no-ip + # apply +``` + +Это означает, что трафик данного абонента будет проходить через фильтр, но **конкретный DPI-лист** не будет его обрабатывать. + +### No IP Remote (исключение по удалённому адресу) + +Параметр `No IP Remote` исключает **удалённый IP-адрес** (адрес сервера/ресурса) из обработки: + +```text + # system dpi lists no-ip-remote + # 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)