10fb7f4e18
- Раздел 22: Балансировщик: мониторинг и диагностика - Раздел 23: Распознавание протоколов (DPI Engine) - Раздел 24: Траблшутинг Каждый раздел включает команды, описания и практические примеры для диагностики и мониторинга работы балансировщика и системы фильтрации.
307 lines
24 KiB
Markdown
307 lines
24 KiB
Markdown
# 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)
|