SSL-Proxy-Load-Balancing – Übersicht

SSL-Proxy-Load-Balancing ist ein Reverse-Proxy-Load-Balancer, der SSL-Traffic aus dem Internet auf VM-Instanzen in Ihrem Google Cloud VPC-Netzwerk verteilt.

Wenn Sie das SSL-Proxy-Load-Balancing für Ihren SSL-Traffic verwenden, werden SSL-(TLS-)Verbindungen von Nutzern auf der Load-Balancing-Ebene terminiert und dann über SSL (empfohlen) oder TCP zu den nächstgelegenen verfügbaren Back-End-Instanzen weitergeleitet. Informationen zu den unterstützten Back-Ends finden Sie unter Back-Ends.

Auf der Premium-Stufe kann das SSL-Proxy-Load-Balancing als globaler Load-Balancing-Dienst konfiguriert werden. Bei der Standardstufe führt der SSL-Proxy-Load-Balancer das Load-Balancing regional aus. Weitere Informationen finden Sie unter Verhalten des Load-Balancers in Netzwerkdienststufen.

In diesem Beispiel wird der Traffic von Nutzern aus Iowa und Boston auf der Load-Balancing-Ebene beendet und es wird eine separate Verbindung zum ausgewählten Back-End aufgebaut.

Cloud Load Balancing mit SSL-Beendigung (zum Vergrößern klicken)
Cloud Load Balancing mit SSL-Beendigung (zum Vergrößern klicken)

SSL-Proxy-Load-Balancing ist für Nicht-HTTP(S)-Traffic konzipiert. Für HTTP(S)-Traffic wird die Verwendung von HTTP(S)-Load-Balancing empfohlen.

Informationen über die unterschiedlichen Google Cloud-Load-Balancer finden Sie in den folgenden Dokumenten:

Vorteile

Bei Verwendung des SSL-Proxy-Load-Balancings bieten sich unter anderem folgende Vorteile:

  • IPv6-Beendigung SSL-Proxy-Load-Balancing wird für Clienttraffic von IPv4- und IPv6-Adressen unterstützt. IPv6-Anfragen von Clients werden auf der Load-Balancing-Ebene beendet und dann über IPv4 an Ihre VMs weitergeleitet.

  • Intelligentes Routing Der Load-Balancer kann Anfragen an Back-End-Speicherorte mit freien Kapazitäten weiterleiten. Im Gegensatz dazu muss ein L3/L4-Load-Balancer ohne Berücksichtigung der Kapazitäten eine Weiterleitung zu regionalen Back-Ends vornehmen. Intelligentes Routing ermöglicht die Bereitstellung mit N+1 oder N+2 anstelle von x*N.

  • Bessere Auslastung von Back-Ends Die SSL-Verarbeitung kann sehr CPU-intensiv sein, wenn die verwendeten Chiffren nicht CPU-effizient sind. Sie können die CPU-Leistung maximieren, indem Sie ECDSA-SSL-Zertifikate sowie TLS 1.2 verwenden und bevorzugt die Cipher Suite ECDHE-ECDSA-AES128-GCM-SHA256 für SSL zwischen dem Load-Balancer und Ihren Back-End-Instanzen einsetzen.

  • Zertifikatsverwaltung Kundenseitige SSL-Zertifikate können entweder Zertifikate sein, die Sie selbst abrufen und verwalten (selbstverwaltete Zertifikate), oder Zertifikate, die von Google abgerufen und verwaltet werden (von Google verwaltete Zertifikate). Von Google verwaltete SSL-Zertifikate unterstützen jeweils bis zu 100 Domains. Für von Google verwaltete Zertifikate werden mehrere Domains unterstützt. Sie müssen nur auf dem Load-Balancer Zertifikate bereitstellen. Auf VMs können Sie die Verwaltung mithilfe selbst signierter Zertifikate vereinfachen.

  • Sicherheitspatches Wenn im SSL- oder TCP-Paket Sicherheitslücken auftreten, werden für den Load-Balancer automatisch Patches bereitgestellt, um die Sicherheit Ihrer VMs zu gewährleisten.

  • Unterstützung für folgende bekannten Ports: 25, 43, 110, 143, 195, 443, 465, 587, 700, 993, 995, 1883, 3389, 5222, 5432, 5671 , 5672, 5900, 5901, 6379, 8085, 8099, 9092, 9200 und 9300. Wenn Sie von Google verwaltete SSL-Zertifikate mit SSL-Proxy-Load-Balancing verwenden, muss der Front-End-Port für Traffic 443 sein, damit die von Google verwalteten SSL-Zertifikate bereitgestellt und erneuert werden können.

  • SSL-Richtlinien Mit SSL-Richtlinien können Sie die Features von SSL steuern, die Ihr SSL-Proxy-Load-Balancer mit Clients aushandelt.

  • Beendigung von TLS geografisch steuern Der SSL-Proxy-Load-Balancer beendet TLS an global verteilten Orten, um die Latenz zwischen den Clients und dem Load-Balancer zu minimieren. Wenn Sie steuern müssen, wo TLS geografisch beendet wird, sollten Sie stattdessen den Load-Balancer des Netzwerks verwenden und TLS auf Back-Ends in solchen Regionen beenden, die für Ihren Bedarf geeignet sind.

