Диагностика трафика в USG выполняется с помощью различных инструментов.

Инструменты – это разделы, предоставляющие функции анализа, тестирования и диагностики трафика или конфигурации сетевого экрана с целью выявления и устранения сетевых проблем.

Все доступные инструменты можно найти в центре диагностики.

Diagnostic Center – центр диагностики. Это раздел, предназначенный для диагностики работы USG и прохождения сетевого трафика. Он объединяет инструменты, позволяющие выполнять тесты, анализировать пакеты, проверять сессии, маршруты, безопасность и состояние интерфейсов. Используется для поиска причин недоступности ресурсов, анализа прохождения трафика, проверки работы туннелей, политик и маршрутов, выявления конфигурационных ошибок.

В центр диагностики можно сгруппировать все доступные инструмент в виде дополнительных вкладок при нажатии на вкладку +. Ниже представлено краткое назначение доступных инструментов.

IPSec Diagnosis – проверка состояния IPSec-туннелей: фазы I/II, параметры SA, алгоритмы, ошибки и статус установления.

Packet Tracing – пошаговое отслеживание, как устройство обрабатывает пакет: к каким политикам он применяется, где блокируется или разрешается.

Ping – отправка ICMP-запросов для проверки доступности узлов.

Traceroute – проверка маршрута до узла, определение «прыжков» и мест, где происходит потеря или задержка.

Diagnosis Information — сводная диагностическая информация: состояние системы, таблицы, конфигурационные данные, полезные для быстрой оценки проблем.

Session Table – просмотр текущих сессий: параметры соединений, порты, протоколы, таймеры, объём переданного трафика.

Web Page Diagnosis – проверка доступности веб-страниц, HTTP/HTTPS-ответов, задержек и ошибок веб-доступа.

Top Sessions – вывод наиболее активных сессий по объёму трафика, количеству пакетов или другим показателям.

Routing Table – просмотр активной таблицы маршрутизации: статические маршруты, динамические протоколы, next-hop, приоритеты.

5-Tuple Packet Capture – захват пакетов для анализа на основе 5-туплета: позволяет видеть реальные пакеты, проходящие через устройство.

5-Tuple Packet Statistics – статистика пакетов по 5-туплету: количество, направления, сбросы.

Security Policy – просмотр работающих политик безопасности и их параметров.

Interface Status – состояние интерфейсов: скорость, дуплекс, ошибки, статистика входящего/исходящего трафика.

Использование этих инструментов рассмотрено далее.

 

PING.

Самое простое и понятное средство. Вводим IP-адрес назначения и нажимаем кнопку Ping. Получаем информацию о доступности или не доступности ресурса.

С помощью пинга можно проверить наличие доступа в Интернет или к локальному ресурсу. Кроме этого пинг показывает задержку (RTT – round-trip time), потери пакетов, работу маршрута и интерфейсов, корректность настроек политик безопасности, работу ARP (для локальной сети). Фактически это базовый тест сетевой связности.

Ниже перечислены самые распространённые ответы пинга в USG при проблемах:

Request time out – узел не ответил в установленное время.
Причины: нет маршрута, устройство недоступно, ICMP блокируется политиками или ACL, проблема на канале связи, ARP не получил MAC-адрес (если это локальный сегмент).

Destination host unreachable – хост назначения недоступен. USG не знает, куда отправить пакет.
Причины: отсутствует маршрут до подсети, ошибочный next-hop, интерфейс down.

Destination network unreachable – сеть назначения недоступна. Маршрутизатор по пути сообщает, что сети нет.
Причины: проблема в промежуточном узле, маршрут пропал в динамическом протоколе.

Unknown host – не корректный адрес.

При строгом файерволе необходимо создавать отдельное правило политики безопасности разрешающее ICMP во всех направлениях, и/или разрешить пинг на интерфейсе.

 

TRACEROUTE.

Данный инструмент показывает IP-адрес каждого узла, через который проходит тестовый пакет.

Принцип работы traceroute в пошаговом уменьшении TTL. Traceroute определяет маршрут до удалённого узла, отправляя последовательность пакетов с постепенно увеличивающимся TTL (Time To Live). Каждый маршрутизатор на пути уменьшает TTL на 1. Когда TTL пакета достигает 0, маршрутизатор должен отправить ICMP Time Exceeded (Type 11). USG фиксирует ответы (или их отсутствие) и строит карту маршрута.

