Veröffentlichte Dienste

Dieses Dokument bietet eine Übersicht über die Verwendung von Private Service Connect, um Dienstnutzern einen Dienst zur Verfügung zu stellen.

Als Dienstersteller können Sie Private Service Connect verwenden, um Dienste mithilfe interner IP-Adressen in Ihrem VPC-Netzwerk zu veröffentlichen. Ihre veröffentlichten Dienste sind für Dienstnutzer über interne IP-Adressen in ihren VPC-Netzwerken zugänglich.

Wenn Sie einen Dienst für Nutzer verfügbar machen möchten, erstellen Sie ein oder mehrere Subnetze. Erstellen Sie anschließend einen Dienstanhang, der auf diese Subnetze verweist. Der Dienstanhang kann unterschiedliche Verbindungseinstellungen haben.

Arten von Dienstnutzern

Es gibt zwei Arten von Nutzern, die eine Verbindung zu einem Private Service Connect-Dienst herstellen können:

• Private Service Connect-Endpunkte
• Private Service Connect-Endpunkte

Endpunkte basieren auf einer Weiterleitungsregel.

Mit einem Endpunkt können Dienstnutzer Traffic vom VPC-Netzwerk des Nutzers an Dienste im VPC-Netzwerk des Dienstherstellers senden (zum Vergrößern klicken).

Back-Ends basieren auf einem Load Balancer.

Mit einem Backend, das einen globalen externen Application Load Balancer verwendet, können Dienstnutzer mit Internetzugriff Traffic an Dienste im VPC-Netzwerk des Diensterstellers senden (zum Vergrößern klicken).

NAT-Subnetze

Private Service Connect-Dienstanhänge sind mit einem oder mehreren NAT-Subnetzen (auch als Private Service Connect-Subnetze bezeichnet) konfiguriert. Pakete aus dem VPC-Netzwerk des Nutzers werden mithilfe von Quell-NAT (SNAT) übersetzt, sodass ihre ursprünglichen Quell-IP-Adressen in Quell-IP-Adressen aus dem NAT-Subnetz im VPC-Netzwerk des Erstellers umgewandelt werden.

Dienstanhänge können mehrere NAT-Subnetze haben. Dem Dienstanschluss können jederzeit weitere NAT-Subnetze hinzugefügt werden, ohne den Traffic zu unterbrechen.

Für einen Dienstanhang können mehrere NAT-Subnetze konfiguriert sein. Ein NAT-Subnetz kann jedoch nicht in mehr als einem Dienstanhang verwendet werden.

Private Service Connect NAT-Subnetze können nicht für Ressourcen wie VM-Instanzen oder Weiterleitungsregeln verwendet werden. Die Subnetze werden nur verwendet, um IP-Adressen für SNAT von eingehenden Nutzerverbindungen bereitzustellen.

Größe des NAT-Subnetzes

Die Größe des Subnetzes bestimmt, wie viele Nutzer eine Verbindung zu Ihrem Dienst herstellen können. Wenn alle IP-Adressen im NAT-Subnetz genutzt werden, schlagen alle zusätzlichen Private Service Connect-Verbindungen fehl. Beachten Sie dabei Folgendes:

• Für jeden Endpunkt oder jedes Backend, das mit dem Dienstanhang verbunden ist, wird eine IP-Adresse aus dem NAT-Subnetz genutzt.

  Die Anzahl der TCP- oder UDP-Verbindungen, Clients oder Nutzer-VPC-Netzwerke wirkt sich nicht auf die Nutzung von IP-Adressen aus dem NAT-Subnetz aus.

• Wenn Verbindungsweitergabe von Nutzern verwendet wird, wird für jeden VPC-Spoke, an den Verbindungen weitergegeben werden, für jeden Endpunkt eine zusätzliche IP-Adresse belegt.

  Sie können die Anzahl der erstellten weitergegebenen Verbindungen steuern, indem Sie das Limit für weitergegebene Verbindungen konfigurieren.

• Wenn Sie schätzen möchten, wie viele IP-Adressen Sie für Endpunkte und Back-Ends benötigen, berücksichtigen Sie alle Mehrmandantenfähige Dienste oder Verbraucher, die Multi-Point-Zugriff für Private Service Connect verwenden.

