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

ネットワークの深淵を覗く：なぜWindowsの tracert は「異端」であり続けるのか

深夜3時、データセンターのラック列に響くファンの音を聞きながら、私はいつも思う。ネットワークの障害は、往々にして「見えない場所」で起きる。パケットがどこで息絶えたのか、あるいはどのルーターがパケットを「冷たくあしらった」のかを知るために、我々は traceroute という魔法の杖を振るうわけだが、OSによってその「杖の振り方」が根本的に異なることを意識しているエンジニアは意外と少ない。

今回は、Windowsの tracert が採用する「ICMP Echo Request」ベースの追跡ロジックと、それが現代の超高速・高セキュリティなネットワークにおいてどのような意味を持つのか、その泥臭い内部挙動を紐解いていこう。

1. UDP vs ICMP：パケットの「身分証明」を巡る戦い

LinuxやmacOSの traceroute は、デフォルトでUDPパケット（ポート番号33434からインクリメント）を送り出し、そのTTL（Time To Live）が0になった際にルーターから返される ICMP Time Exceeded を捕捉する。これは、アプリケーション層の通信を模倣する点では理にかなっている。

対して、Windowsの tracert は、最初から ICMP Echo Request (Type 8) を投げつける。パケットのTTLを1から順にインクリメントし、経路上のルーターから返される ICMP Time Exceeded (Type 11) を収集する。

なぜこれが「異端」なのか？

現代の堅牢なファイアウォールやIDS/IPSは、ICMP Echo Request に対して非常に敏感だ。多くのエッジ機器は、「pingに対する応答」のみを許可し、それ以外のICMPトラフィックを遮断する設定になっていることが多い。

UDP方式: アプリケーションポートへの通信を装えるため、ステートフルなファイアウォールを「透過しているように見える」場合がある。
ICMP方式: ネットワーク管理者がセキュリティポリシーで厳格に「ICMP拒否」を設定している場合、tracert は途中で完全に沈黙する。

運用現場で「Linuxからは到達するのに、なぜWindowsからは落ちるのか」と頭を抱えるエンジニアの多くは、このICMPフィルターの壁にぶつかっている。

2. パケットレベルの挙動とパフォーマンスの観点

tracert の挙動を深く理解することは、TCPバッファチューニングやRTT（Round Trip Time）の最適化を考える上での基礎となる。

tracert が送信するパケットは小さい。しかし、これが頻発することで、特に低帯域のリンクや、パケット検査（DPI: Deep Packet Inspection）を行うゲートウェイでは「ノイズ」として処理される。また、セキュリティ専門家の視点では、頻繁なICMP応答は ICMP Flood の予兆や、ネットワークトポロジーを外部に漏洩させるリスクと見なされる。

パフォーマンスチューニングへの示唆

もし君たちが大規模なアーキテクチャのレイテンシ削減に取り組んでいるなら、以下の sysctl 設定を見直すべきだ。LinuxカーネルレベルでICMP応答のレート制限を緩和・調整することで、監視ツールからの応答精度を向上させることができる。

# ICMPレート制限を調整（高負荷時の応答性を担保）
# /etc/sysctl.conf に追記して反映
net.ipv4.icmp_ratelimit = 1000
net.ipv4.icmp_ratemask = 88088

# 変更を反映
sysctl -p

3. 実践：トランスポート層を意識した診断のベストプラクティス

tracert はあくまで「ICMPの到達可能性」を示すものに過ぎない。もし君がHTTP/3 (QUIC) や TLS 1.3 を多用するWebサービスのパフォーマンスを追っているなら、単なる tracert では不十分だ。

TCPのハンドシェイク（SYN/SYN-ACK）におけるRTTを計測するには、tcptraceroute や、より洗練されたツールを使用すべきだ。これらは、特定のTCPポート（例: 443）への接続を試みるため、実際のアプリケーション経路をより正確に追跡できる。

高度な診断のためのPythonスニペット

以下は、特定のポートに対するパスMTUや経路の挙動を確認するための簡易的な概念コードだ。

import socket

# 特定のターゲットに対してTCP接続を試行し、
# 経路上のルーターがどのようにパケットを扱うかを調査する
def probe_path(target_host, port=443):
    # ソケットを作成し、TTLを細かく操作する（Rawソケットが必要）
    # 現場では scapy などのライブラリを活用するのが定石
    print(f"Starting probe for {target_host}:{port}...")
    # ここに raw socket を用いたパケット送信ロジックを実装する
    # TCP SYN パケットを構築し、IPヘッダーのTTLフィールドを操作する
    pass

# トレードオフの考慮:
# TCP接続試行はセキュリティログに残りやすいため、
# 監視対象のサーバーに悪影響を与えないよう注意すること。

4. 現場のシニアエンジニアからの一言

「ツールが提供する結果」を鵜呑みにしてはいけない。tracert が星印（*）を表示したからといって、必ずしもそこでサーバーがダウンしているわけではない。多くの場合、それはルーターが「管理用トラフィックを優先し、ICMP処理を後回しにしている（コントロールプレーンの保護）」か、「単にICMPを破棄するポリシーが適用されている」だけだ。

ネットワーク診断とは、パケットという「目に見えない旅人」が、冷酷なゲートウェイ（ファイアウォール）や、気まぐれなルーターのバッファをどうすり抜けていくかを想像するクリエイティブな作業である。

Windowsの tracert は、その古典的な手法ゆえに、現代のネットワークでは「あえて無視される」ことでトラブルシューティングを難しくすることもある。もし君がインフラの信頼性を極めたいのなら、ICMPに頼りきらず、tcptraceroute や mtr を使いこなし、パケットがトランスポート層でどのように振る舞うかを、カーネルレベルで追跡する視点を養ってほしい。

ネットワークは嘘をつかない。ただ、我々が見ている「解釈」が間違っているだけなのだ。