Wireless Client Connectivity

このページで学ぶこと

• Wireless Adapter / Radio State
• SSID Visibility
• Client Band Capability
• WLAN Join State
• Security Mode Match
• Personal Credential / PSK-SAE
• Enterprise 802.1X Credential / Certificate
• Windows netsh wlan 確認情報
• macOS Wireless Diagnostics
• Linux nmcli Wi-Fi 確認情報
• WLAN Join vs IP Assignment
• Valid IP to Network到達性
• Wireless vs Non-Wireless 障害範囲
• Client側 Wireless 修正
• Wireless 修正後確認 Flow

1. 無線クライアントは接続段階を分けて切り分ける

無線クライアントで「Wi-Fiにつながらない」と言われても、すべてを同じ障害として扱ってはいけません。

無線接続では、

無線アダプターと無線機能
↓
SSIDの表示状況
↓
WLAN接続とセキュリティ
↓
IP割り当て
↓
ゲートウェイとリモートIP
↓
名前解決

のように段階を分けて確認します。

重要なのは、

どの段階まで成功しているか
↓
最初に失敗している確認はどこか
↓
次に何を確認するか

を判断することです。

2. この確認フローは802.11の固定フレームシーケンスではない

次のフローはトラブルシューティング上の確認順序です。

SSIDの表示状況
↓
WLAN接続とセキュリティ
↓
IP割り当て

すべての無線セキュリティ方式に共通するプロトコルフレームの固定順序を表しているわけではありません。

例えばセキュリティ方式によって、

• アソシエーション
• SAE
• 802.1X/EAP

などが実際に進む順序は異なります。

このページではプロトコル内部のシーケンスそのものではなく、

クライアントがどの接続段階まで進んでいるか

を切り分けます。

3. 最初に無線アダプターと無線機能の状態を確認する

無線トラブルシューティングでは、まずクライアントの無線アダプターが利用可能か確認します。

代表的な確認項目は、

• 無線アダプターが存在するか
• アダプターが有効か
• ハードウェア側の無線機能がオンか
• ソフトウェア側の無線機能がオンか
• 機内モード等で無効化されていないか

です。

無線アダプター自体を利用できなければ、SSIDのスキャンやWLAN接続より前の段階で止まります。

4. 無線機能オフならSSIDやIPより先に無線機能を確認する

例えばWindowsで、

State          : disconnected
Radio status   : Hardware On
                 Software Off

と確認できた場合、

ハードウェア側の無線機能が必ず故障しているとは判断しません。

この場合はまず、

ソフトウェア側の無線機能を有効にできる状態へ戻す

ことを優先します。

DNSやDHCPを最初に調べる段階ではありません。

5. ハードウェア側とソフトウェア側の無線機能を分けて考える

無線アダプターでは、

ハードウェア側の無線機能

と

ソフトウェア側の無線機能

を分けて確認できる場合があります。

例えば、

ハードウェア側オン
ソフトウェア側オフ

なら、

無線ハードウェアが存在していることと、OS側で無線機能を利用できることは同じではありません。

6. アダプターが有効でも無線接続性が正常とは限らない

無線アダプターが有効でも、

• 無線機能がオフ
• 目的のSSIDが見えない
• WLAN接続に失敗
• セキュリティ条件が不一致
• IPを取得できない
• ゲートウェイへ到達できない

可能性があります。

したがって、

アダプター有効
=
無線接続性全体が正常

ではありません。

7. 無線機能が利用可能なら目的のSSIDが見えるか確認する

無線機能が利用可能なら、次に目的のSSIDがクライアントから見えているか確認します。

例えば、

目的SSIDが見える

なら、

クライアントは少なくともそのSSIDに関する無線情報を検出できています。

一方、

目的SSIDが見えない

場合は、WLAN接続やIP割り当てより前の確認へ戻ります。

8. SSIDが見えないだけでAP停止とは断定しない

目的のSSIDがクライアントに表示されない場合でも、

AP故障確定

とは判断できません。

確認候補には、

• クライアントの無線機能状態
• クライアントの周波数帯対応能力
• 通信範囲
• SSIDの提供状態
• クライアント側のスキャン状態

などがあります。

周波数帯やRFの原理そのものは前の無線基礎で扱っているため、このページではクライアント接続性の判断材料として利用します。

9. クライアントが対応する周波数帯を確認する

無線クライアントは、すべての周波数帯へ必ず対応しているわけではありません。

代表的には、

2.4 GHz
5 GHz
6 GHz

があります。

対象SSIDが特定周波数帯だけで提供されている場合、

クライアントがその周波数帯に対応しているか

を確認します。

10. 6 GHzだけのSSIDとクライアントの対応能力

例えば、

SSID
6 GHzのみで提供

