VPC-Netzwerk-Peering

Das Google Cloud VPC-Netzwerk-Peering verbindet zwei VPC-Netzwerke (Virtual Private Cloud), sodass die Ressourcen in jedem Netzwerk miteinander kommunizieren können. Peering-VPC-Netzwerke können sich im selben Projekt, in verschiedenen Projekten derselben Organisation oder in verschiedenen Projekten unterschiedlicher Organisationen befinden.

Spezifikationen

Mit VPC-Netzwerk-Peering haben Sie folgende Möglichkeiten:

Verbindung

  • VPC-Netzwerk-Peering unterstützt das Verbinden von VPC-Netzwerken und nicht Legacy-Netzwerken.
  • VPC-Netzwerk-Peering bietet interne IPv4- und IPv6-Verbindungen zwischen VPC-Netzwerkpaaren. Peering-Traffic (Traffic, der zwischen Peering-Netzwerken fließt) weist die gleiche Latenz, den gleichen Durchsatz und die gleiche Verfügbarkeit wie der Traffic innerhalb eines VPC-Netzwerks auf.
    • VPC-Netzwerk-Peering bietet kein transitives Routing. Wenn beispielsweise die VPC-Netzwerke net-a und net-b über VPC-Netzwerk-Peering verbunden sind und die VPC-Netzwerke net-a und net-c ebenfalls über VPC-Netzwerk-Peering verbunden sind stellt VPC-Netzwerk-Peering keine Verbindung zwischen net-b und net-c her.
    • Mit VPC-Netzwerk-Peering lassen sich nicht zwei VPC-Netzwerke im automatischen Modus verbinden Dies liegt daran, dass Peering-VPC-Netzwerke immer Subnetzrouten austauschen, die private interne IPv4-Adressen verwenden. Jedes Subnetz in einem VPC-Netzwerk im automatischen Modus verwendet einen Subnetz-IP-Adressbereich, der in den CIDR-Block 10.128.0.0/9 passt.
    • Sie können ein VPC-Netzwerk im benutzerdefinierten Modus mit einem VPC-Netzwerk im automatischen Modus verbinden, sofern das VPC-Netzwerk im benutzerdefinierten Modus keine Subnetz-IP-Adressbereiche hat, die innerhalb von 10.128.0.0/9.
  • VPC-Netzwerk-Peering bietet auch bestimmte externe IPv6-Verbindungen zu den externen Ziel-IPv6-Adressbereichen der folgenden Ressourcen, wenn die Routen zu diesen externen IPv6-Zieladressen durch das VPC-Netzwerk-Peering ausgetauscht werden:
    • Netzwerkschnittstellen der Dual-Stack-VM-Instanz
    • Weiterleitungsregeln für die externe Protokollweiterleitung
    • Weiterleitungsregeln für externe Passthrough-Network Load Balancer
  • VPC-Netzwerk-Peering unterstützt sowohl IPv4- als auch IPv6-Verbindungen. Sie können VPC-Netzwerk-Peering in einem VPC-Netzwerk konfigurieren, das Dual-Stack-Subnetze enthält.

Verwaltung

  • Peering-VPC-Netzwerke bleiben administrativ getrennt. Nur Routen werden gemäß der Peering-Konfiguration ausgetauscht.
  • Zum Herstellen einer Peering-Konnektivität muss ein Netzwerkadministrator für jedes VPC-Netzwerk eine Peering-Verbindung zum anderen VPC-Netzwerk erstellen. Ein Netzwerkadministrator für ein VPC-Netzwerk kann eine Peering-Verbindung trennen.
  • 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.
  • Durch das Erstellen einer Peering-Verbindung werden Ihnen keine IAM-Rollen (Identity and Access Management) im anderen VPC-Netzwerk zugewiesen. Wenn Sie beispielsweise die Rolle „Compute-Netzwerkadministrator“ oder die Rolle „Compute-Sicherheitsadministrator“ für ein Netzwerk haben, werden Sie kein Netzwerkadministrator oder Sicherheitsadministrator für das andere Netzwerk.

IAM-Berechtigungen

  • IAM-Berechtigungen zum Erstellen und Löschen von VPC-Netzwerk-Peering sind Bestandteil der Rolle Compute-Netzwerkadministrator (roles/compute.networkAdmin).
  • Sie können eine benutzerdefinierte Rolle verwenden, wenn sie die folgenden Berechtigungen enthält:
    • compute.networks.addPeering
    • compute.networks.updatePeering
    • compute.networks.removePeering
    • compute.networks.listPeeringRoutes

Netzwerksicherheit

VPC-Netzwerk-Peering tauscht keine VPC-Firewallregeln oderFirewallrichtlinien aus.

