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 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 und eine Weiterleitungsanweisung in der URL-Zuordnung.
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 Regionus-west1
verwendet10.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 Regionus-west1
verwendet10.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
- Name:
- 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 Netzwerklb-network
in der Regionus-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-Proxy-Subnetz 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.
Führen Sie die folgenden Schritte aus, wenn Sie jetzt das Nur-Proxy-Subnetz erstellen möchten:
- Rufen Sie in der Cloud Console die Seite VPC-Netzwerke auf:
Zur Seite "VPC-Netzwerke" - Klicken Sie auf den Namen des freigegebenen VPC-Netzwerks:
lb-network
. - Klicken Sie auf Subnetz hinzufügen.
- Geben Sie im Feld Name
proxy-only-subnet
ein. - Wählen Sie
us-west1
als Region aus. - Setzen Sie Zweck auf Regional verwalteter Proxy.
- Geben Sie
10.129.0.0/23
als IP-Adressbereich ein. - Klicken Sie auf Hinzufügen.
gcloud
Erstellen Sie das Nur-Proxy-Subnetz mit dem Befehl gcloud compute networks subnets
create
.
gcloud compute networks subnets create proxy-only-subnet \ --purpose=REGIONAL_MANAGED_PROXY \ --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": "REGIONAL_MANAGED_PROXY", "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-Port22
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-Tagallow-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
und35.191.0.0/16
). In diesem Beispiel wird das Ziel-Tagload-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 Port80
,443
und8080
von den verwalteten Proxys des internen HTTP(S)-Load-Balancers zulässt. In diesem Beispiel wird das Ziel-Tagload-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: IPv4-Bereiche.
- IPv4-Quellbereiche:
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.
- Name:
- 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: IPv4-Bereiche.
- IPv4-Quellbereiche:
130.211.0.0/22
und35.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 Sietcp:80
für das Protokoll und den Port verwenden, kann Google Cloud HTTP auf Port80
verwenden, um Ihre VMs zu kontaktieren. Es kann HTTPS jedoch nicht auf Port443
verwenden, um den Kontakt herzustellen.
- Name:
- 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: IPv4-Bereiche.
- IPv4-Quellbereiche:
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.
- Name:
- Klicken Sie auf Erstellen.
gcloud
Erstellen Sie die Firewallregel
fw-allow-ssh
, um SSH-Verbindungen zu VMs mit dem Netzwerk-Tagallow-ssh
zu ermöglichen. Wenn Siesource-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ürsource-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_ID/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 compute addresses create NAME \ --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.
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
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 \ --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.