Google Cloud Load Balancing 用の SSL プロキシの設定

Google Cloud SSL プロキシは、グローバル負荷分散層でユーザー SSL(TLS)接続を停止し、SSL または TCP を介してインスタンス全体で接続を分散します。Cloud SSL プロキシは HTTP(S)以外のトラフィックを対象にしています。 HTTP(S)トラフィックの場合は、代わりに HTTP(S)負荷分散を使用することをお勧めします。

目次

概要

SSL トラフィックに SSL(TLS)プロキシを使用すると、グローバル負荷分散層で顧客の SSL セッションを停止し、SSL(推奨)または TCP を使用して仮想マシン インスタンスにトラフィックを転送できます。

SSL プロキシは、グローバル負荷分散サービスです。複数の地域にインスタンスをデプロイできます。また、グローバル負荷分散によってユーザーに最も近い地域にトラフィックが自動的に転送されます。地域の容量に達すると、ロードバランサは使用可能な容量を持つ別の地域に新しい接続を自動的に転送します。既存のユーザー接続は現在の地域にそのまま残ります。

SSL(backend-services --protocol SSL)を介してトラフィックを受け取るようにバックエンド サービスを構成することで、SSL プロキシのデプロイに応じてエンドツーエンドの暗号化を使用することをお勧めします。これにより、SSL プロキシ層で復号化されたクライアント トラフィックは、バックエンド インスタンスに送信される前に、もう一度暗号化されるようになります。このエンドツーエンドの暗号化では、SSL 処理を行えるように、インスタンスに証明書と鍵を用意しておく必要があります。

SSL プロキシの利点

  • 高度なルーティング機能 — ロードバランサによって、容量のあるバックエンドの場所にリクエストをルーティングできます。それに対して、L3/L4 ロードバランサは容量に注意を払わずに地域のバックエンドにルーティングする必要があります。より高度なルーティングを使用すると、x*N ではなく、N+1 または N+2 でプロビジョニングできるようになります。
  • 仮想マシン インスタンスのより効率的な使用 — 使用されている暗号の CPU 効率が良くない場合、SSL 処理によって CPU に多大な負担が掛かる可能性があります。CPU パフォーマンスを最大限まで高めるために、ロードバランサとインスタンスの間の SSL に ECDSA SSL 証明書、TLS1.2、そして可能であれば ECDHE-ECDSA-AES128-GCM-SHA256 暗号化スイートを使用します。
  • 証明書の管理 — 証明書を切り替える必要がある場合、1 か所で証明書を使用している顧客を更新するだけで済みます。また、自己署名証明書を使用してインスタンスの管理オーバーヘッドを削減することもできます。
  • セキュリティー パッチ — SSL または TCP スタックで脆弱性が生じると、インスタンスが安全に保てるように、ロードバランサで自動的にパッチを適用します。

注:

  • グローバル負荷分散層とインスタンスの間で暗号化されていない TCP でトラフィックを送信するようにすると(backend-services --protocol TCP)、1 か所で SSL 証明書を管理し、インスタンスから SSL 処理をオフロードできますが、同時に、グローバル負荷分散層とインスタンスの間のセキュリティーが低下するため、そのような処理はおすすめしません。
  • SSL プロキシで HTTPS を処理することもできますが、推奨されません。HTTPS の場合は、代わりに HTTP(S)負荷分散を使用する必要があります。詳細については、よくある質問を参照してください。

次に、SSL プロキシの仕組みを説明し、複数のインスタンスにトラフィックが負荷分散されるように SSL プロキシを設定する方法について詳しく説明していきます。

SSL プロキシを使用した Google Cloud Load Balancing

グローバル負荷分散層に SSL プロキシを設定すると、SSL 接続で着信するトラフィックはグローバル層で停止され、使用可能な最も近いインスタンス グループへプロキシ処理されます。

この例では、Iowa と Boston のユーザーからのトラフィックはグローバル負荷分散層で停止され、分割された接続は選択されたバックエンド サービスに向かうように設定されます。

SSL ターミネーションを使用した Google Cloud Load Balancing(クリックして拡大)
SSL ターミネーションを使用した Google Cloud Load Balancing(クリックして拡大)

SSL 負荷分散の設定

この例は、us-central1us-east1 という 2 つの地域に存在する単純なサービスに対してグローバル SSL 負荷分散を設定する様子を示しています。次を設定します。

  1. インスタンスを保持するインスタンス グループ
  2. インスタンス グループごとのインスタンスのペア
  3. インスタンスの正常性をチェックするヘルスチェック
  4. グループ内のインスタンスをモニタリングし、設定された使用率を超過しないようにするバックエンド サービス
  5. SSL 証明書を使用する SSL プロキシ自体
  6. ユーザーのトラフィックをプロキシに送信するパブリック静的 IP アドレスと転送ルール
  7. ロードバランサ IP アドレスのファイアウォール ルール

