Server Load Balancer:HTTPS リスナーの追加

ステップ 1: リスナーの設定

1. Application Load Balancer (ALB) コンソールにログインします。

2. 上部のナビゲーションバーで、インスタンスがデプロイされているリージョンを選択します。

3. 次のいずれかのメソッドを使用して、リスナー設定ウィザードを開きます。

   • インスタンス ページで、ターゲットインスタンスを見つけ、操作 列の リスナーの作成 をクリックします。

   • インスタンス ページで、ターゲットインスタンスの ID をクリックします。リスナー タブで、リスナーの作成 をクリックします。

4. リスナーの設定 ウィザードで、次のパラメーターを設定し、[次へ] をクリックします。

   リスナー設定	説明
   リスナープロトコルの選択	リスナーのプロトコルを選択します。 この例では、[HTTPS] が選択されています。
   リスナーポート	リクエストを受信してバックエンドサーバーに転送するために使用されるリスナーポートを入力します。この例では、[443] が入力されています。ポート 80 は HTTP のデフォルトポートで、ポート 443 は HTTPS のデフォルトポートです。 ポート番号は 1 から 65535 の間でなければなりません。 説明 同じ ALB インスタンス内では、同じプロトコルのリスナーは同じポートを使用できません。HTTP リスナーと HTTPS リスナーは同じポートを使用できません。
   リスナー名	リスナーの名前を入力します。
   タグ	[タグキー] と [タグ値] を設定します。 タグを設定すると、[リスナー] タブでタグによってリスナーをフィルターできます。
   詳細設定	[変更] をクリックして高度な設定を展開します。
   HTTP/2 の有効化	HTTP/2 を有効にするかどうかを選択します。
   アイドル接続タイムアウト期間	アイドルタイムアウト期間を指定します。有効値: 1 ～ 600 秒。デフォルト値: 15 秒。より大きな値を使用したい場合は、Quota Center に移動してクォータの引き上げをリクエストしてください。 タイムアウト期間内にリクエストが受信されない場合、Server Load Balancer は一時的に現在の接続を中断します。次のリクエストが受信されると、新しい接続が確立されます。 説明 この機能は HTTP/2 リクエストには効果がありません。
   接続リクエストタイムアウト	リクエストタイムアウト期間を指定します。有効値: 1 ～ 600 秒。デフォルト値: 60 秒。より大きな値を使用したい場合は、Quota Center に移動してクォータの引き上げをリクエストしてください。 タイムアウト期間内にバックエンドサーバーから応答がない場合、Server Load Balancer は諦めて HTTP 504 エラーコードをクライアントに返します。
   データ圧縮	この機能を有効にすると、特定のファイルタイプを圧縮できます。この機能が無効になっている場合、ファイルは圧縮されません。 Brotli はすべてのファイルタイプをサポートします。 Gzip は次のファイルタイプをサポートします: text/xml、text/plain、text/css、application/javascript、application/x-javascript、application/rss+xml、application/atom+xml、application/xml、および application/json。 説明 データ圧縮は、応答の Content-Length が 1024 バイトを超えた場合にのみトリガーされます。 クライアントリクエストが Brotli と Gzip の両方をサポートしている場合、ALB はより効率的な Brotli を使用します。 クライアントが Gzip のみをサポートし、ファイルタイプが Gzip でサポートされていない場合、ALB はファイルを圧縮しません。
   実際のクライアントソース IP を見つける	この機能を有効にすると、ALB が X-Forwarded-For ヘッダーフィールドから送信元クライアント IP アドレスを取得できるようになります。この機能を有効にした後、信頼できる IP アドレスのリストを設定する必要があります。 信頼できる IP アドレスのリストを 0.0.0.0/0 に設定した場合: X-Forwarded-For リクエストヘッダーから最も左の IP アドレスを送信元クライアント IP アドレスとして取得します。 信頼できる IP アドレスのリストを proxy1 IP;proxy2 IP;.. に設定した場合: このリストにない右から最初の IP アドレスを送信元クライアント IP アドレスとして取得します。 シナリオ: X-Forwarded-For リクエストヘッダーには、X-Forwarded-For: <client-ip-address>, <proxy1>, <proxy2>, … のように複数の IP アドレスを含めることができます。最も左のアドレスがクライアントの IP アドレスです。ALB 転送ルールで [SourceIp] 一致条件と [QPS (クライアントソース IP に基づくスロットリング)] 機能を使用するには、[送信元クライアント IP アドレスの検索] を有効にします。これにより、ALB は X-Forwarded-For ヘッダーフィールドから送信元クライアント IP アドレスを見つけることができます。詳細については、「転送ルールの追加」をご参照ください。 説明 標準および WAF 対応の ALB インスタンスのみがこの機能をサポートします。Basic ALB インスタンスはサポートしません。
   HTTP ヘッダーフィールドの追加	追加したいカスタム HTTP ヘッダーフィールドを選択します: X-Forwarded-For ヘッダーフィールドを有効にしてクライアントの IP アドレスを取得するかどうかを選択します。 クライアント IP アドレスを保持するために X-Forwarded-For を追加 を選択した場合、ALB はリクエストをバックエンドサーバーに転送する前に、リクエストに X-Forwarded-For ヘッダーを追加するか、リクエストから X-Forwarded-For ヘッダーを削除できます。 追加 (デフォルト) [追加] を選択した場合、ALB はリクエストをバックエンドサーバーに転送する前に、リクエストの X-Forwarded-For ヘッダーに最後のホップの IP アドレスを追加します。リクエストに X-Forwarded-For ヘッダーが含まれていない場合、ALB は値が最後のホップの IP アドレスである X-Forwarded-For ヘッダーを作成し、そのヘッダーをリクエストに追加します。リクエストの X-Forwarded-For ヘッダーには、コンマ (,) で区切られた複数の IP アドレスが含まれる場合があります。 削除 [削除] を選択した場合、ALB はリクエストをバックエンドサーバーに転送する前に、リクエストから X-Forwarded-For ヘッダーを削除します。 クライアント IP アドレスを保持するために X-Forwarded-For を追加 を選択しない場合、ALB はリクエストをバックエンドサーバーに転送する前に、リクエストの X-Forwarded-For ヘッダーに対して何もしません。 フォーマット: X-Forwarded-For: <client-ip-address>, <proxy1>, <proxy2>, … バックエンドサーバーが受信するリクエストの X-Forwarded-For ヘッダーに関する例を見るにはクリックしてください。 この例では、最後のホップの IP アドレスは 127.0.0.1 です。 リクエストの説明 サンプルリクエスト クライアント IP アドレスを保持するために X-Forwarded-For を追加 を選択 クライアント IP アドレスを保持するために X-Forwarded-For を追加 を選択しない 追加 削除 ALB が受信したリクエストに X-Forwarded-For ヘッダーが含まれていません。 GET /index.html HTTP/1.1 Host: example.com X-Forwarded-For: 127.0.0.1 X-Forwarded-For ヘッダーは存在しません。 X-Forwarded-For ヘッダーは存在しません。 ALB が受信したリクエストに X-Forwarded-For ヘッダーとクライアント IP アドレスが含まれています。 GET /index.html HTTP/1.1 Host: example.com X-Forwarded-For: 127.0.0.2 X-Forwarded-For: 127.0.0.2, 127.0.0.1 X-Forwarded-For ヘッダーは存在しません。 X-Forwarded-For: 127.0.0.2 ALB が受信したリクエストに X-Forwarded-For ヘッダーと複数のクライアント IP アドレスが含まれています。 GET /index.html HTTP/1.1 Host: example.com X-Forwarded-For: 127.0.0.2, 127.0.0.3 X-Forwarded-For: 127.0.0.2, 127.0.0.3, 127.0.0.1 X-Forwarded-For ヘッダーは存在しません。 X-Forwarded-For: 127.0.0.2, 127.0.0.3 ALB がクライアント IP アドレスを保持できるようにする方法の詳細については、「Application Load Balancer を介してバックエンドサーバーでクライアントの送信元 IP アドレスを取得する」をご参照ください。 SLB-ID ヘッダーフィールドを追加して、SLB インスタンスの ID を取得します。 X-Forwarded-Proto ヘッダーフィールドを追加して、インスタンスのリスナープロトコルを取得します。 X-Forwarded-Port ヘッダーフィールドを追加して、SLB インスタンスのリスナーポートを取得します。 X-Forwarded-Host ヘッダーフィールドを追加して、クライアントが SLB インスタンスにアクセスするために使用したドメイン名を取得します。 X-Forwarded-Client-srcport ヘッダーフィールドを追加して、SLB インスタンスにアクセスするクライアントのポートを取得します。 X-Forwarded-Clientcert-subjectdn ヘッダーフィールドを追加して、SLB インスタンスへのアクセスに使用されるクライアント証明書の所有者情報を取得します。 X-Forwarded-Clientcert-issuerdn ヘッダーフィールドを追加して、SLB インスタンスへのアクセスに使用されるクライアント証明書の発行者情報を取得します。 X-Forwarded-Clientcert-fingerprint ヘッダーフィールドを追加して、SLB インスタンスへのアクセスに使用されるクライアント証明書の指紋を取得します。 X-Forwarded-Clientcert-clientverify ヘッダーフィールドを追加して、SLB インスタンスへのアクセスに使用されるクライアント証明書の検証結果を取得します。 説明
   QUIC アップデート	QUIC アップグレードを有効にするかどうかを選択します。QUIC アップグレードを有効にする場合は、[関連付けられた QUIC リスナー] ドロップダウンリストから作成済みの QUIC リスナーを選択します。 QUIC リスナーを作成していない場合は、[リスナーの作成] をクリックして作成します。詳細については、「QUIC リスナーの追加」をご参照ください。 ALB は iQUIC と gQUIC をサポートしています。詳細については、「QUIC プロトコルを使用してオーディオおよびビデオサービスへのアクセスを高速化する」をご参照ください。

