SSL-Proxy-Load-Balancing – Überblick

Wenn Sie das SSL-Proxy-Load-Balancing von Google Cloud für Ihren SSL-Traffic verwenden, können Sie SSL- bzw. TLS-Verbindungen der Nutzer auf Load-Balancing-Ebene beenden und anschließend die Verbindungen zwischen Ihren Back-End-Instanzen mithilfe der SSL- (empfohlen) oder TCP-Protokolle ausgleichen. Informationen zu den unterstützten Back-Ends finden Sie unter Back-Ends.

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:

SSL-Proxy-Load-Balancing wird für Client-Traffic 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.

Das SSL-Proxy-Load-Balancing ist ein Load-Balancing-Dienst, der global bereitgestellt werden kann. Sie können Ihre Back-Ends in mehreren Regionen bereitstellen. Der Load-Balancer leitet den Traffic automatisch an die nächstgelegene Region weiter, die über Kapazitäten verfügt. Ist diese voll 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.

Für ein globales Load-Balancing ist die Premium-Stufe der Netzwerkdienststufen erforderlich, die auch die Standardeinstellung ist. Andernfalls wird das Load-Balancing regional bearbeitet.

Vorteile

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

  • 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.

  • Der SSL-Proxy-Load-Balancer unterstützt folgende 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.

Hinweise

  • 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.

  • Das SSL-Proxy-Load-Balancing kann zwar HTTPS verarbeiten, es wird aber davon abgeraten. Für HTTPS-Traffic sollten Sie stattdessen HTTP(S)-Load-Balancing verwenden. Weitere Informationen finden Sie in den FAQ.

  • Sie können SSL-Richtlinien mit dem gcloud-Befehlszeilentool erstellen.

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

  • 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.

In den folgenden Abschnitten wird die Funktionsweise von SSL-Proxy-Load-Balancing beschrieben.

Anwendungsfälle

Bei Verwendung des SSL-Proxy-Load-Balancings werden SSL-Verbindungen auf der Load-Balancing-Ebene beendet und dann zum nächstgelegenen verfügbaren Back-End weitergeleitet.

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)

Verhalten des Load-Balancers in Netzwerkdienststufen

Der SSL-Proxy-Load-Balancer ist ein globaler Dienst mit Premium-Stufe. Sie können nur einen Back-End-Dienst mit Back-Ends in mehreren Regionen haben. So wird der Traffic den Back-Ends zugewiesen:

  1. Wenn ein Client eine Anfrage sendet, ermittelt der Load-Balancing-Dienst anhand der Quell-IP-Adresse den ungefähren Ursprung der Anfrage.
  2. Der Load-Balancing-Dienst bestimmt die Standorte der Back-Ends, die dem Back-End-Dienst gehören, deren Gesamtkapazität und deren aktuelle Auslastung.
  3. Wenn die Back-End-Instanzen, die dem Nutzer am nächsten sind, freie Kapazitäten haben, wird die Anfrage an die nächstgelegene Gruppe von Back-Ends weitergeleitet.
  4. Eingehende Anfragen an die angegebene Region werden gleichmäßig auf alle verfügbaren Back-End-Instanzen in dieser Region verteilt. Bei sehr kleinen Arbeitslasten kann sich die Verteilung als ungleichmäßig darstellen.
  5. Wenn es in einer bestimmten Region keine fehlerfreien Back-End-Instanzen mit verfügbarer Kapazität gibt, sendet der Load-Balancer die Anfrage stattdessen an die nächstgelegene Region mit verfügbarer Kapazität.

Bei der Standardstufe ist das TCP-Proxy-Load-Balancing ein regionaler Dienst. Die Back-Ends müssen sich alle in der Region befinden, die von der externen IP-Adresse und Weiterleitungsregel des Load-Balancers verwendet wird.

Quell-IP-Adressen

Die Quell-IP-Adressen für Pakete, die von jeder Instanz oder jedem Container des Back-Ends der virtuellen Maschine erkannt werden, sind Adressen aus folgenden Bereichen:

  • 35.191.0.0/16
  • 130.211.0.0/22

Die Quell-IP-Adresse für tatsächlichen Traffic mit Load-Balancing liegt innerhalb der Systemdiagnose-IP-Bereiche.

