Informationen zur Verwendung privater IP-Adressen

Auf dieser Seite finden Sie Informationen zur Verwendung privater IP-Adressen mit Cloud SQL. Eine detaillierte Anleitung zum Konfigurieren einer Cloud SQL-Instanz für die Verwendung einer privaten IP-Adresse finden Sie unter Private IP-Adresse konfigurieren.

Informationen zu Terraform-Lösungen für Cloud SQL-Netzwerke finden Sie unter Vereinfachte Netzwerklösungen.

Überblick

Das Konfigurieren einer Cloud SQL-Instanz für die Verwendung privater IP-Adressen erfordert den Zugriff auf private Dienste. Mit dem Zugriff auf private Dienste können Sie private Verbindungen zwischen Ihrem VPC-Netzwerk und dem zugrunde liegenden VPC-Netzwerk des Google-Diensterstellers erstellen. Google-Entitäten, die Dienste anbieten, wie Cloud SQL, werden als Dienstersteller bezeichnet. Jeder Google-Dienst erzeugt ein Subnetz, in dem Ressourcen bereitgestellt werden. Der IP-Adressbereich des Subnetzes ist normalerweise ein /24-CIDR-Block, der vom Dienst ausgewählt wird, und stammt aus dem zugewiesenen IP-Adressbereich.

Private Verbindungen machen Dienste erreichbar, ohne das Internet zu nutzen oder externe IP-Adressen zu verwenden. Aus diesem Grund bieten private IP-Adressen eine geringere Netzwerklatenz als öffentliche IP-Adressen.

Sie verwenden den Zugriff auf private Dienste, um eine Verbindung zu Cloud SQL-Instanzen herzustellen:

Sie können in verschiedenen Regionen eine Verbindung zu privaten IP-Adressen herstellen. Sie können die Verbindung zwischen Projekten auch mithilfe einer freigegebenen VPC herstellen.

Zugewiesene IP-Adressbereiche

Wenn Sie Cloud SQL-Instanzen in einem VPC-Netzwerk mit privater IP-Adresse verwenden möchten, müssen Sie IP-Adressbereiche zuweisen, um den Zugriff auf private Dienste für diese VPC einzurichten. Zum Organisieren Ihrer Cloud SQL-Instanzen möchten Sie möglicherweise mehrere IP-Adressbereiche für die private Verbindung zuweisen. Wenn Sie eine Cloud SQL-Instanz für eine private IP-Adresse konfigurieren, können Sie sowohl das VPC-Netzwerk als auch den zugewiesenen IP-Adressbereich auswählen.

Größe des zugewiesenen Bereichs

Weisen Sie Cloud SQL und anderen von Google verwalteten Diensten, die Sie nutzen möchten, ausreichend große IP-Bereiche zu, da jeder dieser Dienste dedizierte IP-Blöcke aus den zugewiesenen Bereichen benötigt. Die Mindestgröße ist ein einzelner /24-Block (256 Adressen). Die empfohlene Größe ist ein /16-Block (65.536 Adressen).

Wenn Sie einen IP-Adressbereich zuweisen, müssen Sie die Anzahl der zu erstellenden Instanzen berücksichtigen.

Subnetzmaske Adressen Nutzbare Cloud SQL-Instanzen
/2425650
/23512100
/221.024200
/212.048400
/204.096800

Cloud SQL verwendet /24-CIDR-Bereiche als Bereichseinheit, und jede Einheit kann nur für Cloud SQL-Instanzen in einer einzigen Region verwendet werden. Wenn Sie beispielsweise zwei Cloud SQL-Instanzen erstellen, aber für zwei verschiedene Regionen, müssen mindestens zwei /24-CIDR-Bereiche vorhanden sein.

Wenn ein Projekt vor dem 1. April 2021 begonnen hat, Cloud SQL zu verwenden, können Postgres-Instanzen außerdem nicht dieselbe Bereichseinheit mit MySQL- und SQL Server-Instanzen teilen, sondern müssen in jeder Region eine eigene haben. Neuere Projekte unterliegen dieser Einschränkung nicht.

