試験項目 1.6 · CCNA-034

Wired Client Connectivity

Ethernet Link / Gateway / Remote IP / Path / DNS / 障害範囲 / 修正 / 修正後確認

このページのゴール

Wired ClientでLinkから名前解決まで段階的に確認し、障害範囲を絞り、Client側で必要な修正と修正後確認を判断できるようにする。

このページで学ぶこと

Wired Link State
Client設定 Reuse
Gateway 到達性
Remote IP 到達性
Ping 確認情報 Limitation
Traceroute Path 確認情報
Traceroute Timeout Limitation
DNS 名前解決テスト
IP vs DNS 障害範囲
障害範囲 Localization
Client側修正
Infrastructure Boundary
修正後確認 Sequence

1. 有線クライアントは近い地点から順に切り分ける

有線クライアントで「ネットワークにつながらない」と言われても、最初からリモートサーバーやルーターを原因と決めてはいけません。確認範囲をクライアントに近い場所から外側へ広げます。

Ethernetリンク
↓
クライアントIP設定
↓
デフォルトゲートウェイ到達性
↓
リモートIP到達性
↓
経路
↓
名前解決
↓
必要なエンドツーエンド確認

この順序で確認すると、

どこまで正常か
↓
どこから先が異常か
↓
次に何を確認するか

を整理しやすくなります。

2. 最初にEthernetリンク状態を確認する

有線クライアントでは、まず使用しているEthernetアダプターがリンクを確立しているか確認します。確認する代表的な状態は、

アダプターが有効か
ケーブル接続をOSが認識しているか
メディア接続状態
リンクアップまたはリンクダウン

です。例えばWindowsで、

Media disconnected

と表示されている場合、リモートIPやDNSを先に調べるより、まずローカルリンク側を確認します。

3. リンクダウン時はクライアントに近い範囲から確認する

Ethernetリンクが成立していなければ、そのクライアントは通常、そのインターフェースを使ってデフォルトゲートウェイやリモートネットワークへ通信できません。したがって、

リンクダウン
↓
クライアントに最も近い範囲を確認

と考えます。ただしこのページでは、

CRCエラー
デュプレックス不一致
速度不一致
ケーブル長
ピン配置
光信号レベル

などの詳細診断は行いません。それらの詳細は、インターフェースやケーブルの障害診断で扱います。

4. リンクアップだけでネットワーク全体が正常とは判断しない

Ethernetリンクがアップであることは重要な確認情報ですが、

リンクアップ
=
ネットワーク接続性全体が正常

ではありません。リンクがアップでも、

IPアドレスが誤っている
プレフィックスが誤っている
デフォルトゲートウェイが誤っている
DNSサーバーが誤っている
ローカルネットワーク側にインフラ問題がある
上流経路に問題がある

可能性があります。リンクアップは、

次の確認へ進める

という意味で利用します。

5. リンク成立後はページ033で確認したクライアント設定を見る

リンクが成立しているなら、次にクライアントIP設定を確認します。ここではページ033で確認した情報を再利用します。

使用中インターフェース
IPv4とIPv6アドレス
プレフィックスまたはサブネットマスク
デフォルトゲートウェイ
DNSサーバー
手動設定またはDHCPなどの設定方式

このページではこれらの設定方法を最初から再講義するのではなく、

現在の設定
↓
期待する設定との比較
↓
実際の接続性

を組み合わせて障害範囲を判断します。

6. 設定値の正しさと実際の到達性は分けて確認する

クライアント設定が見た目上正しくても、実際のネットワーク到達性まで保証されるわけではありません。例えば、

IPアドレス    192.168.10.25
プレフィックス        /24
ゲートウェイ       192.168.10.1

が設計どおりでも、インフラ側の問題によってゲートウェイへ到達できない場合があります。逆に、現在通信できていても設定値が設計値と異なるなら、設定不一致を放置すべきとは限りません。したがって、

設定確認

と

到達性確認

を分けて考えます。

7. デフォルトゲートウェイ到達性を確認する

クライアント設定に大きな不一致がなければ、次にデフォルトゲートウェイへの到達性を確認します。例えば、

クライアント
192.168.10.25/24

