802.11 ワイヤレススニッフィングの分析とトラブルシュート

Updated: 2024 年 1 月 16 日
Document ID:200527

偏向のない言語

この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブ ランゲージの取り組みの詳細は、こちらをご覧ください。

翻訳について

シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版（リンクからアクセス可能）もあわせて参照することを推奨します。

内容

はじめに
背景説明
正常にキャプチャするためのチェックリスト
スニファツール
Mac OS X のワイヤレス スニフィング ツール
airportd
airport utility
tcpdump
Wi-Fi 診断
エアツール
Windows 7 3.4を使用したワイヤレススニッフィング（非推奨の方法）
はじめに
Cisco Lightweightアクセスポイント(LAP)をスニファモードで使用したワイヤレススニッフィング
はじめに
設定手順
手順 1：WLC/AP 側
ステップ 2：スニファ側：Wireshark
ステップ 3：スニファ側：OmniPeek
Cisco® Autonomous(IOS)APを使用したワイヤレススニッフィング
TACサービスリクエストへのキャプチャファイルのアップロード
スニファ分析
802.11 スニファ キャプチャの分析：物理層
概要：ワイヤレスパケットキャプチャの物理層情報
ワイヤレス パケット ヘッダー：例
802.11スニファキャプチャの分析：Wiresharkフィルタリング
はじめに
Wireshark のフィルタリング：WLAN
目的
前提条件
ワイヤレススニファトレースのキャプチャが必要な理由
ワイヤレススニファキャプチャフィルタの使用が必要な理由
表示フィルタとキャプチャフィルタを使用する状況
フィルタリング方法
メニュー バー
メイン ツール バー
フィルタツールバー
パケットリストペイン
パケットの詳細ペイン
パケットバイトペイン
ステータスバー
初期ステータスバー
キャプチャフィルタの使用
表示フィルタ
色付けフィルタルールの使用
802.11 スニファ キャプチャの分析：管理フレームとオープン認証
はじめに
802.11：フレームとオープン認証
802.11 クライアント認証プロセス
管理フレーム
制御フレーム
データ フレーム
参考資料
802.11 スニファ キャプチャの分析：PSK または EAP による WPA/WPA2
WPA-PSK（TKIP）
WPA2-PSK（AES/TKIP）
Wiresharkによる無線接続パケットキャプチャでのWPA2 AESデータの復号方法
要件：
プロセス
WPA/WPA2 エンタープライズ
dot1x（EAP-TLS）による WPA（TKIP）/WPA2（AES）
802.11 スニファ キャプチャの分析：マルチキャスト
はじめに
解決方法
WLC での IGMP スヌーピング
マルチキャスト モードを使用する場合の注意点
マルチキャストの設定（マルチキャスト間モードを使用）
ワイヤレス LAN コントローラ上
有線ネットワークでのマルチキャスト設定
パケット キャプチャ
トポロジ
MCAST トラフィック ジェネレータ ツール
MCAST ジェネレータでの有線 Wireshark パケット キャプチャ
MCAST パケット ジェネレータでの Windows Netmon キャプチャ
ワイヤレス クライアントのワイヤレス インターフェイスでの Wireshark キャプチャ
ワイヤレス クライアントのワイヤレス インターフェイスでの Netmon キャプチャ
802.11 スニファ キャプチャの分析：Web 認証
はじめに
設定 WebAuth
WLCの設定
クライアントが接続を試行したときのクライアントデバッグを次に示します
参考資料

    はじめに

    このドキュメントでは、802.11 の動作を分析およびトラブルシュートするための、適切なワイヤレススニファトレースを収集するプロセスについて説明します。 

    背景説明

    このプロセスは、困難で時間のかかる作業になる可能性があります。このプロセスを簡素化および高速化するために留意すべきことがいくつかあります。ワイヤレススニッフィングを使用すると、目的を把握するのに役立ちます。ワイヤレススニフィングデバイス自体で確認できるように、未加工のワイヤレスフレームを地上波からキャプチャする必要があります。  

    正常にキャプチャするためのチェックリスト

    ステップ1：スニッフィングデバイス、クライアントデバイス、およびAPは、送信または受信にRF生成無線を使用するため、ワイヤレススニファをターゲットデバイス（クライアントマシン）の近くに配置することをお勧めします。これにより、スニフィングデバイスで、クライアントデバイスが地上波で受信する内容の概要をキャプチャできます。

    ステップ2：ワイヤレススニファとして機能する別のデバイスを使用します。テスト対象のデバイス（ワイヤレストレースを取得するクライアントマシン）で実行されている場合は、適切なワイヤレススニファトレースを取得できません。

    ステップ3：キャプチャを設定する前に、クライアントデバイスが使用する802.11チャネルと帯域を正確に理解します。対象のチャネルにスニファをロックします。スニファのスキャンチャネルモードは使用しないでください。  (スキャンチャネルでは、スニファは1秒あたりにチャネル間をサイクルします。これは、サイト調査や不正の検出に役立ちますが、802.11の問題をキャプチャしようとする場合には役立ちません)。

    また、クライアントデバイスは別のRFチャネルまたは帯域にある別のAPにローミングする可能性があるため、それに応じて計画する必要があることを念頭に置いてください。通常、802.11b/g(2.4GHz)環境では、3つのチャネルスニファが必要になる場合があります。これには、スニッフィングデバイス上で3つのワイヤレスアダプタを使用し、それぞれがチャネル1、6、および11に設定する必要があります。USBワイヤレスアダプタは、このタイプのセットアップに最適です。

    ステップ4:5 GHzのトラブルシューティングを行うと、チャネル数が大幅に増加します。すべてのチャネルをキャプチャするのに十分なカードがないため、周囲のアクセスポイントの4チャネル以下でテストを実行することをお勧めします。

      

    ステップ5：クライアントがあるチャネルから別のチャネルにローミングするときに問題を再現できる場合は、2チャネルスニファで十分です。  使用可能なチャネルスニファが1つだけの場合は、そのスニファにローミング先のチャネルをスニファさせます。

    ステップ6：スニファを常にNTPで同期します。  パケットキャプチャは、デバッグキャプチャや、他の有線または無線のキャプチャと照合する必要があります。  タイムスタンプを1秒オフにすると、照合が非常に困難になります。

    ステップ7：長時間（数時間）キャプチャする場合は、新しいキャプチャファイルを30 MB程度ごとに切り取るようにスニファを設定します。  ハードドライブがいっぱいにならないように、書き込まれるファイル数の上限を設定します。

    note-icon

    注:Linksys USB600Nでは、短いガードインターバルで11nパケットを確実に収集できるわけではありません。ショートガードインターバルパケットの20 ～ 30 %が失われます。必要に応じて、低速のロングガードインターバルのみを使用するようにWLC設定を変更できます。これは一時的な設定変更だけです。コマンドは、config 802.11 {a | b}11nsupport guard-interval {any | long}です。

    スニファツール

    OS X 10.6以降のMacを使用したワイヤレススニッフィング

    Mac でのワイヤレス スニッフィングも良好に機能します。これは Mac OS X にワイヤレス トレースをキャプチャするためのツールが内蔵されているからです。  ただし、コマンドは異なる場合があるため、実行しているOS Xのバージョンによって異なります。このドキュメントでは、OS X 10.6から最新バージョンまでをカバーしています。Wi-Fi診断は、最新のmacbookで推奨されている方法です。MacBookスニファは、スニフィングするクライアントと少なくとも同じ能力を持つ必要があることを覚えておくことは常に良いことです（802.11n MacBookで802.11acスマートフォンをスニフィングすることは最適ではありません） 。

    Mac OS X のワイヤレス スニフィング ツール

    • airportd（10.6 ～10.8）
    • airport utility（10.6 ～ 10.8）
    • tcpdump（10.8）
    • Wi-Fi 診断（10.7 → 10.12）
    • Wireshark（10.6 ～ 10.8）
    • サードパーティ製ツール：エアツール

    airportd

    OS X 10.6(Snow Leopard)以降を実行している場合は、コマンドラインユーティリティairportdを簡単に使用できます。 

    次の手順を使用します。

    • command+スペースバーのキーコンボを使用して、画面右上に検索ダイアログボックスを表示し、terminalと入力します。これにより、ターミナルアプリケーションを検索できます。このアプリケーションを選択して実行します。ターミナルウィンドウが表示されます。
    • ターミナルウィンドウを開いたら、次のコマンドを実行してRFチャネル11(802.11b/g)のワイヤレススニファトレースをキャプチャできます。

    sudo /usr/libexec/airportd en1スニファ11

    次の点に注意してください。

      • 確認のためにアカウントパスワードの入力を求められます。
      • キャプチャファイルの名前や出力を配置する場所を指定することはできません。
      • キャプチャの実行中は、ネットワークへのワイヤレス接続が失われます。
      • Airを使用する場合、ワイヤレスアダプタはen1ではなくen0です。

    トレースが終了したら、Cntl-Cキーを押してトレースを停止すると、ユーティリティによってキャプチャファイルの名前と場所が表示されます。ファイル形式は標準的な Wireshark PCAP ファイルで、Wireshark を介して Mac や Windows で読むことができます。

    airport utility

    Airport Utilityはスニファプログラムではありませんが、ワイヤレスLANに関する情報を提供できます。また、チャネルを設定できないスニファプログラム(tcpdump、Wireshark)にとって重要な、デフォルトのワイヤレスチャネルを設定する機能もあります。

    note-icon

    注：Airport Utilityへのパスが非常に不適切であるため、パス内のディレクトリからAirport Utilityへのシンボリックリンクを設定することをお勧めします。たとえば、 # sudo ln -s /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport /usr/sbin/airportのようになります。

    set the wireless channel

    # sudo /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport --channel=48

    表示されたSSID/BSSIDの情報のダンプ

    # sudo /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport -s

                  SSID      BSSID                  RSSI CHANNEL HT CC  SECURITY (auth/unicast/group)

                   テスト00:24:97:89:cb:41 -53 11 Y:WPA(PSK/TKIP/TKIP) WPA2(PSK/AES/TKIP)

                   Test2 00:24:97:89:cb:40 -53 11 N:WPA(PSK/TKIP/TKIP)

                   ゲスト00:22:75:e6:73:df -64 6,-1 Y:WPA(PSK/AES,TKIP/TKIP) WPA2(PSK/AES,TKIP/TKIP)

    現在の関連付けの詳細情報

    # sudo /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport -I

    agrCtlRSSI:-54

    agrExtRSSI: 0

    agrCtlNoise:-89

    agrExtNoise: 0

    状態：実行中

    opモード：ステーション

    lastTxRate:300

    maxRate: 300

    lastAssocStatus: 0

    802.11認証：オープン

    リンク認証：wpa2-psk

    BSSID:0:24:97:95:47:60

    SSID:GuestNet

    MCS:15

    チャネル：36、1

    tcpdump

    Tcpdumpは、パケットキャプチャを実行できるOS Xに付属のコマンドラインユーティリティです（Wiresharkにバンドルされているtsharkユーティリティとよく似ています）。  tcpdumpを使用してワイヤレスパケットキャプチャを実行するには、次の手順を実行します。

    • 最初に、チャネルを設定し、前に示したようにairportユーティリティを使用します。
    • 次に、ワイヤレスパケットキャプチャを実行し、ファイルに保存します。  完了したら、Ctrl キーを押した状態で C キーを押して終了します。

    以下に例を挙げます。

    bash-3.2# tcpdump -I -P -i en1 -w /tmp/channel-11.pcap

    tcpdump：警告： en1: IPv4アドレスが割り当てられていません

    tcpdump:en1でリスニング、リンクタイプIEEE802_11_RADIO（802.11およびradiotapヘッダー）、キャプチャサイズ65535バイト

    ^C
    897 packets captured

    968 packets received by filter

    0 packets dropped by kernel

    bash-3.2#

    Wi-Fi 診断

    最も簡単なキャプチャ方法は、Wi-Fi 診断というグラフィカル ツールを使用することです。 

    Alt キーを押しながら右上のWiFiアイコン（通常、接続先のSSIDを選択するアイコン）をクリックすると、このアイコンにアクセスできます。

    診断レポートの作成

    リストでOpen Wireless Diagnosticsオプションをクリックします。

    トラブルシューティングに関するデフォルトのレポートを実行するウィンドウが表示されます。このウィンドウは通常は使用しません。

    はじめに

    ウィンドウを開いたまま、画面上部のメニューバーに移動します。Windowをクリックします。さまざまなツールのリストが表示されます（サイト調査や信号分析に便利）。ワイヤレススニファキャプチャの範囲で、Snifferオプションをクリックして選択します。

    概要ドロップダウンメニュー

    次に、プライマリ チャネルとチャネル幅を選択する必要があります。

    スニファキャプチャは、デスクトップまたはMac Os Sierraの時点で/var/tmp/のいずれかに保存されます。

    エアツール

    また、多くのmac os xバージョンをサポートし、チャネルを選択しやすくするオプションを使用して組み込みのスニフィング機能を強化する一部のサードパーティツールも存在します。一例はエアツールです。

    Windows 7 3.4を使用したワイヤレススニッフィング（非推奨の方法）

    はじめに

    Microsoft Network Monitor(3.4)を使用すると、標準的なワイヤレスアダプタを使用して、Windows 7で適切な802.11a/b/g（および11n）ワイヤレススニッフィングを実行できます。  から保存されたファイルは、最新の（1.5以降の）Wiresharkで読み取ることができますが、OmniPeekでは読み取ることができません。Microsoftではもはやサポートされておらず、11nおよび11acアダプタで正常に動作しないことがほとんどです（ほとんどのフレームが欠落しています）。

    Netmon 3.4はXP SP3でサポートされていますが、XPを実行している場合はワイヤレススニッフィングをサポートしていません。Vistaについては、さまざまな環境で使用できます。 

    このドキュメントの「Netmon detailed」セクションは、廃止され、802.11acフレームを確実にキャプチャできないために削除されました。

    詳細については、「Netmonを使用したWindowsでのワイヤレススニッフィング」を参照してください。

    Cisco Lightweightアクセスポイント(LAP)をスニファモードで使用したワイヤレススニッフィング

    はじめに

    Cisco WLCおよびLAPは、有線スニファと組み合わせてスニファモードで使用できます（Wiresharkで最適な結果が得られます）。Omnipeekは、バージョン10の時点でプロトコルを異なる方法で復号化します)。

    単一の有線スニファで複数の AP からのパケットを収集できます。そのため、この方法は複数チャネルのトレースに極めて便利です。静的なシナリオでは、スニファAPを移動できる場合、他のスニフィングオプションの効果的な代替手段として、これを使用できます。

    ローミングのシナリオでは、スニファAPは通常、クライアントがローミングするAPの近くにインストールされます。これにより、クライアントではなくスタティックAPの「観点」が報告される場合があります。

    ローミング中にクライアントの観点からRFを確認するために、テストクライアントを使用できる複数の無線NICを搭載したラップトップでマルチチャネル無線トレースをキャプチャできます。

    設定手順

    手順 1：  WLC/AP 側

    スニファモードのLAPを使用するトレースを収集する手順を次に示します。

    スニファ モードの AP の設定：

    スニファの選択

    APがリブートして、クライアントにサービスを提供できなくなる可能性があります。 AP が WLC に加入したら、AP の無線（802.11b/g/n または 802.11a/n）を設定します。  

             

    • スニファの IP アドレスを指定します。
    • チャネルの選択
    • スニッフィングを有効にします。

    スニファの割り当て

    スニファは、カプセル化された802.11トラフィックを受信し、WLC管理IPアドレスから送信元ポートUDP/5555および宛先UDP/5000でairopeekプロトコルを使用します。

    ステップ 2：スニファ側：Wireshark

    Wiresharkを使用してトラフィックを受信する場合は、次の手順を実行します。

    • スニフィングAPからのトラフィックだけを受信するようにキャプチャオプションを設定します。ポートUDP 5000のみにフィルタを設定した場合、APでパケットをフラグメント化する必要があると、キャプチャでIPフラグメントが欠落します（これは、PEEKREMOTEカプセル化を追加する必要がある、1500バイト長のフレームをAPが傍受した場合に発生します）。

    このフィルタはオプションですが、ワイヤレスに関連しないトラフィックをすべてキャプチャから除外するため、強く推奨します。WLCがトラフィックをUDPポートに送信し、スニファ側でリスニングしているアプリケーションがないとみなします。その結果、WLCから受信する各パケットに対して、ICMPのポート到達不能の応答が発生します。


    これは期待どおりの動作ですが、フィルタは役に立たないこのトラフィックを除外するのにも役立ち、トレースが大きくなって読みにくくなるだけです。

    次に、キャプチャを開始します。

    スニファコード

    キャプチャされたトラフィックはデコードする必要があります。 PEEKREMOTEを使用して、802.11トラフィックを表示できるようにします。

    デコードと宛先ポートの選択Wireshark

    • これで、802.11トラフィックが表示されます。

    コード

    図に示されているRF情報（チャネル、信号強度、ノイズなど）は、APによって追加されます。

    ステップ 3：スニファ側：OmniPeek

    スニファモードでWLC/APからのトラフィックストリームのレシーバとしてOmniPeekを使用する場合、まず最初に、Capture OptionsウィンドウのAdapterメニューでCisco Remote Adapterを作成する必要があります。

    Omnipeekアダプタのプロパティ名

    少なくとも1つのアダプタが必要です。名前は必須フィールドですが、OmniPeekで特定のWLCからの着信トラフィックをフィルタリングしたくない場合は、IPアドレスフィールドを空白にしておくことができます。

    この場合、OmniPeekがワイヤレスLANコントローラからのデータストリームを具体的にキャプチャするためにUDPポートでリッスンするため、トラフィック（ICMPポート到達不能など）をフィルタリングする必要はありません。

    キャプチャを開始する前に、OmniPeekのメインウィンドウで次の設定を確認します。

    Omnipeekのキャプチャ開始

    この時点で、キャプチャを開始でき、結果はAPによって報告されるRF情報を含むトレースになります。

    Omnipeekパケット情報

    note-icon

    注：デフォルトでは、OmniPeekリモートアダプタはAP自体が送信したタイムスタンプを選択します。この情報はAPクロックとは無関係であるため、タイムスタンプが不正確になる可能性があります。単一のスニファAPを使用する場合、タイムスタンプが間違っている可能性がありますが、少なくとも一貫性があります。複数のAPをスニファとして使用する場合、これは当てはまりません（すべてのAPが独自のタイムスタンプ情報を送信するため、マージされたキャプチャで奇妙なタイムジャンプが発生します）。

    解決方法

    ローカル スニファ PC クロックを使用してパケットのタイムスタンプを設定するように OmniPeek に明示的に指示します。

    これにより、シングルAPとマルチAPの両方のシナリオが解決され、OmniPeekを実行するPCにNTP同期クロックがある限り、正確で一貫したタイムスタンプが提供されます。

    手順：

    OmniPeekで次の手順を実行します。

    1. 「ツール」>「オプション」>「分析モジュール」にナビゲートします。

    2. Ciscoリモートアダプタを検索し、ダブルクリックしてオプションを表示します。

    3. Timestampオプションをクリックし、OKをクリックして、再度キャプチャをテストします。

    Omnipeekアダプタオプション

    Cisco® Autonomous(IOS)APを使用したワイヤレススニッフィング

    Autonomous AP はエア パケット キャプチャの収集に使用できます。次の手順は、エアキャプチャの実行方法を示しています。

    1. キャプチャを実行するdot11radioインターフェイスを入力します。ステーションロールをスニファに設定し、Wiresharkを実行してキャプチャを収集できるサーバ/PCのIPを追加し、チャネルを選択します。monitor frames コマンドで指定するポートは、APがキャプチャを送信する宛先UDPポートにすることができます。

    コマンド
    目的

    手順 1

    int {d0 | d1}

    無線インターフェイスを設定するために、インターフェイスコンフィギュレーションコマンドモードを開始します。

    手順 2

    station-role sniffer

    ステーションロールをsnifferに変更します。

    手順 3

    channel number

    snifferモードで動作するチャネルを選択します。

    手順 4

    no shut

    インターフェイスのシャットダウンを元に戻します。

    手順 5

    exit

    インターフェイスコンフィギュレーションコマンドモードを終了します。

    手順 6

    sniffer ip-address destination-ip port port-number

    APがすべてのパケットをリダイレクトするIPアドレスとポート番号を設定します。1024 ～ 65535 の間の任意のポート番号の IP アドレスを指定できます。

    ステップ7

    wireshark enable

    エンドポイントでWiresharkを使用する場合、Wiresharkヘッダーがパケットに追加されます。

    設定例：

    ap(config)# int d0

    ap(config)-if# station-roleスニファ

    ap(config)#チャネル11

    ap(config)# no shut

    ap(config)# exit

    ap(config)# sniffer ip-address 10.10.10.1 30ポート5555

    ap(config)# wireshark enable

    2. サーバ/PCでWiresharkを起動します。[Capture] > [Options] に移動します。イーサネットNIC(LAN)を選択し、手順1で指定したUDPポートのトラフィックだけをキャプチャするフィルタを追加します。

    Wiresharkのオプション

    3. Wiresharkのキャプチャを開始します。

    TACサービスリクエストへのキャプチャファイルのアップロード

    キャプチャ ファイルが電子メールとしては大きすぎる場合は、それらのファイルを TAC サービス要求にアップロードすることができます。

    https://tools.cisco.com/ServiceRequestTool/query/

    SR番号を入力し、File Uploadをクリックします。

    スニファ分析

    ワイヤレスキャプチャを分析するには、次に示すリンクを参照してください。各ドキュメントは前のドキュメントを基に構築されているため、これらのドキュメントは順番に読むように設計されています。  ワイヤレストレースを読むときは、802.11ワイヤレス仕様を理解しておくことをお勧めします。  これらのドキュメントは、パケットフローとワイヤレストレースの検索対象を理解するのに役立ちます。802.11ワイヤレスの仕様を教えるためのものではありません。

    802.11 スニファ キャプチャの分析：物理層

    概要：ワイヤレスパケットキャプチャの物理層情報

    キャプチャされたパケットには、フレームデータのコピーが含まれていますが、各フレームの前には、フレームがどのようにキャプチャされたかに関する情報を提供するメタデータヘッダーが付加されています。  有線パケットでは、メタデータはそれほど多くありません。これは、フレーム番号、パケットがキャプチャされた日付、およびパケットの長さです。  有線パケットの分析を行う場合、物理層に関してあまり気を使うことはありません。ビットエラーレート1010の場合、キャプチャされたビットがそのようなビットであると通常は見なします。

    ワイヤレスはまったく別の話です。物理層は有線よりも複雑で信頼性が高い。  上位層に基づいてキャプチャを分析する前に、キャプチャが取得された物理層について理解しておくことをお勧めします。  物理層が正しく動作していない場合、上位層には機会がありません。

    物理層の品質は、特に次の点に注意する必要があります。

    信号強度（RSSI、信号強度、信号対雑音比）  可能であれば、RSSIに焦点を当てることが一般的に最適です。スニッフィングアダプタがパケットを受信した電力レベル(dBm): 

    • RSSI < -90 dBm：この信号は非常に弱く、レシーバが受信できる限界まで達しています。
    • RSSI -67dBm：これはかなり強い信号で、Voice over WLANのサポートに十分であるとシスコが考える限界を示しています。
    • RSSI > -55dBm：これは非常に強い信号です。
    • RSSI > -30dBm：スニファがトランスミッタのすぐ隣にあります。

    チャネル（周波数）。ワイヤレスLANは3 ～ 25個程度の異なるチャネルをサポートできるため、どのチャネルからキャプチャを取得したかを正確に知ることが重要です。  特定のAPからスニッフィングを受ける場合は、そのAPのチャネルにスニッフィングをロックし、そのチャネルでキャプチャが行われたことを検証します。そうでない場合、キャプチャは役に立ちません。

    .

    データレートは1 Mbpsから300 Mbps以上まで任意です。  データ伝送が常にトランスミッタからレシーバに行われるとは限らない理由を理解するには、使用されているデータレートを把握する必要があります。  「限界」の–80dBmのRSSIは、54Mbpsで変調されたパケットに対しては非常に有効ですが、6Mbpsでは非常に満足できる場合があります。

    ワイヤレス パケット ヘッダー：例

    異なるワイヤレススニファは、異なるメタデータヘッダー形式を使用してワイヤレス物理層をエンコードできます。  情報の精度は使用している特定のアダプタ ハードウェアとドライバによって異なります。  ノイズなどの一部の値は、一般に考慮されます。

    これらのサンプルでは、data rate、frequency、およびRSSIのフィールドが強調表示されています。

    Mac OS X 10.7ワイヤレス診断（Broadcomアダプタ）

    OS X 10.7 は Radiotap v0 ヘッダーを使用します。Wireshark では次のように表示されます。

    スニファコードの表示

    OmniPeek 6.8（Ralink USB アダプタ）

    Wireshark では、次に示すように OmniPeek キャプチャに Airopeek ヘッダーが使用されます。

    スニファデータレート、チャネルおよび信号強度

    Wireshark（1.6.xの時点）では、OmniPeekキャプチャのすべてのワイヤレスメタデータのデコード方法が認識されていません。OmniPeek自体で表示される同じフレームは、信号dBm、ノイズレベル、およびノイズdBmを示します。

    スニファの結果

    Netmon 3.4

    スニファ802.11の周波数

    ワイヤレスファイルをWireshark列として適用しています。

    ワイヤレスフィールドをカラムとして適用すると、ワイヤレススニファで何が行われているかがはるかに簡単に理解できます。これを行う方法を次に示します。

    1.パケットの詳細セクションで対象のフィールドを探し（必要に応じて最初に該当するヘッダーセクションを展開します）、それを右クリックします。  Apply as Columnを選択します。

    Snifferドロップダウンメニュー

    2. 新しい列が表示されます。  これで、列ヘッダーを右クリックしてEdit Column Detailsを選択することで、サイズの変更、名前の変更、および必要に応じた列の移動を行うことができます。

    3.  対象の他のカラムに対してステップ 2 を繰り返します。  これで、キャプチャの物理層の側面をより適切に処理できるようになりました。

    スニファデータ

    4. 新しい列を適用すると、次にWiresharkを実行したときにその列を使用できます(表示されていない場合は、列見出しを右クリックして[Displayed Columns]を選択します)。

    802.11スニファキャプチャの分析：Wiresharkフィルタリング

    はじめに

    802.11 スニファ キャプチャの分析：Wireshark フィルタリング

    Wireshark のフィルタリング：WLAN

    目的

    このドキュメントは、Wiresharkを設定し、Wiresharkフィルタと呼ばれる汎用ツールをWiresharkプログラム内で使用する対象パケットを分析する方法を説明するのに役立ちます。

    前提条件

    プロトコル、ネットワークのトポロジ、およびスニファトレースの実行に考慮すべきデータポイントについての十分な知識と理解がない限り、Wiresharkツール自体はトラブルシューティングプロセスの実行に役立ちません。これは、有線ネットワークの場合も、ネットワークに入る前に無線接続のパケットをキャプチャするワイヤレスネットワークの場合も同様です。ワイヤレス MAC アドレスのストリッピングは、AP によって行われます。

    ワイヤレススニファトレースのキャプチャが必要な理由

    有線スニファトレースを使用する有線ネットワーク上のトラフィックまたはデータを検査したときに、対象パケットが見つからない場合は、それがどこで損失するかを知る必要があります。疑いを持つことで、ワイヤレス、正常、または正常に動作する（無線通信中に損失する）発信元の最初のポイントを通過したかどうかを確認できます。無線で正しく送信されなかった場合は、APによってDSまたは配信システムに有線側で送信されていないか、変換できないか、または有線側に送信されないことが明らかです。そのため、ワイヤレススニファトレースを使用してワイヤレスネットワークの問題を特定し、ローカライズすることが重要になります。

    ワイヤレススニファキャプチャフィルタの使用が必要な理由

    ネットワーク関連の問題のトラブルシューティングに関しては、多くの依存関係があり、階層化モデル内のすべての作業とデータの各層はその下の下位層に依存します。ネットワークには多くのコンポーネント、つまりネットワーク要素があり、デバイスの設定と適切な操作によって、ネットワークをスムーズに運用できます。稼働中のネットワークが機能しなくなった場合は、問題をローカライズするための論理的なアプローチが必要です。特定された障害ポイントを正確に特定することは困難です。このような状況では、スニファが助けになります。このトラブルシューティングプロセスは、最善のアプローチを行っても、またトラブルシューティングのスキルに精通している場合でも、複雑になる可能性があります。問題は、ネットワークデバイスを通過するパケットをキャプチャした場合に大きなファイルが生じる可能性があり、大量のパケットの詳細を含めて長時間キャプチャした場合は1Gで終わることもあります。このように大量のデータがあると、問題の正確な特定に非常に時間がかかり、非常に困難な作業になる可能性があります。 フィルタリングは救援に来て、問題をすばやく見つけ、不要なトラフィックを排除し、一度に焦点を当てる変数を削減するのに役立ちます。これは、対象トラフィックが収集されたトラフィックに存在するかどうかを迅速に検出するのに役立ちます。 

    • 表示フィルタ：多くの情報をキャプチャした後、これらのフィルタは対象とするパケットのみを表示するのに役立ちます。
    • キャプチャフィルタ：対象のパケットがどのようなものであるかを最初から把握しており、それらのパケットのみをキャプチャします。
    • パケットを色付けするフィルタ：表示フィルタまたはキャプチャフィルタを強化するための視覚的なサポートとして使用するか、または高度なアプローチのために多くの異なるパケットをさまざまな色で分類するためにフィルタなしで使用することができます。

    表示フィルタとキャプチャフィルタを使用する状況

    何を検索すべきかがわかっている場合は、キャプチャフィルタを使用して、そのイベントへのトラフィックを実行する際にそれを確認することをお勧めします。これは、トラフィック量の多い環境で数時間を超えて実行した場合にキャプチャされます。これにより、ファイルサイズの観点から収集するデータを妥当な量に保つことができます。

    問題の原因が不明で、しかも動作がランダムな場合は、問題の発生パターンが疑われる時間内（たとえば1時間か2時間）にパケットキャプチャを実行して、すべてのトラフィックをキャプチャします。次に、表示フィルタを使用して、検索する情報のみを表示します。 この使用に加えて、すべてのキャプチャを表示し、色付けルールを使用して、パケットフローを簡単に分類または区別できるように異なる色を割り当てた特定のタイプのパケットを確認できます。

    フィルタリング方法

    一般的なWiresharkスニファトレース内のさまざまなフィールドを理解する必要があります。分割して各フィールドを定義します。

    フィルタリングを使用するために理解しておく必要がある3つの項目に焦点を当てます。

    • キャプチャ フィルタ
    • 表示フィルタ
    • 色付けルール フィルタ

    詳細を掘り下げる前に、Wiresharkのスニファキャプチャウィンドウの例を次に示します。

    メニュー バー

    メニューオプション1

    これはWire Sharkウィンドウのメニューバーです。

    次の項目が含まれます。

    • File：このメニューには、キャプチャファイルを開いてマージするための項目、キャプチャの保存/印刷/エクスポートのための項目が含まれています

    ファイルの全体または一部を保存し、Wiresharkを終了します。

    • 編集：このメニューには、パケットを検索したり、時間基準を設定したり、1つ以上のパケットをマークするための項目が含まれます

    パケット、設定プロファイルの処理、プリファレンスの設定（切り取り、コピー、貼り付け）

    は現在実装されていません）。

    • ビュー：このメニューは、キャプチャされたデータの表示を制御します。これには、以下の色の付けが含まれます。

    packets、フォントのズーム機能、別のウィンドウにパケットを表示し、

    パケット詳細のツリーを折りたたみます。

    • Go：このメニューには、特定のパケットに移動するための項目が含まれています。
    • キャプチャ：このメニューでは、キャプチャの開始と停止、およびキャプチャフィルタの編集を行うことができます。
    • Analyze：このメニューには、表示フィルタを操作したり、

    プロトコルの分析、ユーザ指定のデコードの設定、TCPストリームの使用を行います。

    • 統計情報：このメニューには、要約を含む各種統計情報ウィンドウを表示するための項目が含まれています

    キャプチャされたパケットの概要、プロトコル階層の統計情報の表示など

    が表示されます。

    • テレフォニー – このメニューには、テレフォニー関連のさまざまな統計ウィンドウを表示する項目が含まれています。

    これには、メディア分析、フロー図、表示プロトコル階層の統計情報、

    表示されます。

    • ツール：このメニューには、ファイアウォールの作成方法など、Wiresharkで使用できるさまざまなツールが含まれています

    います。

    • Internals：このメニューには、Wiresharkの内部に関する情報を表示する項目が含まれています。
    • ヘルプ：このメニューには、ユーザが基本的なヘルプやマニュアルにアクセスする際に役立つ項目があります

    さまざまなコマンド ライン ツールのマニュアル ページ、一部の Web ページへのオンライン アクセス、

    通常のバージョン情報のダイアログなどがあります。

    メイン ツール バー

    メニューオプション2

    メイン ツールバーでは、頻繁に使用される項目にメニューから簡単にアクセスできます。このツールバーはカスタマイズできませんが、画面のスペースがさらにパケットデータを表示するために必要な場合は、[表示]メニューで非表示にできます。メニューと同様に、現在のプログラムの状態で役に立つ項目のみを使用できます。その他のオプションはグレー表示される場合があります。（たとえば、キャプチャファイルをロードしていない場合は、そのファイルを保存できません）。

    フィルタツールバー

    メニューオプション3

    フィルタツールバーを使用すると、表示フィルタをすばやく編集して適用できます。

    [フィルタ]：フィルタ作成ダイアログボックス、[キャプチャフィルタ]および[表示フィルタ]ダイアログボックスを表示します。

    • 領域の入力をフィルタして、表示フィルタの文字列式を入力または編集します。入力中にフィルタ文字列のシンタックスチェックが行われます。完全でないまたは無効な文字列を入力すると背景が赤に変わり、有効な文字列を入力すると緑になります。プルダウン矢印をクリックすると、以前に入力したフィルタ文字列をリストから選択できます。プルダウンリストのエントリは、プログラムを再起動した後も使用可能なままです。
    • このフィールドの内容を変更した後、このフィルタ文字列を画面に適用するために、[適用]ボタン（またはEnter/Returnキー）を押すことを忘れないでください。また、このフィールドには現在有効なフィルタも表示されます。
    • 式： 「式の追加…」というラベルが付いた中央のボタンをクリックすると、ダイアログ・ボックスが開きます。このダイアログ・ボックスでは、「フィルタ式」ダイアログ・ボックスで説明されているプロトコル・フィールドのリストから表示フィルタを編集できます。
    • クリア：現在の表示フィルタをリセットし、編集領域をクリアします。
    • 編集領域の現在の値を新しい表示フィルタとして適用します。

    パケットリストペイン

    [Packet List] ペインには、現在のキャプチャ ファイル内のすべてのパケットが表示されます。

    パケット リストの各行はキャプチャ ファイルの 1 つのパケットに対応します。このペインで回線を選択すると、[Packet Details]ペインと[Packet Bytes]ペインに詳細が表示されます。

    メニューオプション4

    パケットの詳細ペイン

    パケット詳細ペインには、現在のパケット（[パケットリスト]ペインで選択したパケット）がより詳細な形式で表示されます。

    メニューオプション5

    パケットバイトペイン

    パケットバイトペインには、パケットリストペインで選択されている現在のパケットのデータが

    hexdump 形式で表示されます。

    メニューオプション6

    ステータスバー

    ステータスバーには、情報メッセージが表示されます。一般に、左側にはコンテキスト関連情報、中央部には現在のパケット数、右側には選択した設定プロファイルが表示されます。サイズを変更するには、テキスト領域間のハンドルをドラッグします。

    初期ステータスバー

    このステータスバーは、キャプチャファイルがロードされていないときに表示されます。たとえば、Wiresharkが起動したときなどです。

    メニューオプション7

    タブラベルのコンテキストメニュー（右クリック）には、使用可能なすべてのページのリストが表示されます。これは、ペインのサイズが小さすぎてすべてのタブ ラベルを表示できない場合に便利です。

    ステータスバー

    メニューオプション8

    ステータス バーには情報メッセージが表示されます。一般に、左側にはコンテキスト関連情報、中央部には現在のパケット数、右側には選択した設定プロファイルが表示されます。サイズを変更するには、テキスト領域間のハンドルをドラッグします。

    キャプチャファイルがロードされている状態のステータスバー。

    • 左側には、キャプチャファイルに関する情報、名前、サイズ、およびキャプチャファイルがキャプチャされてからの経過時間が表示されます。
    • 左側の色付けされた行頭文字は、現在ロードされているキャプチャ ファイルの中で最も専門性が高い情報レベルであることを示します。このアイコンの上にマウスを置くと、エキスパート情報レベルのテキスト説明が表示されます。アイコンをクリックすると、[エキスパート情報]ダイアログボックスが表示されます。
    • 中央部には、キャプチャ ファイル内の現在のパケット数が表示されます。

    次の値が表示されます。

    • Packets：キャプチャされたパケットの数
    • Displayed：現在表示されているパケットの数
    • Marked：マークされたパケットの数
    • Dropped：ドロップされたパケットの数（Wiresharkですべてのパケットをキャプチャできなかった場合にのみ表示されます）。
    • Ignored：無視されたパケットの数（パケットが無視された場合のみ表示）
    • 右側には、選択した設定プロファイルが表示されます。ステータスバーのこの部分をクリックすると、使用可能なすべての設定プロファイルを含むメニューが表示され、このリストから選択すると、設定プロファイルが変更されます。

    メニューオプション9

    キャプチャフィルタの使用

    Capture Interfaces optionsをクリックして、PC上のネットワークで実行中のパケットをキャプチャするために使用されるNetwork adapter fromドロップダウンメニューを選択します。Capture Filtersをクリックして、フィルタ名とフィルタ文字列を入力するか、ボックスに既知のフィルタ文字列を直接入力します。次にボタンを押します。これで、Wireshark スニファ プログラムが、すべてのタイプのプロトコルのリアルタイム パケットの膨大なフローの中から対象のパケットのみをキャプチャします。

    メニューオプションWireshark

    メニューオプション10

    表示フィルタ

    キャプチャしたファイルをロードしたら、フィルタを設定して、対象とするパケットを表示したり、対象としないパケットを回避したりできます。これは、単純なフィルタ式、または論理演算子を使用して複雑なフィルタ文字列を形成する式の組み合わせを通じて実行できます。

    Analyzeをクリックします。Display Filterを選択します。

    この例では、黄色で強調表示された領域に示されているように、フィルタを作成して、802.11ワイヤレスパケットキャプチャトレースからビーコンパケットのみをフィルタリングします。

    メニューオプション新規

    表示フィルタと同様に、Find packetをクリックした後にフィルタを適用すると、特定のパケットを検索できます。

    Filterボタンを探し、フィルタボックスにフィルタ値を入力します。文字列がわからない場合は、さらにフィルタリングをクリックして、Newボタンを押し、フィルタ文字列に名前を付けて、ボックスにフィルタ文字列を適用または入力できます。特定のフィルタスプリングがわからない場合は、それを形成して、さまざまなプロトコルオプションがあるExpressionボタンを選択できます。

    必要なオプションを選択して展開すると、さらに多くのオプションから選択できます。

    また、フィルタを完成させるために配置して適用する値を入力するために使用する論理演算子ボックスもあります。

    メニューオプション11

    多くの異なる比較演算子を使用する値を比較する表示フィルタを作成できます。

    メニューの説明と例

    メニューリストの例

    色付けフィルタルールの使用

    Wireshark で使用可能な非常に便利な機能が、パケットの色付けです。フィルタに従ってパケットが色付けされるようにWiresharkを設定できます。これにより、対象とするパケットを強調できます。 作成するフィルタに応じてパケットを色付けできるようにWiresharkを設定できます。こうすることで、（通常）対象とするパケットを強調することができます。

    この例では、ビーコン、確認応答、プローブ応答、および認証解除のパケットが、前述のフィルタに基づいて色付けされています。

    [View] をクリックします。メインツールバーからColoring rulesまたはEdit coloring rulesを選択します。

    全方向性メニュー

    色付けルールが開き、NewまたはEditを使用して新しい色付けフィルタを追加できます。パケットを選択するか、フィルタ文字列を編集して、必要な色を割り当てるか調整します。

    全方向編集オプション

    [色を編集]ダイアログボックスで、カラーフィルタの名前を入力し、[フィルタ]テキストフィールドにフィルタ文字列を入力します。Edit Color Filterダイアログボックスに、値beaconおよびwlan.fc.type_subtype == 8が表示されます。これは、カラーフィルタの名前がBeaconであり、フィルタはビーコンフィルタ文字列であるタイプwlan.fc.type_subtype == 8のプロトコルを選択できることを意味します。これらの値を入力すると、フィルタ式に一致するパケットの前景と背景の色を選択できます。これを行うには、Foreground color...またはBackground color...をクリックします。

    非常に便利な機能は、色付けフィルタをエクスポートまたは形成し、例に示すようにフィルタをファイル「tac80211color」にエクスポートして保存することです。これはインポートできます。トラブルシューティングフォルダに複数の色付けルールファイルを作成し、トラブルシューティングのたびにテンプレートとして使用できます。

    ルーティング、WLAN、スイッチングなどの色付けフィルタテンプレートファイルを革新的に考え、カスタマイズすることができます。カラーフィルタファイルを使用して、トラブルシューティングする問題に応じてファイルをインポートします。

    ダウンロードして使用できる優れた色付けルールがありますサポートフォーラム – 色付けルール

    全方向性ファイル名を入力

    次に、カラー フィルタ ファイル

    tac80211colorがインポートされ、適用されます。

    オムニファイナル

    802.11 スニファ キャプチャの分析：管理フレームとオープン認証

    はじめに

    802.11 スニファ キャプチャの分析：管理フレームとオープン認証

    802.11：フレームとオープン認証

    802.11パケットアナライザを使用するワイヤレスLANネットワークを分析またはトラブルシューティングする際には、ポインタを見つけるための基礎としてさまざまな802.11フレームタイプを完全に理解して、WLANネットワーク内の問題領域の原因を特定する必要があります。OmnipeekやWiresharkなどのツールを使用して、無線ネットワークインターフェイスカード(NIC)とアクセスポイント間の通信を監視できるWLANスニファトレースを使用します。ワイヤレスLANの運用で発生する各フレームタイプを理解し、ネットワークの問題を解決する必要があります。WLAN RF 環境では無線の伝送条件があまりにも動的に変化する可能性があるために、調整は WLAN の大きな課題となります。管理パケットや制御パケットがこれらの調整機能を担います。

    RF環境に関連するWLANネットワークで発生するWLAN問題の原因を見つけるには、セキュリティを一切利用せずにオープン認証を使用してWLANネットワークをテストするのが最善です。このアプローチを採用すると、RF接続の問題が表面化し、強力な暗号化やOSI層の上位層に移行する前に修正できます。 802.11 仕様での認証は、ユーザの認証ではなく、ワイヤレス ステーションやデバイスの認証に基づいています。

    802.11仕様のクライアント認証プロセスに従い、前述のトランザクションを示します。

    1. アクセスポイントは、隣接するwlanクライアントによって受信されたビーコンフレームを継続的に送信します。
    2. クライアントは、各チャネルの独自のプローブ要求フレームでブロードキャストすることもできます。
    3. 範囲内のアクセスポイントは、プローブ応答フレームで応答します。
    4. クライアントは、アクセスに最適なアクセスポイント(AP)を決定し、認証要求を送信します。
    5. アクセスポイントが認証応答を送信します。
    6. 認証に成功すると、クライアントは関連付け要求フレームをアクセスポイントに送信します。
    7. アクセスポイントがアソシエーション応答で応答します。
    8. これで、クライアントからアクセスポイントにトラフィックを渡せるようになりました。

    802.11 クライアント認証プロセス

    1.png

    ワイヤレスリンクを管理および制御する、無線接続時に発生する802.11 MACレイヤ2通信で使用されるフレームは3種類あります。

    2.png

    これらは、管理フレーム、制御フレーム、データ フレームです。これらのフレームの構成要素を詳細に学習すると、WLANスニファトレースで作業している間にWLANの問題をより適切に分析するのに役立ちます。

    管理フレーム

    802.11 管理フレームは、ステーションが通信を確立し、維持できるようにします。管理パケットは、認証、関連付け、および同期化のサポートに使用されます。

    次に、一般的な802.11管理フレームのサブタイプを示します。

    • 認証フレーム：これは、WLANトポロジ内のネットワークメンバーシップを示すフレームです。802.11 認証は、リソースを作成するために無線 NIC のアイデンティティをアクセスポイントが許可または拒否するプロセスです。認証によってネットワーク上で送受信する機能を制限します。これは、デバイスが802.11 WLANへの接続を試みる最初のステップです。この機能は、管理パケットの交換によって処理されます。認証は、管理パケットの要求/応答の交換によって処理されます。交換されるパケットの数は、使用される認証方式によって異なります。 

    wlan.fc.type_subtype == 0x0b

    4.png

    5.png

    NIC がその ID を含む認証フレームをアクセス ポイントに送信することによって、このプロセスを開始します。オープン システム認証（デフォルト）では、無線 NIC が認証フレーム 1 つのみを送信し、アクセス ポイントが応答として許可（または拒否）を示す認証フレームで応答します。ネットワークに参加した時点で現在のステーション自体が認証される名前に関連付けられた認証 ID があります。

    • 認証解除フレーム：セキュア通信を終了する場合に、別のステーションに認証解除フレームを送信する、ステーションによるアナウンスパケットです。認証局（BSS または機能的に同等のもの）からの一方向通信であり、受け入れる必要があります。このフレームは、直ちに有効になります。

    wlan.fc.type_subtype == 0x0c

    6.png7.png

    8.png

    • 関連付け要求フレーム：802.11関連付けにより、アクセスポイントは無線NICにリソースを割り当て、そのNICと同期できます。NIC は関連付け要求をアクセス ポイントに送信することによって関連付けプロセスを開始します。このフレームは、NICに関する情報（たとえば、サポートされているデータレート）と、関連付けるネットワークのSSIDを伝送します。関連付け要求を受信すると、アクセス ポイントは NIC との関連付けを検討し、（承認する場合は）メモリスペースを予約して NIC の関連付け ID を確立します。パケットは、送信者の現在の関連付けを示すことができます。関連付けと再関連付けは、要求/応答管理パケットで処理します。

    wlan.fc.type_subtype == 0x0

    00.png10.png11.png

    • 関連付け応答フレーム：アクセスポイントは、関連付けを要求する無線NICに対する承認または拒否通知を含み、要求者の関連付けIDを含む関連付け応答フレームを送信します。アクセスポ イントが無線 NIC を承認すると、フレームは関連付け ID やサポート対象のデータ レートなどの関連付けに関する情報を組み込みます。関連付けの結果が良好である場合、無線NICはアクセスポイントを利用してネットワーク上の他のNICや、アクセスポイントの配信側のシステムと通信できます。

    wlan.fc.type_subtype == 0x01

    12.png

    13.png

    14.png

    • 再関連付け要求フレーム：このフレームは、関連付け要求と似ていますが、目的が異なり、主にクライアントローミングで役立ちます。無線NICが現在関連付けられているアクセスポイントからローミングして、より強いビーコン信号を持つ別のアクセスポイントを検出した場合、無線NICは新しいアクセスポイントに再関連付けフレームを送信します。次に、新しいアクセスポイントは、無線NICへの送信を待機している以前のアクセスポイントのバッファにまだ格納されている可能性があるデータフレームの転送を調整します。正常に関連付けられるようにするには、送信者は前もって認証されている必要があります。

    wlan.fc.type_subtype == 0x02

    15.png

    16.png

    17.png

    • 再関連付け応答フレーム：アクセスポイントは、承認通知または拒否通知を含む再関連付け応答フレームを、関連付けを要求している無線NICに送信します。関連付けプロセスと同様に、このフレームは関連付け ID やサポート対象のデータ レートなどの関連付けに関する情報を組み込みます。
    • 関連付け解除フレーム：関連付けを終了する場合、ステーションは別のステーションに関連付け解除フレームを送信します。たとえば、正常にシャットダウンしている無線 NIC が関連付け解除フレームを送信して NIC の電源が切れていることをアクセス ポイントに警告します。アクセス ポイントはメモリ割り当てを放棄し、関連付けテーブルから無線 NIC を削除します。関連付け解除はアクセス ポイントまたはデバイスからのシンプルな宣言です。

    適用および関連付け解除パケットのみの検出に使用されるフィルタは、wlan.fc.type_subtype == 0x0aです。

    18.png

    19.png

    20.png

    • ビーコンフレーム：アクセスポイントは定期的にビーコンフレームを送信してその存在とタイムスタンプなどのリレー情報をアナウンスします。これにより、メンバーステーションとBSS、SSID、および範囲内にある無線NICへのアクセスポイントに関するその他のパラメータとの同期が容易になります。このフレームの目的は、Contention Free Period（CF；コンテンションフリー期間）の開始をアナウンスし、ポーリングすることでアクセスポイントによってどの送信権が付与されるかをアナウンスすることです。無線NICはすべての802.11無線チャネルを継続的にスキャンし、ビーコンを受信して、最適な信号を持ち、関連付けられるアクセスポイントとアベイラビリティを選択する基盤となります。

    適用およびビーコンパケットのみの検出に使用されるフィルタは、wlan.fc.type_subtype == 0x08です。

    21.png

    22.png

    23.png

    • プローブ要求フレーム：ステーションまたはクライアントがアクティブになる、またはPC上でWLANカードが有効になっている場合はアクティブになり、別のステーションまたはアクセスポイントから情報を取得する必要がある場合はプローブ要求フレームを送信します。無線NICがプローブ要求を送信して範囲内にあるアクセスポイントを判別した後、クライアントがサポートするすべてのチャネルで、SSIDとクライアントが要求したデータレートに一致する範囲内のすべてのアクセスポイントを見つけるために、プローブ要求フレームが送信されます。サポートされているデータレートやアクセスポイントの負荷などのさまざまな要因を考慮して関連付けるアクセスポイントを決定し、最適なアクセスポイントを選択して、プローブ応答としてApから応答を取得した8802111ネットワークの認証認証段階に移行します。このメカニズムのサポートにより、ローミングステーションは、新しいアクセスポイントを検索する際に接続状態を維持しながら、セル間を移動できるようになります。

    適用およびプローブ要求パケットのみの検出に使用されるフィルタは、wlan.fc.type_subtype ==0x04です。

    24.png

    25.png

    26.png

    • プローブ応答フレーム：プローブ要求への応答では、基準に一致するAPSが、同期情報とアクセスポイント負荷を含み、機能情報やサポート対象のデータレートなどを含むプローブ応答フレームで応答します。

    適用およびプローブ要求パケットのみの検出に使用されるフィルタは、wlan.fc.type_subtype ==0x05です。

    27.png

    28.png

    29.png

    制御フレーム

    802.11 制御フレームは、ステーション間でのデータ フレームの配信をサポートします。次に、一般的な802.11制御フレームのサブタイプを示します。

    • 送信要求(RTS)フレーム：RTS/CTS機能はオプションであり、隠れステーションに同じアクセスポイントとの関連付けがある場合に発生するフレーム衝突を削減します。ステーションは、データ フレームの送信前に必要な 2 ウェイ ハンドシェイクの第一段階として RTS フレームを別のステーションに送信します。

    wlan.fc.type_subtype == 0x1B

    30.png

    34.png

    35.png

    • 確認応答(ACK)フレーム：データフレームの受信後、受信側ステーションはエラーを利用してプロセスをチェックし、エラーの存在を検出します。受信側ステーションは、エラーが見つからなかった場合はACKフレームを送信側ステーションに送信します。送信側ステーションが一定の時間が経過してもACKを受信しない場合、送信側ステーションはフレームを再送信できます。

    wlan.fc.type_subtype == 0x1D

    36.png

    37.png

    38.png

    データ フレーム

    これらは、基本的なWLAN通信がモバイル端末とアクセスポイント間ですでに確立された後にゲームに着信するフレームです。分析のために常に802.11データフレームに到達しますが、これは通常、フレーム本体内の上位層からのプロトコルやデータがワイヤに到達した場合に、無線接続を確認して分析するためです。これらのフレームは、Webページやプリンタ制御データなどの上位レイヤからのデータパケットをフレーム本体内で転送します。

    wlan.fc.type_subtype == 0x20

    39.png

    40.png

    41.png

    パケットアナライザで、問題の対象となっている802.11データフレーム内のフレーム本体の内容を監視できます。

    参考資料

    802.11 スニファ キャプチャの分析：PSK または EAP による WPA/WPA2

    WPA-PSK（TKIP）

    1.ビーコンフレームは、ワイヤレスネットワークの存在をアナウンスするために定期的に送信され、それに関するすべての情報（データレート、チャネル、セキュリティ暗号、キー管理など）が含まれます。

    WPA-PSK-TKIP-Beacon.png

    2.プローブ要求がAPから情報を取得するためにSTAによって送信されます。

    WPA-PSK-TKIP-Probe-req.png

    3.プローブ応答。APは、STAからプローブ要求フレームを受信した後、機能情報やサポート対象のデータレートなどを含むプローブ応答フレームで応答します。

    WPA-PSK-TKIP-Probe-res.png

    4.802.11認証は、アクセスポイントが無線NICのアイデンティティを受け入れるか拒否するかのいずれかのプロセスです。NICは、そのIDを含む認証フレームをアクセスポイントに送信することによって、このプロセスを開始します。オープンシステム認証（デフォルト）では、無線NICが認証フレーム1つのみを送信し、アクセスポイントが応答として許可（または拒否）を示す認証フレームで応答します。:

    a.Dot11認証要求：

    WPA-PSK-TKIP-Auth-req.png

    b.Dot11認証応答：

    WPA-PSK-TKIP-Assos-res.png

    5. 802.11関連付けは、アクセスポイントが無線NICにリソースを割り当て、そのNICと同期できるようにします。NIC は関連付け要求をアクセス ポイントに送信することによって関連付けプロセスを開始します。このフレームは、NICに関する情報（たとえば、サポートされているデータレート）と、関連付けるネットワークのSSIDを伝送します。

    a.Dot11関連付け要求：

    WPA-PSK-TKIP-Assos-req.png

    関連付け要求を受信すると、アクセス ポイントは NIC との関連付けを検討し、（承認する場合は）メモリスペースを予約して NIC の関連付け ID を確立します。

    b.Dott11アソシエーション応答：

    WPA-PSK-TKIP-Auth-res.png

    6.4ウェイハンドシェイクこのフェーズでPTKが作成され、PSKをPMKとして使用してそれらの値が作成されます。

    a.APは802.1x認証フレームをANonceで送信します。STAはPTKを構築するためのすべての情報を入手します。

    WPA-PSK-TKIP-Key-1.png

    b.STAは802.1x認証フレームにSNonceとMICで応答します。

    WPA-PSK-TKIP-Key-2.png

    c.APは、新しいMICとシーケンス番号付きのGTKで802.1xフレームを作成します。 このシーケンス番号は、受信側STAが基本的なリプレイ検出を実行できるように、次のマルチキャストフレームまたはブロードキャストフレームで使用されます。

    WPA-PSK-TKIP-Key-3.png

    d.STAがACKを送信します。

    WPA-PSK-TKIP-Key-4.png

    そのポイントから、すべてのデータが暗号化されて送信されます。

    WPA2-PSK（AES/TKIP）

    プロセスは前のセクションとほぼ同じです。異なる情報だけが強調表示されます。

    1.WPA2 AP管理フレームには、ユニキャスト暗号スイート、AKM情報、およびGTK暗号スイートを含むRSN要素が含まれています（AESとTKIPの両方を選択した場合、GTKではより強力な暗号化方式を使用できます）。

    image012.png

    2. 4ウェイハンドシェイク時に、フレームのTypeフィールドにWPA2のバージョン情報が含まれます。

    image013.png

    note-icon

    注：トレースに4ウェイハンドシェイクキー交換フレームが含まれており、PSKがわかっている場合は、WEP/WPA-PSK/WPA2-PSK暗号化ワイヤレストラフィックを復号できます。

    Wiresharkでワイヤレストラフィックを暗号化するには、Preferences-> Protocols->IEEE 802.11の順に移動し、PSK情報を入力してEnable decryption optionを選択します。

    WPA/WPA2 暗号化トラフィックを復号するには、次の形式でキーを指定します。

    wpa-psk:PSK:SSI

    note-icon

    注:Wiresharkの特定のSTAからWLANトラフィックをフィルタリングして排除するには、WLAN統計情報オプションを使用できます。

    特定のSTAからのトラフィックをフィルタリングするには、Statistics > WLAN Trafficの順に選択します。 SSIDのリストから、STAに関連付けられている対応するSSIDを選択し、STAに基づいてフィルタを適用します。

    image014.jpg

    Wiresharkによる無線接続パケットキャプチャでのWPA2 AESデータの復号方法

    要件：

    1. キャプチャは.pcap形式です。
    2. フレームは802.11形式で表示されます。
    3. Over the Air Capture が収集された WLAN の SSID 名と PSK がわかっています。
    4. キー：4つのEAPOL 4ウェイハンドシェイクをキャプチャします。

    これを行う最も正確なプロセスは、キャプチャを開始し、ゼロからプロセスをキャッチするためにクライアントの認証を解除することです。つまり、4ウェイEAPOLハンドシェイクを含めることができます。

    フレームがPEEKREMOTEなどの別の形式の場合、フレームをデコードする必要があります。PEEKREMOTEフレームをデコードする方法に関するセクションを参照してください。

    プロセス

    Wiresharkでキャプチャを開いたら、Edit > Preferencesメニューに移動します。

    Protocolsメニュー

    Protocolsメニューに移動し、IEEE 802.11を探します。

    プロトコルオプションIEEE 802.11

        

    IEEE 802.11セクションから、Enable Decryptionチェックボックスにチェックマークを入れて、Decryption Keysラベルの横にあるEdit...ボタンをクリックします。

    IEEE 802.11を選択

    Editメニューが表示されたら、ウィンドウの左側にあるNewボタンをクリックします。

    新規を選択

    キータイプから、wpa-pskを選択します。

    キーを取得するには、復号化プロセスを実行するSSIDとPSKの正確な名前を知ることが重要です。

    これら2つの値を設定し、次のWebサイトに移動して、これら2つの要素に基づいてキーを生成します。

    指定したフィールドにSSID名とPSKを入力します。フィールドに入力する文字列は、SSIDおよびPSK用に定義された正確なものである必要があります。

    [PSKの生成]を選択します

    値を定義したら、Generate PSKをクリックします。これによりキーが生成され、コピーされてWiresharkに戻ります。

    生成を選択

    生成したキーをKeyフィールドに貼り付けます。[OK] をクリックします。

    WEPとWPAの復号化

    次に、Preferences画面でApplyをクリックします。キャプチャのデコードが開始されます。

    値の入力

    デコードすると、以前に暗号化された802.11パケットの内容を確認できます。

    印刷

    WPA/WPA2 エンタープライズ

    1. dot1x(PEAP)によるWPA(TKIP)/WPA2(AES)

    このプロセスでは、AKM方式と、802.11管理フレームのPTK/GTKおよびAPアドバタイズ属性を除き、前と同じ手順を使用します。

    1. この例では、APはdot1x認証を使用してWPA(TKIP)/WPA2(AES)をアドバタイズします。AKMのRSNとWPAタグ属性の両方にWPA値が含まれています。PSK認証の場合、このフィールドにPSKが含まれています。また、この例では、TKIPがWPAに使用され、AESがWPA2に使用されます。

    dot1x.png

    b. STAはAPからアドバタイズされた認証方式と暗号スイートの1つを選択します。この例では、AESを使用するWPA2が選択されています。これはRSN IEパラメータで確認できます。

    WPA2PEAP.png

    c. dot11の関連付けに成功すると、dot1x認証が実行されます。このプロセスでは、STAが認証に使用するEAP方式と、サプリカントとAAAサーバ間の証明書交換情報を確認できます。

    dot1x-PEAP-1.png

    d. dot1x認証に成功すると、AAAサーバからAccess-AcceptメッセージでPMKがAPに送信され、同じPMKがクライアントで取得されます。次の4ウェイハンドシェイクが行われ、PTKとGTKが確立されます。

    WLC と AAA サーバ間での範囲交換

    image018.jpg

    一般的なフロー図：

    image019.jpg

    dot1x（EAP-TLS）による WPA（TKIP）/WPA2（AES）

    このタイプの認証と前の認証の違いは、クライアントが「Client Hello」メッセージで証明書を提供し、証明書に基づいてクライアントとAAAサーバの間で相互認証が実行される点です。

    STA と WLC 間での EAP 交換：

    image020.jpg

    WLC と AAA サーバ間での範囲交換

    image021.jpg

    一般的なフロー図：

    image022.jpg

    dot1x(FAST)による2.WPA(TKIP)/WPA2(AES)

    dot1x認証段階だけが、前の例と少し異なります。dot11関連付けに成功したdot1x認証が実行されると、APはdot1x ID要求をSTAに送信し、STAはID応答を提供します。この応答は、どのPACプロビジョニング(インバンドPACプロビジョニング（フェーズ0）またはアウトオブバンドPACプロビジョニング)が使用されているかによって異なります。インバンドプロビジョニングの場合、PACはAAAサーバからクライアントに送信されます。クライアントがPACを取得すると、この時点からEAP-FASTフェーズ1に進み、TLSトンネルの確立が開始されます（フェーズ1）。

    image023.jpg

    TLSトンネルが確立されると、暗号化されたトンネル内で内部認証方式（フェーズ2）が開始されます。認証が成功すると、PMKがAccess-AcceptメッセージでAAAサーバからAPに送信されます。同じキーは、STAでのdot1x交換に基づいて取得されます。このキー(PMK)は、STAとAP間の通信を保護するために使用できる4ウェイハンドシェイク中にPTKを計算するために使用されます。

    一般的なフロー図：

    image024.jpg

    802.11 スニファ キャプチャの分析：マルチキャスト

    はじめに

    マルチキャスト スニッフィング

    解決方法

    コントローラでは、次の 2 つのモードでマルチキャストを実行します。

    • ユニキャスト モード：コントローラにアソシエートしているすべての AP に、すべてのマルチキャスト パケットがユニキャストされます。このモードは非効率的ですが、マルチキャストをサポートしないネットワークでは必要になる可能性があります。
    • マルチキャスト モード：マルチキャスト パケットは LWAPP マルチキャスト グループに送信されます。この方法では、コントローラプロセッサのオーバーヘッドが減少し、パケット複製の作業がネットワークに移行するため、ユニキャスト方式よりもはるかに効率的です。
    • コントローラのGUIまたはCLIを使用して、マルチキャストモードを有効にできます。

    WLC での IGMP スヌーピング

    IGMP スヌーピングはマルチキャスト パケットの振り分けを最適化するためにコントローラ ソフトウェア リリース 4.2 に導入されました。この機能をイネーブルにすると、コントローラはクライアントからIGMPレポートを収集して処理し、レイヤ3マルチキャストアドレスとVLAN番号を確認した後にIGMPレポートから一意のマルチキャストグループID(MGID)を作成して、IGMPレポートをインフラストラクチャスイッチに送信します。コントローラから送信されるレポートの送信元アドレスには、コントローラでレポートをクライアントから受信したインターフェイスのアドレスが使用されます。

    次に、コントローラは、AP 上のアクセス ポイント MGID テーブルを、クライアント MAC アドレスで更新します。特定のマルチキャスト グループに対するマルチキャスト トラフィックを受信した場合、コントローラは、すべての AP にこのトラフィックを転送します。ただし、そのマルチキャストグループをリッスンまたはサブスクライブするアクティブクライアントがあるAPだけが、その特定のWLAN上でマルチキャストトラフィックを送信します。IP パケットは、入力 VLAN および宛先マルチキャスト グループで一意の MGID を使用して転送されます。レイヤ 2 マルチキャスト パケットは、入力インターフェイスで一意の MGID を使用して転送されます。

    note-icon

    注:IGMPスヌーピングは、2000シリーズコントローラ、2100シリーズコントローラ、またはCiscoサービス統合型ルータ用CiscoワイヤレスLANコントローラネットワークモジュールではサポートされていません。

    マルチキャスト モードを使用する場合の注意点

    ネットワークでマルチキャスト モードを有効にする場合は、次のガイドラインに従ってください。

    Cisco Unified Wireless Network ソリューションでは、いくつかの IP アドレス範囲を特定の目的で使用します。マルチキャストグループを設定する際は、これらの範囲を念頭に置いてください。推奨ではありませんが、任意のマルチキャストアドレスをLWAPPマルチキャストグループに割り当てることができます。これには、OSPF、EIGRP、PIM、HSRP、およびその他のマルチキャストプロトコルで使用される予約済みリンクローカルマルチキャストアドレスが含まれます。

    シスコでは、管理用スコープのブロック 239/8 からマルチキャスト アドレスを割り当てることを推奨します。IANA では、プライベート マルチキャスト ドメインで使用するために、管理用スコープのアドレスとして 239.0.0.0 ～ 239.255.255.255 の範囲を予約しています。その他の制限については、次の注を参照してください。これらのアドレスは、RFC 1918 で定義されている予約済みのプライベート IP ユニキャストの範囲（10.0.0.0/8 など）と事実上よく似ています。ネットワーク管理者は、インターネット上での競合を気にすることなく、管理しているドメイン内でこの範囲のマルチキャスト アドレスを自由に使用できます。この管理用またはプライベートのアドレス空間は、企業内で使用する必要があり、Autonomous Domain（AS）への出入りはブロックされます。

    note-icon

    注:239.0.0.Xのアドレス範囲または239.128.0.Xのアドレス範囲は使用しないでください。これらの範囲のアドレスは、リンク ローカル MAC アドレスとオーバーラップし、IGMP スヌーピングがオンの場合でも、すべてのスイッチ ポートに向けてフラッディングします。

    シスコでは、企業ネットワーク管理者がこのアドレス範囲を企業ネットワーク内のより小さな地理上の管理スコープにさらに分割して、特定のマルチキャストアプリケーションの範囲を制限することを推奨しています。これにより、帯域幅が豊富なキャンパスから発信されてWANリンクに輻輳を発生させる高レートのマルチキャストトラフィックを防止できます。高帯域幅のマルチキャストを効率的にフィルタリングすることによって、高帯域幅のマルチキャストがコントローラおよび無線ネットワークに到達することも防止できます。

    コントローラ上のマルチキャスト モードを有効にする場合は、コントローラ上で LWAPP マルチキャスト グループ アドレスを設定する必要があります。AP は、Internet Group Management Protocol（IGMP）を使用して LWAPP マルチキャスト グループに加入します。

    • Cisco AP 1100、1130、1200、1230、および 1240 は、IGMP バージョン 1、2、および 3 を使用します。ただし、Cisco 1000 シリーズ AP では、マルチキャスト グループへの加入に IGMP v1 だけを使用します。
    • マルチキャスト モードは、レイヤ 3 LWAPP モードのみで機能します。
    • モニタ モード、スニファ モード、または不正検出モードの AP は、LWAPP マルチキャスト グループ アドレスには加入しません。
    • バージョン 4.1 以前を実行するコントローラを使用する場合は、すべてのコントローラ上で同じマルチキャスト アドレスを使用できます。バージョン 4.2 以降を実行するコントローラを使用する場合、コントローラ上に設定する LWAPP マルチキャスト グループは、ネットワーク上で使用されているコントローラごとに異なる必要があります。
    • バージョン 4.1 以前を搭載したコントローラを使用する場合、ゲスト トンネリング、サイト別 VLAN、RADIUS を使用したインターフェイスの上書きなどのサブネット間モビリティ イベント間では、マルチキャスト モードは機能しません。有線 LAN 上のレイヤ 2 IGMP スヌーピング機能および CGMP 機能を無効にすれば、これらのサブネット モビリティ イベントでもマルチキャスト モードが機能します。

    新しいバージョン、つまり 4.2 以降のバージョンでは、ゲスト トンネリングなどのサブネット間モビリティ イベントをまたいで、マルチキャスト モードが機能しません。ただし、RADIUS を使用したインターフェイスの上書き（IGMP スヌーピングが有効になっている場合のみ）およびサイト専用の VLAN（アクセス ポイント グループ VLAN）では機能します。

    • コントローラは、UDP ポート番号 12222、12223、12224 に対して送信されるすべてのマルチキャスト パケットをドロップします。ネットワーク上のマルチキャスト アプリケーションで、これらのポート番号を使用していないことを確認してください。
    • 802.11a ネットワークの場合、マルチキャスト トラフィックは、6 Mbps で送信されます。したがって、複数の WLAN が 1.5 Mbps での送信を試みると、パケット損失が発生します。その結果、マルチキャスト セッションが切断されます。

    マルチキャストの設定（マルチキャスト間モードを使用）

    マルチキャストを選択し、グループを設定します。モビリティグループ内の各WLCは一意のアドレスを使用できます。

    L3デバイスでマルチキャストルーティングを有効にし、これらのVLANでPIMを有効にします。  管理、APマネージャ、APが存在するVLAN、およびマルチキャストストリームを受信するクライアントが存在するVLAN。

    以下に例を挙げます。

    VLAN 40はWLC管理、VLAN 40はAP用、VLAN 50はクライアントがいる場所です。したがって、これらすべてのSVIでmulticastコマンドを発行する必要があります。

    すべてのマルチキャストshowコマンド（show ip mroute、show ip igmp groupsなど）を発行して、APのグループが適切に構築されていることを確認します。

    WLCでIGMPスヌーピングをイネーブルにすることもできます。WLCは、受信するIGMPメッセージに関する独自のスヌーピングテーブルを保持しているため、ストリームの要求者を把握できます。

    ワイヤレス LAN コントローラ上

    WLCでのグローバルマルチキャストの有効化およびWLCでのマルチキャストモードのマルチキャストの有効化

    マルチキャストオプション

    マルチキャストの選択

    クライアントがマルチキャスト加入を送信すると、WLCのMGIDにマルチキャスト加入が表示されます。

    マルチキャストグループ

    有線ネットワークでのマルチキャスト設定

    マルチキャストルーティングをグローバルに設定し、各インターフェイスでPIMを有効にします。

    6504-WLCBUG#sh run | i multicast

    IPマルチキャストルーティング

    6504-WLCBUG#sh run int vla 50

    Building configuration...

    Current configuration :119 bytes

    !

    interface Vlan50

    description // WLAN DHCP pool VLAN //

    ip address 172.16.1.1 255.255.255.0

    ip pim dense-mode

    最後

    6504-WLCBUG#sh run int vla 40

    Building configuration...

    Current configuration :121 bytes

    !

    interface Vlan40

    description // Management Vlan //

    ip address 10.105.135.136 255.255.255.128

    ip pim dense-mode

    最後

    6504-WLCBUG#sh ip pim interface vlan 40

    Address         Interface               Ver/   Nbr   Query DR    

                                                           DR Mode   Count Intvl Prior

    10.105.135.136   Vlan40                   v2/D   0     30     1     10.105.135.136

    6504-WLCBUG#sh ip pim interface vlan 50

    Address         Interface               Ver/   Nbr   Query DR     DR

                                                            Mode   Count Intvl Prior

    172.16.1.1       Vlan50                   v2/D   0     30     1     172.16.1.1

    6504-WLCBUG#sh ip mroute

    IP Multicast Routing Table

    フラグ：D – 稠密、S – 希薄、B – 双方向グループ、s - SSMグループ、C – 接続、

           L - Local, P - Pruned, R - RP-bit set, F - Register flag,

           T - SPT-bit set, J - Join SPT, M - MSDP created entry,

           X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

           U - URD, I - Received Source Specific Host Report,

           Z - Multicast Tunnel, z - MDT-data group sender,

          Y - Joined MDT-data group, y - Sending to MDT-data group

           V - RD & Vector, v - Vector

    発信インターフェイスフラグ：H – ハードウェア交換、A – アサートの選択

    タイマー：稼働時間/有効期限

    インターフェイスの状態：インターフェイス、ネクストホップまたはVCD、状態/モード

    (*, 239.255.255.255), 4d17h/00:02:03, RP 0.0.0.0，フラグ： DC

    着信インターフェイス：ヌル、RPF nbr 0.0.0.0

    Outgoing interface list:

       Vlan40, Forward/Dense, 4d17h/00:00:00

    (*, 239.254.0.3), 2w1d/00:02:07, RP 0.0.0.0，フラグ： DC

    着信インターフェイス：ヌル、RPF nbr 0.0.0.0

    Outgoing interface list:

       Vlan40, Forward/Dense, 3d10h/00:00:00

    (*, 224.0.1.40), 2w1d/00:02:13, RP 0.0.0.0，フラグ： DCL

    着信インターフェイス：ヌル、RPF nbr 0.0.0.0

    Outgoing interface list:

       Vlan11, Forward/Dense, 2w1d/00:00:00

    パケット キャプチャ

    トポロジ

    有線PC ----------- 6500スイッチ--------WISM ------- AP ))((((ワイヤレスクライアント

    VLAN 50                       VLAN 40                 VLAN 40       VLAN 40             VLAN 50

    MCAST トラフィック ジェネレータ ツール

    有線PCでマルチキャストストリームの生成に使用：連続UDPパケット

    トラフィックの生成

    MCAST ジェネレータでの有線 Wireshark パケット キャプチャ

    トラフィック

    McastパケットジェネレータでのWindows Netmonキャプチャ</h=5>

    トラフィックのレポート

    MCAST Receiver Tool をワイヤレス クライアントで使用したソース（有線 PC）からのマルチキャスト トラフィックの受信

    マルチキャストホストグループとUDPポート

    ワイヤレス クライアントのワイヤレス インターフェイスでの Wireshark キャプチャ

    マルチキャストレポート

    ワイヤレス クライアントのワイヤレス インターフェイスでの Netmon キャプチャ

    マルチキャスト最終

    802.11 スニファ キャプチャの分析：Web 認証

    はじめに

    Cisco WLC トラブルシューティングでの Web 認証スニファ

    Web 認証プロセス

    Web 認証とは、事前認証 Access Control List（ACL; アクセス コントロール リスト）で許可されたトラフィックを除いて、有効なユーザ名とパスワードが正しく入力されるまで特定のクライアントからの IP トラフィック（DHCP 関連のパケット/DNS 関連のパケットは除く）をコントローラで許可しないようにするレイヤ 3 セキュリティ機能です。Web 認証は、認証の前にクライアントが IP アドレスを取得することを許可する唯一のセキュリティ ポリシーです。これは、サプリカントやクライアント ユーティリティを必要としない簡単な認証方式です。Web認証は、WLC上でローカルに実行することも、RADIUSサーバ経由で実行することもできます。Web認証は通常、ゲストアクセスネットワークを導入する際に使用されます。

    Web 認証は、クライアントからの最初の TCP HTTP（ポート 80）GET パケットをコントローラがインターセプトしたときに開始されます。クライアントの Web ブラウザがそこまで到達するには、クライアントがまず IP アドレスを取得し、Web ブラウザのために URL の IP アドレスへの変換（DNS 解決）を行う必要があります。これによって、Web ブラウザが HTTP GET を送信する IP アドレスを認識できます。

    WLAN で Web 認証が設定されている場合、コントローラは認証プロセスが完了するまで、クライアントからの DHCP および DNS トラフィックを除くすべてのトラフィックをブロックします。クライアントが最初の HTTP GET を TCP ポート 80 に送信したとき、コントローラは処理のためにそのクライアントを https://10.10.10.1/ にリダイレクトします。このプロセスは最終的にログイン Web ページを起動します。

    • Web ブラウザを開き、たとえば、http://www.google.com などの URL を入力します。  クライアントは、宛先の IP を取得するため、この URL の DNS 要求を送信します。WLCがDNSサーバにDNS要求をバイパスし、DNSサーバが宛先http://www.google.comのIPアドレスを含むDNS応答を返します。この応答はワイヤレスクライアントに転送されます。

    • 続いて、クライアントは宛先 IP アドレスを使用して TCP 接続を開始しようとします。http://www.google.comのIPアドレスを宛先とするTCP SYNパケットを送信します。

    • WLCにはクライアント用に設定されたルールがあるため、http://www.google.comのプロキシとして機能し、TCP SYN-ACKパケットを、http://www.google.comのIPアドレスを送信元とするクライアントに返信できます。クライアントは、3ウェイTCPハンドシェイクを完了するために、TCP ACKパケットを返信し、TCP接続が完全に確立されます。

    • クライアントはhttp://www.google.com宛てのHTTP GETパケットを送信します。WLCはこのパケットをインターセプトし、リダイレクト処理のために送信します。HTTP アプリケーション ゲートウェイは、HTML 本文を準備し、クライアントから要求された HTTP GET への応答として返します。このHTMLにより、クライアントは、<Virtual-Server-IP>/login.htmlなどのWLCのデフォルトWebページのURLに移動します。

    • クライアントは、たとえばhttp://www.google.comなどのIPアドレスとのTCP接続を閉じます。

    • 次に、クライアントはhttp://10.10.10.1/login.htmlに移動するために、WLCの仮想IPアドレスでTCP接続を開こうとします。WLC に 10.10.10.1 の TCP SYN パケットを送信します。

    • WLC は TCP SYN-ACK で返答し、クライアントはハンドシェイクを完了するために、TCP ACK を WLC に戻します。

    • クライアントは、ログインページを要求するために、10.10.10.1を宛先とする、/login.htmlのHTTP GETを送信します。

    • この要求は、WLC の Web サーバで許可され、サーバはデフォルト ログイン ページで応答します。クライアントは、ユーザがログインできるブラウザウィンドウでログインページを受信します。

    設定 WebAuth

    先に進んで設定します。

    トポロジ

    ワイヤレス クライアントは、DNS、ルーティング、L3 接続が設定されているルータに接続されたスイッチに接続されている WLC に登録された AP に接続されます。

    DNSとして機能するルータ。

    3825#sh run | i host
hostname 3825
ip host www.google.com 192.168.200.1
ip host www.yahoo.com 192.168.200.200.2
ip host www.facebook.com 192.168.200.200.3
3825#sh run | i dns
 dns-server 172.16.16.1
ip dns server
3825#sh run | b dhcp
ip dhcp excluded-address 172.16.16.1 172.16.16.5

!
ip dhcp pool webauth-sniffer
 network 172.16.16.0 172.16.255.0
 default-router 172.16.16.1
 dns-server 172.16.16.1

    WLCの設定

    • WLANに移動し、次にNEWに移動して詳細を入力します。
    • WLANをNO L2 Authに設定します。
    • L3用のWLANをWEBAUTHで設定します。
    • 設定後は、次のように表示されます。
    • Securityタブに移動し、ローカルネットユーザを作成します。
    • クライアントクレデンシャルを入力します。
    • Security>> Webauthタブに移動し、Web auth type ==Internal / External redirect / Customを選択します。
    • クライアントを接続します。
    • IPアドレスを取得したら、ブラウザを開き、Webアドレスを入力します。
    • クライアントは、ユーザ名とパスワードを入力したWeb認証ページにリダイレクトされます。
    • 正常にログインすると、クライアントはリダイレクトページにリダイレクトされます。

    次に、クライアントが接続を試行したときのパケットキャプチャを示します。

    クライアントは次を実行します。

    • DHCP
    • DNS
    • WTTP

    クライアントの IP アドレスは 172.16.16.7 です。クライアントは、192.168.200.1 にアクセスしていた Web サーバへの URL を解決しました。上記からわかるように、クライアントは3ウェイハンドシェイクを実行してTCP接続を開始し、パケット576で始まるHTTP GETパケットを送信しました。コントローラは、パケットをインターセプトし、コード 200 で応答しています。コード 200 のパケットには、次のように、リダイレクト URL が含まれています。

    クライアントが [HTTPS Login] ページに移動します。

    クライアントがクレデンシャルを承認します。

    クライアントは、リダイレクト URL への HTTPS 接続を開始します。クライアントはこの URL をコントローラの仮想 IP アドレスである 10.10.10.1 に送信します。SSL トンネルを開始するため、クライアントはサーバ証明書を検証するか、または無視する必要があります。次に、認証が正常に行われ、TCP セッションが問題なく開始された後にクライアントが Facebook.com にアクセスしようとしている例を示します。

    クライアントが接続を試行したときのクライアントデバッグを次に示します

    Cisco Controller) >
(Cisco Controller) >show debug 
MAC address ................................ 00:21:5c:8c:c7:61

Debug Flags Enabled:
 dhcp packet enabled.
 dot11 mobile enabled.
 dot11 state enabled
 dot1x events enabled.
 dot1x states enabled.
 pem events enabled.
 pem state enabled.
 CCKM client debug enabled.
 webauth redirect enabled.

May 18 13:43:50.568: 00:21:5c:8c:c7:61 Adding mobile on LWAPP AP a8:b1:d4:c4:35:b0(0) 
*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 Association received from mobile on AP a8:b1:d4:c4:35:b0
*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 0.0.0.0 START (0) Changing ACL 'MNGMNT' (ACL ID 0) ===> 'none' (ACL ID 255) --- (caller apf_policy.c:1633)
*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 Applying site-specific IPv6 override for station 00:21:5c:8c:c7:61 - vapId 1, site 'default-group', interface 'webauth-sniffer'
*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 Applying IPv6 Interface Policy for station 00:21:5c:8c:c7:61 - vlan 300, interface id 4, interface 'webauth-sniffer'
*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 STA - rates (8): 130 132 139 150 12 18 24 36 0 0 0 0 0 0 0 0
*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 STA - rates (12): 130 132 139 150 12 18 24 36 48 72 96 108 0 0 0 0
*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 0.0.0.0 START (0) Initializing policy
*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 0.0.0.0 START (0) Change state to AUTHCHECK (2) last state AUTHCHECK (2)
*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 0.0.0.0 AUTHCHECK (2) Change state to L2AUTHCOMPLETE (4) last state L2AUTHCOMPLETE (4)
*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 0.0.0.0 L2AUTHCOMPLETE (4) DHCP Not required on AP a8:b1:d4:c4:35:b0 vapId 1 apVapId 1for this client
*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 Not Using WMM Compliance code qosCap 00
*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 0.0.0.0 L2AUTHCOMPLETE (4) Plumbed mobile LWAPP rule on AP a8:b1:d4:c4:35:b0 vapId 1 apVapId 1
*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 0.0.0.0 L2AUTHCOMPLETE (4) Change state to DHCP_REQD (7) last state DHCP_REQD (7)
*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 apfMsAssoStateInc
*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 apfPemAddUser2 (apf_policy.c:223) Changing state for mobile 00:21:5c:8c:c7:61 on AP a8:b1:d4:c4:35:b0 from Idle to Associated
*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 Scheduling deletion of Mobile Station: (callerId: 49) in 1800 seconds
*apfMsConnTask_0: May 18 13:43:50.569: 00:21:5c:8c:c7:61 Sending Assoc Response to station on BSSID a8:b1:d4:c4:35:b0 (status 0) ApVapId 1 Slot 0
*apfMsConnTask_0: May 18 13:43:50.569: 00:21:5c:8c:c7:61 apfProcessAssocReq (apf_80211.c:5272) Changing state for mobile 00:21:5c:8c:c7:61 on AP a8:b1:d4:c4:35:b0 from Associated to Associated
*apfReceiveTask: May 18 13:43:50.570: 00:21:5c:8c:c7:61 0.0.0.0 DHCP_REQD (7) State Update from Mobility-Incomplete to Mobility-Complete, mobility role=Local, client state=APF_MS_STATE_ASSOCIATED
*apfReceiveTask: May 18 13:43:50.570: 00:21:5c:8c:c7:61 0.0.0.0 DHCP_REQD (7) pemAdvanceState2 4494, Adding TMP rule
*apfReceiveTask: May 18 13:26:46.570: 00:21:5c:8c:c7:61 0.0.0.0 DHCP_REQD (7) Adding Fast Path rule

 type = Airespace AP - Learn IP address
 on AP a8:b1:d4:c4:35:b0, slot 0, interface = 1, QOS = 0
 ACL Id = 255, Jumbo Fr

*apfReceiveTask: May 18 13:43:50.570: 00:21:5c:8c:c7:61 0.0.0.0 DHCP_REQD (7) Fast Path rule (contd...) 802.1P = 0, DSCP = 0, TokenID = 1506 IPv6 Vlan = 300, IPv6 intf id = 4
*apfReceiveTask: May 18 13:43:50.570: 00:21:5c:8c:c7:61 0.0.0.0 DHCP_REQD (7) Successfully plumbed mobile rule (ACL ID 255)
*pemReceiveTask: May 18 13:43:50.570: 00:21:5c:8c:c7:61 0.0.0.0 Added NPU entry of type 9, dtlFlags 0x0
*pemReceiveTask: May 18 13:43:50.571: 00:21:5c:8c:c7:61 Sent an XID frame
*DHCP Socket Task: May 18 13:43:50.689: 00:21:5c:8c:c7:61 DHCP received op BOOTREQUEST (1) (len 310,vlan 0, port 1, encap 0xec03)
*DHCP Socket Task: May 18 13:43:50.689: 00:21:5c:8c:c7:61 DHCP processing DHCP DISCOVER (1)
*DHCP Socket Task: May 18 13:43:50.689: 00:21:5c:8c:c7:61 DHCP op: BOOTREQUEST, htype: Ethernet, hlen: 6, hops: 0
*DHCP Socket Task: May 18 13:43:50.689: 00:21:5c:8c:c7:61 DHCP xid: 0xf665da29 (4133870121), secs: 0, flags: 0
*DHCP Socket Task: May 18 13:43:50.689: 00:21:5c:8c:c7:61 DHCP chaddr: 00:21:5c:8c:c7:61
*DHCP Socket Task: May 18 13:43:50.689: 00:21:5c:8c:c7:61 DHCP ciaddr: 0.0.0.0, yiaddr: 0.0.0.0
*DHCP Socket Task: May 18 13:43:50.689: 00:21:5c:8c:c7:61 DHCP siaddr: 0.0.0.0, giaddr: 0.0.0.0
*DHCP Socket Task: May 18 13:43:50.689: 00:21:5c:8c:c7:61 DHCP requested ip: 192.168.226.44
*DHCP Socket Task: May 18 13:43:50.689: 00:21:5c:8c:c7:61 DHCP successfully bridged packet to DS
*DHCP Socket Task: May 18 13:43:50.690: 00:21:5c:8c:c7:61 DHCP received op BOOTREPLY (2) (len 308,vlan 300, port 1, encap 0xec00)
*DHCP Socket Task: May 18 13:43:50.690: 00:21:5c:8c:c7:61 DHCP processing DHCP OFFER (2)
*DHCP Socket Task: May 18 13:43:50.690: 00:21:5c:8c:c7:61 DHCP op: BOOTREPLY, htype: Ethernet, hlen: 6, hops: 0

*DHCP Socket Task: May 18 13:43:50.690: 00:21:5c:8c:c7:61 DHCP xid: 0xf665da29 (4133870121), secs: 0, flags: 0
*DHCP Socket Task: May 18 13:43:50.690: 00:21:5c:8c:c7:61 DHCP chaddr: 00:21:5c:8c:c7:61
*DHCP Socket Task: May 18 13:43:50.691: 00:21:5c:8c:c7:61 DHCP ciaddr: 0.0.0.0, yiaddr: 172.16.16.7
*DHCP Socket Task: May 18 13:43:50.691: 00:21:5c:8c:c7:61 DHCP siaddr: 0.0.0.0, giaddr: 0.0.0.0
*DHCP Socket Task: May 18 13:43:50.691: 00:21:5c:8c:c7:61 DHCP server id: 172.16.16.1 rcvd server id: 172.16.16.1
*DHCP Socket Task: May 18 13:43:50.691: 00:21:5c:8c:c7:61 DHCP successfully bridged packet to STA
*DHCP Socket Task: May 18 13:43:50.704: 00:21:5c:8c:c7:61 DHCP received op BOOTREQUEST (1) (len 314,vlan 0, port 1, encap 0xec03)
*DHCP Socket Task: May 18 13:43:50.704: 00:21:5c:8c:c7:61 DHCP processing DHCP REQUEST (3)
*DHCP Socket Task: May 18 13:43:50.704: 00:21:5c:8c:c7:61 DHCP op: BOOTREQUEST, htype: Ethernet, hlen: 6, hops: 0
*DHCP Socket Task: May 18 13:43:50.704: 00:21:5c:8c:c7:61 DHCP xid: 0xf665da29 (4133870121), secs: 0, flags: 0
*DHCP Socket Task: May 18 13:43:50.704: 00:21:5c:8c:c7:61 DHCP chaddr: 00:21:5c:8c:c7:61
*DHCP Socket Task: May 18 13:43:50.704: 00:21:5c:8c:c7:61 DHCP ciaddr: 0.0.0.0, yiaddr: 0.0.0.0
*DHCP Socket Task: May 18 13:43:50.705: 00:21:5c:8c:c7:61 DHCP siaddr: 0.0.0.0, giaddr: 0.0.0.0
*DHCP Socket Task: May 18 13:43:50.705: 00:21:5c:8c:c7:61 DHCP requested ip: 172.16.16.7
*DHCP Socket Task: May 18 13:43:50.705: 00:21:5c:8c:c7:61 DHCP server id: 172.16.16.1 rcvd server id: 172.16.16.1
*DHCP Socket Task: May 18 13:43:50.705: 00:21:5c:8c:c7:61 DHCP successfully bridged packet to DS
*DHCP Socket Task: May 18 13:43:50.705: 00:21:5c:8c:c7:61 DHCP received op BOOTREPLY (2) (len 308,vlan 300, port 1, encap 0xec00)
*DHCP Socket Task: May 18 13:43:50.705: 00:21:5c:8c:c7:61 DHCP processing DHCP ACK (5)
*DHCP Socket Task: May 18 13:43:50.705: 00:21:5c:8c:c7:61 DHCP op: BOOTREPLY, htype: Ethernet, hlen: 6, hops: 0
*DHCP Socket Task: May 18 13:43:50.706: 00:21:5c:8c:c7:61 DHCP xid: 0xf665da29 (4133870121), secs: 0, flags: 0
*DHCP Socket Task: May 18 13:43:50.706: 00:21:5c:8c:c7:61 DHCP chaddr: 00:21:5c:8c:c7:61
*DHCP Socket Task: May 18 13:43:50.706: 00:21:5c:8c:c7:61 DHCP ciaddr: 0.0.0.0, yiaddr: 172.16.16.7
*DHCP Socket Task: May 18 13:43:50.706: 00:21:5c:8c:c7:61 DHCP siaddr: 0.0.0.0, giaddr: 0.0.0.0
*DHCP Socket Task: May 18 13:43:50.706: 00:21:5c:8c:c7:61 DHCP server id: 172.16.16.1 rcvd server id: 172.16.16.1
*DHCP Socket Task: May 18 13:43:50.706: 00:21:5c:8c:c7:61 Static IP client associated to interface webauth-sniffer which can support client subnet.
*DHCP Socket Task: May 18 13:43:50.708: 00:21:5c:8c:c7:61 Adding Web RuleID 22 for mobile 00:21:5c:8c:c7:61

*DHCP Socket Task: May 18 13:43:50.708: 00:21:5c:8c:c7:61 172.16.16.7 DHCP_REQD (7) Change state to WEBAUTH_REQD (8) last state WEBAUTH_REQD (8)

*apfMsConnTask_0: May 18 13:44:43.347: 00:21:5c:8c:c7:61 172.16.16.7 WEBAUTH_REQD (8) Fast Path rule (contd...) 802.1P = 0, DSCP = 0, TokenID = 1506 IPv6 Vlan = 300, IPv6 intf id = 4

*apfMsConnTask_0: May 18 13:44:43.347: 00:21:5c:8c:c7:61 172.16.16.7 WEBAUTH_REQD (8) Successfully plumbed mobile rule (ACL ID 255)

(Cisco Controller) >*emWeb: May 18 13:47:39.321: 00:21:5c:8c:c7:61 Username entry (Cisco) created for mobile, length = 5 
*emWeb: May 18 13:47:39.321: 00:21:5c:8c:c7:61 Username entry (Cisco) created in mscb for mobile, length = 5 
*emWeb: May 18 13:47:39.322: 00:21:5c:8c:c7:61 172.16.16.7 WEBAUTH_REQD (8) Change state to WEBAUTH_NOL3SEC (14) last state WEBAUTH_NOL3SEC (14)
*emWeb: May 18 13:47:39.322: 00:21:5c:8c:c7:61 apfMsRunStateInc
*emWeb: May 18 13:47:39.322: 00:21:5c:8c:c7:61 172.16.16.7 WEBAUTH_NOL3SEC (14) Change state to RUN (20) last state RUN (20)
*emWeb: May 18 13:47:39.322: 00:21:5c:8c:c7:61 Session Timeout is 1800 - starting session timer for the mobile

    参考資料 

    更新履歴

    改定 発行日 コメント
    3.0
    16-Jan-2024
    SEO、スタイル要件、機械翻訳、スペル、フォーマットが更新されました。
    2.0
    10-Nov-2022
    記事は、PII、偏った言語、機械翻訳、SEO、スタイル要件、およびその他の必要な項目に準拠するために大規模な複数の更新を必要としました。
    1.0
    20-Jun-2016
    初版
    TAC Authored

    シスコ エンジニア提供

    • アーロン・レナード
      カスタマーデリバリエンジニアリングテクニカルリード
    • シャンカル・ラマナタン
      主任エンジニア

    このドキュメントは役に立ちましたか?

    Feedbackフィードバック

    シスコに問い合わせ

    このドキュメントは次の製品に対応しています