Remote-VCN-Peering über ein upgegradetes DRG
In diesem Thema wird Remote-VCN-Peering behandelt.
In diesem Fall bedeutet Remote, dass die virtuellen Cloud-Netzwerke (VCNs) jeweils an ein anderes dynamisches Routinggateway (DRG) angehängt sind und dass sich das DRG in einer anderen Region oder möglicherweise in derselben Region befindet. Wenn sich die VCNs, die Sie verbinden möchten, in derselben Region befinden und mit demselben DRG verbunden sind, lesen Sie Lokales VCN-Peering über ein upgegradetes DRG.
Dieses Szenario ist für ein upgegradetes oder Legacy-DRG verfügbar, mit der Ausnahme, dass Legacy-DRGs das Verbinden von DRGs in verschiedenen Mandanten oder das Anhängen mehrerer VCNs nicht unterstützen. Weitere Informationen zu den DRG-Versionen finden Sie unter DRG-Versionen.
Bevor Sie dieses Szenario implementieren, müssen Sie Folgendes sicherstellen:
- VCN A ist an DRG A angehängt
- VCN B ist an DRG B angehängt
- Routingkonfiguration in beiden DRGs verwendet Standardroutentabellen
- Angemessene IAM-Berechtigungen werden für VCNs angewendet, die sich entweder in demselben oder in verschiedenen Mandanten befinden.
Remote-VCN-Peering - Überblick
Mit Remote-VCN-Peering wird eine Verbindung zwischen zwei VCNs in verschiedenen Regionen aufgebaut. Mit dem Peering können die Ressourcen der VCNs mit privaten IP-Adressen kommunizieren, ohne den Traffic über das Internet oder über ein On-Premise-Netzwerk zu leiten. Die VCNs können sich entweder im selben oder in verschiedenen Oracle Cloud Infrastructure-Mandanten befinden. Ohne Peering benötigt ein VCN ein Internetgateway und öffentliche IP-Adressen für die Instanzen, die mit einem anderen VCN in einer andere Region kommunizieren müssen.
Netzwerkkomponenten für Remote-Peering - Übersicht
Auf hoher Ebene sind folgende Networking-Servicekomponenten für ein Remote-Peering erforderlich:
-
Zwei VCNs mit CIDRs, die sich nicht überschneiden, in verschiedenen Regionen.
Hinweis
Keine VCN-CIDRs dürfen sich überschneiden.
Die beiden VCNs in der Peering-Beziehung dürfen keine sich überschneidenden CIDRs aufweisen. Wenn ein bestimmtes VCN über mehrere Peering-Beziehungen verfügt, dürfen diese anderen VCNs keine CIDRs aufweisen, die sich überschneiden. Beispiel: Wenn VCN-1 mit VCN-2 und VCN-3 in einer Peering-Beziehung steht, dürfen sich die CIDRs von VCN-2 und VCN-3 nicht überschneiden.
Wenn Sie dieses Szenario konfigurieren, müssen Sie diese Anforderung in der Planungsphase erfüllen. Routingprobleme treten wahrscheinlich auf, wenn sich CIDRs überschneiden. Sie werden jedoch nicht daran gehindert, mit der Konsole oder API-Vorgängen eine Konfiguration zu erstellen, die Probleme verursacht.
- Ein an jedes VCN in der Peering-Beziehung angehängtes dynamisches Routinggateway (DRG). Ein VCN verfügt bereits über ein DRG, wenn Sie einen Site-to-Site-VPN-IPSec-Tunnel oder einen privaten Virtual Circuit von Oracle Cloud Infrastructure FastConnect verwenden.
- Eine Remote-Peering-Verbindung (RPC) auf jedem DRG in der Peering-Beziehung.
- Eine Verbindung zwischen diesen beiden RPCs.
- Unterstützende Routingregeln, die den Traffic über die Verbindung und gegebenenfalls nur zwischen den ausgewählten Subnetzen in den jeweiligen VCNs zulassen.
- 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 VCN kann mit den verbundenen RPCs nur VNICs im anderen VCN oder in einem On-Premise-Netzwerk erreichen, wenn das DRG eine Verbindung zu einem On-Premise-CPE herstellt. 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. Weitere Informationen finden Sie unter Wichtige Auswirkungen von Peering.
Wichtige Auswirkungen von 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.
Beim Peering von VCNs in verschiedenen Mandanten treten einige Komplikationen mit Berechtigungen auf, die in beiden Mandanten gelöst werden müssen. Einzelheiten zu den erforderlichen Berechtigungen finden Sie unter IAM-Policys für Routing zwischen VCNs.
Spoke-zu-Spoke: Remote-Peering mit Transitrouting (nur Legacy-DRGs)
Das in diesem Abschnitt genannte Szenario wird weiterhin unterstützt. Es wird jedoch empfohlen, die unter Traffic über eine zentrale virtuelle Netzwerk-Appliance weiterleiten beschriebene DRG-Transitroutingmethode zu verwenden.
Nehmen wir an, dass Sie in jeder Region über mehrere VCNs in einem Hub-and-Spoke-Layout verfügen, wie im folgenden Diagramm dargestellt. Dieser Layouttyp in einer Region wird unter Transitrouting in einem Hub-VCN ausführlich beschrieben. Die Spoke-VCNs in einer Region werden per lokalem Peering mit dem Hub-VCN in derselben Region über lokale Peering-Gateways verbunden.
Sie können Remote-Peering zwischen den beiden Hub-VCNs einrichten. Anschließend können Sie außerdem Transitrouting für das DRG und die LPGs des Hub-VCN einrichten, wie unter Transitrouting in einem Hub-VCN erläutert. Mit diesem Setup können Spoke-VCN in einer Region mit einem oder mehreren Spoke-VCNs in der anderen Region kommunizieren, ohne dass eine Remote-Peering-Verbindung direkt zwischen diesen VCNs benötigt wird.
Beispiel: Sie können das Routing so konfigurieren, dass Ressourcen in VCN-1-A über die Hub-VCNs mit Ressourcen in VCN-2-A und VCN-2-B kommunizieren können. Auf diese Weise benötigt VCN 1-A kein separates Remote-Peering mit den einzelnen Spoke-VCNs in der anderen Region. Sie können das Routing auch so einrichten, dass VCN-1-B mit den Spoke-VCNs in Region 2 kommunizieren kann, ohne dass dazu eigene Remote-Peering-Verbindungen erforderlich sind.
Spoke-zu-Spoke: Remote-Peering mit Transitrouting (upgegradetes DRG)
Im Szenario in diesem Abschnitt wird die DRG-Transitroutingmethode verwendet, die unter Traffic über eine zentrale Netzwerk-Virtual Appliance weiterleiten beschrieben wird.
Nehmen wir an, dass Sie in jeder Region über mehrere VCNs in einem Hub-and-Spoke-Layout verfügen, wie im folgenden Diagramm dargestellt. Dieser Layouttyp in einer Region wird unter Transitrouting in einem Hub-VCN ausführlich beschrieben. Die Spoke-VCNs in der Region werden lokal per Peering mit dem Hub-DRG/VCN-Paar in derselben Region durch gegenseitige Verbindung zum DRG verbunden.
Sie können Remote-Peering zwischen zwei Hub-VCNs einrichten. Anschließend können Sie auch Transitrouting für das DRG des Hub-VCN einrichten, wie unter Traffic über eine virtuelle zentrale Netzwerk-Appliance weiterleiten beschrieben. Mit diesem Setup können Spoke-VCN in einer Region mit einem oder mehreren Spoke-VCNs in der anderen Region kommunizieren, ohne dass eine Remote-Peering-Verbindung direkt zwischen diesen VCNs benötigt wird.
Beispiel: Sie können das Routing so konfigurieren, dass Ressourcen in VCN-1-A über die Hub-VCNs mit Ressourcen in VCN-2-A und VCN-2-B kommunizieren können. Auf diese Weise benötigt VCN 1-A kein separates Remote-Peering mit den einzelnen Spoke-VCNs in der anderen Region. Sie können das Routing auch so einrichten, dass VCN-1-B mit den Spoke-VCNs in Region 2 kommunizieren kann, ohne dass dazu eigene Remote-Peering-Verbindungen erforderlich sind.
Wichtige Konzepte für das Remote-Peering
Die folgenden Konzepte helfen Ihnen dabei, die Grundlagen von VCN-Peering zu verstehen und ein Remote-Peering einzurichten.
- PEERING
- Beim Peering handelt es sich um eine einzelne Peering-Beziehung zwischen zwei VCNs. Beispiel: Wenn VCN-1 per Peering mit zwei anderen VCNs verbunden ist, sind zwei Peerings vorhanden. Der Remote-Teil des Remote-Peerings gibt an, dass die VCNs sich in verschiedenen Regionen befinden. Bei dieser Methode des Remote-Peerings können sich die VCNs in demselben Mandanten oder in verschiedenen Mandanten befinden.
- VCN-ADMINISTRATOREN
- Im Allgemeinen kann VCN-Peering nur dann stattfinden, wenn beide VCN-Administratoren dem zustimmen. In der Praxis müssen die beiden Administratoren:
- ACCEPTOR UND REQUESTOR
- Um die für ein Peering erforderlichen IAM-Policys zu implementieren, müssen die beiden VCN-Administratoren einen Administrator als Requestor und den anderen als Acceptor auswählen. Der Requestor ist derjenige, der die Anforderung zum Verbinden der beiden RPCs initiieren kann. Der Acceptor erstellt wiederum eine bestimmte IAM-Policy, die dem Requestsor die Berechtigung zum Verbinden zu den RPCs im Compartment des Acceptors erteilt. Ohne diese Policy wird die Anforderung des Requestors zum Verbinden nicht erfolgreich sein.
- REGIONSABONNEMENT
- Um eine Peering mit einem VCN in einer anderen Region erstellen zu können, benötigt ein Mandant zunächst ein Abonnement für diese Region. Informationen zum Abonnieren finden Sie unter Regionen verwalten.
- REMOTE-PEERING-VERBINDUNG (RPC)
- Eine Remote-Peering-Verbindung (RPC) ist eine Komponente, die Sie in dem an das VCN angehängten DRG erstellen. Die RPC dient als Verbindungspunkt für ein per Remote-Peering angebundenes VCN. Bei der Konfiguration der VCNs muss jeder Administrator eine RPC für das DRG auf dem VCN erstellen. Ein DRG muss für jedes Remote-Peering, das es für das VCN einrichtet, jeweils eine separate RPC enthalten. Im Falle des vorherigen Beispiels würde dies Folgendes bedeuten: Das DRG auf VCN-1 hätte zwei RPCs für das Peering mit zwei anderen VCNs. In der API ist eine RemotePeeringConnection ein Objekt, das Informationen zum Peering enthält. Eine RPC kann nicht für die Einrichtung eines anderen Peerings wiederverwendet werden.
- VERBINDUNG ZWISCHEN ZWEI RPCS
- Wenn der Requestor die Anforderung an den Peer (in der Konsole oder API) initiierte, fordert er die andere Seiten auf, die beiden RPCs zu verbinden. Der Requestor muss Informationen zur Identifizierung jeder RPC haben (wie Region und OCID der RPC).
- 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. 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 DRG leitet Traffic, der mit dieser Regel übereinstimmt, an das andere DRG weiter, das den Traffic dann zum nächsten Hop im anderen VCN weiterleitet.
-
Callout 1: Routentabelle von Subnetz A Ziel-CIDR Routenziel 0.0.0.0/0 Internetgateway 192.168.0.0/16 DRG-1 Callout 2: Routentabelle von Subnetz X Ziel-CIDR Routenziel 10.0.0.0/16 DRG-2 - 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.
Wichtige Auswirkungen von 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.
Remote-Peering einrichten
In diesem Abschnitt wird der allgemeine Prozess zum Einrichten von Peering zwischen zwei VCNs in verschiedenen Regionen behandelt.
Bei dem folgenden Verfahren wird Folgendes vorausgesetzt:
- Der Mandant hat ein Abonnement für die Region des anderen VCN. Ist das nicht der Fall, lesen Sie Regionen verwalten.
- Sie haben bereits ein VCN an das DRG angehängt. Ist dies nicht der Fall, lesen Sie Dynamische Routinggateways.
- Sie haben bereits die erforderlichen IAM-Policys für die Verbindung eingerichtet. IAM-Policys für Remote-Peering in demselben Mandanten und zwischen Mandanten unterscheiden sich. Siehe IAM-Policys für das Routing zwischen VCNs
Überblick über die erforderlichen Schritte:
- RPCs erstellen: Jeder VCN-Administrator erstellt eine RPC für das eigene VCN-DRG.
- Informationen gemeinsam verwenden: Die Administratoren verwenden die grundlegenden erforderlichen Informationen gemeinsam.
- Verbindung herstellen: Der Requestor verbindet die beiden RPCs (unter Wichtige Konzepte für das Remote-Peering finden Sie Definitionen für Requestor und Acceptor).
- Routentabellen aktualisieren: Jeder Administrator aktualisiert die Routentabellen seines VCN, um den Traffic zwischen den Peer-VCNs wie gewünscht zu ermöglichen.
- Sicherheitsregeln aktualisieren: Jeder Administrator aktualisiert die Sicherheitsregeln ihres VCN, um den Traffic zwischen den Peer-VCNs wie gewünscht zu ermöglichen.
Gegebenenfalls können Administratoren die Aufgaben 4 und 5 ausführen, bevor die Verbindung hergestellt wird. Jeder Administrator muss den CIDR-Block oder bestimmte Subnetze aus dem VCN der jeweils anderen Seite kennen und diese in Aufgabe 2 weitergeben.
Jeder Administrator erstellt eine RPC für sein eigenes VCN-DRG. Mit "Sie" ist in der folgenden Prozedur ein Administrator (Acceptor oder Requestor) gemeint.
Erforderliche IAM-Policy zum Erstellen von RPCs
Wenn die Administratoren bereits über umfassende Netzwerkadministratorberechtigungen verfügen (siehe Verwalten eines Cloud-Netzwerks durch Netzwerkadministratoren zulassen), sind sie dazu berechtigt, RPCs zu erstellen, zu aktualisieren und zu löschen. Ansonsten sehen Sie hier eine Beispiel-Policy, die die erforderlichen Berechtigungen für eine Gruppe mit dem Namen "RPCAdmins" bereitstellt. Die zweite Anweisung ist erforderlich, da sich das Erstellen einer RPC auf das DRG auswirkt, zu dem sie gehört. Daher muss der Administrator über eine Berechtigung zum Verwalten von DRGs verfügen.
Allow group RPCAdmins to manage remote-peering-connections in tenancy
Allow group RPCAdmins to manage drgs in tenancy
- Bestätigen Sie in der Konsole, dass Sie das Compartment mit dem DRG anzeigen, dem Sie die RPC hinzufügen möchten. Informationen über die Compartments und Zugriffskontrolle finden Sie unter Zugriffskontrolle.
- Öffnen Sie das Navigationsmenü , und wählen Sie Networking aus. Wählen Sie unter Kundenkonnektivität die Option Dynamisches Routinggateway aus.
- Wählen Sie das DRG aus, an dem Sie interessiert sind.
- Wählen Sie unter Ressourcen die Option Remote-Peering-Verbindungen - Anhänge aus.
- Wählen Sie Remote-Peering-Verbindung erstellen aus.
-
Geben Sie Folgendes ein:
- Name: Ein benutzerfreundlicher Name für die RPC. Er muss nicht eindeutig sein und kann später in der Konsole nicht geändert werden (Sie können ihn jedoch mit der API ändern). Geben Sie keine vertraulichen Informationen ein.
- Erstellen in Compartment: Das Compartment, In dem Sie die RPC erstellen möchten, wenn es sich von dem Compartment unterscheidet, in welchem Sie arbeiten.
-
Wählen Sie Remote-Peering-Verbindung erstellen aus.
Anschließend wird die RPC auf der Seite Remote-Peering-Verbindungen im ausgewählten Compartment erstellt und angezeigt.
- Notieren Sie sich als Acceptor die Region und die OCID der RPC, um sie später dem Requestor mitteilen zu können.
- Wenn sich die beiden VCNs in unterschiedlichen Mandanten befinden, zeichnen Sie die OCID dieses Mandanten auf (befindet sie sich im unteren Bereich der Seite in der Konsole). Geben Sie die OCID später an den anderen Administrator weiter.
Diese Aufgabe ist spezifisch für eine mandantenübergreifende Verbindung. Wenn sich die Verbindung im selben Mandanten befindet, können Sie zur nächsten Aufgabe wechseln.
-
Als Acceptor müssen Sie dem Requestor die folgenden Informationen bereitstellen (beispielsweise per E-Mail oder über eine andere Out-of-Band-Methode):
- Die Region, in der das VCN sich befindet (der Mandant des Requestors muss ein Abonnement für diese Region haben).
- Die OCID der RPC.
- Die CIDR-Blöcke für Subnetze in dem VCN, das für das andere VCN verfügbar sein soll. Der Requestor benötigt diese Informationen beim Einrichten des Routings für sein VCN.
- Wenn sich die VCNs in verschiedenen Mandanten befinden: die OCID für den Empfängermandanten.
-
Als Requestor müssen Sie dem Acceptor die folgenden Informationen bereitstellen:
- Die Region, in der das VCN sich befindet (der Mandant des Acceptors muss ein Abonnement für diese Region haben).
- Wenn sich die VCNs in demselben Mandanten befinden: Der Name der IAM-Gruppe, die berechtigt ist, eine Verbindung im Compartment des Acceptors zu erstellen.
- Wenn sich die VCNs in verschiedenen Mandanten befinden: die OCID für den Anforderermandanten.
- Die CIDR-Blöcke für Subnetze in dem VCN, das für das andere VCN verfügbar sein soll. Der Acceptor benötigt diese Informationen beim Einrichten des Routings für sein VCN.
Der Requestor führt diese Aufgabe aus.
Voraussetzung: Der Requestor muss Folgendes haben:
- Die Region, in der sich das VCN des Acceptors befindet (der Mandant des Requestors muss ein Abonnement der Region besitzen).
- Die OCID der RPC des Acceptors.
- Die OCID des Mandanten des Acceptors (nur wenn sich das VCN des Acceptors in einem anderen Mandanten befindet)
Weitere Informationen finden Sie unter Zwei Remote-Peering-Verbindungen verbinden. Weitere Aufgaben im Zusammenhang mit RPCs werden unter Remote-Peering-Management beschrieben.
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 anderen VCN kennen.
Entscheiden Sie für jedes VCN, welche Subnetze im lokalen VCN mit dem anderen VCN kommunizieren müssen. Aktualisieren Sie dann die Routentabelle für jedes dieser Subnetze, um eine neue Regel aufzunehmen, die Traffic, der für das andere VCN bestimmt war, an das lokale DRG weiterleitet. Siehe Regeln einer VCN-Routentabelle aktualisieren, und fügen Sie eine Routingregel hinzu, die folgende Einstellungen verwendet:
- Zieltyp: Dynamisches Routinggateway. Das angehängte DRG des VCN wird automatisch als Ziel ausgewählt, sodass Sie es nicht selbst angeben müssen.
- Ziel-CIDR-Block: Der CIDR-Block des anderen VCN. Im Beispiel werden VCNs mit 10.0.0.0/16 und 192.68.0.0/16 verwendet. Gegebenenfalls können Sie ein Subnetz oder eine bestimmte CIDR-Untergruppe des Peer-VCN angeben.
- Beschreibung: Eine optionale Beschreibung der Regel.
Jeder Subnetztraffic mit einem Ziel, das der Regel entspricht, wird an das lokale DRG weitergeleitet. Weitere Informationen zum Einrichten von Routingregeln finden Sie unter VCN-Routentabellen.
Ohne das erforderliche Routing fließt der Traffic nicht zwischen den DRG-Peers. Wenn eine Situation auftritt, in welcher Sie das Peering vorübergehend stoppen müssen, können Sie die Routingregeln, die den Traffic zulassen, entfernen. Die RPCs müssen nicht gelöscht werden.
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. Im Allgemeinen verwenden Sie denselben CIDR-Block, den Sie in der Routentabellenregel in Aufgabe D: Routentabellen konfigurieren verwendet haben.
Es wird empfohlen, die folgenden Regeln hinzuzufügen:
- Ingress-Regeln für den Traffictyp, den Sie aus dem CIDR oder spezifischen Subnetzen des anderen VCN zulassen möchten. Im Beispiel werden VCNs mit 10.0.0.0/16 und 192.68.0.0/16 verwendet.
- 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. Als Nächstes aktualisieren Sie die Sicherheitsliste für jedes dieser Subnetze so, dass Regeln enthalten sind, die den beabsichtigten Egress- oder Ingress-Traffic mit dem CIDR-Block oder Subnetz des anderen VCN zulassen. Weitere Informationen finden Sie unter Regeln in einer Sicherheitsliste aktualisieren und Sicherheitslisten erstellen (Details zu den Optionen, die für Sicherheitsregeln verfügbar sind).
Allgemeine Informationen zu Sicherheitsregeln finden Sie unter Sicherheitsregeln.