トラブルシューティングの体系的アプローチ

ストーリー

「『Webサイトが見れない』って報告が来た。さて、何から調べる？」

「えっと...ping してみますか？」

「悪くないけど、体系的にやらないと見落としが出る。OSI参照モデルの下の層から順番に調べるのがセオリーだ」

「下の層から？」

「物理層 → データリンク層 → ネットワーク層... 下から確認していけば、どの層で問題が起きているか特定できる」

OSI参照モデルとトラブルシューティング

下から順に確認する（ボトムアップアプローチ）

層	確認内容	コマンド
L1 物理層	ケーブル接続、NIC状態	`ip link show`
L2 データリンク層	MACアドレス、ARP	`ip neighbor show`
L3 ネットワーク層	IP設定、ルーティング、疎通	`ip addr`, `ping`, `traceroute`
L4 トランスポート層	ポート、TCP接続	`ss`, `nc`, `telnet`
L5-L7 アプリケーション層	DNS、HTTP、SSL	`dig`, `curl`, `openssl`

なぜ下から？

上位層は下位層に依存しています。IPが通らないのにHTTPを調べても意味がありません。

L7 アプリケーション ← ここでの障害が一番多いが
L4 トランスポート  ← ここが壊れていると L7 は動かない
L3 ネットワーク    ← ここが壊れていると L4 は動かない
L2 データリンク    ← ここが壊れていると L3 は動かない
L1 物理           ← ここが壊れていると全部動かない

診断ワークフロー

Step 1: 問題の切り分け（自分だけ？全員？）

bash

# 自分の環境から確認
ping 8.8.8.8          # インターネット接続
ping ゲートウェイIP    # ローカルネットワーク

# 他の人も同じ問題か確認
# → 自分だけなら自分の環境の問題
# → 全員なら共有インフラの問題

Step 2: L3 ネットワーク層の確認

bash

# IPアドレスの確認
ip addr show

# デフォルトゲートウェイの確認
ip route show

# 疎通確認
ping -c 3 ターゲットIP

# 経路確認
traceroute ターゲットIP

Step 3: L4 トランスポート層の確認

bash

# ポートの到達確認
nc -zv ターゲットIP ポート番号

# TCP接続状態の確認
ss -tn | grep ターゲットIP

Step 4: L5-L7 アプリケーション層の確認

bash

# DNS解決
dig ドメイン名

# HTTP接続
curl -v https://ターゲットURL

# SSL証明書
openssl s_client -connect ホスト:443

主要な診断コマンド一覧

ping - 疎通確認

bash

# 基本的な疎通確認
ping -c 3 192.168.1.100

# タイムアウトを設定
ping -c 3 -W 2 192.168.1.100

結果の読み方:

PING 192.168.1.100: 64 bytes from 192.168.1.100: icmp_seq=1 ttl=64 time=0.5 ms
→ time が応答時間。100ms 以上は遅い。

--- ping statistics ---
3 packets transmitted, 3 received, 0% packet loss
→ packet loss が 0% なら正常

traceroute - 経路確認

bash

# 目的地までの経路を表示
traceroute 192.168.1.100

結果の読み方:

 1  192.168.1.1    0.5 ms   ← ゲートウェイ
 2  10.0.0.1       5.2 ms   ← ISPのルーター
 3  * * *                    ← ★ ここで止まっている = この先に問題
 4  ...

curl - HTTP確認

bash

# 詳細な接続情報を表示
curl -v https://example.com

# レスポンスヘッダのみ
curl -I https://example.com

# タイムアウトを設定
curl --connect-timeout 5 https://example.com

よくある障害パターン

パターン1: DNS解決の失敗

症状: ドメイン名でアクセスできないが、IPアドレスでは可能
確認: dig ドメイン名 / nslookup ドメイン名
原因: DNSサーバーの問題、DNS設定ミス

パターン2: ファイアウォールによるブロック

症状: ping は通るがポートに接続できない
確認: nc -zv ホスト ポート
原因: ファイアウォールで特定ポートがブロック

パターン3: サービスが停止

症状: ポートが LISTEN していない
確認: ss -tln | grep ポート
原因: サービスがクラッシュ or 未起動

パターン4: SSL証明書の期限切れ

症状: HTTPSでアクセスするとエラー
確認: openssl s_client -connect ホスト:443
原因: 証明書の期限切れ、設定ミス

まとめ

ポイント	内容
ボトムアップ	OSI参照モデルの下位層から順番に確認
切り分け	自分だけの問題か、全体の問題かを最初に確認
L3確認	ping, traceroute でネットワーク疎通を確認
L4確認	nc, ss でポートの到達性と接続状態を確認
L7確認	dig, curl, openssl でアプリケーション層を確認

チェックリスト

ボトムアップアプローチの考え方を理解した
ping, traceroute で疎通確認できる
nc でポートの到達確認ができる
4つの障害パターンを把握した

次のステップへ

体系的なトラブルシューティングの手順を学びました。次のセクションでは、よくあるDNS障害について深く掘り下げます。

推定読了時間: 30分