VPC-Netzwerk-Peering

Mit dem Google Cloud VPC-Netzwerk-Peering sind Verbindungen über interne IP-Adressen zwischen zwei VPC-Netzwerken (Virtual Private Cloud) möglich, unabhängig davon, ob sie zum selben Projekt oder zur selben Organisation gehören.

Das VPC-Netzwerk-Peering ermöglicht das Verbinden von VPC-Netzwerken, sodass Arbeitslasten in verschiedenen VPC-Netzwerken intern kommunizieren können. Der Traffic verbleibt im Google-Netzwerk und durchläuft nicht das öffentliche Internet.

VPC-Netzwerk-Peering eignet sich in diesen Umgebungen:

  • SaaS-Umgebungen (Software as a Service) in Google Cloud. Sie können Dienste in verschiedenen VPC-Netzwerken innerhalb von Organisationen und organisationsübergreifend privat verfügbar machen.
  • Organisationen mit mehreren administrativen Netzwerkdomains, die über interne IP-Adressen kommunizieren müssen.

Wenn Sie in Ihrer Organisation mehrere administrative Netzwerkdomains haben, können Sie mit VPC-Netzwerk-Peering Dienste über interne IP-Adressen in VPC-Netzwerken verfügbar machen. Wenn Sie Dienste für andere Organisationen anbieten, können Sie diesen die Dienste mit VPC-Netzwerk-Peering über interne IP-Adressen zur Verfügung stellen. Die Möglichkeit, Dienste organisationsübergreifend anzubieten, ist nützlich, wenn Sie Dienste für andere Unternehmen anbieten möchten, und wenn Sie mehrere Organisationen besitzen oder für diese verantwortlich sind.

VPC-Netzwerk-Peering bietet im Vergleich zur Verwendung externer IP-Adressen oder VPNs zur Verbindung von Netzwerken diverse Vorteile, unter anderem:

  • Netzwerklatenz: Verbindungen, die nur interne Adressen verwenden, bieten eine geringere Latenz als Verbindungen, die externe Adressen nutzen.
  • Netzwerksicherheit: Dienstinhaber müssen ihre Dienste nicht über das öffentliche Internet anbieten und den zugehörigen Risiken aussetzen.
  • Netzwerkkosten: In Google Cloud werden Gebühren für die Bandbreitennutzung ausgehenden Traffics aus Netzwerken berechnet, die über externe IP-Adressen kommunizieren. Dies gilt auch für Traffic innerhalb derselben Zone. Wenn die Netzwerke jedoch über Peering miteinander verbunden sind, können für die Kommunikation interne IP-Adressen verwendet und die Kosten für ausgehenden Traffic eingespart werden. Für den gesamten Traffic gelten aber weiterhin die normalen Netzwerkpreise.

Informationen zum Erstellen von Peering-Verbindungen finden Sie unter VPC-Netzwerk-Peering verwenden.

Haupteigenschaften