Zugriff auf private Dienste für Ihr Netzwerk einrichten

Wenn Sie erstmalig eine private IP-Verbindung in einem bestimmten VPC-Netzwerk konfigurieren, müssen Sie einmalig den Zugriff auf private Dienste für Cloud SQL einrichten.

Nachdem Sie den Zugriff auf private Dienste eingerichtet haben, können Sie eine Cloud SQL-Instanz erstellen, die für die Verwendung einer privaten IP-Adresse konfiguriert ist, oder eine private IP-Adresse für eine vorhandene Cloud SQL-Instanz konfigurieren. Eine detaillierte Anleitung finden Sie unter Private IP-Adresse konfigurieren.

Jedes Mal, wenn Sie eine bestehende Verbindung ändern, müssen Sie auch vpc-peerings aktualisieren.

Anforderungen für private IP-Adressen

Ihre Netzwerk- und Anwendungsumgebung muss die folgenden Voraussetzungen erfüllen, um private IP-Adressen zu verwenden: Außerdem erfordert das erstmalige Einrichten einer privaten IP-Adresse zusätzliche IAM-Berechtigungen.

Anforderungen an die Anwendungsumgebung

  • Wenn Sie von GKE aus eine Verbindung herstellen, müssen Sie GKE 1.8 oder höher in einem VPC-nativen Cluster ausführen.

API- und IAM-Anforderungen

  • Sie müssen die Service Networking API für Ihr Projekt aktivieren.

    • Wenn Sie ein freigegebenes VPC-Netzwerk verwenden, müssen Sie die Service Networking API auch für das Hostprojekt aktivieren.

  • Um eine Zugriffsverbindung auf private Dienste zu verwalten, muss Ihr Nutzer die folgenden IAM-Berechtigungen haben. Wenn der Nutzer nicht über die erforderlichen Berechtigungen verfügt, können Fehler aufgrund unzureichender Berechtigungen auftreten.
    • compute.networks.list
    • compute.addresses.create
    • compute.addresses.list
    • servicenetworking.services.addPeering

    Wenn Sie ein freigegebenes VPC-Netzwerk verwenden, müssen Sie im Hostprojekt denselben Nutzer hinzufügen und dieselben Berechtigungen zuweisen.

Beispiel

Im folgenden Beispiel hat das VPC-Netzwerk des Kunden Google-Diensten den Adressbereich 10.240.0.0/16 zugewiesen und eine private Verbindung eingerichtet, die den zugewiesenen Bereich verwendet. Jeder Google-Dienst (z. B. Cloud SQL) erstellt ein Subnetz aus dem zugewiesenen Block, um neue Ressourcen in einer bestimmten Region bereitzustellen, z. B. Cloud SQL-Instanzen.

