「宛先不明の郵便物」が教えてくれるネットワークの地図:UDP tracerouteの仕組みを紐解く
ネットワークエンジニアの現場で、真っ先に叩き込まれる魔法のコマンドがあります。そう、traceroute です。
「ネットワークが遅い」「どこかのルーターでパケットが止まっている気がする」。そんな不安を抱えたとき、私たちはこのコマンドを打ち込みます。画面に次々と表示されるIPアドレスの羅列を見ながら、「よし、ここまでは来ているな」「おっと、ここで応答が遅れているぞ」と状況を判断するわけです。
でも、ふと立ち止まって考えてみてください。「なぜ、ただパケットを投げただけで、途中の機器が律儀に自分の名前を名乗ってくれるのか?」 と。実はこれ、かなり「泥臭い」仕組みで動いているんです。
今日は、教科書的な説明を飛び越えて、現場の泥臭い視点から「UDP tracerouteのからくり」を解き明かしていきましょう。
—
ネットワークという名の「巨大な郵便局」
パケットを届ける作業は、郵便配達に似ています。
traceroute は、宛先(最終目的地のサーバー)までの道のりを調べるために、わざと「少し変わった郵便物」を送り出します。
通常、私たちがWebサイトを見るような通信では、80番や443番といった、明確な「窓口(ポート番号)」を指定して手紙を送ります。受け取る側も「はい、どうぞ」と受け取ってくれますよね。
しかし、traceroute が使うのは、あえて「誰も使っていないような、非常に大きな番号のポート(例えば33434番以降)」です。
郵便配達で例えるなら…
1. あなたは宛先に「誰もいないはずの部屋番号」を書いた手紙を送ります。
2. 途中のルーターは、手紙を中継しながら「あと何回転送できるか(TTLという寿命)」をカウントダウンします。
3. 最後にその手紙を受け取ったルーターは、「えっ、こんな番号の部屋はないよ!」と困惑します。
4. そこでルーターは、差出人のあなたに対して「宛先不明(ICMP Port Unreachable)」という、お詫びの返信を送り返してくるのです。
この「お詫びの返信」こそが、traceroute の正体。これを受け取ることで、私たちは「ああ、ここまではパケットが届いたんだな」と確信できるというわけです。
—
実践:コマンドで動きを追ってみよう
まずは、実際に traceroute(Windowsなら tracert)を打ったときの様子をイメージしてみましょう。
# Linux環境でのtraceroute実行例
# 宛先サーバーに対してUDPパケットを送り込みます
traceroute 8.8.8.8
# 出力イメージ:
# 1 192.168.1.1 0.5ms
# 2 10.0.0.1 1.2ms
# 3 * * * (タイムアウト)
このとき、裏側ではこんなやり取りが行われています。
- TTL(Time To Live)の調整: 最初は「寿命1」のパケットを投げ、1つ目のルーターに「寿命切れだよ!」と返させる。次は「寿命2」にして、2つ目のルーターに返させる。これを繰り返して地図を作ります。
- ポート番号の指定: 意図的に誰も待ち受けていない高いポート番号を指定することで、最終地点に到達した際に確実に「ポート到達不能エラー」を返させ、終了フラグを立てるのです。
—
なぜ「わざとエラー」を起こす必要があるのか?
「ちゃんと通信できるポートを使えばいいのに、なんでエラーを使っているの?」と疑問に思うかもしれません。
答えはシンプルで、「相手が誰であれ、エラーを返してもらうことが一番の目印になるから」です。
もし、相手が正常なサービスポート(80など)で待ち受けていたら、サーバーは「おっと、通信開始の挨拶かな?」と勘違いして、本来の通信プロセスを開始しようとしてしまいます。これでは通信負荷がかかりますし、何より「到達確認」のための純粋な通知が得られません。
「宛先不明です!」というエラーメッセージは、ネットワークの世界では「ここまでは確実に届きましたよ」という最も信頼できる証明書なんです。
—
現場のシニアエンジニアから、最後にひとこと
現場で障害対応をしていると、traceroute がすべてではないことに気づかされます。
- ファイアウォールの壁: セキュリティが厳しい環境では、この「エラー通知」そのものを無視(ドロップ)するように設定されていることがあります。
tracerouteで結果が返ってこないからといって、必ずしもネットワークが切れているとは限らないのです。 - 非対称経路: 行きと帰りで通る道が違うことも珍しくありません。
tracerouteはあくまで「パケットがどのようなエラーを返してきたか」という片道切符の情報を積み上げたものだと理解しておくことが大切です。
「パケットがなぜエラーを返してくるのか?」「そのエラーの中に何が隠されているのか?」。
この視点を持てたとき、コマンドの黒い画面が、ただの文字の羅列から、パケットが駆け巡るリアルな「生き物」の姿に見えてくるはずです。
一歩ずつで構いません。まずは手元の端末で traceroute を打ち、返ってくるICMPエラーの物語を想像してみてください。それこそが、凄腕エンジニアへの第一歩ですよ!
コメント