VPC-Netzwerk-Peering

Das Google Cloud VPC-Netzwerk-Peering verbindet zwei Virtual Private Cloud-Netzwerke (VPC), sodass Ressourcen in jedem Netzwerk miteinander kommunizieren können:

  • Alle Subnetze können über interne IPv4-Adressen kommunizieren.
  • Dual-Stack-Subnetze können auch über interne oder externe IPv6-Adressen kommunizieren.

Peering-VPC-Netzwerke können sich im selben Projekt, in verschiedenen Projekten derselben Organisation oder in verschiedenen Projekten verschiedener Organisationen befinden.

VPC-Netzwerk-Peering bietet folgende Vorteile:

Vorteile von VPC-Netzwerk-Peering

VPC-Netzwerk-Peering bietet folgende Vorteile:

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

Spezifikationen

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

Allgemeine Spezifikationen:

  • VPC-Netzwerk-Peering kann mit Compute Engine, GKE und der flexiblen App Engine-Umgebung verwendet werden.
    • Standardmäßig wird VPC-Netzwerk-Peering mit GKE bei der 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.
  • VPC-Netzwerk-Peering ist nur zwischen VPC-Netzwerken möglich. Für Legacy-Netzwerke wird das Peering nicht unterstützt.
  • 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. Bei IPv6 werden jedoch nur dynamische Routen ausgetauscht.
  • Für ein VPC-Netzwerk kann Peering mit mehreren anderen VPC-Netzwerken eingerichtet werden, allerdings gibt es hierfür ein Limit.
  • Es ist nicht möglich, zwei verschiedene VPC-Netzwerke im automatischen Modus per Peering zu verbinden, da alle VPC-Netzwerke im automatischen Modus die gleichen Subnetze haben.
  • Sie können ein VPC-Netzwerk im benutzerdefinierten Modus und ein VPC-Netzwerk im automatischen Modus wie das Standardnetzwerk per Peering verbinden. Sie müssen jedoch darauf achten, dass sich keines der Subnetze im VPC-Netzwerk im benutzerdefinierten Modus mit dem Adressbereich des VPC-Netzwerks im automatischen Modus (10.128.0.0/9) überschneidet.

Administrative Trennung:

  • Peering-VPC-Netzwerke bleiben administrativ getrennt. Die Routen, Firewalls, VPNs und anderen Trafficmanagementtools werden in jedem VPC-Netzwerk separat verwaltet und angewendet.
  • Zum Herstellen einer Peering-Verbindung muss ein Netzwerkadministrator für jedes VPC-Netzwerk eine Peering-Verbindung zum anderen VPC-Netzwerk herstellen. Ein Netzwerkadministrator für eines der VPC-Netzwerke 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:

  • 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

Routenaustausch:

  • 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 exportieren immer Subnetzrouten.
  • VPC-Peers importieren Subnetzrouten immer, wenn das Subnetz private IP-Adressen verwendet. Wenn das Subnetz privat genutzte öffentliche IP-Adressen verwendet, müssen Peering-Netzwerke privat genutzte öffentliche IP-Subnetzrouten importieren, um sie von anderen Netzwerken zu empfangen. Weitere Informationen zu privaten und privat verwendeten öffentlichen IP-Adressen finden Sie unter Gültige Bereiche.
  • 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
  • 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.
  • 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.

Einschränkungen:

  • 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.
  • VPC-Firewallregeln können kein Netzwerktag oder Dienstkonto aus einem Peering-Netzwerk verwenden. Weitere Informationen finden Sie unter Netzwerksicherheit.
  • 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.
  • Richtlinienbasierte Routen werden nie über Peering ausgetauscht.

Benutzerdefinierte Routen importieren und exportieren

Netzwerksicherheit

VPC-Netzwerk-Peering tauscht keine VPC-Firewallregeln oder hierarchische Firewallrichtlinien aus. VPC-Firewallregeln in einem VPC-Netzwerk können keine Ziele oder Quellen mithilfe von Netzwerktags oder Dienstkonten aus dem anderen VPC-Netzwerk angeben. Allerdings kann dasselbe Zielnetzwerk-Tag in beiden Netzwerken verwendet werden.

Jedes VPC-Netzwerk enthält implizierte Firewallregeln. Aufgrund der implizierte Firewallregeln zum Ablehnen von eingehendem Traffic müssen Sicherheitsadministratoren für ein lokales VPC-Netzwerk geeignete Firewallregeln zum Zulassen von eingehendem Traffic oder hierarchische Firewallrichtlinien erstellen. Diese Regeln oder Richtlinien lassen Pakete aus den erforderlichen Quell-IP-Adressbereichen im Peering-VPC-Netzwerk zu.