Für VPC-Firewallregeln:

  • Firewallregeln, deren Ziele mithilfe von Netzwerktags definiert sind, werden nur in Instanzen im VPC-Netzwerk der Firewallregel aufgelöst. Auch wenn ein Sicherheitsadministrator eines Peering-VPC-Netzwerks dasselbe Netzwerk-Tag verwenden kann, um Ziele von Firewallregeln in einem Peering-VPC-Netzwerk zu definieren, sind die Ziele der Firewallregeln in der Peering-VPC Netzwerk sind keine Instanzen in Ihrem VPC-Netzwerk enthalten. Entsprechend werden Firewallregeln für eingehenden Traffic, deren Quellen mit Netzwerktags definiert sind, nur in Instanzen im VPC-Netzwerk der Firewallregel aufgelöst.

  • Firewallregeln, deren Ziele mithilfe von Dienstkonten definiert sind, werden nur in Instanzen im VPC-Netzwerk der Firewallregel aufgelöst. Je nach IAM-Berechtigungen kann ein Sicherheitsadministrator eines Peering-VPC-Netzwerks möglicherweise dasselbe Dienstkonto verwenden, um Ziele von Firewallregeln in einem Peering-VPC-Netzwerk zu definieren, aber die Ziele der Firewallregeln im Peering-VPC-Netzwerk umfassen keine Instanzen in Ihrem VPC-Netzwerk. Ebenso werden Firewallregeln für eingehenden Traffic, deren Quellen mit Dienstkonten definiert sind, nur in Instanzen im VPC-Netzwerk der Firewallregel aufgelöst.

Regeln in Netzwerk-Firewallrichtlinien können sichere Tags verwenden, die sich von Netzwerktags unterscheiden, um Ziele und Quellen zu identifizieren:

  • Bei der Angabe eines Ziels für eine Regel für eingehenden oder ausgehenden Traffic in einer Netzwerk-Firewallrichtlinie kann ein Tag nur Ziele im VPC-Netzwerk identifizieren, auf das das Tag beschränkt ist.

  • Wenn es verwendet wird, um eine Quelle für eine Regel für eingehenden Traffic in einer Netzwerk-Firewallrichtlinie anzugeben, kann ein Tag Quellen im VPC-Netzwerk, auf das das Tag beschränkt ist, und in allen mit dem VPC-Netzwerk verbundenen Peer-VPC-Netzwerken, auf die das Tag beschränkt ist, identifizieren. Weitere Informationen finden Sie unter Tags für Firewalls.

Jedes VPC-Netzwerk enthält implizierte Firewallregeln. Aufgrund der implizierte Firewallregeln zum Ablehnen von eingehendem Traffic müssen Sicherheitsadministratoren für jedes VPC-Netzwerk Firewallregeln zum Zulassen von eingehendem Traffic oder in Firewallrichtlinien erstellen. Quellen für diese Regeln können IP-Adressbereiche eines Peering-VPC-Netzwerks enthalten.

Aufgrund der implizierten Firewallregeln zum Zulassen von ausgehendem Traffic müssen Sie keine Firewallregeln oder Firewallregeln zum Zulassen von ausgehendem Traffic in Firewallrichtlinien erstellen, um Pakete an Ziele im Peering-VPC Netzwerks zuzulassen, es sei denn, Ihre Netzwerke enthalten Regeln zum Ablehnen von ausgehendem Traffic.

DNS-Unterstützung

Ressourcen in einem Peering-VPC-Netzwerk können keine internen Compute Engine-DNS-Namen verwenden, die von einem lokalen VPC-Netzwerk erstellt wurden.

Ein Peering-VPC-Netzwerk kann keine von Cloud DNS verwalteten privaten Zonen verwenden, die nur für ein lokales VPC-Netzwerk autorisiert sind. Verwenden Sie eine der folgenden Methoden, um die DNS-Namen für Ressourcen in einem Peering-VPC-Netzwerk verfügbar zu machen:

Support für internen Load-Balancer

Clients in einem lokalen VPC-Netzwerk können auf interne Load Balancer in einem Peering-VPC-Netzwerk zugreifen. Weitere Informationen finden Sie in der Dokumentation zum Load-Balancer in den Abschnitten VPC-Netzwerk-Peering verwenden:

Peering-Netzwerke können statische Routen austauschen, die interne Passthrough-Netzwerk-Load-Balancer als nächste Hops verwenden. Weitere Informationen finden Sie unter Optionen für den Routenaustausch.

Peering-Gruppe und Kontingente

Die VPC-Peering-Kontingente hängen von einem Konzept ab, das als Peering-Gruppe bezeichnet wird. Jedes VPC-Netzwerk hat eine eigene Peering-Gruppe, die aus sich selbst und allen anderen VPC-Netzwerken besteht, die über VPC-Netzwerk-Peering verbunden sind. Im einfachsten Szenario gibt es zwei Peering-Gruppen, wenn zwei VPC-Netzwerke, net-a und net-b, verbunden sind, eine aus der Perspektive von net-a und die andere aus der Perspektive von net-b.