デフォルトゲートウェイ
192.168.10.1

なら、

ping 192.168.10.1

などを使ってゲートウェイとの通信を確認できます。デフォルトゲートウェイはリモートネットワークへ向かう際のローカルネットワーク側の重要な境界です。

8. ゲートウェイ確認は「ローカル側がどこまで動くか」を見る

デフォルトゲートウェイへの通信確認によって、

クライアント
↓
ローカルネットワーク
↓
デフォルトゲートウェイ

までの状態を切り分ける材料が得られます。ゲートウェイへの通信が成功するなら、少なくともその試験で使用した通信について、クライアントからゲートウェイまで到達し、応答が返っていることを確認できます。

9. ゲートウェイへ到達できない場合の確認範囲

リンクがアップでクライアント設定も期待値と一致しているのにゲートウェイへ到達できない場合は、クライアントだけを原因と決めつけません。確認範囲には例えば、

クライアント
ローカルリンク
ローカルのレイヤー2ネットワーク
ゲートウェイ側
インフラ設定
ポリシー

などが含まれます。このページの目的は、

ゲートウェイより手前側に問題がある可能性が高い

という障害範囲を絞ることです。スイッチVLANなどの具体的なインフラ設定の修正まではここでは扱いません。

10. ゲートウェイへのping失敗だけでも原因を確定しない

ゲートウェイへのpingが失敗した場合も、

ゲートウェイがダウンしている

と即断してはいけません。pingは重要な到達性テストですが、ICMPに対する応答制限やフィルタリングなどの影響を受ける場合があります。したがって、

ping失敗
=
通信問題を示す確認情報の1つ

として扱います。

11. リモートIP到達性をゲートウェイと分けて確認する

デフォルトゲートウェイまで確認できたら、次にリモートネットワーク上のIPアドレスへの到達性を確認します。例えば、

クライアント
192.168.10.25

ゲートウェイ
192.168.10.1

リモートサーバー
203.0.113.20

なら、

ping 192.168.10.1

と

ping 203.0.113.20

を別々の確認情報として扱います。

12. ゲートウェイ成功・リモートIP失敗は重要な境界になる

例えば、

Ethernetリンク     アップ
クライアント設定        正常
ゲートウェイへのping      成功
リモートIPへのping    失敗

なら、クライアントとゲートウェイまでのローカル側通信は一定範囲で成立しています。そのため確認範囲を、

ゲートウェイより先
上流経路
リモートネットワーク
宛先側

へ広げます。

13. ゲートウェイ成功後も「ローカル側は完全正常」と断定しない

デフォルトゲートウェイへの通信が成功したからといって、ローカルネットワークに一切問題がないことまで証明されるわけではありません。ただしトラブルシューティングでは、

ゲートウェイへの通信が成功

という確認情報によって、調査の優先度をクライアントに近い範囲から上流側へ移せます。重要なのは、

正常を完全証明する

ことではなく、

次に確認すべき範囲を絞る

ことです。

14. pingはIP到達性を確認する代表的なツール

pingは、宛先へICMPエコー要求を送り、応答を利用してIPレベルの到達性を確認する代表的なツールです。例えば、

ping 203.0.113.20

が成功すれば、その試験時点で、

クライアント
↓
IPネットワーク
↓
宛先
↓
クライアントへの応答

が成立したことを確認する材料になります。

15. ping成功でアプリケーションまで正常とは限らない

リモートIPへのpingが成功しても、

Web
SSH
ファイル転送
データベース
その他のアプリケーションサービス

まで正常とは限りません。pingで確認しているのは主にIPレベルの到達性です。したがって、

ping成功
=
すべてのアプリケーションが正常

とは判断しません。

16. ping失敗でリモートホストの停止とは断定しない

リモートIPへのpingが失敗しても、

リモートホストが停止している

と確定することはできません。考えられる要因には、

ネットワーク経路上の問題
宛先側の問題
ICMPフィルタリング
ICMPへの応答制限
セキュリティポリシー

などがあります。そのため、

ping失敗
↓
追加の確認情報を取得する

という流れにします。

17. 1回の試験結果だけで根本原因を決めない

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

1つのコマンド
↓
1つの結果
↓
根本原因確定