Peering-VPC-Netzwerke haben die folgenden wichtigen Eigenschaften:

  • VPC-Netzwerk-Peering kann mit Compute Engine, GKE und der flexiblen App Engine-Umgebung verwendet werden.
  • Peering-VPC-Netzwerke bleiben administrativ getrennt. Die Routen, Firewalls, VPNs und anderen Trafficmanagementtools werden in jedem VPC-Netzwerk separat verwaltet und angewendet.
  • Alle Komponenten der Peering-Verknüpfung werden unabhängig voneinander eingerichtet. Das Peering ist nur aktiv, wenn beide Seiten übereinstimmend konfiguriert sind. Die Peering-Verknüpfung kann von beiden Seiten jederzeit getrennt werden.
  • Peering und die Option zum Importieren und Exportieren benutzerdefinierter Routen können für ein VPC-Netzwerk konfiguriert werden, auch wenn das andere VPC-Netzwerk noch gar nicht erstellt wurde. Der Routentausch erfolgt jedoch erst, wenn beide Seiten konfiguriert wurden.
  • VPC-Peers tauschen Subnetzrouten, die keine privat wiederverwendeten öffentlichen IP-Adressen nutzen, immer aus. Netzwerke müssen Subnetzrouten, die privat wiederverwendete öffentliche IP-Adressen nutzen, explizit importieren, um sie zu empfangen.
  • Sie können benutzerdefinierte Routen (statische und dynamische Routen) austauschen, je nachdem, ob die Peering-Konfigurationen für den Import oder Export konfiguriert wurden. Weitere Informationen finden Sie unter Benutzerdefinierte Routen importieren und exportieren.
  • Subnetz- und statische Routen sind global. Dynamische Routen können abhängig vom Modus für dynamisches Routing des VPC-Netzwerks regional oder global sein.
  • Für ein VPC-Netzwerk kann Peering mit mehreren anderen VPC-Netzwerken eingerichtet werden, allerdings gibt es hierfür ein Limit.
  • IAM-Berechtigungen zum Erstellen und Löschen von VPC-Netzwerk-Peering sind Bestandteil der Rollen von Projektinhaber, Projektbearbeiter und Netzwerkadministrator.
  • Peering-Traffic (Traffic, der zwischen Peering-Netzwerken fließt) weist die gleiche Latenz, den gleichen Durchsatz und die gleiche Verfügbarkeit wie privater Traffic innerhalb eines Netzwerks auf.
  • Die Abrechnungsrichtlinie für Peering-Traffic entspricht der Abrechnungsrichtlinie für privaten Traffic innerhalb eines Netzwerks.
  • Wenn Sie Administrator für Organisationsrichtlinien sind, können Sie mithilfe einer Organisationsrichtlinie einschränken, welche VPC-Netzwerke mit VPC-Netzwerken in Ihrer Organisation interagieren können. Sie können Peering-Verbindungen zu bestimmten VPC-Netzwerken oder zu VPC-Netzwerken in einem bestimmten Ordner oder einer bestimmten Organisation verhindern. Die Einschränkung gilt für neue Peering-Konfigurationen und wirkt sich nicht auf vorhandene Verbindungen aus. Eine bestehende Peering-Verbindung kann auch dann funktionieren, wenn eine neue Richtlinie keine neuen Verbindungen zulässt. Weitere Informationen finden Sie unter der Einschränkung constraints/compute.restrictVpcPeering.

Beschränkungen

Beim Peering von VPC-Netzwerken gelten die folgenden Beschränkungen:

  • Der CIDR-Bereich eines Subnetzes in einem Peering-VPC-Netzwerk darf sich nicht mit einer statischen Route in einem anderen Peering-Netzwerk überschneiden. Diese Regel gilt sowohl für Subnetzrouten als auch statische Routen. In folgenden Fällen wird in Google Cloud geprüft, ob eine Überschneidung vorliegt, und gegebenenfalls ein Fehler ausgegeben.
    • Wenn VPC-Netzwerke erstmals verbunden werden (Peering)
    • Wenn Sie in einem Peering-VPC-Netzwerk eine Route erstellen
    • Wenn Sie in einem Peering-VPC-Netzwerk ein neues Subnetz erstellen
  • Eine dynamische Route kann sich mit einer Subnetzroute in einem Peering-Netzwerk überschneiden. Bei dynamischen Routen werden die Zielbereiche, die sich mit einer Subnetzroute aus dem Peering-Netzwerk überschneiden, ohne Rückmeldung verworfen. Google Cloud verwendet die Subnetzroute.
  • VPC-Netzwerk-Peering ist nur zwischen VPC-Netzwerken möglich. Ein Peering von Legacy-Netzwerken wird NICHT unterstützt.
  • Sie können den Austausch von Subnetzrouten nicht deaktivieren oder auswählen, welche Subnetzrouten ausgetauscht werden. Nach dem Einrichten des Peerings sind alle Ressourcen, die im Subnetz-IP-Adressbereich liegen, über direkt verbundene Peering-Netzwerke zugänglich. VPC-Netzwerk-Peering bietet keine detaillierte Routensteuerung, um herauszufiltern, welche Subnetz-CIDR-Bereiche innerhalb der Peering-Netzwerke erreichbar sind. Sie müssen bei Bedarf Firewallregeln verwenden, um den Traffic zu filtern. In direkt verbundenen Peering-Netzwerken sind folgende Arten von Endpunkten und Ressourcen erreichbar:
    • Interne IP-Adressen virtueller Maschinen (VMs) in allen Subnetzen
    • Interne IP-Adressen mit Load-Balancing in allen Subnetzen
  • 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.
  • Sie können keine Tags oder Dienstkonten eines Peering-Netzwerks in einem anderen Peering-Netzwerk verwenden.
  • Die in einem Netzwerk erstellten internen DNS-Namen von Compute Engine sind für Peering-Netzwerke nicht erreichbar. Verwenden Sie die IP-Adresse, um die VM-Instanzen in einem Peering-Netzwerk zu erreichen.
  • Standardmäßig wird VPC-Netzwerk-Peering mit GKE bei einer Verwendung mit IP-Aliassen unterstützt. Wenn Sie keine IP-Aliasse verwenden, können Sie benutzerdefinierte Routen exportieren, sodass GKE-Container über Peering-Netzwerke erreichbar sind.