Hinweis: In einem NAT-Subnetz gibt es vier nicht verwendbare IP-Adressen. Ein NAT-Subnetz /29 hat beispielsweise vier verwendbare IP-Adressen und ein NAT-Subnetz /24 hat 252 verwendbare IP-Adressen.

NAT-Subnetzüberwachung

Damit Private Service Connect-Verbindungen nicht aufgrund von nicht verfügbaren IP-Adressen in einem NAT-Subnetz fehlschlagen, empfehlen wir Folgendes:

• Überwachen Sie den Dienstanhang-Messwert private_service_connect/producer/used_nat_ip_addresses. Die Anzahl der verwendeten NAT-IP-Adressen darf die Kapazität der NAT-Subnetze eines Dienstanhangs nicht überschreiten.
• Überwachen Sie den Verbindungsstatus von Dienstanhang-Verbindungen. Wenn eine Verbindung den Status Maßnahme erforderlich hat, sind in den NAT-Subnetzen des Anhangs möglicherweise keine weiteren IP-Adressen verfügbar.
• Bei mehrmandantenfähigen Diensten können Sie Verbindungslimits verwenden, um sicherzustellen, dass ein einzelner Nutzer die Kapazität der NAT-Subnetze eines Dienstanhangs nicht aufbraucht.

Bei Bedarf können NAT-Subnetze jederzeit dem Dienst-Anhang hinzugefügt werden, ohne den Traffic zu unterbrechen.

NAT-Spezifikationen

Berücksichtigen Sie die folgenden Eigenschaften von Private Service Connect-NAT, wenn Sie den zu veröffentlichenden Dienst entwerfen:

• Das Zeitlimit für Inaktivität bei der UDP-Zuordnung beträgt 30 Sekunden und kann nicht konfiguriert werden.

• Das Zeitlimit für Inaktivität hergestellter TCP-Verbindungen beträgt 20 Minuten und kann nicht konfiguriert werden.

  Führen Sie einen der folgenden Schritte aus, um Probleme mit Zeitüberschreitungen bei Clientverbindungen zu vermeiden:

  • Alle Verbindungen dürfen maximal 20 Minuten aktiv sein.

  • Achten Sie darauf, dass ein Teil des Traffics häufiger als alle 20 Minuten gesendet wird. Sie können in Ihrer Anwendung einen Heartbeat oder Keepalive oder TCP-Keepalives verwenden. Sie können beispielsweise einen Keepalive im Zielproxy eines regionalen internen Application Load Balancers oder eines regionalen internen Proxy-Network Load Balancers konfigurieren.

• Das Zeitlimit für Inaktivität vorübergehender TCP-Verbindungen beträgt 30 Sekunden und kann nicht konfiguriert werden.

• Es gibt eine Verzögerung von zwei Minuten, bevor ein 5-Tupel (Quell-IP-Adresse und Quellport des NAT-Subnetzes sowie Zielprotokoll, IP-Adresse und Zielport) wiederverwendet werden kann.

• SNAT für Private Service Connect unterstützt keine IP-Fragmente.

Maximale Anzahl an Verbindungen

Eine einzelne Ersteller-VM kann maximal 64.512 TCP- und 64.512 UDP-Verbindungen gleichzeitig von einem einzelnen Private Service Connect-Nutzer (Endpunkt oder Backend) akzeptieren. Die Gesamtzahl der TCP- und UDP-Verbindungen, die ein Private Service Connect-Endpunkt insgesamt über alle Ersteller-Back-Ends hinweg empfangen kann, ist nicht begrenzt. Client-VMs können alle 65.536 Quellports verwenden,wenn TCP- oder UDP-Verbindungen zu einem Private Service Connect-Endpunkt initiiert werden. Die gesamte Netzwerkadressübersetzung erfolgt lokal auf dem Erstellerhost. Dazu ist kein zentral zugewiesener NAT-Portpool erforderlich.

Dienstanhänge

Dienstersteller stellen ihre Dienste über einen Dienstanhang bereit.

• Für die Freigabe eines Dienstes erstellt ein Dienstersteller einen Dienstanhang, der auf einen Zieldienst verweist. Der Zieldienst kann einer der folgenden sein:
  • Weiterleitungsregel eines Load-Balancers
  • Eine Secure Web Proxy-Instanz