Aufgrund der implizierten Firewallregeln zum Zulassen von ausgehendem Traffic müssen Sie keine Firewallregeln für ausgehenden Traffic oder hierarchische Firewallrichtlinien erstellen, um Pakete an die Ziele im Peering-VPC-Netzwerk zuzulassen. Wenn jedoch Sicherheitsadministratoren für das lokale VPC-Netzwerk explizite Ablehnungsregeln für ausgehenden Traffic erstellt haben, müssen Sie Zulassungsregeln oder -richtlinien erstellen.

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 werden.

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 Passthrough-Network Load Balancer in einem Peering-VPC-Netzwerk zugreifen. Weitere Informationen finden Sie unter VPC-Netzwerk-Peering für interne Network Load Balancer verwenden. Peering-Netzwerke können benutzerdefinierte statische Routen mithilfe von internen Network Load Balancern als nächste Hops austauschen. Weitere Informationen finden Sie unter Optionen für den Routenaustausch.

Clients in einem lokalen VPC-Netzwerk können auf interne Application Load Balancer in einem Peering-VPC-Netzwerk zugreifen. Weitere Informationen finden Sie unter VPC-Netzwerk-Peering für interne Application Load Balancer verwenden.

Limits für VPC-Netzwerk-Peering

Mit VPC-Netzwerk-Peering-Limits wird Folgendes gesteuert:

  • Die Anzahl der Ressourcen wie VM-Instanzen oder interne Weiterleitungsregeln, die in einer Peering-Gruppe vorhanden sein können.
  • Die Anzahl der Netzwerke, mit denen ein bestimmtes VPC-Netzwerk eine Verbindung herstellen kann.

Die Limits für das VPC-Peering hängen vom 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 finden Sie unter Einschränkungen für VPC-Netzwerk-Peering.

Optionen für den Routenaustausch

Wenn ein VPC-Netzwerk lokale Routen für ein Peering-VPC-Netzwerk freigibt, werden die Routen exportiert. Das Peering-VPC-Netzwerk kann dann die Routen importieren. 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.

Optionen für den Austausch von Subnetzrouten

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

Routentyp Bedingungen für den Routenexport Routenimportbedingungen
IPv4-Subnetzrouten (primäre und sekundäre IPv4-Subnetzbereiche) unter Verwendung von privaten IPv4-Adressbereichen Immer exportiert

Kann nicht deaktiviert werden		 Immer importiert

Kann nicht deaktiviert werden
IPv4-Subnetzrouten (primäre und sekundäre IPv4-Subnetzbereiche) unter Verwendung privat verwendeter öffentlicher IPv4-Adressbereiche 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 ist 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 ist durch Festlegen von --stack-type=IPV4_IPV6 aktiviert 		Standardmäßig nicht importiert

Der Import ist durch Festlegen von --stack-type=IPV4_IPV6 aktiviert.

Optionen für den Austausch benutzerdefinierter statischer Routen

In der folgenden Tabelle werden die Optionen für den Routenaustausch für benutzerdefinierte statische Routen beschrieben.

Routentyp Bedingungen für den Routenexport Routenimportbedingungen
Benutzerdefinierte statische Routen mit Netzwerktags (alle Typen des nächsten Hops) Kann nicht exportiert werden Kann nicht importiert werden
Benutzerdefinierte Statische Routen, die den nächsten Hop des Standard-Internetgateways verwenden Kann nicht exportiert werden Kann nicht importiert werden
Benutzerdefinierte statische IPv4-Routen – ohne Netzwerk-Tags, die die private IPv4-Adresse eines internen Passthrough-Network Load Balancers als nächsten Hop verwenden Immer exportiert (wie Subnetz-IPv4-Routen)

Kann nicht deaktiviert werden 		Immer importiert (wie Subnetz-IPv4-Routen)

Kann nicht deaktiviert werden
Benutzerdefinierte statische IPv4-Routen – ohne Netzwerk-Tags, die den Namen der Weiterleitungsregel eines internen Passthrough-Network Load Balancers als nächsten Hop 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.
Benutzerdefinierte statische IPv4-Routen – ohne Netzwerk-Tags, die andere Typen von nächsten Hops 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.
Benutzerdefinierte 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 dynamische Routen beschrieben.

Routentyp Bedingungen für den Routenexport 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.

Benutzerdefinierter Routenaustausch

Wenn ein VPC-Netzwerk benutzerdefinierte Routen exportiert und das andere VPC-Netzwerk benutzerdefinierte Routen importiert, kann das Importnetzwerk Pakete für jede importierte benutzerdefinierte Route direkt im Peering-VPC-Netzwerk senden. Benutzerdefinierte statische und benutzerdefinierte dynamische Routen werden zusammen erlernt und können nicht unabhängig konfiguriert werden. Änderungen in einem Netzwerk werden im anderen Netzwerk unter bestimmten Bedingungen übernommen. Weitere Informationen finden Sie in diesem Dokument unter Ignorierte Routen, Interaktionen mit Subnetz- und Peering-Subnetzrouten und Interaktionen mit Subnetzen und statischen Routen.