ステップ 2: SSL 証明書の設定

HTTPS リスナーを作成するときは、サービスが暗号化され、認証局 (CA) によって認証されるように SSL 証明書を設定する必要があります。次の表に、ALB に設定できる証明書を示します。

1. SSL 証明書の設定 ウィザードで、サーバー証明書を選択します。

   利用可能なサーバー証明書がない場合は、ドロップダウンリストの [SSL 証明書の作成] をクリックして Certificate Management Service コンソールに移動します。コンソールでは、サーバー証明書を購入またはアップロードできます。

2. 任意: [相互認証の有効化] をオンにし、CA 証明書のソースを選択します。

   • CA 証明書ソースを [Alibaba Cloud によって発行] に設定し、[デフォルト CA 証明書の選択] ドロップダウンリストから CA 証明書を選択します。

     利用可能な CA 証明書がない場合は、ドロップダウンリストの [CA 証明書の購入] をクリックして新しい CA 証明書を作成します。

   • CA 証明書ソースを [Alibaba Cloud によって発行されていない] に設定し、[デフォルト CA 証明書の選択] ドロップダウンリストから CA 証明書を選択します。

     自己署名 CA 証明書が利用できない場合は、ドロップダウンリストの [自己署名 CA 証明書のアップロード] をクリックします。[証明書アプリケーションリポジトリ] ページで、リポジトリを作成し、そのデータソースを [CA 証明書のアップロード] に設定します。次に、リポジトリから自己署名ルート CA 証明書または自己署名中間 CA 証明書をアップロードします。

   説明

   • 標準および WAF 対応の ALB インスタンスのみが相互認証をサポートします。Basic ALB インスタンスはサポートしません。

   • 相互認証を有効にした後で無効にする必要がある場合は、次のステップを実行します。

     1. [インスタンス] ページで、ターゲットインスタンスの ID をクリックします。

     2. [リスナー] タブで、ターゲット HTTPS リスナーの ID をクリックします。

     3. [リスナーの詳細] タブで、[SSL 証明書] セクションの相互認証スイッチをオフにします。