Если звездочки уже с первой строчки, то либо нет маршрута, либо запрет политикой безопасности, что чаще всего, особенно если пинг проходит.

На Huawei USG traceroute по умолчанию использует UDP-пакеты. Поэтому при строгих правилах, когда всё запрещено, чтоб трассировка заработала нужно разрешать UDP из local в untrust для портов 33434–33534. Например так.

 

После этого трассировка начинает работать.

 

PACKET TRACING.

Packet Tracing – это инструмент пошагового анализа прохождения пакета через USG. Он позволяет увидеть, какие правила, политики и маршруты применяются к пакету, определяет, почему пакет был разрешён или заблокирован, отслеживает прохождение через интерфейсы, NAT, firewall, маршрутизацию, IPS, диагностирует проблемы с трафиком, сетевыми службами и политиками безопасности. По сути Packet Tracing показывает виртуальный след пакета внутри сетевого экрана.

Для простого примера представлена диагностика по ICMP.

Tracing: Constructed packets – создаётся тестовый пакет, а не используется реальный трафик.

Packet Type: IPv4

Inbound Interface: LAG-1 – входящий интерфейс (реальный агрегированный интерфейс на котором локальная сеть).

Protocol: ICMP (ping).

Source IP: 192.168.1.10 – IP-адрес источника.

Destination IP: 8.8.8.8 – IP-адрес назначения.

 

Вводим параметры и нажимаем кнопку Diagnose.

Кнопка Export выводит детальный лог обработки пакета.

 

Diagnosis Result: The packet was sent successfully – сообщается, что пакет успешно прошёл все этапы внутри устройства.

При нажатии кнопки-ссылки [ViewFlowchart] открывается диаграмма движения трафика.

Packet Processing Flowchart – это детализированная блок-схема, показывающая, как USG обработал данный пакет на каждом внутреннем этапе.

Цветом отмечены результаты прохождения.
Оранжевый – точка входа пакета.
Зелёный – прошёл.
Красный – отклонён.

USG не отправляет реальный трафик из сети. Он сам создаёт виртуальный пакет, который проходит весь внутренний процессинг.

Описание прохождения. Схема демонстрирует типичный путь первого пакета сессии.

Packet receiving – пакет принят физическим интерфейсом. Проверка базовых ошибок L1: CRC, frame length, physical link status.

Link Layer Parsing – разбор Ethernet-кадра, проверка MAC-адресов.

Network Layer Parsing – разбор IP-пакета: IP-адреса, TTL, флаги.

Session table search – поиск существующей сессии (для первого пакета – не найдено).

First packet preprocessing – внутренняя подготовка первого пакета: нормализация заголовков, анализ аномалий (базовый IPS-этап), проверка флагов.

Is a match found? No – нашлись ли правила session-based fast path? Поскольку это первый пакет, никакого fast path нет, и ответ всегда No.

First packet stateful inspection – здесь выполняются stateful-проверки безопасности, то есть: для TCP – валидный ли SYN, нет ли запрещённых флаг-комбинаций, нет ли аномалий размеров заголовка, корректна ли длина пакета, нет ли слишком маленького TTL и тп.

Server-map table search – то внутренний NAT-контекст. Если пакет должен попасть под DNAT то здесь подставляется новый destination IP/port, пакет перенаправляется на другой host. В случае ICMP server-map пуст, поэтому этап пройден без действий.

Routing table search – определяется, куда отправлять пакет, нужно ли обрабатывать его как локальный, есть ли blackhole route, принадлежит ли трафик VPN. Это PRE-routing lookup.

Security policy search – ищутся правила Security Policy: source zone, destination zone, source IP, destination IP, service (протокол/порт), action (permit/deny), дополнительные условия (time range, user, application). Если правило разрешает – пакет проходит дальше. Если deny – схема окрасилась бы красным.

Session table creation – создаётся новая сессия. Теперь последующие пакеты пойдут по fast path.

Processing after a match is found in the session table – Этот блок означает что дальнейшая обработка выполняется уже как часть новой сессии.

