HTTP-zu-HTTPS-Weiterleitung für externe HTTP(S)-Load-Balancer einrichten

In diesem Beispiel wird gezeigt, wie alle Anfragen an Port 80 an die entsprechenden HTTPS-Dienste weitergeleitet werden.

Informationen zum Einrichten der HTTP-zu-HTTPS-Weiterleitung für das externe Load-Balancing finden Sie unter HTTP-zu-HTTPS-Weiterleitung für externe HTTP(S)-Load-Balancer einrichten.

Wenn Sie HTTP-zu-HTTPS-Weiterleitungen mit einer freigegebenen IP-Adresse verwenden möchten, 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 und eine eigene URL-Zuordnung, aber dieselbe IP-Adresse. Für den HTTP-Load-Balancer müssen Sie kein Back-End konfigurieren, da das Front-End Traffic an das Back-End des HTTPS-Load-Balancers weiterleitet.

Dieses Beispiel zeigt, wie Sie alle Anfragen von Port 80 an Port 443 weiterleiten.

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 internen HTTPS-Load-Balancer, um zu prüfen, ob er funktioniert.
Leiten Sie Traffic an den internen HTTPS-Load-Balancer weiter.
Dazu müssen Sie einen partiellen internen HTTP-Load-Balancer mit einem Front-End, aber keine Back-Ends hinzufügen. Das Front-End empfängt Anfragen und leitet sie dann an den internen HTTPS-Load-Balancer weiter. Dafür wird Folgendes verwendet:
- Eine Weiterleitungsregel mit der reservierten internen IP-Adresse, die Ihr HTTPS-Load-Balancer verwendet (im ersten Schritt beschrieben)
- Ein Ziel-HTTP-Proxy
- Eine URL-Zuordnung, die Traffic zum HTTPS-Load-Balancer leitet

Wie im folgenden Diagramm dargestellt, ist der interne HTTPS-Load-Balancer ein normaler Load-Balancer mit den erwarteten Load-Balancer-Komponenten.

Der HTTP-Load-Balancer hat dieselbe IP-Adresse wie der HTTPS-Load-Balancer, eine Weiterleitungsweisung in der URL-Zuordnung und kein Back-End.

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

Internen HTTPS-Load-Balancer erstellen

Dieser Vorgang ähnelt dem Einrichten eines internen HTTP(S)-Load-Balancers.

Die Einrichtung für das interne HTTP(S)-Load-Balancing besteht aus zwei Teilen:

Erforderliche Aufgaben wie Prüfen notwendiger Konten auf die richtigen Berechtigungen und Vorbereiten des VPC-Netzwerks (Virtual Private Cloud) ausführen
Load-Balancer-Ressourcen einrichten

Bevor Sie diese Anleitung durcharbeiten, sollten Sie sich mit Folgendem vertraut machen:

Übersicht über das interne HTTP(S) -Load-Balancing, einschließlich des Abschnitts Einschränkungen
Übersicht über VPC-Firewallregeln

Berechtigungen

Damit Sie dieser Anleitung folgen können, müssen Sie in der Lage sein, Instanzen zu erstellen und ein Netzwerk in einem Projekt zu ändern. Sie müssen entweder Inhaber oder Bearbeiter des Projekts sein oder alle folgenden Compute Engine-IAM-Rollen haben.

Aufgabe	Erforderliche Rolle
Netzwerke, Subnetze und Load-Balancer-Komponenten erstellen	Netzwerkadministrator
Firewallregeln hinzufügen und löschen	Sicherheitsadministrator
Instanzen erstellen	Instanzadministrator

Weitere Informationen finden Sie in folgenden Leitfäden:

Netzwerk und Subnetze konfigurieren

Sie benötigen ein VPC-Netzwerk mit zwei Subnetzen: eines für die Back-Ends des Load-Balancers und eines für die Proxys des Load-Balancers. Ein interner HTTP(S)-Load-Balancer ist regional. Traffic innerhalb des VPC-Netzwerks wird an den Load-Balancer weitergeleitet, wenn sich die Quelle des Traffics in einem Subnetz in derselben Region wie der Load-Balancer befindet.

In diesem Beispiel werden das folgende VPC-Netzwerk, die folgende Region und die folgenden Subnetze verwendet:

Netzwerk. Das Netzwerk ist ein VPC-Netzwerk im benutzerdefinierten Modus mit dem Namen lb-network.
Subnetz für Back-Ends. Ein Subnetz mit dem Namen backend-subnet in der Region us-west1 verwendet 10.1.2.0/24 für seinen primären IP-Bereich.
Subnetz für Proxys Ein Subnetz mit dem Namen proxy-only-subnet in der Region us-west1 verwendet 10.129.0.0/23 für seinen primären IP-Bereich.