Weitere Informationen zu Kontingenten für VPC-Netzwerk-Peering finden Sie unter:

Beschränkungen

Für VPC-Netzwerk-Peering gelten die folgenden Limits.

Subnetz-IP-Bereiche dürfen sich nicht über Peering-VPC-Netzwerke überschneiden

Kein IP-Bereich eines Subnetzes darf sich mit einem Subnetz-IP-Bereich eines Peering-VPC-Netzwerks überschneiden. Beim Peering prüft Google Cloud, ob Subnetze mit sich überschneidenden IP-Bereichen vorhanden sind. Wenn ja, schlägt das Peering fehl. Wenn Sie bei einem Peering-Netzwerk ein VPC-Subnetz erstellen oder einen Subnetz-IP-Bereich erweitern, prüft Google Cloud, ob neue Subnetzbereiche sich mit den vorhandenen Bereichen überschneiden.

Vor dem Erstellen neuer Subnetze können Sie die Routen von Peering-Verbindungen auflisten.

Weitere Informationen zu Überschneidungsprüfungen finden Sie hier:

Interne DNS-Namen werden in Peering-Netzwerken nicht aufgelöst

Interne DNS-Namen von Compute Engine, die in einem Netzwerk erstellt wurden, sind für Peering-Netzwerke nicht erreichbar. Verwenden Sie die IP-Adresse der VM, um die VM-Instanzen im Peering-Netzwerk zu erreichen.

Keine Verwendung von Tags und Dienstkonten über Peering-Netzwerke

Sie können in einer Firewallregel eines Peering-Netzwerks nicht auf Tags oder Dienstkonten einer VM verweisen, die sich in einem anderen Peering-Netzwerk befindet. Beispiel: Eine Regel für eingehenden Traffic in einem Peering-Netzwerk filtert die eigene Quelle basierend auf einem Tag und gilt nur für VM-Traffic innerhalb dieses Netzwerks, nicht für die Peers, auch wenn eine VM in einem Peering-Netzwerk dieses Tag enthält. Diese Situation verläuft ähnlich wie Dienstkonten.

GKE mit VPC-Netzwerk-Peering

VPC-Netzwerk-Peering mit GKE wird unterstützt, wenn es mit IP-Aliassen und benutzerdefinierten Routen verwendet wird. Kubernetes-Dienste sind über VPC-Netzwerke erreichbar, wenn sie über einen internen Passthrough Network Load Balancer bereitgestellt werden. Pod-IP-Adressen sind ebenfalls erreichbar.

Cloud Load Balancing mit VPC-Netzwerk-Peering

Cloud Load Balancing unterstützt nicht die Verwendung der Front-Ends und Back-Ends des Load-Balancers in verschiedenen VPC-Netzwerken, selbst wenn sie über VPC-Netzwerk-Peering verbunden sind.

Interne Passthrough Network Load Balancer und interne Application Load Balancer unterstützen VPC-Netzwerk-Peering nur für den Clientzugriff vom Peering-VPC-Netzwerk.

Optionen für den Routenaustausch

Wenn ein VPC-Netzwerk lokale Routen mit einem Peering-VPC-Netzwerk teilt, werden die Routen exportiert. Das Peering-VPC-Netzwerk kann dann die Routen import. Subnetzrouten, mit Ausnahme von IPv4-Subnetzrouten, die privat verwendete öffentliche IPv4-Adressen verwenden, werden immer ausgetauscht.

Mit der Konfiguration von VPC-Netzwerk-Peering können Sie Folgendes steuern:

  • Wenn IPv6-Routen ausgetauscht werden
  • Wenn Routen für Subnetze, die privat verwendete öffentliche IPv4-Adressen verwenden, exportiert oder importiert werden
  • Ob benutzerdefinierte statische und dynamische Routen exportiert oder importiert werden

Sie können die Konfiguration aktualisieren, bevor das Peering eingerichtet wurde oder während die Peering-Verbindung aktiv ist.

Das VPC-Netzwerk-Peering bietet nicht Folgendes:

  • Detaillierte Methode zur Steuerung des Austauschs von bestimmten Subnetzrouten, statischen Routen und dynamischen Routen.
  • Unterstützung für den Austausch von richtlinienbasierten Routen.

Optionen für den Austausch von Subnetzrouten

In der folgenden Tabelle werden die Routenaustauschoptionen für Subnetzrouten beschrieben.

Routentyp Routenexportbedingungen Routenimportbedingungen
IPv4-Subnetzrouten (primäre und sekundäre IPv4-Subnetzbereiche) mit privaten IPv4-Adressbereichen Immer exportiert

Kann nicht deaktiviert werden		 Immer importiert

Kann nicht deaktiviert werden
IPv4-Subnetzrouten (primäre und sekundäre IPv4-Subnetzbereiche) mit privat verwendeten öffentlichen IPv4-Adressbereichen Standardmäßig exportiert