Das Importieren benutzerdefinierter Routen aus einem Peering-VPC-Netzwerk kann in den folgenden Szenarien hilfreich 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 das Peering-VPC-Netzwerk Routen zu lokalen Ressourcen enthält und Sie auf diese Ressourcen im lokalen VPC-Netzwerk zugreifen müssen, müssen Sie auch Routen für die Subnetz-IP-Adressbereiche des lokalen VPC-Netzwerks im lokalen Netzwerk erstellen. Sie können benutzerdefinierte Cloud Router Route Advertisements im Peering-VPC-Netzwerk verwenden, um diese zusätzliche Anforderung zu erfüllen.

Ignorierte Routen

Selbst wenn ein VPC-Netzwerk eine Route importiert, kann sie die importierte Route in folgenden Situationen 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, und Sie können das 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 oben genannten Situationen finden Sie unter Routingreihenfolge.

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

Interaktionen mit Subnetz- und Peering-Subnetzrouten

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

  • Peering erlaubt identische IPv4-Subnetzrouten. Beispielsweise können zwei Peering-VPC-Netzwerke nicht beide eine IPv4-Subnetzroute haben, deren Ziel 100.64.0.0/10 ist.
  • Das Peering verhindert, dass eine Subnetzroute in einer Peering-Subnetzroute enthalten ist. 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.

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

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

Während Sie Peering-Netzwerke herstellen, gibt Google Cloud einen Fehler zurück, wenn einer der folgenden Vorgänge eine Überschneidung verursacht:

IPv6-Subnetzrouten (intern und extern) sind Definitionsgemäß. 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 ist es erforderlich, dass Subnetzrouten und Peering-Subnetzrouten die spezifischsten IPv4- oder IPv6-Zielbereiche 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 benutzerdefinierten statischen Routen.

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

  • Eine lokale statische Route darf 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 der einzige mögliche Subnetz-IPv6-Adressbereich 2001:0db8:0a0b:0c0d::/64, da Subnetz-IPv6-Adressbereiche in Google Cloud 64-Bit-Subnetzmaskenlängen verwenden müssen.

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

      • Angenommen, zwei VPC-Netzwerke sind bereits über Peering verbunden, exportieren und importieren jedoch derzeit keine IPv4-Subnetzrouten mithilfe privat verwendeter öffentlicher IPv4-Adressbereiche. Im ersten VPC-Netzwerk ist eine lokale statische Route mit dem Ziel 11.0.0.0/24 sowie im Peering-VPC-Netzwerk 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 über Peering verbunden und der Peering-Stack-Typ ist nur IPv4. Im ersten VPC-Netzwerk ist eine lokale statische Route mit dem Ziel 2001:0db8:0a0b:0c0d::/96 sowie im Peering-VPC-Netzwerk eine IPv6-Subnetzroute mit dem Ziel 2001:0db8:0a0b:0c0d::/64 vorhanden. Sie können den Peering-Stack-Typ nicht in IPV4_IPV6 ändern.

    • Wenn VPC-Netzwerke jedoch bereits über VPC-Netzwerk-Peering verbunden sind, können Sie folgende Vorgänge nicht ausführen:

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

      • Erstellen Sie im Peering-VPC-Netzwerk einen neuen Subnetzadressbereich, wenn dieser Bereich genau übereinstimmen oder eine vorhandene lokale statische Route enthalten würde.

  • Eine statische Peering-Route darf 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 benutzerdefinierte 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 Importieren der in Konflikt stehenden statischen Route führt.

    • Wenn VPC-Netzwerke jedoch bereits über VPC-Netzwerk-Peering verbunden sind, können Sie folgende Vorgänge nicht ausführen:

      • 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 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 erlernt werden, als lokale benutzerdefinierte 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 VPC-Netzwerks regional ist, exportiert dieses Netzwerk dynamische Routen nur in derselben Region wie die Cloud Router, die die Präfixe gelernt haben.

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

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

Ein Beispiel zur Veranschaulichung dieses Verhaltens finden Sie unter Lokales VPC-Netzwerk und Peer-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 benutzerdefinierten dynamischen Routen beschrieben.

Beispiele für VPC-Netzwerk-Peering

In den folgenden Beispielen werden zwei gängige VPC-Netzwerk-Peering-Szenarien veranschaulicht.

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

In diesem Beispiel ist 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 ist so konfiguriert, dass die benutzerdefinierten Routen exportiert werden. Die Peering-Verbindung für network-a ist so konfiguriert, dass die benutzerdefinierten Routen importiert werden.

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, muss der Cloud Router in network-b für die Verwendung von Benutzerdefiniertem Route Advertisement konfiguriert sein. 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 wurden für den Export benutzerdefinierter Routen konfiguriert. Die Peering-Verbindungen von network-a zu network-b und von network-c bis network-b wurden für den Import benutzerdefinierter Routen konfiguriert.

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

  • VM-Instanzen in network-a können andere VMs in network-b und lokalen Systemen 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 nicht miteinander kommunizieren, es sei denn, Sie verbinden auch die Netzwerke network-a und network-c über VPC Netzwerk-Peering.

Nächste Schritte