その後、設定をテストします。

インスタンス グループとバックエンド サービスの設定

このセクションでは、簡単なインスタンス グループを作成し、それらにインスタンスを追加して、ヘルスチェックを行ってからそれらのインスタンスをバックエンド サービスに追加する方法を説明します。通常、実働システムではインスタンス テンプレートに基づいて管理対象インスタンス グループを使用しますが、初期テストにはこの設定のほうがより簡単に行えます。

バックエンド構成(クリックして拡大)
バックエンド構成(クリックして拡大)

ゾーンごとのインスタンス グループの作成

gcloud compute instance-groups unmanaged create us-ig1 --zone us-central1-b
Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-b/instanceGroups/us-ig1].
NAME   ZONE          NETWORK MANAGED INSTANCES
us-ig1 us-central1-b                 0
gcloud compute instance-groups unmanaged create us-ig2 --zone us-east1-b
Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-east1-b/instanceGroups/us-ig2].
NAME   ZONE       NETWORK MANAGED INSTANCES
us-ig2 us-east1-b                 0

各ゾーンでの 2 つのインスタンスの作成

テスト用に、各インスタンスに Apache をインストールします。通常、HTTP トラフィックには SSL 負荷分散を使用しませんが、Apache は広く使用されており、テスト用に簡単に設定できます。

これらのインスタンスはすべて ssl-lb のタグで作成されます。このタグは後でファイアウォール ルールによって使用されます。

  1. ゾーン us-central1-big-us-central1-1 を作成します。

    gcloud compute instances create ig-us-central1-1 \
        --image debian-8 \
        --tags ssl-lb \
        --zone us-central1-b \
        --metadata startup-script="#! /bin/bash
          apt-get update
          apt-get install apache2 -y
          a2ensite default-ssl
          a2enmod ssl
          service apache2 restart
          echo '<!doctype html><html><body><h1>SSL load balanced instance - US central 1</h1></body></html>' | tee /var/www/html/index.html
          EOF"
    

    Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-b/instances/ig-us-central1-1].
    NAME             ZONE          MACHINE_TYPE  PREEMPTIBLE INTERNAL_IP EXTERNAL_IP    STATUS
    ig-us-central1-1 us-central1-b n1-standard-1             10.240.0.8  23.251.150.133 RUNNING

  2. ゾーン us-central1-big-us-central1-2 を作成します。

    gcloud compute instances create ig-us-central1-2 \
        --image debian-8 \
        --tags ssl-lb \
        --zone us-central1-b \
         --metadata startup-script="#! /bin/bash
           apt-get update
           apt-get install apache2 -y
           a2ensite default-ssl
           a2enmod ssl
          service apache2 restart
           echo '<!doctype html><html><body><h1>SSL load balanced instance - US central 2</h1></body></html>' | tee /var/www/html/index.html
           EOF"
    

    Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-b/instances/ig-us-central1-2].
    NAME             ZONE          MACHINE_TYPE  PREEMPTIBLE INTERNAL_IP EXTERNAL_IP    STATUS
    ig-us-central1-2 us-central1-b n1-standard-1             10.240.0.11 23.251.148.160 RUNNING

  3. ゾーン us-east1-big-us-east1-1 を作成します。

    gcloud compute instances create ig-us-east1-1 \
        --image debian-8 \
        --tags ssl-lb \
        --zone us-east1-b \
        --metadata startup-script="#! /bin/bash
          apt-get update
          apt-get install apache2 -y
          a2ensite default-ssl
          a2enmod ssl
          service apache2 restart
          echo '<!doctype html><html><body><h1>SSL load balanced instance - US east 1</h1></body></html>' | tee /var/www/html/index.html
          EOF"
    

    Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-east1-b/instances/ig-us-east1-1].
    NAME          ZONE       MACHINE_TYPE  PREEMPTIBLE INTERNAL_IP EXTERNAL_IP    STATUS
    ig-us-east1-1 us-east1-b n1-standard-1             10.240.0.12 104.196.31.214 RUNNING

  4. ゾーン us-east1-big-us-east1-2 を作成します。

    gcloud compute instances create ig-us-east1-2 \
        --image debian-8 \
        --tags ssl-lb \
        --zone us-east1-b \
        --metadata startup-script="#! /bin/bash
          apt-get update
          apt-get install apache2 -y
          a2ensite default-ssl
          a2enmod ssl
          service apache2 restart
          echo '<!doctype html><html><body><h1>SSL load balanced instance - US east 2</h1></body></html>' | tee /var/www/html/index.html
          EOF"</pre>
    

    Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-east1-b/instances/ig-us-east1-2].
    NAME          ZONE       MACHINE_TYPE  PREEMPTIBLE INTERNAL_IP EXTERNAL_IP    STATUS
    ig-us-east1-2 us-east1-b n1-standard-1             10.240.0.13 104.196.25.101 RUNNING