という考え方を避けます。例えば、

リモートIPへのping失敗

だけでは、

クライアント
ローカルネットワーク
ルーティング経路
リモートネットワーク
宛先
フィルタリング

のどこが原因かは確定できません。複数の確認結果を関連付けます。

18. 到達性テストは複数の結果を比較して読む

次のように結果を並べると障害範囲を判断しやすくなります。

リンク	クライアント設定	ゲートウェイ	リモートIP	主な確認範囲
ダウン	未確認	未確認	未確認	クライアントに近いリンク
アップ	不一致	未確認	未確認	クライアント設定
アップ	正常	失敗	未確認	ローカルネットワークやインフラ側
アップ	正常	成功	失敗	上流経路やリモート側
アップ	正常	成功	成功	IP到達性より上の確認へ

この表は根本原因を自動確定するものではありません。次の調査範囲を絞るために利用します。

19. 経路を確認するときはWindowsでtracertを利用できる

Windowsクライアントでは、

tracert <宛先>

を利用して宛先までの経路に関する確認情報を取得できます。例えば、

tracert 203.0.113.20

のように実行します。

20. macOSとLinuxではtraceroute系ツールを利用できる

macOSやLinuxでは、利用可能な環境で、

traceroute <宛先>

などを利用できます。目的はWindowsのtracertと同様に、

宛先までの経路上で
どのようなホップが観測されるか

を確認することです。コマンドの実装や利用可能なオプションはOSや環境によって異なるため、このページでは経路確認という役割を重視します。

21. tracerouteの結果はホップ単位で読む

例：

1  192.168.10.1
2  198.51.100.1
3  198.51.100.9
4  203.0.113.20

この場合、

ホップ1
↓
ホップ2
↓
ホップ3
↓
宛先

という経路上の応答を確認できます。トラブルシューティングでは、

最後に応答したホップ
後続ホップの状態
宛先へ到達したか

を確認します。

22. tracerouteはルーティングテーブルそのものを表示するコマンドではない

tracertやtracerouteで見ているのは、クライアントから実際に試験した宛先へ向かう経路上で観測されたホップです。これは、

各ルーターのルーティングテーブルをすべて表示する

ものではありません。経路確認情報として利用します。

23. tracerouteの途中に「*」が出ることがある

例：

1  192.168.10.1
2  *  *  *
3  198.51.100.1
4  203.0.113.20

この結果ではホップ2から応答を得られていません。しかしホップ3と宛先は応答しています。したがって、

ホップ2 = 停止

とは判断できません。

24. 中間ホップが応答しなくてもトラフィックを転送できる場合がある

途中ルーターがtraceroute用の応答を返さなくても、通過トラフィックを転送している場合があります。したがって、

ホップ2  * * *
ホップ3  応答
ホップ4  宛先応答

なら、ホップ2の機器故障を根拠なく確定してはいけません。

25. tracerouteタイムアウトは「応答が得られなかった」という情報

tracerouteで表示される * は、そのプローブに対して期待した応答をタイムアウトまでに受け取れなかったことを示します。重要なのは、

*
=
機器停止と確定

ではないことです。

26. タイムアウトが途中だけなら後続ホップも確認する

次の結果を考えます。

1  192.168.10.1
2  * * *
3  198.51.100.1
4  203.0.113.20

ホップ2だけを見て止めず、

後続ホップが応答しているか
宛先に到達しているか

まで確認します。このシナリオでは宛先まで到達しているため、ホップ2のタイムアウトを障害地点と断定しません。

27. タイムアウトが継続する場合は障害範囲を絞る材料になる

次のような結果を考えます。

1  192.168.10.1
2  198.51.100.1
3  198.51.100.9
4  * * *
5  * * *
6  * * *

さらに宛先へ到達できない場合、

最後に応答したホップより先

を確認対象にする材料になります。ただし、

ホップ4のルーターが故障

とtracerouteだけで確定することはできません。

28. tracerouteは故障箇所を自動的に特定するツールではない

tracerouteは非常に有用ですが、

最初の*
=
根本原因

ではありません。tracerouteから判断できるのは、

経路上のどの範囲まで応答が観測されたか

