Wie können Sie von HTTP auf HTTPS umleiten, wenn IAP mit GCP Load Balancern konfiguriert ist?

Wie können Sie von HTTP auf HTTPS umleiten, wenn IAP mit GCP Load Balancern konfiguriert ist?

Ich habe derzeit eine Website, die auf Google Compute Engine gehostet wird und mit Identity-Aware-Proxy authentifiziert wird, der sich hinter einem Load Balancer befindet. Das alles funktioniert über https hervorragend, aber ich wollte sicherstellen, dass http auf https umleitet, da es derzeit nur mit einer 404-Fehlermeldung antwortet.

Ich folgte alsohttps://cloud.google.com/load-balancing/docs/https/setting-up-http-https-redirectHier werden Sie aufgefordert, einen zweiten Load Balancer einzurichten, um den HTTP-Verkehr auf HTTPS umzuleiten.

Das Problem ist jedoch, dass nach dem Befolgen dieser Anweisungen, wenn ich zuhttp://meine-website.comIch erhalte die folgende Fehlermeldung:

Fehler 403 (Verboten)!!1

  1. Das ist ein Fehler.

Ihr Client hat keine Berechtigung, die URL / von diesem Server abzurufen. Das ist alles, was wir wissen.

Obwohl der HTTP-Load Balancer mit einer 301 - Moved Permanently Full Path Redirect eingerichtet ist, erfolgt auf der Registerkarte „Netzwerk“ der Browser-Entwicklertools keine Umleitung. Es wird einfach sofort mit der 403-Antwort geantwortet. Die URL bleibt auch beim http://-Schema.


Zusammenfassend sieht mein Setup so aus:

Externer HTTPS-Load Balancer

  • Frontend – HTTPS, statische IP, nur HTTPS
  • Backend - Identity-Aware-Proxy (E-Mail-Authentifizierung über Identity Platform) -> Compute Engine-Instanzgruppe

Externer HTTP-Load Balancer

  • Frontend – HTTP, statische IP (dasselbe wie HTTPS Load Balancer oben)
  • Backend - Keines
  • Host- und Pfadregeln:
    • Modus:Erweiterte Host- und Pfadregeln (URL-Umleitung, URL-Umschreibung)
    • Aktion:Leiten Sie den Client auf einen anderen Host/Pfad um.
    • Host-Umleitung: https://meine-website.com
    • Pfadwert:*
    • Umleitungsantwortcode:301 - Dauerhaft verschoben
    • HTTPS-Weiterleitung:Ermöglicht

Ich bin für alle Ideen dankbar, wie sich das Problem beheben lässt und die 403-Fehlermeldung vermieden wird.

Antwort1

Die Art und Weise, wie Sie beschriebenes sieht so aus, als ob Sie ein Problem mit der URL-Map habenhttpweil Sie auf die Version Ihrer Site zugreifen können .

Um ganz sicher zu gehen, überprüfen Sie noch einmal (oderErstelle neu) URL-Map mit gcloudBefehl:

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

Wenn Ihre URL-Zuordnung fertig ist, erstellen Sie einen Zielproxy:

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

Ergebnis:

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

und eine Weiterleitungsregel:

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

das sollte so aussehen:

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

Stellen Sie sicher, dass Sie für HTTP- und HTTPS-LBs dieselbe öffentliche IP verwenden. Überprüfen Sie die Firewall-Regeln, damit der eingehende Datenverkehr nicht blockiert wird.

Wenn Sie alles richtig machen, sollten Sie dieselbe curlAusgabe erhalten, wie im Beispiel dargestellt.

verwandte Informationen