クライアント
2.4 GHzと5 GHz対応
6 GHz非対応

なら、そのクライアントから目的SSIDが見えないことを説明できます。

この段階では、

DHCPサーバー障害

や

DNS障害

を最初の原因候補にはしません。

11. 同じ場所の別クライアントとの比較も判断材料になる

例えば同じ場所で、

クライアントA
6 GHz対応
→ SSIDが見える

クライアントB
2.4 GHzと5 GHzのみ
→ 目的SSIDが見えない

なら、

クライアントBの周波数帯の対応能力を優先的に確認できます。

ただし、比較結果だけで他の可能性を完全に排除するわけではありません。

12. SSIDが見えることとWLAN接続は別の段階

目的SSIDが表示されていても、

SSIDが見える
=
WLANへ正常接続済み

ではありません。

SSIDの表示状況の次には、

WLAN接続とセキュリティ

を確認します。

13. SSIDが見えるなら次はWLAN接続状態を確認する

目的SSIDが見えているのに接続できない場合、

• クライアントがWLANへ接続できているか
• セキュリティ条件が一致しているか
• 必要な認証情報が正しいか

を確認します。

この時点でリモートルーティングやDNSから調べ始めるのは適切ではありません。

14. WLAN接続状態を明確にする

トラブルシューティングでは、

SSID表示あり

と

接続済み

を区別します。

例えば、

SSIDは一覧に表示される
しかしクライアントは切断状態

なら、SSID検出までは成功していますが、接続完了までは進んでいません。

15. WLANとクライアントのセキュリティ方式が一致するか確認する

WLANとクライアントプロファイルのセキュリティ方式が一致しているか確認します。

代表的には、

WPA2-Personal
WPA3-Personal
WPA2-Enterprise
WPA3-Enterprise

などがあります。

クライアントが保存しているプロファイルと現在のWLAN要件が一致しなければ、正常に接続できない原因になります。

16. Personal方式とEnterprise方式を区別する

無線セキュリティでは、

Personal方式

と

Enterprise方式

を分けて確認します。

Personal方式ではPSKやSAEなどの認証情報を確認します。

Enterprise方式では802.1Xに関連するID情報、認証情報、証明書などを確認します。

17. WPA3-Personalのみの構成とWPA2-Personalを区別する

例えば、

WLAN
WPA3-Personal/SAEのみ

クライアントプロファイル・対応能力
WPA2-Personal/PSKのみ

なら、

セキュリティ方式・認証方式の不一致

です。

一方、WLANがWPA2/WPA3移行モードを許可している場合は、WPA2-Personal/PSKクライアントが接続できる構成もあります。

したがって、

WPA3を使用しているSSID
=
WPA2クライアントは必ず接続不可

とは判断しません。

18. SSIDが同じでもセキュリティ設定が変更されることがある

以前は接続できていたSSIDでも、WLAN側のセキュリティ設定が変更される場合があります。

例えば、

以前
WPA2-Personal

現在
WPA3-Personalのみ

となった場合、クライアントに保存された古いプロファイルやクライアント対応能力が現在のWLAN要件と一致していない可能性があります。

19. Personal方式のWLANでは認証情報を確認する

Personal方式のWLANでは、

セキュリティ方式
と
認証情報

を確認します。

セキュリティ方式が一致していても、認証情報が誤っていれば接続に失敗する可能性があります。

20. WPA2-PersonalではPSK・パスフレーズを確認する

WPA2-Personal環境では、クライアント側で正しいPSK・パスフレーズが設定されているか確認します。

例えば、

SSID           正しい
セキュリティ方式  WPA2-Personal
PSK            誤り

なら、SSIDの表示状況やIP設定ではなく認証情報側が確認対象です。

21. WPA3-PersonalではSAE認証情報を確認する

WPA3-Personal/SAE環境でも、クライアント側認証情報がWLAN要件と一致する必要があります。

例えば、

セキュリティ
WPA3-Personal/SAE

パスフレーズ
誤り

なら、クライアント側認証情報を修正します。

22. 認証情報の問題とIP設定の問題を混同しない

クライアントがまだWLAN接続とセキュリティ段階を完了していないのに、

IPアドレス
デフォルトゲートウェイ
DNS

から原因を探すのは順序が逆です。

まず無線接続を成立させ、その後にIP割り当てを確認します。

23. Enterprise方式のWLANでは802.1X側を確認する

Enterprise方式のWLANでは、クライアント側の802.1X関連情報を確認します。

代表例は、

• ユーザーID・デバイスID
• 認証情報
• クライアント証明書
• 信頼に必要な証明書条件
• クライアントプロファイル

です。

24. Enterprise方式のWLANで証明書が必要な場合

例えばWLAN要件が、

セキュリティ
WPA2-Enterprise