Architektur

Die folgenden Komponenten gehören zu TCP-Proxy-Load-Balancern.

Weiterleitungsregeln und IP-Adressen

Weiterleitungsregeln leiten Traffic abhängig von der IP-Adresse, dem Port und dem Protokoll an eine Load-Balancing-Konfiguration weiter, die aus einem Zielproxy und einem Back-End-Dienst besteht.

Jede Weiterleitungsregel stellt eine einzelne IP-Adresse bereit, die Sie in DNS-Einträgen für Ihre Anwendung verwenden können. Ein Load-Balancing für DNS ist nicht erforderlich. Sie können entweder eine statische IP-Adresse reservieren, die Sie verwenden können, oder Cloud Load Balancing eine Adresse für Sie zuweisen lassen. Wir empfehlen, eine statische IP-Adresse zu reservieren. Andernfalls müssen Sie den DNS-Eintrag jedes Mal, wenn Sie eine Weiterleitungsregel löschen und eine neue erstellen, mit der neu zugewiesenen sitzungsspezifischen IP-Adresse aktualisieren.

Jede externe Weiterleitungsregel, die in einem SSL-Proxy-Load-Balancer verwendet wird, kann auf genau einen der Ports verweisen, die unter Portspezifikationen für Weiterleitungsregeln aufgeführt sind.

Zielproxys

SSL-Proxy-Load-Balancing beendet SSL-Verbindungen des Clients und erstellt neue Verbindungen zu den Back-Ends. Der Zielproxy leitet eingehende Anfragen direkt an den Back-End-Dienst weiter.

Standardmäßig bleiben die ursprüngliche IP-Adresse des Clients und die Portinformationen nicht erhalten. Sie können diese Informationen jedoch mithilfe des Proxy-Protokolls aufbewahren.

SSL-Zertifikate

Auf dem Ziel-SSL-Proxy müssen Sie mindestens ein SSL-Zertifikat installieren. Mit den Zertifikaten sichert der SSL-Ziel-Proxy die Kommunikation zwischen einem Google Front End (GFE) und dem Client. Diese können selbstverwaltete oder von Google verwaltete SSL-Zertifikate sein. Informationen zur Anzahl und zu den Kontingenten von SSL-Zertifikaten finden Sie auf der Seite mit den Load-Balancing-Kontingenten unter SSL-Zertifikate.

Sie können SSL-Richtlinien erstellen, um zu steuern, welche SSL-Funktionen von Ihrem Load-Balancer ausgehandelt werden. Weitere Informationen finden Sie in der Übersicht zu SSL-Richtlinien.