Der URI des Dienstanhangs hat folgendes Format: projects/SERVICE_PROJECT/regions/REGION/serviceAttachments/SERVICE_NAME.

Ein Dienstanhang kann nur einen Zieldienst haben. Mehrere Dienstanhänge können jedoch denselben Zieldienst verwenden.

Mit Dienstanhängen können Sie den Zugriff auf Ihren veröffentlichten Dienst steuern, Verbindungen ansehen und Verbindungslimits konfigurieren. Weitere Informationen finden Sie unter Zugriff auf veröffentlichte Dienste steuern.

Verbindungsstatus

Dienstanhänge haben Verbindungsstatus, die den Zustand ihrer Verbindungen beschreiben. Weitere Informationen finden Sie unter Verbindungsstatus.

DNS-Konfiguration

Informationen zur DNS-Konfiguration für veröffentlichte Dienste und Endpunkte, die eine Verbindung zu veröffentlichten Diensten herstellen, finden Sie unter DNS-Konfiguration für Dienste.

Konfiguration für mehrere Regionen für Failover

Sie können einen Dienst in mehreren Regionen verfügbar machen, indem Sie die folgenden Konfigurationen erstellen.

Erstellerkonfiguration:

• Stellen Sie den Dienst in jeder Region bereit. Jede regionale Instanz des Dienstes muss auf einem regionalen Load-Balancer konfiguriert werden, der Zugriff über ein Backend unterstützt.
• Erstellen Sie einen Dienstanhang, um jede regionale Instanz des Dienstes zu veröffentlichen.

Nutzerkonfiguration:

• Private Service Connect-Backend für den Zugriff auf veröffentlichte Dienste erstellen. Das Backend muss auf einem Load-Balancer basieren, der regionenübergreifendes Failover unterstützt, und die folgende Konfiguration enthalten:
  • Eine Private Service Connect-NEG in jeder Region, die auf den Dienstanhang dieser Region verweist.
  • Ein globaler Back-End-Dienst, der die NEG-Back-Ends enthält

Diese Konfiguration unterstützt das automatische regionsübergreifende Failover. Beim automatischen Failover wird der Traffic nicht mehr an eine Dienstinstanz in einer Region weitergeleitet, wenn diese fehlerhaft wird. Stattdessen wird der Traffic an eine fehlerfreie Dienstinstanz in einer alternativen Region weitergeleitet.

Hier finden Sie weitere Informationen:

• Private Service Connect-Integrität
• Automatische regionsübergreifende Ausfallsicherung für Privatnutzer

Mit einem globalen externen Application Load Balancer können Dienstnutzer mit Internetzugriff Traffic an Dienste im VPC-Netzwerk des Diensterstellers senden. Da der Dienst in mehreren Regionen bereitgestellt wird, kann der Load Balancer des Nutzers Traffic an eine fehlerfreie Dienstinstanz in einer alternativen Region weiterleiten (zum Vergrößern klicken).

Übersetzung von IP-Versionen

Bei Private Service Connect-Endpunkten, die eine Verbindung zu veröffentlichten Diensten (Dienstanhängen) herstellen, bestimmt die IP-Version der IP-Adresse der Nutzerweiterleitungsregel die IP-Version des Endpunkts und den Traffic, der den Endpunkt ausgibt. Die IP-Adresse kann aus einem reinen IPv4-, reinen IPv6- oder Dual-Stack-Subnetz stammen. Die IP-Version des Endpunkts kann entweder IPv4 oder IPv6 sein, aber nicht beides.

Bei veröffentlichten Diensten wird die IP-Version des Dienstanhangs durch die IP-Adresse der zugehörigen Weiterleitungsregel oder Secure Web Proxy-Instanz bestimmt. Diese IP-Adresse muss mit dem Stack-Typ des NAT-Subnetzes des Dienstanhangs kompatibel sein. Das NAT-Subnetz kann ein reines IPv4-, reines IPv6- oder Dual-Stack-Subnetz sein. Wenn das NAT-Subnetz ein Dual-Stack-Subnetz ist, wird entweder der IPv4- oder der IPv6-Adressbereich verwendet, aber nicht beide.

Private Service Connect unterstützt nicht die Verbindung eines IPv4-Endpunkts mit einem IPv6-Dienstanhang. In diesem Fall schlägt die Endpunkterstellung mit der folgenden Fehlermeldung fehl:

Private Service Connect forwarding rule with an IPv4 address cannot target an IPv6 service attachment.

Für unterstützte Konfigurationen sind folgende Kombinationen möglich:

• IPv4-Endpunkt zum IPv4-Dienstanhang
• IPv6-Endpunkt zum IPv6-Dienstanhang

• IPv6-Endpunkt zum IPv4-Dienstanhang

  In dieser Konfiguration übersetzt Private Service Connect automatisch zwischen den beiden IP-Versionen.

Bei Verbindungen zwischen Private Service Connect-Back-Ends und Dienstanhängen müssen sowohl die Weiterleitungsregeln für Nutzer als auch für Ersteller IPv4 verwenden.

Features und Kompatibilität

In den folgenden Tabellen weist ein Häkchen darauf hin, dass ein Feature unterstützt wird, und ein Nein-Symbol weist darauf hin, dass ein Feature nicht unterstützt wird.

Je nachdem, welcher Ersteller-Load-Balancer ausgewählt wird, kann der Erstellerdienst den Zugriff über Endpunkte, Back-Ends oder beides unterstützen.

Unterstützung für Endpunkte

In diesem Abschnitt sind die Konfigurationsoptionen zusammengefasst, die Nutzern und Produzenten zur Verfügung stehen, wenn sie Endpunkte zum Zugriff auf veröffentlichte Dienste verwenden.

Nutzerkonfiguration

In dieser Tabelle sind die unterstützten Konfigurationsoptionen und -funktionen von Endpunkten, die auf veröffentlichte Dienste zugreifen, nach Zielerstellertyp zusammengefasst.

Ziel-Producer	Nutzerkonfiguration (Endpunkt)
	Globaler Nutzerzugriff	Hybridzugriff	Automatische DNS-Konfiguration (nur IPv4)	VPC-Netzwerk-Peering-Zugriff	Verbindungsweitergabe im Network Connectivity Center (nur IPv4)	Unterstützte Zieldienste für IPv4-Endpunkte	Unterstützte Zieldienste für IPv6-Endpunkte
Regionsübergreifender interner Application Load Balancer						IPv4-Dienste	IPv4-Dienste
Interner Passthrough-Network Load Balancer	Nur wenn globaler Zugriff auf dem Load Balancer aktiviert ist (bekanntes Problem)					IPv4-Dienste	IPv4-Dienste IPv6-Dienste
Interne Protokollweiterleitung (Zielinstanz)	Nur wenn globaler Zugriff auf die Weiterleitungsregel des Produzenten aktiviert ist (bekanntes Problem)					IPv4-Dienste	IPv4-Dienste IPv6-Dienste
Portzuordnungsdienste	Nur wenn globaler Zugriff für die Weiterleitungsregel des Erstellers aktiviert ist					IPv4-Dienste	IPv4-Dienste IPv6-Dienste
Regionaler interner Application Load Balancer	Nur wenn globaler Zugriff auf dem Load Balancer aktiviert ist, bevor der Dienstanhang erstellt wird					IPv4-Dienste	IPv4-Dienste
Regionaler interner Proxy-Network Load Balancer	Nur wenn globaler Zugriff auf dem Load Balancer aktiviert ist, bevor der Dienstanhang erstellt wird					IPv4-Dienste	IPv4-Dienste
Sicherer Web-Proxy						IPv4-Dienste	IPv4-Dienste

Erstellerkonfiguration

In dieser Tabelle sind die unterstützten Konfigurationsoptionen und Funktionen veröffentlichter Dienste zusammengefasst, auf die Endpunkte zugreifen.

Produzententyp	Erstellerkonfiguration (veröffentlichter Dienst)
	Unterstützte Ersteller-Back-Ends	PROXY-Protokoll (nur TCP-Traffic)	IP-Version