インスタンス グループへのインスタンスの追加

  1. ig-us-central1-1ig-us-central1-2us-ig1 に追加します。

    gcloud compute instance-groups unmanaged add-instances us-ig1 \
        --instances ig-us-central1-1,ig-us-central1-2 \
        --zone us-central1-b
    

    Updated [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-b/instanceGroups/us-ig1].

  2. ig-us-east1-1ig-us-east1-2us-ig2 に追加します。

    gcloud compute instance-groups unmanaged add-instances us-ig2 \
        --instances ig-us-east1-1,ig-us-east1-2 \
        --zone us-east1-b
    

    Updated [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-east1-b/instanceGroups/us-ig2].

これで、それぞれが 2 つのインスタンスを持つ 2 つの異なる地域に、1 つのインスタンス グループができました。バックエンド サービスを作成する場合はヘルスチェックを指定する必要があるため、次にヘルスチェックを作成します。

ヘルスチェックの作成

インスタンスの正常性を判別するために、SSL または TCP ヘルスチェックのいずれかを設定できます。ロードバランサとインスタンスの間に SSL を使用している場合、SSL ヘルスチェックを使用します。ロードバランサとインスタンスの間に平文の TCP を使用している場合、TCP ヘルスチェックを使用します。設定が終わったら、ヘルスチェックのプローブが、設定されたインスタンス グループ内のすべてのインスタンスに指定されたポートに一定の間隔で送信されます。

この例では、バックエンド サービスとともに使用する単純な SSL ヘルスチェックを作成します。各ヘルスチェックのプローブはポート 443 上の各インスタンスと単純な SSL ハンドシェークを行い、正常性を判別します。続けて 2 回ハンドシェークに成功すると(デフォルト)、新しいインスタンスには HEALTHY のマークが付けられます。HEALTHY インスタンスでハンドシェークが続けて 2 回失敗すると(デフォルト)、そのインスタンスには UNHEALTHY のマークが付けられ、新しい接続はそのインスタンスに送信されなくなります。既存の接続は継続されます。もう一度プローブが続けて 2 回成功すると(デフォルト)、インスタンスには再度 HEALTHY のマークが付けられます。詳細な説明とオプションについては、ヘルスチェックのセクションを参照してください。

gcloud beta compute health-checks create ssl my-ssl-health-check --port 443
Created [https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/global/healthChecks/my-ssl-health-check].
NAME                PROTOCOL
my-ssl-health-check SSL

バックエンド サービスの作成

バックエンド サービスは、それに含まれているインスタンス グループの容量、最大使用率、およびヘルスチェックを定義します。

  • バックエンド サービスによって、着信するトラフィックは接続された 1 つ以上のバックエンドに送信されます(後で説明する負荷分散モードによって異なります)。各バックエンドは 1 つのインスタンス グループと、そのインスタンス グループ内のインスタンス間のトラフィックを調整する追加構成で構成されています。各インスタンス グループは、1 つ以上のインスタンスで構成されています。
  • 各バックエンド サービスは、バックエンド サービスに追加されたすべてのインスタンス グループにあるインスタンスに対して実行されるヘルスチェックも指定します。
  • ロードバランサを介したアイドル SSL プロキシ接続の存続期間は、バックエンド サービスのタイムアウトによって制限されます。

この例では、SSL を介してインスタンスに接続するバックエンド サービスを追加します。これは、ロードバランサとインスタンスの間の接続のみを制御し、ユーザーとロードバランサの間の接続は制御しません。

gcloud beta compute backend-services create my-backend-service \
    --protocol SSL \
    --health-check my-ssl-health-check \
    --timeout 5m
Created [https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/global/backendServices/my-backend-service].
NAME               BACKENDS PROTOCOL
my-backend-service          SSL

あるいは、--protocol TCP を使用して、ロードバランサからインスタンスへの暗号化されていない通信を設定することもできます。

バックエンド サービスの設定

バックエンド サービスを設定するときは、インスタンス グループを追加し、各インスタンス グループ内のインスタンスにロードバランサが送信できるトラフィック数を決定する分散モードを指定する必要があります。特定のインスタンス グループの容量に達すると、容量があり、ユーザーに次に近いインスタンス グループに、その後のリクエストが送信されます。

SSL プロキシでは、次の分散モードがサポートされています。

  • UTILIZATION (デフォルト): インスタンス グループの現在の平均 CPU 使用率が、指定された値未満であれば、インスタンスはトラフィックを受け取ることができます。この値を設定するには、--max-utilization パラメーターを使用し、0.0(0%)~1.0(100%)の値を渡します。デフォルトは 0.8(80%)です。
  • CONNECTION: 接続数が、指定された値未満であれば、インスタンスはトラフィックを受け取ることができます。この値は、次のいずれかにすることができます。
    • --max-connections: インスタンス グループ内のすべてのバックエンド インスタンスにわたる接続の最大数。
    • --max-connections-per-instance: 1 つのインスタンスが処理できる接続の最大数。グループの平均がこの数値を超えなければ、リクエストは転送されます。

