web-dev-qa-db-ja.com

stunnelとhaproxyで仮想IPを使用する

ロードバランサーのセットアップがあり、HTTPSリクエストは次の手順で流れます。-

Client -> DNS -> stunnel on Load-Balancer -> HAProxy on LB -> Web-Server

この設定は、stunnelがLoad-BalancerのローカルIPをリッスンしているときに完全に機能します。

ただし、このセットアップでは2つのロードバランサーがあり、一度に1つのLBにのみ存在する仮想IPをリッスンできるようにする必要があります（最初のLBがフォールオーバーした場合、keepalivedはIPを2番目のLBにフリップします）。

HAProxyはこれを行うのに問題はありません（そして、テストしているロードバランサーで割り当てられた仮想IPにpingを実行できます）が、stunnelはこの概念を嫌っているようです。

誰かが以前にこれを達成したことがありますか（以下は私のstunnel構成です-あなたが見ることができるように、私は実際に443ですべてのトラフィックをリッスンしています）：-

cert= /etc/ssl/certs/mycert.crt
key = /etc/ssl/certs/mykey.key
;setuid = nobody
;setgid = nogroup

pid = /etc/stunnel/stunnel.pid
debug = 3
output = /etc/stunnel/stunnel.log

socket=l:TCP_NODELAY=1
socket=r:TCP_NODELAY=1

[https]
accept=443
connect=127.0.0.1:8443
TIMEOUTclose=0
xforwardedfor=yes

長い質問でごめんなさい！

load-balancinghaproxystunnel
1
isNaN1247

重要なのは、存在しないインターフェースをプログラム（stunnel、HA-proxyなど）にバインドできるようにすることです。そのため、keepalivedが仮想IPをそのボックスにフリップすると、プログラムはすでにそのインターフェイスでトラフィックをリッスンして待機しています。

これは、次のキーと値のペアを含めることで/etc/sysctl.confを変更することで実行できます。

net.ipv4.ip_nonlocal_bind=1

詳細はこちら： http://nbevans.wordpress.com/2011/03/01/safely-pairing-haproxy-with-virtual-network-interface-providers-like-keepalived-or-heartbeat/

次に、stunnelとHA-proxyの設定を変更して、特定の仮想インターフェイスIPへのバインドをハードコーディングするのが最善の方法です。 「開いた」ままにするのではなく。

2
nbevans