
現在の状況に適した高レベルの構成例を探しています。複数の内部 IIS サーバー上にある複数のサブドメイン用のワイルドカード SSL 証明書があります。
site1.example.com (X.X.X.194) -> IISServer01:8081
site2.example.com (X.X.X.194) -> IISServer01:8082
site3.example.com (X.X.X.194) -> IISServer02:8083
受信 SSL トラフィックを 1 つのサーバー エントリで処理し、特定のドメインを内部 IIS アプリケーションに渡すことを検討しています。2 つのオプションがあるようです。
各サブドメインのロケーションセクションをコーディングする(私が見つけた例からすると面倒なようです)
暗号化されていないトラフィックを、サブドメインのホスト名ごとに異なるサーバー エントリが設定された同じ nginx サーバーに転送します (少なくともこれはオプションのようです)。
私の最終的な目標は、SSL トラフィックの多くを nginx 経由で統合し、HAProxy を使用してサーバーの負荷分散を行うことです。
proxy_set_header エントリを適切に設定すれば、アプローチ 2 は nginx 内で機能しますか?
最終的な構成ファイル内では、次のような内容を想定する (アプローチ #2 を使用)。
server {
listen Y.Y.Y.174:443; #Internally routed IP address
server_name *.example.com;
proxy_pass http://Y.Y.Y.174:8081;
}
server {
listen Y.Y.Y.174:8081;
server_name site1.example.com;
-- NORMAL CONFIG ENTRIES --
proxy_pass http://IISServer01:8081;
}
server {
listen Y.Y.Y.174:8081;
server_name site2.example.com;
-- NORMAL CONFIG ENTRIES --
proxy_pass http://IISServer01:8082;
}
server {
listen Y.Y.Y.174:8081;
server_name site3.example.com;
-- NORMAL CONFIG ENTRIES --
proxy_pass http://IISServer02:8083;
}
これは 1 つの方法のように思えますが、これが最善の方法かどうかはわかりません。これに対するより簡単な方法を見逃しているのでしょうか?
答え1
私は次のようにします (nginx 1.4.2 でテスト済み、動作するようです):
server {
listen 127.0.0.1:443 ssl;
server_name site1.example.com;
include common.conf;
location / {
proxy_pass http://127.0.0.2:8081;
}
}
server {
listen 127.0.0.1:443 ssl;
server_name site2.example.com;
include common.conf;
location / {
proxy_pass http://127.0.0.2:8082;
}
}
server {
listen 127.0.0.1:443 ssl;
server_name site3.example.com;
include common.conf;
location / {
proxy_pass http://127.0.0.3:8083;
}
}
少なくとも次のようになりますcommon.conf
:
ssl on;
ssl_certificate /path/to/cert;
ssl_certificate_key /path/to/key;
答え2
信じられないかもしれませんが、次のことが可能です。
ssl_session_cache shared:SSL:2m;
ssl_session_timeout 5m;
server {
listen Y.Y.Y.174:443 default_server ssl;
server_name _;
ssl_certificate /etc/pki/tls/certs/server.chained.crt;
ssl_certificate_key /etc/pki/tls/private/server.key;
}
server {
listen Y.Y.Y.174:443 ssl;
server_name site1.example.com;
[...]
proxy_pass http://IISServer01:8081;
}
server {
listen Y.Y.Y.174:443 ssl;
server_name site2.example.com;
[...]
proxy_pass http://IISServer01:8082;
}
server {
listen Y.Y.Y.174:443 ssl;
server_name site3.example.com;
[...]
proxy_pass http://IISServer02:8083;
}
インクルードは不要で、証明書はメモリに一度だけロードされ、ユーザーがサブドメイン間を移動してもセッションはキャッシュされたままになるため、ハンドシェイクの処理能力が大幅に節約されます。
それ以上の文書は見つかりませんこのサーバー障害の投稿なぜこれが機能するのかを説明することはできませんが、機能することは間違いありません。