Routingreihenfolge

Prüfen Sie sorgfältig die Routingreihenfolge, um zu erfahren, wie Google Cloud Routingkonflikte zwischen Netzwerken in einer Peering-Gruppe löst.

Benutzerdefinierte Routen importieren und exportieren

Subnetzrouten, die keine privat wiederverwendeten öffentlichen IP-Adressen nutzen, werden immer zwischen Peering-Netzwerken ausgetauscht. Sie können auch benutzerdefinierte Routen austauschen, einschließlich statischer und dynamischer Routen sowie Routen für Subnetze, die privat wiederverwendete öffentliche IP-Adressen nutzen. Dafür müssen die Netzwerkadministratoren in beiden Netzwerken die entsprechenden Peering-Konfigurationen haben.

Wenn Sie benutzerdefinierte Routen importieren, kann Ihr VPC-Netzwerk nur dann benutzerdefinierte Routen vom Peering-Netzwerk erhalten, wenn sie von genau diesem Netzwerk exportiert werden. Das Gleiche gilt beim Export benutzerdefinierter Routen – das Peering-Netzwerk kann nur dann benutzerdefinierte Routen erhalten, wenn sie von diesem Netzwerk importiert werden.

Wenn Sie benutzerdefinierte Routen importieren oder exportieren, tauschen Netzwerke diese Routen nur mit direkt verbundenen Peer-Netzwerken aus. Wenn Ihr VPC-Netzwerk beispielsweise mit mehreren Netzwerken verbunden ist, werden Routen, die Ihr Netzwerk aus einem Peering-Netzwerk importiert, nicht in die anderen Peering-Netzwerke exportiert.

Wenn Sie eine Peering-Konfiguration erstellen oder ändern, können Sie wählen, ob Sie Routen importieren, Routen exportieren oder beides möchten. Der Administrator des Peering-Netzwerks muss die Peering-Konfiguration auf die gleiche Weise festlegen, damit die Routen ausgetauscht werden können. Durch diesen Prozess wird sichergestellt, dass beide Netzwerkadministratoren ausdrücklich zustimmen, benutzerdefinierte Routen auszutauschen, bevor der Austausch stattfindet.

Vorteile des Austauschs benutzerdefinierter Routen

Durch das Freigeben benutzerdefinierter Routen für Peering-VPC-Netzwerke können Netzwerke Routen direkt von ihren Peering-Netzwerken lernen. Wenn zum Beispiel eine benutzerdefinierte Route in einem Peering-Netzwerk aktualisiert wird, lernt Ihr VPC-Netzwerk die aktualisierte benutzerdefinierte Route automatisch und nutzt sie, ohne dass Sie eingreifen müssen.

Der Austausch benutzerdefinierter Routen kann in den folgenden Situationen hilfreich sein:

  • Wenn Sie GKE-Cluster ohne native VPC-Adressierung haben, verfügen Sie möglicherweise über mehrere statische Routen, um Traffic an VM-Instanzen zu leiten, in denen sich Ihre Container befinden. Sie können diese statischen Routen exportieren, sodass die Container über Peering-Netzwerke erreichbar sind.
  • Wenn Sie einen VPN-Tunnel oder eine Interconnect-Verbindung haben, können Sie benutzerdefinierte Routen freigeben, damit Peering-Netzwerke Ihr lokales Netzwerk erreichen können. Bei dynamischen Routen müssen Sie in Ihrem VPC-Netzwerk benutzerdefinierte Route Advertisements für Cloud Router hinzufügen, damit Peering-Netzwerk-Subnetze an Ihr lokales Netzwerk gemeldet werden.

Hinweise

