HTTP-zu-HTTPS-Weiterleitung für regionale interne Application Load Balancer einrichten

In diesem Thema erfahren Sie, wie Sie Weiterleitungen von URL-Zuordnungen verwenden, um alle internen Anfragen des Application Load Balancers von HTTP zu HTTPS weiterzuleiten. Im Beispiel auf dieser Seite werden die bekannten Ports 80 (für HTTP) und 443 (für HTTPS) verwendet. Sie müssen diese spezifischen Portnummern jedoch nicht verwenden. Jede Weiterleitungsregel für einen Application Load Balancer kann auf einen einzelnen Port von 1–65535 verweisen.

Um HTTP-zu-HTTPS-Weiterleitungen zu konfigurieren, müssen Sie zwei Load-Balancer erstellen, einen für HTTPS-Traffic und einen für HTTP-Traffic. Jeder Load Balancer hat eine eigene Weiterleitungsregel, einen eigenen Zielproxy und eine eigene URL-Zuordnung, aber dieselbe IP-Adresse. Für den HTTP-Load Balancer müssen Sie kein Backend konfigurieren, da das Frontend Traffic an das Backend des HTTPS-Load Balancers weiterleitet.

Auf übergeordneter Ebene führen Sie folgende Schritte aus, um HTTP-Traffic an HTTPS weiterzuleiten:

Erstellen Sie einen normalen internen HTTPS-Load Balancer mit einer reservierten, freigegebenen internen IP-Adresse.
Testen Sie den Load Balancer, um zu prüfen, ob er funktioniert.
Leiten Sie Traffic an den HTTPS-Load-Balancer weiter.

Dazu müssen Sie einen partiellen internen HTTP-Load Balancer erstellen, der nur ein Frontend hat. Das Frontend empfängt Anfragen und leitet sie dann mithilfe der folgenden Ressourcen an den HTTPS-Load Balancer weiter:
- Eine Weiterleitungsregel mit der reservierten internen IP-Adresse wie der HTTPS-Load Balancer, den Sie in Schritt 1 erstellt haben
- Ein Ziel-HTTP-Proxy
- Eine URL-Zuordnung, die Traffic zum HTTPS-Load-Balancer leitet

Wie im folgenden Diagramm dargestellt, ist der HTTPS-Load Balancer ein regulärer Load Balancer mit den erwarteten Komponenten des internen Load-Balancers.

Der HTTP-Load-Balancer hat dieselbe IP-Adresse wie der HTTPS-Load-Balancer und eine Weiterleitungsanweisung in der URL-Zuordnung.

Konfiguration der internen HTTP-zu-HTTPS-Weiterleitung (zum Vergrößern klicken).

Internen HTTPS-Load-Balancer erstellen

Folgen Sie der Anleitung unter Internen Application Load Balancer einrichten, um einen regionalen internen Application Load Balancer einzurichten.

Wenn Sie bereits einen funktionierenden regionalen internen Application Load Balancer haben, achten Sie darauf, dass er eine reservierte, freigegebene IP-Adresse für die Weiterleitungsregel hat, und fahren Sie dann mit dem nächsten Abschnitt, Traffic an den HTTPS-Load Balancer weiterleiten, weiter.

Für regionenübergreifende interne Application Load Balancer verwenden Sie die Anleitung unter Regionenübergreifenden internen Application Load Balancer mit VM-Instanzgruppen-Back-Ends einrichten, um zwei Load Balancer zu erstellen. Folgen Sie dann der Anleitung unter Traffic an den HTTPS-Load Balancer weiterleiten.

Traffic an den HTTPS-Load-Balancer weiterleiten

Erstellen Sie einen partiellen HTTP-Load Balancer mit derselben IP-Adresse wie der im vorherigen Schritt erstellte HTTPS-Load Balancer. Der partielle Load Balancer leitet den Traffic von Port 80 zu Port 443 weiter.

Console

Konfiguration starten

Rufen Sie in der Google Cloud Console die Seite Load-Balancing auf.

