皆さん、こんにちは！NOC（ネットワークオペレーションセンター）で日々、張り巡らせたケーブルとパケットの奔流に向き合っているシニアエンジニアです。
データセンターのフロアでうなる冷却ファンの轟音を聞きながらコーヒーをすする時、私の頭の中ではいつも、目に見えないパケットたちがどこかのルーターを飛び交い、ファイアウォールの門を叩く姿がイキイキと描かれています。
ネットワークの仕事をしていると、避けて通れないのが「あれ、なんでこのサーバーに繋がらないんだ？」というトラブルですよね。そんな時、私たちの相棒になってくれるのが traceroute というコマンドです。
「宛先までの経路を調べるコマンドでしょ？知ってるよ！」という方も多いかもしれません。でも、この traceroute がパケットを送り出すとき、裏側でどんなドラマが繰り広げられているか、そしてセキュリティの門番である「ファイアウォール」に阻まれたとき、彼らがどんな悲鳴を上げているか、気になったことはありませんか？
今回は、traceroute のポート番号の秘密と、ファイアウォールによるブロックをどうやって見破るのか、身近な例えを交えながら一歩ずつ紐解いていきましょう！
—
1. traceroute は「お手紙リレー」の冒険者
まずは、traceroute が普段どんな風に動いているのか、おさらいしておきましょう。
ネットワークの世界を「巨大な郵便配達システム」に例えてみてください。あなたが東京から大阪の友達へ手紙を出します。手紙はいくつかの郵便局（ルーター）を経由して届けられますよね。
traceroute は、まさにこの「経由地」を一つずつ暴き出すための冒険者です。彼はこんな作戦を使います。
1. 寿命（TTL: Time To Live）を「1」にした手紙を出す
- この手紙は、最初の郵便局（すぐ隣のルーター）に着いた瞬間、「あ、寿命が尽きちゃった！」ということで、郵便局員さんから「宛先まで届きませんでしたよ」というお返事（エラー通知）が送り返されてきます。これで「最初の経由地」が分かります。
2. 次は寿命を「2」にして出す
- 今度は2つ目の郵便局まで進み、そこで寿命が切れて「お返事」が返ってきます。これで「2番目の経由地」が判明します。
3. これを繰り返して、ついに宛先まで到達させる！
この仕組み、シンプルでとてもよくできていますよね。
—
2. なぜポート番号を気にする必要があるの？
さて、ここからが今回の本題です。traceroute が発射する「手紙」には、実は宛先の「部屋番号（ポート番号）」が書き込まれています。
通常、Linuxなどで使われる標準的な traceroute は、誰も使っていなさそうな「UDPの33434番以降」のポート番号めがけて手紙を投げます。一方で、Windowsの tracert は、ICMPという別の仕組みを使ったりします。
ここで想像してみてください。
あなたがとあるマンション（サーバー）の、特定の部屋（例えばWebサーバーなら 80 番や 443 番）宛てに手紙を出そうとしています。しかし、セキュリティが非常に厳しいマンションの場合、管理人のような存在、つまりファイアウォールがこう言います。
「なんだこの変な番号（UDP 33434番など）宛ての手紙は！うちのマンションの住民に関係ない怪しい訪問者は、ぜんぶゴミ箱行きだ！」
こうなると、パケットは途中でファイアウォールにバッサリと切り捨てられてしまい、先へ進めなくなります。これが、ネットワークの世界でよくある「ファイアウォールによるブロック」の正体です。
—
3. ファイアウォールにブロックされると、画面はどうなる？
では、実際にファイアウォールにブロックされたパケットがどうなるのか、コマンドの出力結果を見てみましょう。
例えば、セキュリティがガチガチに固められたサーバーに対して、通常の traceroute を実行したとします。
$ traceroute target-server.example.com
traceroute to target-server.example.com (203.0.113.50), 30 hops max, 60 byte packets
1 gateway.local (192.168.1.1) 1.120 ms 1.050 ms 0.980 ms
2 router-isp.net (10.200.0.1) 5.430 ms 5.210 ms 5.100 ms
3 * * *
4 * * *
5 * * *おっと、途中のルーターまでは順調（1番目、2番目）に返事が返ってきていたのに、3番目以降がすべて * * * （タイムアウト）になってしまいました！
教科書やネットの記事だと「あぁ、途中のルーターが調子悪いのかな？」と思いがちですが、現場のシニアエンジニアの勘としては、「おっ、向こうのファイアウォールが私たちのUDPパケットをシカト（ドロップ）し始めたな」とピンと来ます。
ルーターが意図的にパケットを「無視」するように設定されている場合、traceroute はお返事を待ちぼうけすることになり、アスタリスク（*）の嵐が吹き荒れることになるのです。
—
4. プロトコルとポートを自在に操れ！実践的コマンドテクニック
「じゃあ、ファイアウォールがUDPの33434番をブロックしているなら、どうやって本当の経路や疎通を調べればいいの？」
ここで役に立つのが、tracerouteのポート番号・プロトコル制御機能です！
ファイアウォールは「変なUDPポート」は弾くけれど、「普通のWeb通信（TCPの80番や443番）」は通すように設定されていることがよくあります。
現代のネットワーク診断では、UDPではなくTCPを使ったり、宛先ポートをWebのポートに変更して traceroute を行うのがプロの常道です。
以下に、実務で今すぐ使える実践的なコマンド例をご紹介します。日本語のコメントを参考に、ぜひお手元の環境（※権限や許可されたターゲットでお試しください）でも確認してみてくださいね。
パターンA: TCPのSYNパケットを使ってHTTP（80番ポート）を狙う
# -T オプションでTCPモードにし、-p オプションで宛先ポートを 80 (HTTP) に指定します。
# これにより、Webブラウザが見るのと同じ門を叩いて、ファイアウォールが通してくれるかテストできます。
$ sudo traceroute -T -p 80 target-server.example.comパターンB: より確実なTCP 443番（HTTPS）を狙う
# 暗号化通信（HTTPS）で使われる 443 番ポートを指定します。
# ほとんどの企業のファイアウォールは 443 番を開けているため、ブロックをすり抜けて正確な経路が見えることがあります。
$ sudo traceroute -T -p 443 target-server.example.comパターンC: ICMPモードを使う（お馴染みの方式）
# -I オプションを指定すると、UDPではなくICMP（ECHO REQUEST）を用いたtracerouteになります。
# Windowsの tracert に近い挙動をLinuxでも再現したい時に便利です。
$ sudo traceroute -I target-server.example.com—
5. 現場のエンジニアからのアドバイス：パケットの気持ちになって考えよう
トラブルシューティングの極意は、「自分がパケットになったつもりで、その旅路を想像すること」です。
もしあなたが手紙の配達員だとして、宛先の家にたどり着く前に「その服装（ポート番号）じゃ通せんぼ！」と言われたらどうでしょう？ 服装を変える（ポート番号を変える）か、別のルート（プロトコル変更）を探しますよね。
traceroute は単なる便利ツールではありません。ネットワークという広大な海原に向けて、私たちの代わりに小さな偵察船を飛ばし、向こう側の門番（ファイアウォール）がどういうルールで待ち構えているかを教えてくれる優秀な相棒なのです。
「* が出たからダメだ」と諦めるのではなく、
「お、ここはUDPを弾くけれど、TCPの443番なら通してくれるんだな。ということは、ファイアウォールのポリシーはこうなっているんだな……」
と、一歩踏み込んで解析できるようになると、インフラエンジニアとしてのスキルがぐっと深まりますよ。
さあ、次のトラブルシューティングでは、ぜひポート番号を意識した traceroute を相棒に、ネットワークの奥深くを覗いてみてくださいね。それでは、また次回のNOCルームでお会いしましょう！
コメント