Diagrammübersicht der privaten IP-Konfiguration.

  • Die private Verbindung ist dem zugewiesenen Bereich 10.240.0.0/16 zugeordnet. Aus dieser Zuweisung können Google-Dienste Subnetze erstellen, in denen neue Ressourcen bereitgestellt werden.
  • Auf der Google-Dienst-Seite der privaten Verbindung erstellt Google ein Projekt für den Kunden. Das Projekt ist isoliert, was bedeutet, dass keine anderen Kunden es teilen und dem Kunden nur die Ressourcen in Rechnung gestellt werden, die der Kunde bereitstellt.
  • Jeder Google-Dienst erzeugt ein Subnetz, in dem Ressourcen bereitgestellt werden. Der IP-Adressbereich des Subnetzes ist normalerweise ein /24-CIDR-Block, der vom Dienst ausgewählt wird, und stammt aus dem zugewiesenen IP-Adressbereich. Das Subnetz des Diensterstellers können Sie nicht ändern. Ein Dienst stellt neue Ressourcen in vorhandenen regionalen Subnetzen bereit, die zuvor von diesem Dienst erstellt wurden. Wenn ein Subnetz voll ist, erstellt der Dienst ein neues Subnetz in derselben Region.
  • VM-Instanzen im Kundennetzwerk können auf Dienstressourcen in jeder Region zugreifen, wenn der Dienst dies unterstützt. Einige Dienste unterstützen jedoch möglicherweise keine regionenübergreifende Kommunikation. Weitere Informationen finden Sie in der Dokumentation des jeweiligen Diensts.
  • Die Kosten für ausgehende Datenübertragung für regionenübergreifenden Traffic, bei dem eine VM-Instanz mit Ressourcen in einer anderen Region kommuniziert, fallen weiterhin an.
  • Der Cloud SQL-Instanz wird die IP-Adresse 10.240.0.2 zugeordnet. Im VPC-Netzwerk des Kunden werden Anfragen mit dem Ziel 10.240.0.2 über die private Verbindung an das Netzwerk des Diensterstellers weitergeleitet. Das Dienstnetzwerk enthält Routen, über die die Anfrage anschließend an die richtige Ressource weitergeleitet wird.
  • Der Traffic zwischen VPC-Netzwerken verläuft intern im Google-Netzwerk, nicht über das öffentliche Internet.

Netzwerkprobleme

Cloud SQL weist jeder Region ein /24-Subnetz aus dem IP-Bereich für den Zugriff auf private Dienste zu. Wenn beispielsweise SQL Server-Instanzen in zwei Regionen platziert werden sollen, müssen die zugewiesenen IP-Adressbereiche mindestens zwei verfügbare Subnetze der Größe /24 enthalten.

Verbindungen zu einer Cloud SQL-Instanz mit einer privaten IP-Adresse werden für RFC 1918-Adressbereiche automatisch autorisiert. Auf diese Weise können alle privaten Clients auf die Datenbank zugreifen, ohne den Cloud SQL Auth-Proxy zu verwenden.

Cloud SQL lernt standardmäßig keine Subnetzrouten außerhalb des RFC 1918-Bereichs von Ihrer VPC. Sie müssen deshalb das Netzwerk-Peering auf Cloud SQL aktualisieren, um Routen außerhalb des RFC 1918-Bereichs exportieren zu können.

Sicherheit

Traffic, der über den Zugriff auf private Dienste geleitet wird, wird mit einem bestimmten Grad an Verschlüsselung bereitgestellt. Weitere Informationen finden Sie unter Virtuelle Netzwerkverschlüsselung und -authentifizierung von Google Cloud.

Der Cloud SQL Auth-Proxy kann so konfiguriert werden, dass eine Verbindung über eine private IP-Adresse hergestellt wird. Er bietet eine Authentifizierung über IAM-Anmeldedaten sowie eine Ende-zu-Ende-Verschlüsselung mit einem rotierenden SSL/TLS-Zertifikat.

Wenn Ihre Sicherheitsanforderungen von Ihnen selbst verwaltete SSL/TLS-Zertifikate vorschreiben, verwenden Sie die Anleitungen unter SSL/TLS konfigurieren.

Für jede Instanz ein VPC-Netzwerk mit einer privaten IP-Adresse zu erstellen, gewährleistet eine bessere Netzwerkisolation, als alle Instanzen im "Standard"-VPC-Netzwerk zu erstellen.

Mehrere VPC-Verbindungen

Cloud SQL unterstützt private IP-Adressen über den privaten Dienstzugriff. Wenn Sie eine Cloud SQL-Instanz erstellen, erstellt Cloud SQL die Instanz in ihrer eigenen Virtual Private Cloud (VPC), die sogenannten Cloud SQL-VPC. Zum Aktivieren einer privaten IP-Adresse muss eine Peering-Verbindung zwischen der Cloud SQL-VPC und Ihrem VPC-Netzwerk eingerichtet werden. Dadurch können Ressourcen in Ihrem VPC-Netzwerk auf die internen IP-Adressen Ihrer Cloud SQL-Ressourcen im Cloud SQL-VPC-Netzwerk zugreifen.