Regionsübergreifender interner Application Load Balancer	Zonale GCE-VM_IP_PORT-NEGs Hybrid-NEGs Serverlose NEGs Private Service Connect-NEGs Instanzgruppen		IPv4
Interner Passthrough-Network Load Balancer	Zonale GCE_VM_IP-NEGs Instanzgruppen		IPv4 IPv6
Interne Protokollweiterleitung (Zielinstanz)	Nicht zutreffend		IPv4 IPv6
Portzuordnungsdienste	NEG für Portzuordnung		IPv4 IPv6
Regionaler interner Application Load Balancer	Zonale GCE-VM_IP_PORT-NEGs Hybrid-NEGs Serverlose NEGs Private Service Connect-NEGs Instanzgruppen		IPv4
Regionaler interner Proxy-Network Load Balancer	Zonale GCE-VM_IP_PORT-NEGs Hybrid-NEGs Private Service Connect-NEGs Instanzgruppen		IPv4
Sicherer Web-Proxy	Nicht zutreffend		IPv4

Verschiedene Load-Balancer unterstützen unterschiedliche Portkonfigurationen. Einige Load-Balancer unterstützen einen einzelnen Port, andere einen Portbereich und andere alle Ports. Weitere Informationen finden Sie unter Angabe von Ports.

Unterstützung für Back-Ends

Ein Private Service Connect-Back-End für veröffentlichte Dienste erfordert zwei Load Balancer: einen Nutzer-Load-Balancer und einen Ersteller-Load-Balancer. In diesem Abschnitt sind die Konfigurationsoptionen zusammengefasst, die Nutzern und Erstellern zur Verfügung stehen, wenn sie Back-Ends zum Zugriff auf veröffentlichte Dienste verwenden.

Nutzerkonfiguration

In dieser Tabelle werden die Nutzer-Load Balancer beschrieben, die von Private Service Connect-Back-Ends für veröffentlichte Dienste unterstützt werden. Außerdem wird angegeben, welche Back-End-Dienstprotokolle mit jedem Nutzer-Load Balancer verwendet werden können. Die Nutzer-Load Balancer können auf veröffentlichte Dienste zugreifen, die auf unterstützten Ersteller-Load Balancern gehostet werden.

Nutzer-Load Balancer	Protokolle	IP-Version	Regionenübergreifende Ausfallsicherung
Regionsübergreifender interner Application Load Balancer	HTTP HTTPS HTTP2	IPv4
Regionsübergreifender interner Proxy-Network Load Balancer	TCP	IPv4
Globaler externer Application Load Balancer Hinweis: Der klassische Application Load Balancer wird nicht unterstützt.	HTTP HTTPS HTTP2	IPv4
Globaler externer Proxy-Network Load Balancer Wenn Sie diesen Load Balancer mit einer Private Service Connect-NEG verknüpfen möchten, verwenden Sie die Google Cloud CLI oder senden Sie eine API-Anfrage. Hinweis: Der klassische Proxy-Network Load Balancer wird nicht unterstützt.	TCP/SSL	IPv4
Regionaler externer Application Load Balancer	HTTP HTTPS HTTP2	IPv4
Regionaler externer Proxy-Network-Load-Balancer	TCP	IPv4
Regionaler interner Application Load Balancer	HTTP HTTPS HTTP2	IPv4
Regionaler interner Proxy-Network Load Balancer	TCP	IPv4

Erstellerkonfiguration

In dieser Tabelle wird die Konfiguration für die Ersteller-Load-Balancer beschrieben, die von Private Service Connect-Back-Ends für veröffentlichte Dienste unterstützt werden.

Produzententyp	Erstellerkonfiguration (veröffentlichter Dienst)
	Unterstützte Ersteller-Back-Ends	Weiterleitungsregelprotokolle	Weiterleitungsregelports	Proxyprotokoll	IP-Version	Private Service Connect-Support für Health
Regionsübergreifender interner Application Load Balancer	Zonale GCE-VM_IP_PORT-NEGs Hybrid-NEGs Serverlose NEGs Private Service Connect-NEGs Instanzgruppen	TCP HTTP HTTPS HTTP/2 gRPC	Unterstützt einen, mehrere oder alle Ports		IPv4
Interner Passthrough-Network Load Balancer	Zonale GCE_VM_IP-NEGs Instanzgruppen	TCP	Weitere Informationen findest du unter Konfiguration des Producer-Ports.		IPv4
Regionaler interner Application Load Balancer	Zonale GCE-VM_IP_PORT-NEGs Hybrid-NEGs Serverlose NEGs Private Service Connect-NEGs Instanzgruppen	HTTP HTTPS HTTP/2	Unterstützt einen einzelnen Anschluss		IPv4
Regionaler interner Proxy-Network Load Balancer	Zonale GCE-VM_IP_PORT-NEGs Hybrid-NEGs Private Service Connect-NEGs Instanzgruppen	TCP	Unterstützt einen einzelnen Anschluss		IPv4
Sicherer Web-Proxy	Nicht zutreffend	Nicht zutreffend	Nicht zutreffend		IPv4

