Engineering
Glossvation Engineering
クラウド

traceroute の仕組みと実務での読み方 — どこで詰まっているか見抜く

ICMP/UDP/TCP の違い、TTL と ICMP Time Exceeded の仕組み、* * * の意味、mtr との使い分け、クラウド・コンテナ環境でのトラブル判断まで。

Glossvation ·

traceroute がやっていること

ある IP アドレスまでの通信経路 (ホップごとのルーター) を特定するツール。アプリケーションが遅い / 繋がらない原因を切り分けるときの第一手段です。

仕組み:

  1. 宛先宛にパケットを送る。ただし TTL (Time To Live) を 1 からインクリメント
  2. ルーターは TTL=1 のパケットを受け取ると自分で破棄し、送信元に ICMP Time Exceeded (type 11) を返す
  3. それが traceroute 送信側から見える → そのルーター IP が「1 ホップ目」
  4. TTL=2, 3, … と増やしていくことで、2 ホップ目、3 ホップ目… と経路を特定

宛先に到達したら正常終了 (宛先ホストが Destination Unreachable など応答を返す / UDP ならポート閉のメッセージ)。

実行例と読み方

$ traceroute -n 8.8.8.8

 1  192.168.1.1       0.521 ms  0.483 ms  0.457 ms       # 自宅ルーター
 2  10.0.0.1          4.12 ms  4.08 ms  4.03 ms          # ISP エッジ
 3  xxx.xxx.xxx.xxx   8.45 ms  8.42 ms  8.39 ms          # ISP 中継
 4  * * *                                                # 応答なし
 5  72.14.202.x       12.1 ms  12.0 ms  12.0 ms          # Google
 6  216.239.47.x      11.9 ms  11.8 ms  11.9 ms
 7  8.8.8.8           11.7 ms  11.7 ms  11.7 ms          # 宛先到達

各列の意味:

  • ホップ番号
  • 応答したルーターの IP
  • 3 つの RTT (各ホップに 3 回送っている、デフォルト)

* * * (応答なし) の 4 つの理由

  1. そのホップのルーターが ICMP Time Exceeded を返さない設定 (セキュリティポリシー)
  2. ルーターが応答に時間制限 (rate limit) をかけている
  3. ファイアウォールが ICMP を落としている
  4. 本当にそのホップが落ちている

→ * * * が 1 ホップだけなら 1〜3 の可能性大、無視して OK。 → 以降全部 * * * なら経路が本当に切れている、または宛先側で ICMP を全て遮断。

プロトコル選択: UDP / ICMP / TCP

traceroute 8.8.8.8          # Linux 既定: UDP (ポート 33434+)
traceroute -I 8.8.8.8       # ICMP Echo
traceroute -T -p 443 8.8.8.8 # TCP SYN (Windows の tracert は既定 ICMP)

使い分け:

  • UDP 既定: カジュアルな確認。ただし途中のファイアウォールで落とされがち
  • ICMP (-I): ping と同じ ICMP Echo を使う。ICMP が許可される経路で確実
  • TCP (-T -p 443): 本番環境のトラブル調査で最も実用的。実際のアプリケーションが使う TCP ポートで到達性を確認するので、中継 FW の ICMP 遮断を回避

例: AWS の ALB が 80/443 だけ許可している場合、UDP/ICMP の traceroute は届かないが traceroute -T -p 443 なら到達経路が見える。

mtr — traceroute と ping の良いとこどり

mtr 8.8.8.8

traceroute を連続的に実行して、各ホップのパケロス率と RTT 統計をリアルタイム表示。本番トラブル調査の定番ツール。

ホップLoss%SntLastAvgBestWrstStDev
1. 192.168.1.10%500.50.60.41.20.1
2. 10.0.0.120%505.26.84.015.02.1
3. xxx0%508.48.58.19.00.2

「どのホップでパケロスが発生しているか」が一目瞭然。

クラウド / コンテナ環境での注意

AWS / GCP

  • VPC 内部は ICMP を切っていることが多い → traceroute -T -p 443 が必須
  • 一部のマネージドサービス (ALB, Cloud SQL) は traceroute で中継ルータが見えない

Kubernetes

  • Pod 間通信で traceroute を使うには、Pod に iputils や traceroute パッケージが入っている必要
  • ClusterIP は VIP なので物理 traceroute 経路は見えない
  • NetworkPolicy で ICMP 遮断されていることも

CDN / プロキシ

  • 中継 CDN (Cloudflare, Fastly) は traceroute 中継 IP を抽象化することがある
  • 到達先の実サーバ IP とは異なる IP が返ることが普通

トラブル切り分けの型

サービスが遅い / 繋がらない
    ↓
① ping で到達性確認
    ↓
② traceroute (TCP) で経路確認 — どのホップで止まる？
    ↓
③ mtr で継続観察 — 特定ホップでパケロス？
    ↓
④ 特定ホップ付近の担当 (ISP / クラウドプロバイダ) にエスカレーション

落とし穴

1. 応答順序と経路順序は違う

traceroute が示すのは「自分から各ホップへの応答経路」。実際のパケット経路とは微妙に違うことがある (非対称ルーティング)。

2. RTT は最終ホップほど累積するわけではない

各ホップで独立に RTT を測るので、ホップ 5 の RTT > ホップ 3 の RTT とは限らない。ホップごとの絶対値で見る。

3. DNS 逆引きで表示が遅い

-n で IP 表示にすれば逆引きしないので速い。

4. IPv6 では別コマンド

traceroute6 or traceroute -6。使えないときは ping6 + 手動 TTL 操作。

まとめ

  • traceroute = TTL を 1 ずつ増やしてホップごとに ICMP Time Exceeded を引き出す仕組み
  • 本番環境のトラブル調査は -T -p 443 または mtr
  • * * * は一時的な沈黙 (無視可) と、経路断絶 (問題) を見分ける
  • クラウドや K8s では ICMP が落とされていることが多い、TCP 版を使う
#Linux #Network #トラブルシュート

関連記事