ネットワーク障害診断の手法論

階層型特定——L1からL7まで、1層ずつ除外していく。MTUブラックホール（ICMPフィルタによりTCPハンドシェイクは完了するがデータ転送が不可）、DNS解決異常、TCPハンドシェイクタイムアウト——各古典的な障害には特定の診断パスが存在する。mtrはping/tracerouteよりも一時的なパケット損失の特定に適している。

概要

ネットワーク障害診断の中核となる手法は、階層型特定です。L1（物理層）からL7（アプリケーション層）まで、1層ずつ除外していきます。最も一般的な障害パターンには、MTUブラックホール（ICMPがフィルタリングされ、TCPがデッドロック状態に陥る）、DNS解決異常、TCP接続確立後のデータ転送停止（バッファ/ウィンドウの問題）があります。mtrは、エンドツーエンドの各ホップにおけるパケット損失率とレイテンジジッターを表示するため、長期的なパケット損失の監視にはpingやtracerouteよりも適しています。

階層別診断

L1 (物理): ip link, ethtool eth0 | grep Link
L2 (データリンク): ip neigh, tcpdump arp
L3 (ネットワーク): ping -M do, traceroute, ip route
L4 (トランスポート): ss -tlnp, tcpdump 'tcp[tcpflags] & tcp-syn != 0'
L5-6 (TLS): openssl s_client -connect host:443, tshark 'tls.alert_message.level==2'
L7 (アプリケーション): curl -v, dig, ss -tianp (Recv-Q / Send-Q)

古典的な障害パターン

「ネットワークは接続できるがアクセスできない」

ping は通る → L3 OK, L4 に問題がある可能性あり

確認項目:
  ss -tlnp | grep <port>            サービスはリスニングしているか?
  iptables -L -n -v                  ファイアウォールでブロックされているか?
  tcpdump 'tcp[tcpflags] & tcp-rst != 0'  誰が RST を送信しているか?
  cat /proc/sys/net/netfilter/nf_conntrack_count  conntrack テーブルは満杯か?

MTU ブラックホール

症状: ping は通るが、TCP SYN+ACK は完了し、データ転送が停止する。

根本原因: パス上の MTU が送信パケットサイズ + DF=1 より小さく、かつ ICMP Frag Needed がフィルタリングされている
  → パケットがパス上で破棄され、送信元はそれを認識できない

検出: ping -M do -s 1472 <target> → 失敗 (ただし小さい ping は成功) → MTU ブラックホール
緩和策: iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

DNS 問題

dig <domain> +short                   何が返されたか?
dig +trace <domain>                   再帰パスのどのステップで切断されたか?
tcpdump -nn 'port 53'                 リクエストは送信されたか? 応答はあるか?

一時的なタイムアウト

mtr -r -c 100 <target>               どのホップからパケット損失とジッターが始まったか?
ethtool -S eth0 | grep -E 'err|drop'  NIC でのパケット損失か?
cat /proc/net/dev                      ソフトウェアレベルでのパケット損失か?
tc -s qdisc show dev eth0              qdisc でのパケット損失 (bufferbloat か?)

参考

• mtr: bitwizard.nl/mtr
• iptables: netfilter.org/documentation

Keywords: network troubleshooting, L1-L7, MTU black hole, DNS, TCP RST, conntrack, bufferbloat