分散モードを UTILIZATION に設定していても、--max-connections または --max-connections-per-instance を指定できます。--max-utilization と接続パラメーターの両方が指定されている場合、いずれかの制限に到達すると、グループはすべて使用されているとみなされます。

この例では、両方のインスタンス グループを同じバックエンド サービスに追加し、80% の使用率に到達していないインスタンス グループにトラフィックを送信する負荷分散モードを設定します。

gcloud beta compute backend-services add-backend my-backend-service \
    --instance-group us-ig1 \
    --zone us-central1-b \
    --balancing-mode UTILIZATION \
    --max-utilization 0.8
Updated [https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/global/backendServices/my-backend-service].
gcloud beta compute backend-services add-backend my-backend-service \
    --instance-group us-ig2 \
    --zone us-east1-b \
    --balancing-mode UTILIZATION \
    --max-utilization 0.8
Updated [https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/global/backendServices/my-backend-service].

フロントエンド サービスの設定

このセクションでは、次のフロントエンド リソースを作成する方法を説明します。

  • ロードバランサとともに使用する SslCertificate リソース
  • SSL プロキシ ロードバランサ
  • 静的外部 IP アドレスと、そのアドレスとともに使用する転送ルール
  • ロードバランサおよびヘルス チェッカーからのトラフィックがインスタンスに到達できるようにするファイアウォール ルール
フロントエンド構成(クリックして拡大)
フロントエンド構成(クリックして拡大)

SSL 証明書と鍵の構成

秘密鍵と署名済み証明書がない場合は、テスト用に自己署名証明書を作成したり、認証局から本物の証明書を取得したりすることができます。詳細については、SSL 証明書を参照してください。本番用ロードバランサで自己署名証明書を使用しないでください。

この手順では、証明書と鍵を取得し、SSL 証明書リソースを作成します。次の手順でそれを SSL プロキシに割り当てます。

gcloud compute ssl-certificates create my-ssl-cert \
    --certificate [CRT_FILE_PATH] \
    --private-key [KEY_FILE_PATH]
Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/sslCertificates/ssl-cert1].
NAME      CREATION_TIMESTAMP
ssl-cert1 2016-02-20T20:53:33.584-08:00

ターゲット SSL プロキシの設定

ターゲット SSL プロキシはユーザーからパケットを受け取り、それらをバックエンド サービスに送信します。ターゲット SSL プロキシを作成するときに、バックエンド サービスと SSL 証明書をそのリソースに関連付けます。PROXY プロトコル バージョン 1 ヘッダーの挿入を有効にする場合は、上記のコマンドで --proxy-header PROXY_V1 を使用して設定できます。

PROXY プロトコルの詳細については、プロキシの PROXY プロトコル ヘッダーの更新を参照してください。

gcloud beta compute target-ssl-proxies create my-target-ssl-proxy \
    --backend-service my-backend-service \
    --ssl-certificate my-ssl-cert \
    --proxy-header NONE
Created [https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/global/targetSslProxies/my-target-ssl-proxy].
NAME                PROXY_HEADER SERVICE            SSL_CERTIFICATES
my-target-ssl-proxy NONE         my-backend-service ssl-cert1

グローバル静的 IP アドレスの予約

ここで、サービス用にグローバルに予約された静的 IP アドレスを作成する必要があります。

顧客は、この IP アドレスを使用して負荷分散されたサービスにアクセスします。

gcloud compute addresses create ssl-lb-static-ip --global
Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/addresses/ssl-lb-static-ip].
NAME                 REGION ADDRESS        STATUS
ssl-lb-static-ip     [LB_STATIC_IP]        RESERVED

グローバル転送ルールの設定

グローバル転送ルールを作成して、特定の IP やポートをターゲット SSL プロキシに転送します。顧客のトラフィックが外部 IP アドレスに到達すると、この転送ルールによって、そのトラフィックを SSL プロキシに送信するようにネットワークに伝達されます。

ターゲット プロキシに関連付けられたグローバル転送ルールを作成するには、前の手順で [LB_STATIC_IP] を生成した IP アドレスに置き換えます。

gcloud beta compute forwarding-rules create my-global-forwarding-rule \
    --global \
    --target-ssl-proxy my-target-ssl-proxy \
    --address [LB_STATIC_IP] \
    --port-range 443
Created [https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/global/forwardingRules/my-global-forwarding-rule].
NAME                      REGION IP_ADDRESS     IP_PROTOCOL TARGET
my-global-forwarding-rule        [LB_STATIC_IP] TCP         my-target-ssl-proxy

SSL ロードバランサのファイアウォール ルールの作成

