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