なぜ「UDP Traceroute」を知らねばならないのか？― ネットワークの「見えない壁」を突破する技術
現場でトラブルシューティングをしていると、若手エンジニアからよくこんな相談を受ける。「pingは通るのに、なぜかAPIが叩けない」「特定のパスでパケットが消える」。そんな時、私は決まってこう返す。「お前の traceroute は何を投げているか分かっているか？」と。
多くのエンジニアが何気なく使っている traceroute だが、実はOSによって中身が全く違う。Windowsの tracert はICMP Echoを使うが、Linuxの traceroute（あるいは traceroute -u）が標準で行うのは、「あえて誰も聴いていない高位UDPポートを叩く」という、少し意地悪だが非常に理にかなった通信だ。
今日は、この「UDPベースのTraceroute」がなぜインフラ運用の現場で最強の武器になるのか、そのメカニズムと実用的なデバッグ術を紐解いていく。
—
1. 仕組みの核心：なぜ「届かないはずのUDP」を送るのか
Linux環境で標準的な traceroute を実行すると、送信元は宛先に対して 33434 番ポートから始まるUDPパケットを送り出す。これには明確な理由がある。
1. 生存期間（TTL）の仕掛け: 最初のパケットの TTL を 1 に設定する。
2. ルーターの反応: 経由するルーターは、パケットを受け取るたびに TTL を 1 減算する。TTL が 0 になったルーターは、送信元へ ICMP Time Exceeded（時間切れ）を返す。これで経路が特定できる。
3. 終端の検知: 目的地に到達した際、OSは「そんなポート開いてないよ」という意味で ICMP Port Unreachable を返してくる。このメッセージを受け取った瞬間に、traceroute は「あ、ここが終点だ」と判断する。
つまり、「返事が返ってくること」ではなく「エラー（Unreachable）が返ってくること」をゴールに設定しているわけだ。これが、UDPベースのTracerouteがパケットの消失を正確に検知できる最大の強みである。
—
2. 実践：CLIで挙動を追いかける
ただコマンドを打つだけでは一人前とは言えない。パラメータをいじって、ネットワークの深淵を覗くのだ。
# -I をつけるとICMPを使うが、今回はUDPの挙動を見るためにデフォルトを実行
# -p で開始ポートを指定可能。ファイアウォールで特定のUDP範囲がブロックされているかの検証に使う
traceroute -p 33434 8.8.8.8
# 応答がない場合に、なぜ止まっているかを確認するために詳細モードを活用
traceroute -v 8.8.8.8もし、特定のホップで * * * と表示され続けるなら、そこにはパケットを破棄する「黒い穴（ブラックホール）」が存在する。UDPベースであれば、ルーターがICMPを返さない設定（Rate Limit等）になっている可能性が高く、この場合は traceroute -I（ICMPモード）や tcptraceroute を併用して、「何が通れて、何が通れないか」をパズルのように組み立てる必要がある。
—
3. アプリケーション視点のデバッグ：Pythonによる実装
Web APIの開発において、「サーバー側のポートが空いているか」を検証したいとき、curl も便利だが、生のUDPパケットの挙動を知っておくとトラブル対応の幅が広がる。Pythonの scapy を使えば、より詳細なパケット操作が可能だ。
from scapy.all import IP, UDP, sr1
# 宛先IPとターゲットのUDPポート
target_ip = "192.168.1.1"
target_port = 5000
# UDPパケットを構築（ペイロードは空でもOK）
packet = IP(dst=target_ip) / UDP(dport=target_port)
# パケットを送信し、応答を待つ
reply = sr1(packet, timeout=2)
if reply:
if reply.haslayer("ICMP"):
if reply.getlayer("ICMP").type == 3: # Type 3はDestination Unreachable
print(f"ポート {target_port} は閉じているか、到達不能です。")
else:
print("応答がありません。ファイアウォールでドロップされている可能性があります。")—
4. 現場のシニアからのアドバイス
実務において、traceroute は単なる「経路確認ツール」ではない。「どのファイアウォールポリシーが通信を遮断しているか」を切り分けるためのフォレンジックツールだ。
- UDPが通らない場合:
tracerouteが終端で止まるか、途中のルーターがICMPをブロックしている。 - TCPだけ通る場合: 経路上のセキュリティ機器（IPS等）がUDPトラフィックを「不正なポートスキャン」と見なして遮断している可能性がある。
最後に一つだけ覚えておいてほしい。ネットワークエンジニアとしての真価は、ツールが表示する「結果」ではなく、「なぜその結果になったのか」という仮説を、パケットの挙動から逆算できる能力にある。
教科書通りのコマンドを打つのは新人の仕事だ。プロは、返ってこないICMPの沈黙の中に、ネットワークの設計ミスやセキュリティポリシーの穴を読み取る。皆さんもぜひ、自分の手元のマシンから、世界の向こう側へパケットを投げ、その「沈黙」と対話してみてほしい。そこには、ドキュメントには載っていない真実が必ずある。
コメント