HTTPSトラフィックを処理するためにhaproxy 1.4の前にstunnelを配置したいと思います。X-Forwarded-Forヘッダーを追加するためのstunnelも必要です。これは 、haproxy Webサイトからの「stunnel-4.xx-xforwarded-for.diff」パッチによって達成できます。
ただし、説明では次のように述べています。
このパッチはキープアライブでは機能しないことに注意してください...
私の質問は、これは私にとって実際に何を意味するのでしょうか？わからない
回答:
これは、HTTPキープアライブに関するものです。これにより、複数のリソース要求が単一のTCPセッション（およびSSLを使用する場合は単一のSSLセッション）を介して送信されます。キープアライブがないと、要求されたリソースごとにSSLハンドシェイクが必要になるため、これはSSLサイトのパフォーマンスにとって非常に重要です。
したがって、ここでの懸念は、クライアントからバックエンドサーバーまでの1つの大きなキープアライブセッションです。これはパフォーマンスにとって重要なことであり、最近のHTTPサーバーでは当然のことと考えられていますが、このパッチではサポートされていません。その理由を見てみましょう。
キープアライブセッションは、次々と要求が増えるだけFINです。サーバーが1つの要求に対する応答を完了すると、サーバーはTCPセッションを終了するためのパケットを送信しません。クライアントは単純にヘッダーの別のバッチを送信できます。
そのパッチの機能を理解するために、キープアライブの会話の例を次に示します。
クライアント：
GET / HTTP/1.1
Connection: keep-alive
Host: domain.com
...
サーバ：
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Server: Apache
Content-Length: 34
.... (other headers)
<html><head>content!</head></html>
ここで、非キープアライブ接続が停止します。ただし、キープアライブを使用すると、クライアントは別のクライアントを起動できます。
GET /images/some/image.on.the.page.jpg HTTP/1.1
Connection: keep-alive
Host: domain.com
...
プロキシのクライアントIDの場合、一部のリバースプロキシはX-Forwarded-For、各クライアント要求のヘッダーに追加できます。これにより、ロギングやその他のアプリケーションのニーズにおける健全性のために、要求が（リバースプロキシのIPから開始されるすべての要求の代わりに）どこから来ているかが上流のサーバーに通知されます。
X-Forwarded-Forヘッダは、各フルヘッダーが毎回送信されるように、キープアライブ接続を介して送信されたすべてのクライアントのリソース要求に注入する必要があります。X-Forwarded-Forヘッダーの処理と「実際の」要求IP であるヘッダーへの変換は、TCP-keep-alive-sessionごとではなく、要求ごとに行われます。そして、ねえ、単一のキープアライブセッションを使用して複数のクライアントからの要求にサービスを提供する素晴らしいリバースプロキシソフトウェアがあるかもしれません。
これは、このパッチが失敗する場所です。
そのサイトのパッチは、TCPセッションのバッファでストリーム内の最初のHTTPヘッダーセットの終わりを監視し、最初のヘッダーセットの終わりの後で新しいヘッダーをストリームに挿入します。これが完了すると、X-Forwarded-Forジョブが完了したと見なされ、新しいヘッダーセットの終わりのスキャンが停止します。このメソッドは、後続のリクエストを介して着信する将来のヘッダーすべてを認識しません。
それらを本当に非難することはできません。stunnelは、ストリームのコンテンツの処理と変換を行うために実際に構築されたのではありません。
これがシステムに与える影響は、キープアライブストリームの最初のリクエストでX-Forwarded-Forヘッダーが適切に挿入され、後続のすべてのリクエストが正常に機能することですが、ヘッダーはありません。
接続ごとに複数のクライアント要求を処理できる別のヘッダーインジェクションパッチがない（または、スタックオーバーフローで友人の助けを借りてこれを調整できる）場合を除き、SSL終了の他のオプションを確認する必要があります。
STunnel 4.45は、HAProxy 1.15に付属するいくつかの新機能（プロキシプロトコル）を使用してこれを適切に修正します
以前のパッチとキープアライブの問題も修正します
私が別のスレッドで投稿したものと同様に、HAProxyは1.5-dev12以降、両側でネイティブSSLをサポートしています。したがって、X-Forwarded-For、HTTPキープアライブ、および接続がSSL経由で行われたことをサーバーに通知するヘッダーを使用することは、次のように簡単です。
listen front
bind :80
bind :443 ssl crt /etc/haproxy/haproxy.pem
mode http
option http-server-close
option forwardfor
reqadd X-Forwarded-Proto:\ https if { is_ssl }
server srv1 1.1.1.1:80 check ...
...
stunnelにパッチを適用するよりもはるかに簡単で、キープアライブをドロップする必要があるよりもはるかに優れています。
Shaneからの優れた回答を拡張して、HAproxyの前でNginxをSSLターミネーターとして使用できます。最もレイテンシの影響を受けやすいクライアントとnginxの間のキープアライブを正しく処理し、クライアント要求ごとにバックエンドへの新しい接続を作成して、それぞれにX-FORWARDED-FORを送信します。