ロードバランサとヘルス チェッカーからインスタンスへのトラフィックを許可するファイアウォール ルールを設定します。

 gcloud compute firewall-rules create allow-ssl-130-211-0-0-22 \
     --source-ranges 130.211.0.0/22 \
     --target-tags ssl-lb \
     --allow tcp:443
Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls/allow-ssl-130-211-0-0-22].
NAME                     NETWORK SRC_RANGES     RULES   SRC_TAGS TARGET_TAGS
allow-ssl-130-211-0-0-22 default 130.211.0.0/22 tcp:443          ssl-lb

ロードバランサのテスト

ウェブブラウザで、HTTPS を介して静的 IP アドレスに接続します。このテスト設定では、インスタンスは自己署名証明書を使用します。このため、ページに初めてアクセスしたときに、ブラウザに警告が表示されます。警告は無視してクリックし、実際のページを表示してください。

https://[LB_STATIC_IP]

ユーザーに最も近い地域からいずれかのホストが表示されます。その地域の他のインスタンスが表示されるまでページをリロードします。他の地域からインスタンスを表示するには、最も近い地域でインスタンスを停止するか、それらのインスタンスで Apache を無効にします。

あるいは、ローカルマシンのコマンドラインから curl を使用することもできます。SSL プロキシで自己署名証明書を使用する場合、-k も指定する必要があります。

curl -k https://[LB_STATIC_IP]

その他のコマンド

ターゲット SSL プロキシの一覧表示

gcloud beta compute target-ssl-proxies list
NAME                PROXY_HEADER SERVICE            SSL_CERTIFICATES
my-target-ssl-proxy NONE         my-backend-service ssl-cert1

ターゲット SSL プロキシの記述

gcloud beta compute target-ssl-proxies describe my-target-ssl-proxy
creationTimestamp: '2016-02-20T20:55:17.633-08:00'
id: '9208913598676794842'
kind: compute#targetSslProxy
name: my-target-ssl-proxy
proxyHeader: NONE
selfLink: https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/global/targetSslProxies/my-target-ssl-proxy
service: https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/global/backendServices/my-backend-service
sslCertificates:
- https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/global/sslCertificates/ssl-cert1

ターゲット SSL の削除

ターゲット プロキシを削除するには、まず、そのターゲット プロキシを参照しているグローバル転送ルールを削除する必要があります。

  1. グローバル転送ルールを削除します。

    gcloud beta compute forwarding-rules delete my-global-forwarding-rule \
        --global
    

    The following global forwarding rules will be deleted:
     - [my-global-forwarding-rule]

    Do you want to continue (Y/n)? y

    Deleted [https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/global/forwardingRules/my-global-forwarding-rule].

  2. SSL プロキシを削除します。

    gcloud beta compute target-ssl-proxies delete my-target-ssl-proxy
    

    The following target ssl proxies will be deleted:
     - [my-target-ssl-proxy]

    Do you want to continue (Y/n)? y

    Deleted [https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/global/targetSslProxies/my-target-ssl-proxy].

ターゲット SSL プロキシのバックエンド サービスの更新

update コマンドを使用すると、別のバックエンド サービスで SSL プロキシを指示できます。この例では、新しいバックエンド サービスを作成し、そこでプロキシを指示します。その後、元のプロキシを指示し直します。

  1. 同じヘルスチェックを使用して、2 番目のバックエンド サービスを作成します。

    gcloud beta compute backend-services create my-other-backend-service --protocol SSL --health-check my-ssl-health-check
    

     Created [https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/global/backendServices/my-other-backend-service].
     NAME                     BACKENDS PROTOCOL
     my-other-backend-service          SSL

  2. 新しいバックエンドで SSL プロキシを指示します。

    gcloud beta compute target-ssl-proxies update my-target-ssl-proxy --backend-service my-other-backend-service
    

    Updated [https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/global/targetSslProxies/my-target-ssl-proxy].

  3. このバックエンド サービスにはインスタンスが含まれていないため、この時点でプロキシを使用しようとしても、ウェブページは取得できません。テストを続行するには、最初のバックエンド サービスで SSL プロキシを指示し直します。

    gcloud beta compute target-ssl-proxies update my-target-ssl-proxy --backend-service my-backend-service
    

    Updated [https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/global/targetSslProxies/my-target-ssl-proxy].

ターゲット SSL プロキシの SSL 証明書の更新

このコマンドを使用して、SSL プロキシで SSL 証明書を置き換えます。2 番目の SSL 証明書リソースを既に作成している必要があります。

gcloud beta compute target-ssl-proxies update my-target-ssl-proxy \
  --ssl-certificate ssl-cert2
Updated [https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/global/targetSslProxies/my-target-ssl-proxy].

プロキシの PROXY プロトコル ヘッダーの更新

このコマンドを使用して、既存のターゲット SSL プロキシの PROXY プロトコル ヘッダーを変更します。

gcloud beta compute target-ssl-proxies update my-target-ssl-proxy \
  --proxy-header [NONE | PROXY_V1]
Updated [https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/global/targetSslProxies/my-target-ssl-proxy].