Hinweis:Damit der Zugriff über ein Private Service Connect-Back-End in einem globalen oder regionsübergreifenden Load Balancer möglich ist, muss der globale Zugriff für den Load Balancer des Dienstanbieters aktiviert sein, bevor der Dienstanhang erstellt wird. Deaktivieren Sie den globalen Zugriff nicht, wenn es Private Service Connect-NEGs mit globalem Zugriff gibt, die mit einem Producer-Load-Balancer verbunden sind (bekanntes Problem).

Konfiguration des Ersteller-Ports

Wenn ein interner Passthrough Network Load Balancer mit Private Service Connect veröffentlicht wird, müssen Nutzer, die Private Service Connect-Backends verwenden, um auf den Dienst zuzugreifen, wissen, welchen Port sie für die Kommunikation mit dem Dienst verwenden müssen. Beachten Sie beim Erstellen der Weiterleitungsregel für den internen Passthrough-Network Load Balancer des Erstellers Folgendes:

• Wir empfehlen, den Nutzern mitzuteilen, welcher Port in der Weiterleitungsregel des Erstellers verwendet wird, damit sie den Port beim Erstellen eines NEG angeben können.

• Wenn Nutzer beim Erstellen ihrer NEGs keinen Ersteller-Port angeben, wird der Ersteller-Port anhand der Konfiguration der Weiterleitungsregel des Erstellers bestimmt:

  • Wenn die Weiterleitungsregel des Erstellers einen einzelnen Port verwendet, verwendet das Verbraucher-Backend denselben Port.

  • Wenn in der Weiterleitungsregel des Erstellers mehrere Ports verwendet werden, gilt Folgendes:

    • Wenn Port 443 enthalten ist, verwendet das Verbraucher-Backend Port 443.
    • Wenn Port 443 nicht enthalten ist, verwendet das Verbraucher-Backend den ersten Port in der Liste, nachdem die Liste alphabetisch sortiert wurde. Wenn Sie beispielsweise Port 80 und Port 1111 angeben, verwendet das Verbraucher-Backend Port 1111.

    • Wenn Sie ändern, welche Ports von den Ersteller-Backends verwendet werden, kann es zu einer Dienstunterbrechung für die Nutzer kommen.

      Angenommen, Sie erstellen einen veröffentlichten Dienst mit einer Weiterleitungsregel, die die Ports 443 und 8443 verwendet, und Backend-VMs, die auf Ports 443 und 8443 reagieren. Wenn ein Nutzer-Backend eine Verbindung zu diesem Dienst herstellt, verwendet es Port 443 für die Kommunikation.

      Wenn Sie die Backend-VMs so ändern, dass sie nur auf Port 8443 reagieren, kann das Verbraucher-Backend den veröffentlichten Dienst nicht mehr erreichen.

• Wenn in der Weiterleitungsregel des Erstellers alle Ports verwendet werden, muss der Dienstnutzer beim Erstellen der NEG einen Erstellerport angeben. Wenn kein Port angegeben wird, verwendet das Verbraucher-Backend Port 1, was nicht funktioniert.

Freigegebene VPC

Dienstprojektadministratoren können Dienstanhänge in Dienstprojekten mit freigegebener VPC erstellen, die eine Verbindung zu Ressourcen in freigegebenen VPC-Netzwerken herstellen.

Die Konfiguration ist mit Ausnahme der folgenden Punkte mit der Konfiguration eines regulären Dienst-Anhangs identisch:

• Die Weiterleitungsregel des Load Balancers des Erstellers ist mit einer IP-Adresse aus dem freigegebenen VPC-Netzwerk verknüpft. Das Subnetz der Weiterleitungsregel muss für das Dienstprojekt freigegeben werden.
• Der Dienstanhang verwendet ein Private Service Connect-Subnetz aus dem freigegebenen VPC-Netzwerk. Dieses Subnetz muss für das Dienstprojekt freigegeben werden.