Der Export wird mit dem Flag --export-subnet-routes-with-public-ip gesteuert. 		Standardmäßig nicht importiert

Der Import wird mit dem Flag --import-subnet-routes-with-public-ip gesteuert.
Interne IPv6-Subnetzbereiche
(ipv6-access-type=INTERNAL) 		Standardmäßig nicht exportiert

Der Export wird durch Festlegen von --stack-type=IPV4_IPV6 aktiviert. 		Standardmäßig nicht importiert

Der Import ist durch Festlegen von --stack-type=IPV4_IPV6 aktiviert.
Externe IPv6-Subnetzbereiche
(ipv6-access-type=EXTERNAL) 		Standardmäßig nicht exportiert

Der Export wird durch Festlegen von --stack-type=IPV4_IPV6 aktiviert 		Nicht standardmäßig importiert

Der Import wird durch die Einstellung --stack-type=IPV4_IPV6 aktiviert

Optionen für den Austausch statischer Routen

In der folgenden Tabelle werden die Routenaustauschoptionen für statische Routen beschrieben.

Routentyp Routenexportbedingungen Routenimportbedingungen
Statische Routen mit Netzwerk-Tags (alle nächsten Hop-Typen) Kann nicht exportiert werden Kann nicht importiert werden
Statische Routen, die den nächsten Hop des Standard-Internetgateways verwenden Kann nicht exportiert werden Kann nicht importiert werden
Statische IPv4-Routen ohne Netzwerk-Tags, die einen nächsten Hop als das Standard-Internetgateway verwenden Standardmäßig nicht exportiert

Der Export wird mit dem Flag --export-custom-routes gesteuert. 		Standardmäßig nicht importiert

Der Import wird mit dem Flag --import-custom-routes gesteuert.
Statische IPv6-Routen ohne Netzwerk-Tags, die eine VM-Instanz als nächsten Hop verwenden Standardmäßig nicht exportiert

Der Export wird über das Flag --export-custom-routes gesteuert, wenn der Stacktyp des Peerings auf --stack-type=IPV4_IPV6 gesetzt ist. 		Standardmäßig nicht importiert

Der Import wird mit dem Flag --import-custom-routes gesteuert, wenn der Stacktyp des Peerings auf --stack-type=IPV4_IPV6 gesetzt ist.

Optionen für den Austausch dynamischer Routen

In der folgenden Tabelle werden die Routenaustauschoptionen für Subnetzrouten beschrieben.

Routentyp Routenexportbedingungen Routenimportbedingungen
Dynamische IPv4-Routen Standardmäßig nicht exportiert

Der Export wird mit dem Flag --export-custom-routes gesteuert. 		Standardmäßig nicht importiert

Der Import wird mit dem Flag --import-custom-routes gesteuert.
Dynamische IPv6-Routen Standardmäßig nicht exportiert

Der Export wird über das Flag --export-custom-routes gesteuert, wenn der Stacktyp des Peerings auf --stack-type=IPV4_IPV6 gesetzt ist. 		Standardmäßig nicht importiert

Der Import wird mit dem Flag --import-custom-routes gesteuert, wenn der Stacktyp des Peerings auf --stack-type=IPV4_IPV6 gesetzt ist.

Vorteile des Austauschs statischer und dynamischer Routen

Wenn ein VPC-Netzwerk statische und dynamische Routen exportiert und das andere VPC-Netzwerk diese Routen importiert, kann das Importnetzwerk für jede importierte statische oder dynamische Route, deren nächster Hop im Peer-VPC-Netzwerk liegt, Pakete direkt an den nächsten Hop senden.

Ein Netzwerkadministrator eines lokalen VPC-Netzwerks steuert den Export der statischen und dynamischen Routen dieses Netzwerks mithilfe des Flags --export-custom-routes. Ein Netzwerkadministrator des entsprechenden Peering-VPC-Netzwerks steuert den Import dieser statischen und dynamischen Routen mit dem Flag --import-custom-routes. Weitere Informationen finden Sie unter Ignorierte Routen, Interaktionen mit Subnetz- und Peering-Subnetzrouten und Interaktionen mit Subnetzen und statischen Routen eine

