Lokales VCN-Peering mit lokalen Peering-Gateways

In diesem Thema geht es um lokales VCN-Peering. In diesem Fall bedeutet lokal, dass sich die VCNs in derselben Region befinden. Wenn sich die VCNs in unterschiedlichen Regionen befinden, finden Sie weitere Informationen unter Remote-VCN-Peering mit einem Legacy-DRG.

Lokale Peering-Gateways werden weiterhin unterstützt. In diesem Szenario wird davon ausgegangen, dass Sie ein Legacy-DRG verwenden. Oracle empfiehlt derzeit, Traffic von einem VCN zu einem anderen über ein upgegradetes DRG zu leiten, wie unter Lokales VCN-Peering über ein upgegradetes DRG beschrieben.

Lokales VCN-Peering - Überblick

Beim lokalen VCN-Peering werden zwei VCNs in derselben Region verbunden, sodass ihre Ressourcen über private IP-Adressen kommunizieren können, ohne den Traffic über das Internet oder über ein On-Premise-Netzwerk zu leiten. Die VCNs können sich sowohl im selben als auch in verschiedenen Oracle Cloud Infrastructure-Mandanten  befinden. Ohne Peering benötigt ein bestimmtes VCN ein Internetgateway und öffentliche IP-Adressen für die Instanzen, die mit einem anderen VCN kommunizieren müssen.

Informationen zu Limits finden Sie unter Gatewaylimits und Erhöhung des Servicelimits anfordern.

Weitere Informationen finden Sie unter Zugriff auf andere VCNs: Peering.

Übersicht der Netzwerkkomponenten für Peering mit einem LPG

Auf hoher Ebene sind folgende Networking-Servicekomponenten für ein lokales Peering erforderlich:

  • Zwei VCNs mit nicht überlappenden CIDRs in derselben Region
  • Ein lokales Peering-Gateway (LPG), das an jedes VCN in der Peering-Beziehung angehängt ist.
  • Eine Verbindung zwischen diesen beiden LPGs.
  • Unterstützende Routingregeln, die den Traffic über die Verbindung und nur zwischen den ausgewählten Subnetzen in den jeweiligen VCNs zulassen (sofern gewünscht).
  • Unterstützende Sicherheitsregeln zur Steuerung, welche Traffictypen von und zu den Instanzen in den Subnetzen, die mit dem anderen VCN kommunizieren müssen, weitergeleitet werden dürfen.

Das folgende Diagramm veranschaulicht die Komponenten.

Diese Abbildung zeigt das grundlegende Layout von zwei VCNs mit jeweils einem lokalen Peering-Gateway.
Hinweis

Ein bestimmtes VCN kann mit Peer-LPGs die folgenden Ressourcen erreichen:

  • VNICs im anderen VCN
  • Ein On-Premise-Netzwerk, das an ein anderes VCN angehängt ist, wenn ein erweitertes Routingszenario mit dem Namen Transitrouting für die VCNs eingerichtet wurde

Ein VCN kann sein Peer-VCN nicht verwenden, um andere Ziele außerhalb der VCNs (wie das Internet) zu erreichen. Beispiel: Wenn VCN-1 im vorherigen Diagramm ein Internetgateway hätte, könnte es von den Instanzen in VCN-2 nicht zum Senden von Traffic an Endpunkte im Internet verwendet werden. VCN-2 könnte jedoch Traffic vom Internet über VCN-1 empfangen. Weitere Informationen finden Sie unter Wichtige Auswirkungen von VCN-Peering.

Explizite Zustimmung von beiden Seiten erforderlich

Das Peering umfasst zwei VCNs, die zu derselben Partei oder zu zwei verschiedenen Parteien gehören können. Die Parteien befinden sich möglicherweise beide in Ihrem Unternehmen, aber in verschiedenen Abteilungen. Die Parteien könnten sich auch in komplett verschiedenen Unternehmen befinden (Beispiel: in einem Serviceanbietermodell).

Das Peering zwischen zwei VCNs erfordert eine explizite Zustimmung beider Parteien in Form von Oracle Cloud Infrastructure Identity and Access Management-Policys, die jede Partei für das Compartment  oder den Mandanten des eigenen VCN implementiert. Wenn sich die VCNs in unterschiedlichen Mandanten befinden, muss jeder Administrator die Mandanten-OCID angeben und spezielle Policy-Anweisungen einrichten, um das Peering zu aktivieren.

Erweitertes Szenario: Transitrouting