Logging

Sie können VPC-Flusslogs in den Subnetzen aktivieren, die die Back-End-VMs enthalten. Die Logs zeigen den Datenfluss zwischen den Back-End-VMs und den IP-Adressen im Subnetz „Private Service Connect”.

Hinweis: Es ist möglich, VPC-Flusslogs für das Subnetz „Private Service Connect” zu aktivieren. Da jedoch keine VMs mit diesem Subnetz verbunden sind, werden keine Abläufe protokolliert.

VPC Service Controls

VPC Service Controls und Private Service Connect sind miteinander kompatibel. Wenn sich das VPC-Netzwerk, in dem der Private Service Connect-Endpunkt bereitgestellt wird, in einem VPC Service Controls-Perimeter befindet, ist der Endpunkt Teil desselben Perimeters. Alle von VPC Service Controls unterstützten Dienste, auf die über den Endpunkt zugegriffen wird, unterliegen den Richtlinien dieses VPC Service Controls-Perimeters.

Wenn Sie einen Endpunkt erstellen, werden zwischen den Nutzer- und Erstellerprojekten API-Aufrufe auf Steuerungsebene ausgeführt, um eine Private Service Connect-Verbindung herzustellen. Das Einrichten einer Private Service Connect-Verbindung zwischen Nutzer- und Herstellerprojekten, die sich nicht im selben VPC Service Controls-Perimeter befinden, erfordert keine explizite Autorisierung mit Richtlinien für ausgehenden Traffic. Die Kommunikation mit von VPC Service Controls unterstützten Diensten über den Endpunkt ist durch den VPC Service Controls-Perimeter geschützt.

Informationen zur Nutzerverbindung aufrufen

Standardmäßig übersetzt Private Service Connect die Quell-IP-Adresse des Nutzers in eine Adresse in einem der Private Service Connect-Subnetze im VPC-Netzwerk des Diensterstellers. Wenn Sie stattdessen die ursprüngliche Quell-IP-Adresse des Nutzers sehen möchten, können Sie das PROXY-Protokoll aktivieren, wenn Sie einen Dienst veröffentlichen. Private Service Connect unterstützt das PROXY-Protokoll Version 2.

Das PROXY-Protokoll wird nicht von allen Diensten unterstützt. Weitere Informationen finden Sie unter Features und Kompatibilität.

Wenn das PROXY-Protokoll aktiviert ist, können Sie die Quell-IP-Adresse und die PSC-Verbindungs-ID (pscConnectionId)des Nutzers aus dem PROXY-Protokoll-Header abrufen.

Das Format der PROXY-Protokoll-Header hängt von der IP-Version des Endpunkts des Verbrauchers ab. Wenn der Load Balancer Ihres Dienstanhangs eine IPv6-Adresse hat, können Nutzer sowohl eine IPv4- als auch eine IPv6-Adresse verwenden. Konfigurieren Sie Ihre Anwendung so, dass sie PROXY-Protokoll-Header für die IP-Version des Traffics empfängt und liest, den sie empfangen soll.

Bei Nutzer-Traffic, der über eine weitergeleitete Verbindung fließt, beziehen sich die Quell-IP-Adresse des Nutzers und die PSC-Verbindungs-ID auf den weitergeleiteten Private Service Connect-Endpunkt.

Wenn Sie das PROXY-Protokoll für einen Dienstanhang aktivieren, gilt die Änderung nur für neue Verbindungen. Vorhandene Verbindungen enthalten keinen PROXY-Protokoll-Header.

Wenn Sie das PROXY-Protokoll aktivieren, finden Sie in der Dokumentation zur Backend-Webserver-Software Informationen zum Parsen und Verarbeiten eingehender PROXY-Protokoll-Header in der TCP-Nutzlast der Clientverbindung. Wenn das PROXY-Protokoll auf dem Dienstanhang aktiviert ist, der Backend-Webserver aber nicht für die Verarbeitung von PROXY-Protokoll-Headern konfiguriert ist, können Webanfragen fehlerhaft sein. Wenn die Anfragen fehlerhaft sind, kann der Server die Anfrage nicht interpretieren.

