内部 HTTP(S) ロードバランサでの HTTP から HTTPS へのリダイレクトの設定

この例では、ポート 80 へのすべてのリクエストがそれぞれの HTTPS サービスにリダイレクトされる方法を示しています。

外部負荷分散に HTTP から HTTPS へのリダイレクトを設定する方法については、外部 HTTP(S) ロードバランサの HTTP から HTTPS へのリダイレクトを設定するをご覧ください。

HTTP から HTTPS へのリダイレクトを共有 IP アドレスで使用するには、HTTPS トラフィック用と HTTP トラフィック用の 2 つのロードバランサを作成する必要があります。各ロードバランサには独自の転送ルールと URL マップがありますが、IP アドレスは共通です。HTTP ロードバランサの場合、フロントエンドは HTTPS ロードバランサのバックエンドにトラフィックをリダイレクトするため、バックエンドを構成する必要はありません。

次の例は、すべてのリクエストをポート 80 からポート 443 にリダイレクトする方法を示しています。

HTTP トラフィックを HTTPS にリダイレクトするには、次のことを行う必要があります。

  1. 予約済みの共有内部 IP アドレスを使用して、通常の内部 HTTPS ロードバランサを作成します。
  2. 内部 HTTPS ロードバランサをテストして、機能していることを確認します。
  3. トラフィックを内部 HTTPS ロードバランサにリダイレクトします。
    これを行うには、フロントエンドを持つ部分的な内部 HTTP ロードバランサを追加する必要があります。フロントエンドは、受信したリクエストを内部 HTTPS ロードバランサにリダイレクトします。この処理では次のものが使用されます。
    • HTTPS ロードバランサと同じ予約済みの内部 IP アドレスを使用して転送ルール(手順 1 を参照)
    • ターゲット HTTP プロキシ
    • HTTPS ロードバランサにトラフィックをリダイレクトする URL マップ

次の図のように、HTTPS ロードバランサは、想定されるロードバランサ コンポーネントを含む通常のロードバランサです。

HTTP ロードバランサには、HTTPS ロードバランサと同じ IP アドレスが設定され、URL マップにリダイレクト命令が指定されています。

内部 HTTP から HTTPS へのリダイレクト構成(クリックして拡大)
内部 HTTP から HTTPS へのリダイレクト構成

内部 HTTPS ロードバランサの作成

このプロセスは、内部 HTTP(S) ロードバランサの設定と同様です。

内部 HTTP(S) 負荷分散の設定は、次の 2 つの部分に分かれます。

  • 前提となる作業を行う(必要なアカウントに適切な権限を付与し、Virtual Private Cloud(VPC)ネットワークを準備するなど)。
  • ロードバランサのリソースを設定する。

このガイドに進む前に、次の内容を理解しておいてください。

権限

このガイドに従うには、プロジェクト内でインスタンスを作成してネットワークを変更できる必要があります。そのためにはプロジェクトのオーナーまたは編集者であるか、または次の Compute Engine IAM のロールをすべて持っている必要があります。

タスク 必要なロール
ネットワーク、サブネット、負荷分散コンポーネントの作成 ネットワーク管理者
ファイアウォール ルールの追加と削除 セキュリティ管理者
インスタンスの作成 インスタンス管理者

詳細については、次のガイドをご覧ください。

ネットワークとサブネットの構成

ロードバランサのバックエンド用とロードバランサのプロキシ用の 2 つのサブネットが存在する VPC ネットワークが必要です。内部 HTTP(S) ロードバランサはリージョンです。VPC ネットワーク内のトラフィックは、送信元がロードバランサと同じリージョンのサブネット内にある場合、ロードバランサに転送されます。

