【入門編】 tracerouteのTTLエージングを利用したホップバイホップ経路特定 – トラブルシューティング＆ネットワーク運用監視実践ガイド

こんにちは！データセンターの片隅で、日々幾万ものパケットの息吹を感じながらネットワークの監視と障害対応に明け暮れているシニアエンジニアです。

ネットワークの世界に飛び込んだばかりの頃、「自分が打ったコマンドの裏側で、パケットはいったいどうやって目的地までたどり着いているんだろう？」と、暗黒のトンネルを覗くようなワクワクと不安を抱いたことはありませんか？

今回は、そんなネットワークの旅の軌跡を丸裸にしてくれる魔法のコマンド、tracerouteの仕組みについて、現場の生きた知見を交えながら優しく紐解いていきたいと思います。難しい専門用語の嵐に挫折しそうになっている方も大丈夫です。一歩ずつ、身近な例えから紐解いていきましょう！

—

宛先まで迷子になったパケットを探せ！tracerouteってどんなコマンド？

ネットワークの調子が悪いとき、「あそこのサーバーまで繋がらない！」となったとき、皆さんはまず何をしますか？そう、まずは生存確認のpingを打つことが多いですよね。

でも、「pingは通るけれど、なんだか通信がすごく遅い」「意図したルートを通らずに変な経由地を通っている気がする」そんなときに頼りになるのが、今回主役として取り上げるtraceroute（Windowsの場合はtracert）というコマンドです。

このコマンドを使うと、自分のパソコンから目的地のサーバーにたどり着くまでに、「パケットがどのルータという名の経由地を通ってきたのか」を、1つ残らずホップ（中継地点）単位で暴くことができます。

では、この裏側でパケットたちは一体どんな冒険をしているのでしょうか？その秘密は、パケットにこっそり仕込まれた「寿命」にあるんです。

—

郵便配達で例える「TTL（Time to Live）」の仕組み

パケットの旅を分かりやすくするために、現実世界の「郵便配達」に例えてみましょう。

あなたが東京から沖縄の友人へ、どうしても伝えたい手紙を送るとします。この手紙には、特別なルールが書き込まれた封筒を使います。そのルールとは、「この手紙は、中継する郵便局を通るたびに『スタンプ』を1つ押され、スタンプの数が『10個』に達した時点で、それ以上運んではいけない（即座に破棄される）」というものです。

もし、配達途中の郵便局でスタンプの数が限界に達してしまったら、その郵便局の配達員はどうするでしょうか？彼は困ってしまい、あなたの手紙に「あぁ、ここで寿命を迎えてしまいました…」と悲しいお便り（エラーメッセージ）を添えて、東京のあなたの元へ送り返してくれます。

この「パケットに持たせた寿命（中継できる限界回数）」のことを、ネットワークの世界では TTL（Time to Live） と呼びます。

tracerouteはこの仕組みを巧妙に利用しています。

1. 寿命「1」のパケットを放つ: まず、寿命を「1」にしたパケットを送り出します。最初のルータに届いた瞬間、寿命が尽きて「寿命切れです！」とエラーが返ってきます。これで「1つ目のルータ」の住所がわかります。
2. 寿命「2」のパケットを放つ: 次は寿命を「2」にして送り出します。1つ目のルータは通過しますが、2つ目のルータに届いた瞬間に寿命が尽きてエラーが返ってきます。これで「2つ目のルータ」の住所がわかります。
3. 目的地に届くまで繰り返す: これを「3」「4」「5」……と、目的地に届くまで1ずつ増やしながら何度もパケットを送り続けるのです。

泥臭いけれど、非常によくできた仕組みだと思いませんか？

—

実際にコマンドを叩いて、パケットの軌跡を覗いてみよう

百聞は一見にしかず。実際に私たちの手で、パケットを旅立たせてみましょう。

ターミナル（Mac/Linux）やコマンドプロンプト（Windows）を開いて、以下のように入力してみてください。今回は例として、GoogleのパブリックDNSサーバー（8.8.8.8）を宛先にしてみましょう。

