tspu-docs/chapters/24.md

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

← Оглавление · ← Раздел 23: Распознавание протоколов (DPI Engine)

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для поиска сессий используется команда show session с фильтрацией по локальному адресу абонента:

    > show session la <IP-адрес_абонента>:<порт> | more

Или для просмотра всех сессий абонента:

    > show session la <IP-адрес_абонента> | more

Для подсчёта количества сессий:

    > show session la <IP-адрес_абонента> | count

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

Если известен IP-адрес ресурса, к которому обращается абонент:

    > show session ra <IP-адрес_ресурса> | more

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

Результат	Интерпретация
Сессии найдены	Трафик абонента проходит через фильтр — ТСПУ его видит
Сессии не найдены	Трафик не проходит через данный фильтр — абонент идёт другим путём, либо проблема до ТСПУ
Сессии есть, но ресурс недоступен	Возможна блокировка на уровне DPI — проверить DPI-листы

Важно: при поиске сессий помните принцип «локальный адрес всегда на первом месте» (см. раздел 12). Независимо от направления трафика, IP-адрес абонента записывается в поле local. Если в поле local отображаются адреса, которые не являются абонентскими (интернет-адреса), — это признак перепутки LAN/WAN (см. раздел 24.6).

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

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

24.3. Проверка ресурса в DPI-листах: show dpi match

Команда show dpi match позволяет проверить, находится ли конкретный ресурс в списках блокировки:

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

    call balance-group <группа> software-bypass bypass

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

• Нет флапов линков — оператор ничего не замечает;
• Гранулярность — можно байпасить отдельные filter groups;
• Мгновенность — переключение происходит немедленно.

Bypass по правилам фильтрации (flow rules)

Альтернативный вариант — создать на балансировщике временное правило с action bypass для конкретного трафика:

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

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

Переключение оптического байпаса в режим bypass/TAP — более радикальный метод, который вызывает флапы линков у оператора. Используется в крайнем случае и, как правило, требует согласования с оператором.

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

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

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

Для точечной диагностики на уровне конкретного абонента используется параметр No IP в настройках DPI-листа (см. раздел 17.4.8).

No IP (исключение по локальному адресу)

Параметр No IP исключает локальный адрес абонента из обработки конкретным DPI-листом:

    # system dpi lists <N> no-ip <IP-адрес_абонента>
    # apply

Это означает, что трафик данного абонента будет проходить через фильтр, но конкретный DPI-лист не будет его обрабатывать.

No IP Remote (исключение по удалённому адресу)

Параметр No IP Remote исключает удалённый IP-адрес (адрес сервера/ресурса) из обработки:

    # system dpi lists <N> no-ip-remote <IP-адрес_ресурса>
    # apply

Диагностический алгоритм

    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). Если на первом месте оказался интернет-адрес — порты перепутаны.

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

Место	Описание
На байпасе	Кабели 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

Именно поэтому для эффективной диагностики часто необходимо совместное моделирование ситуации в реальном времени: абонент генерирует трафик, а инженер ТСПУ анализирует, как этот трафик проходит через систему.

---

← Оглавление · ← Раздел 23: Распознавание протоколов (DPI Engine)