3. [TLS セキュリティポリシー] を選択し、[次へ] をクリックします。

   利用可能な TLS セキュリティポリシーがない場合は、ドロップダウンリストの [TLS セキュリティポリシーの作成] をクリックします。

   TLS セキュリティポリシーには、HTTPS でサポートされている TLS プロトコルバージョンと暗号スイートが含まれています。

ステップ 3: サーバーグループの選択

サーバーグループ ウィザードで、サーバーグループを選択し、バックエンドサーバーに関する情報を表示してから、[次へ] をクリックします。

ステップ 4: 確認

確定 ページで、設定を確認し、[送信] をクリックします。

HTTPS はどの TLS プロトコルバージョンをサポートしていますか？

TLS 1.0、TLS 1.1、TLS 1.2、および TLS 1.3。詳細については、「TLS セキュリティポリシー」をご参照ください。

バックエンドサーバーは、HTTPS リスナーへのクライアントリクエストのプロトコルバージョンを取得できますか？

はい、できます。

HTTPS リスナーがバックエンドサーバーにアクセスするために使用する HTTP プロトコルバージョンは何ですか？

• クライアントリクエストが HTTP/1.1 または HTTP/2 を使用する場合、レイヤー 7 リスナーは HTTP/1.1 を使用してバックエンドサーバーにアクセスします。

• クライアントリクエストが HTTP/1.1 または HTTP/2 以外のプロトコルを使用する場合、レイヤー 7 リスナーは HTTP/1.0 を使用してバックエンドサーバーにアクセスします。

ALB リスナーでワイルドカード証明書を使用するためのルールは何ですか？

HTTPS セッションチケットの有効期間はどのくらいですか？

HTTPS セッションチケットの有効期間は 300 秒です。