Netzwerk und Subnetz für Back-Ends konfigurieren

Console

Rufen Sie in der Google Cloud Console die VPC-Netzwerkseite auf.
Zur VPC-Netzwerkseite
Klicken Sie auf VPC-Netzwerk erstellen.
Geben Sie im Feld Name lb-network ein.
Im Bereich Subnetze:
- Legen Sie Modus für Subnetzerstellung auf Benutzerdefiniert fest.
- Geben Sie im Bereich Neues Subnetz folgende Informationen ein:
  - Name: backend-subnet
  - Region: us-west1
  - IP-Adressbereich: 10.1.2.0/24
- Klicken Sie auf Fertig.
Klicken Sie auf Erstellen.

gcloud

Erstellen Sie mit dem Befehl gcloud compute networks create das benutzerdefinierte VPC-Netzwerk:
```
gcloud compute networks create lb-network --subnet-mode=custom
```

Erstellen Sie mit dem Befehl gcloud compute networks subnets create ein Subnetz im Netzwerk lb-network in der Region us-west1:

gcloud compute networks subnets create backend-subnet \
    --network=lb-network \
    --range=10.1.2.0/24 \
    --region=us-west1

API

Stellen Sie eine POST-Anfrage an die Methode networks.insert und ersetzen Sie PROJECT_ID dabei durch Ihre Projekt-ID.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks

{
  "routingConfig": {
    "routingMode": "REGIONAL"
  },
  "name": "lb-network",
  "autoCreateSubnetworks": false
}

Stellen Sie eine POST-Anfrage an die Methode subnetworks.insert und ersetzen Sie PROJECT_ID dabei durch Ihre Projekt-ID.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks

{
  "name": "backend-subnet",
  "network": "projects/project-id/global/networks/lb-network",
  "ipCidrRange": "10.1.2.0/24",
  "region": "projects/project-id/regions/us-west1",
}

Nur-Proxysubnetz konfigurieren

Das Nur-Proxysubnetz ist für alle internen HTTP(S)-Load-Balancer in der Region us-west1 bestimmt.

Console

Wenn Sie die Google Cloud Console verwenden, können Sie das Nur-Proxy-Subnetz später auf der Seite "Load-Balancing" erstellen.

gcloud

Erstellen Sie das Nur-Proxy-Subnetz mit dem Befehl gcloud compute networks subnets create.

gcloud compute networks subnets create proxy-only-subnet \
  --purpose=INTERNAL_HTTPS_LOAD_BALANCER \
  --role=ACTIVE \
  --region=us-west1 \
  --network=lb-network \
  --range=10.129.0.0/23

API

Erstellen Sie das Nur-Proxysubnetz mit der Methode subnetworks.insert und ersetzen Sie PROJECT_ID dabei durch Ihre Projekt-ID.

POST https://compute.googleapis.com/compute/projects/PROJECT_ID/regions/us-west1/subnetworks

{
  "name": "proxy-only-subnet",
  "ipCidrRange": "10.129.0.0/23",
  "network": "projects/project-id/global/networks/lb-network",
  "region": "projects/project-id/regions/us-west1",
  "purpose": "INTERNAL_HTTPS_LOAD_BALANCER",
  "role": "ACTIVE"
}

Firewallregeln konfigurieren

In diesem Beispiel werden die folgenden Firewallregeln verwendet:

fw-allow-ssh: Eine Regel für eingehenden Traffic, die für die Instanzen mit Load-Balancing gilt und eingehende SSH-Verbindungen über TCP-Port 22 von jeder Adresse aus ermöglicht. Sie können einen restriktiveren IP-Quellbereich für diese Regel auswählen. Geben Sie dazu beispielsweise nur die IP-Bereiche des Systems an, von dem aus Sie SSH-Sitzungen initiieren. In diesem Beispiel wird das Ziel-Tag allow-ssh verwendet.
fw-allow-health-check. Eine Regel für eingehenden Traffic, die für die Instanzen mit Load-Balancing gilt und Traffic von den Google Cloud-Systemen für Systemdiagnosen zulässt (130.211.0.0/22 und 35.191.0.0/16). In diesem Beispiel wird das Ziel-Tag load-balanced-backend verwendet.
fw-allow-proxies. Eine Regel für eingehenden Traffic, die für die Instanzen mit Load-Balancing gilt und TCP-Traffic über Port 80, 443und 8080 von den verwalteten Proxys des internen HTTP(S)-Load-Balancers zulässt. In diesem Beispiel wird das Ziel-Tag load-balanced-backend verwendet.