Das Importieren statischer und dynamischer Routen aus einem Peering-VPC-Netzwerk kann in den folgenden Szenarien nützlich sein:

  • Wenn das Peering-VPC-Netzwerk routenbasierte GKE-Cluster enthält und Sie Pakete an die Pods in diesen Clustern senden müssen: Pod-IP-Adressen werden als Zielbereiche für benutzerdefinierte statische Routen implementiert, die sich im Peering-VPC-Netzwerk befinden.
  • Wenn Sie eine Verbindung zwischen einem lokalen Netzwerk und einem Peering-VPC-Netzwerk bereitstellen müssen. Angenommen, ein lokales VPC-Netzwerk enthält dynamische Routen mit einem Cloud VPN-Tunnel als nächsten Hop, einem Cloud Interconnect-Anhang (VLAN) oder einer Router-Appliance, die eine Verbindung zu einem lokalen Netzwerk herstellt. Um einen Pfad vom Peering-VPC-Netzwerk zum lokalen Netzwerk bereitzustellen, aktiviert ein Netzwerkadministrator für das lokale VPC-Netzwerk den benutzerdefinierten Routenexport und einen Netzwerkadministrator für das Peering-VPC-Netzwerk aktiviert den Import benutzerdefinierter Routen. Um einen Pfad vom lokalen Netzwerk zum Peering-VPC-Netzwerk bereitzustellen, muss ein Netzwerkadministrator für das lokale VPC-Netzwerk benutzerdefiniertes Route Advertisement von Cloud Router auf dem Cloud Router verwenden, der die BGP-Sitzung für den Cloud VPN-Tunnel, den Cloud Interconnect-Anhang (VLAN) oder die Router-Appliance verwaltet, die eine Verbindung zum lokalen Netzwerk herstellt. Der Inhalt dieser benutzerdefinierten Route Advertisements muss die Subnetz-IP-Adressbereiche des Peering-VPC-Netzwerks enthalten.

Ignorierte Routen

Selbst wenn ein VPC-Netzwerk eine Route importiert, kann es die importierte Route in Situationen wie den folgenden ignorieren:

  • Wenn das lokale VPC-Netzwerk eine Route mit einem identischen oder spezifischeren Ziel (längere Subnetzmaske) hat, verwendet das lokale VPC-Netzwerk immer seine lokale Route.

  • Wenn das lokale VPC-Netzwerk nicht die spezifischste Route für das Ziel eines Pakets enthält, aber zwei oder mehr Peering-VPC-Netzwerke dasselbe, spezifischste Ziel für das Paket enthalten, verwendet Google Cloud einen internen Algorithmus, um einen nächsten Hop aus nur einem der Peering-VPC-Netzwerke auszuwählen. Diese Auswahl erfolgt, bevor die Routenpriorität berücksichtigt wird. Sie können dieses Verhalten nicht konfigurieren. Als Best Practice sollten Sie diese Konfiguration vermeiden, da das Hinzufügen oder Entfernen von Peering-VPC-Netzwerken zu unbeabsichtigten Änderungen an der Routingreihenfolge führen kann.

Weitere Informationen zu den vorherigen Situationen finden Sie unter Routingreihenfolge.

Wenn bei Dual-Stack-Peerings ein lokales VPC-Netzwerk, das IPv6-Routen importiert, keine Dual-Stack-Subnetze hat, kann keine der IPv6-Routen verwendet werden, die es von Peering-VPC-Netzwerken empfängt. Wenn außerdem die Einschränkung der Organisationsrichtlinie constraints/compute.disableAllIpv6 festgelegt wurde, kann ein Netzwerkadministrator möglicherweise keine Dual-Stack-Subnetze erstellen.

Interaktionen von Subnetz- und Peering-Subnetzrouten

IPv4-Subnetzrouten in Peering-VPC-Netzwerken dürfen sich nicht überschneiden:

  • Mit Peering sind identische IPv4-Subnetzrouten nicht zulässig. Beispielsweise können zwei Peering-VPC-Netzwerke nicht beide eine IPv4-Subnetzroute mit dem Ziel 100.64.0.0/10 haben.
  • Mit Peering wird verhindert, dass eine Subnetzroute in einer Peering-Subnetzroute enthalten wird. Wenn das lokale VPC-Netzwerk beispielsweise eine Subnetzroute mit dem Ziel 100.64.0.0/24 hat, kann keines der Peering-VPC-Netzwerke eine Subnetzroute mit dem Ziel 100.64.0.0/10 haben.

Google Cloud erzwingt die vorherigen Bedingungen für IPv4-Subnetzrouten in den folgenden Fällen:

  • Wenn Sie VPC-Netzwerke zum ersten Mal über VPC-Netzwerk-Peering verbinden.
  • Die Netzwerke sind über Peering verbunden.
  • Wenn Sie eine Peering-Konfigurationsänderung vornehmen, z. B. das Importieren von IPv4-Routen von Subnetzen mit privat verwendeten öffentlichen IP-Adressen aktivieren.

Beim Peering von Netzwerken gibt Google Cloud einen Fehler zurück, wenn einer der folgenden Vorgänge zu einer Überschneidung führt:

IPv6-Subnetzrouten (sowohl interne als auch extern) sind Definitionsgemäß eindeutig. Zwei VPC-Netzwerke können nicht dieselben internen oder externen IPv6-Subnetzbereiche verwenden. Wenn beispielsweise ein VPC-Netzwerk fc:1000:1000:1000::/64 als IPv6-Subnetzbereich verwendet, kann kein anderes VPC-Netzwerk in Google Cloud fc:1000:1000:1000::/64 verwenden, unabhängig davon, ob die VPC-Netzwerke über VPC-Netzwerk-Peering verbunden sind.