です。その情報を他の到達性テストと組み合わせます。

29. ゲートウェイへのpingとtracerouteを関連付ける

例えば、

ゲートウェイへのping       成功
リモートIPへのping     失敗
traceroute
ホップ1 ゲートウェイ      応答
ホップ2              応答
ホップ3以降          タイムアウト
宛先        応答なし

なら、クライアント自身の設定だけを何度も変更するより、

上流側の経路

を調査対象にする合理性が高くなります。

30. ゲートウェイへ到達できない状態でリモート経路から調べない

例えば、

リンク               アップ
クライアント設定          正常
ゲートウェイへのping        失敗
リモートIPへのping         失敗

の場合、リモートネットワークだけを優先して調べるのは効率的ではありません。まず、

クライアント
↓
ローカルネットワーク
↓
ゲートウェイ

の範囲を確認します。

31. ローカルネットワークとリモートネットワークを区別する

有線クライアントのトラブルシューティングでは、

ローカルネットワーク

と

リモートネットワーク

を区別することが重要です。クライアントと同一ローカルネットワーク内の通信と、デフォルトゲートウェイを経由するリモートネットワーク通信では、確認する障害範囲が異なります。

32. プレフィックス判断そのものはページ033の結果を利用する

ローカルとリモート判断にはクライアントのプレフィックスが関係します。ただしこのページではサブネット計算を再講義しません。ページ033までで確認した、

クライアントアドレス
プレフィックス
デフォルトゲートウェイ

が期待値と一致していることを前提に、接続性を確認します。

33. IP到達性の次に名前解決を分離する

IPアドレスでは宛先へ到達できるのに、ホスト名では接続できない場合があります。例えば、

203.0.113.20

へのIP到達性は確認できる一方、

server.example

が期待するIPへ名前解決できないシナリオです。この場合、

ネットワーク到達性

と

名前解決

を別問題として扱います。

34. IPで成功・ホスト名で失敗ならDNS側を優先する

同じ宛先について、

IPアドレスで到達      成功
ホスト名での利用      失敗

となる場合、確認範囲をクライアントのDNS設定や名前解決側へ移します。リンクやゲートウェイを最初から繰り返し調査するより、

DNSサーバー設定
名前解決テスト

を確認します。

35. Windowsではnslookupを利用できる

Windowsでは代表的なDNS確認ツールとして、

nslookup

を利用できます。例えば、

nslookup server.example

を実行し、

クエリに使用されたDNSサーバー
名前解決の結果
返されたアドレス

などを確認する材料にできます。

36. DNS設定確認とDNSクエリ確認は別である

ページ033では、

クライアントに設定されているDNSサーバーアドレス

を確認しました。このページではさらに、

実際に名前解決を試験するとどうなるか

を確認します。つまり、

DNSサーバーアドレスが設定されている

ことと、

名前解決が成功する

ことは同じではありません。

37. DNSサーバーアドレスが正しくても名前解決失敗は起こり得る

例えばクライアントに期待どおりのDNSサーバーアドレスが設定されていても、

DNSサーバーへの到達性
DNSサーバー側の状態
クエリ結果
対象名に関するDNS側の問題

などによって名前解決が失敗する可能性があります。このページでは、

クライアント側設定か
名前解決側か

という障害範囲を判断します。DNSレコードの詳細診断までは行いません。

38. DNSレコードタイプの詳細診断はここでは扱わない

このページでは、

ホスト名が期待どおり解決できるか

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

Aレコード
AAAAレコード
CNAME
MX
TXT

などのレコードタイプ自体の詳細なトラブルシューティングはここでは行いません。クライアント接続性から障害範囲を示すところまでです。

39. ホスト名失敗でも必ずDNSとは限らない

アプリケーション上でホスト名指定時に失敗しただけでは、常にDNSが原因とは限りません。そのため、

IPアドレスによる到達性
と
DNSクエリ結果

を確認します。例えば、

IP到達性    成功
nslookup           失敗

なら、名前解決側へ障害範囲をかなり絞れます。

40. IPとDNSを比較する基本シナリオ

Ethernetリンク      アップ
クライアント設定          正常
ゲートウェイ            成功
リモートIP          成功
DNSクエリ          失敗