この例では、次の VPC ネットワーク、リージョン、サブネットを使用します。

  • ネットワーク。ネットワークは、lb-network という名前のカスタムモードの VPC ネットワークです。

  • バックエンドのサブネット。us-west1 リージョンの backend-subnet という名前のサブネット。プライマリ IP 範囲として 10.1.2.0/24 を使用します。

  • プロキシのサブネット。us-west1 リージョンの proxy-only-subnet という名前のサブネット。プライマリ IP 範囲として 10.129.0.0/23 を使用します。

バックエンドのネットワークとサブネットの構成

Console

  1. Google Cloud Console で [VPC ネットワーク] ページに移動します。
    [VPC ネットワーク] ページに移動
  2. [VPC ネットワークを作成] をクリックします。
  3. [名前] に「lb-network」と入力します。
  4. [サブネット] セクションで次の設定を行います。
    • [サブネット作成モード] を [カスタム] に設定します。
    • [新しいサブネット] セクションに、次の情報を入力します。
      • 名前: backend-subnet
      • リージョン: us-west1
      • IP アドレス範囲: 10.1.2.0/24
    • [完了] をクリックします。
  5. [作成] をクリックします。

gcloud

  1. gcloud compute networks create コマンドを使用してカスタム VPC ネットワークを作成します。

    gcloud compute networks create lb-network --subnet-mode=custom
    
  2. gcloud compute networks subnets create コマンドを使用して、us-west1 リージョンの lb-network ネットワークにサブネットを作成します。

    gcloud compute networks subnets create backend-subnet \
        --network=lb-network \
        --range=10.1.2.0/24 \
        --region=us-west1
    

API

networks.insert メソッドに POST リクエストを送ります。PROJECT_ID は実際のプロジェクト ID に置き換えます。

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks

{
  "routingConfig": {
    "routingMode": "REGIONAL"
  },
  "name": "lb-network",
  "autoCreateSubnetworks": false
}

subnetworks.insert メソッドに POST リクエストを送ります。PROJECT_ID は実際のプロジェクト ID に置き換えます。

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks

{
  "name": "backend-subnet",
  "network": "projects/project-id/global/networks/lb-network",
  "ipCidrRange": "10.1.2.0/24",
  "region": "projects/project-id/regions/us-west1",
}

プロキシ専用サブネットの構成

このプロキシ専用サブネットは、us-west1 リージョン内のすべての内部 HTTP(S) ロードバランサのためのサブネットです。

Console

Google Cloud Console を使用している場合は、しばらく待ってから、負荷分散ページでプロキシ専用サブネットを作成できます。

gcloud

gcloud compute networks subnets create コマンドを使用して、プロキシ専用サブネットを作成します。

gcloud compute networks subnets create proxy-only-subnet \
  --purpose=INTERNAL_HTTPS_LOAD_BALANCER \
  --role=ACTIVE \
  --region=us-west1 \
  --network=lb-network \
  --range=10.129.0.0/23

API

subnetworks.insert メソッドを使用してプロキシ専用サブネットを作成します。PROJECT_ID は実際のプロジェクト ID に置き換えます。

POST https://compute.googleapis.com/compute/projects/PROJECT_ID/regions/us-west1/subnetworks

{
  "name": "proxy-only-subnet",
  "ipCidrRange": "10.129.0.0/23",
  "network": "projects/project-id/global/networks/lb-network",
  "region": "projects/project-id/regions/us-west1",
  "purpose": "INTERNAL_HTTPS_LOAD_BALANCER",
  "role": "ACTIVE"
}

ファイアウォール ルールの構成

この例では、次のファイアウォール ルールを使用します。

  • fw-allow-ssh負荷分散されたインスタンスに適用される内向きルール。任意のアドレスから TCP ポート 22 への SSH 接続を許可します。このルールには、送信元の IP 範囲をより限定的に指定できます。たとえば、SSH セッションを開始するシステムの IP 範囲を指定できます。この例では、ターゲットタグ allow-ssh を使用しています。

  • fw-allow-health-check負荷分散されているインスタンスに適用される上り(内向き)ルール。Google Cloud ヘルスチェック システム(130.211.0.0/2235.191.0.0/16)からのすべての TCP トラフィックを許可します。この例では、ターゲットタグ load-balanced-backend を使用しています。

  • fw-allow-proxies負荷分散されているインスタンスに適用される上り(内向き)ルール。内部 HTTP(S) ロードバランサが管理するプロキシからポート 804438080 への TCP トラフィックを許可します。この例では、ターゲットタグ load-balanced-backend を使用しています。

