パケットの墓場を覗く：Linux traceroute (UDP版) が奏でる死のワルツと、境界防御の深層
深夜3時、アラートが鳴り響く。某メガリージョンのデータセンター間を結ぶ専用線で、突如としてレイテンシーが跳ね上がり、一部のマイクロサービス間通信がタイムアウトを起こしている。こんな修羅場で、私たちは無意識のうちにターミナルを開き、指先が勝手にひとつの呪文を叩き出す。
traceroute
画面に流れるアスタリスクの群れ。ルーティングループか、それともBGPの収束遅延か。私たちは普段、このコマンドを「経路を暴く便利なオラクル」程度にしか思っていないかもしれない。だが、シニアエンジニアとして幾百もの夜を越えてきた者なら知っているはずだ。この何気ないコマンドの背後には、OSI参照モデルの限界を逆手に取り、ネットワークの暗部を暴くための、実に見事で、かつ泥臭いハックが隠されていることを。
今回は、Unix/Linux標準のUDPベース traceroute が、いかにしてパケットを迷宮の奥深くへと送り込み、そしていかにしてその最期を看取るのか。そのパケットレベルの内部挙動から、現代のファイアウォール環境における運用の罠まで、徹底的に解剖していこう。
—
1. 宛先ポートの罠：なぜ「使われていない高位ポート」を叩くのか？
私たちが普段何気なく実行するLinuxの traceroute（iputilsやinetutilsパッケージに含まれる伝統的な実装）は、デフォルトでUDPを使用する。ICMP Echoを使うのは、多くの場合 ping か、あるいは traceroute -I を明示的に叩いたときだけだ。
では、UDP版 traceroute は、宛先ホストのどのポートを狙っているのだろうか？
答えは、33434 から始まるエフェメラル領域に近い高位ポート群である。
# デフォルトの挙動で宛先ホストへtracerouteを実行し、パケットの挙動を観察する
$ traceroute -n 192.168.100.1このコマンドがバックグラウンドで何をしているかというと、宛先IPアドレスのポート 33434（ホップが進むごとにポート番号はインクリメントされる）に向けて、ペイロードの乗ったUDPデータグラムを射出している。
なぜ、あえて「サービスが稼働していない可能性が極めて高いポート」を狙うのか？ 理由は明快だ。宛先のOSに「そんなポートは開いてないよ」と、明確に怒鳴り返させるためである。
もし、運悪く（あるいは運良く）その宛先ポートで何らかのアプリケーションがデーモンとして待ち受けていた場合、パケットは受理され、UDPの正常な応答（あるいは無視）が返ってきてしまい、tracerouteのセッションが狂ってしまう。意図的に閉じたポート、あるいは誰もリスニングしていないポートを叩くことで、レイヤー4のトランスポート層における「異常系レスポンス」を意図的に引き起こしているのだ。
—
2. TTLのカウントダウンとICMPの悲鳴：パケットのライフサイクル
tracerouteのアルゴリズムの美しさは、IPヘッダーの TTL (Time To Live) フィールド、あるいはIPv6における Hop Limit の巧妙なハックにある。
パケットが辿るライフサイクルを、パケットキャプチャの視点で追ってみよう。
1. 第1波 (TTL=1):
送信元から発射されたUDPパケットのTTLは 1 に設定される。ルーターA（最初のホップ）に到達した瞬間、ルーターは自身のルーティングテーブルを見る前に、まずTTLをデクリメントする。1 - 1 = 0。ここでTTL切れが発生する。
ルーターAはパケットを破棄し、送信元IPアドレス宛てに ICMP Time Exceeded (Type 11, Code 0: Time-to-live exceeded in transit) というお叱りのメッセージを送り返す。これで、第1ホップのIPアドレスが特定される。
2. 第2波 (TTL=2):
今度はTTLを 2 にして発射する。ルーターAを無事に通過し（TTL=1になる）、ルーターBに到達したところでTTLが尽きる。ルーターBから再び ICMP Time Exceeded が返ってくる。これで第2ホップが判明する。
3. 終着点 (TTL=N):
パケットがついに宛先ホストに到達する。宛先ホストはパケットを受理し、トランスポート層（UDPレイヤー）で該当ポートをスキャンする。当然、そんなポートで待ち受けているプロセスはない。
OSのネットワークスタック（Linuxカーネルであれば net/ipv4/udp.c あたり）は、受信したUDPパケットに対し、ICMP Destination Unreachable (Type 3, Code 3: Port Unreachable) を生成し、送信元へ送り返す。
この ICMP Port Unreachable こが、「これ以上ホップを進める必要はない、宛先に到達した」というtracerouteにとっての終了フラグなのだ。
—
3. カーネルの内部挙動とソケットプログラミングの視点
インフラエンジニアであれば、この一連の動作がLinuxカーネル内部でどのように処理されているかを知っておくべきだ。Pythonなどの低レイヤーソケットを触る際にも非常に役に立つ知識である。
以下は、UDPを用いた簡易的なtracerouteの核心部分を概念的に示すPythonコードの断片だ。OSのソケットオプションを操作し、TTLを動的に変更しながらパケットを投げる挙動を再現している。
import socket
import struct
import sys
def simple_udp_traceroute(dest_ip, max_hops=30):
dest_port = 33434 # tracerouteのデフォルト開始ポート
for ttl in range(1, max_hops + 1):
# 1. 送信用ソケットの作成 (IPv4, UDP)
send_socket = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
# 2. IPヘッダーのTTL（またはHop Limit）を設定する極めて重要なステップ
send_socket.setsockopt(socket.SOL_IP, socket.IP_TTL, ttl)
# 3. 受信用ソケット（ICMPを受信するため）の作成
recv_socket = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_ICMP)
recv_socket.settimeout(2.0) # 2秒でタイムアウト
recv_socket.bind(("", dest_port)) # 自ホストのポートにバインド
try:
# 狙った宛先のエフェメラルポートへダミーデータを送信
send_socket.sendto(b"X" * 32, (dest_ip, dest_port))
# 応答の待ち受け
while True:
packet, addr = recv_socket.recvfrom(1024)
# 実際には、受信したICMPパケットのペイロードをパースし、
# どのセッションに対するエラーかを厳密に突き合わせる必要がある
print(f"TTL {ttl}: 応答元 -> {addr[0]}")
break
except socket.timeout:
print(f"TTL {ttl}: * (タイムアウト)")
break
finally:
send_socket.close()
recv_socket.close()
dest_port += 1
if __name__ == "__main__":
# 実務での検証時は適切な宛先を指定すること
# simple_udp_traceroute("8.8.8.8")
passこのコードが示す通り、tracerouteは単にパケットを投げるだけでなく、生ソケット（Raw Socket）を使って非同期に飛んでくるICMPパケットを待ち受け、タイマーと突き合わせるという、なかなかに泥臭い処理をユーザー空間で行っている。
—
4. 現代のネットワークインフラにおける「壁」と運用の落とし穴
さて、ここまで教科書的（かつ本質的）なUDP tracerouteの仕組みを解説したが、現場のシニアエンジニアとして声を大にして言いたい。
「現代のインターネットやモダンなデータセンターにおいて、この純粋なUDP tracerouteは、しばしば使い物にならない」
なぜか？ セキュリティ上の理由から、あらゆる境界防御がこの仕組みの裏をかいているからだ。
1. ステートフル・ファイアウォールとIDS/IPSによる遮断
多くの次世代ファイアウォール（NGFW）やクラウドのセキュリティグループは、見知らぬ高位ポート（33434番台など）宛てのUDPパケットを「スキャン行為」とみなしてドロップする。また、ルーティング機器自体が、コントロールプレーン保護（CoPP: Control Plane Policing）の一環として、 ICMP Time Exceeded の生成レートを厳しく制限（Rate Limit）している。
結果として、途中のルーターが応答を返さず、画面には延々と * * * が並ぶ「ステルスホップ」が完成する。
2. ECMP（Equal-Cost Multi-Path）の悪夢
現代のデータセンターファブリック（Closトポロジなど）では、同一宛先へのトラフィックを複数のパスに分散させるためにECMPが多用される。
UDP版tracerouteは、ホップごとに宛先ポート番号（33434, 33435, 33436…）をインクリメントしていく。これが何を意味するか？ パケットごとにL4のハッシュ値が変わるため、ホップごとに異なる物理・論理パスを通ってしまう可能性があるのだ。
「あれ？ ルートAを通ったはずなのに、次のホップで急に全然違うデータセンターの機器が現れたぞ？」という現象が起きるのは、大抵このECMPによるハッシュ値の変動が原因である。経路の診断をしているついでに、自分で自らのパケットの道をかき乱しているという皮肉な状況が生まれる。
—
5. シニアエンジニアが実践する、次世代の診断戦略
こうした現代的な障壁を突破し、真のネットワークの姿を捉えるために、私たちはUDP tracerouteから派生した、より洗練されたツールやオプションを使い分ける必要がある。
ICMP版 / TCP版 tracerouteへの切り替え
もし通常のUDP tracerouteが途中で星（*）に阻まれるなら、プロトコルを変更する。
- ICMP版 (
traceroute -I):
宛先に向かってICMP Echo Requestを飛ばす。ファイアウォールがICMPを許可している環境であれば、UDPよりもクリーンな経路が見えることが多い。
- TCP版 (
traceroute -Tまたはtcptraceroute):
企業の厳重なファイアウォールでも、多くの場合 TCP 80 (HTTP) や TCP 443 (HTTPS) は空いている。あえて TCP SYN パケットを特定のWebポートに向けて発射し、SYN-ACK または RST が返ってくるまでのホップを測定する。これならば、実際のアプリケーション層の通信経路を極めて高精度にシミュレートできる。
# 443番ポートをターゲットにしたTCP SYN tracerouteの例（Linux iputils）
$ traceroute -T -p 443 target.example.comパケットのペイロードサイズとMTUの考慮
さらに踏み込んだトラブルシューティング、例えば「特定のサイズ以上のパケットだけが途中でドロップする（MTUパスディスカバリーの失敗）」といった現場では、tracerouteのパケットサイズを明示的に指定して実行する。
# パケットサイズを1400バイトに指定してUDP tracerouteを実行
$ traceroute -M 1400 192.168.100.1これにより、巨大なフレームがどのルーターのインターフェース（MTUの小さなトンネルなど）で破棄されているかをピンポイントで暴くことができる。
—
結びにかえて
ネットワークのパケットは、私たちが目に見えないサイバー空間のシルクロードを、コンマ数ミリ秒の間に何千、何万と駆け抜けている。その一瞬の営みの中で、TTLが尽き、ルーターが静かに ICMP Time Exceeded を送り返すという一連のメカニズムは、枯れた技術でありながら、実にエレガントな工学的美しさを秘めている。
CLIの画面に現れる * の文字にイライラさせられる夜もあるだろう。しかし、そのパケットがどのポートを叩き、どのカーネルレイヤーで処理され、どのようなポリシーに阻まれているのかを脳内で正確にトレースできるようになったとき、障害はもはや「恐怖の対象」ではなく、解き明かすべき「美しいパズル」へと変わる。
さあ、ターミナルに戻ろう。次のパケットが君を待っている。
コメント