Lokales VCN-Peering über ein upgegradetes DRG
In diesem Szenario wird die Verwendung einer gegenseitigen Verbindung zu einem aktualisierten DRG beschrieben, um Traffic zwischen zwei oder mehr VCNs zu ermöglichen.
Überblick
Anstatt lokale Peering-Verbindungen zu verwenden, können Sie private Netzwerkkommunikation zwischen zwei oder mehr virtuellen Cloud-Netzwerken (VCNs) in derselben Region einrichten, indem sie diese an ein gemeinsames dynamisches Routinggateway (DRG) anhängen und die entsprechenden Änderungen an VCN- und DRG-Routentabellen vornehmen.
Dieses Szenario ist nur für ein upgegradetes DRG verfügbar.
Wenn sie das Legacy-DRG verwenden, können Sie zwei VCNs in derselben Region mit lokalen Peering-Gateways (LPG) Peering durchführen, wie im Szenario Lokales VCN-Peering mit lokalen Peering-Gateways beschrieben. Durch das Peering zweier VCNs in derselben Region über ein DRG erhalten Sie mehr Routingflexibilität und vereinfachte Verwaltung. Jedoch erhöht sich die Latenz um die Kosten von Mikrosekunden, weil der Traffic über einen virtuellen Router, das DRG, geleitet werden.
In diesem Beispielszenario wird Peering zwischen zwei VCNs eingerichtet. Bevor Sie dieses Szenario implementieren, stellen Sie Folgendes sicher:
- VCN-A ist keinem DRG zugeordnet
- VCN-B ist keinem DRG zugeordnet
- Die von VCN-A und VCN-B verwendeten CIDRs überschneiden sich nicht
Das Peering der VCNs in verschiedenen Mandanten erfordert mehr IAM-Policys für die mandantenübergreifende Autorisierung. Einzelheiten zu den erforderlichen Berechtigungen finden Sie unter IAM-Policys für das Routing zwischen VCNs. Wenn Sie ein VCN in einer anderen Region an ein DRG anschließen, führen Sie die Schritte unter DRG in einem anderen Mandanten an ein VCN anhängen aus. Die meisten Schritte in diesem Szenario gehen davon aus, dass sich das DRG und beide VCNs im selben Mandanten befinden.
Schritte
Im Folgenden wird der allgemeine Prozess zum Einrichten eines Peerings zwischen zwei VCNs in derselben Region mit einem DRG beschrieben:
- DRG erstellen: Siehe Task A: DRG erstellen.
- VCN A an das DRG anhängen: Siehe Aufgabe B: VCN-A an das DRG anhängen.
- VCN B an das DRG anhängen: Siehe Aufgabe C: VCN-B an das DRG anhängen.
- Routentabellen in VCN A konfigurieren, um Traffic, der für das CIDR von VCN B bestimmt ist, an das DRG zu senden: Siehe Aufgabe D: Routentabellen in VCN-A konfigurieren, um Traffic, der für das CIDR von VCN-B bestimmt ist, an den DRG-Anhang zu senden.
- Routentabellen in VCN B konfigurieren, um Traffic, der für das CIDR von VCN A bestimmt ist, an das DRG zu senden: Siehe Aufgabe E: Routentabellen in VCN-B konfigurieren, um Traffic, der für das CIDR von VCN-A bestimmt ist, an den DRG-Anhang zu senden.
- Sicherheitsregeln aktualisieren: Aktualisieren Sie die Sicherheitsregeln jedes VCN, um den gewünschten Traffic zwischen den Peer-VCNs zu aktivieren. Siehe Aufgabe F: Sicherheitsregeln aktualisieren.
Auf dieser Seite werden einige Auswirkungen auf die Zugriffskontrolle, Sicherheit und Performance von Peer-VCNs zusammengefasst. Sie können den Zugriff und den Traffic zwischen zwei Peer-VCNs mit IAM-Policys, Routentabellen in jedem VCN, Routentabellen im DRG und Sicherheitslisten in jedem VCN kontrollieren.
Übersicht der Networking-Komponenten für Peering über ein DRG
Allgemein erforderliche Networking-Servicekomponenten für ein lokales Peering über ein DRG:
- Zwei VCNs in derselben Region mit CIDRs, die sich nicht überschneiden
- Ein einzelnes Dynamisches Routinggateway (DRG), das an jedes Peer-VCN angehängt ist
- 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.
Ein bestimmtes VCN kann folgende 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
Zwei mit einem DRG verbundene VCNs können andere Cloud-Gateways (wie ein Internetgateway oder NAT-Gateway) nicht erreichen, es sei denn, das Transitrouting über ein LPG wird übertragen. Beispiel: Wenn VCN-1 im vorherigen Diagramm ein Internetgateway hätte, könnten die Instanzen in VCN-2 das nicht zum Senden von Traffic an Endpunkte im Internet verwenden. VCN-2 könnte jedoch Traffic vom Internet über VCN-1 empfangen. Weitere Informationen finden Sie unter Wichtige Auswirkungen von VCN-Peering.
Wichtige Konzepte für das lokale Peering
Die folgenden Konzepte helfen Ihnen dabei, die Grundlagen von VCN-Peering in Verbindung mit einem DRG zu verstehen und ein lokales Peering einzurichten.
- PEERING
- Ein Peering ist eine Beziehung zwischen zwei VCNs, die beide mit demselben DRG verbunden ist und Traffic gegenseitig weiterleiten können. Der lokale Teil des lokalen Peerings gibt an, dass die VCNs sich in derselben Region befinden. Ein bestimmtes DRG kann jeweils maximal 300 lokale DRG-Anhänge aufweisen.
- Administratoren
- Im Allgemeinen kann VCN-Peering nur dann stattfinden, wenn alle beteiligten VCN-Administratoren und DRG-Administratoren dem zustimmen. Je nach Situation kann ein einzelner Administrator für alle beteiligten VCNs, VCNs und zugehörigen Policys zuständig sein.
- ROUTING ZUM DRG
- 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 ist dies genauso, wie beim Einrichten von 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 DRG als Ziel an. Das VCN leitet Traffic, der mit dieser Regel übereinstimmt, an das DRG weiter, das den Traffic wiederum zum nächsten Hop im anderen VCN weiterleitet.
-
Callout 1: Routentabelle von Subnetz A Ziel-CIDR Routenziel 172.16.0.0/12 DRG 192.168.0.0/16 DRG 0.0.0.0/0 Internetgateway Callout 2: Routentabelle von Subnetz X Ziel-CIDR Routenziel 172.16.0.0/12 DRG 10.0.0.0/16 DRG - 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 entscheiden, welche Subnetze in seinem eigenen VCN mit VNICs in dem anderen VCN kommunizieren müssen, und dass die Sicherheitslisten des Subnetzes entsprechend aktualisiert werden.
Dieses Szenario in der Console einrichten
Ein vor Mai 2021 erstelltes DRG kann weder Routing zwischen On-Premise-Netzwerken und mehreren VCNs ausführen noch lokales Peering zwischen VCNs bereitstellen. Wenn Sie diese Funktionalität benötigen und die Schaltfläche DRG upgraden angezeigt wird, wählen Sie sie aus.
Wenn Sie auf die Schaltfläche DRG upgraden klicken, wird auch alle vorhandenen BGP-Sessions zurückgesetzt, und der Traffic vom On-Premise-Netzwerk wurde vorübergehend unterbrochen, während das DRG upgegradet wurde. Sie können das Upgrade nicht zurücksetzen.
Wenn Sie ein DRG in derselben Region wie die VCNs angeben, die Sie als Peer verwenden möchten, führen Sie die Schritte unter DRG erstellen aus.
Ein upgegradetes DRG kann an viele VCNs angehängt werden, ein VCN hingegen an nur jeweils ein DRG. Der Anhang wird automatisch in dem Compartment erstellt, das das VCN enthält. Ein VCN muss sich Nicht in demselben Compartment oder Mandanten wie das upgegradete DRG befinden.
Sie können lokale Peering-Verbindungen aus dem gesamten Netzwerkdesign beseitigen, wenn Sie mehrere VPNs in derselben Regionmit demselben DRG verbinden und die DRG-Routingtabellen entsprechend konfigurieren.
Das Peering der VCNs in verschiedenen Mandanten erfordert mehr IAM-Policys für die mandantenübergreifende Autorisierung. Einzelheiten zu den erforderlichen Berechtigungen finden Sie unter IAM-Policys für das Routing zwischen VCNs. Wenn Sie ein VCN in einer anderen Region an ein DRG anschließen, führen Sie die Schritte unter DRG in einem anderen Mandanten an ein VCN anhängen aus.
Hängen Sie VCN-A an das DRG an, das Sie in Aufgabe A erstellt haben. Sie können ein DRG an ein VCN anhängen oder ein VCN an ein DRG anhängen.
Ein DRG kann an viele VCNs angehängt werden, ein VCN hingegen an nur jeweils ein DRG. Der Anhang wird automatisch in dem Compartment erstellt, das das VCN enthält. Ein VCN muss sich nicht im selben Compartment wie das DRG befinden.
Sie können lokale Peering-Verbindungen aus dem gesamten Netzwerkdesign beseitigen, wenn Sie mehrere VPNs in derselben Regionmit demselben DRG verbinden und die DRG-Routingtabellen entsprechend konfigurieren.
Das Peering der VCNs in verschiedenen Mandanten erfordert mehr IAM-Policys für die mandantenübergreifende Autorisierung. Einzelheiten zu den erforderlichen Berechtigungen finden Sie unter IAM-Policys für das Routing zwischen VCNs. Wenn Sie ein VCN in einer anderen Region an ein DRG anschließen, führen Sie die Schritte unter DRG in einem anderen Mandanten an ein VCN anhängen aus.
Hängen Sie VCN-B an das DRG an, das Sie in Aufgabe A erstellt haben. Sie können ein DRG an ein VCN anhängen oder ein VCN an ein DRG anhängen.
Wie vorher erwähnt, kann jeder Administrator diese Aufgabe vor oder nach dem Anhängen des VCN an das DRG ausführen.
Voraussetzung: Jeder Administrator muss den CIDR-Block für das andere VCN oder für bestimmte Subnetze in diesem VCN haben.
Entscheiden Sie für VCN-A, welche Subnetze in VCN-A mit VCN-B kommunizieren müssen, und aktualisieren Sie die Routentabelle für jedes dieser Subnetze, um eine neue Regel aufzunehmen, die Traffic, der für das CIDR des anderen VCN bestimmt ist, an das DRG weiterleitet. Verwenden Sie die folgenden Einstellungen:
- Zieltyp: Dynamisches Routinggateway.
- Ziel-CIDR-Block: Der CIDR-Block von VCN-B. Gegebenenfalls können Sie ein Subnetz oder eine bestimmte CIDR-Untergruppe von VCN-B angeben.
- Ziel-Compartment: Das Compartment mit dem anderen VCN, sofern nicht das aktuelle Compartment.
- Ziel: Das in Aufgabe A erstellte DRG.
- Beschreibung: Eine optionale Beschreibung der Regel.
Jeder Subnetztraffic mit einem Ziel, das der Regel entspricht, wird an die DRG weitergeleitet. Weitere Informationen zum Einrichten von Routingregeln finden Sie unter VCN-Routentabellen.
Wenn Sie das Peering in Zukunft nicht mehr benötigen und die Peering-Beziehung beenden möchten, löschen Sie zuerst alle Routingregeln in dem VCN, die das andere VCN angeben.
Ohne das erforderliche Routing fließt der Traffic nicht zwischen den Peer-VCNs. Wenn eine Situation auftritt, in der Sie die Peering-Beziehung vorübergehend stoppen müssen, entfernen Sie die Routingregeln, die Traffic zulassen.
Wie vorher erwähnt, kann jeder Administrator diese Aufgabe vor oder nach dem Anhängen des VCN an das DRG ausführen.
Voraussetzung: Jeder Administrator muss den CIDR-Block oder bestimmte Subnetze aus dem VCN der jeweils anderen Seite kennen.
Entscheiden Sie für VCN-B, welche Subnetze in VCN-B mit VCN-A kommunizieren müssen, und aktualisieren Sie die Routentabelle für jedes dieser Subnetze, um eine neue Regel aufzunehmen, die Traffic, der für das CIDR des anderen VCN bestimmt ist, an das DRG weiterleitet. Verwenden Sie die folgenden Einstellungen:
- Zieltyp: Dynamisches Routinggateway.
- Ziel-CIDR-Block: Der CIDR-Block von VCN-A. Gegebenenfalls können Sie ein Subnetz oder eine bestimmte Untergruppe des CIDR-Blocks von VCN-A angeben.
- Ziel-Compartment: Das Compartment mit dem anderen VCN, sofern nicht das aktuelle Compartment.
- Ziel: Das in Aufgabe A erstellte DRG.
- Beschreibung: Eine optionale Beschreibung der Regel.
Jeder Subnetztraffic mit einem Ziel, das der Regel entspricht, wird an die DRG weitergeleitet. Weitere Informationen zum Einrichten von Routingregeln finden Sie unter VCN-Routentabellen.
Wenn Sie das Peering später nicht mehr benötigen und die Peering-Beziehung beenden möchten, löschen Sie alle Routingregeln in dem VCN, die das andere VCN als Ziel angeben.
Ohne das erforderliche Routing fließt der Traffic nicht zwischen den Peer-VCNs. Wenn Sie das Peering jemals vorübergehend stoppen müssen, können Sie die Routingregeln entfernen, die Traffic aktivieren.
Wie vorher erwähnt, kann jeder Administrator diese Aufgabe vor oder nach dem Herstellen der Verbindung ausführen.
Voraussetzung: Jeder Administrator muss den CIDR-Block oder bestimmte Subnetze aus dem VCN der jeweils anderen Seite kennen. Verwenden Sie im Allgemeinen denselben CIDR-Block, den Sie in der Routentabellenregel in Aufgabe E: Routentabellen konfigurieren verwendet haben.
Fügen Sie folgende Regeln hinzu:
- Ingress-Regeln für den Traffictyp, den Sie aus dem CIDR oder spezifischen Subnetzen des anderen VCN zulassen möchten.
- Egress-Regel, um abgehenden Traffic vom lokalen VCN zum anderen VCN zuzulassen. Wenn das Subnetz bereits eine umfassende Egress-Regel für alle Protokolltypen an alle Ziele (0.0.0.0/0) hat, müssen Sie für das andere VCN keine spezielle Regel hinzufügen.
Im folgenden Verfahren werden Sicherheitslisten verwendet. Sie könnten jedoch stattdessen die Sicherheitsregeln in eine Netzwerksicherheitsgruppe implementieren und dann die Ressourcen des Subnetzes in dieser NSG erstellen.
Entscheiden Sie für jedes VCN, welche Subnetze im lokalen VCN mit dem anderen VCN kommunizieren müssen, und aktualisieren Sie die Sicherheitsliste für jedes dieser Subnetze, sodass Regeln enthalten sind, die den beabsichtigten Egress- oder Ingress-Traffic mit dem CIDR-Block oder Subnetz des anderen VCN zulassen
Um eine zustandsbehaftete Regel hinzuzufügen, die Ingress-HTTPS-(Port 443-)Traffic vom CIDR des anderen VCN zulässt, verwenden Sie die folgenden Einstellungen, um diese Regel zu implementieren:
- Lassen Sie das Kontrollkästchen zustandslos deaktiviert.
- Quelltyp: Als CIDR beibehalten.
- Quell-CIDR: Geben Sie denselben CIDR-Block an, den die Routingregeln verwenden (siehe Aufgabe D oder Aufgabe E).
- IP-Protokoll: Behalten Sie "TCP" bei.
- Quellportbereich: Behalten Sie "Alle" bei.
- Zielportbereich: Geben Sie "443" ein.
- Beschreibung: Eine optionale Beschreibung der Regel.
Weitere Informationen zu Sicherheitsregeln finden Sie unter Sicherheitsregeln.