Private IP-Adresse

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.

Übersicht

Wenn Sie eine Cloud SQL-Instanz für die Nutzung privater IP-Adressen konfigurieren, verwenden Sie den Zugriff auf private Dienste. Der Zugriff auf private Dienste wird als eine VPC-Peering-Verbindung zwischen Ihrem VPC-Netzwerk und dem zugrunde liegenden VPC-Netzwerk von Google-Diensten implementiert, in dem sich Ihre Cloud SQL-Instanz befindet. Auch wenn mehrere IP-Bereiche zugewiesen werden können, wird der von der privaten IP-Adresse verwendete IP-Bereich immer von Google zugewiesen. IP-Traffic, der Zugriff auf private Dienste nutzt, wird nicht über das öffentliche Internet geleitet. Daher sind die Angriffsvektoren begrenzt. Außerdem haben private IP-Adressen eine geringere Netzwerklatenz als öffentliche IP-Adressen.

Mit dem Zugriff auf private Dienste können Sie eine Verbindung zu folgenden Ressourcen herstellen:

  • Cloud SQL-Ressourcen mit Zugriff auf ein VPC-Netzwerk

  • Cloud SQL-Ressourcen von externen Quellen über einen VPN-Tunnel oder Cloud Interconnect zu Ihrem VPC-Netzwerk.

Über eine private IP-Adresse können Sie aus einer beliebigen Region eine Verbindung herstellen. Sie können auch über freigegebene VPCs eine Verbindung zwischen Projekten herstellen.

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 erstellt ein Subnetz aus dem zugewiesenen Block, um neue Ressourcen in einer bestimmten Region, wie Cloud SQL-Instanzen, bereitzustellen.

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. Zum Beispiel können VM-Instanzen nur mit Cloud SQL-Instanzen kommunizieren, die sich in derselben Region befinden. Weitere Informationen finden Sie in der Dokumentation des jeweiligen Diensts.
  • Die Kosten für ausgehenden Traffic 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.

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 diese API auch für das Hostprojekt aktivieren.

  • Um eine Zugriffsverbindung für private Dienste zu verwalten, sollte der Nutzer die folgenden IAM-Berechtigungen haben. Wenn Sie nicht die erforderlichen Berechtigungen haben, können Fehler auftreten.
    • compute.networks.list
    • compute.addresses.create
    • compute.addresses.list
    • servicenetworking.services.addPeering

    Wenn Sie ein freigegebenes VPC-Netzwerk verwenden, müssen Sie den Nutzer auch dem Hostprojekt hinzufügen und ihm dort dieselbe Berechtigung zuweisen.

Netzwerkprobleme

Cloud SQL weist jeder Kombination aus Region und Datenbanktyp ein /24-Subnetz aus dem IP-Bereich für den Zugriff auf private Dienste zu. Wenn beispielsweise MySQL-Instanzen in zwei Regionen platziert werden sollen, muss der zugewiesene IP-Adressbereich mindestens zwei verfügbare Subnetze der Größe /24 enthalten. Für das Bereitstellen von MySQL und PostgreSQL in zwei Regionen sind vier verfügbare Subnetze der Größe /24 erforderlich. SQL Server-Instanzen können in einer Region das Subnetz mit MySQL-Instanzen teilen.

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. Adressen außerhalb des RFC 1918-Bereichs müssen als autorisierte Netzwerke konfiguriert sein.

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.

Übersicht über das Einrichten des Zugriffs auf private Dienste für Ihr Netzwerk

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.

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. Allerdings haben Sie in einem freigegebenen VPC-Netzwerk nicht die Möglichkeit, einer vorhandenen Cloud SQL-Instanz eine private IP-Adresse zuzuordnen.
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 am Netzwerk vornehmen, mit dem sie verbunden ist, wird die Instanz neu gestartet. Dies führt zu einer Ausfallzeit von einigen Minuten.
Statische IP-Adressen Die private IP-Adresse der Cloud SQL-Instanz ist statisch. Sie ändert sich nicht.
Replikate Ein Replikat übernimmt den privaten IP-Status von seiner primären Instanz. Sie können private IP-Adressen nicht direkt auf einem Replikat konfigurieren.
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. Damit die private IP-Adresse verwendet wird, muss der Nutzer das Flag -ip_address_types=PRIVATE an den Cloud SQL Auth-Proxy übergeben. Weitere Informationen.
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 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 mit N2 und N3 verbunden ist, aber N2 und N3 nicht direkt miteinander verbunden sind, kann das VPC-Netzwerk N2 nicht per VPC-Netzwerk-Peering mit dem VPC-Netzwerk N3 kommunizieren.

Cloud SQL-Instanzen in verschiedenen Google Cloud-Projekten können über freigegebene VPC-Netzwerke miteinander verbunden werden.

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