認証
802.1X

クライアント証明書
必須

であるのにクライアント証明書が存在しない場合、

クライアント側要件を満たしていません。

この場合、

要件に合うクライアント証明書・ID情報を準備する

ことがクライアント側修正になります。

25. 802.1X失敗時にDHCPから調べない

Enterprise方式のWLANで802.1X認証が完了していない場合、

DHCPプール
デフォルトゲートウェイ
DNSサーバー

を最初に確認する段階ではありません。

まずクライアント側の、

802.1Xの認証情報・証明書

などを確認します。

26. RADIUSサーバー内部の設定まではこのページで追わない

802.1X認証失敗時に、

RADIUSサーバー内部の設定
EAP内部メッセージフロー
サーバー証明書ポリシーの詳細

まで深掘りするのはこのページでは扱いません。

ここでは、

クライアント側の無線セキュリティ条件か
インフラ側へ切り分けるべきか

を判断するところまで扱います。

27. Windowsではnetsh wlanを利用できる

Windowsでは無線クライアントの状態確認にnetsh wlanを利用できます。

代表的なコマンドは、

netsh wlan show interfaces
netsh wlan show networks mode=bssid
netsh wlan show profiles
netsh wlan show wlanreport

です。

それぞれ取得する情報の目的が異なります。

28. netsh wlan show interfacesで現在の接続状態を確認する

現在の無線インターフェースの状態を確認する代表的コマンドです。

netsh wlan show interfaces

確認対象には、

• インターフェース
• 状態
• SSID
• 信号強度
• 無線機能関連の状態
• 接続情報

などがあります。

トラブルシューティングでは、

現在そのクライアントがどの無線ネットワークへ接続しているか

を判断する材料になります。

29. show interfacesは周囲の全SSID一覧を確認するコマンドではない

netsh wlan show interfacesは、現在の無線インターフェースの状態を確認するために使用します。

周囲に表示されるネットワークを調べたい場合は、別コマンドを利用します。

30. netsh wlan show networks mode=bssidで周囲のSSIDを確認する

周囲に表示される無線ネットワークを確認したい場合、

netsh wlan show networks mode=bssid

を利用できます。

確認情報には、

• SSID
• BSSID
• 信号強度
• チャネル
• 無線方式
• セキュリティ関連情報

などが含まれます。

31. 表示されるネットワークの確認は周波数帯の対応能力切り分けにも利用できる

周囲の無線ネットワーク情報を確認することで、

目的SSIDがクライアントから検出されているか

を調べられます。

他のクライアントでは見えるSSIDが対象クライアントでは見えない場合、

クライアント対応能力や無線機能状態の確認へ進む材料になります。

32. netsh wlan show profilesで保存済みプロファイルを確認する

保存済み無線プロファイルは、

netsh wlan show profiles

で確認できます。

例えば、

以前のWLAN設定がクライアントへ保存されている

かどうかを確認する材料になります。

33. 保存プロファイルが存在するだけでは正しいとは限らない

保存済みプロファイルが表示されても、

現在のWLAN要件と一致

することまでは保証されません。

WLAN側セキュリティ設定が変更されている場合、保存プロファイルの見直しが必要になることがあります。

34. netsh wlan show wlanreportで無線ネットワークレポートを生成する

Windowsでは、

netsh wlan show wlanreport

によって無線ネットワークレポートを生成できます。

最近の無線セッションや切断などを確認する材料になります。

単発の画面だけでは分かりにくい問題を調査するときに利用できます。

35. Windowsではコマンドを目的別に使い分ける

コマンド名だけを覚えるのではなく、

何を確認したいのか

と対応させます。

36. 保存パスワードの抽出を学習目的にしない

このページでnetsh wlanを扱う目的は、

無線クライアント接続の確認

です。

保存認証情報を表示・抽出すること自体は学習目的ではありません。

37. macOSではWi-Fi設定を確認する

macOSではWi-Fi設定から、

• Wi-Fiが有効か
• どのネットワークへ接続しているか
• クライアント側ネットワーク設定
• 接続状態

などを確認します。

目的はWindowsと同じく、

クライアント側がどの接続段階にいるか

を判断することです。

38. macOSではワイヤレス診断を利用できる

macOSにはワイヤレス診断（Wireless Diagnostics）があります。

Wi-Fi接続や無線環境に関する問題を分析するときのクライアント側の確認ツールとして利用できます。

39. ワイヤレス診断だけで根本原因が確定するとは限らない

ワイヤレス診断から情報を得られても、

診断ツールを実行
=
根本原因完全確定

とは限りません。

結果を、

• クライアント状態
• 無線接続状態
• IP設定
• ネットワーク到達性

などと組み合わせます。

40. macOSでも無線とIPを分離して確認する