Content security check? No – Это IPS/AV/URL filtering. Для ICMP это всегда No, поэтому пакет сразу идёт дальше.

Packet sending – пакет отправлен наружу.

Packet Processing Result – результат: The packet was sent successfully – успех.

​

​

Режим Existing network traffic означает: попробовать отследить реальный трафик, уже проходящий через USG firewall, и попытаться построить flowchart для уже существующих пакетов.

Но USG не делает «активный захват» и не ждёт появление таких пакетов. Он пытается проверить, есть ли уже существующая сессия, проверить, есть ли в кэше недавний пакет, подходящий под критерии, проверить, не был ли пакет отброшен до L3/L2 и др. Если не находится идеально совпадающий пакет, то выводится сообщение:  Packets fail to reach the firewall or are discarded by the interface.

Этот режим практически не работает для ICMP и однопакетных протоколов.

Чтоб разобраться в работе этого режима, можно указать IP-адрес и порт сетевого экрана.

Далее поизучать получившиеся диаграммы. Попробовать различные настройки правил политик и посмотреть, как это влияет на результат.

Flowtrace корректно отображает входящий трафик, направленный непосредственно на firewall, потому что такие пакеты гарантированно доходят до интерфейса и обрабатываются самим USG.

Для внешних сервисов Flowtrace часто показывает ошибку, потому что реальный трафик не совпадает с искусственно заданными параметрами, проходит по другому маршруту, подвергается NAT или не возвращает ответ. Поэтому зелёная диаграмма возможна даже при неработающем сервисе USG, а красная – даже при рабочем внешнем сервисе.

В итоге можно отметить, что Packet Tracing хороший инструмент для диагностики, но он не моделирует реальное сетевое взаимодействие с устройством и не учитывает многие реальные настройки, например management на интерфейсе, обратный трафик (echo-reply), блокировки вне forwarding-pipeline и др. Поэтому диаграмма показывает только то, как пакет был бы обработан в теории, то есть на уровне forwarding pipeline, а не то, как устройство реально отвечает на ICMP, адресованный его собственному IP.

На основании этого можно сделать вывод, что использовать только данный инструмент для диагностики нельзя – она не отражает полностью поведение и может показывать «успешную обработку» даже в ситуациях, когда реальный трафик блокируется. Для точной диагностики необходимо комбинировать Packet Tracing с другими инструментами: packet capture, логами, сессиями и проверкой реальных политик.

 

DIAGNOSIS INFORMATION.

Diagnosis Information – это механизм сбора всей необходимой для диагностики информации, такой как  таблицы маршрутизации, таблицы ARP, сессии, NAT сервер-мэп таблицы, статистика пакетов, состояние интерфейсов, конфигурация, версии, логи, фильтрация по IP в реальном времени.

В итоге формируется диагностический пакет, который можно просматривать в GUI или экспортировать для тех. поддержки Huawei Support.

Basic collection – базовый сбор. Это быстрый сбор, подходит для общего анализа. В него собираются системное время (clock), версия ПО, базовые конфигурации, interface brief, CPU/memory.

Advanced collection – расширенный сбор. Он собирает всё в Basic, плюс таблицы маршрутизации в реальном времени, ARP в реальном времени, текущие сессии, server-map table (NAT),  статистику пакетов по интерфейсам и протоколам.  Кроме того, здесь можно отфильтровать сбор по IP-адресам источника и назначения. То есть можно собрать только данные, относящиеся, например, к проблемному хосту.

Для использования указываем адрес назначения (обязательно) и источника (по желанию), отмечаем типы собираемых данных и нажимаем кнопку Collect.

Предупреждение сообщает:

В зависимости от аппаратного обеспечения и конфигурации устройства процесс сбора информации может занять 20 минут или более.

Во время сбора информации выполнение каких-либо операций невозможно.

В результате формируется список диагностической информации с возможностью поиска по доступным на выбор разделам.

Во время сбора данных блокируются любые операции. USG продолжает работать, но управлять им нельзя. Поэтому запускать рекомендуется в нерабочее время.

 

WEB PAGE DIAGNOSIS.

Это инструмент который используется для диагностики проблем доступа пользователя к конкретному веб-сайту. Принцип действия – это не генерация трафика от клиента, а диагностический пинг от самого USG от имени клиента. То есть USG эмулирует трафик пользователя, повторяет его Route + NAT, но не использует реальное устройство в сети.