Wenn Sie den Traffic zwischen der Load-Balancing-Ebene und den Back-End-Instanzen über unverschlüsselte TCP-Verbindungen senden, können Sie die SSL-Verarbeitung von Ihren Back-Ends auslagern. Dies beeinträchtigt jedoch die Sicherheit. Daher wird dies nicht empfohlen. Zur Gewährleistung einer optimalen Sicherheit verwenden Sie bei der Bereitstellung des SSL-Proxy-Load-Balancers eine Ende-zu-Ende-Verschlüsselung. Weitere Informationen finden Sie unter Verschlüsselung vom Load-Balancer zu Back-Ends.

Allgemeine Informationen darüber, wie Google Nutzertraffic verschlüsselt, finden Sie im Whitepaper Verschlüsselung bei der Übertragung in Google Cloud.

Back-End-Dienste

Back-End-Dienste leiten eingehenden Traffic an mindestens ein verknüpftes Back-End weiter. Jedes Back-End besteht aus einer Instanzgruppe oder einer Netzwerk-Endpunktgruppe und Informationen zur Bereitstellungskapazität des Back-Ends. Die Bereitstellungskapazität für das Back-End basiert auf der CPU oder auf Anfragen pro Sekunde (Requests Per Second, RPS).

Der Back-End-Dienst legt die Systemdiagnosen fest, die für die verfügbaren Back-Ends auszuführen sind.

Sie vermeiden Unterbrechungen für Ihre Nutzer weitgehend, wenn Sie den Verbindungsausgleich bei Back-End-Diensten aktivieren. Unterbrechungen dieser Art können auftreten, wenn ein Back-End beendet, manuell entfernt oder durch Autoscaling entfernt wird. Weitere Informationen zum Vermeiden von Dienstunterbrechungen mithilfe des Verbindungsausgleichs finden Sie unter Verbindungsausgleich aktivieren.

Firewallregeln

Die Back-End-Instanzen müssen Verbindungen aus den folgenden Quellen zulassen:

  • Das Google Front End (GFE) des Load-Balancers für alle Anfragen, die an Ihre Back-Ends gesendet werden
  • Systemdiagnoseprüfungen

Zum Zulassen dieses Traffics müssen Sie Firewallregeln für eingehenden Traffic erstellen. Die Ports für diese Firewallregeln müssen folgenden Traffic zulassen:

  • An den Zielport für die Systemdiagnose jedes Back-End-Dienstes.

  • Für Instanzgruppen-Back-Ends: Diese werden durch die Zuordnung zwischen dem benannten Port des Back-End-Dienstes und den Portnummern bestimmt, die mit diesem benannten Port in jeder Instanzgruppe verknüpft sind. Die Nummern können je nach Instanzgruppe, die demselben Back-End-Dienst zugewiesen ist, variieren.

  • Für GCE_VM_IP_PORT-NEG-Back-Ends: an die Portnummern der Endpunkte.

Firewallregeln werden auf VM-Instanzebene und nicht auf GFE-Proxys implementiert. Sie können Google Cloud-Firewallregeln nicht verwenden, um zu verhindern, dass Traffic den Load-Balancer erreicht. Sie können dafür Google Cloud Armor verwenden.

Weitere Informationen zu Systemdiagnoseprüfungen und dazu, warum Traffic von diesen zugelassen werden muss, finden Sie unter Prüfungs-IP-Bereiche und Firewallregeln.

Für SSL-Proxy-Load-Balancer und TCP-Proxy-Load-Balancer sind folgende Quellbereiche erforderlich:

  • 130.211.0.0/22
  • 35.191.0.0/16

Diese Bereiche gelten für Systemdiagnosen und Anfragen vom GFE.

Quell-IP-Adressen