Interaktionen mit Subnetzen und statischen Routen

Für Google Cloud müssen Subnetzrouten und Peering-Subnetzrouten die spezifischsten Ziel-IPv4- oder -IPv6-Bereiche haben. In jedem VPC-Netzwerk kann eine lokale statische Route kein Ziel haben, das genau mit einer lokalen Subnetzroute übereinstimmt oder in diese passt. Weitere Informationen zu diesem Szenario finden Sie unter Interaktionen mit statischen Routen.

Dieses Konzept wird auf VPC-Netzwerk-Peering durch die folgenden beiden Regeln erweitert:

  • Eine lokale statische Route kann kein Ziel haben, das genau mit einer Peering-Subnetzroute übereinstimmt oder in diese passt. Wenn eine lokale statische Route vorhanden ist, erzwingt Google Cloud Folgendes:

    • Sie können keine neue Peering-Verbindung zu einem VPC-Netzwerk herstellen, das bereits eine Subnetzroute enthält, die genau mit dem Ziel der lokalen statischen Route übereinstimmt oder diese enthält, wenn die Peering-Konfiguration zum Import der in Konflikt stehenden Subnetzroute führt. Beispiel:

      • Wenn eine lokale statische Route mit dem Ziel 10.0.0.0/24 vorhanden ist, können Sie keine neue Peering-Verbindung zu einem VPC-Netzwerk herstellen, das eine IPv4-Subnetzroute enthält, deren Ziel genau mit 10.0.0.0/24 übereinstimmt oder 10.0.0.0/24 enthält (z. B. 10.0.0.0/8).

      • Wenn der vorgesehene Peering-Stack-Typ IPV4_IPV6 ist gilt: Wenn eine lokale statische Route mit 2001:0db8:0a0b:0c0d::/96-Ziel vorhanden ist, können Sie keine neue Peering-Verbindung zu einem VPC-Netzwerk herstellen, das eine IPv6-Subnetzroute enthält, deren Ziel genau übereinstimmt oder 2001:0db8:0a0b:0c0d::/96 enthält. In diesem Fall ist 2001:0db8:0a0b:0c0d::/64 der einzig mögliche Subnetz-IPv6-Adressbereich, da Subnetz-IPv6-Adressbereiche in Google Cloud 64-Bit-Subnetzmasken verwenden müssen.

    • Sie können eine vorhandene Peering-Verbindung nicht aktualisieren, wenn die aktualisierte Peering-Konfiguration dazu führt, dass die in Konflikt stehende Subnetzroute importiert wird. Beispiel:

      • Angenommen, für zwei VPC-Netzwerke ist bereits ein Peering durchgeführt, aber sie exportieren und importieren derzeit keine IPv4-Subnetzrouten über privat verwendete öffentliche IPv4-Adressbereiche. Im ersten VPC-Netzwerk ist eine lokale statische Route mit dem Ziel 11.0.0.0/24 vorhanden. Im Peering-VPC-Netzwerk ist eine Subnetzroute mit dem Ziel 11.0.0.0/8 vorhanden. Sie können nicht das Peering-VPC-Netzwerk so konfigurieren, dass es Subnetzrouten mithilfe privat verwendeter öffentlicher IPv4-Adressen exportiert und gleichzeitig das erste VPC-Netzwerk so konfigurieren, dass es Subnetzrouten mithilfe privat verwendeter öffentlicher IPv4-Adressen importiert.

      • Angenommen, zwei VPC-Netzwerke sind bereits per Peering verbunden und der Peering-Stack-Typ ist nur IPv4. Eine lokale statische Route mit dem Ziel 2001:0db8:0a0b:0c0d::/96 ist im ersten VPC-Netzwerk und eine IPv6-Subnetzroute mit dem Ziel 2001:0db8:0a0b:0c0d::/64 ist im Peering-VPC-Netzwerk vorhanden. Sie können den Peering-Stack-Typ nicht in IPV4_IPV6 ändern.

    • Umgekehrt können Sie die folgenden Vorgänge nicht ausführen, wenn VPC-Netzwerke bereits über VPC-Netzwerk-Peering verbunden sind:

      • Erstellen Sie eine neue lokale statische Route, deren Ziel genau mit einer importierten Peering-Subnetzroute übereinstimmt oder darin enthalten ist.

      • Erstellen Sie einen neuen Subnetzadressbereich im Peering-VPC-Netzwerk, wenn dieser Bereich genau mit einer vorhandenen lokalen statischen Route übereinstimmt oder diese enthält.

  • Eine statische Peering-Route kann kein Ziel haben, das genau mit einer lokalen Subnetzroute übereinstimmt oder in diese passt. Wenn eine lokale Subnetzroute vorhanden ist, verhindert Google Cloud Folgendes:

    • Sie können keine neue Peering-Verbindung zu einem VPC-Netzwerk herstellen, das bereits eine statische Route enthält, die genau mit dem Ziel der Subnetzroute des lokalen VPC-Netzwerks übereinstimmt oder diese enthält, wenn die Peering-Konfiguration zum Import der statischen Route aus dem Peer führt. Beispiele:

      • Wenn eine lokale Subnetzroute für 10.0.0.0/8 vorhanden ist, können Sie keine Peering-Verbindung zu einem VPC-Netzwerk mit einer statischen Route herstellen, deren Ziel genau mit 10.0.0.0/8 übereinstimmt oder in 10.0.0.0/8 passt. Beispiel: 10.0.0.0/24

      • Wenn der vorgesehene Peering-Stack-Typ IPV4_IPV6 ist, gilt: wenn eine lokale Subnetzroute für 2001:0db8:0a0b:0c0d::/64 vorhanden ist, können Sie keine Peering-Verbindung zu einem VPC-Netzwerk mit einer statischen Route herstellen, deren Ziel genau übereinstimmt mit 2001:0db8:0a0b:0c0d::/64 oder passt in 2001:0db8:0a0b:0c0d::/64. Beispiel: 2001:0db8:0a0b:0c0d::/96.

    • Sie können eine vorhandene Peering-Verbindung nicht aktualisieren, wenn die aktualisierte Peering-Konfiguration zum Import der in Konflikt stehenden statischen Route führt.

    • Umgekehrt können Sie die folgenden Vorgänge nicht ausführen, wenn VPC-Netzwerke bereits über VPC-Netzwerk-Peering verbunden sind:

      • Erstellen Sie eine neue lokale Subnetzroute, deren Ziel genau mit einer importierten statischen Peering-Route übereinstimmt oder diese enthält.
      • Erstellen Sie im Peering-VPC-Netzwerk eine neue statische Route, deren Ziel genau mit einer vorhandenen lokalen Subnetzroute übereinstimmen oder dorthin passen würde.

