【入門編】 ICMPベースのtraceroute（Windows tracert等）の動作差異 – トラブルシューティング＆ネットワーク運用監視実践ガイド

なぜ「宛先に届かない？」を解決するtracerouteの裏側を紐解く：WindowsとLinuxの意外な違い

ネットワークエンジニアとして現場に立っていると、必ずと言っていいほど直面するのが「通信が途中で消える」という不可解なトラブルです。そんな時、一番にお世話になるのが traceroute（Windowsでは tracert）ですよね。

「あ、途中のルーターで止まってるな」「ここまでは正常に来ているな」と、パケットの足取りを追跡してくれるこのツール。実は、OSによって「追いかけ方」が微妙に違うことをご存知でしたか？今日は、現場で地味に差が出るこの「実装の違い」について、少しだけ深く、でも優しくお話ししていきたいと思います。

—

郵便配達で例える「traceroute」の仕組み

まずは、パケットの動きを「郵便」に例えてみましょう。

traceroute は、宛先までの道のりを一つずつ確認する「迷子にならないための探索」です。パケットには「TTL（Time To Live）」という寿命が設定されています。この寿命は、ルーターを通過するたびに「1」ずつ減っていき、ゼロになった瞬間に「寿命が尽きました！」という通知（ICMP Time Exceeded）を返送するようにできています。

traceroute はこれを利用して、わざと寿命の短い手紙を送り、途中のルーターに「寿命だよ！」と反応させて、その送り主（ルーターのIPアドレス）を特定しているんです。

—

Windowsの tracert と Linuxの traceroute の違い

さて、ここからが本題です。多くのエンジニアが混乱するのは、「Windowsの tracert はICMPを使うのに、Linuxの traceroute はなぜかUDPを使う（のがデフォルト）」という点です。

1. Windows（tracert）の流儀：ICMP Echo Request

Windowsの tracert は、いわゆる ping で使われる「ICMP Echo Request」を送りつけます。

メリット: 非常にシンプルで、多くのネットワーク機器が「pingには答える」設定になっているため、計測が成功しやすいです。
デメリット: 企業のセキュリティポリシーで「ICMPは一切許可しない」というファイアウォールがある場合、パケットが門前払いを食らってしまい、正確な追跡ができません。

2. Linux（traceroute）の流儀：UDPパケット

一方、Linuxなどの標準的な traceroute は、本来は使われないような「非常に大きなポート番号（33434以降）」宛に、UDPパケットを投げます。

メリット: 「通信の一部」として振る舞うため、ファイアウォールをすり抜けられる可能性が（ICMPよりは）高いです。
デメリット: 途中の経路でパケットがフィルタリングされていたり、そもそもUDPのポートスキャンを警戒する環境では、結果が「* * *（タイムアウト）」になってしまうことがあります。

—

現場で役立つコマンドの使い分け

実務では、標準的なコマンドだけでなく、オプションを駆使して「どこまで通るか」を調べるのがプロの技です。

WindowsでTCPポートを指定して確認する（PowerShell）

Windows標準の tracert はICMP固定ですが、もし「Webサーバー（80番/443番）まで届いているか？」を調べたいなら、PowerShellの Test-NetConnection が最強です。

# 80番ポートへの経路を詳細に調査する（ルートトレース）
Test-NetConnection -ComputerName "example.com" -InformationLevel "Detailed" -TraceRoute

LinuxでICMPを選択する（-I オプション）

Linuxで「Windowsと同じようにICMPで調査したい」時は、しっかり指定してあげましょう。

# -I オプションでICMP Echo Requestを利用して追跡
sudo traceroute -I example.com

—

なぜ「* * *」と表示されるのか？

トラブルシューティングをしていて、結果が * * * と表示されると焦りますよね。でも、安心してください。これは必ずしも「障害」ではありません。

1. ファイアウォールのガード: 途中のルーターが「パケットは通すけど、いちいち返事するのは面倒（またはセキュリティ的に嫌）」という設定になっているだけかもしれません。
2. ICMPのレート制限: ルーターが「返信が多すぎて負荷が高いから、返信を間引こう」と判断しているケースです。

「ここが通らないから通信障害だ！」と断定する前に、「ICMPを拒否する設定になっていないか？」と一度立ち止まって考えるのが、百戦錬磨のエンジニアへの第一歩です。

—

最後に：一歩ずつ理解していきましょう

ネットワークの世界は、目に見えないパケットが飛び交う広大な宇宙のようなものです。最初は tracert や traceroute の結果を眺めていても「何がどうなっているんだ？」と迷子になるかもしれません。

でも、大丈夫です。まずは「手紙（パケット）を投げて、反応（ICMP）を待つ」という単純な繰り返しの積み重ねだと考えてみてください。一つひとつのコマンドがどんなパケットを投げているのかを意識し始めると、ネットワークの向こう側に、ルーターやファイアウォールが呼吸している姿が見えてくるはずです。

皆さんのネットワーク運用が、トラブルの少ない平和なものになりますように。また現場でお会いしましょう！