1

マシンで実行されている TCP サーバーと通信するデバイスがあります。私のマシンは通常、イーサネット経由でネットワークに接続されていますが、ルーターに接続するために使用できるワイヤレス アダプターもあります。デバイス (TCP クライアント) はルーター (WPA2-Personal/AES 暗号化/セキュリティ キー) に接続されています。

サーバーと通信しているイーサネット アダプターに Wireshark を搭載したデバイスが表示されます。ワイヤレスアダプタを見てもデバイスが見つかりません(IPでデバイスを探しています)。Edit > Preferences > Protocols > IEEE 802.11 wireless Lan > Decryption Keys > に移動し、wpa=pwd "password:ssid" と wep-psk "key that I generated here " を設定します。

私の PC から発信されたものではないトラフィックを確認するために Wireshark を使用したことはありませんが、この特定の例では、問題をトラブルシューティングするために必要です。どんな助けでも大歓迎です。

4

1 に答える 1

2

(私が考えている間、最初に:これの根本的な原因は暗号化とはまったく関係がありません-そうでなければ、確かに暗号化されたトラフィックが表示されますが、それでも「もの」が通過するのが見えます。)

マルチキャストまたはブロードキャストの場合、このデバイスとの間のトラフィックのみが表示されます。

これは、Wi-Fi/802.11 で AP (アクセス ポイント) と STA (ステーション) の間で通信が行われる方法によるものです。802.11 レベルでは、たとえば STA A と STA B の間のすべての「ユニキャスト」[0] 通信は、実際にはSTA A から STA B に直接行くわけではありません。最初に STA A から AP への 802.11 フレームがあり、次にAP はそれを STA B などに送信します。

そのため、デバイスがマルチキャスト/ブロードキャスト トラフィックを送信すると、これが表示されますが、これだけです (マルチキャスト/ブロードキャストへの応答は多くの場合ユニキャストです)。

このステーションから発生する可能性のあるトラフィックの一部は、たとえば ARP 要求です。これはブロードキャストであり、これをすべての STA に送信するのは AP の仕事です。これらが表示されます。

Wi-Fi コンテキストでのこのようなトラフィックのもう 1 つの非常に一般的な例は、STA が DHCP クライアントである場合です。DHCP 要求が表示されます。典型的なシナリオでは、この STA は AP へのアソシエーション/認証の直後にそのような DHCP 要求を発行します。このような場合、wireshark を実行している PC (同じ AP からの別の STA) から DHCP 要求が表示されます。DHCP 要求はブロードキャストされ、AP が配布するためです (意図的に「転送」という用語は使用しません)。ただし、典型的なシナリオでは AP が DHCP サーバーでもあるため、通常はそれ以上のことはありません。したがって、この DHCP プロセスに関する残りの通信は、AP と前述の STA の間で直接行われます。ただし、前述の DHCP クライアント STA によって発行された ARP 要求 (上記を参照) も表示されるはずです。

それほど一般的ではありませんが、それほどまれではないもう 1 つのトラフィックは、本質的にブロードキャストされるものです。

  • ICMPv6 近隣要請/広告 (デュアル IP スタックを備えた最新の OS を実行している STA から)
  • Dropbox LAN ディスカバリ プロトコル (これは通常の PC STA からは非常にノイズが多い可能性があります)
  • UPnP SSDP (ポート 1900 での UDP マルチキャスト)
  • ...そして、STA (またはもちろん DHCP などの AP) で実行されているアプリケーションによっては、さらに多くの可能性があります。

これは、AP/STA セットアップで Wi-Fi/802.11 を使用する場合に理解し、決して忘れてはならない基本的なポイントです。すべての通信は AP を介して行われ、STA 間で直接行われることはありません[2][3]。

「自分の PC から発信されたものではないトラフィックを確認するために Wireshark を使用したことがない」場合は、プロミスキャス モードの概念に慣れていない可能性がありますが、それは重要ではなく、ここでは役に立たないことに注意してください。ネットワーク インターフェイスに到着するトラフィックを確認するのに役立ちますが、通常はそのドライバーまたは OS スタックによって破棄されます。しかし、ここでは、AP は基本的な 802.11 レベルでこのトラフィックを送信しないため、トラフィックは実際にはそもそもインターフェイスに送信されません。AP の基本的な役割は、 STA であり、有線イーサネット スイッチを使用する場合と同じ状況にあり、そのようなトラフィックを確認するには、スイッチでポート ミラーリングが必要です。、スイッチは、このトラフィックを接続先のポートに送信しないほどスマートであるためです。

