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:

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

Wenn Sie einen Dienst veröffentlichen, erstellen Sie ein NAT-Subnetz und wählen einen IP-Adressbereich aus. Die Größe des Subnetzes bestimmt, wie viele Private Service Connect-Endpunkte oder -Back-Ends gleichzeitig eine Verbindung zum Dienstanhang herstellen können.

IP-Adressen werden aus dem NAT-Subnetz entsprechend der Anzahl der Private Service Connect-Verbindungen genutzt. Wenn alle IP-Adressen im NAT-Subnetz genutzt werden, schlagen alle zusätzlichen Private Service Connect-Verbindungen fehl. Daher ist es wichtig, das NAT-Subnetz entsprechend zu dimensionieren.

Berücksichtigen Sie bei der Auswahl einer Subnetzgröße Folgendes:

  • Es gibt vier unbrauchbare IP-Adressen in einem NAT-Subnetz, sodass die Anzahl der verfügbaren IP-Adressen 2(32 - PREFIX_LENGTH) - 4 beträgt. Wenn Sie beispielsweise ein NAT-Subnetz mit der Präfixlänge von /24 erstellen, kann Private Service Connect 252 der IP-Adressen für SNAT verwenden. Ein /29-Subnetz mit vier verfügbaren IP-Adressen ist die kleinste Subnetzgröße, die in VPC-Netzwerken unterstützt wird.
  • Für jeden Endpunkt oder jedes Backend, das mit dem Dienstanhang verbunden ist, wird eine IP-Adresse aus dem NAT-Subnetz genutzt.
  • 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.
  • 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 beispielsweise zwei Endpunkte mit einem einzelnen Dienstanhang verbunden sind, werden zwei IP-Adressen aus dem NAT-Subnetz genutzt. Wenn sich die Anzahl der Endpunkte nicht ändert, können Sie für diesen Dienstanhang ein /29-Subnetz mit vier nutzbaren IP-Adressen verwenden.

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 65.536 TCP- und 65.536 UDP-Verbindungen gleichzeitig von einem einzelnen Private Service Connect-Endpunkt 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. Nutzer-VMs können alle 65.536 Ports 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 die Weiterleitungsregel des Load-Balancers des Dienstes verweist.

  • Für den Zugriff auf einen Dienst erstellt ein Dienstnutzer einen Endpunkt, der auf den Dienstanhang verweist.

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

Auf jeden Load-Balancer kann nur von einem einzelnen Dienstanhang verwiesen werden. Es ist nicht möglich, mehrere Dienstanhänge zu konfigurieren, die denselben Load-Balancer verwenden.

Verbindungseinstellungen

Jeder Dienstanhang hat eine Verbindungseinstellung, die angibt, ob Verbindungsanfragen automatisch akzeptiert werden. Sie haben drei Möglichkeiten zur Auswahl:

  • Alle Verbindungen automatisch akzeptieren. Der Dienstanhang akzeptiert automatisch alle eingehenden Verbindungsanfragen von jedem Nutzer. Die automatische Annahme kann durch eine Organisationsrichtlinie überschrieben werden, die eingehende Verbindungen blockiert.
  • Verbindungen für ausgewählte Netzwerke akzeptieren. Der Dienstanhang akzeptiert nur eingehende Verbindungsanfragen, wenn das Nutzer-VPC-Netzwerk auf der Nutzerannahmeliste des Dienstanhangs steht.
  • Verbindungen für ausgewählte Projekte akzeptieren Der Dienstanhang akzeptiert nur eingehende Verbindungsanfragen, wenn das Nutzerprojekt auf der Nutzerannahmeliste des Dienstanhangs steht.

Wir empfehlen, Verbindungen für ausgewählte Projekte oder Netzwerke zu akzeptieren. Die automatische Annahme aller Verbindungen ist möglicherweise sinnvoll, wenn Sie den Nutzerzugriff auf andere Weise steuern und einen strikten Zugriff auf Ihren Dienst ermöglichen möchten.

Verbindungsstatus

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

Nutzerannahmelisten und Nutzerablehnungslisten

Nutzerannahmelisten und Nutzerablehnungslisten sind eine Sicherheitsfunktion von Dienstanhängen. Mit Annahmelisten und Ablehnungslisten können Dienstersteller angeben, welche Nutzer Private Service Connect-Verbindungen zu ihren Diensten herstellen können. Nutzerannahmelisten geben an, ob eine Verbindung akzeptiert wird, und Nutzerablehnungslisten geben an, ob eine Verbindung abgelehnt wird. Mit beiden Listen können Sie Nutzer nach dem VPC-Netzwerk oder Projekt der verbindenden Ressource angeben. Wenn Sie ein Projekt oder Netzwerk sowohl auf die Annahmeliste als auch auf die Ablehnungsliste setzen, werden Verbindungsanfragen von diesem Projekt oder Netzwerk abgelehnt. Die Angabe von Nutzern nach Ordner wird nicht unterstützt.

