トラブルシューティング実践
ネットワーク障害の切り分け手法
ネットワーク障害が発生した場合、闇雲に対処するのではなく、体系的な切り分けを行うことで効率的に原因を特定できます。OSI参照モデルの下位層から順に確認していく「ボトムアップ法」が基本です。
障害切り分けの手順
- 物理層（L1）の確認：ケーブル接続、リンクランプ、ポートのLED状態
- データリンク層（L2）の確認：MACアドレステーブル、VLANの設定、STPの状態
- ネットワーク層（L3）の確認：IPアドレス、サブネットマスク、デフォルトゲートウェイ、ルーティング
- トランスポート層（L4）の確認：ポート番号、ファイアウォールルール
- アプリケーション層（L7）の確認：DNS解決、Webサーバー応答、アプリケーション設定
ポイント：「影響範囲」を最初に確認することが重要です。1台だけの問題か、1つのフロアか、全社的な問題かによって、原因の候補が大きく変わります。全員が影響を受けているならルーターやコアスイッチ、1人だけなら端末側を疑うのが定石です。
基本的なトラブルシューティングコマンド
ipconfig / ifconfig
端末のネットワーク設定を確認するコマンドです。
📋 具体例
ipconfig /all
確認ポイント：
・IPアドレスが正しいか（169.254.x.x ではないか = DHCP障害）
・サブネットマスクが正しいか
・デフォルトゲートウェイが設定されているか
・DNSサーバーが設定されているか
DHCP再取得：
ipconfig /release
ipconfig /renew
DNSキャッシュのクリア：
ipconfig /flushdns
ping
宛先への到達性を確認する最も基本的なコマンドです。段階的にpingを打つことで、障害箇所を特定します。
📋 具体例
段階的ping確認の手順：
① ping 127.0.0.1 → 自身のTCP/IPスタック確認
② ping 192.168.1.100 → 自身のIPアドレス（NIC動作確認）
③ ping 192.168.1.1 → デフォルトゲートウェイ（LAN内通信）
④ ping 8.8.8.8 → 外部IP（インターネット到達性）
⑤ ping www.google.com → DNS名前解決の確認
③まで成功して④で失敗 → ルーターからインターネットへの問題
④まで成功して⑤で失敗 → DNS設定の問題
②で失敗 → NICの故障またはドライバーの問題
tracert（traceroute）
宛先までの経路（通過するルーター）を表示するコマンドです。どの中継地点で遅延や断が発生しているか特定できます。
📋 具体例
tracert 8.8.8.8
出力例：
1 <1 ms 192.168.1.1 → 社内ルーター
2 5 ms 10.0.0.1 → ISPのルーター
3 10 ms 172.16.0.1 → ISPのバックボーン
4 * * * 要求がタイムアウト → ここで問題発生
※ホップ4以降が「*」の場合、ホップ3〜4の間で障害が発生している可能性
nslookup / dig
DNS名前解決の動作を確認するコマンドです。
📋 具体例
nslookup www.google.com
出力例：
サーバー: dns.company.local
Address: 192.168.1.10
権限のない回答:
名前: www.google.com
Address: 142.250.196.100
特定のDNSサーバーを指定して確認：
nslookup www.google.com 8.8.8.8
社内DNSで失敗し、外部DNS（8.8.8.8）で成功する場合 → 社内DNSサーバーの問題
netstat / ss
現在のネットワーク接続とポートの使用状況を確認するコマンドです。
📋 具体例
netstat -an | find "LISTENING"
→ 待ち受け中のポートを一覧表示
netstat -an | find ":443"
→ 443番ポートの接続状況を確認
netstat -b
→ 各接続に関連するプロセス名を表示（管理者権限必要）
Wiresharkによるパケットキャプチャ
Wiresharkは、ネットワーク上を流れるパケットをキャプチャ・分析する無料ツールです。他のコマンドでは原因がわからない複雑な問題の調査に使用します。
- 通信の中身を可視化：どのプロトコルで何を送受信しているか確認
- フィルタリング：特定のIPアドレスやプロトコルの通信のみ表示
- 遅延分析：パケット間の時間差を測定して遅延の原因を特定
📋 具体例
よく使うWiresharkフィルター：
ip.addr == 192.168.1.100 → 特定IPの通信のみ表示
tcp.port == 443 → HTTPS通信のみ表示
dns → DNS問い合わせのみ表示
tcp.flags.syn == 1 → TCP接続開始パケットのみ
http.request → HTTPリクエストのみ表示
tcp.analysis.retransmission → TCP再送パケット（ネットワーク品質問題の指標）
⚠️ 注意
Wiresharkでのパケットキャプチャは、通信の内容を傍受することになります。必ず自身の管理するネットワーク内で、業務上の必要がある場合のみ使用してください。また、キャプチャデータには個人情報が含まれる可能性があるため、不要になったらすぐに削除しましょう。
ケーブルテスターの活用
LANケーブルの物理的な障害は、意外と多い障害原因です。
- ケーブルテスター（Fluke MicroScanner等）：ケーブルの導通確認、ワイヤーマップ確認
- トーンジェネレーター：壁内のケーブル経路を特定
- 目視確認：コネクタの破損、ケーブルの折れ曲がり、ツメの折れ
ひとり情シスの視点：簡易ケーブルテスター（3,000〜5,000円程度）は必ず1台持っておきましょう。「つながらない」問題の意外な割合がケーブル不良です。特にオフィス移転後や配線工事後は要注意です。
問題切り分けフローチャート
「インターネットにつながらない」と報告を受けた場合の標準的な切り分けフローを紹介します。
- 影響範囲の確認：他のユーザーも同じ症状か？ → Yes: 共有機器を調査 / No: 端末個別の問題
- 物理接続の確認：LANケーブルは正しく刺さっているか？Wi-Fiは接続されているか？
- IPアドレスの確認：ipconfigで正常なIPが取得できているか？ → 169.254.x.xならDHCP障害
- ゲートウェイへのPing：デフォルトゲートウェイにPingが通るか？ → 通らなければL2/L1の問題
- 外部IPへのPing：8.8.8.8にPingが通るか？ → 通らなければルーターorISPの問題
- 名前解決の確認：nslookupでDNSが正常に動作しているか？ → ダメならDNSの設定を確認
- 特定サイトの確認：すべてのサイトか特定サイトのみか？ → 特定サイトならフィルタリングやプロキシを確認
ポイント：トラブルシューティングで最も大切なのは「仮説を立ててから検証する」ことです。手当たり次第にコマンドを打つのではなく、「このコマンドの結果がこうなら原因はこれ」と仮説を持って進めましょう。また、対応した内容は必ずメモに残し、ナレッジベースとして蓄積することで、同様の問題に次回から迅速に対応できます。
✅ 完了済み