【入門編】 tracerouteのTTL（Time To Live）ヘッダーフィールドの減算メカニズム – トラブルシューティング＆ネットワーク運用監視実践ガイド

なぜパケットは「迷子」にならずに目的地へ辿り着くのか？ tracerouteの魔法を解き明かす

ネットワークの現場に飛び込んで最初に出会う「魔法」のようなコマンド、それが traceroute（Windowsなら tracert）です。

「通信が遅い」「繋がらない」そんな時、真っ先に叩くこのコマンド。目の前にずらりと並ぶルータのIPアドレスを見て、「へぇ、ここを通ってきたんだな」と満足していませんか？でも、「一体どうやって、途中のルータたちが自分の存在を名乗り出ているのか？」を突き詰めると、ネットワークの深淵に触れることができます。

今日は、百戦錬磨のシニアエンジニアである私が、この「ネットワークの迷宮」を解き明かす鍵である TTL（Time To Live） という仕組みについて、泥臭い現場の感覚を交えて解説します。

—

郵便配達で例える「TTL」の正体

TTLは、日本語で「生存時間」と訳されます。でも、これだけだと少しイメージしにくいですよね。

こう想像してみてください。あなたが手紙を送る時、封筒に「この手紙は、最大10人までしか回してはいけません。もし10人に届いても目的地に着かなければ、その場で破棄して差出人に『届きませんでした』と報告してください」という「回覧板のルール」を書くとします。

最初の配達員（ルータ1）： 手紙を受け取ると、数字を「10」から「9」に減らして次の人へ。
次の配達員（ルータ2）： 数字を「9」から「8」に減らして次の人へ。
……これを繰り返し、数字が「0」になった配達員は？：

「おっと、ルールで『0になったら破棄して報告しろ』と言われているな」と判断し、差出人であるあなたへ「残念ながら、私のところで力尽きました」という通知を送り返します。

これが、ネットワークの世界で起きていることの正体です。パケットは、自分がどこまで旅をしていいのかという「寿命（TTL）」を背負って旅に出るのです。

—

パケットが「死ぬ」ことでルートが見える

traceroute は、この「TTLが0になってパケットが破棄される」という悲しい挙動を、あえて悪用（！）することで地図を作っています。

1. わざと寿命の短いパケットを投げる：
「まずはTTL=1で出発！」→ 最初のルータで寿命が尽きて「Time Exceeded（時間切れ）」が返ってくる。これで1つ目のルータが判明。
2. 次は少し寿命を延ばす：
「次はTTL=2！」→ 最初のルータは通過し、2つ目のルータで寿命が尽きて「Time Exceeded」が返ってくる。これで2つ目のルータが判明。
3. これを目的地まで繰り返す：
こうして、パケットを次々と「意図的に死なせる」ことで、ルータたちは「私、ここにいました！」と名乗りを上げざるを得なくなるのです。

—

現場で使う traceroute の実戦テクニック

教科書では traceroute google.com と打てば終わりですが、現場では少し工夫が必要です。例えば、ファイアウォールが ICMP（pingの仲間）を遮断している場合、通常の traceroute は星印（* * *）を表示して沈黙してしまいます。

そんな時は、TCPポートを指定して無理やり道を通すテクニックが有効です。

Linux/macOSでの実行例

# TCPの80番ポート（HTTP）を狙ってトレースをかける
# ICMPが通らなくても、TCPならファイアウォールを抜けてくれることが多い
sudo traceroute -T -p 80 google.com

Windowsでの実行例（PowerShell）

Windowsでは tracert が一般的ですが、応答がない場合は Test-NetConnection を使うのが現代のエンジニアの嗜みです。

# 特定のポートを指定して経路を確認する（PowerShell 5.0以上）
Test-NetConnection -ComputerName google.com -TraceRoute -Port 80

—

最後に：エンジニアとして持つべき「視点」

トラブルシューティングの現場では、traceroute の結果だけで「ここが故障だ！」と決めつけるのは危険です。ルータの設定によっては、わざと ICMP の応答を低優先度にしていたり、セキュリティのために経路上でパケットを捨てていることもあります。

「パケットは常に正直だ」と信じるのではなく、「パケットはネットワークの制約に従って、時々嘘をついたり、黙り込んだりする」という疑いを持つこと。それが、数々の障害を乗り越えてきた私の実感です。

TTLの減算メカニズムという小さな仕組みが、世界中の通信を支えている。そう思うと、黒い画面に流れるコマンドの羅列も、なんだか少し愛おしく見えてきませんか？

次回のトラブルシュートでは、ぜひ「今、このパケットは寿命を削りながらどこを走っているんだろう？」と、旅するパケットの気持ちになって画面を眺めてみてください。きっと、今まで見えなかったトラブルの兆候が、少しだけ見えてくるはずですよ。

それでは、また現場でお会いしましょう！