Главный недостаток – Web Page Diagnosis в USG не поддерживает HTTPS-URL. Он работает только с HTTP (порт 80). В таком виде от него мало толку, потому что сейчас все сайта работают через HTTPS.

 

IPSEC DIAGNOSIS.

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

В настройке присутствует два варианта диагностируемых объектов: Negotiated tunnel и Data Flow. Рассмотрим их по очереди.

Negotiated tunnel – согласованный туннель. Этот вариант проверяет уже существующий, установленный IPSec-туннель, который успешно прошёл фазу IKE и SA-переговоров. Используется, когда туннель есть, но по нему что-то работает нестабильно. Диагностика проверяет: состояние IKE SA, состояние IPSec SA, время жизни ключей, параметры шифрования, совпадение настроек между двумя сторонами, есть ли ошибки повторных переговоров, разрывы туннелей, проблемы Dead Peer Detection, NAT-Traversal, MTU/MSS.

Назначение настроек.

IPSec Policy Name – выбор VPN-политики для диагностики.

Local Interface – интерфейс USG, через который устанавливается туннель.

Diagnosis Mode – режимы диагностики.

Proactively initiate negotiation (принудительно инициировать переговоры) – сетевой экран инициирует туннель для проверки. Используется только для site-to-site VPN. Потому что USG может стартовать IKE только тогда, когда точно знает IP адрес пира. Для client-to-site адрес клиента динамический, клиентов много, USG не может инициировать переговоры.

Receive packets from peer (получить пакеты от пира) – проверка входящего трафика (не для site-to-multisite). USG пассивно ожидает входящие IKE-пакеты, попытку подключения, начало переговоров со стороны партнёра. После получения первого пакета USG начинает проводить анализ данных. Если сайтов много, то USG не может распределить от какого сайта идут пакеты, поэтому диагностика site-to-multisite не работает. Если один филиал (client-to-site,) – то срабатывает.

Diagnose – запускает проверку туннеля.

Export – позволяет сохранить результаты для отчёта или анализа.

Чтоб получить какой-то результат, диагностику нужно запускать перед началом подключения клиента.

 

Data Flow – поток данных. Этот режим диагностирует не сам туннель, а конкретный трафик (поток данных), который должен идти через IPSec. Он проверяет: входит ли трафик в политику IPSec, подходит ли поток под ACL (Proxy ID/Traffic Selector), правильно ли шифруются пакеты, доходит ли трафик до удалённой стороны, есть ли обратный поток, падает ли трафик из-за неправильного направления, есть ли вопросы с маршрутом, есть ли дропы на этапе шифрования/дешифрования.

Source IP Address – адрес источника (клиента в client-to-site). Это внутренний адрес, который получает VPN-клиент после подключения.

Destination IP Address – адрес назначения (сервер в client-to-site). Это адрес внутренней сети, куда должен идти трафик через VPN.

Protocol – протокол, который используется для передачи данных внутри туннеля. TCP – наиболее универсальный вариант.

Source Port – порт источника. Указывать не обязательно.

Destination Port – порт назначения. Указывать не обязательно.

Нажимаем кнопку Diagnose.

На кнопку Export можно сохранить полученный результат в текстовый файл.

 

Рассмотрим  результат.

Security Policy – политики, разрешившие IPsec трафик. NAT-T (NAT Traversal) также разрешён – туннель может работать через NAT.

NAT Policy – применившаяся политика NAT.

Data Flow Route – проверка маршрута для VPN-трафика (существует).

Interface Status – интерфейс, через который идёт туннель, активен и корректно поднят. Физическая и протокольная связь работает.

IPSec Policy on a Routing – на маршрутизируемом интерфейсе не применяется IPSec-политика. Если IPSec Policy не привязана к маршрутизирующему интерфейсу, диагностика останавливается, потому что весь остальной анализ теряет смысл.

Если проверка проходит немного дальше.

IPSec Policy Matching Data Flow – проверка того, что выбранная IPSec-политика совпадает с анализируемым трафиком.