これらのファイアウォール ルールがない場合は、デフォルトの上り拒否ルールによってバックエンド インスタンスへの受信トラフィックがブロックされます。

ターゲットタグは、バックエンド インスタンスを定義します。ターゲットタグがない場合、ファイアウォール ルールは VPC ネットワーク内のすべてのバックエンド インスタンスに適用されます。バックエンド VM を作成する場合は、マネージド インスタンス グループの作成の説明に沿って、指定したターゲットタグを忘れずに含めてください。

Console

  1. Google Cloud Console の [ファイアウォール ルール] ページに移動します。
    [ファイアウォール ルール] ページに移動
  2. [ファイアウォール ルールを作成] をクリックして、SSH 接続の受信を許可するルールを作成します。
    • 名前: fw-allow-ssh
    • ネットワーク: lb-network
    • トラフィックの方向: 上り(内向き)
    • 一致したときのアクション: 許可
    • ターゲット: 指定されたターゲットタグ
    • ターゲットタグ: allow-ssh
    • ソースフィルタ: IP 範囲
    • 送信元 IP 範囲: 0.0.0.0/0
    • プロトコルとポート:
      • 指定されたプロトコルとポートを選択します。
      • [tcp] チェックボックスをオンにして、ポート番号に「22」と入力します。
  3. [作成] をクリックします。
  4. [ファイアウォール ルールを作成] をもう一度クリックして、Google Cloud ヘルスチェックを許可するルールを作成します。
    • 名前: fw-allow-health-check
    • ネットワーク: lb-network
    • トラフィックの方向: 上り(内向き)
    • 一致したときのアクション: 許可
    • ターゲット: 指定されたターゲットタグ
    • ターゲットタグ: load-balanced-backend
    • ソースフィルタ: IP 範囲
    • 送信元 IP 範囲: 130.211.0.0/2235.191.0.0/16
    • プロトコルとポート:
      • 指定されたプロトコルとポートを選択します。
      • [tcp] チェックボックスをオンにして、ポート番号に「80」と入力します。
        このルールは、ヘルスチェックに使用されているプロトコルとポートのみに制限することをおすすめします。プロトコルとポートに tcp:80 を使用すると、Google Cloud はポート 80 で HTTP を使用して VM に接続できますが、ポート 443 では HTTPS を使用して VM に接続することはできません。
  5. [作成] をクリックします。
  6. [ファイアウォール ルールを作成] をもう一度クリックをして、ロードバランサのプロキシ サーバーがバックエンドに接続できるようにするルールを作成します:
    • 名前: fw-allow-proxies
    • ネットワーク: lb-network
    • トラフィックの方向: 上り(内向き)
    • 一致したときのアクション: 許可
    • ターゲット: 指定されたターゲットタグ
    • ターゲットタグ: load-balanced-backend
    • ソースフィルタ: IP 範囲
    • 送信元 IP 範囲: 10.129.0.0/23
    • プロトコルとポート:
      • 指定されたプロトコルとポートを選択します。
      • [tcp] チェックボックスをオンにして、ポート番号に「80, 443, 8080」と入力します。
  7. [作成] をクリックします。

