ロードバランサーはどのように管理するかTCP接続

Question

ロードバランサーによるTCP接続の処理について質問があります。

ロードバランサーの背後に3台のサーバーがあります。サーバーとRSTフラグが送信されたためにアイドル接続が5分間切断されると、サーバーとクライアント間でデータが送信されないことがあります。）。ロードバランサーが原因であるのではないかと思っていたので、WireSharkを使用してTCP RST FLAGのパケットをキャプチャし、そのようなパケットをキャプチャしました。

私の質問は、ロードバランサーが接続のリセットを担当している場合、変更されたソースIPを使用してLBから送信されたRSTパケットがサーバー側に表示されないのですか？または、おそらく私は間違っています。LBがRSTパケットを送信していても、サーバー側でそれをキャプチャすることはまだ可能ですか？

編集1

質問を絞り込みたい（または強化したい）。クライアントとサーバーの間の何かがRSTを使用してパケットを送信する場合、それはクライアントとサーバーの両方で、またはそれらの1つ（たとえばクライアント）でのみ表示されますか？

編集2

クライアントとサーバー側でRSTフラグ付きのパケットをキャプチャしましたが、奇妙なのは、クライアント側ではLBサーバーが送信したように見え、サーバー側ではクライアントが送信元/宛先IPで送信したように見えることです）

FarazX · Accepted Answer

私の知る限り、これはOSIレイヤーや通信方法などのネットワーキングトピックに関する誤解です。

主な質問に簡単に答えると、LoadBalancerがどのように処理するかは、構成と、それをどのように定義/処理したいかに依存します。ただし、OSIモデルのレイヤー4および7でLoadBalancingが実際にどのように機能するかを示すには、次の情報をお読みください。

まず、RSTパケットについては、RSTは接続をリセットするために使用され、完了できなかったものと、サーバーとクライアント間で会話が行われなくなったときに両側で発生する可能性があるため、言及したことは完全に一般的であることに注意してください。接続はまだ終了していません。 Quora の回答からの抜粋、RSTパケットは、サーバーが接続を拒否したとき、またはデータの途中でORが使用できないときに、3ウェイハンドシェイクの途中で送信されますサーバーまたはクライアントのいずれかが使用不可になるか、正式な4方向TCP接続終了プロセスなしでそれ以上の通信を拒否したときに転送します。

伝送制御プロトコル（TCP）はtransportレイヤー（OSIモデルのレイヤー4）で動作します。 TCPは、オクテットのストリームの信頼性が高く、順序付けられ、エラーチェックされた配信を提供し、IPネットワークで通信するホスト上で実行されているアプリケーション間に仮想接続を作成します。つまり、アプリケーションプログラムとインターネットプロトコルの間の中間レベルで通信サービスを提供します。IPパケットは、失われたり、破損したり、順不同で到着したりする可能性があるため、TCPにはメカニズムがありますこれらのエラーを修正するために、IPパケットのストリームを信頼性の高い通信チャネルに変換します。各アプリケーションには一意のTCPポート番号が割り当てられ、多くのアプリケーションが実行されているホスト上の正しいアプリケーションへの配信を可能にします。たとえば、標準のTCPポート22は、SSHサーバーに接続するために割り当てられています。デフォルトのポートは、必要に応じて構成ファイルで変更できます。

レイヤー4のロードバランシングでは、ロードバランサーのIPアドレスがWebサイトまたはサービスのクライアントにアドバタイズされます。推測されたように、クライアントのリクエストに記録された宛先アドレスはLoadBalancerのアドレスになります。 Layer 4ロードバランサーがリクエストを受信してロードバランシングを決定すると、リクエストパケットに対してネットワークアドレス変換（NAT）も実行され、自身の内部IPアドレスから、内部ネットワークで選択したコンテンツサーバーの宛先IPアドレスまでの記録された宛先IPアドレス。たとえば、あなたのシナリオでは、LoadBalancerは独自のアドレスを要求されたサービスをクライアントに提供するために必要なアドレスに変更します。より明確にするために、LoadBalancerの背後にある3つのサーバーの1つがストレージサーバーとして機能し、クライアントはウェブサイトのPDFまたはその他のコンテンツを喜んで読みます。クライアントの宛先アドレスは、LoadBalancerに割り当てられているパブリックIPアドレスに設定されており、LoadBalancerが要求を受信すると、内部サーバーで独自のサーバーを使用するサーバーを決定します。 LoadBalancerで設定および構成します。同様に、サーバーの応答をクライアントに転送する前に、ロードバランサーはパケットヘッダーに記録されたソースアドレスを内部サーバーのIPアドレス（たとえば、ストレージ）から独自のものに変更します。（パケットに記録された宛先および送信元のTCPポート番号も、同様の方法で変更されることがあります。）次に、TCPストリーム。パケットの内容は検査しません。

「ロードバランサーが接続のリセットを担当している場合、ソースIPが変更されたLBによって送信されているため、サーバー側でRSTパケットは表示されませんか？」と回答するには、他のサーバーでRSTパケットのみが表示されると言う必要があります。 LoadBalancerとのクライアント接続ではなく、LoadBalancerとの接続をリセットする必要があります。

ところで、内部サーバーでtcpdumpを使用して、LoadBalancerからのリクエストを受信できるかどうかを確認することを強くお勧めします。これにより、問題の原因を特定し、問題を修正する方法を見つけることができます。 WireSharkを使用することに戸惑うことはありません。素晴らしいツールですが、WireSharkが何を示しているかを理解するには十分な知識が必要です。