Negotiation Mode – Not supported. Diagnosis supports only non-template IKE negotiation. Диагностика поддерживает только «не шаблонные» IKE-туннели. Если используется IKE template или динамический peer – проверка не возможна. Иными словами данная диагностика не поддерживает client-to-site.

 

SESSION TABLE.

Таблица сессий – это таблица состояний межсетевого экрана Stateful Firewall.  Она фиксирует каждую активную сетевую сессию, которая прошла проверку политик безопасности.

Кнопки управления.

Terminate Session – сбросить выбранную сессию.

Costumize – добавить или удалить столбцы в таблицу.

Add Filter – использовать фильтр (для нахождения сессии по конкретным параметрам).

При нажатии на кнопку в столбце Detalis напротив каждой сессии, открывается подробное содержание.

Таблица сессий используется для:

-отслеживания состояния подключений, чтобы понимать, какие пакеты относятся к уже разрешённым соединениям;

-повышения производительности, так как после создания записи в таблице USG не проверяет каждый пакет заново, а пропускает его на основе существующей session entry;

-поддержки NAT, потому что там хранится информация о трансляции адресов и портов;

-выявления аномалий и атак, например, чрезмерное количество сессий от одного источника;

-диагностики трафика – можно видеть, что происходит в реальном времени, например, если Reverse Packets = 0, то нет обратного трафика, и тп.

Пример рассмотрения одной сессии.

Source – источник трафика.
Source Virtual System: public
Виртуальная система (VSYS), по умолчанию – public.
Source Zone: trust – зона источника трафика.
Source Address: 192.168.1.15 – адрес источника внутри сети.
Source Port: 49763 – динамический порт источника.
NAT Source Address: 92.219.227.68 – публичный внешний IP после Source NAT.
NAT Source Port: 19404 – транслированный порт вместо исходного.

Destination – назначение трафика.
Destination Virtual System: public – VSYS назначения.
Destination Zone: untrust – зона назначения.
Destination Address: 104.81.99.218 – IP удалённого сервера.
Destination Port: 80 ­– HTTP (TCP/80).
NAT Destination Address/Port – пусто, значит DNAT не применялся.

Common Session Field – общие параметры сессии.
Creation Time: 2025/11/24 8:4:11 – время создания сессии.
Session Timeout: 00:15:00 – максимальное время бездействия, после которого запись будет удалена.
(для TCP обычно ~15 минут для established state)
Time Remaining: 00:03:43 – время до удаления сессии при отсутствии трафика.
Protocol: HTTP – USG определил протокол.
Application: General_TCP – идентификация приложения через App-ID.
General_TCP – TCP-направленное, без точной сигнатуры.
Security Policy: пусто, в GUI иногда не показывается имя политики, хотя она была применена.
Source User: пусто – нет аутентифицированного пользователя.
Forward Packets: 5 – количество пакетов от источника к назначению.
Reverse Packets: 4 – количество пакетов в обратном направлении.
Forward Bytes: 452 – сколько байт передано от клиента к серверу.
Reverse Bytes: 898 – сколько байт передано от сервера к клиенту.
Outbound Interface: Dialer0 – интерфейс выхода в интернет (PPPoE).
MAC Address: – MAC источника (пусто, трафик не пришёл через L2-интерфейс или не сохраняется).
Next Hop: 104.81.99.218 – следующий узел (обычно совпадает с адресом назначения, если маршрутизируется напрямую).

В итоге сессия означает следующее.

Внутренний ПК 192.168.1.15 из зоны trust инициировал HTTP-подключение к серверу 104.81.99.218:80. Сетевой экран сделал Source NAT и подменил адрес/порт на 92.219.227.68:19404. Трафик идёт через интерфейс Dialer0. Всего передано 5/4 пакетов, сессия активна ещё ~3 минуты.

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

Над таблицей сессий отображается настройка Fast Session Aging – это функция, которая автоматически ускоряет удаление старых или неактивных сессий, когда таблица начинает переполняться.

Назначение параметров.

Fast Session Aging: On/Off – включает или выключает механизм ускоренного удаления сессий.

Upper Limit on Session Table Usage: 80% – если таблица сессий заполнена на 80%, USG включает режим ускоренного aging.

Lower Limit on Session Table Usage: 60% – когда заполнение падает до 60%, ускоренный режим отключается – firewall возвращается к нормальному aging.