Ohne diese Firewallregeln blockiert die Standardregel zum Ablehnen von eingehendem Traffic den eingehenden Traffic zu den Back-End-Instanzen.

Die Back-End-Instanzen werden von den Ziel-Tags definiert. Ohne die Ziel-Tags gelten die Firewallregeln für alle Ihre Back-End-Instanzen im VPC-Netzwerk. Achten Sie beim Erstellen der Back-End-VMs darauf, die angegebenen Ziel-Tags wie in Verwaltete Instanzgruppe erstellen beschrieben zu verwenden.

Console

Rufen Sie in der Google Cloud Console die Seite "Firewallregeln" auf.
Zur Seite "Firewallregeln"
Klicken Sie auf Firewallregel erstellen, um die Regel zu erstellen, die eingehende SSH-Verbindungen zulässt:
- Name: fw-allow-ssh
- Netzwerk: lb-network
- Trafficrichtung: Eingehend
- Aktion bei Übereinstimmung: Zulassen
- Ziele: Angegebene Ziel-Tags
- Zieltags: allow-ssh
- Quellfilter: IP-Bereiche.
- Quell-IP-Bereiche: 0.0.0.0/0
- Protokolle und Ports:
  - Wählen Sie Angegebene Protokolle und Ports aus.
  - Klicken Sie das Kästchen tcp an und geben Sie 22 als Portnummer ein.
Klicken Sie auf Erstellen.
Klicken Sie ein zweites Mal auf Firewallregel erstellen, um die Regel zum Zulassen von Google Cloud-Systemdiagnosen zu erstellen:
- Name: fw-allow-health-check
- Netzwerk: lb-network
- Trafficrichtung: Eingehend
- Aktion bei Übereinstimmung: Zulassen
- Ziele: Angegebene Ziel-Tags
- Zieltags: load-balanced-backend
- Quellfilter: IP-Bereiche.
- Quell-IP-Bereiche: 130.211.0.0/22 und 35.191.0.0/16
- Protokolle und Ports:
  - Wählen Sie Angegebene Protokolle und Ports aus.
  - Klicken Sie das Kästchen tcp an und geben Sie 80 als Portnummer ein.
    Sie sollten diese Regeln nur auf Protokolle und Ports beschränken, die mit den von Ihren Systemdiagnosen verwendeten übereinstimmen. Wenn Sie tcp:80 für das Protokoll und den Port verwenden, kann Google Cloud HTTP auf Port 80 verwenden, um Ihre VMs zu kontaktieren. Es kann HTTPS jedoch nicht auf Port 443 verwenden, um den Kontakt herzustellen.
Klicken Sie auf Erstellen.
Klicken Sie ein drittes Mal auf Firewallregel erstellen, um die Regel zu erstellen, die Verbindungen von den Proxyservern des Load-Balancers zu den Back-Ends zulässt:
- Name: fw-allow-proxies
- Netzwerk: lb-network
- Trafficrichtung: Eingehend
- Aktion bei Übereinstimmung: Zulassen
- Ziele: Angegebene Ziel-Tags
- Zieltags: load-balanced-backend
- Quellfilter: IP-Bereiche.
- Quell-IP-Bereiche: 10.129.0.0/23
- Protokolle und Ports:
  - Wählen Sie Angegebene Protokolle und Ports aus.
  - Klicken Sie das Kästchen tcp an und geben Sie 80, 443, 8080 als Portnummer ein.
Klicken Sie auf Erstellen.

gcloud

Erstellen Sie die Firewallregel fw-allow-ssh, um SSH-Verbindungen zu VMs mit dem Netzwerk-Tag allow-ssh zu ermöglichen. Wenn Sie source-ranges weglassen, bezieht Google Cloud die Regel auf jede Quelle.
```
gcloud compute firewall-rules create fw-allow-ssh \
    --network=lb-network \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22
```
Erstellen Sie die Regel fw-allow-health-check, um Google Cloud-Systemdiagnosen zuzulassen. In diesem Beispiel wird der gesamte TCP-Traffic von Systemdiagnosetests zugelassen. Sie können jedoch Ihren Anforderungen entsprechend eine kleinere Gruppe von Ports konfigurieren:
```
gcloud compute firewall-rules create fw-allow-health-check \
    --network=lb-network \
    --action=allow \
    --direction=ingress \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --target-tags=load-balanced-backend \
    --rules=tcp
```
Erstellen Sie die Regel fw-allow-proxies, um Verbindungen von den Proxys des internen HTTP(S)-Load-Balancers zu Ihren Back-Ends zuzulassen. Legen Sie für source-ranges die zugewiesenen Bereiche des Nur-Proxy-Subnetzes fest, z. B. 10.129.0.0/23.
```
gcloud compute firewall-rules create fw-allow-proxies \
  --network=lb-network \
  --action=allow \
  --direction=ingress \
  --source-ranges=source-range \
  --target-tags=load-balanced-backend \
  --rules=tcp:80,tcp:443,tcp:8080
```