Die Quell-IP-Adresse für Pakete, die von den Back-Ends erkannt wird, ist nicht die externe Google Cloud-IP-Adresse des Load-Balancers. Mit anderen Worten: Es gibt zwei TCP-Verbindungen:

  • Verbindung 1 vom ursprünglichen Client zum Load-Balancer (GFE):

    • Quell-IP-Adresse: Der ursprüngliche Client (oder die externe IP-Adresse, wenn sich der Client hinter NAT oder einem Weiterleitungsproxy befindet)
    • Ziel-IP-Adresse: IP-Adresse Ihres Load-Balancers
  • Verbindung 2 vom Load-Balancer (GFE) zur Back-End-VM oder zum Back-End-Endpunkt:

    • Quell-IP-Adresse: IP-Adresse aus einem der unter Firewallregeln angegebenen Bereiche

    • Ziel-IP-Adresse: Interne IP-Adresse der Back-End-VM oder des Containers im VPC-Netzwerk (Virtual Private Cloud)

Quell-IP-Adressen von Clients beibehalten

Um die ursprünglichen Quell-IP-Adressen eingehender Verbindungen zum Load Balancer beizubehalten, können Sie den Load Balancer so konfigurieren, dass ein Header des PROXY-Protokolls Version 1 vorangestellt wird. Auf diese Weise werden die ursprünglichen Verbindungsinformationen beibehalten. Weitere Informationen finden Sie unter PROXY-Protokollheader für den Proxy aktualisieren.

Offene Ports

SSL-Proxy-Load-Balancer sind Reverse-Proxy-Load-Balancer. Der Load-Balancer beendet eingehende Verbindungen und öffnet dann neue Verbindungen vom Load-Balancer zu den Back-Ends. Diese Load-Balancer werden mit Google Front End-Proxys (GFE) weltweit implementiert.

GFEs haben mehrere offene Ports, um andere Google-Dienste, die in derselben Architektur ausgeführt werden, zu unterstützen. Eine Liste der Ports, die in GFEs wahrscheinlich geöffnet sind, finden Sie unter Weiterleitungsregel: Portspezifikationen. Möglicherweise gibt es andere offene Ports für andere Google-Dienste, die auf GFEs ausgeführt werden.

Aus folgenden Gründen ist die Ausführung eines Portscans für die IP-Adresse eines GFE-basierten Load-Balancers aus Sicht der Prüfung nicht hilfreich:

  • Ein Portscan (z. B. mit nmap) erwartet beim Ausführen von TCP-SYN-Tests normalerweise kein Antwortpaket oder ein TCP-RST-Paket. GFEs senden SYN-ACK-Pakete als Antwort auf SYN-Prüfungen für eine Vielzahl von Ports, wenn Ihr Load-Balancer eine IP-Adresse der Premium-Stufe verwendet. GFEs senden jedoch nur Pakete an Ihre Back-Ends, wenn Pakete an die IP-Adresse und den Zielport Ihres Load-Balancers gesendet wurden, die in seiner Weiterleitungsregel konfiguriert sind. Pakete, die an verschiedene IP-Adressen des Load-Balancers oder an die IP-Adresse Ihres Load-Balancers an einem Port gesendet werden, der nicht in Ihrer Weiterleitungsregel konfiguriert ist, führen nicht dazu, dass Pakete an die Back-Ends Ihres Load-Balancers gesendet werden. Auch ohne eine spezielle Konfiguration bieten die Google-Infrastruktur und die GFEs gestaffelte Sicherheitsebenen für DDoS-Angriffe und SYN-Floods.

  • Pakete, die an die IP-Adresse Ihres Load-Balancers gesendet werden, können von jedem GFE in der Google-Flotte beantwortet werden. Wird jedoch eine Kombination aus IP-Adresse und Zielport eines Load-Balancers gescannt, wird nur ein einziges GFE pro TCP-Verbindung abgefragt. Die IP-Adresse des Load-Balancers wird keinem einzelnen Gerät oder System zugewiesen. Wenn also die IP-Adresse eines GFE-basierten Load-Balancers gescannt wird, werden nicht alle GFEs in der Flotte von Google gescannt.