Aging Acceleration Coefficient: 20% – насколько быстрее будут удаляться сессии. Например: если обычный timeout = 10 минут, то при коэффициенте 20% оно сокращается до 8 минут.

При такой настройке Fast Session Aging предотвращает переполнение таблицы сессий, автоматически ускоряя очистку старых записей при высокой нагрузке.

Настройка Fast Session Aging доступна при входе в таблицу сессий через отдельный пункт в боковом меню.

 

TOP SESSIONS.

Топ сессий – это список внутренних устройств, которые создают наибольшее количество активных сессий в данный момент.

В таблице:

Source Address – IP-адрес устройства в сети

Sessions – сколько активных сессий оно установило

Ranking – место в рейтинге по количеству сессий

Например: 192.168.1.10 – 740 сессий – это сейчас самый активный хост.

 

Топ-сессий применяется для следующих целей.

1.Поиск аномальной активности. Если один хост внезапно создаёт слишком много сессий, это может указывать на вирусы, сканирование портов, DoS-поведение, ошибочное приложение, создающее огромное количество соединений.

2.Диагностика перегрузки сетевого экрана. Если таблица сессий почти заполнена, Top Sessions помогает увидеть, кто именно её загружает.

3.Анализ поведения пользователей. Понимание, какие рабочие станции или сервисы создают больше всего соединений.

4.Точка входа для расследования сетевых проблем. Если кто-то жалуется на сеть или интернет, а у него 1000+ сессий, это может быть причина.

5.Оптимизация политик и QoS. Позволяет увидеть, какие клиенты требуют больше всего ресурсов – можно настроить приоритеты или ограничения.

 

ROUTING TABLE.

Таблица маршрутов – это карта, по которой firewall определяет, куда отправлять пакеты. Каждая строка сообщает сетевому экрану как добраться до нужной сети и через какой интерфейс.

Protocol – как маршрут был получен:

Static – создан вручную;

Direct – сеть подключена напрямую;

UNR – unreachable route (служебный маршрут для недоступности);

 

Destination/Mask – к каким IP-сетям относится маршрут.

Например:
0.0.0.0/0 – маршрут «по умолчанию» (весь остальной трафик без конкретных маршрутов в интернет).
127.0.0.0/8 – внутренние loopback-маршруты самого сетевого экрана.

Priority/Cost – метрики выбора лучшего маршрута. Меньше – «лучше».

Next Hop – кому передать пакеты дальше, IP-адрес следующего маршрутизатора.

Interface – физический интерфейс, через который отправляется трафик.

Над таблицей есть небольшой фильтр, в котором можно выбрать параметры для поиска нужного маршрута.

 

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

-проверить, есть ли маршрут к нужной сети;

-понять, куда уходит трафик, через какой интерфейс и какому next hop всё отправляется;

-диагностика проблем с доступом в интернет – ошибочный default-route это частая причина неисправностей;

-разбор конфликтов маршрутов – почему выбирается один путь, а не другой;

-уточнение работы NAT и VPN – чтобы убедиться, что трафик идёт по правильному пути.

 

INTERFACE STATUS.

В этом разделе представлена сводная таблица всех интерфейсов устройства: физических, логических, агрегированных.

Для каждого интерфейса показываются ключевые параметры:

Interface Name – название интерфейса.

Zone – зона безопасности, к которой интерфейс относится (trust/untrust/dmz/none или собственная).

Virtual System – виртуальная система интерфейса (обычно public).

IP Address – адрес интерфейса.

Connection Type – тип соединения: статический, динамический, PPPoE.

VLAN/VXLAN – по ID указывает, к какому логическому сегменту сети привязан интерфейс (если настроено).

Mode – режим работы интерфейса (Routing/Switching/Bypass/Interface Pair) — определяет, как USG обрабатывает трафик, проходящий через данный порт.

State – состояние интерфейса.

Три индикатора:

Physical: поднят ли физический линк.

IPv4: активен ли IPv4-адрес.

IPv6: активен ли IPv6.

Обобщая можно сказать что Interface Status показывает состояние всех интерфейсов USG и их настройки. В диагностике используется для проверки доступности интерфейсов, корректности маршрутизации и правильности прохождения трафика.

 

