夜通しの障害対応で冷めかけたコーヒーをマグカップごと持ち上げながら、私は後輩のエンジニアにこう問いかけることがある。
「おい、Web APIのレスポンスが突然返らなくなったとき、お前はまず何を叩く？」
大抵の若手は「pingです！」と元気に答える。間違っちゃいない。L3の生死確認としては王道だ。だが、シニアの現場では、ping（ICMP Echo）が通らないからといって「経路が死んでいる」「サーバーが落ちている」と即断するのは素人のやることだ。セキュリティポリシーでICMPがバッサリとドロップされている環境なんて、今や企業インフラでもクラウドでも星の数ほどある。
では、パケットがどのルーターをホップし、どこで消えているのかを正確に突き止めたいとき、お前は何を使う？
そう、tracerouteだ。今回は、多くのエンジニアが「なんとなく便利だから」と使っているtracerouteの裏側、特にUDPベースの方式がいかにエレガントなトリックを使ってネットワークの急所を暴き出しているかについて、実務の現場目線で徹底的に紐解いてやろう。
—
1. なぜUDPなのか？パケットを迷子にする巧妙な仕組み
ネットワークの診断ツールといえばtraceroute（Windowsならtracert）だが、実はOSや実装によって、使っているプロトコルが違うのを知っているか？
Windowsの標準tracertはデフォルトでICMP Echo Requestを投げる。しかし、Linuxや多くのUNIX系OSで標準的に使われる伝統的なtracerouteは、UDPパケットを標的に叩き込む。
「TCPでもなく、なぜUDPなのか？」
理由は単純だ。UDPは「コネクションレス」のプロトコルだからだ。TCPのように3wayハンドシェイクを確立する必要がなく、いきなりパケットを送りつけられる。しかも、UDPの挙動には、ルーターや宛先ホストから「返り討ち」に遭いやすいという絶妙な性質がある。
tracerouteはこの「返り討ちの性質」を逆手に取っているのだ。
TTL（Time to Live）という名の寿命タイマー
パケットが無限ループに陥ってインターネットが崩壊しないよう、IPヘッダーには TTL（IPv4）または Hop Limit（IPv6）というフィールドが存在する。ルーターを1台通過するたびにこの値は「1」ずつデクリメントされ、値が「0」になった瞬間にそのルーターはパケットを破棄し、同時に送信元へ向けて ICMP Time Exceeded（タイプ11、コード0）というエラーメッセージを泣きながら送り返す。
これがtracerouteの基本原理だ。
1. 送信元は、あえて TTL=1 に設定したUDPパケットを投げる。
2. すぐ隣のルーター（ホップ1）がパケットを受け取り、TTLを1減らして「0」にする。
3. ルーターはパケットを捨て、送信元に ICMP Time Exceeded を送る。これでホップ1のIPアドレスが判明する。
4. 次は TTL=2 にして投げる。ホップ1を通過し、ホップ2のルーターで再びパケットが破棄され、ホップ2のIPアドレスが判明する。
5. これを繰り返し、目的地に到達するまでホップを暴いていく。
—
2. 誰も聞いていないポートを狙え！「ICMP Port Unreachable」の美学
ここで一つ疑問が湧くはずだ。
「目的地（宛先ホスト）にたどり着いたあとのUDPパケットはどうなるのか？」
tracerouteは、宛先ホストに対して「通常は絶対にアプリケーションがリッスンしていないような、極めて高いポート番号（通常は33434から始まる）」宛てのUDPパケットを送信する。
パケットが目的地のサーバーに無事に到着したとする。サーバーのOSは、そのポートで待ち受けているプロセスが「存在しない」ことに気づく。ここで、OSのL4（トランスポート層）スタックが発動する。
「おっと、誰もこのポート番号を聞いていないぞ」
こうして、宛先ホストは送信元（私たちの手元のマシーン）に対して、ICMP Port Unreachable（タイプ3、コード3：Destination port unreachable）というICMPパケットをわざわざ送り返してやるのだ。
tracerouteのプログラムは、この ICMP Port Unreachable を受信した瞬間、こう理解する。
*「よし、パケットが無事に目的地のホストまで到達したな。これ以上のホップ探索は終了だ」*
この「意図的にエラーを起こさせて、そのエラー通知をキャッチして生存確認する」というアプローチこそ、ネットワークエンジニアの真骨頂である。正常な通信を成功させることよりも、異常時のエラー応答から真実を導き出す方が圧倒的に多いのが、インフラ運用の現実なのだ。
—
3. シカゴのルーターも裸足で逃げ出す？通信フローのシーケンス
頭の中を整理するために、送信元から宛先ホスト（例：192.0.2.1）までの通信シーケンスを可視化しておこう。
[送信元 (Client)] [ルーター (Hop 1)] [宛先サーバー (Target)]
| | |
|--- (1) IP: TTL=1, UDP DstPort=33434 -------------->| |
| | (TTLが0になったため破棄) |
|<-- (2) ICMP Time Exceeded (Type 11) ---------------| |
| (発信元ルーターのIPが判明) | |
| | |
|--- (3) IP: TTL=2, UDP DstPort=33435 -------------->|--- (4) IP: TTL=1, UDP DstPort=33435 -->|
| | | (ポート33435は閉鎖中)
|<-- (5) ICMP Port Unreachable (Type 3, Code 3) ---------------------------------------------|
| (目的地の到達を検知してトレース終了) |ご覧の通り、宛先に近づくにつれてポート番号は 33434 から 33435、33436 とインクリメントされていく。これは、ネットワーク上に迷子として残っている古いパケットの応答と、現在送信しているパケットの応答を混同（ミスマッチ）させないための、先人たちの泥臭くも素晴らしい知恵である。
—
4. 実務で役立つ！traceroute の実践コマンドとパラメーター
では、実際に現場でどのようにこのコマンドを使い分けるべきか。Linux（iputilsやtracerouteパッケージ）を前提に、実務で使える実践的なコマンドをいくつか紹介しよう。
基本的なUDPトレース
最も標準的な実行方法だ。デフォルトで3回ずつパケットを送り、応答速度（RTT）を計測する。
# api.example.com に対してUDPベースのtracerouteを実行
traceroute api.example.comパケットロスやファイアウォールの裏をかくオプション
インフラの現場では、セキュリティアプライアンス（ファイアウォールやIDS/IPS）がUDPパケットやICMPを冷酷にドロップすることが日常茶飯事だ。そんなときはパラメーターをいじって突破を試みる。
# プローブ（送信パケット）の種類をICMP（ECHO）に変更する（-I）
# ファイアウォールがUDPをブロックしている場合でも、ICMPなら通るケースがある
traceroute -I api.example.com
# 送信元ポートを指定する（-s）や、TCP SYNパケットを使う（-T）
# ※L4のロードバランサーや特定のステートフルインスペクションをバイパスしたい時に有効
traceroute -T -p 443 api.example.com特に最後の -T（TCP SYN Traceroute）は、現代のWeb APIやクラウドインフラ（AWSのALBやGCPのHTTP(S) Load Balancerなど）のトラブルシューティングにおいて必須のテクニックだ。UDPが途中でブラックホール化（無応答）する場合でも、443番ポートへのTCP SYNなら通るというケースは非常に多い。実務ではこちらが主流になりつつあることも覚えておいて損はない。
—
5. コードやスクリプトからネットワークの壁を暴く
ネットワークエンジニアだけでなく、Web APIを設計・運用するアプリケーションエンジニアにとっても、こうしたネットワークの挙動をコードから意識できるかどうかは、フルスタックエンジニアとしての格を分けるポイントだ。
例えば、Pythonでネットワークの疎通や簡単な診断ツール、あるいはヘルスチェッカーを自作する際、低レイヤーのソケット操作を理解していれば、的確なデバッグコードが書けるようになる。
以下は、Pythonで特定のホストのポートに対してソケットを直叩きし、到達性を確認する簡易的なスクリプトの例だ。
import socket
import sys
def check_udp_port(target_host, target_port):
"""
指定されたホストとUDPポートに対してソケット通信を試み、
低レイヤーのエラーハンドリングを行うサンプル関数
"""
# IPv4 (AF_INET) と UDP (SOCK_DGRAM) のソケットを作成
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
# タイムアウトを2秒に設定（無限ブロックを防ぐインフラの基本）
sock.settimeout(2.0)
try:
print(f"[*] 診断開始: {target_host} の UDPポート {target_port} へ送信中...")
# ダミーデータを送信
sock.sendto(b"PING_TEST_PAYLOAD", (target_host, target_port))
# 応答の受信を試みる（UDPなので通常は返ってこないか、Port Unreachableが返る）
data, addr = sock.recvfrom(1024)
print(f"[+] 応答を受信しました: {addr} から {len(data)} バイト")
except socket.timeout:
# タイムアウトした場合（ファイアウォールでドロップされている可能性が高い）
print("[-] タイムアウトしました: パケットが破棄されたか、応答がありません（ブラックホールの可能性）。")
except ConnectionRefusedError:
# OSがICMP Port Unreachableを検知して例外として拾える場合
print("[+] 目的地のポートは閉じられています (ICMP Port Unreachable を検知)。ホストは生存しています。")
except Exception as e:
print(f"[!] 予期せぬエラーが発生しました: {e}")
finally:
sock.close()
if __name__ == "__main__":
# テスト実行用のコード（例：ローカルの適当なポート）
target = "127.0.0.1"
port = 33434
check_udp_port(target, port)このコードを実行すると、対象ポートが開いていなければ ConnectionRefusedError を捕捉できたり、完全にドロップされていればタイムアウトしたりと、OSのネットワークスタックが裏側で何を受け取っているのかが手に取るようにわかるはずだ。
—
シニアからの最後のメッセージ
「なぜこのパケットはここで消えたのか？」
「なぜこのタイムアウトが発生するのか？」
障害対応の現場において、勘や思い込みで動くエンジニアはすぐに壁にぶつかる。だが、パケットがどのようなルールで生まれ、ルーターにどう処理され、どんなエラーメッセージを連れて帰ってくるのかを頭の中で正確にトレースできるエンジニアは、どんな大規模障害が起きたって慌てない。
traceroute が何気なく吐き出す * * * の向こう側には、ファイアウォールのポリシーがあり、ルーターのルーティングテーブルがあり、そしてネットワークのロマンが詰まっている。
さあ、コーヒーを飲み干したら、次のインシデントに向かうとしよう。君のパケットに、良質なルーティングがあらんことを。
コメント