Beachten Sie beim Konfigurieren des Imports oder Exports benutzerdefinierter Routen die folgenden Verhaltensweisen:

  • Beim Peering prüft Google Cloud, ob es Subnetz-IP-Bereiche gibt, die sich mit Subnetz-IP-Bereichen im anderen Netzwerk überschneiden. Wenn es eine Überschneidung gibt, wird das Peering nicht hergestellt. Diese Prüfung der Überschneidung bezieht sich nur auf VPC-Subnetzbereiche. Statische und dynamische Routen werden nicht geprüft. Wenn das Peering ausgeführt wird, werden sie in der vorliegenden Form exportiert.
  • Sowohl statische als auch dynamische Routen werden exportiert bzw. importiert. Sie können nicht nur einen Routentyp importieren oder exportieren.
  • Benutzerdefinierte Routen, die aus einem VPC-Netzwerk importiert wurden, können nicht transitiv in ein anderes Peering-VPC-Netzwerk exportiert werden.
  • Die folgenden Routen sind vom Import und Export ausgeschlossen:
    • Getaggte Routen werden nie zwischen Peering-Netzwerken ausgetauscht. Getaggte Routen sind benutzerdefinierte statische Routen, die mithilfe von Netzwerktags bestimmten VM-Instanzen zugeordnet werden. Netzwerktags können nur in dem VPC-Netzwerk aufgelöst werden, in dem sie erstellt wurden.
    • Statische Routen, bei denen ein nächster Hop das Standard-Internetgateway ist, werden nie ausgetauscht. Beispielsweise wird die Standardroute (0.0.0.0/0) mit dem Standard-Internetgateway als nächstem Hop nicht zwischen Peering-Netzwerken ausgetauscht.
  • Importierte Routen können zu unbeabsichtigten Änderungen am Trafficfluss führen, z. B. Änderungen an der Routingreihenfolge. Weitere Informationen finden Sie unter Routingreihenfolge.
  • Wenn ein VPC-Netzwerk benutzerdefinierte Routen aus einem Peering-Netzwerk importiert, werden die Zielbereiche unverändert importiert. Der nächste Hop für importierte Routen wird jedoch auf den Namen der Peering-Verbindung festgelegt. Traffic wird an das Peering-Netzwerk geleitet, in dem der tatsächliche nächste Hop definiert ist.

Netzwerke in Szenarien mit VPC-Netzwerk-Peering

In den folgenden Abschnitten wird gezeigt, wie sich VPC-Netzwerk-Peering in bestimmten Szenarien verhält.

Überlappende Subnetze zum Zeitpunkt des Peerings

Beim Peering prüft Google Cloud, ob es zwischen den beiden VPC-Netzwerken oder einem ihrer Peering-Netzwerke Subnetze mit sich überschneidenden IP-Bereichen gibt. Gibt es eine solche Überschneidung, wird das Peering nicht hergestellt. Da zwischen den VM-Instanzen eine vollständig vermaschte Verbindung hergestellt wird, dürfen die Subnetze in den Peering-VPC-Netzwerken keine Überschneidungen in den IP-Bereichen aufweisen, weil dies Routingkonflikte verursachen würde.

Überlappende Subnetz-IP-Bereiche bei zwei Peering-Komponenten (zum Vergrößern klicken)
Subnetz-IP-Bereiche mit Überschneidung bei zwei Peering-Komponenten (zum Vergrößern klicken)

Subnetze mit Überschneidungen in den IP-Bereichen der Komponenten eines VPC-Netzwerks verursachen Routingkonflikte. Angenommen, zwischen dem VPC-Netzwerk N1 und dem VPC-Netzwerk N2 wurde bereits ein Peering hergestellt. Nun versucht VPC-Netzwerk N3, ein Peering mit N2 aufzubauen. Dieses Peering wäre ungültig, da N3 das Subnetz Subnet_5 enthält, dessen IP-Bereich sich mit dem von Subnet_1 im Netzwerk N1 überschneidet.

Überlappende Subnetz-IP-Bereiche bei drei Peering-Komponenten (zum Vergrößern klicken)
Subnetz-IP-Bereiche mit Überschneidung bei drei Peering-Komponenten (zum Vergrößern klicken)

Überlappende Subnetze beim Erstellen oder Erweitern von Subnetzen

Wenn ein neues Subnetz erstellt oder der IP-Bereich eines Subnetzes erweitert wird, prüft Google Cloud, ob sich der neue Subnetzbereich mit den IP-Bereichen von Subnetzen im selben VPC-Netzwerk oder in direkt verbundenen Peering-VPC-Netzwerken überschneidet. Ist dies der Fall, schlägt die Erstellung oder Erweiterung fehl. Wenn zum Beispiel in Netzwerk N2 das neue Subnetz Subnet_3 erstellt wird, wie in der nachstehenden Abbildung gezeigt, dürfen sich dessen IP-Bereiche nicht mit denen des direkt verbundenen Peering-Netzwerks N1 überschneiden.

Prüfung bei der Subnetzerstellung (zum Vergrößern klicken)
Prüfung bei der Subnetzerstellung (zum Vergrößern klicken)

Google Cloud stellt außerdem sicher, dass in VPC-Netzwerken mit einem gemeinsamen Peering-Netzwerk keine überlappenden Subnetz-IP-Bereiche zulässig sind. Liegt eine solche Überschneidung vor, schlägt die Erstellung bzw. Erweiterung fehl. Wenn zum Beispiel in Netzwerk N3 das neue Subnetz Subnet_5 erstellt wird, wie in der nachstehenden Abbildung gezeigt, dürfen sich dessen IP-Bereiche weder mit denen des direkt verbundenen Peering-Netzwerks N2 noch mit denen des Netzwerks N1 überschneiden, da N1 bereits mit N2 verbunden ist.