Mit Nutzerannahmelisten und Nutzerablehnungslisten können Sie Projekte oder VPC-Netzwerke angeben, jedoch nicht beides gleichzeitig. Sie können eine Liste von einem Typ zum anderen ändern, ohne die Verbindungen zu unterbrechen. Sie müssen die Änderung jedoch in einer einzelnen Aktualisierung vornehmen. Andernfalls könnten einige Verbindungen vorübergehend in den Status "Ausstehend" wechseln.

Informationen zur Interaktion von Nutzerlisten mit Organisationsrichtlinien finden Sie unter Interaktion zwischen Nutzerannahmelisten und Organisationsrichtlinien.

Limits für Nutzerannahmelisten

Für Nutzerannahmelisten gelten Verbindungslimits. Mit diesen Limits wird die Gesamtzahl der Private Service Connect-Endpunkt- und Backend-Verbindungen festgelegt, die ein Dienstanhang vom angegebenen Nutzerprojekt oder VPC-Netzwerk akzeptieren kann.

Ersteller können diese Limits verwenden, um zu verhindern, dass einzelne Nutzer IP-Adressen oder Ressourcenkontingente im Ersteller-VPC-Netzwerk erschöpfen. Jede akzeptierte Private Service Connect-Verbindung wird vom konfigurierten Limit für ein Nutzerprojekt oder ein VPC-Netzwerk abgezogen. Die Limits werden beim create oder Aktualisieren von Nutzerannahmelisten festgelegt. Sie können die Verbindungen eines Dienstanhangs aufrufen, indem Sie ihn beschreiben.

Angenommen, ein Dienstanhang hat eine Nutzerannahmeliste, die project-1 und project-2 mit jeweils einem Limit von einer Verbindung enthält. Das Projekt project-1 fordert zwei Verbindungen an, project-2 fordert eine Verbindung an und project-3 fordert eine Verbindung an. Da project-1 auf eine Verbindung beschränkt ist, wird die erste Verbindung akzeptiert und die zweite bleibt ausstehend. Die Verbindung von project-2 wird akzeptiert und die Verbindung von project-3 bleibt ausstehend. Die zweite Verbindung von project-1 kann akzeptiert werden, indem Sie das Limit für project-1 erhöhen. Wenn project-3 der Annahmeliste hinzugefügt wird, wechselt diese Verbindung von "Ausstehend" zu "Akzeptiert".

Verbindungsabgleich

Mit dem Verbindungsabgleich wird festgelegt, ob sich Aktualisierungen der Zulassungs- oder Ablehnungslisten eines Dienstanhangs auf bestehende Private Service Connect-Verbindungen auswirken können. Wenn der Verbindungsabgleich aktiviert ist, können vorhandene Verbindungen durch das Aktualisieren der Zulassungs- oder Ablehnungslisten beendet werden. Verbindungen, die zuvor abgelehnt wurden, können angenommen werden. Wenn der Verbindungsabgleich deaktiviert ist, wirkt sich die Aktualisierung der Zulassungs- oder Ablehnungslisten nur auf neue und ausstehende Verbindungen aus.

Angenommen, ein Dienstanhang hat mehrere akzeptierte Verbindungen von Project-A. Project-A ist in der Zulassungsliste des Dienstanhangs enthalten. Der Dienstanhang wird aktualisiert. Dazu wird Project-A aus der Zulassungsliste entfernt.

Wenn der Verbindungsabgleich aktiviert ist, werden alle vorhandenen Verbindungen von Project-A zu PENDING übertragen, wodurch die Netzwerkverbindung zwischen den beiden VPC-Netzwerken beendet und der Netzwerktraffic sofort beendet wird.

Wenn der Verbindungsabgleich deaktiviert ist, sind vorhandene Verbindungen von Project-A nicht betroffen. Der Netzwerkverkehr kann weiterhin über die vorhandenen Private Service Connect-Verbindungen fließen. Neue Private Service Connect-Verbindungen sind jedoch nicht zulässig.

Informationen zum Konfigurieren der Verbindungsabgleichung für neue Dienstanhänge finden Sie unter Dienst mit expliziter Genehmigung veröffentlichen.

Informationen zum Konfigurieren des Verbindungsabgleichs für vorhandene Dienstanhänge finden Sie unter Verbindungsabgleich konfigurieren.

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

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

Erstellerkonfiguration:

Nutzerkonfiguration:

In dieser Konfiguration leitet der Endpunkt den Traffic mithilfe der standardmäßigen globalen Load-Balancing-Richtlinie weiter – zuerst nach Status und dann nach dem Standort, der dem Client am nächsten liegt.

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 Traffic an eine NEG in der nächstgelegenen fehlerfreien Region weiterleiten (zum Vergrößern klicken).

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, zusammengefasst.

Nutzerkonfiguration (Endpunkt) Ersteller-LoadBalancer
Interner Passthrough-Network Load Balancer Regionaler interner Application Load Balancer Regionaler interner Proxy-Network Load Balancer Interne Protokollweiterleitung (Zielinstanz)
Globaler Nutzerzugriff

Unabhängig von der globalen Zugriffseinstellung auf dem Load-Balancer