Daher können Sie die Sicherheit Ihrer Back-End-Instanzen am besten mit folgenden Methoden prüfen:

  • Ein Sicherheitsprüfer sollte die Konfiguration der Weiterleitungsregeln für die Konfiguration des Load-Balancers prüfen. Die Weiterleitungsregeln definieren den Zielport, für den Ihr Load-Balancer Pakete akzeptiert und an die Back-Ends weiterleitet. Bei GFE-basierten Load-Balancern kann jede externe Weiterleitungsregel nur auf einen einzelnen TCP-Zielport verweisen.

  • Ein Sicherheitsprüfer sollte die Konfiguration der Firewallregel für Back-End-VMs prüfen. Die festgelegten Firewallregeln blockieren den Traffic von den GFEs zu den Back-End-VMs, aber nicht den eingehenden Traffic zu den GFEs. Best Practices finden Sie im Abschnitt Firewallregeln.

Traffic-Verteilung

Die Art und Weise, wie ein SSL-Proxy-Load-Balancer den Traffic an seine Back-Ends verteilt, hängt vom Load-Balancing-Modus und der ausgewählten Hash-Methode ab, um ein Back-End auszuwählen (Sitzungsaffinität).

Verteilung von Verbindungen

Das TCP-Proxy-Load-Balancing kann als globaler Load-Balancing-Dienst mit der Premium-Stufe und als regionaler Dienst in der Standardstufe konfiguriert werden.

Premium-Stufe:

  • Sie können nur einen Back-End-Dienst haben und der Back-End-Dienst kann Back-Ends in mehreren Regionen haben. Für globales Load-Balancing stellen Sie Ihre Back-Ends in mehreren Regionen bereit. Der Load-Balancer leitet den Traffic automatisch an die Region weiter, die dem Nutzer am nächsten ist. Ist eine Region ausgelastet, leitet der Load-Balancer neue Verbindungen automatisch zu einer anderen Region mit freien Kapazitäten um. Bestehende Nutzerverbindungen bleiben aber in der aktuellen Region.
  • Google bewirbt die IP-Adresse Ihres Load-Balancers von allen Points of Presence weltweit. Jede IP-Adresse des Load-Balancers ist eine globale Anycast-Adresse.
  • Wenn Sie einen Back-End-Dienst mit Back-Ends in mehreren Regionen konfigurieren, versuchen Google Front Ends (GFEs) Anfragen an fehlerfreie Back-End-Instanzgruppen oder NEGs in der Region weiterzuleiten, die dem Nutzer am nächsten ist. Weitere Informationen zu diesem Vorgang finden Sie auf dieser Seite.

Standardstufe:

  • Google bewirbt die IP-Adresse Ihres Load-Balancers von Points of Presence, die mit der Region der Weiterleitungsregel verknüpft sind. Der Load-Balancer verwendet eine regionale externe IP-Adresse.

  • Sie können Back-Ends in derselben Region wie die Weiterleitungsregel konfigurieren. Der hier dokumentierte Prozess gilt weiterhin, aber GFEs leiten Anfragen nur an fehlerfreie Back-Ends in dieser Region weiter.

Ablauf der Anfrageverteilung:

Der Balancing-Modus und die Auswahl des Ziels definieren die Back-End-Vollständigkeit aus der Perspektive jeder zonalen GCE_VM_IP_PORT-NEG, zonalen Instanzgruppe oder Zone einer regionalen Instanzgruppe. Die Verteilung innerhalb einer Zone erfolgt anschließend mit konsistentem Hashing.

