夜間帯のデータセンター、冷たいサーバの唸り声、そして不穏に点滅するオレンジ色の警告灯。インフラエンジニアなら誰もが一度は冷や汗をかいた経験があるだろう。「APIのレスポンスが突如としてタイムアウトするようになった」「特定リージョンからの疎通だけが数ミリ秒遅延している気がする」。
そんな修羅場で、君が最初に叩くコマンドは何だろうか？ ping か、それともブラウザのリロードボタンか。しかし、パケットがどのルータの迷宮で迷子になっているかを特定したいとき、真に頼りになるのは traceroute だ。
今回は、教科書の仕様書をただなぞるような退屈な話はしない。パケットがIPヘッダーの TTL (Time To Live) という小さなカウンターを武器に、どのようにルータの壁を突破し、あるいは跳ね返されて帰ってくるのか。その泥臭くも美しいメカニズムを、現場の知見を交えて徹底的に解説しよう。
—
1. なぜtracerouteは経路を特定できるのか？（TTLの魔術）
ネットワークの世界では、パケットが無制限にループし続けてネットワーク資源を食いつぶす「ルーティングループ」が最悪の悪夢の一つだ。これを防ぐために、IPパケットのヘッダーには TTL（IPv4の場合）または Hop Limit（IPv6の場合）というフィールドが用意されている。
TTL は、パケットが通過できるルータ（ホップ）の最大数を表す8ビットの整数だ。パータンが1台のルータを通過するたびに、ルータはこの値を 1 ずつデクリメント（減算）する。そして、もし TTL が 0 に達したとき、そのルータは冷酷にもそのパケットを破棄し、送信元に対して ICMP Time Exceeded (Type 11, Code 0) という「お前のパケット、寿命が尽きたぞ」という旨のエラー通知を送り返す。
traceroute は、この仕様をハッキング的に逆手にとって経路をあぶり出す。
1. 送信元は、まず TTL = 1 のパケットを宛先に向けて発射する。
2. すぐ隣の最初のルータ（デフォルトゲートウェイ）がパケットを受信し、TTL を 1 から 0 に減算する。
3. ルータは「寿命切れ」と判断し、パケットを破棄すると同時に、送信元IPアドレス宛に ICMP Time Exceeded を送り返す。
4. これにより、送信元は「最初のルータのIPアドレス」を知る。
5. 次に TTL = 2 に増やしてパケットを送信する。今度は1台目を無事に通過し、2台目のルータで TTL が 0 になり、同様にエラーが返ってくる。
このプロセスを、宛先に到達するまで TTL を 1, 2, 3… とインクリメントしながら繰り返す。これが traceroute の正体だ。非常にシンプルだが、ネットワークの構造を暴くには十分すぎるほど巧妙な仕組みである。
—
2. 通信フローの裏側（シーケンス）
実際のパケットのやり取りを、頭の中でパケットキャプチャ（Wireshark）を思い浮かべながら追ってみよう。多くのOS（LinuxやmacOS）のデフォルト実装では、traceroute はUDPパケットやICMPエコーリクエスト（あるいはTCP SYN）を使用するが、ここでは最も伝統的なUDPベースの挙動を見てみる。
[Client (自分)] [Router A (Hops 1)] [Destination (Server)]
| | |
|--- (1) IP (TTL=1) -> UDP ------------>| |
| (宛先は存在しない高番号ポート) | |
| | (TTLが0になった!) |
|<-- (2) ICMP Time Exceeded -----------| |
| (Src: Router AのIP) | |
| | |
|--- (3) IP (TTL=2) -> UDP ----------------------------------------->|
| | (今度はRouter Aを通過) |
| | | (宛先ポート閉じている)
|<-- (4) ICMP Port Unreachable --------------------------------------|
| (Destination Unreachable: Port) | |ここで重要なのは、最後の宛先（Destination）に到達したときの挙動だ。
traceroute は、宛先サーバに対して通常は「誰も待ち受けていないような適当な高番号ポート（例: 33434など）」へ向けてパケットを投げる。そのため、宛先サーバにパケットが到達した際、OSは「そんなポート開いてないよ」ということで、今度は ICMP Destination Unreachable (Port Unreachable, Type 3, Code 3) を返してくる。
送信元は、この Port Unreachable を受信した瞬間に、「おお、ついに宛先のホスト自身から返事が来たぞ！ ここが終点だ」と理解し、プローブ（探索）を終了するのだ。
—
3. 実務で役立つコマンドの実装とデバッグTips
実務の現場では、標準の traceroute がファイアウォール（FW）やセキュリティグループによって阻まれることが日常茶飯事だ。「セキュリティ要件でICMPやUDPがブロックされていて、星印 (* * *) ばかり並ぶ」という絶望的な状況に直面した読者も多いだろう。
そんなときは、プロトコルやポートを切り替えるのがシニアの常套手段だ。
Linuxでの実戦的traceroute (iputils / traceroute パッケージ)
現代のLinux環境では、デフォルトでインストールされている traceroute コマンドが非常に高機能だ。
# 【Tips 1】TCP SYNパケットを使ったtraceroute（WebサーバーやAPIへの経路調査の定番）
# 多くのファイアウォールはTCP 80/443へのSYNパケットを通すため、UDPやICMPが塞がれていても経路が見えることが多い
sudo traceroute -T -p 443 api.example.com
# 【Tips 2】ICMPエコー（pingの仕組み）を使ったtraceroute
# ルータによってはUDPよりもICMPの処理を優先/許可している場合がある
sudo traceroute -I api.example.com
# 【Tips 3】DNS逆引きを無効化して高速化 (-n) & タイムアウトを短縮 (-w)
# 障害対応中はDNSの応答待ちでイライラしたくないため、必ずIP表示(-n)にする
traceroute -n -w 1 8.8.8.8—
4. アプリケーション開発者・インフラエンジニアへの警鐘
Web APIの設計やクラウドインフラ（AWS VPCやGCP VPC）の構築において、この TTL や traceroute の挙動を知っておくことは、単なるネットワークの知識にとどまらない。
1. ロードバランサー（ALB/NLB）やAnycast環境での罠
現代のクラウドインフラでは、パケットの送信元ポートや TTL、あるいはハッシュアルゴリズムによって、通過するバックエンドのルータやロードバランサーのインスタンスが変わることがある。
そのため、traceroute の結果表示で途中から経路がコロコロ変わったり、星印 (*) が混ざったりするのは「障害ではなく、ロードバランシングの仕様」であることが非常に多い。パニックを起こさず、分散の仕組みを疑うことだ。
2. セキュリティ機器によるICMPレートリミット
セキュリティ機器（IDS/IPSやステートフルFW）は、DDoS攻撃対策として ICMP Time Exceeded の送信レートを厳しく制限（Rate Limit）している。
そのため、traceroute を実行した際に、途中のルータが本来生きているにもかかわらずタイムアウト（* * *）扱いになることがある。「ルータが死んでいる」と勘違いして回線キャリアに問い合わせる前に、別のプロトコル（TCPなど）で再確認する冷静さを持とう。
—
5. まとめ
traceroute は、単に「パケットの通る道を見るコマンド」ではない。
IPパケットが持つ TTL という極めてシンプルなカウンターが、ルータという無機質なハードウェアと対話しながら、ネットワークのトポロジーを私たちの目の前に描き出す、いわばネットワークエンジニアの羅針盤だ。
現場で予期せぬレイテンシーや疎通不良に直面したとき、パケットがどのホップで消え去っているのか、あるいはどのファイアウォールに阻まれているのかを頭の中でイメージできるようになれば、君はもう一人前のネットワーク・トラブルシューターだ。
さあ、次のインシデントに備えて、手元の端末で traceroute のオプションを叩き、パケットの息吹を感じてみるとしよう。
コメント