Wichtig: Das Aktivieren des PROXY-Protokolls ist kein Ersatz für Sicherheitsprotokolle in der Anwendungsschicht und ersetzt nicht die standardmäßigen Verschlüsselungs- und Authentifizierungsmechanismen, z. B. End-to-End-Protokolle wie TLS.

Die Private Service Connect-Verbindungs-ID (pscConnectionId) wird im PROXY-Protokoll-Header im TLV-Format (Typ-Länge-Wert) codiert.

Feld	Feldlänge	Feldwert
Typ	1 Byte	0xE0 (PP2_TYPE_GCP)
Länge	2 Byte	0x8 (8 Byte)
Wert	8 Byte	Die 8-Byte-pscConnectionId in Netzwerkreihenfolge

Sie können den 8-Byte-pscConnectionId-Wert in der Nutzer-Weiterleitungsregel oder im Anhang für den Dienstanbieter einsehen.

Der pscConnectionId-Wert ist global für alle aktiven Verbindungen zu einem bestimmten Zeitpunkt eindeutig. Im Laufe der Zeit kann jedoch eine pscConnectionId in folgenden Szenarien wiederverwendet werden:

• Wenn Sie in einem bestimmten VPC-Netzwerk einen Endpunkt (Weiterleitungsregel) löschen und einen neuen Endpunkt mit derselben IP-Adresse erstellen, wird möglicherweise derselbe pscConnectionId-Wert verwendet.

• Wenn Sie ein VPC-Netzwerk löschen, das Endpunkte (Weiterleitungsregeln) enthält, kann nach einer siebentägigen Wartezeit der für diese Endpunkte verwendete pscConnectionId-Wert für einen anderen Endpunkt in ein weiteres VPC-Netzwerk verwendet werden.

Sie können pscConnectionId-Werte für das Debugging und zum Verfolgen der Paketquellen verwenden.

Eine separate 16-Byte-Private Service Connect-Anhangs-ID (pscServiceAttachmentId) ist über den Dienstanhang des Erstellers verfügbar. Der Wert „pscServiceAttachmentId“ ist eine global eindeutige ID, mit der ein Private Service Connect-Dienstanhang identifiziert wird. Sie können den Wert pscServiceAttachmentId für Sichtbarkeit und Debugging verwenden. Dieser Wert ist nicht im PROXY-Protokoll-Header enthalten.

Preise

Die Preise für Private Service Connect werden auf der Seite "VPC-Preise" beschrieben.

Kontingente

Die Gesamtzahl der Private Service Connect-Endpunkte und weitergeleiteten Verbindungen, die von einem beliebigen Nutzer auf Ihr VPC-Netzwerk des Diensterstellers zugreifen können, wird durch das Kontingent PSC ILB consumer forwarding rules per producer VPC network gesteuert.

Endpunkte tragen bis zu ihrem Löschen zu diesem Kontingent bei, auch wenn der zugehörige Dienstanhang gelöscht oder so konfiguriert ist, dass die Verbindung abgelehnt wird. Fortgeleitete Verbindungen tragen zu diesem Kontingent bei, bis der zugehörige Endpunkt gelöscht wird, auch wenn die Verbindungsweiterleitung am Network Connectivity Center-Hub deaktiviert ist oder der Spoke der fortgeleiteten Verbindung gelöscht wird.

Lokaler Zugriff

Private Service Connect-Dienste werden über Endpunkte verfügbar gemacht. Auf diese Endpunkte kann über unterstützte verbundene lokale Hosts zugegriffen werden. Weitere Informationen finden Sie unter Über lokale Hosts auf den Endpunkt zugreifen.

Beschränkungen

Für veröffentlichte Dienste gelten folgende Einschränkungen:

• Load Balancer, die mit mehreren Protokollen konfiguriert sind – das Protokoll ist auf L3_DEFAULT festgelegt –, werden nicht unterstützt.
• Bei der Paketspiegelung können keine Pakete für Traffic von veröffentlichten Private Service Connect-Diensten gespiegelt werden.
• Sie müssen die Google Cloud CLI oder die API verwenden, um einen Dienstanhang zu erstellen, der auf eine Weiterleitungsregel verweist, die für die interne Protokollweiterleitung verwendet wird.

Informationen zu Problemen und Problemumgehungen finden Sie unter Bekannte Probleme.