Der Load-Balancer verwendet den folgenden Prozess:

  1. Die externe IP-Adresse der Weiterleitungsregel wird durch Edge-Router an den Rändern des Google-Netzwerks beworben. Jede Anzeige enthält einen nächsten Hop zu einem Layer-Load-Balancing-System mit 3/4-Ebene (Maglev) in größtmöglicher Nähe des Nutzers.
  2. Maglev-Systeme prüfen die Quell-IP-Adresse des eingehenden Pakets. Sie leiten die eingehende Anfrage an die Maglev-Systeme weiter, die von den Geo-IP-Systemen von Google so nah wie möglich am Nutzer ermittelt werden.
  3. Die Maglev-Systeme leiten Traffic an ein Google Front End (GFE) der ersten Ebene weiter. Das GFE auf der ersten Ebene beendet TLS gegebenenfalls und leitet dann den Traffic gemäß diesem Prozess an GFEs der zweiten Ebene weiter:
    1. Wenn ein Back-End-Dienst eine Instanzgruppe oder GCE_VM_IP_PORT-NEG-Back-Ends verwendet, bevorzugen die GFEs der ersten Ebene GFEs der zweiten Ebene, die sich innerhalb oder in der Nähe der Region mit der Instanzgruppe oder NEG befinden.
    2. Bei Back-End-Buckets und Back-End-Diensten mit Hybrid-NEGs, serverlosen NEGs und Internet-NEGs wählen die GFEs der ersten Ebene GFEs der zweiten Ebene in einer Teilmenge von Regionen aus, sodass die Umlaufzeit zwischen den beiden GFEs minimiert wird.

      Die GFE-Einstellung der zweiten Ebene ist keine Garantie und kann sich je nach den Netzwerkbedingungen und Wartungsaktivitäten von Google dynamisch ändern.

      GFEs der zweiten Ebene erkennen den Status der Systemdiagnose und die tatsächliche Nutzung der Back-End-Kapazität.

  4. Das GFE der zweiten Ebene leitet Anfragen an Back-Ends in Zonen innerhalb seiner Region weiter.
  5. Bei der Premium-Stufe senden GFEs der zweiten Ebene manchmal Anfragen an Back-Ends in Zonen unterschiedlicher Regionen. Dieses Verhalten wird als Spillover bezeichnet.
  6. Das Spillover unterliegt zwei Prinzipien:

    • Ein Spillover ist möglich, wenn alle Back-Ends, die einem GFE einer zweiten Ebene bekannt sind, ausgelastet oder fehlerhaft sind.
    • Das GFE der zweiten Ebene enthält Informationen für fehlerfreie, verfügbare Back-Ends in Zonen einer anderen Region.

    Die GFEs der zweiten Ebene sind in der Regel so konfiguriert, dass sie eine Teilmenge der Back-End-Standorte bereitstellen.

    Das Spillover-Verhalten schöpft nicht alle möglichen Google Cloud-Zonen aus. Wenn Sie Traffic von Back-Ends in einer bestimmten Zone oder einer gesamten Region weiterleiten müssen, legen Sie den Kapazitätsskalierer auf null fest. Wenn Sie Back-Ends für Systemdiagnosen konfigurieren, ist nicht garantiert, dass das GFE der zweiten Ebene Anfragen an Back-Ends in Zonen einer anderen Region weiterleitet.

  7. Beim Verteilen von Anfragen an Back-Ends arbeiten GFEs auf einer zonalen Ebene.

    Bei einer geringen Anzahl von Verbindungen bevorzugen GFEs der zweiten Ebene manchmal eine bestimmte Zone innerhalb einer Region. Dieses Verhalten ist normal und wird erwartet. Die Verteilung zwischen Zonen in der Region ist erst dann gleichmäßig, wenn der Load-Balancer mehr Verbindungen erhält.

Balancing-Modus

Wenn Sie dem Back-End-Dienst ein Back-End hinzufügen, legen Sie einen Load-Balancing-Modus fest.

Beim SSL-Proxy-Load-Balancing sind die Balancing-Modi CONNECTION oder UTILIZATION möglich.

Wenn der Load-Balancing-Modus CONNECTION ist, basiert die Verteilung der Last darauf, wie viele gleichzeitige Verbindungen das Back-End verarbeiten kann. Außerdem müssen Sie einen der folgenden Parameter genau angeben: maxConnections (außer für regionale verwaltete Instanzgruppen), maxConnectionsPerInstance oder maxConnectionsPerEndpoint.

Wenn der Load-Balancing-Modus UTILIZATION ist, wird die Last anhand der Auslastung der Instanzen in einer Instanzgruppe verteilt.

