☰

IAP が GCP ロードバランサで構成されている場合に、HTTP から HTTPS にリダイレクトするにはどうすればよいですか?

tag-icon • tag-icon https http http-status-code-403 google-cloud-http-load-balancer
IAP が GCP ロードバランサで構成されている場合に、HTTP から HTTPS にリダイレクトするにはどうすればよいですか?

現在、私は Google Compute Engine でホストされている Web サイトを持っていますが、これはロード バランサーの背後にある Identity-Aware-Proxy で認証されています。これはすべて https 経由ではうまく機能しますが、現在は 404 で応答するだけなので、http が https にリダイレクトされるようにしたいと考えていました。

そこで私はhttps://cloud.google.com/load-balancing/docs/https/setting-up-http-https-redirectこれは、http トラフィックを https にリダイレクトするための 2 番目のロード バランサーを設定するように指示します。

しかし、問題は、これらの手順を実行した後、http://my-website.com次のエラーが発生します:

エラー 403 (禁止)!!1

  1. それはエラーです。

クライアントにはこのサーバーから URL / を取得する権限がありません。わかっているのはこれだけです。

http ロード バランサは 301 - Moved Permanently Full path Redirect で設定されていますが、ブラウザ開発者ツールのネットワーク タブではリダイレクトは発生しません。 403 ですぐに応答します。 URL も http:// スキームのままです。

要約すると、私の設定は次のようになります。

外部 HTTPS ロードバランサ

  • フロントエンド - HTTPS、静的 IP、HTTPS のみ
  • バックエンド - Identity-Aware-Proxy（Identity Platform 経由のメール認証） -> Compute Engine インスタンス グループ

外部 HTTP ロードバランサ

  • フロントエンド - HTTP、静的 IP (上記の HTTPS ロード バランサと同じ)
  • バックエンド - なし
  • ホストとパスのルール:
    • モード：高度なホストとパスのルール (URL リダイレクト、URL 書き換え)
    • アクション：クライアントを別のホスト/パスにリダイレクトする
    • ホストリダイレクト: https://my-website.com
    • パス値:*
    • リダイレクト応答コード:301 - 永久に移動
    • HTTPS リダイレクト:有効

これを修正して 403 が出ないようにするアイデアがあれば、ぜひ教えてください。

答え1

あなたが説明したようにurl-mapに問題があるようですhttpサイトのバージョンにアクセスできるためです。

確実にするために、もう一度確認してください（または新しく作る) コマンドで url-map を実行しますgcloud:

gcloud compute url-maps describe web-map-http

creationTimestamp: '2020-12-02T03:18:27.053-08:00'
defaultUrlRedirect:
  httpsRedirect: true
  redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
fingerprint: KU2hPu1ao=
id: '50586028237895404'
kind: compute#urlMap
name: web-map-http
selfLink: https://www.googleapis.com/compute/v1/projects/xxxxx/global/urlMaps/web-map-http

URL マップの準備ができたら、ターゲット プロキシを作成します。

gcloud compute target-http-proxies create http-lb-proxy \
   --url-map=web-map-http \
   --global

結果：

gcloud compute target-http-proxies describe http-lb-proxy
creationTimestamp: '2020-12-02T03:19:39.090-08:00'
fingerprint: lgJkIY8E=
id: '3781119498457764'
kind: compute#targetHttpProxy
name: http-lb-proxy
selfLink: https://www.googleapis.com/compute/v1/projects/xxxx/global/targetHttpProxies/http-lb-proxy
urlMap: https://www.googleapis.com/compute/v1/projects/xxxx/global/urlMaps/web-map-http

転送ルール:

gcloud compute forwarding-rules create http-content-rule \
   --address=lb-ipv4-1 \ # Same IP address used for HTTPS load balancer
   --global \
   --target-http-proxy=http-lb-proxy \
   --ports=80

それは次のようになります:

gcloud compute forwarding-rules describe http-content-rule --global
IPAddress: 34.107.123.141
IPProtocol: TCP
creationTimestamp: '2020-12-02T03:22:38.132-08:00'
description: ''
fingerprint: L1vA0Ik9Y=
id: '888330202637841'
kind: compute#forwardingRule
loadBalancingScheme: EXTERNAL
name: http-content-rule
networkTier: PREMIUM
portRange: 80-80
selfLink: https://www.googleapis.com/compute/v1/projects/xxxx/global/forwardingRules/http-content-rule
target: https://www.googleapis.com/compute/v1/projects/xxxx/global/targetHttpProxies/http-lb-proxy

HTTP LB と HTTPS LB の両方に同じパブリック IP を使用していることを確認してください。着信トラフィックがブロックされない場合は、ファイアウォール ルールを確認してください。

curlすべてを正しく実行すると、例に示されているのと同じ出力が得られるはずです。

関連情報