クライアント接続情報を保持するための PROXY プロトコル

SSL プロキシを使用した Google Cloud Load Balancing では、クライアントからの SSL 接続が停止され、インスタンスへの新しい接続が作成されるため、デフォルトで元のクライアント IP とポート情報は保持されません。

この情報を保持し、インスタンスに送信する必要がある場合、PROXY プロトコル(バージョン 1)を有効にする必要があります。この場合、ソース IP アドレス、宛先 IP アドレス、およびポート番号などの元の接続情報を含むヘッダーがさらに追加され、リクエストの一部としてインスタンスに送信されます。

このパラメーターは、TCP および SSL ヘルスチェック用に設定することもできます。

一般に、PROXY プロトコル ヘッダーはユーザーが読み取れる単一の行であり、次のような形式になります。

PROXY TCP4 <client IP> <load balancing IP> <source port> <dest port>\r\n

PROXY プロトコルの例を以下に示します。

PROXY TCP4 192.0.2.1 198.51.100.1 15221 443\r\n

この例の場合、クライアント IP は 192.0.2.1、負荷分散 IP は 198.51.100.1、クライアント ポートは 15221、宛先ポートは 443 です。

クライアント IP が不明な場合、ロードバランサは次の形式で PROXY プロトコル ヘッダーを生成します。

PROXY UNKNOWN\r\n

ヘルスチェック

ヘルスチェックでは、どのインスタンスが新しい接続を受け取れるかが判別されます。ヘルス チェッカーは指定された間隔でインスタンスをプローブします。指定された回数続けてプローブに対する応答に失敗したインスタンスには UNHEALTHY のマークが付けられます。そのインスタンスには新しい接続は送信されませんが、既存の接続は継続できます。ヘルス チェッカーは異常なインスタンスのポーリングを続けます。インスタンスが指定された回数続けてプローブへの応答に成功すると、そのインスタンスには再度 HEALTHY のマークが付けられ、新しい接続を受け取れるようになります。

SSL または TCP ヘルスチェックのいずれかを設定して、バックエンド インスタンスの正常性を判別できます。ロードバランサとインスタンスの間に SSL を使用している場合、SSL ヘルスチェックを使用します。ロードバランサとインスタンスの間にプレーンな TCP を使用している場合、TCP ヘルスチェックを使用します。設定が完了すると、設定されたインスタンス グループ内のすべてのインスタンスに、指定されたポートを使用して一定の間隔で、ヘルスチェックのプローブが送信されます。

ヘルスチェックのタイプを SSL に設定すると、各インスタンスに SSL 接続が開かれます。ヘルスチェックをのタイプを TCP に設定すると、TCP 接続が開かれます。ヘルスチェック自体は、次のいずれかのチェックを使用できます。

  • 単純なハンドシェークによるヘルスチェック(デフォルト): ヘルス チェッカーは単純な TCP または SSL ハンドシェークを試みます。成功すると、インスタンスはプローブのラウンドに合格します。
  • リクエスト/応答によるヘルスチェック: TCP または SSL ハンドシェークを完了した、ヘルス チェッカーが送信するリクエスト ストリングを指定します。インスタンスが設定した応答ストリングを返すと、そのインスタンスはプローブのラウンドに合格します。リクエスト ストリングと応答ストリングにはどちらも最大で 1024 バイトを使用できます。

新しいインスタンスで、指定した回数続けて(デフォルトは 2 回)プローブが成功すると、そのインスタンスには HEALTHY のマークが付けられます。HEALTHY のインスタンスで、指定した回数続けて(デフォルトで 2 回)プローブに失敗すると、そのインスタンスには UNHEALTHY のマークが付けられます。指定した回数続けて(デフォルトで 2 回)プローブにもう一度成功すると、そのインスタンスには再度 HEALTHY のマークが付けられます。ヘルスチェックに失敗したインスタンス上でも、既存の接続は続行できます。

ヘルスチェックの作成

gcloud beta compute health-checks create [tcp | ssl] my-ssl-health-check \
    [--port PORT ]  \
    ...other options

ロードバランサとインスタンスの間のトラフィックを暗号化している場合、SSL ヘルスチェックを使用します。トラフィックが暗号化されていない場合、TCP ヘルスチェックを使用します。

