ネットワーク運用の現場に身を置いていると、夜中に突然「社内システムが重い」「特定の拠点からクラウドに繋がらない」といったアラートが飛び込んでくることがあります。そんなとき、私たちNOC（ネットワークオペレーションセンター）のエンジニアが真っ先に手に取る魔法の杖が、宛先までの経路を暴き出す traceroute（Windowsでは tracert）です。
しかし、ここで長年インフラを触ってきたエンジニアほど、ふと疑問に思うことがあります。
「あれ？ Linuxの traceroute と、Windowsの tracert って、やってることは同じなのに、どうしてファイアウォールの向こう側に対する挙動がこうも違うんだろう？」と。
今回は、この謎を解き明かしながら、ICMPベースのtracerouteが持つ独特の仕様と、現場で役立つ実践的なトラブルシューティングの世界へ皆さんをご案内します。難しい専門用語はできるだけ噛み砕いてお話ししますので、一歩ずつリラックスして理解していきましょう！
—
1. ネットワークの「郵便配達」でイメージするtracerouteの基本
まずは、traceroute がやっていることを身近な例えで考えてみましょう。
あなたが遠く離れた友人に手紙を送るとします。手紙は直接友人のポストに届くわけではなく、地元の郵便局から中継局、相手の街の郵便局へと、いくつかの「中継地点（ルーター）」を経由して運ばれますよね。
もし、「この手紙が今、どこを通って届いたのか」を調べたいとしましょう。
標準的な traceroute（Linuxなどで使われる方式）のやり方は、こんな感じです。
1. 「寿命（TTL：Time-to-Live）」が「1」のスタンプを押した手紙を出す
- この手紙は、最初の中継地点（ルーター）に届いた瞬間に「寿命切れ」になってしまいます。
2. 最初のルーターが「寿命切れです！」と差出人に教えてくれる
- これで「最初のルーターがどこにあるか」が分かります。
3. 次は「寿命2」のスタンプを押して手紙を出す
- 2番目の中継地点で寿命切れになるため、2番目のルーターの場所が分かります。
4. これを繰り返して、最終的な宛先までたどり着く。
これが traceroute の基本的な仕組みです。途中のルーターに「ちょっとお邪魔します、あなたの住所を教えてください」と手紙を送りつけて、その返事から経路をマッピングしていくわけですね。
—
2. Windowsの tracert が持つ「ちょっとしたこだわり」
ここで今回の主役であるWindowsの tracert の登場です。
実は、一般的な traceroute とWindowsの tracert には、中継地点に投げる「手紙の種類」に大きな違いがあります。
- 一般的な
traceroute（LinuxやmacOSなど）のやり方 - 最初は UDPパケット（あるいはTCPパケット）という、普段はアプリが通信に使うような形式のデータを使って、わざとポート番号を外しながら送ります。
- Windowsの
tracertのやり方 - 最初から最後まで一貫して ICMP Echo Request（いわゆる
pingのお友達）を使います。
「あれ、ping と同じなら分かりやすくていいじゃないか」と思いますよね。確かに仕組み自体はシンプルで直感的です。しかし、これが現場のネットワーク運用では「諸刃の剣」になることがあるのです。
—
3. なぜファイアウォールで挙動が変わるのか？
実際のデータセンターや企業ネットワークには、不正なアクセスを防ぐための「ファイアウォール（警備員）」が必ずと言っていいほど立ち塞がっています。
ここで、警備員（ファイアウォール）の気持ちになって考えてみましょう。
一般的な traceroute（UDP方式）の場合
ランダムなポート番号宛てのUDPパケットが飛んできたとき、警備員やルーターは「おっと、このポート番号宛てのサービスは動いていないぞ。送信元に『そんなポートないよ（ICMP Port Unreachable）』と教えてあげよう」と親切に返事をします。
この返事こそが、私たちが経路を特定するための重要な手がかりになります。
Windowsの tracert（ICMP方式）の場合
Windowsの tracert は、中継地点に対して ping（ICMP Echo Request）を投げ続けます。
しかし、世の中の多くのセキュリティポリシーでは、「インターネット側から社内ネットワーク機器への ping はすべて無視（ドロップ）する」という設定がされています。社内ルーターがセキュリティのために ping に応答しないようにしているわけです。
結果どうなるか？
Windowsの tracert を実行すると、途中のルーターまでは寿命切れの通知が返ってくるので綺麗に表示されるのに、セキュリティが厳重なルーターや宛先のサーバーに近づいた瞬間、突然画面に * * *（タイムアウト）が並び続けるという現象が起きます。
「あれ？ サーバーが落ちているのかな？」と焦ってしまう瞬間ですが、実はルーターやサーバーが単に「Windowsからの ping（ICMP）には返事をしない」と設定されているだけ、というケースが現場では非常によくあるのです。この違いを知っているだけで、障害切り分けのときの無駄な焦りがスッと消えていきますよね。
—
4. 実務で役立つ！ コマンドの実行例とポイント
それでは、実際にWindows環境やLinux環境でどのようにこれらを使い分けるか、実用的なコマンド例を見ていきましょう。
Windowsでの tracert 実行例
WindowsのコマンドプロンプトやPowerShellを開き、次のように入力します。
C:\Users\NOC-Engineer> tracert -d 8.8.8.8
# 【解説】
# -d オプションをつけることで、IPアドレスからホスト名への逆引き名前解決をスキップします。
# これにより、DNSの応答待ちでコマンドがモタつくのを防ぎ、現場での迅速な調査が可能になります。Linuxでの traceroute 実行例（ICMPモードの強制）
もしLinux環境でWindowsの tracert と同じ挙動（ICMPを使った経路探索）を試したい場合は、 -I オプションを使用します。
$ traceroute -I 8.8.8.8
# 【解説】
# デフォルトではUDPを使うLinuxのtracerouteですが、-I オプションを指定することで
# ICMP ECHO（pingと同じパケット）を用いた経路探索に切り替えることができます。
# ファイアウォールの通過性を比較したいときに非常に便利なテクニックです。—
5. まとめ：現場のエンジニアとしての心構え
今回は、Windows固有の tracert が持つICMPベースの仕様と、ファイアウォール通過時の挙動の違いについてお話ししました。
- 一般的な
tracerouteはUDPなどを使い、ポート不達の通知を頼りに経路を探る。 - Windowsの
tracertはICMP Echo Requestを使い、よりpingに近い挙動をする。 - セキュリティ設定（ファイアウォール）によっては、Windowsの
tracertの方が途中でプツッと応答が途絶えやすい。
ネットワークの世界では、見えているパケットの形が少し違うだけで、セキュリティ機器の反応がガラリと変わり、トラブルシューティングの結論が180度変わることが多々あります。「なぜこのツールはこの動きをするのか？」という背後にあるストーリーを少しだけ想像できるようになると、ネットワーク技術はもっと楽しく、深みのあるものになりますよ。
日々の運用監視やトラブル対応、本当にお疲れ様です。次に * が並んだ画面に直面したときは、「おっ、ここは厳重な警備員が立ち塞がっているな」と、ぜひニヤリとしながらパケットの旅路を想像してみてくださいね。
コメント