この場合、

クライアントからリモートネットワークまでのIP到達性

は確認できています。次に優先するのは、

クライアントのDNS設定
DNSサーバー到達性
名前解決

です。

41. 障害範囲は「最後に成功した地点」から絞る

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

何が失敗したか

だけではなく、

どこまで成功したか

を見ることが重要です。例えば、

リンク       成功
設定     正常
ゲートウェイ    成功
リモートIP失敗

なら、

ゲートウェイまで成功

という事実が障害範囲を絞る材料になります。

42. 「最初に失敗した確認」も重要な手掛かりになる

確認を近い場所から順番に実施している場合、

最初に失敗した段階

は重要です。例えば、

リンク       成功
設定     正常
ゲートウェイ    失敗

なら、まずゲートウェイまでの範囲を調査します。一方、

ゲートウェイ    成功
リモートIP失敗

なら、確認範囲をゲートウェイより先へ移します。

43. 確認項目ごとに大まかな障害範囲を整理する

有線クライアントでは大まかに、

確認	主に得られる情報
Ethernetリンク	クライアントに近い物理・リンク状態
IPアドレス・プレフィックス・デフォルトゲートウェイ	クライアントのレイヤー3設定
ゲートウェイ到達性	ローカルネットワーク出口までの到達性
リモートIP	エンドツーエンドのIP到達性の一部
traceroute	経路上のホップ確認情報
DNSクエリ	名前解決

として整理できます。ただし、1つの試験だけで厳密なレイヤーや根本原因を確定するものではありません。

44. クライアント側で直せる問題とインフラ側を分ける

トラブルシューティングの結果、クライアント側に明確な不一致が見つかった場合はクライアント側を修正できます。例えば、

アダプターが無効
IPアドレスが設計値と違う
プレフィックスが違う
デフォルトゲートウェイが違う
DNSサーバーが違う
手動設定またはDHCP設定方式が違う

などです。

45. 原因と関係のないクライアント設定を変更しない

例えば、

デフォルトゲートウェイだけが誤っている

と確認できたなら、根拠なく、

IPアドレス
プレフィックス
DNSサーバー

まで同時に変更する必要はありません。トラブルシューティングでは、

確認した不一致
↓
対応する設定を修正

を基本にします。

46. デフォルトゲートウェイ不一致の修正例

期待値：

デフォルトゲートウェイ
192.168.20.1

実際：

デフォルトゲートウェイ
192.168.2.1

なら、クライアント側のデフォルトゲートウェイ設定を期待値へ修正します。

192.168.2.1
↓
192.168.20.1

原因がゲートウェイ不一致なら、DNSやプレフィックスを根拠なく変更しません。

47. DNSサーバー不一致の修正例

次の状態を考えます。

IPアドレス        正常
プレフィックス            正常
ゲートウェイ           正常
リモートIP         到達可能

DNSサーバー
旧アドレスを設定

この場合、クライアントのDNSサーバー設定を正しい設計値へ修正することが適切です。

48. クライアント設定が正しければインフラ側へ境界を移す

クライアント側に不一致がなく、リンクや各到達性テストからインフラ側が疑われるなら、

クライアント設定を根拠なく変更する

のではなく、

インフラ側へ障害範囲を切り分ける

ことが重要です。

49. スイッチVLANの具体的な修正はここでは扱わない

例えば、

クライアント設定正常
↓
スイッチ側のVLAN設定不備が判明

した場合、ページ034で重要なのは、

クライアントではなくインフラ側の問題

と判断できることです。具体的な、

アクセスポートVLAN変更
トランク設定
switchport設定

などの具体的な設定変更は、スイッチ設定の説明で扱います。

50. スイッチポートの具体的な修正はインフラ側で行う

クライアントから見ると、

リンク
設定
ゲートウェイ到達性

などを確認できます。しかし、

スイッチポートをどのように設定変更するか

はこのページでは扱いません。このページでは、

クライアント側か
インフラ側か

を分離することを重視します。

51. ルーティングプロトコルや経路選択の詳細診断はここでは扱わない

ゲートウェイまでは正常だがリモートネットワークへ到達できない場合、ルーティング側に問題がある可能性があります。ただしこのページでは、

