HAProxyを使用したリモートIP

いくつかの問題を抱えている新しいWebサーバーのセットアップをテストしています。基本的に、Webサーバーがあり、コードはいくつかの興味深いことにリモートIPを使用し、特定のIP（オフィスなど）に保護されたapacheディレクトリも使用します。

ただし、これをha_proxyの背後に追い込んで、さらにアプリケーションサーバーを追加できるようにしましたが、現在では、リモートIPは実際のリモートユーザーではなく、プロキシIPとして常に通過しています。これは、一部の場所に到達できないことを意味し、ユーザーIPが重要な場所でアプリが少し奇妙に動作しています。

設定は次のとおりです。

global
      maxconn 4096
      pidfile /var/run/haproxy.pid
      daemon

defaults
      mode http
      retries 3
      option redispatch
      maxconn 2000
      contimeout 5000
      clitimeout 50000
      srvtimeout 50000

listen farm xxx.xxx.xxx.xxx:80
      mode http
      cookie GALAXY insert
      balance roundrobin
      option httpclose
      option forwardfor
      stats enable
      stats auth username:userpass

      server app1 xxx.xxx.xxx.xxx:80 maxconn 1 check

haproxy.1wt.euのHAProxyドキュメントから引用。

-アプリケーションが元のクライアントのIPを記録する必要がある場合は、
  「forwardfor」オプションは、「X-Forwarded-For」ヘッダーを追加します。
  元のクライアントのIPアドレス。また、「httpclose」を使用して、
  各リクエストの最初のリクエストだけでなく、すべてのリクエストを書き換えます
  セッション：
        オプションhttpclose
        オプション

クライアントのIPアドレスを知るには、アプリケーションがX-Forwarded-For HTTPヘッダーを処理する必要があると記載されています。あなたの場合に行く唯一の方法のようです。

HAProxy 1.4用に更新されました

Haproxy 1.4では、「option http-server-close」という新しいモードが導入されました。サーバーへの接続はまだ閉じていますが、可能であればクライアントへのキープアライブを維持して使用します。ほとんどのセットアップでは、接続の単一の高遅延部分（Haproxyとクライアントの間）の遅延に役立つため、おそらくそれを使用する必要があります。

   option http-server-close
   option forwardfor

送信元アドレスの転送を許可するTproxyを含めるためにHAproxyを再コンパイルする方法があります。

それについてのブログ投稿があります：http : //blog.loadbalancer.org/configure-haproxy-with-tproxy-kernel-for-full-transparent-proxy/

いくつかのメモ：

最新のLinuxカーネル（2.6.28-11-server）にはTProxyのサポートが含まれているため、カーネルを再コンパイルする必要はありません。

HAProxyサーバーを指すデフォルトゲートウェイアドレスを使用して、Webファーム内のサーバーを構成してください。

rpaf apache module http://stderr.net/apache/rpaf/ を使用してください。これは昔の投稿ですが、これを見つけるのに何日もかかりました。これにより、すべてのアプリケーションにx-forwarded-for IPが提示されます。

Apacheヘッダーを変更すると、アプリケーションに表示される内容をオーバーライドできるように見えることに注意してください。

SetEnvIf X-Forwarded-For (.*) REMOTE_ADDR=$1
SetEnvIf X-Forwarded-For (.*) REMOTE_IP=$1

ただし、これは「許可元」などを介したApacheアクセスでは機能しません。

HAProxyは、設計上、他のプロキシとほとんど同じように、元のIPアドレスを実サーバーに転送できません。

あなたの唯一の問題がWebサーバーにある場合、1つの解決策は、クライアントのアドレスを含むX-forwarded-for HTTPヘッダーを調べることです。さて、それはほとんどアプリケーション/言語固有ですが、phpでこの例を見てください：

$headers = apache_request_headers();

$real_client_ip = $headers["X-Forwarded-For"];

元のアドレスも記録する場合は、httpd.confのLogFormatを次のように変更できます。

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{X-Forwarded-For}i\"" common

さて、X-Forwarded-forはあなたのセットアップではうまく機能していないようです。では、haproxyを使い続ける特別な理由はありますか？IPVSはあなたのニーズにより適しているようです（実際にldirectorを使用し、さらにlvtorを使用します）。

を見てみましょう：

http://kb.linuxvirtualserver.org/wiki/IPVS

そして

http://www.vergenet.net/linux/ldirectord/

「IPトンネリング」または「直接ルーティング」モードでIPVSを使用すると、クライアントのアドレスが保持されます。

http://www.openinfo.co.uk/apache/からmod_extract_forwardedを試してください

LoadModule extract_forwarded_module modules/mod_extract_forwarded.so
MEFOrder refuse,accept
MEFRefuse all
MEFAccept xxx.xxx.xxx.xxx

モードtcpおよびnginxでhaproxyを使用する簡単な方法：

サーバーオプションとしてsend-proxyを追加します。

haproxy.conf：

。

。

listen ssl 0.0.0.0:443

モードtcp

バランス最小

オプションhttpchk GET / ping

オプションlog-health-checks

サーバーw1 192.168.1.1:443 send-proxy check check-ssl verify none

サーバーw2 192.168.1.1:443 send-proxy check check-ssl verify none

。

。

Nginxはプロキシプロトコルをサポートする必要があります

nginx.conf：

。

。

listen 192.168.1.1:443 ssl proxy_protocol;

。

。

set_real_ip_from 192.168.1.0/24;

real_ip_header proxy_protocol;

。

。