DanielLavrushin_tspu-docs/docs/troubleshooting.md

# 23. Траблшутинг

[← Оглавление](../README.md) · [← Раздел 22: Распознавание протоколов и двухстадийная блокировка](protocol-blocking.md)

---

Диагностика проблем на ТСПУ — комплексная задача, требующая понимания архитектуры системы, принципов прохождения трафика и взаимодействия компонентов. В данном разделе описаны типовые подходы к траблшутингу, которые применяются при обращениях операторов связи и абонентов.

## 23.1. Общий подход к диагностике проблем доступности

При обращении оператора или абонента с жалобой на недоступность ресурса необходимо последовательно пройти несколько шагов:

```text
    1. Уточнить детали проблемы
           │
    2. Определить, есть ли проблема прямо сейчас (или была вчера)
           │
    3. Найти сессии абонента на фильтрах
           │
    4. Проверить ресурс в DPI-листах
           │
    5. Исключить ТСПУ как причину (bypass / No IP)
           │
    6. Локализовать проблему
```

### Шаг 1: Уточнение деталей

Всегда необходимо **выяснять подробности** у абонента или оператора. Формулировка «ресурс недоступен» может означать совершенно разные вещи:

| Жалоба абонента              | Что это может означать на самом деле                      |
| ---------------------------- | --------------------------------------------------------- |
| «Сайт не открывается»       | Полная блокировка, ошибка DNS, проблема на стороне сервера |
| «Всё тормозит»              | Деградация протокола, перегрузка канала, проблема на стороне оператора |
| «Часть сайта не работает»   | Блокировка отдельных ресурсов (CDN, API), проблема с HTTPS |
| «Приложение не подключается»| Блокировка протокола, обновление приложения, проблема с обфускацией |

> **Статистика:** по опыту эксплуатации, примерно в **80% случаев** проблема связана **не с ТСПУ**, а с самим ресурсом, абонентом или оператором связи. Однако всегда необходимо проверять и исключать влияние ТСПУ.

### Шаг 2: Актуальность проблемы

**Диагностика постфактум крайне затруднена.** Если абонент сообщает о проблеме, которая была вчера, а сегодня её нет, — возможности анализа ограничены:

- Если сохранились **логи соединений** за нужный период — можно проанализировать, были ли сессии к проблемному ресурсу;
- Если логов нет — восстановить картину практически невозможно.

**Если проблема существует прямо сейчас** — шансы на успешную диагностику значительно выше. В этом случае важно работать **в реальном времени** совместно с абонентом или оператором.

## 23.2. Поиск сессии абонента: обход фильтров площадки

Первый практический шаг — **найти сессии** конкретного абонента к конкретному ресурсу на фильтрах площадки.

Балансировщик не ведёт журнала распределения и не сообщает, на какой фильтр отправлена сессия ([раздел 6.5.4](balancer.md)), поэтому поиск выполняется на каждом фильтре площадки — вручную или простым скриптом. Оба направления сессии всегда находятся на одном и том же фильтре.

### Поиск по локальному адресу

Для поиска сессий используется команда `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](filter-sessions.md)). Независимо от направления трафика, IP-адрес абонента записывается в поле local. Если в поле local отображаются адреса, которые не являются абонентскими (интернет-адреса), — это признак перепутки LAN/WAN (см. раздел 23.6).

### Особенности при установке после CGNAT

Если ТСПУ установлен **после CGNAT** (см. [раздел 3.3.1](placement.md)), на фильтре видны только белые (транслированные) адреса. Для идентификации конкретного абонента необходимо **взаимодействие с оператором** — оператор должен по журналам трансляций CGNAT сообщить, в какой адрес и какие порты абонент был транслирован в нужный момент времени.

## 23.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.

## 23.4. Программный байпас для исключения ТСПУ как причины проблемы

Один из ключевых методов диагностики — **исключение ТСПУ** из пути прохождения трафика, чтобы определить, является ли ТСПУ причиной проблемы.

### Программный bypass на балансировщике

Наиболее удобный способ — программный bypass на балансировщике (см. [раздел 9.7](balancer-monitoring.md)):

```text
    call ecofilter-balancer set-bypass-ecofilter-unit unit <группа> bypass