ヘルスチェックの create オプション

  • --check-interval [CHECK_INTERVAL]; default=5s
    インスタンスにヘルスチェックのプローブを送信する頻度。たとえば、10s に設定すると、プローブは 10 秒ごとに送信されます。このフラグには、秒には s、分には m の単位を使用できます。
  • --description [DESCRIPTION]
    ヘルスチェックの説明(省略可)。文字列にスペースが含まれる場合は引用符で囲む必要があります。
  • --healthy-threshold [HEALTHY_THRESHOLD]; default=2
    ヘルスチェックのプローブが連続して成功する必要がある回数。この回数を満たさなければ、異常なインスタンスに HEALTHY のマークが付けられます。
  • --port [PORT]; default=80(TCP の場合)、443(SSL の場合)
    このヘルスチェックがモニタリングする TCP ポート番号。
  • --request
    ヘルス チェッカーがインスタンスに送信できる、最大で 1024 文字の任意の文字列。ヘルス チェッカーは、--response フィールドに指定されたストリングのインスタンスから応答を探します。 --response が設定されていない場合、ヘルス チェッカーは応答を待機せず、TCP または SSL ハンドシェークが成功すると、プローブは成功したとみなします。
  • --response
    ヘルス チェッカーがインスタンスから受け取ることを期待する、最大で 1024 文字の任意の文字列。応答が正確に受け取られなければ、ヘルスチェックのプローブは失敗します。--response は設定されているが --request は設定されていない場合、ヘルス チェッカーは応答を待機します。ハンドシェークが成功した場合の応答として、システムによって自動的になんらかのメッセージが送信される場合以外は、必ず --response--request と明確に一致するように設定します。
  • --timeout [TIMEOUT]; default=5s
    この期間内にヘルス チェッカーがインスタンスから有効な応答を受け取らなければ、プローブは失敗したとみなされます。たとえば、10s を指定すると、チェッカーは 10 秒間待ってからプローブが失敗したとみなします。このフラグには、秒には s、分には m の単位を使用できます。
  • --unhealthy-threshold [UNHEALTHY_THRESHOLD]; default=2
    ヘルスチェックのプローブが連続して失敗する回数。この値に達すると、正常なインスタンスに UNHEALTHY のマークが付けられます。
  • --proxy-header [NONE | PROXY_V1]
    ヘルスチェックに対してプロキシ プロトコル ヘッダーをアクティブ化できます。正常性をチェックし、同じポートでコンテンツを提供している場合、ロードバランサの設定と一致するようにヘルスチェックの --proxy-header を設定できます。別のポートを使用している場合、必要に応じて、これをヘルスチェック用に設定しても、しなくてもかまいません。

ヘルスチェックの一覧表示

現在のプロジェクト内のすべてのヘルスチェックを一覧表示します。

gcloud beta compute health-checks list
NAME                PROTOCOL
my-ssl-health-check SSL

ヘルスチェックの記述

特定のヘルスチェックに関する詳細情報を提供します。

gcloud beta compute health-checks describe my-ssl-health-check
checkIntervalSec: 5
creationTimestamp: '2016-02-20T20:47:26.034-08:00'
description: ''
healthyThreshold: 2
id: '1423984233044836273'
kind: compute#healthCheck
name: my-ssl-health-check
selfLink: https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/global/healthChecks/my-ssl-health-check
sslHealthCheck:
  port: 443
timeoutSec: 5
type: SSL
unhealthyThreshold: 2

ヘルスチェックの更新

ヘルスチェックでパラメーターを変更するには、次のコマンドを実行し、いずれかの create パラメーターで渡します。指定したすべてのパラメーターが変更されます。指定されていないパラメーターは、同じまま変化しません。

gcloud beta compute health-checks [tcp|ssl] update
    [--options]

例:

gcloud beta compute health-checks update ssl my-ssl-health-check \
    --description "SSL health check"
Updated [https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/global/healthChecks/my-ssl-health-check].

接続ドレイン

バックエンド サービスで接続ドレインを有効にすると、トラフィックを処理しているインスタンスが停止されたり、手動で削除されたり、自動スケーラ-によって削除されたりした場合に、ユーザーに対する中断を最小限に抑えることができます。接続ドレインの詳細については、接続ドレインの有効化を参照してください。

推奨

  • クライアントの接続情報を保持する必要がある場合、PROXY プロトコル バージョン 1 ヘッダーを先頭に追加してロードバランサを構成する必要があります。
  • トラフィックが HTTPS の場合、負荷分散には SSL プロキシではなく、HTTPS 負荷分散を使用する必要があります。

トラブルシューティング

ロードバランサの IP からページをロードできない

インスタンスの正常性の確認

インスタンスが HEALTHY であることを確認します。

gcloud beta compute backend-services get-health my-backend-service
---
backend: https://www.googleapis.com/resourceviews/v1beta1/projects/[PROJECT_ID]/zones/us-central1-b/resourceViews/us-ig1
status:
  kind: compute#backendServiceGroupHealth
---
backend: https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/zones/us-east1-b/instanceGroups/us-ig2
status:
  kind: compute#backendServiceGroupHealth