API

Erstellen Sie die Firewallregel fw-allow-ssh, indem Sie eine POST-Anfrage an die Methode firewalls.insert senden und dabei PROJECT_ID durch Ihre Projekt-ID ersetzen.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
  "name": "fw-allow-ssh",
  "network": "projects/project-id/global/networks/lb-network",
  "sourceRanges": [
    "0.0.0.0/0"
  ],
  "targetTags": [
    "allow-ssh"
  ],
  "allowed": [
   {
     "IPProtocol": "tcp",
     "ports": [
       "22"
     ]
   }
  ],
 "direction": "INGRESS"
}

Erstellen Sie die Firewallregel fw-allow-health-check, indem Sie eine POST-Anfrage an die Methode firewalls.insert senden und dabei PROJECT_ID durch Ihre Projekt-ID ersetzen.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
  "name": "fw-allow-health-check",
  "network": "projects/project-id/global/networks/lb-network",
  "sourceRanges": [
    "130.211.0.0/22",
    "35.191.0.0/16"
  ],
  "targetTags": [
    "load-balanced-backend"
  ],
  "allowed": [
    {
      "IPProtocol": "tcp"
    }
  ],
  "direction": "INGRESS"
}

Erstellen Sie die Firewallregel fw-allow-proxies, um TCP-Traffic im Proxysubnetz für die Methode firewalls.insert zuzulassen. Ersetzen Sie dabei PROJECT_ID durch Ihre Projekt-ID.

POST https://compute.googleapis.com/compute/v1/projects/{project}/global/firewalls

{
  "name": "fw-allow-proxies",
  "network": "projects/project-id/global/networks/lb-network",
  "sourceRanges": [
    "10.129.0.0/23"
  ],
  "targetTags": [
    "load-balanced-backend"
  ],
  "allowed": [
    {
      "IPProtocol": "tcp",
      "ports": [
        "80"
      ]
    },
  {
      "IPProtocol": "tcp",
      "ports": [
        "443"
      ]
    },
    {
      "IPProtocol": "tcp",
      "ports": [
        "8080"
      ]
    }
  ],
  "direction": "INGRESS"
}

Ressourcen für den internen HTTPS-Load-Balancer erstellen

In diesem Beispiel werden VM-Back-Ends in Compute Engine in einer verwalteten Instanzgruppe verwendet. Sie können stattdessen andere unterstützte Back-End-Typen verwenden.

Instanzvorlage mit einem HTTP-Server erstellen

gcloud

gcloud compute instance-templates create l7-ilb-backend-template \
    --region=us-west1 \
    --network=lb-network \
    --subnet=backend-subnet \
    --tags=allow-ssh,load-balanced-backend \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --metadata=startup-script='#! /bin/bash
    apt-get update
    apt-get install apache2 -y
    a2ensite default-ssl
    a2enmod ssl
    vm_hostname="$(curl -H "Metadata-Flavor:Google" \
    http://169.254.169.254/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    systemctl restart apache2'

Verwaltete Instanzgruppe in der Zone erstellen

gcloud

gcloud compute instance-groups managed create l7-ilb-backend \
    --zone=us-west1-a \
    --size=2 \
    --template=l7-ilb-backend-template

HTTP-Systemdiagnose erstellen

gcloud

gcloud compute health-checks create http l7-ilb-basic-check \
     --region=us-west1 \
     --use-serving-port

Back-End-Dienste erstellen

gcloud

gcloud compute backend-services create l7-ilb-backend-service \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --protocol=HTTP \
    --health-checks=l7-ilb-basic-check \
    --health-checks-region=us-west1 \
    --region=us-west1

Back-Ends zum Back-End-Dienst hinzufügen

gcloud

gcloud compute backend-services add-backend l7-ilb-backend-service \
    --balancing-mode=UTILIZATION \
    --instance-group=l7-ilb-backend \
    --instance-group-zone=us-west1-a \
    --region=us-west1

URL-Zuordnung erstellen

gcloud