```

Преимущества:

- **Нет флапов линков** — оператор ничего не замечает;
- **Гранулярность** — отдельные filter groups байпасятся автоматически по keep-alive, вручную переключается группа балансировки целиком ([раздел 6.6.2](balancer.md));
- **Мгновенность** — переключение происходит немедленно.

### 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** или подсеть, не затрагивая остальной трафик. По статистике правила (пакеты/байты) можно убедиться, что трафик действительно проходит (см. [раздел 9.5](balancer-monitoring.md)).

### Bypass на оптическом байпасе

Переключение на самом байпасе — более радикальный метод: он полностью снимает канал с фильтрации. У байпасов **Silicom** перевод сегмента в TAP или Active Bypass выполняется **без флапа линков** оператора — теряются лишь пакеты, находившиеся в этот момент внутри ТСПУ (см. [раздел 5.2.6](bypass.md)). У оптических байпасов **GL Sun** любое переключение **вызывает флапы линков** и, как правило, требует согласования с оператором (см. [раздел 5.3.2](bypass.md)).

### Интерпретация результатов

| После bypass                     | Интерпретация                                                |
| -------------------------------- | ------------------------------------------------------------ |
| Проблема **исчезла**             | ТСПУ являлось причиной — диагностировать дальше на уровне фильтров/DPI |
| Проблема **осталась**            | ТСПУ не является причиной — проблема на стороне ресурса, оператора или абонента |

## 23.5. Исключение абонента из обработки: параметр No IP

Для точечной диагностики на уровне **конкретного абонента** используется параметр **No IP** в настройках DPI-листа (см. [раздел 17.4.8](filter-dpi.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 и применить конфигурацию.

## 23.6. Перепутки LAN/WAN и их диагностика

**Перепутка LAN/WAN** — ситуация, когда порты LAN и WAN подключены **наоборот**: LAN-порт подключён в сторону интернета, а WAN-порт — в сторону абонентов.

### Как распознать перепутку

Основной признак — при просмотре сессий на фильтре в поле **local** отображаются адреса, которые **не являются абонентскими**:

- в local видны адреса интернет-ресурсов, а не адреса абонентов оператора (серые — или белые адреса NAT-пула, если ТСПУ стоит после CGNAT, [раздел 3.3.1](placement.md));
- Направление сессий (Egress/Ingress) не соответствует ожидаемому.

Это происходит потому, что фильтр определяет направление трафика по портам: трафик, приходящий в LAN-порт, считается абонентским, а source IP записывается как local. Если LAN и WAN перепутаны, source IP интернет-хоста ошибочно записывается как local.

> **Ключевой принцип:** локальный (абонентский) IP-адрес **всегда записывается на первое место** в сессии (см. [раздел 12.5](filter-sessions.md)). Если на первом месте оказался интернет-адрес — порты перепутаны.

### Где может произойти перепутка

| Место                        | Описание                                                                                                                                                                                 |
| ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **На байпасе**               | Кабели LAN и WAN подключены к неправильным портам байпаса                                                                                                                                |
| **На балансировщике**        | Порты в линке назначены неверно (LAN вместо WAN и наоборот)                                                                                                                              |
| **На коммутаторе оператора** | Кабели между оператором и байпасом подключены неверно                                                                                                                                    |
| **Канал on-a-stick**         | Участки до и после BRAS/CGNAT не разделены: трафик одного из них проходит через ТСПУ в обратной ориентации — это следствие схемы, а не ошибка подключения ([раздел 3.4.1](placement.md)) |

### Последствия перепутки

При перепутке LAN/WAN:

- Фильтр **некорректно определяет направление** трафика;
- DPI-обработка может работать **неправильно** (блокировка не того, что нужно);
- Сессии и трансляции формируются **неверно**;
- Connection logging записывает **некорректные данные**.

### Диагностика

1. Выполнить `show session` и проверить поле local — должны быть адреса абонентов оператора (серые или, после CGNAT, адреса NAT-пула);
2. Если в local видны адреса интернет-ресурсов — вероятна перепутка;
3. Проверить физическое подключение кабелей;
4. Проверить конфигурацию линков на балансировщике.

## 23.7. Взаимодействие с оператором связи

Эффективная диагностика часто требует **совместной работы** с оператором связи и конечным абонентом:

### Когда необходимо взаимодействие

| Ситуация                                   | Что нужно от оператора/абонента                          |
| ------------------------------------------ | -------------------------------------------------------- |
| Проблема существует **прямо сейчас**        | Абонент генерирует трафик, а инженер ТСПУ анализирует сессии в реальном времени |
| ТСПУ установлен **после CGNAT**            | Оператор сообщает транслированные адреса для поиска сессий |
| Проблема с **конкретным ресурсом**          | Абонент уточняет URL, IP-адрес, порт, тип приложения     |
| Подозрение на проблему **на стороне оператора** | Оператор проверяет свою часть сети (маршрутизация, CGNAT, BRAS) |

### Рекомендации по взаимодействию

**С корпоративными клиентами:** как правило, корпоративные клиенты заинтересованы в решении проблемы и готовы к сотрудничеству — совместному моделированию ситуации в реальном времени. Это наиболее эффективный сценарий диагностики.

**С частными абонентами:** частный абонент, столкнувшийся с проблемой, может просто уйти и не возвращаться к ресурсу. Диагностика постфактум без сохранённых логов практически невозможна.

**С оператором:** при переключениях bypass/primary необходимо **согласовывать работы** с оператором, так как переключение оптического байпаса вызывает флапы линков. Программный bypass на балансировщике не требует такого согласования.

## 23.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) · [← Раздел 22: Распознавание протоколов и двухстадийная блокировка](protocol-blocking.md)