このトピックでは、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
次のステップ
内部アプリケーション ロードバランサの仕組みを確認する。内部アプリケーション ロードバランサの概要をご覧ください。
内部アプリケーション ロードバランサに必要なプロキシ専用サブネットのリソースを管理するには、内部アプリケーション ロードバランサのプロキシ専用サブネットをご覧ください。