Mithilfe von VPC-Netzwerk-Peering implementiert Cloud SQL den Zugriff auf private Dienste intern. Dadurch können interne IP-Adressen eine Verbindung über zwei VPC-Netzwerke herstellen, unabhängig davon, ob sie zum selben Projekt oder zur selben Organisation gehören. Da das VPC-Netzwerk-Peering jedoch nicht transitiv ist, sendet es nur Routen zwischen den beiden VPCs, die direkt per Peering verbunden sind. Wenn Sie eine zusätzliche VPC haben, kann sie nicht über die mit Ihrer ursprünglichen VPC eingerichtete Verbindung auf Ihre Cloud SQL-Ressourcen zugreifen.

Um diese Einschränkung zu umgehen und Ihre Cloud SQL-Instanz über mehrere private IP-Adressen mit mehreren VPCs zu verbinden, können Sie die folgenden Verbindungsoptionen verwenden:

  • Verbindung über benutzerdefiniertes Route Advertisement herstellen
  • Verbindung über einen Zwischenproxy (SOCKS5) herstellen
  • Verbindung über Cloud SQL Auth-Proxy als Dienst herstellen

Weitere Informationen zum Verbinden mehrerer VPCs finden Sie unter Instanz mit mehreren VPCs verbinden.

Kurzreferenz zu Themen rund um private IP-Adressen

Wenn Sie Cloud SQL-Instanzen mit einer privaten IP-Adresse verwalten, interessieren Sie vielleicht die folgenden Themen:

Thema Diskussion
Freigegebene VPC-Netzwerke Sie können Cloud SQL-Instanzen mit privaten IP-Adressen in einem freigegebenen VPC-Netzwerk erstellen. Sie können jedoch einer vorhandenen Cloud SQL-Instanz keine private IP-Adresse in einem freigegebenen VPC-Netzwerk zuweisen.
Regionen Sie können in verschiedenen Regionen über private IP-Adressen eine Verbindung herstellen.
Legacy-Netzwerke Sie können keine Verbindung zur privaten IP-Adresse einer Cloud SQL-Instanz von einem Legacy-Netzwerk aus herstellen. Legacy-Netzwerke unterstützen weder VPC-Netzwerk-Peering noch den Zugriff auf private Dienste.
Private IP-Adresse entfernen Nachdem Sie eine Cloud SQL-Instanz für die Verwendung einer privaten IP-Adresse konfiguriert haben, können Sie die Funktion für private IP-Adressen nicht mehr aus der Instanz entfernen.
Öffentliche und private IP-Adressen Sie können sowohl öffentliche als auch private IP-Adressen verwenden, um eine Verbindung zur selben Cloud SQL-Instanz herzustellen. Keine der beiden Verbindungsmethoden wirkt sich auf die andere aus.
Vorhandene Cloud SQL-Instanzen Sie können eine Instanz so konfigurieren, dass sie bei der Instanzerstellung eine private IP-Adresse verwendet. Sie können auch eine vorhandene Instanz für die Verwendung privater IP-Adressen konfigurieren. Wenn Sie eine vorhandene Instanz für die Verwendung einer privaten IP-Adresse konfigurieren oder Änderungen an dem Netzwerk vornehmen, mit dem sie verbunden ist, wird die Instanz neu gestartet. Dies führt zu einer Ausfallzeit von einigen Minuten.
Statische IP-Adressen Bei öffentlichen und privaten IP-Adressen ist die eingehende Adresse der Cloud SQL-Instanz statisch. Sie ändert sich nicht. Die ausgehende Adresse ist nicht immer statisch, mit Ausnahme der ausgehenden öffentlichen IP-Adressen externer Serverreplikate, die immer statisch sind.
Replikate Ein Replikat übernimmt den privaten IP-Status von seiner primären Instanz. Sie können private IP-Adressen nicht direkt für ein Replikat konfigurieren. Wenn Sie eine Verbindung zu einem Replikat über eine private IP-Adresse herstellen, müssen Sie keine zusätzliche private VPC-Verbindung für das Replikat erstellen, da diese ebenfalls von der primären Instanz übernommen wird.
Der Cloud SQL Auth-Proxy Wenn Sie eine Verbindung zu einer Cloud SQL-Instanz mithilfe einer privaten IP-Adresse herstellen möchten, muss sich der Cloud SQL Auth-Proxy auf einer Ressource befinden, die Zugriff auf dasselbe VPC-Netzwerk wie die Instanz hat. Wenn für die Instanz beide Arten von IP-Adressen aktiviert sind, verwendet der Cloud SQL Auth-Proxy standardmäßig die öffentliche IP-Adresse. Um sicherzustellen, dass sie private IP-Adressen verwendet, müssen Sie das Flag -ip_address_types=PRIVATE an den Cloud SQL Auth-Proxy übergeben. Weitere Informationen.
Serverloser VPC-Zugriff Bei Verbindungen von einer serverlosen Quelle wie der App Engine-Standardumgebung, Cloud Run oder Cloud Functions wird Ihre Anwendung oder Funktion direkt über den serverlosen VPC-Zugriff ohne den Cloud SQL Auth-Proxy mit der Instanz verbunden.
VPC-Netzwerk-Peering Eine Verbindung, die den Zugriff auf private Dienste verwendet, ist auf VPC-Netzwerk-Peering angewiesen. Sie erstellen das Peering für das VPC-Netzwerk jedoch nicht explizit, da es Google Cloud-intern ist. Nachdem Sie die Verbindung für den Zugriff auf private Dienste erstellt haben, können Sie sich das zugrunde liegende VPC-Netzwerk-Peering auf der Seite VPC-Netzwerk-Peering in der Google Cloud Console ansehen. Sie sollten es jedoch nur dann löschen, wenn Sie die private Verbindung entfernen möchten.

