VPC-Netzwerk-Peering

VPC-Netzwerk-Peering (Virtual Private Cloud) in Google Cloud ermöglicht private RFC 1918-Verbindungen zwischen zwei VPC-Netzwerken, unabhängig von ihrer Zugehörigkeit zu demselben Projekt oder derselben Organisation.

Mit VPC-Netzwerk-Peering können Sie VPC-Netzwerke verbinden, sodass Arbeitslasten in verschiedenen VPC-Netzwerken im privaten RFC 1918-Bereich miteinander kommunizieren können. Der Traffic verbleibt im Netzwerk von Google und durchläuft nicht das öffentliche Internet.

VPC-Netzwerk-Peering eignet sich für:

  • 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 können durch Peering miteinander verbunden werden.

Wenn Sie in Ihrem Unternehmen mehrere administrative Netzwerkdomains haben, können Sie mit VPC-Netzwerk-Peering Dienste innerhalb eines privaten RFC 1918-Bereichs in verschiedenen VPC-Netzwerken zur Verfügung stellen. Wenn Sie hingegen anderen Organisationen Dienste anbieten, können Sie die Dienste mit VPC-Netzwerk-Peering diesen Unternehmen innerhalb eines privaten RFC 1918-Bereichs zur Verfügung stellen. Die Möglichkeit, Dienste organisationsübergreifend bereitzustellen, ist nützlich, wenn Sie anderen Unternehmen Dienste anbieten. Sie ist auch innerhalb Ihres Unternehmens nützlich, wenn Sie aufgrund Ihrer Unternehmensstruktur oder nach Fusionen oder Übernahmen mehrere separate Organisationsknoten haben.

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

  • Netzwerklatenz: Netzwerke mit öffentlichen IP-Adressen haben eine höhere Latenz als private Netzwerke. Der gesamte Peering-Traffic verbleibt im Google-Netzwerk.
  • Netzwerksicherheit: Dienstinhaber müssen ihre Dienste nicht über das öffentliche Internet verfügbar machen und sie nicht entsprechenden 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 Traffic-Managementtools 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 entsprechend 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-Peering-Netzwerke tauschen immer alle Subnetzrouten aus. Sie können auch 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 zwischen Peering-Netzwerken) 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 Organisation verweigern. Die Einschränkung gilt für neue Peering-Konfigurationen und wirkt sich nicht auf vorhandene Verbindungen aus. Eine vorhandene Peering-Verbindung kann auch dann funktionieren, wenn eine neue Richtlinie neue Verbindungen ablehnt. 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 für 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 über Peering verbunden werden
    • 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. Für Legacy-Netzwerke wird das Peering NICHT unterstützt.
  • Sie können den Austausch von Subnetzrouten nicht deaktivieren und auch nicht 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/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 eine VM-Instanz 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

Nach dem Einrichten von Peering mit einem anderen Netzwerk und dem Austausch von Routen verfügt Ihr VPC-Netzwerk möglicherweise über Routen mit konkurrierenden Zielen. Informationen dazu, wie Google Cloud die Routingreihenfolge festlegt, finden Sie unter Routingreihenfolge.

Benutzerdefinierte Routen importieren und exportieren

Standardmäßig werden Subnetzrouten zwischen Peering-Netzwerken immer ausgetauscht. Wenn die Netzwerkadministratoren bei beiden Netzwerken die entsprechenden Peering-Konfigurationen festgelegt haben, können Sie auch benutzerdefinierte Routen austauschen, einschließlich statischer und dynamischer Routen.

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

Wenn Sie benutzerdefinierte Routen importieren oder exportieren, tauschen Netzwerke diese Routen nur mit direkt verbundenen Peering-Netzwerken aus. Wenn Ihr VPC-Netzwerk beispielsweise mit mehreren Netzwerken über Peering 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, sind möglicherweise mehrere statische Routen aktiv, um Traffic an VM-Instanzen zu leiten, auf 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 Subnetze von Peering-Netzwerken an Ihr lokales Netzwerk gemeldet werden.

Hinweise

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

  • 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ächsten Hop nicht zwischen Peering-Netzwerken ausgetauscht.
  • Importierte Routen können zu unbeabsichtigten Änderungen am Trafficfluss führen, z. B. zu Ä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.

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

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

Wenn es bei den Komponenten eines VPC-Netzwerks Subnetze mit überlappenden IP-Bereichen gibt, verursacht dies einen Routingkonflikt. Angenommen, zwischen dem VPC-Netzwerk N1 und dem VPC-Netzwerk N2 wurde bereits eine Peering-Verbindung hergestellt. Nun versucht VPC-Netzwerk N3, eine Peering-Verbindung zu 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.

Grafik: Überlappende Subnetz-IP-Bereiche bei drei Peering-Komponenten (zum Vergrößern klicken)
Überlappende Subnetz-IP-Bereiche 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 seine IP-Bereiche nicht mit denen des direkt verbundenen Peering-Netzwerks N1 überschneiden.

Grafik: 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. Ist dies der Fall, schlägt die Erstellung oder 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.

Grafik: Prüfung bei der Subnetzerstellung mit drei Komponenten (zum Vergrößern klicken)
Prüfung bei der Subnetzerstellung mit drei 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 ausgehender Traffic zum VPN-Tunnel geleitet wird.