Das erweiterte Routingszenario mit dem Namen Transitrouting ermöglicht die Kommunikation zwischen einem On-Premise-Netzwerk und mehreren VCNs über ein einzelnes Oracle Cloud Infrastructure FastConnect oder Site-to-Site-VPN. Die VCNs müssen in derselben Region vorhanden und per lokalem Peering in einem Hub-and-Spoke-Layout verbunden sein. Im Szenario verfügt das VCN, das als Hub fungiert, über eine Routentabelle, die mit jedem LPG verknüpft ist (in der Regel werden Routentabellen mit den Subnetzen eines VCN verknüpft).

Beim Erstellen eines LPG können Sie optional eine Routentabelle damit verknüpfen. Wenn bereits ein LPG ohne eine Routentabelle vorhanden ist, können Sie eine Routentabelle damit verknüpfen. Die Routentabelle muss zum VCN dieses LPG gehören. Eine Routentabelle, die einem LPG zugeordnet ist, kann nur Regeln enthalten, die das an das VCN angehängte DRG als Ziel verwenden. Es kann auch private IP-Next-Hop-Routen zu einer Instanz im VCN unterstützen.

Ein LPG kann auch ohne zugehörige Routentabelle vorhanden sein. Sobald Sie eine Routentabelle jedoch mit einem LPG verknüpft haben, muss immer eine Routentabelle mit ihm verknüpft sein. Sie können jedoch eine andere Routentabelle mit dem LPG verknüpfen. Sie können auch die Regeln der Tabelle bearbeiten sowie einige oder alle Regeln löschen.

Wichtige Konzepte für das lokale Peering

Die folgenden Konzepte helfen Ihnen dabei, die Grundlagen von VCN-Peering zu verstehen und ein lokales Peering einzurichten.

PEERING
Beim Peering handelt es sich um eine einzelne Peering-Beziehung zwischen zwei VCNs. Beispiel: Wenn VCN-1 per Peering mit drei anderen VCNs verbunden ist, sind drei Peerings vorhanden. Der lokale Teil des lokalen Peerings gibt an, dass die VCNs sich in derselben Region befinden. Für ein bestimmtes VCN sind jeweils maximal 10 lokale Peerings möglich.
Achtung

Die CIDRs der beiden VCNs in der Peering-Beziehung dürfen sich nicht überschneiden. Wenn jedoch VCN-1 per Peering mit drei anderen VCNs verbunden ist, dürfen die CIDRs dieser drei VCNs sich überschneiden. Sie würden die Subnetze in VCN-1 so einrichten, dass Routingregeln vorhanden sind, die den Traffic zum Ziel-Peer-VCN weiterleiten.
VCN-ADMINISTRATOREN
Im Allgemeinen kann VCN-Peering nur dann stattfinden, wenn beide VCN-Administratoren dem zustimmen. In der Praxis bedeutet dies, dass die beiden Administratoren:
  • Einige grundlegende Informationen gemeinsam verwenden.
  • Die Einrichtung der erforderlicher Oracle Cloud Infrastructure Identity and Access Management-Policys koordinieren, um das Peering zu ermöglichen.
  • Ihre VCNs für das Peering konfigurieren.