macOSクライアントでも、

Wi-Fiへ接続済み

と

有効なIPを取得済み

は同じ意味ではありません。

無線接続後にIP割り当てを確認します。

41. LinuxのNetworkManager環境ではnmcliを利用できる

NetworkManagerを使用するLinuxでは、nmcliで無線デバイスや接続の状態を確認できます。

ただし、

すべてのLinux環境でNetworkManager必須

とはしません。

このページではNetworkManager環境を前提とした代表例として扱います。

42. nmcli device wifi listで周囲のWi-Fiを確認する

周囲のWi-Fiネットワークを一覧する代表的コマンドは、

nmcli device wifi list

です。

確認情報には、

• SSID
• チャネル
• 信号強度
• セキュリティ

などがあります。

43. LinuxでもSSIDの表示状況を確認できる

例えば、

nmcli device wifi list

で目的SSIDが表示されるなら、

SSID表示の段階の確認情報になります。

目的SSIDが出ない場合は、無線機能やクライアント対応能力などを確認します。

44. nmcli device statusでデバイス状態を確認する

NetworkManager環境では、

nmcli device status

を使ってデバイスの状態を確認できます。

例えば無線デバイスが、

connected
disconnected
unavailable

など、どの状態にあるかを見る材料になります。

45. 接続プロファイルと現在の接続状態を分ける

Linuxでも、

接続プロファイルが存在する

ことと、

現在その接続がアクティブ

であることは別です。

プロファイルの存在だけを見て接続成功と判断しません。

46. NetworkManagerではアクティブな接続も確認する

必要に応じて、

nmcli connection show --active

などで現在アクティブな接続を確認できます。

目的は、

目的の無線接続が実際にアクティブか

を判断することです。

47. OSが違っても切り分けの考え方は共通

Windows、macOS、Linuxでツールは異なります。

しかし基本考え方は共通です。

無線機能
↓
SSIDの表示状況
↓
接続とセキュリティ
↓
IP
↓
ゲートウェイ
↓
リモートネットワーク
↓
DNS

OS固有のコマンドを暗記するだけではなく、確認目的を理解します。

48. WLAN接続とIP割り当ては別の段階

無線トラブルシューティングで非常に重要なのが、

WLANへ接続した

ことと、

期待するIP設定を取得した

ことを分けることです。

WLAN接続が成功しても、IP割り当てに失敗する場合があります。

49. 「接続済み」表示だけでインターネット接続性が正常とは判断しない

クライアントが、

接続済み

と表示されていても、

• 有効なIP設定がない
• デフォルトゲートウェイへ届かない
• リモートネットワークへ届かない
• DNSが失敗

する可能性があります。

したがって、

Wi-Fi接続済み
=
インターネット利用可能

とは判断しません。

50. アソシエーション・認証成功後にIPを確認する

WLAN接続とセキュリティが成立していることを確認できたら、次にクライアントIP設定を確認します。

確認対象はページ033で扱った、

IPv4・IPv6アドレス
プレフィックス
デフォルトゲートウェイ
DNS
手動設定・DHCP

です。

51. 169.254.x.xだけならIP割り当て側へ確認を移す

例えば無線クライアントが、

SSID接続：成功
認証：成功
IPv4            169.254.x.x

となっている場合、

期待するIPv4アドレスを取得できていない可能性があります。

この場合、

SSIDの表示状況
セキュリティ認証情報

を何度も確認するより、

IP割り当て・クライアントIP設定

へ障害範囲を移します。

52. 169.254.x.xだけでDHCPサーバー故障と断定しない

IPv4リンクローカルアドレスを確認しても、

DHCPサーバー故障確定

とは判断しません。

期待するDHCPアドレスを取得できていない原因候補には、

• クライアント側
• 無線接続
• VLAN・インフラ
• リレー
• DHCPサーバー

など複数あります。

このページでは、

無線接続より後のIP割り当て側

へ切り分けることが重要です。

53. DHCP内部メッセージフローはページ036以降で扱う

このページで、

WLAN接続成功
IP取得失敗

まで切り分けた後、

• DHCPDISCOVER
• DHCPOFFER
• DHCPREQUEST
• DHCPACK
• UDP 67/68
• リレー
• giaddr

の詳細はページ036以降で扱います。

54. 有効なIP設定取得後はネットワーク到達性へ進む

無線クライアントが期待するIP設定を持っているなら、

デフォルトゲートウェイ
↓
リモートIP
↓
名前解決

へ確認を進めます。

ここからの基本考え方はページ034の有線クライアントと共通です。

55. ゲートウェイへ到達できるなら無線側だけを疑い続けない

例えば、

WLAN接続       成功
IP設定       有効
ゲートウェイへのping    成功

