こんにちは！NOC（ネットワークオペレーションセンター）で日々、パケットの荒波と格闘しているシニアエンジニアです。
データセンターの深夜、突然鳴り響くアラート。「おい、海外のクラウドサーバーに繋がらなくなったぞ！どこでパケットが迷子になってるんだ？」――そんな修羅場を、私たちは幾度となくくぐり抜けてきました。
ネットワークの調子が悪いとき、まず最初に叩くコマンドといえば何でしょうか？ そう、おなじみの ping や traceroute ですよね。「目的地までちゃんと届いているか」「途中のどのルーター（中継地点）で止まっているか」を調べるための、いわばネットワークエンジニアの「聴診器」です。
でも、ちょっと待ってください。
現場でバリバリ働いていると、こんな壁にぶつかりませんか？
「あれ？ traceroute を打っても、途中のルーターが全然返事をしてくれなくて、宛先の直前まで『* * *』で真っ暗なんだけど……」
そうなんです。現代のインターネットは、セキュリティ（ファイアウォール）がガチガチに固められています。そのため、昔ながらの「普通の traceroute」だと、途中の門番に門前払いを食らってしまい、正確な経路が見えないことがよくあるのです。
そんな「困った！」を鮮やかに解決してくれるのが、今回ご紹介する tcptraceroute（TCPベースのトレーサーウト） という高度な診断手法です。
今回は、パケットの気持ちになりながら、ファイアウォールの裏側をスルスルとすり抜けるその仕組みを、身近な例えを交えながら一緒に優しく紐解いていきましょう！
—
1. 郵便配達で例える「普通のtraceroute」の限界
まずは、普段私たちがよく使う traceroute が、裏側でどうやって動いているのかを「郵便配達」に例えておさらいしてみましょう。
traceroute は、手紙（パケット）の寿命（TTL：Time To Live という「あと何回中継地点を渡っていいか」のカウンター）を最初は「1」にして送り出します。
1. 寿命「1」の手紙を出す：
すぐ隣の郵便局（ルーターA）に着いた瞬間、寿命が「0」になり、郵便局員が「おっと、寿命切れだ！」と気づいて、あなたのもとに「ここで寿命が切れましたよ」というお返事を送り返してくれます。これで「最初のルーターの住所」が分かります。
2. 寿命「2」の手紙を出す：
今度はルーターAを通過し、次の郵便局（ルーターB）で寿命が「0」になります。ルーターBからお返事が返ってくるので、「2番目のルーターの住所」が分かります。
3. これを繰り返して、目的地までの地図を完成させます。
とってもスマートですよね。しかし、ここで大きな問題が発生します。
多くの企業やクラウドのファイアウォール（門番）は、「見ず知らずの人から送られてくる、変なUDPパケットやICMPパケットなんて怪しいから、全部ゴミ箱に捨てちゃおう！」 という厳しいルールを設定しています。
そのため、私たちが「おーい、生きてますかー？」と投げたパケットが途中の門番にバッサリとブロックされてしまい、宛先までたどり着けない（あるいは途中の経路が見えなくなる）という現象が起きてしまうのです。
—
2. ファイアウォールを欺く「tcptraceroute」の clever な仕組み
「じゃあ、門番が絶対に追い返せないパケットを使えばいいんじゃないか？」
そう考えて生まれたのが tcptraceroute です。
ウェブサイトを見るための通信（HTTPやHTTPS）に使われる TCP というプロトコルを思い出してください。インターネットの世界では、Webサーバーの 80番ポート や 443番ポート は、世界中に公開されていなければいけない「開かれた正面玄関」です。
ファイアウォールも、Webサイトを見に来る正当な通信（TCPパケット）までは完全に遮断できません。もし遮断してしまったら、誰もそのサイトを見られなくなってしまいますからね。
tcptraceroute は、この仕組みを逆手に取ります。
- 普通のtraceroute：怪しまれやすいUDPやICMPという種類のパケットを使う。
- tcptraceroute：Webサーバーに向かうふりをした 「TCP SYNパケット（通信の最初にお願いする挨拶のパケット）」 を使う。
ファイアウォールから見れば、それは「ただのWebサイトへのアクセス要求」に見えます。そのため、門番は疑うことなくスルスルと通してしまうのです。「お、この手紙なら正面玄関宛てだし、通してやろう」というわけですね。
こうして、途中の厳重なセキュリティ網をまるで忍者のようにすり抜けながら、目的地までの正確な経路と、目的地のポート（例: 443 番）が本当に開いているかまで同時にチェックできてしまう。これが tcptraceroute の正体です。
—
3. 実践！ tcptraceroute を使ってみよう
百聞は一見に如かず。実際にLinux環境などでこのコマンドを使ってみましょう。
（※多くのディストリビューションで sudo apt install tcptraceroute などで簡単にインストールできます）
基本的なコマンドの書き方はとてもシンプルです。今回は例として、あるウェブサーバーの 443 番ポート（HTTPS）に向けて経路を調査してみます。
# 宛先サーバー（example.com）の443番ポートに対してTCPベースで経路をトレースする
sudo tcptraceroute example.com 443実行すると、次のような出力が画面に流れます（出力イメージ）。
Selected device eth0, IP 192.168.1.50
Using TCP port 443, seq 1234567890, ack 0
1 gateway (192.168.1.1) 1.234 ms 1.102 ms 0.985 ms
2 10.100.0.1 (10.100.0.1) 5.432 ms 5.210 ms 5.198 ms
3 * * *
4 core-router-tokyo.net (203.0.113.50) 12.450 ms 12.310 ms 12.110 ms
5 example.com (93.184.216.34) [open] 14.200 ms 14.150 ms 14.120 ms出る杭は打たれる？ 途中の * * * の意味
おや、3行目が * * * になっていますね。「おや、ここでパケットが消えた？」と焦る必要はありません。
これは、途中のルーター（あるいはセキュリティ機器）が「経路の途中で寿命を迎えたパケット（TTL切れ）」に対して、親切にお返事を返す機能をあえてオフにしている（あるいはファイアウォールで捨てている）ためです。
でも、安心してください。4行目や 5 行目を見てみると、しっかりと先のルーターや最終目的地からの返信が帰ってきていますよね。
特に最後の行に [open] と表示されていることに注目してください。これは 「宛先のサーバーの443番ポートがちゃんと開いていて、通信を待ち構えている状態ですよ」 ということを示しています。もしポートが閉まっていれば [closed] や別の応答になり、ファイアウォールに完全にブロックされている場合は [filtered] と表示されます。
これ一本で、「経路の確認」と「ポートが開いているかの生死確認（ポートスキャン的な要素）」が同時にできるのは、現場のエンジニアにとって本当に強力な武器なんです。
—
4. トラブルシューティングでの実践的な活用シーン
現場で tcptraceroute が真価を発揮するのは、次のような「嫌な汗をかく瞬間」です。
1. 「特定のAPIサーバーにだけ繋がらない」という問い合わせ
社内ネットワークやクラウドのセキュリティグループ（ファイアウォール）の設定ミスが疑われるとき、どのレイヤー（どのルーターやセキュリティアプライアンス）でパケットが落とされているのかを特定できます。
2. ロードバランサーやプロキシの挙動確認
途中に負荷分散装置（LB）が入っている場合、通常の ping では見えない「特定のTCPポートに対するルーティングの偏り」や「途中のルーティングループ」を見つけ出すことができます。
実務で役立つちょっとしたコツ
もし、デフォルトの 443 番や 80 番ポートへの通信がファイアウォールで完全に禁止されているような、超ウルトラセキュアな環境にいる場合は、「相手が必ず開けていそうなポート（例えばDNSの 53 番や、社内で許可されている特定のTCPポート）」 にターゲットを変更して実行してみるのもテクニックの一つです。
# 宛先サーバーの53番ポート（DNS等）を指定してトレースする例
sudo tcptraceroute target-server.internal 53—
まとめ
いかがでしたでしょうか？
今回は、TCPベースのトレーサーウトである tcptraceroute の仕組みと、ファイアウォールをすり抜けるスマートな挙動について解説しました。
- 普通の
tracerouteは、途中の門番にブロックされやすいUDPやICMPを使う。 tcptracerouteは、Web閲覧などで使われる「正面玄関を通るTCPパケット（SYN）」を使うため、ファイアウォールの目をかいくぐりやすい。- 経路の確認だけでなく、目的地のポートが開いているかどうかも同時にチェックできる優秀な診断ツール。
インフラやネットワークの世界は、目に見えないパケットの動きを想像することが第一歩です。「なぜこのパケットは通るのか」「なぜここで阻まれるのか」を頭の中でイメージできるようになると、トラブルシューティングが何倍も楽しく、そしてスピーディーになりますよ。
日々の運用監視や、いざという時の障害切り分けの引き出しとして、ぜひ今日の知識を役立ててみてくださいね。それでは、また次回のNOCブログでお会いしましょう！
コメント