Je nach Situation kann ein einzelner Administrator sowohl für beide VCNs als auch für die zugehörigen Policys zuständig sein.
Weitere Informationen zu den erforderlichen Policys und der VCN-Konfiguration finden Sie unter Lokales Peering einrichten.
ACCEPTOR UND REQUESTOR
Um die für das Peering erforderlichen IAM-Policys zu implementieren, müssen die beiden VCN-Administratoren einen Administrator als Requestor und den anderen als Acceptor zuweisen. Der Requestor ist derjenige, der die Anforderung zum Verbinden der beiden LPGs initiiert. Der Acceptor erstellt wiederum eine bestimmte IAM-Policy, die dem Requestor die Berechtigung zum Verbinden zu den LPGs im Compartment  des Acceptors erteilt. Ohne diese Policy wird die Anforderung des Requestors zum Verbinden nicht erfolgreich sein.
LOKALES PEERING-GATEWAY (LPG)
Lokales Peering-Gateway (LPG) ist eine Komponente in einem VCN, mit der Traffic an ein lokales Peer-VCN geleitet wird. Bei der VCN-Konfiguration muss jeder Administrator ein LPG für sein VCN erstellen. Ein bestimmtes VCN muss für jedes lokale Peering ein eigenes LPG haben (max. 10 LPGs pro VCN). Im vorherigen Beispiel würde dies Folgendes bedeuten: VCN-1 hätte drei LPGs für das Peering mit drei anderen VCNs. In der API ist ein LocalPeeringGateway ein Objekt, das Informationen zum Peering enthält. Ein LPG kann nicht für die Einrichtung eines anderen Peerings wiederverwendet werden.
PEERING-VERBINDUNG
Wenn der Requestor die Anforderung zum Peering (in der Konsole oder API) initiiert, fordert er praktisch die andere Seite auf, die beiden LPGs zu verbinden. Der Requestor muss Informationen zur Identifizierung jedes LPG haben (wie Compartment und Name des LPG oder LPG-OCID). Jeder Administrator muss die erforderlichen IAM-Policys für das Compartment oder den Mandanten einrichten.
Beide VCN-Administratoren können ein Peering beenden, indem sie ihr LPG löschen. In diesem Fall wird der Status des anderen LPG auf REVOKED umgeschaltet. Der Administrator kann stattdessen die Funktion der Verbindung stoppen, indem er die Routingregeln oder Sicherheitsregeln entfernt, mit denen Traffic über die Verbindung fließen kann (siehe die nächsten Abschnitte).
ROUTING ZUM LPG
Bei der Konfiguration der VCNs muss jeder Administrator das Routing des VCN aktualisieren, um den Traffic zwischen den VCNs zu ermöglichen. In der Praxis ähnelt dies dem von Ihnen eingerichteten Routing für jedes Gateway (wie Internetgateway oder dynamisches Routinggateway). Aktualisieren Sie für jedes Subnetz, das mit dem anderen VCN kommunizieren muss, die Routentabelle des Subnetzes. Die Routingregel gibt das CIDR des Zieltraffics und das LPG als Ziel an. Das LPG leitet den Traffic, der dieser Regel entspricht, an das andere LPG weiter. Dieses LPG leitet den Traffic wiederum zum nächsten Hop im anderen VCN weiter.
Im folgenden Diagramm sind VCN-1 und VCN-2 per Peering miteinander verbunden. Der Traffic von einer Instanz im Subnetz A (10.0.0.15), der für eine Instanz in VCN-2 (192.168.0.15) bestimmt ist, wird an LPG-1 basierend auf der Regel in der Routentabelle von Subnetz A weitergeleitet (siehe Callout 1: Routentabelle von Subnetz A). Von dort wird der Traffic an LPG-2 und schließlich an das Ziel im Subnetz X weitergeleitet.
Diese Abbildung zeigt den Pfad des Traffics, der von einem lokalen Peering-Gateway zum anderen weitergeleitet wird.
Callout 1: Routentabelle von Subnetz A
Ziel-CIDR Routenziel
0.0.0.0/0 Internetgateway
172.16.0.0/12 DRG
192.168.0.0/16 LPG-1
Callout 2: Routentabelle von Subnetz X
Ziel-CIDR Routenziel
10.0.0.0/16 LPG-2
Hinweis

Wie bereits erwähnt, kann ein bestimmtes VCN mit den verbundenen LPGs VNICs in einem anderen VCN oder On-Premise-Netzwerk erreichen, wenn das Transaktionsrouting für die VCNs eingerichtet ist. Ein VCN kann jedoch sein Peer-VCN nicht verwenden, um andere Ziele außerhalb der VCNs (wie das Internet) zu erreichen. Beispiel: Im vorherigen Diagramm kann VCN-2 das an VCN-1 angehängte Internetgateway nicht verwenden.

SICHERHEITSREGELN
Jedes Subnetz in einem VCN verfügt über mindestens eine Sicherheitsliste, die den Traffic in die und aus den VNICs des Subnetzes auf der Paketebene steuert. Mit Sicherheitslisten steuern Sie, welcher Traffictyp für das andere VCN zulässig ist. Bei der Konfiguration der VCNs muss jeder Administrator auswählen, welche Subnetze in seinem eigenen VCN mit VNICs in dem anderen VCN kommunizieren müssen, und die Subnetzsicherheitslisten entsprechend aktualisieren.
Wenn Sie Netzwerksicherheitsgruppen (NSGs) zur Implementierung von Sicherheitsregeln verwenden, können Sie Sicherheitsregeln für eine NSG schreiben, die eine andere NSG als Quelle oder Ziel des Traffics angeben. Die beiden NSGs müssen jedoch zum selben VCN gehören.

Wichtige Auswirkungen von VCN-Peering

Sofern noch nicht geschehen, lesen Sie Wichtige Auswirkungen von Peering, um die wichtigen Auswirkungen auf die Zugriffskontrolle, Sicherheit und Performance von Peer-VCNs zu verstehen.

Lokales Peering einrichten

