В каких случаях необходимо собирать дамп сетевых пакетов с компьютера или порта роутера?

Зачем необходимо собирать дамп сетевых пакетов с компьютера или порта маршрутизатора (роутера)? В каких случаях нужен дамп с компьютера, а в каких - с маршрутизатора? Когда полезен дамп пакетов без роутера? Какую информацию нужно сообщить дополнительно для анализа сетевых пакетов?

Часть 1. Для чего вообще нужен дамп сетевых пакетов

При прохождении через маршрутизатор (роутер или интернет-центр) поток трафика претерпевает определенные изменения – например, в сетевых пакетах могут изменяться IP-адреса источника или назначения (в зависимости от направления трафика), порты источника/назначения, увеличивается TTL (время жизни пакета), часть пакетов блокируется фильтрами или механизмами защиты маршрутизатора и т.п.
На рисунке приведен пример прохождения пакетов через маршрутизатор.

Кроме того, некоторые пакеты можно наблюдать только с одной стороны маршрутизатора (установка соединения маршрутизатора с провайдером, например, видна только со стороны WAN-порта, а пакеты NetBIOS для доступа к ресурсам компьютера (ПК) в рамках домашней локальной сети средствами ОС Windows – только со стороны LAN).

Таким образом, дамп сетевых пакетов нужен для того, чтобы посмотреть, что происходит с конкретными пакетами:

  • приходят или уходят они клиенту или маршрутизатору;
  • в корректной ли форме они приходят;
  • как они модифицируются при прохождении маршрутизатора.

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

 

Инструкция по использованию встроенного модуля захвата сетевых пакетов в интернет-центрах серии Keenetic представлена в статье: «Использование встроенного модуля захвата сетевых пакетов»

Для диагностики работы маршрутизатора полезно проанализировать пакеты:

1.1. С хоста, подключенного к локальной сети (в LAN-порт маршрутизатора). Здесь видны:

  • Все исходящие пакеты с ПК-клиента в исходном виде (до обработки их маршрутизатором).
  • Входящие пакеты, которые были пропущены маршрутизатором извне и уже претерпевшие изменения со стороны маршрутизатора.

1.2. Со стороны провайдера (WAN-порта маршрутизатора). Здесь можно увидеть:

  • Исходящие пакеты из локальной сети, пропущенные маршрутизатором (возможно, измененные при прохождении маршрутизатора).
  • Все входящие пакеты, прошедшие вышестоящий шлюз провайдера.


Важно! По пути от источника в нашу сеть наши входящие пакеты проходят несколько шлюзов, и на каждом они также видоизменяются. Но для работы нашего маршрутизатора важен тот их вид, который они принимают именно на провайдерском шлюзе. За дальнейшее прохождение как входящих, так и исходящих пакетов отвечает вышестоящее оборудование, и это не имеет отношения непосредственно к работе домашнего маршрутизатора.

1.3. Без участия маршрутизатора (при подключении напрямую к провайдеру). Так мы видим:

  • Все входящие и исходящие пакеты между ПК и шлюзом провайдера в исходном виде – без изменений со стороны промежуточного оборудования.


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


Часть 2. Откуда (с какого порта или интерфейса) снимать дамп сетевых пакетов в различных ситуациях

Особое внимание здесь нужно обратить на то, что для анализа возникающей некорректной ситуации необходимо ОБЯЗАТЕЛЬНО воссоздавать ее во время работы модуля захвата пакетов или программы-анализатора трафика. Например, если мы столкнулись с ситуацией, когда через маршрутизатор не удается совершить телефонный звонок с SIP-телефона, во время сбора дампа пакетов нужно обязательно попробовать позвонить. Если речь идет об обрыве подключения к провайдеру – обязательно начать сбор пакетов до обрыва и завершить его после сбоя.

2. Сбор дампа только с LAN-порта (т.е. анализ трафика между ПК и маршрутизатором) может быть полезен:

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

2.2. Для общего представления о нагрузке, создаваемой конкретным хостом. Например, дает возможность оценить нагрузку на порту (по данным «число пакетов в секунду») для исключения перегрузки; просмотреть исходящие пакеты на предмет посторонних или вредоносных (некоторые приложения самостоятельно генерируют трафик без ведома клиента, что иногда может влиять на работу маршрутизатора) и т.д.