Informationen zum Vergleichen der Load-Balancer-Typen und der unterstützten Balancing-Modi finden Sie unter Load-Balancing-Methoden.

Sitzungsaffinität

Mit Sitzungsaffinität werden alle Anfragen vom selben Client an dasselbe Back-End gesendet, wenn das Back-End fehlerfrei ist und Kapazität hat.

Das TCP-Proxy-Load-Balancing bietet Client-IP-Affinität, mit der alle Anfragen von derselben Client-IP-Adresse an dasselbe Back-End weitergeleitet werden.

Failover

Wenn ein Back-End fehlerhaft wird, wird der Traffic automatisch zu fehlerfreien Back-Ends in derselben Region weitergeleitet. Wenn alle Back-Ends innerhalb einer Region fehlerhaft sind, wird der Traffic an fehlerfreie Back-Ends in anderen Regionen verteilt (nur Premium-Stufe). Wenn alle Back-Ends fehlerhaft sind, löscht der Load-Balancer den Traffic.

Load-Balancing für GKE-Anwendungen

Wenn Sie Anwendungen in Google Kubernetes Engine erstellen, können Sie eigenständige NEGs verwenden, um den Traffic direkt auf Container zu verteilen. Bei eigenständigen NEGs müssen Sie das Service-Objekt erstellen, das die NEG erstellt, und dann die NEG mit dem Back-End-Dienst verknüpfen, damit der Load-Balancer eine Verbindung zu den Pods herstellen.

Zugehörige GKE-Dokumentation:

Beschränkungen

  • SSL-Proxy-Load-Balancer haben jeweils eine einzelne Back-End-Dienstressource. Änderungen am Back-End-Dienst erfolgen nicht sofort. Es kann einige Minuten dauern, bis Änderungen an Google Front Ends (GFEs) wirksam werden.

  • Die auf einem Clientzertifikat basierte Authentifizierung, die auch als gegenseitige TLS-Authentifizierung bezeichnet wird, wird von SSL-Proxy-Load-Balancern nicht unterstützt.

  • Obwohl das SSL-Proxy-Load-Balancing HTTPS-Traffic verarbeiten kann, wird dies nicht empfohlen. Für HTTPS-Traffic sollten Sie stattdessen HTTP(S)-Load-Balancing verwenden. HTTP(S) Load Balancing führt auch Folgendes aus, was es in den meisten Fällen zu einer besseren Wahl macht:

    • Unterstützt Negotiation mit HTTP/2 und HTTP/3.
    • Weist ungültige HTTP-Anfragen oder -Antworten zurück.
    • Leitet Anfragen je nach URL-Host und -Pfad an verschiedene VMs weiter
    • Integriert sich in Cloud CDN.
    • Verteilt die Anfragelast gleichmäßiger zwischen den Back-End-Instanzen, wodurch die Back-End-Auslastung optimiert wird. Beim HTTPS-Load-Balancing wird jede Anfrage separat verarbeitet, während beim SSL-Proxy-Load-Balancing alle Byte einer SSL- oder TCP-Verbindung an dieselbe Back-End-Instanz gesendet werden.
  • Für SSL-Proxy-Load-Balancer mit von Google verwalteten SSL-Zertifikaten müssen die Front-End-Ports 443 enthalten, damit die Zertifikate bereitgestellt und verlängert werden.

    SSL-Proxy-Load-Balancing kann für andere Protokolle verwendet werden, die SSL verwenden, z. B. WebSockets und IMAP über SSL.

  • SSL-Proxy-Load-Balancer unterstützen nur Kleinbuchstaben in Domains in einem Attribut für einen gemeinsamen Namen (CN) oder ein Attribut für einen alternativen Antragstellernamen (SAN) des Zertifikats. Zertifikate mit Großbuchstaben in Domains werden nur zurückgegeben, wenn sie als primäres Zertifikat im Zielproxy festgelegt wurden.

  • SSL-Proxy-Load-Balancer unterstützen VPC-Netzwerk-Peering nicht.

Nächste Schritte