なら、無線接続からデフォルトゲートウェイまで一定範囲の通信が成立しています。

リモートサービスへ到達できないからといって、SSIDや認証情報だけを繰り返し変更する必要はありません。

56. 有効なIP設定を取得しゲートウェイ到達も成功したらリモート側へ進む

シナリオ：

無線接続     成功
有効なIP設定          あり
ゲートウェイ       到達可能
リモートIP         失敗

なら、

リモートネットワーク・上流経路

へ確認範囲を進めます。

無線セキュリティを最初からやり直すのは優先順位が低くなります。

57. リモートIP成功・ホスト名失敗ならDNSを確認する

シナリオ：

無線接続     成功
有効なIP設定          あり
ゲートウェイ           成功
リモートIP         成功
ホスト名          失敗

なら、

クライアントのDNS設定
名前解決

を優先します。

無線機能やSSIDの表示状況へ戻る必要はありません。

58. 無線側の障害と無線以外の障害を分ける

無線クライアントを使っているからといって、

発生する全障害
=
無線障害

ではありません。

無線接続後の障害は、

• IP割り当て
• ゲートウェイ
• ルーティング経路
• DNS
• リモートサービス

など無線以外の範囲にある場合があります。

59. SSIDが見えない状態は無線側の重要な切り分け点

例えば、

無線機能オン
目的SSIDが見えない

なら、IP割り当てやリモートルーティングより前の無線側を優先します。

クライアントの周波数帯対応能力やSSIDの表示状況条件を確認します。

60. WLAN接続失敗も無線側の重要な切り分け点

例えば、

SSID表示あり
接続失敗

なら、

• セキュリティ方式
• 認証情報
• クライアントプロファイル
• Enterprise方式なら802.1X関連情報

を優先します。

61. 接続成功後のIP失敗は無線セキュリティと分離する

例えば、

SSID表示           あり
WLAN接続           成功
認証               成功
有効なIP設定            なし

なら、セキュリティを何度も変更するより、

IP割り当て側

へ障害範囲を移します。

62. ゲートウェイ成功後のリモート障害は無線と分離する

例えば、

WLAN接続           成功
IP設定              有効
ゲートウェイ             成功
リモートIP           失敗

なら、無線アソシエーションや認証情報が主要原因である可能性は低くなります。

上流ネットワーク側へ確認を進めます。

63. クライアント側で修正できる無線問題

このページで扱う代表的なクライアント側修正は、

• 無線アダプターと無線機能を有効化
• 正しいSSIDを選択
• 現在のWLAN要件にプロファイルを合わせる
• 正しいPersonal方式の認証情報を使用
• 必要なEnterprise方式の認証情報・証明書を準備
• 不整合な保存プロファイルを更新・再作成
• 必要なクライアントIP設定を修正

などです。

64. 無線機能オフなら無線機能を修正する

シナリオ：

ハードウェア側の無線機能   オン
ソフトウェア側の無線機能   オフ

なら、

ソフトウェア側の無線機能を有効にできる状態へ戻す

ことがクライアント側の最初の修正です。

セキュリティプロファイルやDNSを先に変更しません。

65. 誤ったSSIDなら正しいSSIDへ接続する

複数SSIDが表示されている環境では、

期待しているSSID

へ接続しているか確認します。

似た名前の別SSIDへ接続している場合、その後のセキュリティやIP条件が異なる可能性があります。

66. 古いセキュリティプロファイルなら現在の要件を確認する

シナリオ：

クライアント
WPA3対応

保存プロファイル
WPA2-Personal

現在のWLAN
WPA3-Personal/SAEのみ

なら、保存プロファイルを現在のWLANセキュリティ条件に合うよう更新・再作成します。

一方、クライアント自体がWPA2-Personalまでしか対応していない場合は、プロファイル変更だけでは解決できません。

また、WLANがWPA2/WPA3移行モードでWPA2クライアントを許可している場合は、WPA2プロファイルで接続できる可能性があります。

67. 認証情報だけが誤っているなら認証情報を修正する

セキュリティ方式が正しくても認証情報が誤っている場合、

IPアドレス
ゲートウェイ
DNS

まで根拠なく変更する必要はありません。

確認した不一致
↓
対応する認証情報を修正

とします。

68. Enterprise方式の要件なら必要なID情報・証明書を修正する

Enterprise方式のWLANで、

クライアント証明書：必須

なのに証明書が欠落している場合、

クライアント側要件に合う証明書・ID情報を準備します。

周波数帯やDNSの変更では解決しません。

69. 原因と関係ない設定を同時に変更しない

例えば、

ソフトウェア側の無線機能オフ

だけが確認できている場合に、

プロファイル削除
IPアドレス変更
DNS変更
証明書変更

を同時に行うべきではありません。

