Невозможно найти трафик для определенного устройства с Wireshark (через Wi-Fi)

У меня есть устройство, которое обменивается данными с TCP-сервером, работающим на моем компьютере. Моя машина обычно подключается к сети через Ethernet, однако у меня также есть беспроводной адаптер, который я могу использовать для подключения к моему маршрутизатору. Устройство (клиент TCP) подключено к моему маршрутизатору (шифрование / ключ безопасности WPA2-Personal / AES).

Я вижу, как устройство с Wireshark на моем адаптере Ethernet обменивается данными с моим сервером. Я не могу найти устройство, когда смотрю на беспроводной адаптер (ищу устройство по IP). Я зашел в Edit> Preferences> Protocols> IEEE 802.11 wireless Lan> Decryption Keys> и затем установил ключ wpa = pwd "password: ssid" и wep-psk ", который я создал здесь".

Я никогда не использовал Wireshark для просмотра трафика, исходящего не от моего ПК, однако в данном конкретном случае это необходимо для устранения проблемы. Любая помощь будет принята с благодарностью.


person user3693406    schedule 05.05.2016    source источник
comment
Какое отношение этот вопрос имеет к программированию? Вам следует попытаться задать этот вопрос суперпользователю.   -  person Ron Maupin    schedule 05.05.2016


Ответы (1)


(Пока я думаю об этом, во-первых: основная причина этого не имеет никакого отношения к шифрованию - в противном случае вы бы наверняка увидели зашифрованный трафик, но все равно видели бы прохождение «всякого».)

Вы будете видеть трафик к этому устройству и от него, только если он многоадресный или широковещательный.

Это связано с тем, что в Wi-Fi / 802.11 происходит обмен данными между AP (точкой доступа) и STA (станцией). На уровне 802.11 каждое "одноадресное" [0] взаимодействие между, скажем, STA A и STA B фактически не идет напрямую от STA A к STA B: сначала идет кадр 802.11 от STA A к AP, а затем AP отправит его на STA B и т. Д.

Поэтому, если ваше устройство отправляет некоторый многоадресный / широковещательный трафик, вы увидите это - но только это (ответы на многоадресную / широковещательную рассылку часто являются одноадресными).

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

Другой очень распространенный пример такого трафика в контексте Wi-Fi - если STA является клиентом DHCP. Затем вы увидите запрос DHCP. В типичном сценарии эта STA выдает такой запрос DHCP сразу после ассоциации / аутентификации с AP. В таком случае на вашем ПК, на котором запущен wirehark (который является другим STA от той же точки доступа), вы увидите DHCP-запрос, поскольку он транслируется, и точка доступа будет его распространять (я намеренно не использую термин «пересылка»). Но обычно не намного больше, потому что, опять же, в типичном сценарии AP также является DHCP-сервером, следовательно, остальная часть взаимодействия, касающаяся этого процесса DHCP, будет происходить непосредственно между AP и упомянутым STA. Однако вы также должны увидеть запрос ARP - см. Выше - выданный упомянутым DHCP-клиентом STA, чтобы проверить, что IP, который ему только что был предложен DHCP-сервером, действительно бесплатный, потому что это то, что требует протокол DHCP [1 ] если реализовано правильно.

Другой не такой распространенный, но не такой редкий трафик, который вы можете увидеть, - это тот, который по своей сути является широковещательным:

  • Запрос / объявление соседей ICMPv6 (от STA под управлением современной ОС с двойным стеком IP)
  • Протокол обнаружения Dropbox LAN (и ох, это может быть довольно шумно от обычного ПК STA)
  • UPnP SSDP (это многоадресная рассылка UDP на порт 1900)
  • ... и, вероятно, многие другие, в зависимости от приложений, работающих в STA (или, конечно, AP, например, DHCP).

Это фундаментальный момент, который следует понимать и никогда не забывать при работе с Wi-Fi / 802.11 в настройке AP / STA: все коммуникации проходят через AP, никогда напрямую между STA [2] [ 3].

Если вы «никогда не использовали Wireshark для просмотра трафика, исходящего не с моего ПК», возможно, вы не знакомы с концепцией неразборчивый режим, но имейте в виду, что это не суть и здесь не поможет: неразборчивый режим может только помочь в отслеживании трафика, который поступает на ваш сетевой интерфейс, но обычно отбрасывается его драйвером или вашим Стек ОС. Но здесь трафик фактически никогда не идет на ваш интерфейс, потому что AP не будет отправлять этот трафик к нему на базовом уровне 802.11: фундаментальная роль AP - действовать как мост ("переключатель ") между STA, и вы находитесь в той же ситуации, что и с проводным коммутатором Ethernet, и вам потребуется зеркалирование портов на коммутаторе, чтобы видеть такой трафик, потому что коммутатор достаточно умен, чтобы не отправлять этот трафик на порт, к которому вы будете подключены.

В контексте 802.11, помимо «обычного режима» и «беспорядочного режима», существует третий режим: " monitor ". В режиме мониторинга - если все идет нормально, потому что это не всегда очевидно - ваш компьютер, перехватывающий пакеты, работающий wireshark, тогда не будет STA и не будет каким-либо образом участвовать в каком-либо трафике Wi-Fi, но тогда вы можете «видеть все» (зашифрованный, если есть шифрование, но wireshark может помочь).