SECURITY POLICY.

Вкладка политик безопасности предназначена для создания, удаления, настройки и контроля применения этих политик. В центре диагностики она добавлена для того, чтобы быстро видеть, какая политика применяется к конкретному трафику или сессии, оперативно проверять и изменять правила при анализе сетевых проблем.

Подробнее про Security Policy можно прочитать тут.

 

5-TUPLE PACKET CAPTURE.

5-Tuple Packet Capture – это механизм захвата пакетов, основанный на пяти ключевых параметрах, по которым устройство идентифицирует сетевой поток.

Параметры 5-tuple:

Source Address – IP-адрес источника.

Destination Address – IP-адрес назначения

Source Port – порт источника.

Destination Port – порт назначения.

Protocol – протокол.

Комбинация этих параметров однозначно определяет конкретный поток.

5-tuple используется для точечного захвата пакетов, диагностики проблем с NAT/ACL/Policy-based routing или анализа конкретной сессии, не перегружая устройство полным захватом.

 

Проведем тестовый захват пакетов, чтоб понять, как это работает.

Настраиваем конфигурацию через кнопку Configure.

Первые три параметра конфигурации оставляем по умолчанию в данном случае. Эти параметры позволяют сбалансировать нагрузку, чтобы не навредить производительности.

Sample Ratio – коэффициент выборки. Определяет, как часто брать пакеты в захват.

1:1 – захватывать каждый пакет.

1:10 – брать 1 пакет из каждых 10.

1:100 – брать 1% трафика. Используется для снижения нагрузки на CPU при анализе высоконагруженных потоков.

Чтоб увидеть каждый пакет нужно указывать 1:1.

Total Number of One—Way Captured Packets – максимальное количество пакетов в одном направлении. Это лимит количества пакетов, которые USG захватит для одного 5-tuple в одном направлении. Нужен чтоб контролировать переполнение буфера памяти.

Maximum Packet Length – максимальная длина сохраняемого пакета. Диапазон 40-1500 байт.

40 байт – только заголовки, полезная нагрузка не сохранится.

1500 байт – полный пакет, включая payload.

 

Добавляем нужный интерфейс в список.

 

Настройка интерфейса.

Настройка интерфейса.

Interface — определяет, на каком физическом или логическом интерфейсе будет вестись захват пакетов. В данном примере LAG-1 – это агрегированный интерфейс, через который в сетевой экран подключена локальная сеть.

Traffic Direction – направление трафика. (выбраны оба направления)

Inbound – входящий трафик на интерфейс.

Outbound – исходящий трафик с интерфейса.

VLAN – захват трафика из конкретного VLAN. (не используется)

Packet Type – тип анализируемых пакетов.

Варианты: IPv4 – только трафик IPv4 протоколов.

Non-IP – трафик на уровне L2.

All – и то и другое.

В интерфейсе нужно указать 5-tuple в виде добавления правила. Указываем IP-адрес источника, назначения (any=любой), протокол и порты. В данном случае для примера выбран распространенный порт 443.

Action:

Permit – включить анализ.

Deny – игнорировать этот трафик.

 

Сохраняем настройку. Запускаем захват трафика на кнопку Start.

Перед запуском появляется сообщение, которое предупреждает о том, что:

Захват пакетов может привести к сбору персональных данных и снижению производительности системы.
Захват требует периодического обновления данных. Поэтому, когда время ожидания истечет, веб-страница не закроется.

В результате захвата сформируется таблица.

 

Рассмотрим содержание любого пакета.

Ethernet II – канальный уровень OSI. Отвечает за передачу кадров между устройствами в одной сети по MAC-адресам.

Destination – MAC-адрес получателя (e4:83:26:75:9a:29)

Source – MAC-адрес отправителя (f4:1e:57:cb:d7:09)

Type – тип протокола уровня 3 (IP)

 

IP (IPv4) – сетевой уровень. Отвечает за маршрутизацию пакета от источника к назначению по IP-адресам.

Version – версия IP (4)

Header length – длина заголовка IP (20 байт)

Differentiated Services Field – приоритет/маркировка пакета (DSCP/ECN)

Total Length – общий размер пакета в байтах (41)