# GoogleのパブリックDNSサーバーへの経路をトレースする
traceroute 8.8.8.8

コマンドを実行すると、画面に次々と行が表示されていきます。出力結果の読み方を、実際の現場で見ているかのように解説しますね。

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 64 byte packets
 1  gateway (192.168.1.1)  2.123 ms  1.890 ms  1.750 ms
 2  ntt-east-fiber.net (203.0.113.1)  12.450 ms  11.200 ms  10.980 ms
 3  core-router-A01.net (198.51.100.45)  15.340 ms  14.890 ms  15.120 ms
 ...
 12  dns.google (8.8.8.8)  18.500 ms  18.230 ms  18.110 ms

出力結果の読み方ポイント

左側の数字（1, 2, 3…）: これがまさに、先ほどお話ししたTTLの数（ホップ数）です！上から順に、1つ目のルータ、2つ目のルータ……と進んでいます。
ルータのIPアドレスやホス名: 通過した機器の名前やIPが表示されます。「おっ、いま家のルータを抜けて、プロバイダの設備に入ったな」というのが手に取るように分かりますよね。
ミリ秒（ms）の数値: パケットがそのルータまで往復するのにかかった時間（遅延時間）です。各ホップごとに3回パケットを投げるのが一般的なので、3つのタイムラグが表示されます。ここで急激に数字が跳ね上がっていたら、「あ、あの区間で通信が渋滞しているぞ」とアタリを付けることができます。

—

実務の現場で遭遇する「アスタリスク（*）」の謎

さて、インフラ現場でtracerouteを叩いていると、たまに次のような不気味な出力に出会うことがあります。

4  * * *
 5  * * *
 6  core-router-B02.net (203.0.113.99)  25.100 ms  24.900 ms  25.200 ms

「あれっ？ 4番目と5番目が全部 * （アスタリスク）になって返ってこない！障害が発生しているのかな？」

初学者の頃は、この表示を見ると背筋が凍る思いをするものですが、シニアエンジニアから言わせれば、これは日常茶飯事です。

この現象が起きる主な理由は以下の2つです。

1. ルータのセキュリティ設定（ファイアウォール）:
世の中の多くのルータやセキュリティ機器は、「外から変なパケットが来ても、余計な返事（ICMP Time Exceeded）をするな！」という厳格なポリシーで守られています。そのため、パケットはちゃんと通過しているのに、ルータがあえて「シッ！」と沈黙を守っているケースが多々あります。
2. 非対称ルーティング（Asymmetric Routing）:
行きと帰りで通る道が完全に変わってしまい、エラーメッセージが別のルートを通って迷子になってしまうケースです。

もし途中で * が続いても、その先のホップで再び応答が返ってくるようであれば、パケット自体はちゃんと生き残って目的地に向かっている証拠です。慌てずに全体の流れを見極めましょう。

—

まとめ：ネットワークの「目」を持とう

今回は、tracerouteの基本原理であるTTLのエージングと、ホップバイホップの経路特定についてお話ししました。

tracerouteはパケットの「寿命（TTL）」を1つずつ増やしていくことで、経由するルータの足跡をたどる技術である。
経由地で寿命を迎えたパケットに対し、ルータが「寿命切れだよ」と教えてくれるエラーメッセージを利用している。
途中の * （アスタリスク）は、セキュリティ上の理由でルータが返事を意図的に無視している場合もあるため、慌てず全体の流れを見る。

ネットワークのトラブルシューティングは、目に見えないパケットたちの動きを、こうしたコマンドのヒントを頼りに脳内でどれだけリアルに再現できるかが勝負の分かれ道です。

「今、自分のパケットが海の向こうのルータを駆け抜けているんだな」――そんな想像力を持ちながら、ぜひ日々の運用や検証を楽しんでみてくださいね。それでは、また次回のNOCルームでお会いしましょう！