Cloud VPN unterstützt statisches und dynamisches Routing, Cloud Interconnect unterstützt jedoch nur dynamisches Routing. Verwenden Sie für dynamisches Routing Cloud Router, sodass Routen zwischen dem VPC-Netzwerk und dem 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 Sie auf Ressourcen in Peering-VPC-Netzwerken zugreifen können, 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:

Netzwerk 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 network-b globales dynamisches Routing aktiviert, 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. So können beispielsweise die VM-Instanzen vm-a1 und vm-a2 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:

Netzwerk 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 andere 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.

  • network-b verfügt über die relevanten statischen VPN-Routen, um Traffic an das verbundene lokale Netzwerk weiterzuleiten. Die statische Route wird exportiert und dann von den Peering-VPC-Netzwerken importiert. Wenn Sie Cloud Router für dynamisches Routing verwenden, müssen Sie die Subnetz-IP-Adressen der Peering-Netzwerke per Advertising anbieten. Cloud Router bietet Routen von VPC-Netzwerk-Peering nicht automatisch an.

  • Hosts im lokalen Netzwerk können Traffic an Hosts in jedem der VPC-Netzwerke senden und von dort erhalten. Das lokale Netzwerk muss Routen enthalten, die das VPN-Gateway als nächsten Hop aufweisen, wenn Traffic für ein VPC-Netzwerk bestimmt ist.

  • Hosts in network-c können Hosts in network-b und im lokalen Netzwerk erreichen, jedoch keine Hosts in network-a. Ebenso können Hosts in network-a network-b und das lokale Netzwerk erreichen, aber nicht network-c. Das liegt daran, dass Peering-Routen nicht transitiv sind.

Internes TCP/UDP-Load-Balancing

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:

  • Die VMs befinden sich in derselben Region wie der interne TCP/UDP-Load-Balancer.
  • Firewallregeln für eingehenden Traffic, die für die Back-End-VMs des Load-Balancers gelten, lassen Traffic von Quellen in Peering-Netzwerken zu. Diese Firewallregeln für eingehenden Traffic müssen in dem VPC-Netzwerk erstellt werden, das den Load-Balancer enthält.

Weitere Informationen finden Sie unter VPC-Netzwerk-Peering verwenden.

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.

Firewall

Firewallregeln können nicht in Peering-Netzwerke importiert werden. Sie können Firewallregeln in jedem Netzwerk separat konfigurieren, um Traffic von den verbundenen Peering-Netzwerken zuzulassen oder zu blockieren.

Bei einer Peering-Verbindung zwischen Ihrem VPC-Netzwerk und einem anderen VPC-Netzwerk möchten Sie möglicherweise Traffic zu bestimmten VM-Instanzen oder internen Load-Balancing-Endpunkten unterbinden. Verwenden Sie hierfür Firewallregeln, da es nicht möglich ist, bestimmte VM-Instanzen oder interne Load-Balancer vom Peering auszuschließen. Wenn Sie die Kommunikation mit bestimmten VM-Instanzen oder internen Load-Balancern unterbinden möchten, können Sie in dem Netzwerk, zu dem die Kommunikation blockiert werden soll, Firewallregeln für eingehenden Traffic konfigurieren.

  • VM-Instanzen: In diesem Fall können Sie eine Eingangsfirewall installieren, die nur Traffic von bestimmten Quell-IP-Adressen zulässt. Diese Quell-IPs können den Subnetz-CIDRs in Ihrem eigenen VPC-Netzwerk zugeordnet werden. Auf diese Weise wird sämtlicher Traffic blockiert, der von den verbundenen Peering-VPC-Netzwerken kommt.
Grafik: Firewall mit VPC-Netzwerk-Peering (zum Vergrößern klicken)
Firewall mit VPC-Netzwerk-Peering (zum Vergrößern klicken)
  • Interne Load-Balancer: In diesem Fall können Sie Firewallregeln für eingehenden Traffic im VPC-Netzwerk mit dem internen Load-Balancer konfigurieren. Diese Quell-IPs können alle oder einen Teil der Subnetz-CIDRs in Ihrem eigenen Netzwerk zuordnen. Wenn für alle Subnetz-CIDR-Bereiche des verbundenen Peering-Netzwerks Firewallregeln für eingehenden Traffic konfiguriert sind, kann keine Instanz in diesem Netzwerk die Back-End-VMs des internen Load-Balancers erreichen.

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.

Grafik: 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 network-SVPC anhängen. network-SVPC ist über Peering mit network-A verbunden. Deshalb gilt:

  • VM-Instanzen in Dienstprojekten der freigegebenen VPC, die network-SVPC (VM3 und VM4) nutzen, haben private interne IP-Verbindungen mit allen Endpunkten, die network-A zugeordnet sind.
  • network-A zugeordnete VM-Instanzen haben private, interne IP-Verbindungen mit allen Endpunkten, die network-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.

Routing-Richtlinie 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 Peers und nicht zwischen anderen Netzwerken, in denen die Instanzen Netzwerkschnittstellen enthalten, nach überlappenden IP-Bereichen. 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. Traffic, der die VM-Instanz an jedes Subnetz weitergibt, 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, tauscht Google Cloud immer die Subnetzrouten zwischen den beiden Peering-Netzwerken aus. Wenn Firewallregeln in jedem Netzwerk die Kommunikation zulassen, können VM-Instanzen in einem Netzwerk mit Instanzen im Peering-Netzwerk kommunizieren.

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

Weitere Informationen