Identification – идентификатор фрагмента (0x23b)

Flags – флаги управления фрагментацией (Don’t Fragment)

Fragment offset – смещение фрагмента (0)

Time To Live (TTL) – максимальное число хопов (127)

Protocol – транспортный протокол (TCP)

Header checksum – контрольная сумма заголовка

Source – IP-адрес отправителя (192.168.1.25)

Destination – IP-адрес получателя (20.190.147.11)

 

TCP – транспортный уровень. Обеспечивает доставку данных, упорядочивание и контроль ошибок между приложениями.

Source port – порт отправителя (61805)

Destination port – порт получателя (443)

Sequence number – номер последовательности (1427659041)

Header length – длина заголовка TCP (32 байта)

Flags – флаги TCP (0xc2 = SYN + другие)

Window size – размер окна приёма (64240)

Checksum – контрольная сумма TCP

На основании анализа можно предположить что этот пакет идёт из локальной сети в интернет, TCP-соединение ещё не установлено, это первый SYN-пакет. Пакет захвачен на внутреннем интерфейсе до NAT. MTU стандартный, пакет маленький, фрагментации нет. TTL 127 – значит, это оригинальный пакет от хоста (не модифицирован маршрутизатором).

Пакет сам по себе не несёт данных, но для диагностики сетевых проблем он иногда полезнее, чем любые DATA-пакеты.

 

5-TUPLE PACKET STATISTICS.

5-Tuple Packet Discarding Statistics показывает, сколько пакетов, подходящих под заданный 5-tuple фильтр, устройство реально получило, передало и/или отбросило. Фактически это счётчики прохождения трафика через движок обработки, удобный механизм для отладки ACL, NAT и маршрутизации.

Нажимаем кнопку Configure 5-Tuple Packet Statistic.

В открывшейся форме указываем источник, назначение и протокол. Если оставить пустые поля, то статистика пойдет по всему подряд трафику.

 

Нажимаем старт и видим статистику.

Summary of Packets Discarded on the Device – это общий итог по всему 5-tuple-потоку.

 

Packets Discarded in Common Forwarding

USG делит обработку на два пути Common Forwarding и Fast Forwarding.

Common forwarding (медленный путь) – когда пакет проверяется подробно: ACL, NAT lookup, IPS, zone firewall. Здесь показывается сколько входило пакетов, сколько после полной проверки ушло дальше, сколько были отброшены механизмами: ACL, zone-policy, invalid SYN/ACK и тп.

Fragmented Packets/Unfragmented Packets – USG отдельно считает фрагментированные IP пакеты и обычные, неразбитые пакеты.

Packets Discarded in Fast Forwarding

Fast forwarding (быстрый путь) – когда пакет проходит через аппаратный ускоритель. В fast-path трафик идёт, если сессия уже создана, NAT вычислен, нет IPS и тп, нет особых политик, пакет нормальный стандартный (ACK, PSH, без опций).

При нажатии кнопки View можно рассмотреть детали статистики.

Это список всех обнаруженных 5-tuple потоков, которые совпали с заданными параметрами фильтра.

Protocol/Source, Destination Port – в этой колонке отображается конкретный поток, который устройство нашло и поставило на учёт. В нем отображается обычный рабочий трафик.

Direction – USG делит записи на два направления Forward и Reverse.

Forward – трафик от внутреннего узла к удалённому серверу.

Reverse – ответы сервера назад.

Один поток = две потенциальные строки. Если Reverse = 0 пакетов – трафик назад не пришёл (возможная сетевая проблема).

Fragmented packets/Unfragmented packets показывает, были ли IP-фрагменты.

Discarded packets – самый важный столбец. Показывает, что firewall отбросил во входящем направлении на данном конкретном потоке.

Unfragmented packets Discarded видно что 1 пакет был отброшен сетевым экраном на этом потоке. Там, где цифра красная. Это может быть ACL или Zone-policy drop, TCP invalid flag и подобные обнаружения. Если красных значений много, то нужно проанализировать трафик на данном потоке.

Packets Forwarded – количество пакетов, которые прошли дальше.

Delay – задержка, представлена колонками First Packet Delay, Max Delay и Avg Delay. В них отображается задержка в микросекундах между получением первого пакета и его передачей дальше.