ネットワーク障害の基本対応 - ping/traceroute/ss/dig【LPIC-1 109.3】

2026-05-30 読了時間: 約14分 難易度: 中級

この記事で達成できること

• ping でホストとの疎通を確認し、-c で回数を制御できる
• traceroute / tracepath で経路上のどこで止まっているか特定できる
• ss で待ち受けポートと接続状態を確認し、netstat との対応を説明できる
• ip addr / ip route で IP 設定とルーティングを確認できる
• dig / host で DNS 名前解決の成否を切り分けられる
• 物理層から DNS・アプリ層まで、層を追った障害切り分けができる

LPIC-1 主題 109.3「基本的なネットワークの問題を解決する」の中核。「つながらない」を、思い込みではなく層ごとの確認で原因に絞り込む技術。

障害切り分けはどの順で進めるか

ネットワーク障害は「下の層から上の層へ」順に確認すると最短で原因に到達する。下が壊れていれば上は必ず失敗するため、下から潰すのが鉄則。

「Web サイトが見られない」なら、まず ping 8.8.8.8 のように IP 直打ちで疎通を見て、次に ping example.com で名前解決込みを見る。IP では通るのにドメインで通らなければ DNS の問題、と一発で切り分けられる。

手順

Step 1: インターフェースと IP を確認する

ip link show
ip addr show

2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
    link/ether 08:00:27:ab:cd:ef brd ff:ff:ff:ff:ff:ff
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
    inet 192.168.1.20/24 brd 192.168.1.255 scope global enp0s3

ip link はネットワークデバイス（リンク層）の状態を表示する。UP と LOWER_UP があればリンクは生きている。ip addr で IP アドレス（inet 192.168.1.20/24）が付いているかを確認する。アドレスが付いていなければ、ここから先は確認しても無駄。

Step 2: ルーティングとゲートウェイを確認する

ip route show

default via 192.168.1.1 dev enp0s3 proto dhcp metric 100
192.168.1.0/24 dev enp0s3 proto kernel scope link src 192.168.1.20

ip route はルーティングテーブルを表示する。default via 192.168.1.1 がデフォルトゲートウェイ。この行が無いとローカルネットワーク外（インターネット）へ出られない。「LAN 内は通るが外に出られない」障害の大半はここが原因。

Step 3: ping で疎通を確認する

ping -c 4 192.168.1.1
ping -c 4 8.8.8.8

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=115 time=12.3 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=115 time=11.8 ms
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms

ping は ICMP ECHO パケットで疎通を確認する。-c 4 は「4 回送信したら終了」の意味（man ping: "Stop after sending count ECHO_REQUEST packets"）。これを付けないと Ctrl+C まで送り続ける。送信間隔は -i で秒指定でき、デフォルトは 1 秒。まずゲートウェイ、次に外部 IP の順で確認する。

Step 4: traceroute で経路を追う

traceroute 8.8.8.8

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1)  0.8 ms  0.7 ms  0.7 ms
 2  10.0.0.1 (10.0.0.1)  8.2 ms  8.1 ms  8.0 ms
 3  * * *
 4  8.8.8.8 (8.8.8.8)  12.1 ms  12.0 ms  11.9 ms

traceroute は宛先までの経路上の各ホップ（ルーター）を順に表示する（man: "tracks the route packets taken ... on their way to a given host"）。各ホップで止まっていれば、その手前まではつながっていると分かる。* * * はそのホップが「タイムアウト内に応答しなかった」表示で、必ずしも障害ではなく ICMP を返さないルーターでも出る。

非特権ユーザーで実行したい、または経路の MTU も知りたい場合は tracepath を使う。man tracepath によれば「tracepath は traceroute と違い特権プログラムではない」。

tracepath example.com

Step 5: dig / host で DNS を確認する

dig example.com
dig +short example.com

;; ANSWER SECTION:
example.com.		3600	IN	A	93.184.216.34

93.184.216.34

dig は DNS 問い合わせの詳細を表示する。基本構文は dig @server name type（BIND 9 公式）。ANSWER SECTION に解決結果（リソースレコード）が出れば名前解決は成功。+short は簡潔表示で、結果の値だけを返す。

dig MX example.com
dig -x 93.184.216.34
host example.com

レコード種別を指定するには type を付ける（dig MX example.com）。-x は IP からホスト名への逆引き（PTR）。host はより簡潔な DNS ルックアップユーティリティで、host name だけで A・AAAA・MX をまとめて確認できる。

Step 6: ss で待ち受けポートと接続を確認する

ss -tulnp