Auswirkungen des dynamischen Routingmodus

Der dynamische Routingmodus eines VPC-Netzwerks bestimmt die Regionen, in denen Präfixe, die von Cloud Routern in diesem Netzwerk erkannt werden, als lokale dynamische Routen angewendet werden. Weitere Informationen zu diesem Verhalten finden Sie unter Auswirkungen des dynamischen Routingmodus.

Dieses Konzept wird auf VPC-Netzwerk-Peering erweitert. Der dynamische Routingmodus des Exporting-VPC-Netzwerks, also das Netzwerk mit den Cloud Routern, die die Präfixe für diese dynamischen Routen erkannt haben, bestimmt die Regionen, in denen die dynamischen Peering-Routen in Peer-Netzwerken programmiert werden können:

  • Wenn der dynamische Routingmodus des Export-VPC-Netzwerks regional ist, exportiert dieses Netzwerk dynamische Routen nur in derselben Region wie die Cloud Router, die die Präfixe erkannt haben.

  • Wenn der dynamische Routingmodus des Export-VPC-Netzwerks global ist, exportiert dieses Netzwerk dynamische Routen in alle Regionen.

In beiden Fällen ist der dynamische Routingmodus des importierenden VPC-Netzwerks nicht relevant.

Ein Beispiel, das dieses Verhalten veranschaulicht, finden Sie unter Lokales VPC-Netzwerk und Peering-VPC-Netzwerk mit lokaler Konnektivität.

Interaktionen mit Subnetz und dynamischen Routen

Konflikte zwischen lokalen oder Peering-Subnetzrouten und dynamischen Routen werden behoben, wie unter Interaktionen mit dynamischen Routen beschrieben.

Beispiele für VPC-Netzwerk-Peering

In den folgenden Beispielen werden zwei gängige Szenarien für VPC-Netzwerk-Peering gezeigt.

Lokales VPC-Netzwerk und Peer-VPC-Netzwerk mit lokaler Verbindung

In diesem Beispiel wird das folgende Netzwerk-Peering eingerichtet:

  • network-a ist mit network-b verbunden und network-b mit network-a.
  • network-a enthält zwei Subnetze, in denen sich jedes Subnetz in einer separaten Region befindet. network-b enthält ein einzelnes Subnetz.
  • network-b ist über dynamisches VPN mit dynamischem Routing mit einem lokalen Netzwerk verbunden. (Dieselben Prinzipien gelten auch, wenn die Tunnel durch Cloud Interconnect-VLAN-Anhänge ersetzt werden.)
  • Die Peering-Verbindung für network-b wird mit dem Flag --export-custom-routes und die Peering-Verbindung für network-a mit dem Flag --import-custom-routes konfiguriert.

