☰

HAProxy バックエンド - リモート サーバーに接続するにはどうすればいいですか?

tag-icon • tag-icon haproxy remote backend
HAProxy バックエンド - リモート サーバーに接続するにはどうすればいいですか?

皆さんこんにちは。

私はウェブホスティングの初心者で、まだ海の真ん中で泳ぎ方を学んでいるような気分です。やりたいことは、バックエンドのリモート サーバーにリクエストを転送するように HAproxy を設定することです。このサーバーは SSL で、Cloudflare の背後にあります。

インターネット全体を検索しましたが、今のところ、私の質問に対する明確な答えを見つけることができません。haproxy イメージを取得し、外部 haproxy.cfg ファイルを含むコンテナーで使用しています。バックエンドのサーバーとして使用できるかどうか、ネットワークから離れたサーバー (ローカルではない) として使用できるかどうか、さらにこの通信に SSL を使用する方法については、誰も明確に説明していません。これについて知っている方がいらっしゃいましたら、これが実行可能かどうか、またその方法について回答していただければ幸いです。

今のところ、サーバーの NginxProxyManager コンテナーで使用しており、HAProxy の負荷分散機能を調査しています。これまでのところ、ローカル コンテナーのラウンドロビンは正常に実行されていますが、離れたサーバーでは常に統計情報に「メンテナンスのためダウン」という応答が返されます。また、ha-proxy コンテナーのターミナルで wget コマンドを実行し、外部の世界を見ることができます。HAProxy コンテナーの内部から Google に ping すると、ping が送信されます。すべてのコンテナーは、ブリッジ ネットワークと、docker のユーザーが作成したネットワーク (ブリッジ ドライバー) の両方に接続されています。そのため、私は完全に混乱しています。そこで、主な質問は、それが実行可能かどうか、また、実行可能な場合、次のシナリオは可能かどうかです (?)。

  1. クライアントはHAProxyにhttpsリクエストを送信します
  2. ラウンドロビンを使用して、ローカルコンテナとリモートサーバーの間でロールバックします（したい）。
  3. 「リモート サーバー」ラウンドに到達したら、バックエンドから正しいサーバーのホスト (書き換え済み - ローカル コンテナーの場合は既に実行できます) と、これが SSL 要求であるという情報を送信したいと思います。
  4. 次に、NginxProxyManager または別の HAProxy がそれをそこに接続されているコンテナーに転送し、応答を取得してそれを (最初の) HAProxy に送り返し、後者をクライアントに送り返します。

これが可能かどうかは分かりません。以下をご覧ください。ローカルコンテナでは動作しますが、リモートサーバーでは動作しません。リクエストを送信し、ホストヘッダーの名前を書き換えます。haproxy.cfgは次のとおりです。

global
        maxconn     4000
        daemon

defaults
        mode    http
        default-server init-addr last,libc,none
        option  http-keep-alive
        option  redispatch
        retries 3
        timeout connect 10s
        timeout client  1m
        timeout server  1m
        option forwardfor 


resolvers mynameservers
   nameserver ns2 8.8.8.8:853


frontend stats
        bind *:8500
        stats enable
        stats uri /
        stats refresh 10s


frontend ft
        bind 0.0.0.0:443 ssl crt /usr/local/etc/haproxy/ha_trial.pem  
        default_backend bt2

backend bt2
        balance roundrobin
        http-send-name-header Host        
        server web1 web1:8080 check
        server web2 web2:8080 check
        server web3 web3:8080 check        
        server myback.mysite.com myback.mysite.com:443 ssl verify none resolvers mynameservers
## the latter does not work - it ends at down for maintenance in statistics and in logs it says: Layer6 invalid response, info: "SSL handshake failure" while it is "verify none"

もしあなたが答えを知っているなら、そして/またはいくつかの参考資料で私を助けていただければ、私のようなすべての人、特に私にとっては大変ありがたく思います。

ありがとう

答え1

このケースは、HAProxy Docker イメージが QUIC に対応しておらず、バックエンドがデフォルトで QUIC をサポートする Cloudflare の背後にあるため、まさに SSL ハンドシェイクが失敗するケースです。https の通信プロトコルで QUIC に対応していない別のドメインを使用すると、すべて正常に動作します。また、フロントエンドとバックエンドを別々に処理するのはなぜなのかも気になります。フロントエンドでは QUIC を理解します (? - または、ユーザーと cloudflare 間の QUIC であり、cloudflare からサーバーへの暗号化が異なる?) が、バックエンドからの接続は不可能ですか?

つまり、簡単に言うと:

  1. HAProxy Docker イメージは QUIC が有効になっていません - 少なくとも私が持っているもの (alpine)
  2. Cloudflare では、自社のサービスの通信プロトコルとして QUIC がデフォルトで有効になっており、これを変更することはできません。
  3. これら 2 つの連携は明らかに不可能であり、「SSL ハンドシェイクの失敗」が発生します。
  4. これを修正するには、最新のテクノロジの通信プロトコルをサポートしていないプロバイダーを使用します。現時点では、これは緩和策のみであり、解決策ではありません。
  5. HAProxy サイトでは、QUIC サポートを使用して github から HAProxy を再コンパイルする方法が提供されており、後で調査する予定です...

関連情報