このページは Cloud Translation API によって翻訳されました。

リージョン内部アプリケーションロードバランサの HTTP から HTTPS へのリダイレクトを設定する

このトピックでは、URL マップリダイレクトを使用して、すべての内部ロードバランサリクエストを HTTP から HTTPS にリダイレクトする方法について説明します。このページの例では、既知のポート 80（HTTP の場合）と 443（HTTPS の場合）を使用しています。ただし、これらの特定のポート番号を使用する必要はありません。アプリケーションロードバランサの転送ルールでは、1～65535 の単一ポートを参照できます。

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

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

予約済みの共有内部 IP アドレスを使用して、通常の内部 HTTPS ロードバランサを作成します。
ロードバランサが機能していることを確認します。
トラフィックを HTTPS ロードバランサにリダイレクトします。

これを行うには、フロントエンドのみを持つ部分的な内部 HTTP ロードバランサを作成する必要があります。フロントエンドはリクエストを受信し、次のリソースを使用して HTTPS ロードバランサにリダイレクトします。
- 手順 1 で作成した HTTPS ロードバランサと同じ予約済み内部 IP アドレスを持つ転送ルール
- ターゲット HTTP プロキシ
- HTTPS ロードバランサにトラフィックをリダイレクトする URL マップ

次の図に示すように、HTTPS ロードバランサは、想定される内部アプリケーションロードバランサコンポーネントを備えた通常のロードバランサです。

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

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

リージョン内部アプリケーションロードバランサは、内部アプリケーションロードバランサの設定の手順で設定します。

すでに機能しているリージョン内部アプリケーションロードバランサがある場合は、転送ルールに予約済みの共有 IP アドレスがあることを確認してから、次のセクションの HTTPS ロードバランサにトラフィックをリダイレクトするをご覧ください。

クロスリージョン内部アプリケーションロードバランサの場合は、VM インスタンスグループバックエンドを使用したクロスリージョン内部アプリケーションロードバランサを設定するの手順に沿って 2 つのロードバランサを作成し、HTTPS ロードバランサにトラフィックをリダイレクトするの説明に従って操作します。

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

前の手順で作成した HTTPS ロードバランサと同じ IP アドレスを持つ部分的な HTTP ロードバランサを作成します。部分的なロードバランサは、ポート 80 からポート 443 にトラフィックをリダイレクトします。

コンソール

構成を開始する

Google Cloud コンソールで、[ロードバランシング] ページに移動します。

[ロードバランシング] に移動
[ロードバランサを作成] をクリックします。
[ロードバランサの種類] で [アプリケーションロードバランサ（HTTP / HTTPS）] を選択し、[次へ] をクリックします。
[インターネット接続または内部] で [内部] を選択し、[次へ] をクリックします。
[クロスリージョンまたはシングルリージョンのデプロイ] で [リージョンワークロードに最適] を選択し、[次へ] をクリックします。
[構成] をクリックします。

基本構成

ロードバランサの名前に「l7-ilb-http-redirect」と入力します。
[リージョン] で、us-west1 を選択します。
[ネットワーク] で lb-network を選択します。

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

[バックエンドの構成] をクリックします。
バックエンドサービスの選択メニューで、既存のバックエンドサービス l7-ilb-backend-service を選択します。
[OK] をクリックします。

URL マップの構成

[ルーティングルール] をクリックします。
[モード] で、[詳細なホストとパスのルール] を選択します。
[ホストとパスのルールを追加] をクリックします。
[ホスト] を * に設定します。

[パスマッチャー（一致、アクション、サービス）] に、次のコードを入力します。

name: matcher1
defaultUrlRedirect:
  httpsRedirect: true
  hostRedirect: IP_ADDRESS:443
  redirectResponseCode: PERMANENT_REDIRECT

l7-ilb-backend-service が、ホストとパスが一致しなかった場合に使用される唯一のバックエンドサービスであることを確認します。

トラフィック管理の詳細については、内部アプリケーションロードバランサのトラフィック管理を設定するをご覧ください。

HTTP 用にフロントエンドを構成する

[フロントエンドの構成] をクリックします。
転送ルールの名前を l7-ilb-forwarding-rule に設定します。
[プロトコル] を HTTP に設定します。
[サブネットワーク] を [backend-subnet] に設定します。
[ポート] を 80 に設定します。
[IP アドレス] メニューで、HTTPS ロードバランサ転送ルール用に予約されている共有 IP アドレスを選択します。
[完了] をクリックします。

構成を確認する

[確認と完了] をクリックします。
ロードバランサの構成を確認します。
省略可: [同等のコード] をクリックして、ロードバランサの作成に使用する REST API リクエストを表示します。
[作成] をクリックします。

gcloud

トラフィックリダイレクト構成を含む YAML ファイルを作成して、新しい URL マップを作成します。IP_ADDRESS は、HTTPS ロードバランサ転送ルール用に予約された共有 IP アドレスに置き換えます。

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: IP_ADDRESS:443
       redirectResponseCode: PERMANENT_REDIRECT
       httpsRedirect: True

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

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

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

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

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

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

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

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

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

ポート 80 で IP_ADDRESS に HTTP リクエストを送信し、トラフィックリダイレクトが行われるかどうか確認します。
```
curl -L -k IP_ADDRESS
```

サンプル出力を表示します。

Page served from: l7-ilb-backend-w11t

詳細を確認するには、-vvv を追加します。

curl -L -k IP_ADDRESS -vvv



Rebuilt URL to: IP_ADDRESS/
Trying IP_ADDRESS...
TCP_NODELAY set
Connected to IP_ADDRESS (IP_ADDRESS) port 80 (#0)
> GET / HTTP/1.1
> Host: IP_ADDRESS
> User-Agent: curl/7.52.1
> Accept: /
>
< HTTP/1.1 308 Permanent Redirect
< location: https://IP_ADDRESS: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 IP_ADDRESS left intact
Issue another request to this URL: 'https://IP_ADDRESS:443/'
Trying IP_ADDRESS...
TCP_NODELAY set
Connected to IP_ADDRESS (IP_ADDRESS) 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: IP_ADDRESS
> 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 IP_ADDRESS left intact

次のステップ

内部アプリケーションロードバランサの仕組みを確認する。内部アプリケーションロードバランサの概要をご覧ください。
内部アプリケーションロードバランサに必要なプロキシ専用サブネットのリソースを管理するには、内部アプリケーションロードバランサのプロキシ専用サブネットをご覧ください。
ロードバランサの設定をクリーンアップする。

リージョン内部アプリケーション ロードバランサの HTTP から HTTPS へのリダイレクトを設定する