現在2つのアプリケーションをホストしているウェブサーバーファームがあります。両方のアプリケーションがすべてのサーバーで実行されています。これを分割して、各アプリ専用のサーバーファームを用意します(これには十分な理由があります)。
ホスト名に基づいてトラフィックを適切なファームにルーティングするすべてのサーバーの前に単一のロードバランサーを配置することを望んでいましたが、WebサーバーへのSSLを維持したいと考えています。
私たちが提供しているルーターはこれをしていないようです。 SNIがなければこれは不可能だと思いますが、ほぼすべてのトラフィックでSNIインジケーターを期待しています。
現在私はプログラマーであり、ネットワークの専門家ではありませんが、新しいSSL接続要求が来たときに、ルーターがSNIヘッダーを調べて正しいファームにルーティングすることはできません。着信SSL接続は{source IP:source port}によって識別されると想定しているため、後続の着信パケットについてこれを覚えていませんか(SNIが最初のパケットにのみ存在する場合)?
私が知る限り、Haproxyはこれを行いますが、ハードウェアロードバランサーはそうではないようです。これには理由がありますか、これは私たちがプッシュする必要があるものですか?
(IE on XP SNIを含まない最後のガードについては、古いファームにトラフィックを送信する必要があります。必要に応じて、新しいファームへのプロキシを管理します)。
彼らのウェブサイトによると、F5ロードバランサーはSNIをサポートしています:
https://devcentral.f5.com/articles/ssl-profiles-part-7-server-name-indication
SNIに基づいてiRulesを作成することもできます。
免責事項:
ルータがSNIヘッダーを検査できない、
ルーターは通常、OSIレイヤー3でのみ機能します。つまり、パケットの内容は検査せず、ターゲットIPのみを検査します。 SNIに基づくルーティングの場合、TCPとTLSの理解が必要です。これは、IPアドレスに基づくルーティングよりも複雑であり、(パフォーマンスに関して)非常にコストがかかります。これも通常はその後、ルーティングを呼び出しました。
Haproxyはこれを行いますが、ハードウェアロードバランサーは行いません。
ルーター(レイヤー3)、ハードウェアロードバランサー(レイヤー4以上)、およびHaproxy(ソフトウェアロードバランサー)を混在させています。ハードウェアロードバランサーは、いくつかのソフトウェアロードバランサーを備えたアプライアンスにすぎず、特定のアクションのためのいくつかのハードウェアアクセラレーションでもあります。ハードウェアロードバランサーでは、SNI情報に基づくバランシング(ルーティングではなく)を本質的に不可能にするものはありません。別の回答のように、これをサポートする製品があることを示唆しています。しかし、もちろんそれを実装する必要があり、それはパフォーマンスを犠牲にします-彼らはあなたがより深くあなたがトラフィックを見るのが遅くなるほど、トラフィックを見ます。