ファイアウォール ルールが正しいことの確認

  • ヘルス チェッカーとロードバランサの両方で 130.211.0.0/22 が開いている必要があります。
  • ロードバランサとインスタンスの間で SSL を実行している場合、SSL ヘルスチェックを行う必要があります。この場合、tcp:443130.211.0.0/22 からのファイアウォールで許可されている必要があります。インスタンスに対して TCP を実行している場合、TCP ヘルスチェックを行い、代わりに 130.211.0.0/22 からの tcp:80 を開きます。
  • インスタンス タグを使用している場合、ファイアウォール ルールでそのタグが TARGET_TAGS としてリストにあることを確認し、すべてのインスタンスにそのタグがあることを確認します。この例では、インスタンスには ssl-lb のタグが付けられています。

    gcloud compute firewall-rules list

    NAME                      NETWORK SRC_RANGES     RULES                        SRC_TAGS TARGET_TAGS
    allow-ssl-130-211-0-0-22  default 130.211.0.0/22 tcp:443                               ssl-lb

各インスタンスに到達可能なことの確認

インスタンスに個別にアクセスできるファイアウォール ルールを一時的に設定し、特定のインスタンスからページをロードできるか試してみます。

  1. ファイアウォールを開いて、ソースからタグ付けされたインスタンスへのトラフィックを許可します。

    gcloud compute firewall-rules create allow-ssl-0-0-0-0   \
      --source-ranges 0.0.0.0/0   \
      --target-tags ssl-lb    \
      --allow tcp:443
    

    Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls/allow-ssl-0-0-0-0].
    NAME              NETWORK SRC_RANGES RULES   SRC_TAGS TARGET_TAGS
    allow-ssl-0-0-0-0 default 0.0.0.0/0  tcp:443          ssl-lb

  2. いずれかのインスタンスの EXTERNAL_IP アドレスを見つけます。

    gcloud compute instances list
    

    NAME             ZONE           MACHINE_TYPE  PREEMPTIBLE INTERNAL_IP EXTERNAL_IP    STATUS
    ig-us-central1-1 us-central1-b  n1-standard-1             10.240.0.8  EXTERNAL_IP RUNNING
    ig-us-central1-2 us-central1-b  n1-standard-1             10.240.0.11 EXTERNAL_IP RUNNING
    ig-us-east1-1    us-east1-b     n1-standard-1             10.240.0.12 EXTERNAL_IP RUNNING
    ig-us-east1-2    us-east1-b     n1-standard-1             10.240.0.13 EXTERNAL_IP RUNNING

  3. 次に、ブラウザから直接 1 つ以上のインスタンスにアクセスします。

    https://[EXTERNAL_IP]
    
  4. この方法でインスタンスにアクセスできない場合、ソフトウェアが正しく実行されているか確認します。正しく実行されている場合、ロードバランサのファイアウォールが正しいか確認します。

    gcloud compute firewall-rules describe allow-ssl-130-211-0-0-22
    

    allowed:
    - IPProtocol: tcp
      ports:
      - '443'
    creationTimestamp: '2016-02-20T22:27:15.094-08:00'
    description: ''
    id: '5304629236729177644'
    kind: compute#firewall
    name: allow-130-211-0-0-22-ssl
    network: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/default
    selfLink: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls/allow-130-211-0-0-22-ssl
    sourceRanges:
    - 130.211.0.0/22
    targetTags:
    - ssl-lb

  5. インスタンスが機能していることを確認したら、「from anywhere」ファイアウォールを削除します。

    gcloud compute firewall-rules delete allow-ssl-0-0-0-0
    

    The following firewalls will be deleted:
     - [allow-ssl-0-0-0-0]

    Do you want to continue (Y/n)? y

    Deleted [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls/allow-ssl-0-0-0-0].

よくある質問

SSL プロキシ負荷分散ではなく HTTPS 負荷分散の使用が必要になる場合

SSL プロキシでも HTTPS トラフィックを処理できますが、HTTPS 負荷分散にはたいていの場合に選択したほうがよい追加機能が備わっています。

HTTPS 負荷分散では、次の追加機能を使用できます。

  • HTTP/2 と SPDY/3.1 をネゴシエーションします。
  • 無効な HTTP リクエストまたは応答を拒否します。
  • URL ホストおよびパスに基づいて、別のインスタンス グループにリクエストを転送します。
  • Cloud CDN と統合します。
  • インスタンス間でリクエストの負荷をより均等に分散し、インスタンスをより効率的に使用できます。HTTPS では各リクエストは別個に負荷分散されますが、SSL プロキシでは同じ SSL または TCP 接続からのすべてのバイトが同じインスタンスに送信されます。

Google Cloud Load Balancing の SSL プロキシは、Websocket over SSL や IMAP over SSL など、SSL を使用するその他のプロトコルに使用できます。

グローバル負荷分散層への接続の元の IP アドレスを表示できますか?

はい。PROXY プロトコル バージョン 1 ヘッダーを先頭に付けて、元の接続情報が維持されるようにロードバランサを設定できます。詳細については、プロキシの PROXY プロトコル ヘッダーの更新を参照してください。

外出先でもリソースをモニタリング

Google Cloud Console アプリを入手して、プロジェクトの管理にお役立てください。

フィードバックを送信...