Prüfung bei der Subnetzerstellung mit drei Peering-Komponenten (zum Vergrößern klicken)
Prüfung bei der Subnetzerstellung mit drei Peering-Komponenten (zum Vergrößern klicken)

Lokaler Zugriff aus Peering-Netzwerk

Sie können entweder Cloud VPN oder Cloud Interconnect verwenden, um Ihr lokales Netzwerk sicher mit Ihrem VPC-Netzwerk zu verbinden. Wenn Sie benutzerdefinierte Routen exportieren, können Peering-VPC-Netzwerke auch eine Verbindung zu Ihrem lokalen Netzwerk herstellen. Auf der lokalen Seite müssen Sie Routen erstellen, damit zu VPC-Netzwerken verlaufender Traffic zum VPN-Tunnel geleitet wird.

HA VPN und Cloud Interconnect erfordern dynamisches Routing. Klassische VPN-Tunnel können statisches oder dynamisches Routing verwenden. Bestimmte Anwendungsfälle von klassischen VPN-Tunneln wurden jedoch verworfen.

Verwenden Sie für dynamisches Routing Cloud Router, sodass Routen zwischen Ihrem VPC-Netzwerk und Ihrem lokalen Netzwerk mithilfe des Border Gateway Protocol (BGP) dynamisch aktualisiert werden. Cloud Router können Routen in der Region oder für alle Regionen in einem VPC-Netzwerk lernen und propagieren. Dieses Verhalten hängt vom Modus für dynamisches Routing des VPC-Netzwerks ab, der regional oder global sein kann.

Die folgenden Anwendungsfälle zeigen, wie auf Ressourcen in Peering-VPC-Netzwerken zugegriffen werden kann, nachdem benutzerdefinierte Routen importiert und exportiert wurden. Jedes Beispiel zeigt zwei Netzwerke (network-a und network-b), die per Peering verbunden sind. In einem Beispiel ist der dynamische Routingmodus für network-b regional und im anderen Beispiel global.

Regionales dynamisches Routing

Wenn Sie regionales dynamisches Routing verwenden, können nur Ressourcen in derselben Region wie der Cloud Router auf das lokale Netzwerk zugreifen. Diese Beschränkung gilt für das VPC-Netzwerk des Cloud Routers und jegliche Peering-VPC-Netzwerke, unabhängig vom Modus für dynamisches Routing des Peering-VPC-Netzwerks. Im folgenden Beispiel enthält network-b einen VPN-Tunnel (der auch eine Interconnect-Verbindung sein könnte) und einen Cloud Router. Der dynamische Routingmodus von network-b ist auf "regional" eingestellt. Im Peering-Netzwerk befindet sich subnet-a in derselben Region wie der Cloud Router in network-b.

Nachdem eine Peering-Verbindung hergestellt wurde, kann network-a auf den VPN-Tunnel in network-b zugreifen. Dieser Zugriff ist auf Subnetze beschränkt, die sich in derselben Region wie der Cloud Router befinden. Zum Beispiel kann die VM-Instanz vm-a den VPN-Tunnel erreichen, da sie sich in derselben Region wie der Cloud Router befindet. VM-Instanzen in anderen Regionen können den Tunnel nicht erreichen.

Cloud Router lernt keine Routen und propagiert keine Routen aus Peering-VPC-Netzwerken. Deshalb müssen Sie auf dem Cloud Router ein benutzerdefiniertes Route Advertisement haben, das den Bereich 10.8.1.0/24 in der BGP-Sitzung auf das lokale Netzwerk propagiert.

In der folgenden Tabelle sind die resultierenden Routen für network-a und network-b zusammengefasst, wenn beide die benutzerdefinierten Routen sowohl importieren als auch exportieren:

Netz Ziel Nächster Hop Ursprung
network-a 0.0.0.0/0 Internetgateway lokal
10.8.1.0/24 network-a lokal
10.30.0.0/16 vm-a1 lokal
10.8.2.0/24 Peering von a zu b Peering-Komponente
10.10.0.0/16
(dynamische Route ist begrenzt auf us-west1)
Peering von a zu b Peering-Komponente
network-b 0.0.0.0/0 Internetgateway lokal
10.8.2.0/24 network-b lokal
10.10.0.0/16
(dynamische Route ist begrenzt auf us-west1)
vpn-b lokal
10.8.1.0/24 Peering von b zu a Peering-Komponente
10.30.0.0/16 Peering von b zu a Peering-Komponente