Die Quell-IP-Adressen für den Traffic, die von den Back-Ends erkannt werden, entsprechen nicht der externen Google Cloud-IP-Adresse des Load-Balancers. Mit anderen Worten: Es gibt zwei HTTP-, SSL- oder TCP-Sitzungen:

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

    • Quell-IP-Adresse: Der ursprüngliche Client (oder die externe IP-Adresse, wenn der Client hinter NAT liegt)
    • Ziel-IP-Adresse: IP-Adresse Ihres Load-Balancers
  • Sitzung 2 vom Load-Balancer (GFE) zur Back-End-VM oder zum Back-End-Container:

    • Quell-IP-Adresse: IP-Adresse aus einem der folgenden Bereiche: 35.191.0.0/16 oder 130.211.0.0/22

      Eine Vorhersage der tatsächlichen Quelladresse ist nicht möglich.

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

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 Netzwerk-Load-Balancing verwenden und TLS auf Back-Ends beenden, die sich in Regionen befinden, die für Ihren Bedarf geeignet sind.

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. Die Reverse-Proxy-Funktionalität wird von den Google-Front-Ends (GFEs) bereitgestellt.

Die festgelegten Firewallregeln blockieren den Traffic von den GFEs zu den Back-End-Instanzen, aber nicht den eingehenden Traffic zu den GFEs.

Die SSL-Proxy-Load-Balancer haben eine Reihe von offenen Ports, um andere Google-Dienste, die in derselben Architektur ausgeführt werden, zu unterstützen. Wenn Sie einen Sicherheits- oder Portscan für die externe IP-Adresse Ihres Load-Balancers ausführen, wirkt es so, als ob weitere Ports offen wären.

Dies hat keine Auswirkungen auf SSL-Proxy-Load-Balancer. Externe Weiterleitungsregeln, die in der Definition eines SSL-Load-Balancers verwendet werden, können nur auf die TCP-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. verweisen. Traffic mit einem anderen TCP-Zielport wird nicht an das Back-End des Load-Balancers weitergeleitet.

Firewallregeln

Die Back-End-Instanzen müssen Verbindungen von den GFE- / Systemdiagnosebereichen des Load-Balancers zulassen. Dies bedeutet, dass Sie eine Firewallregel erstellen müssen, die Traffic von 130.211.0.0/22 und 35.191.0.0/16 zulässt, um Ihre Back-End-Instanzen oder Endpunkte zu erreichen. Diese IP-Adressbereiche werden als Quellen für Systemdiagnose-Pakete und für alle Pakete mit Load-Balancing verwendet, die an Ihre Back-Ends gesendet werden.

Die Ports, die Sie für diese Firewallregel konfigurieren, müssen Traffic zu Back-End-Instanzen oder -Endpunkten zulassen:

  • Sie müssen die von jeder Weiterleitungsregel verwendeten Ports zulassen.
  • Sie müssen die von jeder Systemdiagnose verwendeten Ports zulassen, die für jeden Back-End-Dienst konfiguriert sind.

Firewallregeln werden auf VM-Instanzebene und nicht auf GFE-Proxys (Google Front End) implementiert. Sie können Google Cloud-Firewallregeln nicht verwenden, um zu verhindern, dass Traffic den Load-Balancer erreicht.

Weitere Informationen zu Systemdiagnosetests und dazu, warum Traffic von 130.211.0.0/22 und 35.191.0.0/16 zugelassen werden muss, finden Sie unter Prüfungs-IP-Bereiche und Firewallregeln.

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.

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.

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 Nutzer-Traffic verschlüsselt, finden Sie im Whitepaper Verschlüsselung bei der Übertragung in Google Cloud.

FAQ

Wann sollte ich HTTP(S)-Load-Balancing statt SSL-Proxy-Load-Balancing verwenden?

SSL-Proxy-Load-Balancing kann zwar HTTPS-Traffic verarbeiten, doch ist HTTP(S)-Load-Balancing in den meisten Fällen die bessere Wahl, da es zusätzliche Features hat.

HTTP(S)-Load-Balancing bietet folgende Zusatzfunktionen:

  • Unterstützt Negotiation mit HTTP/2 und SPDY/3.1.
  • 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.

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

Kann ich die ursprüngliche IP-Adresse der Verbindung zur Load-Balancing-Ebene sehen?

Ja. Sie können den Load-Balancer so konfigurieren, dass ein PROXY-Protokoll-Header der Version 1 erstellt wird, der die ursprünglichen Verbindungsinformationen enthält. Weitere Informationen finden Sie unter PROXY-Protokoll-Header für den Proxy aktualisieren.

Nächste Schritte