2.3. Исключения проблем на конкретном ПК, например отсутствие ответов на запросы извне (их блокирование межсетевым экраном, антивирусом и другими средствами на ПК); отсутствие запросов к удаленным ресурсам и т.д.

2.4. Для первичной диагностики проблем с доступом к ресурсам в локальной сети извне. Например, в случае подозрения на ошибки в работе проброса портов NAT, фильтров, межсетевого экрана можно определить, прошел запрос в локальную сеть или потерялся.

Важно! В данном случае отсутствие пакета со стороны LAN не говорит однозначно о проблемах на маршрутизаторе. Для подтверждения этого нужно также посмотреть дамп напрямую – убедиться, что такой пакет проходит через провайдерское оборудование.

2.5 Сбор дампа пакетов только с WAN-порта, т.е. между WAN-портом маршрутизатора и шлюзом провайдера, полезен при диагностике проблем передачи данных исключительно между роутером и провайдером (т.е. с передачей тех пакетов, которые генерируются на самом маршрутизаторе или адресованы только ему, а не в локальную сеть).

Например, для диагностики различных проблем с подключением к провайдеру (не устанавливается соединение, соединение обрывается) или проблем с удаленным доступом на сам маршрутизатор. Также анализ пакетов на WAN полезен при проблемах, возникающих только при работе одновременно нескольких ПК в локальной сети (если при подключении одного любого клиента таких проблем не наблюдается) – например, пропадает трансляция потока IPTV, когда его смотрят с нескольких устройств сразу.

2.6 Дамп напрямую (без роутера) полезен, если нужно исключить проблему на уровне вышестоящего оборудования. Например, при проблемах с доступом к локальному ПК извне необходимо убедиться, что пакеты приходят на хост и уходят от него в нужном корректном виде, а не блокируются провайдером или средствами защиты на ПК.
Также в некоторых случаях анализ такого дампа помогает установить причину самопроизвольных перезагрузок маршрутизатора (например, из-за появления в сети провайдера так называемых пакетов-убийц или слишком большого количества постороннего трафика-мусора).

Однако в некоторых случаях описанной диагностики недостаточно. Такая ситуация может возникнуть, когда проблемы на стороне провайдера и с некорректными настройками уже исключены. Тогда нужно анализировать дамп пакетов одновременно со стороны хоста и WAN-порта маршрутизатора. Например, при отсутствии доступа извне на локальные ресурсы только при использовании маршрутизатора или проблемах с прохождением трафика, обрабатываемого алгоритмами ALG (SIP, FTP и пр.).

В данном случае обязательным условием будет параллельный сбор дампов пакетов со стороны хоста и WAN-порта роутера, чтобы отследить весь путь конкретного пакета. Для удобства диагностики полезно запустить пинг с локального хоста на какой-либо внешний узел, чтобы проще было синхронизировать данные с локальной и внешней стороны.

Важно! Из-за достаточно сложного механизма сбора дампа пакетов со стороны WAN-интерфейса, нужно исключить максимум возможных проблем на других уровнях (провайдера, ПК) при помощи анализа локального трафика и трафика без роутера.

 

Часть 3. Что необходимо предоставить для диагностики, кроме самого дампа сетевых пакетов

Так как в дамп попадут не только полезные для диагностики пакеты, а все пакеты, существующие в рамках данного сегмента сети, для фильтрации нужного трафика потребуется указать:

3.1. IP- и/или МАС-адреса диагностируемых устройств – хоста, если дамп снят в локальной сети; маршрутизатора и/или шлюза провайдера – если дамп снят с WAN-порта.
3.2. Адрес удаленного узла, с которым наблюдается проблема.
3.3. Информацию о типе или признаке трафика, с которым наблюдались проблемы во время работы анализатора. Это может быть конкретный номер порта, на который нет доступа; тип пакетов, не проходящих через маршрутизатор корректно (SIP, мультикаст, DHCP и т.д).

KB-2854

Была ли эта статья полезной?

Пользователи, считающие этот материал полезным: 5 из 5

Еще есть вопросы? Отправить запрос

Комментарии

0 комментариев

Войдите в службу, чтобы оставить комментарий.