変更点を最小限にすると、どの修正が効果を持ったか判断しやすくなります。

70. インフラ側ならクライアントを根拠なく変更しない

クライアント側の、

無線機能
SSID
セキュリティ
認証情報
IP

が期待どおりであるにもかかわらずインフラ側に問題があると判断できる場合、

クライアント設定を無関係に変更し続けません。

障害範囲をインフラ側へ引き渡します。

71. WLCポリシーの詳細変更はこのページでは行わない

このページでは、

WLAN側に問題がある可能性

まで切り分けることがあります。

ただし、

• WLCのWLANポリシー
• AP設定
• RRM
• チャネル変更
• インフラのセキュリティポリシー

などの具体的な管理側変更は扱いません。

72. APチャネルやRF設計の変更へ踏み込まない

SSIDが見えにくいシナリオでも、

チャネル変更
チャネル幅変更
AP配置変更
送信電力変更

などのRF設計作業をこのページのクライアント修正として実施しません。

RFの原理は前の無線基礎で扱います。

73. 修正後は修正した段階から再確認する

無線設定を修正したら、

修正して終了

ではありません。

修正した段階から後続の接続性を再確認します。

74. 無線機能を修正した場合の確認

無線機能を有効化した場合、

無線機能
↓
SSIDの表示状況
↓
WLAN接続
↓
IP
↓
必要なネットワーク到達性

を順に確認します。

75. セキュリティ設定を修正した場合の確認

保存プロファイルやセキュリティ方式を修正した場合、

WLAN接続とセキュリティ
↓
IP設定
↓
ゲートウェイ
↓
リモート接続性
↓
必要なら名前解決

を確認します。

76. 認証情報を修正した場合の確認

PSK・SAE認証情報やEnterprise方式の認証情報を修正した場合も、

認証成功

だけで完了としません。

後続する、

IP割り当て
ゲートウェイ到達性
必要なネットワーク利用

まで確認します。

77. IP取得だけで修正完了とはしない

無線接続後、

有効なIP設定取得

を確認できても、

必要な接続性が戻ったとは限りません。

必要に応じて、

デフォルトゲートウェイ
リモートIP
DNS

まで再確認します。

78. 問題パターン1：Windowsの現在の接続状態

Windowsクライアントで、

現在の無線インターフェース
SSID
状態
信号強度

などを確認する代表的コマンドは、

netsh wlan show interfaces

です。

79. 問題パターン2：Windowsで表示されるSSID

周囲のSSID・BSSID・チャネル・信号強度などを確認する代表的コマンドは、

netsh wlan show networks mode=bssid

です。

80. 問題パターン3：6 GHz非対応クライアント

SSID
6 GHzのみ

クライアント
2.4 GHzと5 GHzのみに対応

なら、最初に確認すべき障害範囲は、

クライアントの周波数帯対応能力

です。

81. 問題パターン4：無線アダプター無効

無線アダプター
無効

なら、最初のクライアント側修正は、

無線アダプターと無線機能を有効化

です。

82. 問題パターン5：SSIDは見えるが接続できない

SSID表示あり
WLAN接続失敗

なら、

クライアントプロファイル
セキュリティ方式
認証情報

を優先します。

83. 問題パターン6：WPA3-PersonalのみとWPA2の不一致

WLAN
WPA3-Personal/SAEのみ

クライアントプロファイル・対応能力
WPA2-Personal/PSKのみ

なら、

セキュリティ方式・認証方式の不一致

です。

WPA2/WPA3移行モードでWPA2クライアントを許可している構成とは区別します。

84. 問題パターン7：WPA3パスフレーズ誤り

セキュリティ方式
WPA3-Personal/SAE

認証情報
誤り

なら、

SAEパスフレーズ・認証情報

を修正します。

85. 問題パターン8：Enterprise方式の802.1X認証失敗

SSID表示あり
Enterprise方式のWLAN
802.1X失敗

なら、

802.1Xの認証情報・証明書

をクライアント側から確認します。

86. 問題パターン9：macOSの無線分析

macOSでWi-Fi接続や無線環境を分析する代表的ツールは、

ワイヤレス診断

です。

87. 問題パターン10：Linuxで表示されるWi-Fi

NetworkManager環境のLinuxで、

SSID
チャネル
信号強度
セキュリティ

などを確認する代表的コマンドは、

nmcli device wifi list

です。

88. 問題パターン11：接続成功だが169.254.x.x

アソシエーション・認証
成功

IPv4
169.254.x.xのみ

なら、

IP割り当て・クライアントIP設定

へ確認を移します。

89. 問題パターン12：ゲートウェイ成功後のリモート障害

WLAN接続      成功
有効なIP設定       あり
ゲートウェイ        成功
リモートサービス：失敗

