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

なぜ「Windowsのtracert」は、ネットワークエンジニアを悩ませるのか？

夜中の3時、データセンターの片隅で冷たい空気に当たりながら、私はディスプレイを見つめていた。APIのレスポンスが妙に遅い。特定のリージョンからだけ、パケットの往復時間が跳ね上がっている。

「またか」と溜息をつき、お決まりのツールを叩く。Linux環境なら迷わず traceroute を打つところだが、手元の検証用Windowsホストから tracert を叩いたとき、私はふと思い出した。若手エンジニアがよく陥る「ある罠」について。

今日は、教科書的な説明では決して語られない、Windows固有の tracert の挙動と、それが実務の現場でどう「嘘」をつくのか。現場の知見を交えて深掘りしていこう。

—

1. 原理の乖離：UDPか、それともICMPか

多くのエンジニアが混同しているが、UNIX系OSの traceroute とWindowsの tracert は、その「心臓部」の動きが全く異なる。

  • UNIX/Linux系 (traceroute): 基本的に UDP パケット（ポート33434番以降）を送信する。宛先ホストに向けてTTL（Time To Live）を1から順にインクリメントし、経路上のルータから返ってくる ICMP Time Exceeded を拾う。
  • Windows (tracert): 実は ICMP Echo Request (Type 8) を送信する。そう、あの ping と同じパケットだ。

この仕様の違いが、現場では決定的な「見える景色」の差を生む。

なぜこれが問題なのか？

最近の堅牢なファイアウォールやACL（Access Control List）は、トラフィックの種別に応じて厳密に制御されていることが多い。
「ICMP は拒否するが、UDP は特定のポートなら通す」といった設定がなされている場合、Linuxから打てば経路が見えるのに、Windowsから打つと途中で星印（* * *）が並んでタイムアウトする――。そんな経験はないだろうか。それはネットワークの不調ではなく、単に tracert が使っているプロトコルが門前払いされているだけなのだ。

—

2. 実務で遭遇する「パケットの迷走」をコードで読み解く

Web APIの疎通確認を行う際、curl やPythonで同様の検証を行うことも多いはずだ。ここで、なぜ tracert の結果を鵜呑みにしていけないのか、Pythonで擬似的な実装を考えてみよう。

import socket
import struct

# ICMP Echo Requestを模倣したパケット送信の概念コード
def send_icmp_probe(dest_ip, ttl):
    # ICMP Type 8 (Echo Request) を構築
    # ※実際にはソケットオプションでTTLを設定する必要がある
    sock = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_ICMP)
    sock.setsockopt(socket.IPPROTO_IP, socket.IP_TTL, ttl)
    
    # パケット送信 (データ部分は簡略化)
    sock.sendto(b'\x08\x00\xf7\xff\x00\x00\x00\x00', (dest_ip, 1))
    
    # 応答を待つ
    # ここで返ってくるのが ICMP Time Exceeded (Type 11)

もし君たちがAPIの疎通性をデバッグするなら、tracert だけで安心せず、必ず curl や nmap で「実際のアプリケーションポート」が通るかを確認してほしい。

# APIサーバーの80/443ポートに対して疎通を確認するコマンド例
# tracerouteの結果が途切れていても、TCP/UDPの特定のポートなら通ることは往々にしてある
curl -Iv https://api.example.com/healthcheck

—

3. シニアエンジニアからの教訓：現場での「切り分け」手順

トラブルシューティングの現場では、ツールを盲信せず、「どのプロトコルが許可されているか」を逆算して考えるのが鉄則だ。

ステップ1: 境界を確認する

まず tracert を打つ。もし中継ノードでパケットが止まるなら、それは「経路上でICMPが制限されている」可能性を疑う。

ステップ2: 別の手法を試す

Linux環境や、あるいは tcptraceroute のようなツールを使い、ターゲットポート（例：443）に対して TCP SYN を送り、経路を再確認する。

# TCP 443ポートを利用したトレース（Linux環境の例）
# これにより、FirewallがICMPを弾いているだけなのか、本当に経路が切れているのかが分かる
sudo traceroute -T -p 443 api.example.com

ステップ3: APIのレスポンスタイムとの相関をとる

tracert の各ホップの応答速度と、実際に Fetch API 等で叩いたときの Time to First Byte (TTFB) を比較する。

// ブラウザやNode.js環境での簡易計測例
const start = performance.now();
fetch('https://api.example.com/data')
  .then(() => {
    const end = performance.now();
    console.log(`APIレスポンス時間: ${end - start}ms`);
  });

—

結論：ツールはあくまで「視点」の一つに過ぎない

tracert はWindowsにおける標準ツールであり、手軽で便利だ。しかし、それが ICMP という「特定の言語」で会話しているに過ぎないことを忘れてはいけない。

ネットワークのトラブルシューティングにおいて、最も恐ろしいのは「見えているものだけが真実だ」と思い込むことだ。tracert が星印を表示したとき、それは「ネットワークが死んでいる」のではなく、「君のパケットが、そのファイアウォールのセキュリティポリシーによって丁重に無視されただけ」かもしれない。

次にトラブルにぶつかったときは、そのパケットがどんな「服（プロトコル）」を着ているのか、そして「相手（ルータやFW）」がその服を好むのかどうかを想像してみてほしい。それが、一流のインフラエンジニアへの第一歩だ。

健闘を祈る。また次の現場で会おう。

スポンサーリンク

コメント

タイトルとURLをコピーしました