OSPF
スタティックルート
経路選択
アドミニストレーティブディスタンス
メトリック

などの詳細診断へ進みません。

上流経路側を確認する必要がある

という切り分けまでを扱います。

52. DHCP内部処理へすぐ進まない

クライアントに期待するアドレスがない場合でも、このページではDHCPサーバーやDHCPリレー内部処理を詳細に追いません。まずページ033の結果として、

クライアント設定が期待と違う

ことを識別します。DHCPメッセージフローやリレーの詳細診断はここでは扱いません。

53. 有線と無線の切り分けを混在させない

ページ034は有線クライアント接続を扱います。したがって、

SSID
周波数帯
WPA2
WPA3
アソシエーション
無線認証
802.1X無線セキュリティパラメーター

などを有線接続のトラブルシューティングへ混在させません。無線固有の段階はページ035で扱います。

54. 問題パターン1：Media disconnected

シナリオ：

Windows Ethernetアダプター
Media disconnected

最初に確認する対象は、

Ethernetリンク状態

です。DNSやリモート経路よりクライアントに近い状態から確認します。

55. 問題パターン2：リンクアップ後の次の確認

シナリオ：

Ethernetリンクアップ
通信不可

次に確認するのはページ033で扱った、

IP
プレフィックス
ゲートウェイ
DNS
設定方式

です。いきなりリモートサーバーだけを調べません。

56. 問題パターン3：まずゲートウェイを確認する

シナリオ：

クライアント
192.168.10.25/24

ゲートウェイ
192.168.10.1

ローカルネットワーク側の到達性確認として、

192.168.10.1

への通信を確認します。

57. 問題パターン4：ゲートウェイ成功・リモート失敗

ゲートウェイ      成功
リモートIP    失敗

なら、

クライアントのローカルリンクだけ

を原因と決めず、

上流経路

へ確認範囲を広げます。

58. 問題パターン5：リモートIPへのping失敗

ping <リモートIP>
失敗

だけなら、

宛先ホスト停止

とは確定できません。ICMPへの応答制限なども考慮し、追加の確認情報を取得します。

59. 問題パターン6：Windowsの経路確認

Windowsで宛先までのホップ情報を確認する代表的コマンドは、

tracert

です。

60. 問題パターン7：途中ホップだけ「*」

1  192.168.10.1
2  * * *
3  198.51.100.1
4  203.0.113.20

なら、

ホップ2停止と確定

とは判断しません。後続ホップと宛先が応答していることを重視します。

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

リモートIP
成功

ホスト名
失敗

なら、

DNSサーバー設定
名前解決

を優先して確認します。

62. 問題パターン9：WindowsのDNS確認

Windowsでクライアント側からDNS名前解決を確認する代表的ツールは、

nslookup

です。

63. 問題パターン10：IP通信だけ成功する

同じ宛先について、

IPアドレスで通信
成功

ホスト名指定
失敗

なら、名前解決側を優先して切り分けます。

64. 問題パターン11：ゲートウェイ設定だけ誤っている

期待値：

192.168.20.1

実際：

192.168.2.1

なら、

デフォルトゲートウェイを期待値へ修正

します。他の正常設定を根拠なく変更しません。

65. 問題パターン12：DNSサーバーだけ誤っている

IPアドレス    正常
ゲートウェイ       正常
リモートIP     成功
DNSサーバー    旧アドレス

なら、

クライアントのDNSサーバー設定を修正

します。

66. 問題パターン13：スイッチVLAN側が疑われる

クライアント設定が正常で、スイッチVLAN側の設定不備が疑われる場合、

インフラ側へ切り分ける

と判断します。スイッチVLANの具体的な修正手順までは扱いません。

67. 問題パターン14：クライアント設定修正後

クライアントのIPアドレス・プレフィックスなどを修正したら、

設定値を変更して終了

ではありません。新しい設定値と必要な到達性を再確認します。

68. 問題パターン15：有線接続の初期3段階

有線クライアントの基本的な初期確認は、

Ethernetリンク
↓
クライアントIP設定
↓
デフォルトゲートウェイ到達性

