無線の問題は複雑です。ユーザが無線の調子が悪いと申告しても、色々な要因が考えられるため調査が長期化することは良くあります。Meraki はこのような問題を解決するために、ヘルス機能を拡張してきました。ヘルス機能は IT 管理者の問題解決に大きく貢献していますが、問題によってはより詳細な情報が原因特定のために必要です。なので、今回の記事では事象発生時の状況把握から詳細なデータの取得方法を記載します。ちなみに、プリセールスエンジニアになって 3 年以上経ちましたが、今回初めてこの情報を取得することになりました。
ローミングの問題はさらに複雑な取得方法になるので、別の記事で扱いたいと考えています。
状況把握
無線で問題が発生した場合、まずは状況をしっかりと把握しなければいけません。なぜならば、利用者が無線に問題があると報告しても、無線が原因だとは限らないからです。報告を受け、IT 管理者が無線を中心に調査を開始したけれども、ネットワークの他の部分が原因だったということは稀ではありません。無線の調査は有線よりも時間と労力を費やすため、原因が無線でない限り開始したくありません。これを判断することは困難なことですが、下記問診票を記入することによって有線と無線の切り分けがある程度可能だと考えています。また、記入することによって調査対象と範囲を決められます。下記の質問は Meraki がドキュメントとして公開している Case 作成時に必要な情報（問診票）とほぼ同じです。
- どのような現象か
例:
1F の○○会議室で無線に接続できない
4F のデスクでメールの送信に失敗した、特定のアプリを利用している際に気づいた - 現象が発生しはじめたのはいつか
発生日時:
- この現象は繰り返し発生しているか
[ ] 1 回のみ（今回が初めて）
[ ] 複数回、不定期に発生 ※ 可能なら各発生日時をお知らせください
[ ] 複数回、定期的に発生 ※ 発生頻度をお知らせください
[ ] 不明/未確認 - この現象が発生しはじめる前に何らかの変化（変更）があったか
[ ] 特になし
[ ] 機器の設定変更、firmware アップグレードなど
[ ] ネットワーク構成の変更 (接続構成変更、拠点追加、機器追加など)
[ ] 保守作業 (HW 交換、システム停止など)
[ ] 使用状況の変化 (ユーザ数の増減による使用量の変化など)
[ ] その他 - クライアントの MAC アドレス
例:
b0:b9:8a:6d:07:b8
モバイルデバイスマネージメント (MDM) を導入している場合、クライアントにユーザを紐づけているため、クライアントの MAC アドレスや種類を MDM から引き抜くことができます。しかし、導入していない場合はユーザの協力が必要です。ユーザに自身の端末を操作してもらい、必要な情報を共有してもらいます。Windows 10 の場合は、「スタート (ウィンドウズアイコン) > 設定 (歯車) > ネットワークとインターネット > WiFi > 詳細オプション」になります。
macOS の場合は「⌥ (オプションキー) を押したまま画面右上 WiFi アイコンをクリック」から確認可能です。
- クライアントの種類
例:
Windows 10、NETGEAR A6210 WiFi USB3.0 Adapter (バージョン: 5.1.35.0)
Windows 10、Qualcomm QCA61x4A 802.11ac Wireless Adapter (バージョン: 12.0.0.1016)
macOS Catalina (10.15.7) MacBook Pro (16-inch, 2019) - アクセスポイントの名前
例: AP 19-1
Meraki のダッシュボードでは「ネットワークワイド > クライアント > [事象が発生している端末を選択] 」から対象のアクセスポイントと SSID を確認できます。
- SSID 名
例: Sydney
データ取得方法
概要
Meraki のヘルス機能から原因が特定できず、問診票からも無線が原因の可能性が高いと判断した場合、無線での調査を開始します。具体的に、事象発生時に下図の赤丸でパケットキャプチャを同時取得しなければいけません。
具体的に下記の 4 箇所になります。
- 事象発生端末の無線ネットワークインターフェイス (NIC)
- 無線空間
- MR の有線 LAN インターフェイス
- MS の MR が接続しているポート
4 箇所同時にパケットキャプチャを取得することによって、どの機器に問題があるのか特定できます。
必要機材
この調査は上図のように、事象発生端末の他に調査用端末が 2 つ必要です。その理由は、調査用端末⓵で無線キャプチャを開始すると、その端末の無線 NIC は受信専用になり、通信ができなくなるからです。MR と MS のパケットキャプチャを取得するためには、インターネットに接続し、Meraki のダッシュボードにアクセスしなければいけません。なので、MR と MS のパケットキャプチャを実施する調査用端末②が必要になります。
調査開始前にある程度の準備は必要になります。事象発生端末には Wireshark をインストールしなければいけないですし、調査用端末はなんでもいいというわけではありません。それぞれの端末の要件を表にまとめました。
| 端末 | 要件 |
|---|---|
| 事象発生端末 | Wireshark がインストールされている |
| 調査用端末① | MacBook もしくは OmniPeek (高額) がインストールされている Windows マシン 事象発生端末の NIC よりも同等以上の NIC を搭載 |
| 調査用端末② | Meraki ダッシュボードにアクセスできる AWS に存在する仮想マシンでも問題ない |
この時、調査用端末①の無線 NIC は事象発生端末の無線 NIC よりも高スペック、もしくは同等でないと取りこぼしが発生してしまいます。取りこぼしというのは、取得した無線キャプチャに存在するはずのフレームが多数欠損している状態です。この原因は調査用端末①のスペックが足りていないことがほとんどです。例えば、調査用端末①が 802.11n しか対応していなくて、事象発生端末が 802.11ac に対応しているとします。事象発生端末は 802.11ac で アクセスポイント (AP) と通信しますが、802.11n しか対応していない調査用端末①がその通信を受信することはできません。無線 NIC が対応しているストリーム数も同じことが言えます。ハードウェアの限界を超えることはできないので、調査用端末①はなるべく最新の端末を使用してください。
稀に、事象が発生した場所に有線ポートが存在します。その時は調査用端末を 1 台に集約できます。調査用端末①で無線キャプチャを開始しても、有線 NIC 経由でダッシュボードへアクセスし、MR と MS のパケットキャプチャが可能です。
手順
同時パケットキャプチャは下記の手順に従って進めてください。また、この記事では事象発生端末と調査用端末として下記の機材を使用します。
| 事象発生端末 | Windows 10、NETGEAR A6210 WiFi USB3.0 Adapter (バージョン: 5.1.35.0) |
| 調査用端末① | MacBook Pro |
| 調査用端末② | インターネット接続がある仮想マシン |
なお、再現試験は基本的に発生した場所で実施します。
1. 調査用端末①で無線パケットキャプチャ開始
無線パケットキャプチャを正しく取得するためには、MR がどのチャネル、チャネル幅を使用しているのか確認しなければいけません。ダッシュボードでは「ネットワークワイド > クライアント > [事象が発生している端末を選択] > [アクセスポイントをクリック]」から確認できます。事象が発生している端末とアクセスポイントは問診票の 5 と 7 から確認できますが、今回の場合は AP 19-1 です。
この時、可能であればアクセスポイントのチャネルを固定で設定します。パケットキャプチャ取得中にアクセスポイントが自動チャネル設定の仕組みでチャネルを変更してしまうと、無線パケットキャプチャが途切れてしまいます。MR を固定チャネルに設定するためには「ワイヤレス > 電波設定」から可能になっています。
次に、調査用端末① (MacBook Pro) のスポットライトに「wireless diagnostics」と入力し、ワイヤレス診断というアプリを開きます。その後、上部メニューバーの「ウィンドウ」> 「スニファ」を開き、対象のアクセスポイントが使用しているチャネルとチャネル幅を指定し、キャプチャを開始します。デフォルトの設定だと、キャプチャファイルは /var/tmp に保存されます。
2. 調査用端末②で MR と MS のパケットキャプチャ開始
MR と MS のパケットキャプチャを取得するために、調査用端末② で Meraki ダッシュボードにアクセスします。AP 19-1 の有線パケットキャプチャを取得するために、「ネットワーク全体 > パケットキャプチャ > [アクセスポイント向けを選択] 」を開きます。AP は対象の MR を選択、インタフェースは有線、出力は .pcap ファイル、時間（秒）は 1200 に設定し、キャプチャを開始をクリックします。
MR の有線パケットキャプチャはバックグラウンドで残したいので、ブラウザで新しいタブを開きます。対象の MS のポートでパケットキャプチャを取得するためには、上記の MR がどの MS のどのポートに接続しているのか「ネットワークワイド > クライアント > [事象が発生している端末を選択] > [アクセスポイントを選択]」から確認します。
上記の画像から AP 19-1 は backbone rack 3/39 という MS のポート 23 番に接続していることが分かります。そのリンクをクリックすると、そのポートの詳細画面へ飛びます。飛んだ先のページで下へスクロールするとトラブルシューティングという項目が存在し、このポートでパケットキャプチャを実行しますというリンクをクリックします。飛んだ先で MR の時と同じように、出力は .pcap ファイル、時間（秒）は 1200 に設定し、キャプチャを開始します。
3. 事象発生端末で ping 開始
事象発生端末 (Windows 10) でコマンドプロンプトを開き ping 1.1.1.1 -l 100 -t を実行します。
Ping は等間隔で端末が送信するため、遅延問題を調査する時の指標となります。その上、MR と MS の有線パケットキャプチャが正常に取得できているか確認できます。Windows の場合は、macOS の場合は ping 1.1.1.1 -s 100 です。なお、無線に接続できない問題の場合は、宛先への疎通が通らないことは想定された動作となりますので、気にせず次の取得手順を進めます。
4. 事象発生端末でパケットキャプチャ開始
事象発生端末で Wireshark を開き、無線インターフェースでキャプチャを開始します。
5. 事象発生端末で事象を発生させる
再現方法は事象によって異なりますが、事象発生時と同じ動作を再現するまで繰り返します。「1F の○○会議室で無線に接続できない」という問題だった場合は SSID への接続を試みます。
6. 事象発生端末の無線を無効、有効にし SSID に再接続させる
クライアントと AP は通信開始前に情報のやりとりを実施しますが、その情報をキャプチャするために無線のオン・オフを実施します。Windows 10 の場合は、「スタート (ウィンドウズアイコン) > 設定 (歯車) > ネットワークとインターネット > WiFi > オフ > オン」実施できます。macOS の場合は「 画面右上 WiFi アイコン > Wi-Fi をオフにする > Wi-Fi をオンにする」です。
7. 事象発生端末で事象を発生させる
4 と同様。
8. 全てのデバイスでパケットキャプチャを停止
全てのパケットキャプチャを停止します。
9. ファイル名変更
それぞれのキャプチャファイルは、下記のようにファイル名を変更します。
| 事象発生端末の無線ネットワークインターフェイス (NIC) | client-[セット番号] |
| 無線空間 | wireless-[セット番号] |
| MR の有線 LAN インターフェイス | mr_wired-[セット番号] |
| MS の MR が接続しているポート | ms_port_[ポート番号]-[セット番号] |
例えば、今回の場合ですと下記のようになります。
| 事象発生端末の無線ネットワークインターフェイス (NIC) | client-1 |
| 無線空間 | wireless-1 |
| MR の有線 LAN インターフェイス | mr_wired-1 |
| MS の MR が接続しているポート | ms_port_23-1 |
取得したデータを確認
取得したデータを解析する前に、それぞれのパケットキャプチャが正常に取得できたか確認してください。複数のパケットキャプチャを同時に取得しているので、正しく取得できていないことは良くあります。このめんどくさい作業を繰り返さないためにも、パケットキャプチャを取得したら確認する癖をつけた方が良いです。
パケットキャプチャは 4 箇所で取得しましたが、有線と無線では確認するパケット・フレームが異なります。有線、無線それぞれ下記のパケット・フレームが存在するか確認してください。もちろん、無線に接続できない問題の場合は、ping は通らないので ICMP や QoS データを確認することはできません。
有線
- ICMP echo request
- ICMP echo reply
- RADIUS Access-Request (802.1X のみ)
- RADIUS Access-Reply (802.1X のみ)
- RADIUS Access-Accept/Reject (802.1X のみ)
無線
- Authentication Request
- Authentication Response
- Association Request
- Association Response
- EAPOL Start (任意、802.1X のみ)
- EAP Request (802.1X のみ)
- EAP Response (802.1X のみ)
- EAP Success/Failure (802.1X のみ)
- 4-Way Handshake (Message 1、2、3、4)
- RTS (任意)
- CTS (任意)
- QoS Data
これらをシーケンス図にまとめたものを載せます。
Wireshark のカラールール
確認のためには Wireshark を使います。しかし、Wireshark のデフォルトのカラールールでは無線パケットキャプチャの確認は非常に分かりにくいです。筆者のおすすめは Cisco のサポートエンジニアが作成したものになり、こちらからダウンロードできます。蛍光色を使用しているので目がチカチカするかもしれませんが、慣れるとすぐに内容を把握することができるので便利です。
有線パケットキャプチャ
有線パケットキャプチャの確認は簡単です。確認するのは ICMP と RADIUS 関連のパケットとなります。しつこくなりますが、無線に接続できない場合は ICMP パケットは確認できないですし、SSID の認証方式が 8021.X で設定されていても Authentication や Association のフェーズで問題があれば RADIUS 関連のパケットは確認できません。
ICMP
ICMP パケットを確認するためには icmp && ip.addr == 1.1.1.1 というフィルタを使用します。恐らく、この事象発生端末しか 1.1.1.1 へ ping を送信していないはずですが、送信元 MAC アドレスを確認します。
RADIUS
RADIUS パケットを確認するためには radius というフィルタを使用します。Access-Request を選択し、そのパケットが事象発生端末のものかを Radius Attribute の User-Name と Calling-Station-Id から確認します。
無線キャプチャ
無線キャプチャの確認はシーケンス図に沿って確認します。まずは、wlan.addr == [端末の MAC アドレス] をフィルターとして使用し、Authentication Request を探します。今回の例だとフィルターは wlan.addr==b0:b9:8a:6d:07:b8 です。
画像のように Authentication Request を選択し、IEEE 802.11 Authentication の情報を開き、BSSID を確認します。そして、フィルターを wlan.addr==[事象発生端末の MAC アドレス] || wlan.addr == [BSSID] に更新します。今回 BSSID は 98:18:88:ff:f1:23 なので、wlan.addr==b0:b9:8a:6d:07:b8 || wlan.addr == a2:18:98:fc:6f:8a を使用します。フィルターを更新すると、シーケンス図に沿ったやりとりを確認できます。
それぞれ取りこぼしがないか確認してください。もちろんシーケンスの途中で止まっている可能性があります。
まとめ
このような無線調査はほとんどの場合必要ありませんが、必要になった時はここに記載された手順に沿って進めれば正しく取得できます。問題をいち早く解決するためにも、取りこぼしがないように情報を取得するのは大事なことです。余裕がある場合は、それぞれのパケットキャプチャをシーケンス図に沿って確認し、どこに問題があるのか自分で確認するのもいいと思います。
APICLI 