Globales dynamisches Routing

Wenn für network-b globales dynamisches Routing aktiviert ist, können Ressourcen in allen Regionen auf das lokale Netzwerk zugreifen. Dies gilt für das VPC-Netzwerk des Cloud Routers und jegliche Peering-VPC-Netzwerke, unabhängig vom Modus für dynamisches Routing des Peering-VPC-Netzwerks.

Im folgenden Beispiel können Ressourcen in network-a unabhängig von ihrer Region auf den VPN-Tunnel in network-b zugreifen. Die VM-Instanzen vm-a1 und vm-a2 können beispielsweise das lokale Netzwerk erreichen, obwohl sich vm-a2 in einer anderen Region als der VPN-Tunnel befindet.

Cloud Router muss deshalb auch ein benutzerdefiniertes Route Advertisement umfassen, über das die Bereiche 10.8.1.0/24 und 10.9.1.0/24 in der BGP-Sitzung an das lokale Netzwerk gemeldet werden.

In der folgenden Tabelle sind die resultierenden Routen für network-a und network-b zusammengefasst, wenn beide die benutzerdefinierten Routen sowohl importieren als auch exportieren:

Netz Ziel Nächster Hop Ursprung
network-a 0.0.0.0/0 Internetgateway lokal
10.8.1.0/24 network-a lokal
10.9.1.0/24 network-a lokal
10.30.0.0/16 vm-a1 lokal
10.8.2.0/24 Peering von a zu b Peering-Komponente
10.10.0.0/16
(globale dynamische Route)
Peering von a zu b Peering-Komponente
network-b 0.0.0.0/0 Internetgateway lokal
10.8.2.0/24 network-b lokal
10.10.0.0/16
(globale dynamische Route)
vpn-b lokal
10.8.1.0/24 Peering von b zu a Peering-Komponente
10.9.1.0/24 Peering von b zu a Peering-Komponente
10.30.0.0/16 Peering von b zu a Peering-Komponente

VPC-Netzwerk als Transitnetzwerk

Angenommen, Sie haben eine einzelne lokale Verbindung zwischen Ihrem VPC-Netzwerk und dem lokalen Netzwerk, z. B. einen VPN-Tunnel oder eine Interconnect-Verbindung. Sie möchten diese Verbindung für andere VPC-Netzwerke freigeben, sodass Sie keine lokale Verbindung für alle anderen VPC-Netzwerke neu erstellen müssen.

Sie können andere VPC-Netzwerke über Peering mit Ihrem VPC-Netzwerk (auch als Transitnetzwerk bezeichnet) verbinden, sodass die anderen Netzwerke die lokale Verbindung verwenden können. Alle Peering-Netzwerke können die lokale Verbindung nutzen, aber sie können keinen Traffic über das Transitnetzwerk zu einem anderen Peering-Netzwerk leiten.

Im folgenden Beispiel gibt es drei VPC-Netzwerke. network-b ist durch Peering mit network-a und network-c verbunden. Alle Netzwerke exportieren und importieren benutzerdefinierte Routen. network-b fungiert als Transitnetzwerk, in dem sich der VPN-Tunnel befindet.

  • Standardmäßig bewirbt der Cloud Router, der Routen für Tunnel verwaltet, die mit dem Cloud VPN-Gateway in network-b verbunden sind, automatisch die Subnetz-IP-Adressbereiche von Subnetzen in network-b.

  • Routen zu lokalen Zielen werden als benutzerdefinierte dynamische Routen in network-b installiert. Dies geschieht durch den Cloud Router, der Routen für Tunnel verwaltet, die mit dem Cloud VPN-Gateway in network-b verbunden sind.

  • Sie müssen die Subnetz-IP-Adressbereiche für Subnetze in network-a und network-c hinzufügen, indem Sie benutzerdefinierte Route Advertisements auf dem Cloud Router konfigurieren, der Routen für Tunnel verwaltet, die mit dem Cloud VPN-Gateway in network-b verbunden sind.

  • Die benutzerdefinierten dynamischen Routen (zu lokalen Zielen) werden über VPC-Netzwerk-Peering sowohl an network-a als auch an network-c ausgetauscht, da network-b für den Export von benutzerdefinierten Routen konfiguriert wurde. Die beiden anderen Netzwerke wurden für den Import konfiguriert.

  • Dieses Beispiel bietet die folgende Erreichbarkeit:

    • VM-Instanzen in network-a können andere VMs in network-b und Systeme im lokalen Netzwerk erreichen.
    • VM-Instanzen in network-b können andere VMs in network-a und network-c sowie Systeme im lokalen Netzwerk erreichen.
    • VM-Instanzen in network-c können andere VMs in network-b und Systeme im lokalen Netzwerk erreichen.
    • Da das VPC-Netzwerk-Peering nicht transitiv ist, können VM-Instanzen in network-a und network-c nicht miteinander kommunizieren, es sei denn, Sie stellen auch ein Peering-Netzwerk zwischen network-a und network-c her.