Load-Balancing aufrufen
Klicken Sie auf Load-Balancer erstellen.
Wählen Sie unter Typ des Load Balancers die Option Application Load Balancer (HTTP/HTTPS) aus und klicken Sie auf Weiter.
Wählen Sie für Öffentlich oder intern die Option Intern aus und klicken Sie auf Weiter.
Wählen Sie für Regionenübergreifende oder Einzelregion-Bereitstellung die Option Am besten für regionale Arbeitslasten aus und klicken Sie auf Weiter.
Klicken Sie auf Konfigurieren.

Grundlegende Konfiguration

Geben Sie l7-ilb-http-redirect als Name für den Load-Balancer ein.
Wählen Sie bei Region die Option us-west1 aus.
Wählen Sie für Netzwerk die Option lb-network aus.

Backend-Dienst konfigurieren

Klicken Sie auf Backend-Konfiguration.
Wählen Sie im Menü Backend-Dienste auswählen den vorhandenen Backend-Dienst l7-ilb-backend-service aus.
Klicken Sie auf OK.

URL-Zuordnung konfigurieren

Klicken Sie auf Routingregeln.
Wählen Sie unter Modus die Option Erweiterte Host- und Pfadregel aus.
Klicken Sie auf Host- und Pfadregel hinzufügen.
Legen Sie für Hosts * fest.

Geben Sie unter Tool zur Abgleichung von Pfaden (Übereinstimmungen, Aktionen und Dienste) den folgenden Code ein:

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

Achten Sie darauf, dass l7-ilb-backend-service der einzige Backend-Dienst für alle nicht übereinstimmenden Hosts und alle nicht übereinstimmenden Pfade ist.

Informationen zur Trafficverwaltung finden Sie unter Trafficverwaltung für interne Application Load Balancer einrichten.

Frontend für HTTP konfigurieren

Klicken Sie auf Frontend-Konfiguration.
Legen Sie den Namen der Weiterleitungsregel auf l7-ilb-forwarding-rule fest.
Legen Sie für Protokoll den Wert HTTP fest.
Setzen Sie die Option Subnetzwerk auf backend-subnet.
Legen Sie als Port 80 fest.
Wählen Sie im Menü IP-Adresse die freigegebene IP-Adresse aus, die für die Weiterleitungsregel des HTTPS-Load Balancers reserviert war.
Klicken Sie auf Fertig.

Konfiguration prüfen

Klicken Sie auf Prüfen und abschließen.
Prüfen Sie die Konfigurationseinstellungen des Load-Balancers.
Optional: Klicken Sie auf Entsprechender Code, um die REST API-Anfrage aufzurufen, die zum Erstellen des Load-Balancers verwendet wird.
Klicken Sie auf Erstellen.

gcloud

Erstellen Sie eine neue URL-Zuordnung. Erstellen Sie dazu eine YAML-Datei mit der Konfiguration der Trafficweiterleitung. Ersetzen Sie IP_ADDRESS durch die freigegebene IP-Adresse, die für die Weiterleitungsregel des HTTPS-Load Balancers reserviert war.

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

Importieren Sie die YAML-Datei in die neue URL-Zuordnung:

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

Zielproxy des HTTP-Load-Balancers erstellen:

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

Neue Weiterleitungsregel und freigegebene IP-Adresse erstellen

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

Trafficweiterleitung testen

Stellen Sie eine Verbindung zur Client-VM her.

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

Senden Sie eine HTTP-Anfrage an IP_ADDRESS an Port 80 und erwarten Sie eine Trafficweiterleitung.
```
curl -L -k IP_ADDRESS
```

Sehen Sie sich die Beispielausgabe an.

Page served from: l7-ilb-backend-w11t

Fügen Sie -vvv hinzu, um weitere Details aufzurufen.

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

Nächste Schritte

Informationen zur Funktionsweise von internen Application Load Balancern finden Sie unter Übersicht über internen Application Load Balancer.
Informationen zum Verwalten der Nur-Proxy-Subnetzressource, die für interne Application Load Balancer erforderlich ist, finden Sie unter Nur-Proxy-Subnetz für interne Application Load Balancer.
Einrichtung des Load-Balancers bereinigen