gcloud

  1. ネットワーク タグ allow-ssh を使用して、VM との SSH 接続を許可する fw-allow-ssh ファイアウォール ルールを作成します。source-ranges を省略すると、Google Cloud は任意の送信元としてルールを解釈します。

    gcloud compute firewall-rules create fw-allow-ssh \
        --network=lb-network \
        --action=allow \
        --direction=ingress \
        --target-tags=allow-ssh \
        --rules=tcp:22
    
  2. Google Cloud ヘルスチェックを許可する fw-allow-health-check ルールを作成します。この例では、ヘルスチェック プローブからのすべての TCP トラフィックを許可します。ただし、必要に応じてポートの範囲を狭く構成することもできます。

    gcloud compute firewall-rules create fw-allow-health-check \
        --network=lb-network \
        --action=allow \
        --direction=ingress \
        --source-ranges=130.211.0.0/22,35.191.0.0/16 \
        --target-tags=load-balanced-backend \
        --rules=tcp
    
  3. 内部 HTTP(S) ロードバランサのプロキシにバックエンドへの接続を許可する fw-allow-proxies ルールを作成します。source-ranges を、プロキシ専用サブネットの割り振り範囲に設定します(例: 10.129.0.0/23)。

    gcloud compute firewall-rules create fw-allow-proxies \
      --network=lb-network \
      --action=allow \
      --direction=ingress \
      --source-ranges=source-range \
      --target-tags=load-balanced-backend \
      --rules=tcp:80,tcp:443,tcp:8080
    

API

firewalls.insert メソッドに POST リクエストを送り、fw-allow-ssh ファイアウォール ルールを作成します。PROJECT_ID は実際のプロジェクト ID に置き換えます。

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
  "name": "fw-allow-ssh",
  "network": "projects/project-id/global/networks/lb-network",
  "sourceRanges": [
    "0.0.0.0/0"
  ],
  "targetTags": [
    "allow-ssh"
  ],
  "allowed": [
   {
     "IPProtocol": "tcp",
     "ports": [
       "22"
     ]
   }
  ],
 "direction": "INGRESS"
}

firewalls.insert メソッドに POST リクエストを送り、fw-allow-health-check ファイアウォール ルールを作成します。PROJECT_ID は実際のプロジェクト ID に置き換えます。

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
  "name": "fw-allow-health-check",
  "network": "projects/project-id/global/networks/lb-network",
  "sourceRanges": [
    "130.211.0.0/22",
    "35.191.0.0/16"
  ],
  "targetTags": [
    "load-balanced-backend"
  ],
  "allowed": [
    {
      "IPProtocol": "tcp"
    }
  ],
  "direction": "INGRESS"
}

firewalls.insert メソッドのプロキシ サブネット内で TCP トラフィックを許可する fw-allow-proxies ファイアウォール ルールを作成します。PROJECT_ID は、実際のプロジェクト ID に置き換えます。

POST https://compute.googleapis.com/compute/v1/projects/{project}/global/firewalls

{
  "name": "fw-allow-proxies",
  "network": "projects/project-id/global/networks/lb-network",
  "sourceRanges": [
    "10.129.0.0/23"
  ],
  "targetTags": [
    "load-balanced-backend"
  ],
  "allowed": [
    {
      "IPProtocol": "tcp",
      "ports": [
        "80"
      ]
    },
  {
      "IPProtocol": "tcp",
      "ports": [
        "443"
      ]
    },
    {
      "IPProtocol": "tcp",
      "ports": [
        "8080"
      ]
    }
  ],
  "direction": "INGRESS"
}

内部 HTTPS ロードバランサ リソースを作成する

この例では、マネージド インスタンス グループ内の Compute Engine 上の仮想マシン バックエンドを使用します。代わりに、他のサポートされているバックエンド タイプを使用することもできます。

HTTP サーバーを使用してインスタンス テンプレートを作成する

gcloud

gcloud compute instance-templates create l7-ilb-backend-template \
    --region=us-west1 \
    --network=lb-network \
    --subnet=backend-subnet \
    --tags=allow-ssh,load-balanced-backend \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --metadata=startup-script='#! /bin/bash
    apt-get update
    apt-get install apache2 -y
    a2ensite default-ssl
    a2enmod ssl
    vm_hostname="$(curl -H "Metadata-Flavor:Google" \
    http://169.254.169.254/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    systemctl restart apache2'