Interne Load-Balancer

VM-Instanzen in Peering-Netzwerken können auf die internen IP-Adressen interner TCP/UDP-Load-Balancer in Ihrem VPC-Netzwerk zugreifen, wenn die folgenden Bedingungen erfüllt sind:

  • Wenn der globale Zugriff auf einem internen TCP/UDP-Load-Balancer deaktiviert ist, müssen sich Clients in derselben Region wie der Load-Balancer befinden. Sie müssen sich außerdem im selben VPC-Netzwerk wie der Load-Balancer oder in einem VPC-Netzwerk befinden, das über VPC-Netzwerk-Peering mit dem VPC-Netzwerk des Load-Balancers verbunden ist.

  • Wenn der globale Zugriff auf einem internen TCP/UDP-Load-Balancer aktiviert ist, können Clients sich in einer beliebigen Region befinden. Sie müssen sich aber trotzdem im selben VPC-Netzwerk wie der Load-Balancer oder in einem VPC-Netzwerk befinden, das über VPC-Netzwerk-Peering mit dem VPC-Netzwerk des Load-Balancers verbunden ist.

  • Firewallregeln für eingehenden Traffic, die für die Back-End-VMs des Load-Balancers gelten, ermöglichen Traffic von Quellen in Peering-Netzwerken. Diese Firewallregeln für eingehenden Traffic müssen in dem VPC-Netzwerk erstellt werden, das den Load-Balancer enthält.

Weitere Informationen

Firewallregeln

Wenn Sie Netzwerke über VPC-Netzwerk-Peering verbinden, werden keine Firewallregeln zwischen ihnen ausgetauscht. Wenn Sie eingehenden Traffic von VM-Instanzen in einem Peering-Netzwerk zulassen möchten, müssen Sie Firewallregeln zum Zulassen von eingehendem Traffic erstellen. Eingehender Traffic zu VMs wird standardmäßig durch die implizierte Regel zum Ablehnen von eingehendem Traffic blockiert.

Wenn Sie den Zugriff auf VMs so einschränken müssen, dass nur andere VMs in Ihrem VPC-Netzwerk Zugriff haben, sollten in den Quellen für Ihre Firewallregeln zum Zulassen von eingehendem Traffic nur VMs in Ihrem VPC-Netzwerk und nicht solche aus Peering-Netzwerken angegeben werden. Sie können beispielsweise Quell-IP-Bereiche nur für die Subnetze in Ihrem VPC-Netzwerk angeben.

Zum Beschränken des Zugriffs auf einen internen TCP/UDP-Load-Balancer erstellen Sie Firewallregeln für eingehenden Traffic, die für die Back-End-VMs des Load-Balancers gelten.

Freigegebene VPC

VPC-Netzwerk-Peering erlaubt das Peering mit einer freigegebenen VPC. Über ein Hostprojekt einer freigegebenen VPC können andere Projekte eines seiner Netzwerke verwenden. Das folgende Diagramm veranschaulicht die Konfiguration.

Freigegebene VPC mit Netzwerk-Peering (zum Vergrößern klicken)
Freigegebene VPC mit Netzwerk-Peering (zum Vergrößern klicken)

network-SVPC befindet sich in Hostprojekt P1 eines freigegebenen VPC-Netzwerks. Die Dienstprojekte P3 und P4 können VM-Instanzen an Netzwerk-SVPC anhängen. network-SVPC ist über Peering mit network-A verbunden. Deshalb gilt:

  • VM-Instanzen in freigegebenen VPC-Dienstprojekten, die das Netzwerk-SVPC (VM3 und VM4) nutzen, haben private interne IP-Verbindungen mit allen Endpunkten, die Netzwerk-A zugeordnet sind.
  • Netzwerk-A zugeordnete VM-Instanzen haben private, interne IP-Verbindungen mit allen Endpunkten, die Netzwerk-SVPC zugeordnet sind, unabhängig davon, ob das Projekt, zu dem sie gehören, das Hostprojekt oder ein Dienstprojekt ist.

Sie können auch ein VPC-Netzwerk-Peering zwischen zwei freigegebenen VPC-Netzwerken einrichten.

