無線ネットワークにおける基本的なトラブルシューティング

SSID の設定がブリッジモードになっている

クライアントが接続しているSSIDが"ブリッジモード"に設定されている場合、クライアントは IP アドレスを LAN 上に存在する DHCP サーバーから取得します。

以下に、 DHCP や VLAN タグに関連するよくある原因について解説します。

SSID が Meraki NAT モード

クライアントが接続しているSSIDが Meraki NATモードに設定されている場合は、Meraki APがすべてのクライアントにIPアドレスを割り当てるので、DHCP サーバーは問題になりません。 しかし、APがIPアドレスを割り当てていない可能性を排除するために、以下の手順を試してください。

1. 同じデバイスで別の SSID に接続する。
   1. これにより問題が特定の SSID に限定のものか確認できます
2. 他のクライアントを同じ SSID に接続する
   1. これにより事象の影響範囲が 1 つの SSID と 1 台のクライアント間であるか確認できます。
3. クライアント側でパケットキャプチャを実行する。
   1. Wireshark を使用してパケットキャプチャを確認し、 ACK がクライアントから AP へ送信されているか確認します。クライアントからの ACK がない場合、DHCP のプロセスは完了しません。

デバイスのイベントログを確認する

どの段階で問題が発生しているか確認するためには、 クライアントのイベントログが役立ちます。クライアントのイベントログは、ネットワーク全体 > クライアント > 対象クライアント、あるいは、ネットワーク全体 > イベントログ にて クライアントの MAC アドレスでフィルターすることで確認できます。

認証情報を確認する

クライアントが特定のSSIDに接続できない場合、認証情報（ユーザー名またはパスワード）が正しくないことが最も一般的な問題です。 この問題は、単純にデバイスからSSIDを削除し、再度接続を試みて、事前共有キーを再入力することで除外できることが多いです。

Google Chrome でダッシュボードへアクセスし、SSIDの事前共有キーを最近変更した場合、古い値がキャッシュされ、キーが実際には変更されないことがあります。 事前共有キーの変更が実際に適用され、保存されていることを確認することが重要です。 ブラウザのシークレットモードなどでこのような設定を変更し、変更が適切に保存されたことを再確認するのが良い方法です。また、RADIUSやAD認証を使用している場合、ADの認証情報やRADIUSサーバーの認証情報を再確認することは、トラブルシューティングの手順として有効です。RADIUSに関するトラブルシューティングの詳細は、「RADIUS問題解決ガイド」を参照してください。

失敗した接続は、「ワイヤレス」→「ヘルス」→「接続」を選択し、失敗した接続をクリックすることで確認できます。下図のように、すべての失敗した接続のレポートが生成されます。

単純な構成の SSID で確認する

一般的に、クライアントが特定のAPに接続できないという問題を解決するための最良の方法は、できるだけシンプルな設定を適用したテスト用SSIDを作成することです。

以下のような設定で SSID を作成し、疎通性を確認します。

• 接続条件 : 事前共有キーあるいはオープン
• スプラッシュページ : なし
• クライアントの IP アドレス割り当て: Meraki NAT モード
• バンド選択: デュアルバンド
• 最低ビットレート: 1

ワイヤレス > SSID の稼働設定と、APのタグ付けによってテスト用 SSID をブロードキャストする AP を限定できます。

これらの設定により、関係するすべての第三者を排除し、クライアントとアクセスポイント間の問題を簡単に診断できるようになります。また、1台のAPだけに問題がある場合に、ネットワーク全体への影響を低減できます。

RADIUS 認証の問題を特定する際には、基本的な機能が類似している Meraki 認証が役立つちます。Meraki 認証は、MerakiがホストするRADIUSサーバーを使用しており、これを使ったテストにより、ローカルまたはクライアント側のRADIUSの問題を特定できます。

アップストリームの設定を確認する

アップストリームポートの設定を確認します。APが接続されているポートが、クライアントが使用しているVLANのトラフィックを通さない場合、クライアントに接続の問題が発生している可能性があります。 可能であれば、APを現在のポートから、動作している別のAPや既知のデバイスが使用しているポートに交換してみてください。これにより、アップストリームポートに問題があることが判明します。

AP を再起動する

すべてのプロセスを再開することでAPが安定した状態になるかどうかを確認するには、APを再起動することが有効です。

クライアント側の挙動

APは、デバイスとローカルネットワークインフラ間の橋渡し役として機能します。AP との接続プロセスについては、「802.11アソシエーションプロセス」で説明しています。接続先のAPの決定は、完全にクライアントが行うものであり、クライアントに特定のAPへの接続を強制する方法はありません。しかし、適切な設定を行うことで、クライアントの判断に影響を与えることはできます。

クライアントはさまざまな要素から接続先AP を決定しています。それらに影響を与えられる操作可能な設定は以下のとおりです。

• 信号/ノイズ比（SNR）

• 最小ビットレート

すべての機器が、周囲にあるすべてのAPのS/N比を計算して、最も信号強度の高いAPを選ぶ機能を持っているわけではありません。ほとんどのクライアントは、近くのAPに接続し、信号がなくなるまで同じAPに接続し続けようとします。その結果、1台のAPが過負荷状態になり、残りのAPがアイドル状態になることがあります。これは、クライアントバランシングをオンにすることで軽減することができます。 

最適なアクセスポイントへの接続を促す設定

クライアントに最適なアクセスポイントへの接続を促す設定として、最小ビットレートと送信電力があります。 これらの設定の適切な数値は、無線環境などに左右されます。

下図の例では2 台の AP (AP1, AP2) とクライアントPCが存在し、アクセスポイントの最小ビットレートの設定は "12mbps" になっています。

当初、クライアントPCが初めて無線ネットワークに接続した際、PCは AP1 に接続したとします。施設内を歩き回り、AP2に近づいても、PCは AP1 に接続したままです。画像下部は、SNRとビットレートの値を示しています（繰り返しますが、これらの値は環境によって異なります）。このPC は AP2 に接近していますが、ビットレートに関する要件はどちらの AP でも満たしているため、PC は AP2 が最も近い AP であっても接続しない可能性があることがわかります。

この問題は、送信電力を下げるか、最小ビットレートを上げることで対応できる場合があります。ただし、他のデバイスのワイヤレス性能に影響を与える可能性があるため、変更を行う際には複数の要因を考慮する必要があります。例えば、すべてのデバイスが高いビットレートをサポートしているわけではないこと、送信電力を下げるとカバレッジに影響を与える可能性があることを考慮することが重要です。

サイトサーベイの実施

アクセスポイントを設置している施設の無線環境を正しく理解するためには、無線インフラのサイトサーベイを実施することが最良の選択肢です。サイトサーベイのツールやベストプラクティスに関する情報は、Conducting Site Surveys with MR Access Pointsで確認できます。

unknown reason (理由不明)

このイベントは、クライアントがAPから離れたことを意味し、正確な理由を説明するための十分なデータがないことを示しています。多くの場合、これはデバイスが接続を解除する前に AP に理由を通知することに失敗したためです。以下の図は、「802.11 disassociation」というタイプのイベントログで、理由が「unknown reason」であることを示しています。