Weitere Informationen zum VPC-Netzwerk-Peering
VPC Service Controls VPC Service Controls bietet die Möglichkeit, das Risiko der Datenexfiltration zu reduzieren. Mit VPC Service Controls erstellen Sie Perimeter um die Cloud SQL-Instanz. Durch VPC Security Controls wird der Zugriff auf Ressourcen im Perimeter von außerhalb eingeschränkt. Nur Clients und Ressourcen im Perimeter können miteinander interagieren. Weitere Informationen finden Sie unter VPC Service Controls. Wichtige Informationen enthält auch der Abschnitt zu Cloud SQL im Artikel Unterstützte Produkte und Einschränkungen. Informationen zur Verwendung von VPC Service Controls mit Cloud SQL finden Sie unter VPC Service Controls konfigurieren.
Transitives Peering Nur direkt verbundene Peering-Netzwerke können miteinander kommunizieren. Transitives Peering wird nicht unterstützt. Wenn also das VPC-Netzwerk N1 per Peering mit N2 und N3 verbunden ist, aber N2 und N3 nicht direkt miteinander verbunden sind, kann das VPC-Netzwerk N2 nicht über VPC-Netzwerk-Peering mit dem VPC-Netzwerk N3 kommunizieren.

Clients in einem Projekt können mithilfe von freigegebenen VPC-Netzwerken eine Verbindung zu Cloud SQL-Instanzen in mehreren Projekten herstellen.
Cloud SQL-Instanzen verschieben Cloud SQL-Instanzen können nur zwischen Netzwerken verschoben werden, die zu dem Projekt gehören, in dem sie sich befinden. Darüber hinaus können Cloud SQL-Instanzen weder zwischen Projekten noch zwischen Netzwerken verschoben werden, die von verschiedenen Projekten gehostet werden.

Nächste Schritte