Mehrere Netzwerkschnittstellen pro VM-Instanz

Eine VM-Instanz kann mehrere Netzwerkschnittstellen haben, eine pro VPC-Netzwerk. Für diese Instanzen werden in Google Cloud zielbasierte IP-Routen zugewiesen, wobei jede Schnittstelle eine Route aus dem Subnetz erhält, in dem sie sich befindet. Darüber hinaus bietet Google Cloud eine Standardroute für die primäre Netzwerkschnittstelle. Beim zielbasierten Routing wird jeglicher Traffic, der nicht an eines der Subnetze der Instanz gerichtet ist, von der primären Netzwerkschnittstelle aus weitergeleitet. Weitere Informationen finden Sie unter DHCP-Verhalten mit mehreren Netzwerkschnittstellen.

Wenn Sie Peering-Netzwerke haben, die VM-Instanzen mit mehreren Netzwerkschnittstellen enthalten, müssen Sie möglicherweise die Standardrichtlinie für zielbasiertes Routing zu einer Richtlinie für quellenbasiertes Routing ändern. Weitere Informationen finden Sie unter Richtlinienrouting konfigurieren.

Die folgenden Szenarien zeigen, wann eine VM-Instanz möglicherweise eine quellenbasierte Routingrichtlinie erfordert.

Routingrichtlinie erforderlich

Im folgenden Beispiel erfordert vm1 eine quellenbasierte Routingrichtlinie, damit vm1 und vm2 erfolgreich kommunizieren können. Ohne Routingrichtlinie wird der gesamte ausgehende Traffic durch vm1-nic0 an network-a geleitet, sofern der Traffic nicht an subnet-b gerichtet ist, wo sich nic1 befindet. Von vm1 an network-c gerichteter Traffic wird so verworfen oder an das falsche Ziel gesendet, da die VM-Instanz Traffic immer von der primären Schnittstelle sendet.

Routingrichtlinie abhängig von den Subnetz-IP-Bereichen erforderlich

Im folgenden Beispiel befindet sich die primäre Netzwerkschnittstelle von vm1 in einem Netzwerk, das über Peering mit einem anderen Netzwerk verbunden ist. Sie müssen die Routingrichtlinie nicht auf vm1 konfigurieren.

Im folgenden Beispiel befinden sich vm1-nic1 und vm2-nic0 in überlappenden Subnetzen. Wenn Peering eingerichtet ist, sucht Google Cloud nur zwischen Peering-Komponenten nach überlappenden IP-Bereichen und nicht zwischen anderen Netzwerken, in denen die Instanzen Netzwerkschnittstellen enthalten. Damit vm1 und vm2 kommunizieren können, müssen Sie für vm1-nic0 eine quellenbasierte Routingrichtlinie hinzufügen.

Peering zwischen Schnittstellen

Das folgende Beispiel zeigt eine VM-Instanz mit mehreren Netzwerkschnittstellen, wobei sich jede in einem Netzwerk befindet, das über Peering mit dem anderen verbunden ist. In diesem Fall ist für vm1 keine quellenbasierte Routingrichtlinie erforderlich. Der Traffic, der die VM-Instanz zu jedem der Subnetze verlässt, verwendet die entsprechende Netzwerkschnittstelle.

Wenn vm1 Traffic an die IP-Adresse von vm2-nic1 sendet, gelangt der Traffic zwar zu nic1, wird aber aus nic0 gesendet. Wenn vm3 Traffic an die IP-Adresse von vm2-nic0 sendet, gelangt der Traffic entsprechend zu nic0, wird aber aus nic1 gesendet.

Subnetz-Sekundärbereiche

Ein Subnetz hat einen einzelnen primären IP-Adressbereich und optional einen oder mehrere sekundäre IP-Adressbereiche. Für jeden Subnetz-IP-Adressbereich erstellt Google Cloud eine Subnetzroute. Wenn Sie VPC-Netzwerk-Peering verwenden, werden die Subnetzrouten, die keine privat wiederverwendeten öffentlichen IP-Adressen zwischen den beiden Peering-Netzwerken nutzen, in Google Cloud immer ausgetauscht. Wenn Firewallregeln in jedem der Netzwerke die Kommunikation zulassen, können VM-Instanzen in einem Netzwerk mit Instanzen im Peering-Netzwerk kommunizieren.

Beim Einrichten einer Peering-Beziehung prüft Google Cloud, ob sich der primäre und der sekundäre Bereich eines Subnetzes mit anderen Bereichen in Peering-Netzwerken überschneidet.

Weitere Informationen