Traceroute InSession: 現代のネットワークのためのTracerouteツール
ファイアウォールとロードバランサーの問題を乗り越える
2024年7月6日
翻訳: 竹洞 陽一郎
この記事は米Catchpoint Systems社のブログ記事「Traceroute InSession: A traceroute tool for modern networks」の翻訳です。
Spelldataは、Catchpointの日本代理店です。
この記事は、Catchpoint Systemsの許可を得て、翻訳しています。
これは以前発表したTraceroute InSessionに関する投稿の続編であり、そこで提供した技術的な詳細について説明しました。
このシリーズでは、InSessionが現代のネットワークで対処する課題を探り、他のTracerouteのバリエーションと比較します。
Catchpointでは、自分たちがTracerouteの専門家であることを誇りに思っています。
なぜなら、過去15年間で150億回以上のTracerouteを実行し、2023年だけで30億回以上を実行したからです！
これらのTracerouteは、世界中のTier1 ISPに接続されたバックボーンロケーション、クラウドおよび無線ロケーション、プライベートネットワーク内のエンタープライズノード、さらにはWorkforce Experienceエージェントを実行しているラップトップから発信されました。
問題の発見
標準的なTracerouteでは、結果はしばしば次のようになります。
これは、Cogent Communicationsに接続されたニューヨークのバックボーンノードからAmazonまでのTCP Tracerouteの例です。
予想通り、Amazonは異なるエッジロケーションからトラフィックを提供するためにCDNを使用しているので、Tracerouteは時間とともに5つの異なる目的地を通過します。
この動作は予期され、正常です。
ファイアウォールの問題
しかし、予期されないことは何でしょうか？
赤い点とすべての交差する線です。
赤い点はパケット損失を示していますが、実際にはインターネットはそれほど壊れていません。
パケット損失ではなく、これはファイアウォールがいくつかのTracerouteパケットをブロックしている結果である可能性が高いです。
これをファイアウォールの問題と呼びます。
経路の問題
すべての交差する線は、非常に複雑なルータートポロジーを示しているように見えますが、実際にはそうではありません。
これを経路の問題と呼びます。
実際、標準的なTracerouteはパケットが通る経路を明らかにすることはできません。
これは非常に直感に反しています。
Tracerouteは経路をトレースするためのものですが、実際にはXホップ先にあるルーターとYホップ先にあるルーターに遭遇したことを教えてくれるだけです。
ルーターが接続されているかどうか、またはその間に何があるかを証明する方法はありません。
経路の問題をさらに説明するために、個々のTraceroute実行結果を見てみましょう。
Traceroute to www.amazon.com (18.164.107.218), 30 hops max 1 gateway (38.101.106.65) [AS 174] 0 ms 0 ms 0 ms 2 * * * 3 te0-0-0-1.ccr31.jfk04.atlas.cogentco.com (154.54.5.177) [AS 174] 1 ms 1 ms 1 ms 4 be3363.ccr42.jfk02.atlas.cogentco.com (154.54.3.125) [AS 174] 2 ms 1 ms 1 ms 5 be3201.rcr52.ewr01.atlas.cogentco.com (154.54.90.62) [AS 174] 2 ms 2 ms 2 ms 6 38.142.215.210 (38.142.215.210) [AS 174] 2 ms 2 ms 2 ms 7 * * * 8 * * * 9 * * * 10 * * * 11 15.230.208.23 (15.230.208.23) 2 ms 2 ms 2 ms 12 15.230.208.23 (15.230.208.23) 2 ms 2 ms 2 ms 13 server-18-164-107-218.jfk50.r.cloudfront.net (18.164.107.218) [AS 16509] 2 ms 2 ms 2 ms
この出力は、Tracerouteがゲートウェイに行き、その後jfk04 Cogentルーター、次にjfk02ルーターなどに行ったことを示していますね？
違います！
実際には、Tracerouteの一つのパケットがゲートウェイを通り、ソースから1ホップ離れていることを発見しました。
別のパケットはjfk04を通り、ソースから3ホップ離れていることを発見しました。
さらに別のパケットはjfk02を通り、ソースから4ホップ離れていることを発見しました。
このように、従来のTracerouteでは各パケットが独立して動作します。
Tracerouteの出力は、各ルーターのソースからの距離を示すだけで、それらが相互に接続されているかどうかは示しません。
もう一つの問題は、単一のTracerouteではすべての可能なルーターが特定されたかどうかが分からないことです。
幸いなことに、Catchpointや他の企業はこの問題をかなり前に解決しました。
各Tracerouteがいくつかのルーターを特定するので、すべてのルーターを見つける唯一の方法は、多くのTracerouteを実行することです。
これが、最初の図が得られた方法です。
各Tracerouteが各ホップで1つのルーターを見つけ、多くのTracerouteを実行してすべてのルーターを見つけたと確信しました。
ファイアウォールと経路の課題をTraceroute InSessionで解決する
私たちは、残っている2つの問題（「ファイアウォール」と「経路」）、つまりファイアウォールが引き起こすいわゆる「パケット損失」と、実際には隣接していないルーターが隣接していると誤認される問題を改善することを目指しました。
そして、成功しました。
その結果、Traceroute InSessionは、上記の例に対して次のような図を作成します。
赤い点がはるかに少なく（この例ではまったくありません！）、非常にクリーンな線で、ルーターが隣接していることを比較的自信を持って示しています。
どうやって？
それについて説明します（そして、書いたコードをオープンソースとして公開したリンクも提供します）が、まずはTracerouteの始まりに戻りましょう。
もし待ちきれないなら、背景を飛ばして解決策に直接飛び込んでください。
まずは、背景を少し掘り下げてみましょう。
Tracerouteの簡単な歴史
Tracerouteは、パケットがIPネットワークを通過する経路を特定し、その経路の性能を評価するための診断ツールとして開発されました。
IPネットワークが登場する前には、Tracerouteは必要ありませんでした。
まあ、もしかしたら存在していたかもしれませんが、その当時のインターネットは非常にシンプルだったため、そのようなツールを必要としませんでした。
例えば、1984年のインターネットはこのようなものでした。
それと比べて、現在のインターネットは以下のようになっています。
多くの複雑さがあり、その複雑さを解読するためのツールが必要になります。
この原則は、私たちの議論の中で繰り返し登場するテーマです。
1980年代には、1974年にVint CerfとBob Kahnによって作成されたインターネットプロトコル（IP）はまだ新しい概念でした。
Pingは、クライアントと目的地の間のレイテンシを測定するために1983年に導入されました。
その後、1988年にVan Jacobsonが有名な「Tracerouteのメール」を書きました。
Date: Tue, 20 Dec 88 05:13:28 PST Received-Date: Tue, 20 Dec 88 05:14:46 PST Received: from heliose.lbl.gov by venera.isi.edu (5.54/5.51) id AA25556; Tue, 20 Dec 88 05:14:46 PST Received: by helios.ee.lbl.gov (5.59/2.1) id AA03127; Tue, 20 Dec 88 05:13:28 PST Message-Id: <[email protected]> To: [email protected], [email protected] Subject: 4850 routing diagnostic tool available for ftp Date: Tue, 20 Dec 88 05:13:28 PST From: Van Jacobson <[email protected]> Content-Length: 2373 X-Lines: 46 Status: RO After a frustrating week of trying to figure out "where the !*#?! are the packets going?", I cobbled up a program to trace out the route to a host. It works by sending a udp packet with a ttl of one & listening for an icmp "time exceeded" message. If it gets one, it prints the source address from the icmp message, then increments the ttl by one & etc. (As usual, I didn't come up with this clever idea -- I heard Steve Deering mention it at an end-to-end task force meeting.)
「パケットは一体どこに行っているんだ？」と考えてフラストレーションの溜まる一週間を過ごした後、ホストへのルートをトレースするプログラムを急ごしらえしました。
このプログラムは、ttlを1に設定したudpパケットを送信し、icmpの「タイムエクシーデッド」メッセージを待ち受けることで機能します。
メッセージを受信すると、icmpメッセージの送信元アドレスを表示し、その後ttlを1ずつ増やしていきます。
（いつものことですが、この賢いアイデアは私が考えたものではなく、Steve Deeringがエンドツーエンドタスクフォースの会議で言及していたのを聞いたものです。）
複雑さのレベルが専門的なツールの作成を必要とするまでに達していました。
Tracerouteはどのように機能するのか？
Van Jacobsonは、1987年に元々のTracerouteをIPのTime To Live（TTL）フィールドを使用して作成しました。
このフィールドは、パケットが通過できる最大のルーター数を指定します。
パケットがルーターを通過するたびに、このフィールドはデクリメントされます。
フィールドが0に達すると、エラーメッセージ（IPv4の場合はICMP TTL Exceeded、IPv6の場合はHop Limit Exceeded）が返送されます。
現代のネットワークはより複雑
Van Jacobsonによって実装された元のアルゴリズムは、今日でも多くのシナリオで機能しますが、現代のネットワークの複雑さにより、このアルゴリズムは適切に機能するために強化する必要があります。
特に、トレーサルートはファイアウォールやロードバランサーに苦労しています。
ファイアウォールの課題
セキュリティは絶え間ない「ネコとネズミのゲーム」です。
各技術革新は悪意のあるアクターによって悪用され、その結果、これらの抜け穴を閉じるためのさらなる革新が行われます。
Tracerouteでも同じことが起こりました。
ICMP Tracerouteは、ICMPメッセージが一般的に診断目的で使用され、アプリケーションデータをほとんど運ばないため、現代のネットワークではしばしば失敗します。
多くのファイアウォールはそれらを完全にブロックします。
同様に、UDPトレーサルートでは、ファイアウォールがそれをアプリケーショントラフィックとして認識しないため、しばしばブロックされます。
Tracerouteを模倣する一般的なUDPアプリケーションはないため、ファイアウォールはパケットをブロックします。
しばらくの間、TCP Tracerouteが解決策とされていました。
なぜなら、すべてのTCP接続は3ウェイハンドシェイクで始まり、ファイアウォールにはアプリケーションデータを確認する手段がないため、SYNパケットが通過することができたからです。
しかし、悪意のあるアクターがSYNフラッドを発見し悪用するようになり、SYNフラッドをブロックするファイアウォールの結果として、TCP Tracerouteも機能しなくなりました。
（もちろん、これはSYNフラッド検出の実装方法やSYNレートのしきい値設定などによります。）
ロードバランサーの課題
インターネットは脆弱です。
その耐障害性を向上させるための技術の一つがロードバランサー、特にリンクロードバランサーです。
この文脈では、ロードバランサーは、パケットの送信先ネットワークではなく、さまざまな他の基準によってパケットを送信する場所を決定する特殊なルーターと見なすことができます。
例えば、コスト関連のポリシーは重要なアプリケーショントラフィックを信頼性のためにより高価なリンクに指示したり、耐障害性の観点からは、プライマリルートが遅すぎる場合にバックアップリンクを経由してトラフィックを再ルーティングするかもしれません。
これらの決定は、次のようなシナリオを引き起こします。
この図を外部の知識なしに見ると、特定のパケットがサーバーに到達するためにどの経路を取るかを知ることは不可能です。
1-2-5かもしれませんし、1-3-4かもしれませんし、1-2-4かもしれません。
ロードバランサーは一般的にフロートラフィックをバランスさせるように構成されています。
特定の経路でTCP接続が確立された場合、ロードバランサーはその接続内のすべてのパケットに対して同じ経路を維持しようとします。
同じ原則がUDPフローにも適用されます。
しかし、Tracerouteでは、「フロー」とは単一のパケットと応答のことを指します。
送信される各プローブは異なる特性を持ち、異なる経路にロードバランスされる可能性があります。
この変動性は非常に奇妙なTracerouteの応答を引き起こす可能性があります。
例えば、上記の図では、ホップ1は常にルーター1になります。
ホップ2はルーター2またはルーター3になり得ます。
ホップ3はルーター4またはルーター5になり得ます。
ホップ4はサーバーです。
したがって、トレーサルートを実行すると、以下のような出力が表示された場合に
1 (ルーター1) 2 (ルーター2) (ルーター3) 3 (ルーター4) (ルーター5) 4 (サーバー)
実際の経路が何であるかをどのように知ることができますか？
例えば、可能なフローとして1-2-4が考えられますが、その経路は存在しないかもしれません。
複雑さへの対応: Traceroute InSessionの紹介
ファイアウォールやロードバランサーによってもたらされる複雑さは、元のTracerouteの有用性を低下させました。
これらの課題に対処するために、CatchpointはTraceroute InSessionを開発し、オープンソース化しました。
Traceroute InSessionの動作についての詳細な説明は、私たちの元のブログ投稿をご覧ください。
以下に簡単な概要を示します。
InSessionは、宛先サーバーへのTCP接続を確立することでTCP接続を模倣し、ファイアウォールを通過させます。
また、単一のTCP接続を使用することで、ロードバランサーは各プローブを同じフローの一部と見なすため、一貫した経路を使用します。
その結果がこちらです。
$ sudo traceroute -T bing.com traceroute to bing.com (13.107.21.200), 30 hops max, 60 byte packets 1 gateway (192.168.1.1) 0.473 ms 0.643 ms 0.627 ms 2 * * * 3 * * * 4 * * * 5 172.19.184.88 (172.19.184.88) 17.826 ms 17.772 ms 17.724 ms 6 172.19.177.10 (172.19.177.10) 17.685 ms 17.109 ms 10.027 ms 7 ae49.milano50.mil.seabone.net (195.22.205.116) 9.707 ms 9.964 ms ae48.milano50.mil.seabone.net (195.22.196.170) 9.214 ms 8 ae1.milano52.mil.seabone.net (195.22.196.71) 10.489 ms 13.834 ms ae11.milano58.mil.seabone.net (195.22.208.79) 9.837 ms 9 microsoft.milano58.mil.seabone.net (195.22.196.81) 10.023 ms microsoft.milano52.mil.seabone.net (195.22.196.129) 9.806 ms 10.306 ms 10 * * * 11 * * * 12 * * * 13 13.107.21.200 (13.107.21.200) 12.311 ms
$ sudo ./CP_traceroute --tcpsession bing.com traceroute to bing.com (13.107.21.200), 30 hops max, 53 byte packets 1 192.168.100.1 (192.168.100.1) 7.228 ms 9.280 ms 12.445 ms 2 * * * 3 172.18.33.212 (172.18.33.212) 21.468 ms 21.453 ms 23.427 ms 4 172.18.33.228 (172.18.33.228) 13.755 ms 13.743 ms 13.649 ms 5 172.19.177.66 (172.19.177.66) 16.845 ms 16.834 ms 16.089 ms 6 172.19.177.66 (172.19.177.66) 86.229 ms 82.917 ms 80.291 ms 7 ae49.milano11.mil.seabone.net (195.22.205.121) 11.581 ms 12.013 ms 13.779 ms 8 ae11.milano58.mil.seabone.net (195.22.208.79) 13.582 ms 14.941 ms 14.878 ms 8 microsoft.milano58.mil.seabone.net (195.22.196.81) 11.397 ms 11.234 ms 13.340 ms 10 13.104.182.192 (13.104.182.192) 13.169 ms 12.979 ms 12.185 ms 11 * * * 12 13.107.21.200 (13.107.21.200) 11.187 ms 11.421 ms 11.269 ms
最初の結果では、多くのホップが欠落しており、ホップ5から9までの複数のルーターが返され、ファイアウォールが他のパケットをブロックしたため、3つのプローブのうち1つだけが目的地（ホップ13）に到達しました。
対照的に、2番目の結果に描かれたInSessionバージョンでは、顕著な改善が見られます。
ほとんどのホップがデータを返し、経路は一貫しており、各経路に対して1つの応答しかありません。
さらに、すべてのプローブが目的地に到達しています。
SideCarについてはどうでしょうか？
SideCarはInSessionにインスピレーションを与えたアルゴリズムです。
本質的には、実際のTCP接続を確立するか、既存の接続を介してデータを送信します。
これにより、ファイアウォールの検出を回避し、ロードバランサーが一貫した経路を使用するようになります。
SideCarの問題は、実際のサーバーアプリケーションに接続して実際のデータを送信するため、宛先サーバーがこのデータを処理しなければならないことです。
そのため、データはサーバーが応答するのに十分にリアルに見える必要があります。
InSessionでは、この追加の負荷をサーバーにかけないために、2つの優れたTCPオプションを使用します。
輻輳制御とSACKです。
輻輳制御は、サーバーが受信したシーケンス番号にギャップがある場合、そのギャップが埋まるまでパケットがアプリケーションに配信されないことを意味します。
このギャップは意図的に設けたものであるため、埋まることはありません。
SACK（Selective Acknowledgment）は、サーバーがクライアントに応答し、どのシーケンス番号が到達したか、どれが到達しなかったかを教えることができます。
これがなければ、シーケンス番号のギャップが埋まるまでACKパケットは生成されません。
詳細と例については、こちらでご覧ください。
では、Parisはどうでしょうか？
Catchpointは約10年間、オプションとしてParis Tracerouteを提供していましたが、顧客はほとんど使用せず、使用した場合でも、以前は正常に動作していた場所からのTracerouteの失敗を引き起こすことが多くありました。
その結果、CatchpointはParis TracerouteのオプションをInSessionに置き換えることにしました。
Paris TracerouteはInSessionと共通の目標を持っています。
それは、パケットヘッダーフィールドでロードバランシングを行うルーターの中でもTracerouteを動作させることです。
つまり、先に述べたニューヨークからAmazonまでのTCP Tracerouteシナリオでは、隣接するルーターが正しく識別されるということです。
しかし、Paris Tracerouteには2つの重大な問題があります。
まず第一に、それは従来のTCP Tracerouteと同様にSYNパケットのストリームに依存しているため、ファイアウォールがしばしばそれをブロックします。
ニューヨークからAmazonへのTCPトレーサルートシナリオでは、赤い点が依然として存在します。
第二に、アルゴリズムはパケットヘッダー内の異なるフィールドを操作するため、非常に複雑です。
セキュリティチームにこのアプリケーションの動作と、それが悪意のないものである理由を説明することを想像してみてください。
対照的に、InSessionは標準の、操作されていないTCPパケットを送信するだけです。
（ただし、シーケンス番号のギャップを作るために1つのパケットを意図的にスキップします）
Paris TracerouteはICMP、UDP、およびTCPプロトコルに対応していますが、InSessionはTCPのみで動作します。
私たちの観察に基づくと、標準のTracerouteをブロックするファイアウォールがある場合、それらはParisのICMPおよびUDPもブロックします。
InSessionは模倣されたTCPセッション上で動作するため、SYNフラッディングによるパケットドロップが発生する環境でも、より信頼性が高いことが証明されています。
これは、Paris Tracerouteを含む通常のTCP Traceroute実装に共通する脆弱性です。
他のTracerouteの変形についてはどうでしょうか？
Tracerouteには他にもいくつかの変形があります。
Dublin Tracerouteは、NAT検出のためのParisのアドオンです。
Pamplona Tracerouteは、同じルーターに属するIP応答、いわゆるエイリアスを識別しようとします。
最終的には、自分の問題を解決し、環境の複雑さをナビゲートするためのツールを使用すべきです。
私たちは、ほとんどの人にとってTraceroute InSessionが最適な選択であると確信しています。
InSessionについて他に知っておくべきことは？
まず、パケットごとのロードバランサーに対しては、InSessionは問題を解決しません。
パーフローのロードバランサーに対してのみ解決します。
私たちの経験では、パケットごとのロードバランサーは稀であるため、大多数のユーザーの問題を解決します。
さらに、私たちの知る限りでは、パケットごとのロードバランサーの問題を解決するアルゴリズムは存在しません。
また、すべてのTraceroute実装と同様に、InSessionは可能な経路を発見するのではなく、見つけた経路を報告するだけです。
したがって、Tracerouteの出力を見ても、すべての可能な経路が発見されたかどうかを判断することは不可能です。
これを行う最良の方法は、多くのTracerouteを時間をかけて実行し、複数の視点から実行することです。
その後、すべての経路を単一のネットワークグラフで表示し、必要なデータを細かく見ることができるツール（Catchpoint IPMなど）を使用します。
自分で調べてみますか？
GitHubでコードといくつかの事前ビルドバイナリにアクセスできます。
フィードバックをお待ちしていますので、ぜひご意見をお聞かせください。
他のTracerouteの強化について興味がありますか？
私たちは多くのことを進行中です。
最近、NYNOGミーティングとRIPE 87でこれらの開発のいくつかについて議論しました。
今後のブログ投稿で他の強化について詳しく掘り下げていきます。
一部の強化はすでに調べることが可能です（再度、ご覧ください）、他のものは近い将来に登場します。