gcloud compute url-maps create l7-ilb-service-url-map \
    --default-service=l7-ilb-backend-service \
    --region=us-west1

Regionales SSL-Zertifikat erstellen

Im folgenden Beispiel wird gezeigt, wie Sie mit gcloud ein selbstverwaltetes SSL-Zertifikat erstellen. Weitere Informationen finden Sie unter Selbstverwaltete SSL-Zertifikate verwenden und Von Google verwaltete SSL-Zertifikate verwenden.

gcloud

gcloud compute ssl-certificates create CERTIFICATE_NAME \
    --certificate=CERTIFICATE_FILE \
    --private-key=PRIVATE_KEY_FILE \
    --region=us-west1

Mit dem regionalen SSL-Zertifikat einen Zielproxy erstellen

gcloud

gcloud compute target-https-proxies create l7-ilb-https-proxy \
    --url-map=l7-ilb-service-url-map \
    --region=us-west1 \
    --ssl-certificates=l7-ilb-cert

Freigegebene IP-Adresse für die Weiterleitungsregeln reservieren

gcloud

gcloud beta compute addresses create \
    --addresses=10.1.2.99 \
    --region=us-west1 \
    --subnet=backend-subnet \
    --purpose=SHARED_LOADBALANCER_VIP

HTTPS-Weiterleitungsregel erstellen

gcloud

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

HTTPS-Load-Balancer testen

An dieser Stelle ist der Load-Balancer (einschließlich Back-End-Dienst, URL-Zuordnung und Weiterleitungsregel) bereit. Testen Sie diesen Load-Balancer, um zu prüfen, ob er wie erwartet funktioniert.

Erstellen Sie eine Client-VM-Instanz zum Testen der Konnektivität.

gcloud

gcloud compute instances create l7-ilb-client-us-west1-a \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --network=lb-network \
    --subnet=backend-subnet \
    --zone=us-west1-a \
    --tags=allow-ssh

Stellen Sie eine SSH-Verbindung zur Client-VM her.

gcloud

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

Stellen Sie mithilfe von Curl eine Verbindung zum HTTPS-Load-Balancer her.

curl -k -s 'https://10.1.2.99:443' --connect-to 10.1.2.99:443

Beispielausgabe:

Page served from: l7-ilb-backend-850t

Senden Sie 100 Anfragen und prüfen Sie, ob für alle Load-Balancing ausgeführt wurde.

{
  RESULTS=
  for i in {1..100}
  do
      RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.99:443)"
  done
  echo "***"
  echo "*** Results of load-balancing to 10.1.2.99: "
  echo "***"
  echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
  echo
}

Beispielausgabe:

***
*** Results of load-balancing to 10.1.2.99:
***
     51  l7-ilb-backend-https-850t
     49  l7-ilb-backend-https-w11t
    100 Page served from

Traffic an den HTTPS-Load-Balancer weiterleiten

Der HTTP-Load-Balancer hat eine freigegebene IP-Adresse, die Traffic von Port 80 an 443 weiterleitet.

Neue URL-Zuordnung zum Weiterleiten von Traffic erstellen

Erstellen Sie eine YAML-Datei mit der Konfiguration der Trafficweiterleitung.

echo "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: 10.1.2.99:443
        pathRedirect: /
        redirectResponseCode: PERMANENT_REDIRECT
        httpsRedirect: True
        stripQuery: True" > /tmp/url_map.yaml

Importieren Sie die YAML-Datei in eine neue URL-Zuordnung.

gcloud

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

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

Neue Weiterleitungsregel und freigegebene IP-Adresse erstellen

gcloud

gcloud compute forwarding-rules create l7-ilb-forwarding-rule \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=lb-network \
    --subnet=backend-subnet \
    --address=10.1.2.99 \
    --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

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

Senden Sie eine HTTP-Anfrage an 10.1.2.99 auf Port 80 und erwarten Sie eine Trafficweiterleitung.

curl -L -k 10.1.2.99

Eine Beispielausgabe.

Page served from: l7-ilb-backend-w11t

Sie können -vvv hinzufügen, um weitere Details aufzurufen.

curl -L -k 10.1.2.99 -vvv

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

Nächste Schritte

Informationen zur Funktionsweise des internen HTTP(S)-Load-Balancings finden Sie unter Übersicht über das Interne HTTP(S)-Load-Balancing.
Informationen zum Verwalten der Nur-Proxy-Subnetzressource, die für das interne HTTP(S)-Load-Balancing erforderlich ist, finden Sie unter Nur-Proxy-Subnetz für interne HTTP(S)-Load-Balancer.
Einrichtung des Load-Balancers bereinigen