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

- Раздел 22: Балансировщик: мониторинг и диагностика
- Раздел 23: Распознавание протоколов (DPI Engine)
- Раздел 24: Траблшутинг

Каждый раздел включает команды, описания и практические примеры для диагностики и мониторинга работы балансировщика и системы фильтрации.
This commit is contained in:
Daniel Lavrushin
2026-02-20 13:59:30 +01:00
parent f1d391ccf3
commit 10fb7f4e18
25 changed files with 801 additions and 68 deletions

306
chapters/24.md Normal file
View File

@@ -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)