です。無線SSIDやWPA3パラメーターは有線接続の初期確認には入りません。

69. 問題パターン16：macOSとLinuxの経路確認目的

macOSとLinuxでtraceroute系ツールを使用する主目的は、

宛先までのホップ情報を確認する

ことです。DNS設定変更やDHCPプール確認のためのツールではありません。

70. 問題パターン17：タイムアウトが最後まで継続する

1  応答
2  応答
3  応答
4  * * *
5  * * *
6  * * *
宛先 応答なし

なら、ホップ4付近より先を調査対象にする材料になります。ただし、

ホップ4 機器停止と確定

とは判断しません。

71. 問題パターン18：ゲートウェイには到達できる

ゲートウェイ
成功

リモートサービス
失敗

なら、クライアントのローカルリンクだけを原因と決めず上流側も確認します。また、リモートIPへのpingが失敗しても、それだけでリモートホストの停止とは断定しません。

72. 問題パターン19：インフラ修正後

クライアント設定が正常でインフラ側に問題があり、インフラ側で修正された場合も、クライアントから再確認します。例えば、

Ethernetリンク
↓
クライアント設定
↓
ゲートウェイ到達性
↓
リモート到達性

を必要な範囲で確認し、期待する接続性が戻ったことを検証します。

73. 修正後確認は根本原因に近い地点から始める

修正後は、何でも最初から機械的に実行する必要はありません。ただし、

修正した設定
↓
その設定が影響する近い通信
↓
より遠い通信

の順で確認すると確実です。例えばゲートウェイを修正したなら、

ゲートウェイ設定値
↓
ゲートウェイ到達性
↓
リモートIP到達性
↓
必要ならDNS

を確認します。

74. IPアドレスとプレフィックスを修正した場合の確認

クライアントのIPアドレスやプレフィックスを修正したなら、

1. 新しいアドレスとプレフィックスを確認
2. デフォルトゲートウェイ設定を確認
3. ゲートウェイ到達性を確認
4. リモートIP到達性を確認
5. 必要なら名前解決を確認

という流れが考えられます。

75. DNSサーバーを修正した場合の確認

DNSサーバーアドレスを修正したなら、

1. DNSサーバー設定値を確認
2. IP到達性が維持されていることを確認
3. 名前解決を再試験
4. 必要なホスト名が期待どおり利用できることを確認

します。

76. インフラ修正後もクライアントから確認する

インフラ担当者がスイッチや上流側を修正した場合でも、

インフラ側で修正済み
=
クライアント接続性確認不要

ではありません。クライアントの視点から、

リンク
IP設定
ゲートウェイ
リモート到達性
名前解決

のうち必要な項目を再確認します。

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

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

リンクアップ
→ ネットワーク全体が正常

ゲートウェイへのping失敗
→ ゲートウェイ機器の故障と確定

リモートIPへのping失敗
→ リモートサーバー停止と確定

tracerouteで*
→ そのルーター故障確定

リモートIP成功
→ DNSも正常

クライアント設定正常
→ インフラも正常

いずれも確認情報を過剰に解釈しています。

78. 有線接続のトラブルシューティング比較表

状態	判断	次の確認
Ethernetリンクダウン	クライアントに近いリンク側を優先	アダプターとリンク
リンクアップ・クライアント設定不一致	クライアント設定問題を優先	設計値との比較・修正
リンクアップ・設定正常・ゲートウェイ失敗	ローカルネットワーク側を優先	ローカルインフラ
ゲートウェイ成功・リモートIP失敗	上流側へ範囲を移す	経路やリモート側
リモートIP成功・ホスト名失敗	名前解決側を優先	DNS設定とDNSクエリ
traceroute途中のみタイムアウト	ダウンとは断定しない	後続ホップと宛先
tracerouteタイムアウト継続・宛先失敗	経路上の範囲を絞る	最後の応答地点より先
インフラ側原因	クライアント設定を根拠なく変更しない	インフラ側へ切り分け
修正後	設定変更だけで終了しない	接続性再確認

79. Windows有線クライアントの基本的な確認フロー

