ICMPの死角を突け：TCP tracerouteで紐解く「見えない」ネットワークの深層
データセンターの深夜、アラートが鳴り響く。監視システムは特定のセグメントで断続的なパケットロスを告げているが、標準的な traceroute を打っても、中継ノードから返ってくるのは虚しい「* * *」の羅列だ。
セキュリティポリシーによるICMPの遮断。これは現代の堅牢なインフラにおいて、ある種「当然の教養」となっている。しかし、トラブルシューティングの現場では、この「当然」が我々の視界を奪う最大の障壁となる。
今日は、教科書的なツールを卒業し、TCP SYNパケットを武器に、フィルタリングの裏側を覗き見る高度な経路診断の世界を深掘りしよう。
なぜ、ICMP/UDPのtracerouteは「盲目」なのか
標準的な traceroute は、デフォルトでUDP（Linux系）またはICMP（Windows系）を使用する。これらは「宛先ポートが閉じていれば ICMP Port Unreachable を返す」という挙動を前提にしている。しかし、ファイアウォール（FW）やロードバランサーがこれをドロップする設定であれば、パケットはブラックホールに消える。
ここで我々が活用すべきは、tcptraceroute や hping3 といったツールを用いた「TCP SYNによる経路探索」だ。これは、実際のトラフィックに近い振る舞いをさせることで、ポリシーの隙間をすり抜ける手法である。
tcptraceroute を使った実戦的アプローチ
単にパケットを送るだけではない。重要なのは、ターゲットの「開いているポート」に対してSYNを送ることだ。
# TCP SYNパケットを宛先80番ポートへ送信（デフォルトは80）
# --tos 0x10 は低遅延（Minimize-Delay）を要求するフラグ
sudo tcptraceroute -f 1 -m 30 -p 80 192.0.2.1このコマンドが優れているのは、対象のポートがオープンであれば SYN/ACK が返り、経路上のFWが透過を許可していれば、そのプロセスが可視化される点だ。もし途中のルータが TTL Exceeded を返せば経路が特定でき、もしファイアウォールでブロックされていれば、どこで SYN が沈黙したかが明確になる。
パケットレベルで紐解く「接続の最適化」
ここで、単なる診断に留まらない「インフラエンジニアの視点」を加えよう。tcptraceroute で経路を確認する際、対象がTLS終端を行っているのか、あるいはTCPの握手段階でどの程度のRTT（Round Trip Time）が発生しているかを意識する必要がある。
特に、TCPの SYN 送出時に TCP Window Scale や Selective Acknowledgement (SACK) が有効な環境であれば、経路上のミドルボックスがこれらのオプションを書き換えていないか（あるいはパケットをドロップしていないか）を疑うべきだ。
TCPバッファチューニングのヒント
診断中にRTTの揺らぎが激しい場合、ホスト側のカーネルパラメータがボトルネックになっている可能性がある。
# sysctlでのTCPバッファチューニング例
# ネットワーク帯域が広く、遅延が大きい場合はバッファを拡大する
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# TCP SACKを有効にして再送効率を向上させる
net.ipv4.tcp_sack = 1フィルタリング回避の「奥の手」：TCPオプションの活用
多くのFWは、単なるSYNパケットには厳しいが、特定のフラグセットには寛容な場合がある。hping3 を使用すれば、さらにディープなパケット操作が可能だ。
# SYNパケットを特定のポート(443)に送信しつつ、シーケンス番号やフラグを細工する
# --syn はSYNフラグのみを立てる
# --keep-ttl はTTLを固定してホップによる変化を追跡する
sudo hping3 -S -p 443 --ttl 64 192.0.2.1また、あえて偽装した TCPオプション を付与することで、ステートフル・インスペクションを通過するケースもある。例えば、MSS (Maximum Segment Size) の値をあえて小さく設定することで、断片化を避けて検閲システムを回避するという、「泥臭い」テクニックも存在する。
現場の知見：その「パケットロス」は本物か？
シニアエンジニアとして最後に一つだけ警鐘を鳴らしたい。
「tracerouteで確認した途中のルータでのロス」が、必ずしもサービス障害の原因とは限らない。多くのコアルータは、コントロールプレーンの保護のために、ICMPの処理優先度を極めて低く設定している。
パケットが捨てられているのではなく、ルータが「後回し」にしているだけかもしれない。
真に重要なのは、tcptraceroute を通じて、目的のポートへの SYN/ACK がどの程度の遅延で返ってくるかという「エンド・ツー・エンドのパフォーマンス」だ。経路上のノードがどう振る舞うかよりも、最終的なTCPハンドシェイクが確立されるまでの「時間」と「確率」。これこそが、我々が守るべきサービスの品質そのものなのだ。
技術は進歩し、ネットワークは抽象化される。しかし、パケットは嘘をつかない。今日もまた、CLIと向き合い、レイヤー4の深層からインフラの真実を読み解いていこうではないか。
コメント