Nur wenn globaler Zugriff auf dem Load-Balancer aktiviert ist, bevor der Dienst-Anhang erstellt wird

Nur wenn globaler Zugriff auf dem Load Balancer aktiviert ist, bevor der Dienst-Anhang erstellt wird

Unabhängig von der globalen Zugriffseinstellung auf dem Load Balancer

Interconnect-Traffic

Cloud VPN-Traffic
Automatische DNS-Konfiguration Nur IPv4 Nur IPv4 Nur IPv4 Nur IPv4
IPv4-Endpunkte
  • Weiterleitungsregeln des IPv4-Erstellers
  • Weiterleitungsregeln des IPv4-Erstellers
  • Weiterleitungsregeln des IPv4-Erstellers
  • Weiterleitungsregeln des IPv4-Erstellers

Erstellerkonfiguration

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

Erstellerkonfiguration (veröffentlichter Dienst) Ersteller-LoadBalancer
Interner Passthrough-Network Load Balancer Regionaler interner Application Load Balancer Regionaler interner Proxy-Network Load Balancer Interne Protokollweiterleitung (Zielinstanz)

Unterstützte Ersteller-Back-Ends

  • Zonale GCE_VM_IP-NEGs
  • Instanzgruppen
  • Zonale GCE-VM_IP_PORT-NEGs
  • Hybrid-NEGs
  • Serverlose NEGs
  • Private Service Connect-NEGs
  • Instanzgruppen
  • Zonale GCE-VM_IP_PORT-NEGs
  • Hybrid-NEGs
  • Serverlose NEGs
  • Private Service Connect-NEGs
  • Instanzgruppen
Nicht zutreffend
Proxyprotokoll Nur TCP-Traffic Nur TCP-Traffic
Sitzungsaffinitätsmodi NONE (5-Tupel)
CLIENT_IP_PORT_PROTO
Nicht zutreffend Nicht zutreffend Nicht zutreffend
IP-Version
  • Weiterleitungsregeln des IPv4-Erstellers
  • Weiterleitungsregeln des IPv4-Erstellers
  • Weiterleitungsregeln des IPv4-Erstellers
  • Weiterleitungsregeln des IPv4-Erstellers

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

Globaler externer Application Load Balancer (unterstützt mehrere Regionen)

Hinweis: Der klassische Application Load Balancer wird nicht unterstützt.

  • HTTP
  • HTTPS
  • HTTP2
IPv4

Regionaler externer Application Load Balancer

  • HTTP
  • HTTPS
  • HTTP2
IPv4

Regionaler interner Application Load Balancer

  • HTTP
  • HTTPS
  • HTTP2
IPv4

Cross-region internal Application Load Balancer

  • HTTP
  • HTTPS
  • HTTP2
IPv4

Regionaler interner Proxy-Network Load Balancer

  • TCP
IPv4

Regionsübergreifender interner Proxy-Network Load Balancer

  • TCP
IPv4

Regionaler externer Proxy-Network-Load-Balancer

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

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.

Konfiguration Ersteller-LoadBalancer
Interner Passthrough-Network Load Balancer Regionaler interner Application Load Balancer Regionaler interner Proxy-Network Load Balancer
Unterstützte Ersteller-Back-Ends
  • Zonale GCE_VM_IP-NEGs
  • Instanzgruppen
  • Zonale GCE-VM_IP_PORT-NEGs
  • Hybrid-NEGs
  • Serverlose NEGs
  • Private Service Connect-NEGs
  • Instanzgruppen
  • Zonale GCE-VM_IP_PORT-NEGs
  • Hybrid-NEGs
  • Serverlose NEGs
  • Private Service Connect-NEGs
  • Instanzgruppen
Weiterleitungsregelprotokolle
  • TCP
  • HTTP
  • HTTPS
  • HTTP/2
  • TCP
Weiterleitungsregelports Wir empfehlen, einen einzelnen Port zu verwenden. Weitere Informationen findest du unter Konfiguration des Producer-Ports. Unterstützt einen einzelnen Anschluss Unterstützt einen einzelnen Anschluss
Proxyprotokoll
IP-Version IPv4 IPv4 IPv4

Konfiguration des Ersteller-Ports

Wenn ein Nutzer-Backend eine Verbindung zu einem veröffentlichten Dienst herstellt, der auf einem internen Passthrough Network Load Balancer gehostet wird, wählt Google Cloud einen Port für den Nutzer aus. Der Port wird anhand der Portkonfiguration der Weiterleitungsregel des Erstellers ausgewählt. Beachten Sie beim Erstellen der Weiterleitungsregel für den Load Balancer des Erstellers Folgendes:

  • Wir empfehlen, einen einzelnen Anschluss anzugeben. In dieser Konfiguration verwendet das Verbraucher-Backend denselben Port.
  • Wenn Sie mehrere Ports angeben, 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.

  • Verwenden Sie nicht --port=ALL. Bei dieser Konfiguration verwendet das Verbraucher-Backend den 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”.

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.

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.

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.

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:

Informationen zu Problemen und Problemumgehungen finden Sie unter Bekannte Probleme.