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

「なぜWindowsのtracertは少し違うの？」現場のシニアエンジニアが教えるルート追跡の裏側

こんにちは。ネットワークオペレーションセンター（NOC）で、深夜の障害対応に追われながらも、パケットの流れる光景にロマンを感じている現場エンジニアです。

皆さんは普段、ネットワークの調子が悪いとき、真っ先に何をしますか？そう、ping で疎通を確認し、それでもダメなら traceroute（Windowsなら tracert）で「どこで止まっているか」を確認しますよね。

でも、ふと疑問に思ったことはありませんか？
「Linuxの traceroute はUDPを使うのに、Windowsの tracert はなぜかICMPを使うって聞くけど、結局何が違うの？」

今日は、この「教科書には載っていないけれど、現場では常識」な挙動の秘密を、郵便配達に例えて紐解いていきましょう。

—

郵便配達でイメージする「パケットの旅」

ネットワークの疎通確認は、遠方の友人に手紙（パケット）を送る作業に似ています。

1. ping: 「届いてる？」と確認するだけの往復書簡。
2. traceroute: 経由する全ての郵便局（ルーター）に対して、「お前を通ったぞ、名乗り出ろ！」と記録を残させる旅。

ここで重要になるのが、パケットに付いている「寿命（TTL：Time To Live）」というスタンプです。ルーターを通るたびにこのスタンプが「あと1回」「あと0回」と減っていき、0になった瞬間にルーターは「寿命が尽きたので捨てます」と送信元に報告します。この「捨てた報告」を利用して、どこを通ったか特定するのがルート追跡の基本です。

—

Linux（UDP）とWindows（ICMP）の「手紙の中身」

ここからが本題です。Linux系とWindows系で、この「手紙（パケット）」の中身が違います。

Linuxの流儀：UDPを使う

Linuxの traceroute は、宛先に対して「UDP」という形式の手紙を送ります。しかも、普通の通信では使われないような「非常に大きなポート番号」を指定して送ります。

なぜ？: 宛先のサーバーに「そんなポート使ってないよ！」と怒らせて、「ICMP Port Unreachable（到達不能）」というエラーを返させるためです。これを合図に「ゴールに到着した！」と判定します。

Windowsの流儀：ICMPを使う

一方でWindowsの tracert は、最初から最後まで一貫して「ICMP Echo Request」（いわゆるpingと同じ形式）を使います。

なぜ？: Windowsは、宛先までの経路を確認する際に「pingを少し特殊な方法で連続して送る」というアプローチを取ります。

—

現場で遭遇する「Windows特有の壁」

この違い、実は現場では結構重要なんです。なぜなら、「セキュリティ設定」の壁にぶつかる確率が変わるからです。

多くの企業ネットワークやクラウド環境では、セキュリティ対策として「ping（ICMP）を拒否する設定」がよく行われています。

LinuxのUDP方式: 途中のルーターは「寿命が来た」というエラーをICMPで返してくれますが、ゴール地点では「ポート不一致」という別のエラーを返します。そのため、途中の経路までは特定しやすい。
WindowsのICMP方式: そもそもping自体がブロックされていると、途中のルーターからの応答すら返ってこない、あるいはゴールで完全に無視されるという現象が起きがちです。

「Linuxだとルートが見えるのに、Windowsからだと途中で星印（*）ばかりになる！」という経験、あなたも一度は味わうかもしれません。それはWindowsがICMPという「封筒」を使っているせいで、セキュリティフィルターに引っかかりやすいからなのです。

—

実践：現場で使うコマンドの使い分け

Windowsのコマンドプロンプトで確認する際は、以下のようにシンプルに実行します。

:: 宛先へのルートを追跡する（Windows標準）
tracert -d 8.8.8.8

:: -dオプションをつけることで、IPアドレスの逆引き（名前解決）をスキップします
:: これを付けると、余計なDNS通信が発生せず、結果が早く返ってくるので現場では必須です！

もし、Windows上で「LinuxのようにUDPを使って正確に調査したい」と思った場合は、PowerShellなどで代替ツールを検討するか、素直にLinux環境（WSL2など）を使うのが近道です。

—

最後に：なぜ「違い」を知る必要があるのか

インフラエンジニアの仕事は、単にコマンドを叩くことではありません。「なぜパケットが届かないのか」「なぜこのツールは反応しないのか」という挙動の裏側にあるロジックを想像することです。

「Windowsだから仕方ない」と諦めるのではなく、「ICMPを使っているから、ルーターのファイアウォールで弾かれているのかも？」と一歩踏み込んで推論できる。これこそが、トラブルシューティングの現場で頼られるエンジニアの第一歩です。

皆さんも、明日からは tracert を打つとき、「お、今お前はICMPの封筒で旅をしているんだな」と、パケットの姿を思い浮かべてみてください。ネットワークが、単なる黒い画面の向こう側にある「生き物」に見えてくるはずですよ！

それでは、また次回の現場の知恵袋でお会いしましょう。現場からは以上です！