Ethernetアダプターとリンク
↓
ipconfig /all等でクライアント設定確認
↓
デフォルトゲートウェイ到達性
↓
リモートIP到達性
↓
必要ならtracert
↓
nslookup等で名前解決
↓
障害範囲を判断
↓
クライアント側なら修正
インフラ側なら切り分け
↓
再確認

80. macOSとLinuxでも切り分けの考え方は同じ

使用するコマンドや画面はOSごとに異なります。しかし切り分けの考え方は共通です。

リンク
↓
クライアント設定
↓
ゲートウェイ
↓
リモートIP
↓
経路
↓
DNS

コマンド名だけを暗記するのではなく、

そのツールで何を確認したいのか

を理解します。

81. ページ033とのつながり

ページ033は、

使用中インターフェース
IPv4とIPv6
プレフィックス
デフォルトゲートウェイ
DNSサーバー
手動設定またはDHCP
期待値と実際値

を確認するページです。このページではその結果を利用して、

実際にどこまで通信できるか

を確認します。

82. ページ035とのつながり

このページでは有線クライアントを扱います。次のような無線固有項目はページ035で扱います。

無線アダプターと無線機能
SSID
周波数帯対応
アソシエーション
WPA2/WPA3
PSK/SAE
802.1Xの資格情報と証明書
無線診断

83. DHCP詳細診断との切り分け

このページではクライアントに適切なIP設定があるかを利用します。ただし、

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

などのDHCP内部処理は、DHCPの詳細診断で扱います。

84. インフラ設定との切り分け

このページの確認結果から、

ローカルインフラ側
上流側
DNS側

へ障害範囲を切り分けることはできます。しかし、

スイッチVLAN設定
スイッチポート設定
ルーティングプロトコル
経路選択
DNSレコード設定

の具体的な修正はここでは扱いません。

85. 有線クライアントの最終確認フロー

Ethernetリンクは成立しているか
├─ いいえ
│  └─ クライアントに近いリンク側を確認
│
└─ はい
   ↓
クライアントIP設定は期待値と一致するか
├─ いいえ
│  └─ クライアント側の不一致を修正
│
└─ はい
   ↓
デフォルトゲートウェイへ到達できるか
├─ いいえ
│  └─ ローカルネットワーク側を優先して確認
│
└─ はい
   ↓
リモートIPへ到達できるか
├─ いいえ
│  └─ 上流経路やリモート側を確認
│       ↓
│       必要ならtracertまたはtraceroute
│
└─ はい
   ↓
ホスト名は期待どおり名前解決できるか
├─ いいえ
│  └─ DNS設定と名前解決を確認
│
└─ はい
   ↓
必要な接続性が成立

各失敗は根本原因を自動確定するものではありません。確認範囲を段階的に絞るための分岐です。

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

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

Media disconnected
→ リンク側から確認

リンクアップかつクライアント設定不一致
→ クライアント設定を修正

クライアント設定正常・ゲートウェイ失敗
→ ローカルネットワーク側を優先

ゲートウェイ成功・リモートIP失敗
→ 上流経路へ範囲を移す

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

traceroute途中だけ*
→ 中間機器の停止とは断定しない

タイムアウト継続・宛先未到達
→ 最後に応答した地点より先を確認対象にする

クライアント設定正常・インフラ問題
→ インフラ側へ切り分ける

修正完了
→ クライアントから必要な接続性を再確認

まとめ

有線クライアント接続では、クライアントに近い地点から順に確認します。

Ethernetリンク
↓
クライアントIP設定
↓
デフォルトゲートウェイ到達性
↓
リモートIP到達性
↓
tracerouteによる経路確認
↓
DNS名前解決

pingやtracert、tracerouteは重要な確認ツールですが、単一結果だけで根本原因を確定してはいけません。特に、

ping失敗
=
宛先停止確定

や、

tracerouteの*
=
そのルーター故障確定

とは判断しません。クライアント側に明確な不一致があれば対応する設定を修正し、インフラ側に障害範囲を絞れた場合はクライアント設定を根拠なく変更しません。修正後は、

修正内容
↓
近距離の到達性
↓
リモート到達性
↓
必要なら名前解決

の順で再確認し、期待する有線接続が回復したことを確認します。

理解確認

このページの内容を15問で確認します。

理解確認15問へ →