なら、

リモートネットワーク・経路・サービス側

へ範囲を進めます。

90. 問題パターン13：リモートIP成功・ホスト名失敗

リモートIP
成功

ホスト名
失敗

なら、

クライアントのDNS設定
名前解決

を優先します。

91. 問題パターン14：古いWPA2プロファイル

クライアント
WPA3対応

保存プロファイル
WPA2-Personal

現在WLAN
WPA3-Personal/SAEのみ

なら、

クライアントプロファイルを現在のセキュリティ要件へ更新・再作成

します。

クライアント自体がWPA3非対応なら、プロファイル変更だけでは解決できません。

また、WLANがWPA2/WPA3移行モードを許可している場合は、WPA2プロファイルが必ず不一致になるとは限りません。

92. 問題パターン15：セキュリティ修正後

無線セキュリティを修正したら、

WLAN接続とセキュリティ
↓
IP
↓
ネットワーク到達性

を再確認します。

93. 問題パターン16：Windowsの複数確認ツール

Windowsの無線トラブルシューティングでは、

netsh wlan show interfaces
netsh wlan show networks mode=bssid
netsh wlan show wlanreport

などを目的に応じて使用します。

Cisco IOSのshow ip routeやshow spanning-treeはWindowsクライアント上の無線状態確認コマンドではありません。

94. 問題パターン17：別々の3段階

無線クライアント接続では、

SSIDの表示状況
WLAN接続とセキュリティ
IP割り当て

を別々の段階として扱います。

95. 問題パターン18：同じ場所でクライアント差

6 GHz対応クライアント
SSID表示あり

6 GHz非対応クライアント
SSID表示なし

なら、非対応クライアントの周波数帯の対応能力が重要な確認点です。

96. 問題パターン19：Enterpriseでクライアント証明書が欠落

WLAN要件が、

802.1X
クライアント証明書：必須

でクライアント証明書だけが欠落しているなら、

要件に合うクライアント証明書・ID情報

を準備します。

97. 問題パターン20：macOSのWi-Fi状態

macOSでは、

Wi-Fi設定
ワイヤレス診断

をクライアント側無線状態と接続情報の確認に利用します。

IPv4アドレスやデフォルトルートだけを見るツールではありません。

98. 問題パターン21：Linuxでプロファイルあり・未接続

NetworkManager環境で、

SSID表示あり
接続プロファイル：あり
未接続

なら、

`nmcli`でデバイスと接続の状態

を確認します。

プロファイルが存在するだけで接続済みとは判断しません。

99. 問題パターン22：セキュリティ修正後の3確認

セキュリティプロファイルを修正して再接続した後は、

有効なIP設定
デフォルトゲートウェイ到達性
必要な名前解決

など後続の接続性を確認します。

SSIDが一度見えただけで確認を終了しません。

100. 問題パターン23：ハードウェア側オン・ソフトウェア側オフ

State          : disconnected
Radio status   : Hardware On
                 Software Off

なら、最初に、

ソフトウェア側の無線機能を有効にできる状態へ戻す

ことを確認・修正します。

ハードウェア故障、セキュリティ不一致、DHCP失敗をこの情報だけで確定しません。

101. 無線クライアントのトラブルシューティング比較表

102. Windowsの基本確認フロー

netsh wlan show interfaces
↓
無線機能と現在の接続状態を確認
↓
必要なら
netsh wlan show networks mode=bssid
↓
SSIDの表示状況とクライアント対応能力確認
↓
セキュリティ・プロファイル・認証情報確認
↓
WLAN接続確認
↓
IP設定確認
↓
ゲートウェイとリモート到達性
↓
必要なら名前解決

103. macOSの基本確認フロー

Wi-Fi設定
↓
Wi-Fiと現在のネットワーク確認
↓
SSID・接続・セキュリティ確認
↓
必要ならワイヤレス診断
↓
IP設定
↓
ゲートウェイとリモート到達性
↓
名前解決

104. LinuxのNetworkManager環境における基本確認フロー

nmcli device status
↓
無線デバイス状態
↓
nmcli device wifi list
↓
SSIDの表示状況
↓
接続とプロファイルの状態
↓
WLAN接続
↓
IP設定
↓
ゲートウェイとリモート到達性
↓
名前解決

105. 無線トラブルシューティングで避ける判断

次のような断定は避けます。

SSIDが見えない
→ AP停止確定

SSIDが見える
→ WLAN接続成功

「接続済み」表示
→ 有効なIP設定取得済み

有効なIP設定あり
→ インターネット正常

169.254.x.x
→ DHCPサーバー故障確定

無線クライアントの通信障害
→ 必ずRFまたはセキュリティの問題

それぞれ別の確認が必要です。

106. ページ034とのつながり

