こんにちは！長年、データセンターの薄暗いサーバーラックの間で、パケットのささやきを聞き続けてきたNOCエンジニアです。
皆さんは「なんだか通信が遅いな？」「特定のサイトだけつながらないぞ？」と思ったとき、真っ先にどのコマンドを打ちますか？ おそらく、多くの方が ping や traceroute を思い浮かべるはずです。
特に traceroute（Windowsでは tracert）は、自分のPCから目的のサーバーまで「パケットがどのルーターを経由しているか」を可視化してくれる、まさにネットワーク界の「スタンプラリー」のようなツールです。
しかし、このツール。「Windowsで実行するとうまくいくのに、LinuxやMacからだと途中で星マーク（* * *）になって消えてしまう……」という不思議な現象に遭遇したことはありませんか？
実は、WindowsとUnix系（Linux/Mac）では、目的地を探すための「手段」が根本的に違うのです。今日はその舞台裏を、郵便配達の仕組みに例えて、優しく、かつ深く紐解いていきましょう！
—
そもそも traceroute はどうやって「道」を知るのか？
本題に入る前に、まずは traceroute の魔法の種明かしをしておきましょう。
通常、インターネット上のパケットには TTL（Time To Live） という「寿命」が設定されています。これは「ルーターを1つ通過するたびに1減る数値」です。
もしこの数値が「0」になると、その時パケットを持っているルーターは、「残念ですが、ここで寿命です」というメッセージ（ICMP Time Exceeded）を送り主に返して、パケットを破棄します。
traceroute はこの仕組みを逆手に取ります。
1. まず TTLを「1」にしてパケットを投げる → 最初のルーターで寿命が尽き、1番目の場所がわかる。
2. 次に TTLを「2」にして投げる → 2番目のルーターで寿命が尽き、2番目の場所がわかる。
3. これを繰り返して、ゴールまでの地図を完成させる。
この「寿命が尽きたよ！」という返信をもらうプロセスは共通なのですが、「どんなパケットを投げるか」が OS によって異なるのです。
—
1. Windows流：丁寧な「お返事ください」方式 (ICMP)
Windowsの tracert コマンドが使うのは、ICMP Echo Request という種類のパケットです。これは ping で使われるものと全く同じです。
挙動のイメージ
郵便に例えると、こんな感じです。
> Windowsくん： 「すみません、受取人さん。届いたら『届いたよ』って返事をくれるハガキを送りますね！」
Windowsは、目的地に対して「返事をください」というリクエストを投げます。道中のルーターたちは、寿命が来たパケットに対して「ここで寿命ですよ」と教えてくれます。そして最終目的地に届いたとき、相手は「はい、届きましたよ（ICMP Echo Reply）」と返事をしてくれます。
メリットとデメリット
- メリット: 非常にシンプル。
- デメリット: セキュリティの観点から、多くの企業のファイアウォールやサーバーでは「ping（ICMP）への応答」を禁止していることが多いです。そのため、ゴール直前で遮断されてしまうことがよくあります。
—
2. Unix/Linux/Mac流：あえて「間違い電話」をかける方式 (UDP)
一方で、LinuxやMacの traceroute は、デフォルトでは UDP（User Datagram Protocol） という方式を使います。しかも、宛先のポート番号に 33434 番といった、「まず普通は使われていない大きな数字」を指定して送ります。
挙動のイメージ
これが非常にユニークなんです。
> Linuxくん： 「（どうせ誰も使っていないだろうけど）33434番窓口宛に荷物を送るよ！ もし窓口がなかったら『そんな窓口ないよ』って教えてね！」
道中のルーターが「寿命ですよ」と教えてくれるのはWindowsと同じです。
面白いのは「ゴールに着いた時」です。パケットを受け取った目的地サーバーは、中身を見てこう思います。
「えっ、33434番ポートなんて開いてないよ！ そんなサービスやってないよ！」
そして、サーバーは送り主に 「ICMP Port Unreachable（そんなポートはありません）」 というエラーを返します。この「エラー」が届いたことで、Linuxくんは「よし、エラーが返ってきたってことは、そこが目的地だな！」と判断するのです。
メリットとデメリット
- メリット: ネットワーク機器によっては、ICMP（ping）は無視するけれど、UDPパケットなら通してくれる、という設定になっている場合があります。
- デメリット: 逆に「使っていないポートへの通信」を攻撃とみなしてブロックするファイアウォールがあると、そこで止まってしまいます。
—
どちらが「壁（ファイアウォール）」を通り抜けやすい？
ここがエンジニアの腕の見せ所です。現場では、以下のような「壁」にぶつかることがよくあります。
- ケースA: Windowsの
tracertは通るのに、Linuxのtracerouteは通らない。 - 原因: ファイアウォールで「高い番号のUDPポート」が閉じられている。
- ケースB: どちらも途中で
* * *になる。 - 原因: 途中のルーターが「寿命が尽きたよ」という通知（ICMP）自体を返さない設定になっている（セキュリティの厳しい商用バックボーンなど）。
実践！コマンドを使い分けて診断しよう
もしあなたがLinuxを使っていて、デフォルトのUDP方式でうまくいかない場合は、「Windowsと同じICMP方式」に切り替えて試してみましょう。
# [Linux] 通常のUDP方式（デフォルト）
traceroute google.com
# [Linux] Windowsと同じICMP方式を使う（管理者権限が必要です）
# これで通るなら、UDPポートがどこかで遮断されています。
sudo traceroute -I google.com
# [Linux] Webサーバーの調査なら、TCPの80番ポートを使う裏技も！
# 実際のWeb通信と同じポートを使うので、より正確な経路がわかります。
sudo traceroute -T -p 80 google.comWindowsの場合も、標準の tracert 以外に、高度なツールを使うことで診断の幅が広がります。
:: [Windows] 標準のコマンド
tracert google.com—
NOCエンジニアのイチオシ：最強ツール mtr
もしあなたがこれからインフラエンジニアを目指すなら、ぜひ覚えておいてほしいツールがあります。それが mtr (My Traceroute) です。
これは ping と traceroute を合体させたようなツールで、リアルタイムに経路ごとの「パケットロス率」や「遅延のムラ（ジッタ）」を表示してくれます。
# 経路の品質をリアルタイムで監視する
# -w オプションでレポート形式での出力も可能です
mtr google.com現場で「通信が不安定だ！」と騒ぎになったとき、この mtr を走らせて「3番目のルーターでパケットが20%落ちていますね」と即座に回答できれば、あなたはもう立派なネットワーク職人です。
—
まとめ：道具の「癖」を知れば、ネットワークはもっと楽しくなる！
いかがでしたでしょうか？
- Windows (
tracert) は、丁寧な「お返事ください（ICMP）」方式。 - Unix系 (
traceroute) は、あえて空振りを狙う「間違い電話（UDP）」方式。
この違いを知っているだけで、トラブルが起きた時に「次はどのコマンドを試すべきか」という次の手が見えてきます。
ネットワークの世界は、目に見えないパケットたちが健気に、そして時に不器用にやり取りを繰り返すことで成り立っています。次に traceroute を打つときは、ぜひそのパケットたちが一生懸命「寿命です！」というメッセージを運んでいる姿を想像してみてください。
一歩ずつ、パケットの気持ちがわかるエンジニアになっていきましょうね！応援しています！
コメント