Netid State   Local Address:Port   Peer Address:Port  Process
tcp   LISTEN  0.0.0.0:22           0.0.0.0:*          users:(("sshd",pid=812,fd=3))
tcp   LISTEN  0.0.0.0:80           0.0.0.0:*          users:(("nginx",pid=940,fd=6))
udp   UNCONN  0.0.0.0:68           0.0.0.0:*

ss はソケット統計を表示する。よく使う組み合わせ -tulnp の意味は man ss に従い以下のとおり。

「サービスを起動したのに接続できない」場合、ss -tlnp で対象ポートが LISTEN になっているか、どのプロセスが握っているかを確認する。

なぜ netstat ではなく ss を使うのか

netstat の man ページ NOTES 節には次のように明記されている。「This program is mostly obsolete.（このプログラムはほぼ廃止予定）Replacement for netstat is ss.」。つまり公式に ss が後継と位置づけられている。同様に netstat -r の代替は ip route、netstat -i の代替は ip -s link と man に書かれている。

実務上も ss は netstat より高速で、/proc/net を直接読まずカーネルから直接ソケット情報を取得する。オプション体系は互換性が高く、netstat -tulnp はほぼそのまま ss -tulnp に置き換えられる。古い手順書には netstat が残っているが、新規環境では ss を第一選択にするのが定石。LPIC-1 でも両者の対応関係（ss が後継、ip route が route/netstat -r の後継）は頻出ポイント。

よくあるミス

• netstat 前提で手を止める: 最小構成のコンテナや新しいディストリには netstat（net-tools）が入っていないことがある。ss を覚えておけば追加インストール不要で動く。
• ping が通らない＝不通と決めつける: ICMP をブロックした環境では正常でも ping は失敗する。TCP ポートへの接続可否（ss / アプリ層の確認）と合わせて判断する。
• DNS 障害を疎通障害と取り違える: ping ドメイン名 の失敗だけで「ネットワークが切れた」と判断しない。IP 直打ち（ping 8.8.8.8）が通れば物理・IP・経路は正常で、原因は DNS。
• デフォルトゲートウェイ未設定を見落とす: LAN 内は通るのに外に出られないとき、ip route に default via ... が無いケースが多い。アドレスだけ見て満足しない。
• ss のポート番号をホスト名解決で読み違える: -n を付けないと :22 が :ssh と表示され、ポート番号の特定に手間取る。確認時は -n を付ける。

トラブルシューティング

症状: ping example.com が Name or service not known で失敗する

原因: ネットワークは正常だが DNS 名前解決が失敗している

確認:

ping -c 2 8.8.8.8
dig +short example.com

対処: IP 直打ちの ping が通れば物理・IP・経路は正常。dig で解決できなければ /etc/resolv.conf の nameserver 行を確認し、到達可能な DNS サーバーを設定する。

症状: LAN 内は通るがインターネットに出られない

原因: デフォルトゲートウェイが未設定、または誤っている

確認:

ip route show
ping -c 2 192.168.1.1

対処: ip route に default via <ゲートウェイIP> の行があるか確認する。無ければ ip route add default via <ゲートウェイIP> で追加（恒久化はディストリの設定ファイルで行う）。

症状: サービスを起動したのにクライアントから接続できない

原因: プロセスが意図したアドレス/ポートで待ち受けていない、またはファイアウォールでブロックされている

確認:

ss -tlnp

対処: 対象ポートが LISTEN か、待ち受けアドレスが 127.0.0.1（ローカルのみ）でなく 0.0.0.0 等になっているかを確認する。LISTEN していればアプリは正常で、原因はファイアウォール側の可能性が高い。

症状: traceroute の途中が * * * のまま進まない

原因: 途中のルーターが ICMP を返さない、または実際にそこで経路が途切れている

確認:

traceroute 8.8.8.8
tracepath 8.8.8.8

対処: * * * でも宛先まで到達し最終行に応答があれば経路は生きている（中継ルーターが ICMP を返さないだけ）。最終ホップまで届かない場合は、最後に応答したホップの先で障害が起きていると絞り込める。

作業完了チェックリスト

• [ ] ip addr / ip link でインターフェースと IP を確認した
• [ ] ip route でデフォルトゲートウェイを確認した
• [ ] ping -c でゲートウェイと外部 IP の疎通を確認した
• [ ] traceroute / tracepath で経路上の停止点を確認した
• [ ] dig / host で DNS 名前解決を確認した
• [ ] ss -tulnp で待ち受けポートとプロセスを確認した

まとめ

ネットワーク障害対応の本質は「層を順に潰す」こと。下から確認すれば、勘に頼らず原因にたどり着ける。netstat は ss に、ifconfig/route は ip に置き換わった点も合わせて押さえれば、109.3 の出題範囲を一通りカバーできる。