О сложном мире перехвата пакетов Wi-Fi см .:

Настройка захвата WLAN (IEEE 802.11)

(хотя и ориентированы на wireshark, технические концепции применимы также к другим инструментам на основе pcap, таким как libpcap (конечно ...), но также и tcpdump)

[0] Я использую термин «одноадресная передача» здесь на ее корневом уровне, то есть не в его значении «IP / уровень 3» (мы находимся на уровне 802.11, который является PHY (уровень 1) + Medium Управление доступом, также известное как MAC (уровень 2) - среда, являющаяся «эфиром», но более фундаментально, как «одноадресная передача = связь от определенного объекта A к другому конкретному объекту B».

[1]: Из RFC 2131, Протокол динамической конфигурации хоста, 3.1 Взаимодействие клиент-сервер - назначение сетевого адреса, стр.16, абзац 5:

Клиенту СЛЕДУЕТ выполнить окончательную проверку параметров (например, ARP для выделенного сетевого адреса) и записать продолжительность аренды, указанную в сообщении DHCPACK. На этом этапе клиент настроен. Если клиент обнаруживает, что адрес уже используется (например, с помощью ARP), клиент ДОЛЖЕН отправить сообщение DHCPDECLINE на сервер и перезапускает процесс настройки.

[2]: (совсем недавно) Wi-Fi Direct, который не является эксклюзивным для AP / STA - но это уже другая тема - изменили ситуацию в этом отношении.

[3]: ... и не волнуйтесь, это не загружает программное обеспечение точки доступа (например, это не относится даже к программному обеспечению точки доступа пользователя, например, hostapd). - технически сложный аппаратный чипсет Wi-Fi.

РЕДАКТИРОВАТЬ:

Извините, я был слишком занят объяснением «почему» из ваших вопросов, забыв «... теперь как?»:

... однако в данном конкретном случае необходимо устранить проблему.

Итак, я использовал 2 подхода:

1 / Используйте режим монитора.

Хотя проблем может быть много:

  • ваше (нюхающее) оборудование Wi-Fi может не поддерживать его (обычно это не проблема Linux, по крайней мере, но ...),
  • ваша ОС может не поддерживать и / или не требовать определенного оборудования (см. ссылку на wiki Wireshark выше, особенно если вы работаете в Windows),
  • радио среда может быть раздражающе шумной (случай для меня на работе), и поскольку вы нюхаете компьютер, он просто пассивно слушает радио, а не подключен ко всему, что вы можете пропустить пакеты (также случай для меня на работе, которые появляются в wireshark "следуйте диалогу", а затем вы увидите несколько "(отсутствующих байтов: XXX)),
  • а до этого у вас возникла проблема с шифрованием, и вы, возможно, захотите переключиться на незашифрованное, чтобы упростить работу, что может быть неприемлемым вариантом (я обычно могу это сделать, но слишком часто некоторые "(XXX недостающих байтов) "сделать все бесполезным.

В целом, по моему опыту, я оставляю режим монитора для низкоуровневого набора микросхем Wi-Fi и исследования основных проблем стека 802.11 = не для устранения неполадок прикладных протоколов более высокого уровня. Но, пожалуйста, попробуйте, если это сработает для вас, ничего страшного.

Это требует некоторого контроля над устройством (что меня устраивает, так как, так сказать, «я их строю»). Чтобы использовать это, я использую SSH-соединение для запуска tcpdump на устройстве - некоторые предварительные условия, поэтому, конечно, если у вас нет возможностей удаленной оболочки или исполняемого файла _12 _ / _ 13_ на устройстве, это бесполезно для вас ...: - / Тем не менее, я бы очень рекомендовал это, если возможно.

Вот оно:

ssh foo@device "/usr/sbin/tcpdump -U -s0 -w - -i <wireless interface on the device> 'not port 22'" | wireshark -k -i -

... это запускает tcpdump процесс на устройстве (конечно, пользователь "foo" должен иметь соответствующие права для запуска tcpdump в беспорядочном режиме по умолчанию, хотя, возможно, его --no-promiscuous-mode параметр может быть в порядке, в зависимости от вашей проблемы), сам по себе <wireless interface on the device> , отфильтруйте сам SSH, чтобы инструмент не смешивался с интересующим трафиком, и отправьте его обратно на ПК, где он, в свою очередь, будет перенаправлен на wireshark. И «Вуаля», наблюдайте за волшебством!

Надеюсь это поможет.

person jbm    schedule 07.05.2016
comment
Спасибо за отличный ответ! Хотя у меня все еще есть некоторые проблемы (в Windows), похоже, что подход 1 - это то, что нужно. Вы определенно дали мне более чем достаточно, чтобы попытаться с этим справиться. Хотя я создал устройство, с которым у меня возникли проблемы, я, к сожалению, не могу запустить захват на нем. По сути, устройство представляет собой небольшой микроконтроллер PIC, подключенный к адаптеру последовательного интерфейса WiFi. У меня проблемы с подключением к другим компьютерам через TCP в сети (хотя он без проблем подключается к нашему серверу через общедоступный IP-адрес). Еще раз спасибо за отличный ответ! - person user3693406; 09.05.2016