Remote-VCN-Peering mit einem Legacy-DRG
In diesem Thema wird Remote-VCN-Peering behandelt. Remote bedeutet in diesem Fall, dass sich die VCNs in verschiedenen Regionen befinden.Wenn sich die zu verbindenden VCNs in derselben Region befinden, lesen Sie Lokales VCN-Peering mit lokalen Peering-Gateways.
In diesem Artikel wird davon ausgegangen, dass das DRG ein Legacy-DRG ist. Für alle upgegradeten DRGs wird die unter Remote-VCN-Peering über ein upgegradetes DRG beschriebene Methode empfohlen. Eine Erläuterung der DRG-Versionen finden Sie unter DRG-Versionen.
Remote-VCN-Peering - Überblick
Mit Remote-VCN-Peering wird das Verbinden zweier VCNs in verschiedenen Regionen (jedoch mit demselben Mandanten ) bezeichnet. Mit 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. 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, die Remote-Peering unterstützen.
Hinweis
Es darf zu keinen Überschneidungen der VCN-CIDRs kommen
Die CIDRs der beiden VCNs in der Peering-Beziehung dürfen sich nicht überschneiden. Wenn ein bestimmtes VCN über verschiedene Peering-Beziehungen verfügt, dürfen sich CIDRs dieser anderen VCNs ebenfalls nicht ü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.
- 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 von und in 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 jeweils VNICs in dem anderen VCN oder einem On-Premise-Netzwerk und keine Ziele außerhalb der VCNs, wie das Internet, erreichen. 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.
Spoke-zu-Spoke: Remote-Peering mit Transitrouting
Das in diesem Abschnitt erwähnte Szenario wird weiterhin unterstützt, ist jedoch veraltet. Es wird empfohlen, die unter Traffic über eine zentrale virtuelle Netzwerk-Appliance weiterleiten beschriebene DRG-Transitrouting-Methode 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 bestimmte 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 kann ein Spoke-VCN in einer Region mit einem oder mehreren Spoke-CNs 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.
Explizite Zustimmung von beiden Seiten erforderlich
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 des eigenen VCN implementiert.
Wichtige Konzepte für das Remote-Peering
Die folgenden Konzepte helfen Ihnen dabei, die Grundlagen von 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 sind, sind zwei Peers vorhanden. Der Remote-Teil des Remote-Peerings gibt an, dass die VCNs sich in verschiedenen Regionen befinden.
- 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:
- 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 Initiiert. 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 ein 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 bestimmtes DRG muss für jedes Remote-Peering, das es für das VCN einrichtet, 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. Dies bedeutet, dass der Requestor Informationen zur Identifizierung jeder RPC haben muss (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 3: Routentabelle von Subnetz A Ziel-CIDR Routenziel 0.0.0.0/0 Internetgateway 192.168.0.0/16 DRG-1 Callout 4: 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, um den Traffic zuzulassen.
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.
RemotePeering einrichten
In diesem Abschnitt wird der allgemeine Prozess zum Einrichten eines Peerings zwischen zwei VCNs in verschiedenen Regionen beschrieben.
Bei dem folgenden Verfahren wird Folgendes vorausgesetzt:
- Dieser Mandant hat ein Abonnement für die Region des anderen VCN. Ist dies nicht der Fall, lesen Sie Regionen verwalten.
- An das VCN ist bereits ein DRG angehängt. Ist dies nicht der Fall, lesen Sie Dynamische Routinggateways.
- 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.
- Erforderliche IAM-Policys für die Verbindung einrichten: Die Administratoren richten IAM-Policys ein, damit die Verbindung hergestellt werden kann.
- 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 seine VCN-Routentabellen, um Traffic zwischen den Peer-VCNs oder Subnetzen zu aktivieren.
- Sicherheitsregeln aktualisieren: Jeder Administrator aktualisiert seine VCN-Sicherheitsregeln, um Traffic zwischen den Peer-VCNs oder Subnetzen zu aktivieren.
Gegebenenfalls können Administratoren vor dem Verbindungsaufbau die Aufgaben E und F ausführen. Jeder Administrator muss den CIDR-Block oder bestimmte Subnetze aus dem anderen VCN kennen und diese in Aufgabe B gemeinsam verwenden.
Jeder Akzeptor- oder Anfordereradministrator erstellt eine RPC für das DRG seines eigenen VCN.
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
Allgemeine Anweisungen zum Erstellen und Arbeiten mit RPCs finden Sie unter Remote-Peering-Verbindung erstellen und Remote-Peering-Verwaltung. Wenn Sie der Acceptor sind, notieren Sie die Region und OCID der RPC, und geben Sie diese Informationen an den Requestor weiter. Wenn sich die beiden VCNs in unterschiedlichen Mandanten befinden, muss jeder Administrator seine Mandanten-OCID (die ganz unten auf der Seite in der Konsole zu finden ist) aufzeichnen und diese Informationen dem anderen Administrator mitteilen.
Wenn sich beide VCNs in demselben Mandanten, aber in verschiedenen Regionen befinden, verwenden Sie die unter Remote-Peering mit einem Legacy-DRG angegebenen Policys.
Wenn sich beide VCNs in unterschiedlichen Mandanten, aber in derselben Region befinden, verwenden Sie die unter An VCNs in anderen Mandanten anhängen angegebenen Policys.
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.
Allgemeine Anweisungen finden Sie unter Remote-Peering-Verbindung erstellen, und verwenden Sie die Informationen, die für den Acceptor bereitgestellt werden. Allgemeine Anweisungen zum Arbeiten mit RPCs finden Sie unter Remote-Peering-Management.
Wie vorher erwähnt, kann jeder Administrator diese Aufgabe vor oder nach dem Herstellen der Verbindung ausführen.
Voraussetzung: Jeder Administrator muss den VCN-CIDR-Block oder den CIDR-Block für bestimmte Subnetze im anderen VCN haben.
Entscheiden Sie für jedes VCN, welche Subnetze im VCN mit dem anderen VCN kommunizieren müssen, und aktualisieren Sie die Routentabelle (siehe Regeln einer VCN-Routentabelle aktualisieren) für jedes dieser Subnetze, um eine neue Routingregel aufzunehmen, die Traffic, der für das andere VCN bestimmt ist, an das DRG weiterleitet:
- 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. 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 die DRG weitergeleitet. Weitere Informationen zu VCN-Routentabellen und -regeln finden Sie unter VCN-Routentabellen.
Ohne das erforderliche Routing fließt der Traffic nicht zwischen den DRG-Peers. Wenn eine Situation auftritt, in dem Sie das Peering vorübergehend stoppen müssen, müssen Sie die Routingregeln, die den Traffic zulassen, vorübergehend 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 kennen, die er gemeinsam mit dem anderen VCN verwenden kann. 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 die Traffiktypen, die Sie aus dem anderen VCN zulassen möchten, entweder aus dem CIDR des VCN oder nur bestimmten Subnetzen.
- Egress-Regel, um abgehenden Traffic vom lokalen VCN zum anderen VCN zuzulassen. Wenn das Subnetz bereits eine umfassende Egress-Regel für alle Protokolltyp an alle Ziele (z.B. 0.0.0.0/0) hat, müssen Sie für das andere VCN keine spezielle Regeln 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 das lokale VCN, welche Subnetze im VCN mit dem anderen VCN kommunizieren müssen, und aktualisieren Sie die Sicherheitsliste für jedes dieser Subnetze, sodass Regeln enthalten sind, die den Egress- oder Ingress-Traffic mit dem CIDR-Block oder Subnetz des anderen VCN zulassen:
Weitere Informationen zu Sicherheitsregeln finden Sie unter Sicherheitsregeln.
Beispiel: Sie möchten eine Regel mit zustandsbehaftetem Traffic hinzufügen, die Ingress-HTTPS-Traffic (Port 443) vom CIDR des anderen VCN zulässt. Die folgenden grundlegenden Schritte werden beim Hinzufügen einer Regel ausgeführt:
- Wählen Sie im Abschnitt Regeln für Ingress zulassen die Option +Add-Regel aus.
- Lassen Sie das Kontrollkästchen zustandslos deaktiviert.
- Quelltyp: Als CIDR beibehalten.
- Quell-CIDR: Geben Sie denselben CIDR-Block ein, den die Routingregeln verwenden (siehe Aufgabe E: Routentabellen konfigurieren).
- IP-Protokoll: Behalten Sie "TCP" bei.
- Quellportbereich: Behalten Sie "Alle" bei.
- Zielportbereich: Geben Sie "443" ein.
- Beschreibung: Eine optionale Beschreibung der Regel.