Für eine Verbindung von lokalen Umgebungen zu Subnetzen in network-a und network-b, muss der Cloud Router in network-b für die Verwendung von Benutzerdefiniertem Route Advertisement konfiguriert sein. Der Cloud Router bewirbt beispielsweise nur das benutzerdefinierte Präfix custom-prefix-1, das den Subnetzbereich aus network-b und die Subnetzbereiche aus network-a enthält.

Der Cloud Router in us-west1 lernt on-premises-prefix von einem lokalen Router. on-premises-prefix verursacht keinen Konflikt, da es breiter als die Subnetz- und Peering-Subnetzrouten ist. Mit anderen Worten: on-premises-prefix stimmt nicht genau überein und passt nicht in eine Subnetz- oder Peering-Subnetzroute.

In der folgenden Tabelle wird die im vorherigen Beispiel angegebene Netzwerkkonfiguration zusammengefasst:

Netzwerkname Netzwerkkomponente IPv4-Bereich IPv6-Bereich Region

network-a

subnet-a

10.0.0.0/24

fc:1000:1000:1000::/64

us-west1

network-a

subnet-b

10.0.1.0/24

fc:1000:1000:1001::/64

europe-north 1

network-b

subnet-c

10.0.2.0/23

fc:1000:1000:1002::/64

us-west1

network-b

Cloud Router

10.0.0.0/22

fc:1000:1000:1000::/64

us-west1

Lokales Netzwerk

Lokaler Router

10.0.0.0/8

fc:1000:1000:1000::/56

–

Unabhängig vom Modus für dynamisches Routing von network-a gelten die folgenden Routingeigenschaften:

  • Wenn der dynamische Routingmodus von network-b global ist, werden On-premises prefix, die vom Cloud Router in network-b erlernt wurden, als dynamische Routen in allen Regionen von network-b und als dynamische Peering-Routen in allen Regionen von network-a hinzugefügt. Wenn Firewallregeln korrekt konfiguriert sind, kann vm-a1 ,vm-a2 und vm-b mit einer lokalen Ressource über die IPv4-Adresse 10.5.6.7 (oder IPv6-Adresse fc:1000:1000:10a0:29b::) kommunizieren.

  • Wenn der dynamische Routingmodus von network-b in regional geändert wird, werden On-premises prefix, die vom Cloud Router in network-b erlernt wurden, nur als dynamische Routen in der us-west1-Region von network-b und als dynamische Peering-Routen in der Region us-west1 von network-a hinzugefügt. Wenn die Firewallregeln richtig konfiguriert sind, können nur vm-a1 und vm-b mit einer lokalen Ressource mit der IPv4-Adresse 10.5.6.7 (oder der IPv6-Adresse fc:1000:1000:10a0:29b::) kommunizieren, denn dies ist die einzige VM in derselben Region wie der Cloud Router.

Transitnetzwerk

Im folgenden Beispiel fungiert network-b als Transitnetzwerk.

  • network-a ist mit network-b verbunden und network-b mit network-a.
  • network-c ist mit network-b verbunden und network-b mit network-c.
  • network-b ist über dynamisches VPN mit dynamischem Routing mit einem lokalen Netzwerk verbunden. Dieselben Prinzipien gelten auch, wenn die Tunnel durch Cloud Interconnect-VLAN-Anhänge ersetzt wurden.
    • Für eine Verbindung von lokalen Umgebungen zu Subnetzen in network-a, network-b und network-c wird der Cloud Router in network-b für die Verwendung von Benutzerdefiniertem Route Advertisement konfiguriert. Beispielsweise bewirbt der Cloud Router Subnetzrouten von network-b sowie benutzerdefinierte Präfixe, die Subnetzrouten in network-a und network-c abdecken.
    • Je nach Subnetz- und dynamischen Routeninteraktionen erlernt der Cloud Router in network-b lokale Präfixe und erstellt dynamische Routen in network-b.
  • Die Peering-Verbindungen von network-b zu network-a und von network-b zu network-c werden mit dem Flag --export-custom-routes konfiguriert. Die Peering-Verbindungen von network-a zu network-b und von network-c zu network-b werden mit dem Flag --import-custom-routes konfiguriert.

Wenn Firewalls korrekt konfiguriert sind, sind folgende Szenarien möglich:

  • VM-Instanzen in network-a können andere VMs in network-b und lokale Systeme erreichen.
  • VM-Instanzen in network-c können andere VMs in network-b und lokalen Systemen erreichen.
  • VM-Instanzen in network-b können andere VMs in network-a und network-c sowie Systeme im lokalen Netzwerk erreichen.

Da das VPC-Netzwerk-Peering nicht transitiv ist, können VM-Instanzen in network-a und network-c nur dann miteinander kommunizieren, wenn Sie auch die Netzwerke network-a und network-c über VPC-Netzwerk-Peering verbinden.

Preise

Für VPC-Netzwerk-Peering gelten die regulären Netzwerkpreise.

Nächste Schritte