経路探索の深淵：tracerouteの挙動差異が暴くネットワークの「嘘」
ネットワークエンジニアにとって、tracerouteは単なる導通確認ツールではない。それは、複雑怪奇に絡み合うISPのAS間経路や、中継ルーターの「気まぐれ」を解き明かすための、いわば外科手術用のメスだ。
しかし、なぜ我々は同じ「経路探索」を行っているはずなのに、OSやツールによって全く異なる結果を得ることがあるのか。本稿では、Unix系（UDP/33434〜）とWindows系（ICMP Echo）の挙動差異を軸に、パケットレベルの深淵を覗いていく。
—
1. UDPポートバースト（Unix系）の正体と「透過」の論理
LinuxやmacOSのデフォルトであるtracerouteは、UDPデータグラムを使用する。この手法は非常に巧妙だ。
1. TTLの段階的インクリメント: 送信元はIPヘッダーのTTL（Time To Live）を1から順に増加させながらパケットを投げる。
2. ICMP Time Exceededの誘発: 中継ルーターはTTLが0になった時点でパケットを破棄し、送信元へICMP Type 11 (Time Exceeded)を返す。
3. 非特権ポートの活用: 宛先ホストに到達すると、UDPポート番号（デフォルト33434から開始）が「使われていない」ことを期待する。OSはICMP Type 3 Code 3 (Port Unreachable)を返し、これを受け取った瞬間、探索は「終了」と判定される。
この手法の最大の弱点は、昨今の強固なステートフル・ファイアウォール（FW）だ。多くのFWは、UDPセッションの開始（ポート33434〜）を「不正な通信」または「スキャン」と見なし、ドロップする。結果、経路の途中でアスタリスク（*）が並び、トポロジーがブラックボックス化する。
2. ICMP Echo（Windows系）の静かなる浸透
対してWindowsのtracertは、ICMP Echo Requestを投げる。これは、Pingと同じプロトコルだ。
この手法は、UDPと比較して「透過性が高い」傾向にある。理由は単純で、多くのネットワーク管理者はPing（ICMP Echo）を許可しているからだ。しかし、注意が必要だ。現代の高度なセキュリティポリシーでは、ICMPを「pingの死活監視」に限定し、Tracerouteのような意図的なTTL操作を伴うICMPパケットをレートリミットまたはフィルタリングすることがある。
—
3. 実務で直面する「罠」：パフォーマンスとセキュリティの最適化
現場でトラブルシューティングを行う際、我々はしばしば「経路上のパケットロス」と「ルーターの制御プレーンの負荷」を混同する。
高負荷時における挙動の乖離
中継ルーターにおいて、ICMP Time Exceededの生成は、データプレーンではなく制御プレーン（CPU）で行われることが多い。そのため、ルーターが非常に忙しい場合、応答が間引かれる。これが「ネットワークは混雑していないのにtracerouteだけがロスする」現象の正体だ。
この際、TCPベースの経路探索（tcptraceroute）が真価を発揮する。
# TCP SYNパケットを用いた経路探索（ポート80や443をターゲットにする）
# これにより、FWは「通常のWebトラフィック」として処理するため、透過率が格段に上がる
sudo tcptraceroute -n -p 443 192.0.2.1TCPバッファとMTUの影響
経路探索において、パケットサイズを制御することは重要だ。デフォルトのパケットサイズが、経路上のどこかのセグメントでMTUを超過し、ICMP Fragmentation Neededがブロックされている場合、tracerouteは謎の沈黙を守る。
大規模データセンター間の接続では、以下のチューニングを検討せよ。
# LinuxカーネルのTCPバッファチューニング（sysctl.conf）
# 広帯域・高遅延環境（BDPが巨大な場合）のパケットロス耐性を強化する
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# TCP Window Scalingを有効化
net.ipv4.tcp_window_scaling = 1—
4. 総括：プロトコルの「意図」を読み解く
インフラアーキテクトとして、tracerouteの結果を鵜呑みにしてはならない。
- UDP方式は、トランスポート層を偽装した探索であり、FWのポリシーを露骨に反映する。
- ICMP方式は、IP層の基本機能に依存しており、インフラの堅牢性を測定するのに向く。
- TCP方式は、現代のWebサービスにおいて最も信頼できる「疎通のシミュレーション」である。
トラブルシューティングの極意は、単一のツールに頼らないことにある。ICMPがブロックされているならTCPで叩き、UDPが棄却されるならパケットサイズを調整してMTUの制約を疑う。
現場のNOCでは、パケットが「どこで、なぜ」捨てられたのかを想像する力こそが、最も優れた診断ツールとなる。教科書的なコマンドを打つ前に、そのプロトコルがネットワークのどこで処理されるのか――その「物理的・論理的な居場所」を常にイメージしてほしい。
ネットワークは嘘をつかない。ただ、我々が聞く質問の仕方が間違っているだけなのだ。
コメント