BGPマルチパスとリターンルート
私はおそらくserverfault関連の質問に関して完全なn00bですが、私たちのIT部門は私が確認したい大胆な声明を出します。インターネットを検索しましたが、質問に関連するものが見つからないので、ここに来ました。
Threat Management Gateway 2010があり、以前はリクエストをIISにルーティングし、IPアドレスが含まれているため、どこから来たのかを確認できました。しかし、今では「リクエストが表示されます。 「TMGサーバーに来てください」というように、IPアドレスは転送されなくなります。すべての要求にはTMGサーバーのIPが含まれます。
この背後にある考え方は、マルチパスbgpルートのため、着信要求はRouteAを経由しますが、確認応答メッセージcouldはRouteBを経由して返されるということです。主張は、要求が最初の既知のソースであるプロキシからではなく、IISからのものであるため、Webサイトの訪問者の一部のスマートルーターが確認メッセージを認識せず、フィルターで除外するというものです。つまり、応答が到着することはありません。
繰り返しますが、これは主張です。しかし、私はこの主張を裏付けるインターネット上のリソースを見つけることができません。私はbgpマルチパスについて読んでいますが、最速のルートが何らかの理由で失敗したときに代替ルートがある場合はもっと。
それで、主張は完全に偽物ですか、それとも（いくつかの）真実がありますか？誰かが私にリソースを説明したり指摘したりできますか？
前もって感謝します！
この種の非対称ルーティングは、実際にインターネット上でかなり頻繁に発生します。特定のBGPルーターは、多数のローカルプリファレンスルールと、パスおよび使用するピアに関するさまざまなパースペクティブを持つことができます。インターネットルーターは、セッションがどのパイプを通過したかを認識または認識しません。また、それも問題ではありません。パケットが宛先に到達する限り、すべてが正常に機能しています。
ただし、その動作は、WebサーバーとTMGプロキシ間の通信とは何の関係もありません。
説明の問題はここにあります：
リクエストは最初の既知のソースであるプロキシからではなく、IISから送信されます
これが当てはまる場合、Webサーバーへのすべての接続は無条件に失敗します。クライアントはプロキシのIPアドレスに接続し、同じアドレスからの応答トラフィックを期待します-応答トラフィックの送信元IPであるIISサーバー（TMGをスキップ）は応答トラフィックを拒否します）。
TMGが接続の見かけのソースを「実際の」クライアントにすることが正しく機能する理由は、TMGがWebサーバーの前にインラインで配置されているためです（TMGがインラインであり、ルーターとして機能している場合にのみ機能します）。 。 TMGは、クライアントアドレスにバインドされたWebサーバーからの応答トラフィックを確認し、それをキャッチして、正しい接続（クライアントがTMGに対して開始した接続）を介してクライアントに送信します。
したがって、基本的に、BGPとインターネットルーティングはそれとは関係ありませんが、内部ネットワーク（TMGデバイスが応答トラフィックのルーティングに使用されない）での同様の種類の非対称ルーティングは、Webクライアントからの接続を切断し、使用する必要があります見かけの接続ソースとしてのTMGIPアドレス。多分彼らはトポロジーの変更を計画していますか？