Im Folgenden wird der allgemeine Prozess zum Einrichten eines Peerings zwischen zwei VCNs in derselben Region beschrieben:

  1. LPGs erstellen: Jeder VCN-Administrator erstellt einen LPG für das eigene VCN.
  2. Informationen gemeinsam verwenden: Die Administratoren verwenden die grundlegenden erforderlichen Informationen gemeinsam.
  3. Erforderliche IAM-Policys für die Verbindung einrichten: Die Administratoren richten IAM-Policys ein, damit die Verbindung hergestellt werden kann.
  4. Verbindung herstellen: Der Requestor verbindet die beiden LPGs.
  5. Routentabellen aktualisieren: Jeder Administrator aktualisiert die Routentabellen seines VCN, um den Traffic zwischen den Peer-VCNs wie gewünscht zu ermöglichen.
  6. Sicherheitsregeln aktualisieren: Jeder Administrator aktualisiert die Sicherheitsregeln seines VCN, um den Traffic zwischen den Peer-VCNs wie gewünscht zu ermöglichen.

Gegebenenfalls können Administratoren die Aufgaben E und F vor dem Verbindungsaufbau ausführen. In diesem Fall muss jeder Administrator den CIDR-Block oder bestimmte Subnetze aus dem VCN der jeweils anderen Seite kennen und diese in Aufgabe B gemeinsam verwenden. Nach dem Herstellen der Verbindung können Sie auch den CIDR-Block des anderen VCN abrufen, indem Sie die entsprechenden LPG-Details in der Konsole anzeigen. Suchen Sie nach Von Peer angebotenes CIDR. Wenn Sie die API verwenden, suchen Sie nach dem Parameter peerAdvertisedCidr.

Außerdem müssen Sie einige IAM-Einstellungen wie Gruppen vorkonfigurieren, bevor Sie den schrittweisen Prozess durchlaufen.

Aufgabe A: LPGs erstellen

Anweisungen hierzu finden Sie unter Lokales Peering-Gateway erstellen.

Aufgabe B: Informationen freigeben

Als Requestor müssen Sie dem Acceptor die folgenden Informationen bereitstellen (beispielsweise per E-Mail oder über eine andere Out-of-Band-Methode):

  • Wenn sich die VCNs in demselben Mandanten befinden: Name der IAM-Gruppe, der die Berechtigung zum Erstellen einer Verbindung im Compartment des Acceptors erteilt werden soll. Im Beispiel der nächsten Aufgabe ist dies die Gruppe "RequestorGrp".
  • Wenn sich die VCNs in unterschiedlichen Mandanten befinden: OCID für Ihren Mandanten und OCID für die IAM-Gruppe, der die Berechtigung zum Erstellen einer Verbindung im Compartment des Acceptors erteilt werden soll. Im Beispiel der nächsten Aufgabe ist dies die OCID für die "RequestorGrp".
  • Optional: Das CIDR Ihres VCN oder bestimmte Subnetze für das Peering mit dem anderen VCN.

Als Acceptor müssen Sie dem Requestor folgende Informationen bereitstellen:

  • Wenn sich die VCNs in demselben Mandanten befinden: OCID für Ihr LPG. Optional können Sie auch die Namen des VCN, des LPG und des Compartments, in dem sich diese befinden, bereitstellen.
  • Wenn sich die VCNs in unterschiedlichen Mandanten befinden: OCID für Ihr LPG und OCID für Ihren Mandanten.
  • Optional: Das CIDR Ihres VCN oder bestimmte Subnetze für das Peering mit dem anderen VCN.
Aufgabe C: IAM-Policys einrichten

Wenn sich beide VCNs in demselben Mandanten befinden, verwenden Sie die Policy im Lokalen Peering mit einem LPG (VCNs im selben Mandanten).

Wenn sich die VCNs in verschiedenen Mandanten befinden, verwenden Sie die Policy in Lokales Peering mit einem LPG (VCNs in verschiedenen Mandanten).

Aufgabe E: Routentabellen konfigurieren

Konfigurieren Sie die Routentabellen so, dass sie die Informationen für das andere VCN verwenden, das Sie unter Aufgabe B: Informationen zum Teilen angegeben haben. Verwenden Sie dazu die Anweisungen unter VCN-Routentabellen zur Verwendung eines LPG konfigurieren.

Aufgabe F: Sicherheitsregeln konfigurieren

Konfigurieren Sie die Sicherheitsregeln so, dass die Informationen für das andere VCN verwendet werden, das Sie unter Aufgabe B: Informationen zum Teilen angegeben haben. Verwenden Sie dazu die Anweisungen unter Sicherheitsregeln für die Verwendung eines LPG konfigurieren.