ゾーンにマネージド インスタンス グループを作成する

gcloud

gcloud compute instance-groups managed create l7-ilb-backend \
    --zone=us-west1-a \
    --size=2 \
    --template=l7-ilb-backend-template

HTTP ヘルスチェックを作成する

gcloud

gcloud compute health-checks create http l7-ilb-basic-check \
     --region=us-west1 \
     --use-serving-port

バックエンド サービスを作成する

gcloud

gcloud compute backend-services create l7-ilb-backend-service \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --protocol=HTTP \
    --health-checks=l7-ilb-basic-check \
    --health-checks-region=us-west1 \
    --region=us-west1

バックエンド サービスにバックエンドを追加する

gcloud

gcloud compute backend-services add-backend l7-ilb-backend-service \
    --balancing-mode=UTILIZATION \
    --instance-group=l7-ilb-backend \
    --instance-group-zone=us-west1-a \
    --region=us-west1

URL マップの作成

gcloud

gcloud compute url-maps create l7-ilb-service-url-map \
    --default-service=l7-ilb-backend-service \
    --region=us-west1

リージョン SSL 証明書を作成する

次の例は、gcloud を使用してセルフマネージド SSL 証明書を作成する方法を示しています。詳細については、セルフマネージド SSL 証明書の使用および Google マネージド SSL 証明書の使用をご覧ください。

gcloud

gcloud compute ssl-certificates create CERTIFICATE_NAME \
    --certificate=CERTIFICATE_FILE \
    --private-key=PRIVATE_KEY_FILE \
    --region=us-west1

リージョン SSL 証明書を使用してターゲット プロキシを作成する

gcloud

gcloud compute target-https-proxies create l7-ilb-https-proxy \
    --url-map=l7-ilb-service-url-map \
    --region=us-west1 \
    --ssl-certificates=l7-ilb-cert

転送ルール用の共有 IP アドレスを予約する

gcloud

gcloud beta compute addresses create \
    --addresses=10.1.2.99 \
    --region=us-west1 \
    --subnet=backend-subnet \
    --purpose=SHARED_LOADBALANCER_VIP

HTTPS 転送ルールを作成する

gcloud

gcloud compute forwarding-rules create l7-ilb-https-forwarding-rule \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=lb-network \
    --subnet=backend-subnet \
    --address=10.1.2.99 \
    --ports=443 \
    --region=us-west1 \
    --target-https-proxy=l7-ilb-https-proxy \
    --target-https-proxy-region=us-west1

HTTPS ロードバランサをテストする

この時点で、ロードバランサ(バックエンド サービス、URL マップ、転送ルールを含む)の準備は完了しています。このロードバランサをテストして、期待どおりに動作することを確認します。

クライアント VM インスタンスを作成して接続をテストします。

gcloud

gcloud compute instances create l7-ilb-client-us-west1-a \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --network=lb-network \
    --subnet=backend-subnet \
    --zone=us-west1-a \
    --tags=allow-ssh

SSH 経由でクライアント VM に接続します。

gcloud

gcloud compute ssh l7-ilb-client-us-west1-a \
    --zone=us-west1-a

Curl を使用して HTTPS ロードバランサに接続します。

curl -k -s 'https://10.1.2.99:443' --connect-to 10.1.2.99:443

出力例:

Page served from: l7-ilb-backend-850t

100 個のリクエストを送信し、すべて負荷分散されていることを確認します。

{
  RESULTS=
  for i in {1..100}
  do
      RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.99:443)"
  done
  echo "***"
  echo "*** Results of load-balancing to 10.1.2.99: "
  echo "***"
  echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
  echo
}

出力例:

***
*** Results of load-balancing to 10.1.2.99:
***
     51  l7-ilb-backend-https-850t
     49  l7-ilb-backend-https-w11t
    100 Page served from

HTTPS ロードバランサにトラフィックをリダイレクトする

HTTP ロードバランサには、ポート 80 から 443 にトラフィックをリダイレクトする共有 IP アドレスがあります。

トラフィックのリダイレクト用に新しい URL マップを作成する

トラフィック リダイレクト構成を含む YAML ファイルを作成します。

defaultService: regions/us-west1/backendServices/l7-ilb-backend-service
kind: compute#urlMap
name: l7-ilb-redirect-url-map
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- name: matcher1
  defaultUrlRedirect:
        hostRedirect: 10.1.2.99:443
        pathRedirect: /
        redirectResponseCode: PERMANENT_REDIRECT
        httpsRedirect: True

YAML ファイルを新しい URL マップにインポートします。

gcloud

gcloud compute url-maps import l7-ilb-redirect-url-map \
    --source=/tmp/url_map.yaml \
    --region=us-west1

HTTP ロードバランサのターゲット プロキシを作成する

gcloud

gcloud compute target-http-proxies create l7-ilb-http-proxy \
    --url-map=l7-ilb-redirect-url-map \
    --region=us-west1

新しい転送ルールと共有 IP アドレスを作成する

gcloud

gcloud compute forwarding-rules create l7-ilb-forwarding-rule \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=lb-network \
    --subnet=backend-subnet \
    --address=10.1.2.99 \
    --ports=80 \
    --region=us-west1 \
    --target-http-proxy=l7-ilb-http-proxy \
    --target-http-proxy-region=us-west1

トラフィックのリダイレクトをテストする

クライアント VM に接続します。

gcloud

gcloud compute ssh l7-ilb-client-us-west1-a \
    --zone=us-west1-a

トラフィックがリダイレクトされることを想定して、ポート 80 の 10.1.2.99 に HTTP リクエストを送信します。

curl -L -k 10.1.2.99

出力例。

Page served from: l7-ilb-backend-w11t

-vvv を追加すると、詳細が表示されます。

curl -L -k 10.1.2.99 -vvv

* Rebuilt URL to: 10.1.2.99/
*   Trying 10.1.2.99...
* TCP_NODELAY set
* Connected to 10.1.2.99 (10.1.2.99) port 80 (#0)
> GET / HTTP/1.1
> Host: 10.1.2.99
> User-Agent: curl/7.52.1
> Accept: */*
>
< HTTP/1.1 308 Permanent Redirect
< location: https://10.1.2.99:443/
< date: Fri, 07 Aug 2020 05:07:18 GMT
< via: 1.1 google
< content-length: 0
<
* Curl_http_done: called premature == 0
* Connection #0 to host 10.1.2.99 left intact
* Issue another request to this URL: 'https://10.1.2.99:443/'
*   Trying 10.1.2.99...
* TCP_NODELAY set
* Connected to 10.1.2.99 (10.1.2.99) port 443 (#1)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
...
...
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: O=Google TESTING; CN=test_cert_1
*  start date: Jan  1 00:00:00 2015 GMT
*  expire date: Jan  1 00:00:00 2025 GMT
*  issuer: O=Google TESTING; CN=Intermediate CA
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x561a6b0e3ea0)
> GET / HTTP/1.1
> Host: 10.1.2.99
> User-Agent: curl/7.52.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200
< date: Fri, 07 Aug 2020 05:07:18 GMT
< server: Apache/2.4.25 (Debian)
< last-modified: Thu, 06 Aug 2020 13:30:21 GMT
< etag: "2c-5ac357d7a47ec"
< accept-ranges: bytes
< content-length: 44
< content-type: text/html
< via: 1.1 google
<
Page served from: l7-ilb-backend-https-w11t
* Curl_http_done: called premature == 0
* Connection #1 to host 10.1.2.99 left intact

次のステップ