802.11 コンテキストでは、「通常モード」「無差別モード」の他に、 「モニター」という 3 番目のモードがあります。監視モードでは、すべてが正常に行われた場合、それは常に明らかであるとは限らないため、実行中のパケット スニッフィング PCwiresharkは STA ではなく、Wi-Fi トラフィックに参加することもありませんが、「すべてを見る」ことができます (存在する場合は暗号化されます)。暗号化されますが、wireshark役立つ場合があります)。

Wi-Fi パケット スニッフィングのトリッキーな世界については、以下を参照してください。

WLAN (IEEE 802.11) キャプチャのセットアップ

( を対象としていますが、技術的な概念は(もちろん...)などwiresharkの他のベースのツールにも適用されます)pcaplibpcaptcpdump

[0] ここでは「ユニキャスト」という用語をそのルート レベルで使用しています。つまり、「IP/レイヤー 3」という意味ではありません (802.11 レベルであり、PHY (レイヤー 1) + メディア) Access Control aka MAC (layer 2) - 媒体は「空気」ですが、より基本的には「ユニキャスト = 特定のエンティティ A から別の特定のエンティティ B への通信」です。

[1]: RFC 2131、Dynamic Host Configuration Protocol、3.1 クライアントとサーバーの相互作用 - ネットワーク アドレスの割り当て、16 ページ、パラグラフ 5 から:

クライアントは、パラメータ (割り当てられたネットワーク アドレスの ARP など) の最終チェックを実行する必要があり、DHCPACK メッセージで指定されたリース期間に注意する必要があります。この時点で、クライアントが構成されます。クライアントがアドレスが既に使用されていることを検出した場合 (たとえば、ARP の使用によって)、クライアントは DHCPDECLINE メッセージをサーバーに送信し、構成プロセスを再開する必要があります。

[2]: (ごく最近の) Wi-Fi directは、AP/STA に限定されていませんが、これは別の話題になりますが、この点で状況を変えました。

[3]: ...心配する必要はありません。これは AP ソフトウェアに負荷をかけることはありません (たとえばhostapd、これはユーザーランドの AP ソフトウェアにも影響しません)。技術的に洗練された Wi-Fi ハードウェア チップセット。

編集:

申し訳ありませんが、私はあなたの質問の「理由」を説明するのに忙しすぎて、「... 今どうすればいいですか?」を忘れていました:

...ただし、この特定のインスタンスでは、問題をトラブルシューティングする必要があります。

だから私は2つのアプローチを使用しています:

1/ モニターモードを使用します。

ただし、多くの問題が発生する可能性があります。

  • (スニッフィング) Wi-Fi ハードウェアがサポートしていない可能性があります (通常、少なくとも Linux では問題ありませんが...)。
  • お使いの OS が特定のハードウェアをサポートしていない、または必要としない場合があります (特に Windows を使用している場合は、上記の Wireshark の wiki リンクを参照してください)。
  • 無線環境は迷惑なほど騒がしいかもしれません (仕事中の私の場合)。PC をスニッフィングしているので、何かに接続されているのではなく、無線を受動的に聞いているだけなので、パケットを見逃す可能性があります (仕事中の私の場合も同様です。wireshark「ダイアログをたどる」と、「(XXX行方不明のバイト))、
  • その前に、暗号化の問題があり、物事を楽にするために非暗号化に切り替えたいと思うかもしれません。 「すべてを無駄にする。

全体として、私の経験では、監視モードを低レベルの Wi-Fi チップセットと基本的な 802.11 スタックの問題の調査に予約します。高レベルのアプリケーション プロトコルのトラブルシューティングには使用しません。でも、試してみてください。それがうまくいくなら、それでいいでしょう。

2/ トラブルシューティングを行っているデバイスで実際のスニッフィング プロセスを実行し、それを解剖ステーション ( wireshark/を実行している PC tcpdump) に転送します。

これには、デバイスでかなりの制御が必要です(いわば「私がそれらを構築する」ので、私にとっては問題ありません)。これを使用するために、SSH 接続を使用tcpdumpしてデバイス上で を起動します - かなりの前提条件があります。もちろん、デバイス上でリモート シェル機能やpcap/tcpdump実行可能ファイルがない場合、それは役に立ちません... :-/ それでも私は可能であれば、それを強くお勧めします。

ここに行きます:

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

...これはデバイス上でプロセスを起動します(もちろん、「foo」ユーザーはデフォルトの無差別モードでtcpdump起動するための適切な権限を持っている必要がありますが、問題によってはそのオプションで問題ないかもしれません)それ自体でスニッフィングし、SSHを除外しますツールが目的のトラフィックと混同しないように、それ自体を PC に送り返し、次にパイプで. そして「Voilà」、魔法を見てください!tcpdump--no-promiscuous-mode<wireless interface on the device>wireshark

お役に立てれば。

于 2016-05-07T07:29:32.043 に答える