Browse Source
- Раздел 22: Балансировщик: мониторинг и диагностика - Раздел 23: Распознавание протоколов (DPI Engine) - Раздел 24: Траблшутинг Каждый раздел включает команды, описания и практические примеры для диагностики и мониторинга работы балансировщика и системы фильтрации.pull/1/head
Daniel Lavrushin
8 months ago
25 changed files with 801 additions and 68 deletions
@ -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) |
|||
@ -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) |
|||
@ -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) |
|||
Loading…
Reference in new issue