なぜ「あのパケット」は届かなくても成功するのか？ ― tracerouteの裏側にあるUDPの知恵
ネットワークエンジニアとして深夜のデータセンターで冷え切ったサーバーの前に座っているとき、画面に流れる traceroute の結果は、まさに「迷宮の地図」です。
「どうしてUDPを使うのか？」「なぜ33434番ポートから始まるのか？」
若手エンジニアから時折受けるこの質問に対し、マニュアル通りの回答をするのは簡単です。しかし、現場でトラフィック解析をしていると、この仕様がいかに「泥臭い工夫」の結晶であるかがよく分かります。今日は、この一見奇妙なUDPベースのtracerouteの挙動を、深掘りして解説しましょう。
—
1. なぜ「わざと」届かないポートを狙うのか？
標準的なUnix系OSの traceroute は、宛先に対してわざと「使われていなさそうな高いポート番号（デフォルトで33434〜）」へ向けてUDPパケットを投げます。
なぜか？ 答えは単純明快です。「宛先に到達したことを、確実にホストから教えてもらうため」です。
もしこれがICMP Echo Request（ping）であれば、宛先ホストは正常に応答を返して終わりです。しかし、UDPパケットを意図的に閉じたポートに送りつけると、受信側のOSのネットワークスタックはこう反応します。
> 「おい、誰も待ち受けていないポートにパケットが来たぞ。宛先不明（ICMP Type 3, Code 3: Port Unreachable）を送信元に返しておけ！」
この ICMP Port Unreachable が返ってきた瞬間に、クライアント側は「あ、これ以上先はないんだな。ここが終点だ」と判断できるわけです。非常に古典的ですが、極めて論理的な「終了フラグ」の検知方法なのです。
2. 通信フロー：TTLの魔法とICMPの対話
traceroute の本質は、IPヘッダーにある TTL (Time To Live) フィールドの悪用、もとい活用にあります。
1. TTL=1の送信: パケットを投げる。最初のルーターが TTL をデクリメントし、0になった瞬間に「Time Exceeded (ICMP Type 11)」を送信元に返す。これで1ホップ目が判明。
2. TTLを順次増加: 次は TTL=2、その次は TTL=3 とインクリメントしていく。
3. 終着点での反応: 宛先ホストにパケットが届くと、前述の通り Port Unreachable が返される。これでループを抜ける。
この「道中のルーターからの怒り（Time Exceeded）」と「終点からの拒絶（Port Unreachable）」を使い分けることで、私たちはパケットの航跡を追跡しているのです。
3. 実務で役立つデバッグTips
実務では、標準的な traceroute がファイアウォール（FW）によってブロックされるケースが多々あります。UDP 33434以降を許可していないセキュアな環境で、どうやって調査すべきでしょうか。
Pythonによる簡易実装例
「標準ツールが使えない環境」や「特定のアプリケーションの疎通を確認したい」場合、PythonでSocketを叩く方が早いこともあります。
import socket
import struct
# 宛先とポートを指定
dest_ip = "8.8.8.8"
dest_port = 33434
# UDPソケットを作成
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
# TTLを2に設定して送信（2ホップ先まで確認する場合）
sock.setsockopt(socket.IPPROTO_IP, socket.IP_TTL, 2)
# 空のペイロードを送信
sock.sendto(b"traceroute_test", (dest_ip, dest_port))
print(f"UDPパケットを {dest_ip}:{dest_port} に送信しました。")CLIでの回避策
もしネットワーク管理者が traceroute のUDPをフィルタリングしているなら、-T オプション（TCP SYN）や -I オプション（ICMP Echo）を検討してください。
# TCP 80番ポートを使って経路を追跡する（FWを通過しやすい）
sudo traceroute -T -p 80 example.com
# ICMP Echoを使って追跡する（pingが通る環境ならこれが一番確実）
sudo traceroute -I example.com4. エンジニアへのアドバイス：パケットは「嘘」をつかない
最後に一つだけ、現場からの教訓を。
traceroute の結果で途中のホップが * * * となることがあります。これは必ずしも「そこがダウンしている」わけではありません。ルーターがセキュリティポリシーで「ICMP Time Exceededを返さない設定」にしているだけ、というケースがほとんどです。
「パケットが通らない」と焦る前に、まずは「制御プレーンの制限」を疑うこと。そして、TCPやICMPなど複数の手段で経路を比較すること。これが、障害対応のスピードを左右するシニアエンジニアの思考プロセスです。
ネットワークの迷宮は、コマンド一つで解き明かせるほど単純ではありません。しかし、その裏にある仕様を理解していれば、必ず出口は見つかります。皆さんの現場のパケットが、今日も健やかに流れますように。
コメント