ページ034では有線クライアントについて、

Ethernetリンク
クライアントIP設定
ゲートウェイ
リモートIP
traceroute
DNS

を扱いました。

このページでは、

無線アダプターと無線機能
SSID
周波数帯の対応能力
WLAN接続
無線セキュリティ

という無線固有の前段階を追加します。

WLAN接続後のネットワーク到達性の考え方はページ034の考え方を再利用します。

107. RF特性やチャネル設計の基礎とのつながり

このページでは、

クライアントの周波数帯対応能力
SSIDの表示状況

を接続性切り分けの材料として使います。

ただし、

• RF特性
• チャネル設計
• チャネル幅
• 干渉の理論
• AP密度
• RRM

などを再講義しません。

それらは前の無線基礎で扱う内容です。

108. ページ036とのつながり

このページでは、

WLAN接続成功
↓
期待IPなし
↓
IP割り当て側へ切り分け

まで扱います。

その後の、

DHCPDISCOVER
DHCPOFFER
DHCPREQUEST
DHCPACK
UDP 67/68
リレー
giaddr

はページ036以降で扱います。

109. 無線インフラとの切り分け

クライアント側確認の結果、

クライアント設定は正常
インフラ側が疑わしい

と切り分けることはできます。

ただしこのページでは、

• WLCポリシー変更
• WLAN作成
• APチャネル変更
• RADIUSサーバー内部の設定
• スイッチVLAN・PoE修正

などの具体的なインフラ変更は行いません。

110. 無線クライアントの最終トラブルシューティングフロー

無線アダプターと無線機能は利用可能か
├─ なし
│  └─ クライアント側で無線アダプターと無線機能を確認・修正
│
└─ あり
   ↓
目的SSIDは見えるか
├─ なし
│  └─ クライアントの周波数帯対応能力・表示条件を確認
│
└─ あり
   ↓
WLAN接続とセキュリティは成立するか
├─ なし
│  ├─ セキュリティ方式
│  ├─ Personal方式の認証情報
│  └─ Enterprise方式の認証情報・証明書
│
└─ あり
   ↓
期待するIP設定があるか
├─ なし
│  └─ IP割り当て側へ確認を移す
│
└─ あり
   ↓
デフォルトゲートウェイへ到達できるか
├─ なし
│  └─ ローカルネットワーク側へ切り分け
│
└─ あり
   ↓
リモートIPへ到達できるか
├─ なし
│  └─ 上流・リモートネットワーク側へ切り分け
│
└─ あり
   ↓
必要なホスト名を名前解決できるか
├─ なし
│  └─ DNSと名前解決を確認
│
└─ あり
   ↓
必要な接続性が成立

111. 最終的に判断できるようにすること

このページでは、次のシナリオを判断できることが重要です。

無線アダプター無効
→ 無線アダプターと無線機能を修正

無線機能オン・SSID表示なし
→ 周波数帯の対応能力・表示条件を確認

SSID表示あり・接続失敗
→ セキュリティ方式・認証情報を確認

WPA3-Personal・誤ったパスフレーズ
→ SAE認証情報を修正

Enterprise方式のWLAN・802.1X認証失敗
→ クライアントのID情報・認証情報・証明書を確認

接続成功・169.254.x.x
→ IP割り当て側へ移動

有効なIP設定・ゲートウェイ成功・リモート到達失敗
→ 無線より先のネットワークへ切り分け

リモートIP成功・ホスト名失敗
→ DNSと名前解決を確認

クライアント側の不一致修正
→ 接続 → IP → ネットワーク到達性を再確認

まとめ

無線クライアント接続では、

無線アダプターと無線機能
↓
SSIDの表示状況
↓
クライアントの周波数帯対応能力
↓
WLAN接続とセキュリティ
↓
IP割り当て
↓
ゲートウェイとリモートIP
↓
名前解決

という段階を分けて確認します。

SSIDが見えること、WLANへ接続できること、有効なIPを取得すること、リモートネットワークへ到達できることは、それぞれ別の確認です。

Windowsではnetsh wlan、macOSではWi-Fi設定やワイヤレス診断、NetworkManager環境のLinuxではnmcliを確認ツールとして利用できます。

無線クライアントを使用しているからといって、すべての障害をRFやセキュリティへ帰属させてはいけません。

どこまで無線段階が成功しているか
↓
IP割り当てへ進めるか
↓
無線以外のネットワーク側へ障害範囲を移すべきか

を判断します。

クライアント側に明確な不一致があれば対応する設定だけを修正し、修正後は、

WLAN接続とセキュリティ
↓
IP設定
↓
ゲートウェイ
↓
リモート接続性
↓
必要なら名前解決

を再確認して、期待する無線接続性が回復したことを検証します。