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.
Dieser Artikel bezieht sich speziell auf die Verwendung eines Legacy-DRG. Die Informationen im Remote-VCN-Peering über ein upgegradetes DRG mit einem upgegradeten DRG sind die aktuelle Empfehlung von Oracle. Eine Aufschlüsselung der möglichen 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. Dank Peering können die VCN-Ressourcen über private IP-Adressen kommunizieren, ohne den Traffic über das Internet oder über Ihr 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 anderen 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 sich nicht überschneidenden CIDRs 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 mehrere Peering-Beziehungen verfügt, dürfen sich die 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 dynamisches Routinggateway (DRG), das an jedes VCN in der Peering-Beziehung angehängt ist. Ihr 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 jeweils nur VNICs in dem anderen VCN oder Ihrem 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 dieses 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. Oracle empfiehlt, die unter Routing von Traffic über eine virtuelle zentrale Netzwerk-Appliance beschriebene Methode für das DRG-Transitrouting zu verwenden.
Nehmen wir an, Sie besitzen in jeder Region mehrere VCNs in einem Hub-and-Spoke-Layout, 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 bestimmten 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-VCNs in der anderen Region kommunizieren, ohne dass eine Remote-Peering-Verbindung direkt zwischen diesen VCNs erforderlich ist.
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 keine separate Remote-Peering-Verbindung 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 ist, sind zwei Peerings 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 das Peering erforderlichen IAM-Policys zu implementieren, müssen die beiden VCN-Administratoren einen Administrator als Requestor und den anderen als Acceptor bestimmen. Der Requestor ist derjenige, der die Anforderung zum Verbinden der beiden RPCs initiiert. Der Acceptor erstellt wiederum eine bestimmte IAM-Policy, die dem Requestor die Berechtigung für die Verbindung zu den RPCs im Compartment des Acceptors erteilt. Ohne diese Policy wird die Anforderung des Requestors zum Verbinden nicht erfolgreich sein.
- REGIONSABONNEMENT
- Um ein Peering mit einem VCN in einer anderen Region erstellen zu können, benötigt Ihr Mandant 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 Ihr 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, 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) initiiert, fordert er die andere Seite 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 Ihr DRG als Ziel an. Ihr DRG leitet den Traffic, der dieser Regel entspricht, an das andere DRG weiter. Dieses leitet den Traffic wiederum zum nächsten Hop im anderen VCN weiter.
-
Callout 3: Routentabelle von Subnetz A Ziel-CIDR Routenziel 0.0.0.0/0 Internetgateway 192.168.0.0/16 DRG-1 172.16.0.0/12 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 festlegen, welche Subnetze in seinem eigenen VCN mit VNICs in dem anderen VCN kommunizieren müssen, und die Subnetzsicherheitslisten entsprechend aktualisieren.
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:
- Ihr Mandant besitzt ein Abonnement für die Region des anderen VCN. Ist dies nicht der Fall, lesen Sie Regionen verwalten.
- An Ihr VCN ist bereits ein DRG angehängt. Andernfalls 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 die Routentabellen seines VCN, um den Traffic zwischen den Peer-VCNs nach Bedarf zu aktivieren.
- Sicherheitsregeln aktualisieren: Jeder Administrator aktualisiert die Sicherheitsregeln seines VCN, um den Traffic zwischen den Peer-VCNs nach Bedarf zu aktivieren.
Gegebenenfalls können Administratoren die Aufgaben E und F vor dem Verbindungsaufbau ausführen. Jeder Administrator muss den CIDR-Block oder bestimmte Subnetze aus dem VCN der jeweils anderen Seite kennen und diese in Aufgabe B gemeinsam verwenden.
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 klicken Sie auf Networking. Klicken Sie unter Kundenkonnektivität auf Dynamisches Routinggateway.
- Klicken Sie auf das gewünschte DRG.
- Klicken Sie unter Ressourcen auf Remote-Peering-Verbindungen.
- Klicken Sie auf Remote-Peering-Verbindung erstellen.
-
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 dem Sie derzeit arbeiten.
-
Klicken Sie auf Remote-Peering-Verbindung erstellen.
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 beide VCNs in demselben Mandanten, aber in verschiedenen Regionen befinden, verwenden Sie die Policys, die in Remote-Peering mit einem Legacy-DRG bereitgestellt werden.
Wenn sich beide VCNs in verschiedenen Mandanten, aber in derselben Region befinden, verwenden Sie die Policys, die unter An VCNs in anderen Mandanten anhängen bereitgestellt werden.
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.
- Zeigen Sie in der Konsole die Details für die RPC des Requestors an, die Sie mit der RPC des Acceptors verbinden möchten.
- Klicken Sie auf Verbindung herstellen.
-
Geben Sie Folgendes ein:
- Region: Die Region, die das VCN des Acceptors enthält. Die Dropdown-Liste enthält nur die Regionen, die Remote-VCN-Peering unterstützen und für die Ihr Mandant ein Abonnement besitzt.
- OCID der Remote-Peering-Verbindung: Die OCID der RPC des Acceptors.
-
Klicken Sie auf Verbindung herstellen.
Die Verbindung wird hergestellt, und der RPC-Status wechselt zu PEERED.
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.
Für Ihr eigenes VCN:
- Bestimmen Sie, welche Subnetze im VCN mit dem anderen VCN kommunizieren müssen.
-
Aktualisieren Sie die Routentabelle für jedes dieser Subnetze, um eine neue Regel aufzunehmen, die den Traffic, der für das andere VCN bestimmt ist, an Ihr DRG weiterleitet:
- Öffnen Sie das Navigationsmenü, und klicken Sie auf Networking, Virtuelle Cloud-Netzwerke.
- Klicken Sie auf das gewünschte VCN.
- Klicken Sie unter Ressourcen auf Routentabellen.
- Klicken Sie auf die gewünschte Routentabelle.
-
Klicken Sie auf Routingregel hinzufügen, und geben Sie Folgendes ein:
- 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.
- Klicken Sie auf Routingregel hinzufügen.
Jeder Subnetztraffic mit einem Ziel, das der Regel entspricht, wird an das 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 der Sie das Peering vorübergehend stoppen müssen, können Sie die Routingregeln, die den Traffic zulassen, einfach 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 müssen Sie denselben CIDR-Block verwenden, den Sie in der Routentabellenregel in Aufgabe E: Routentabellen konfigurieren verwendet haben.
Welche Regeln sollen hinzugefügt werden?
- Ingress-Regeln für die Traffictypen, die Sie aus dem anderen VCN zulassen möchten, insbesondere aus dem CIDR oder spezifischen Subnetzen des VCN.
- Egress-Regel, mit der ausgehender Traffic von einem VCN in das andere übertragen werden kann. 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 alle Ressourcen des Subnetzes in dieser NSG erstellen.
Für Ihr eigenes VCN:
- Bestimmen Sie, welche Subnetze im VCN mit dem anderen VCN kommunizieren müssen.
-
Aktualisieren Sie die Sicherheitsliste für jedes dieser Subnetze mit Regeln, die den gewünschten Egress- oder Ingress-Traffic speziell mit dem CIDR-Block oder einem Subnetz des anderen VCN zulassen:
- Klicken Sie in der Konsole auf Sicherheitslisten, während Sie das gewünschte VCN anzeigen.
- Klicken Sie auf die gewünschte Sicherheitsliste.
- Klicken Sie unter Ressourcen auf Ingress-Regeln oder Egress-Regeln, je nachdem, mit welchem Regeltyp Sie arbeiten möchten.
-
Wenn Sie eine neue Regel hinzufügen möchten, klicken Sie auf Ingress-Regel hinzufügen (oder Egress-Regel hinzufügen).
- Wenn Sie eine vorhandene Regel löschen möchten, klicken Sie auf das Menü "Aktionen" (
) und dann auf Entfernen. - Wenn Sie eine vorhandene Regel bearbeiten möchten, klicken Sie auf das Menü "Aktionen" () und dann auf Bearbeiten.
Weitere Informationen zu Sicherheitsregeln finden Sie unter Sicherheitsregeln.
Beispiel: Sie möchten eine Regel für zustandsbehafteten Traffic hinzufügen, die den Ingress-HTTPS-Traffic (Port 443) vom CIDR des anderen VCN aktiviert. Die folgenden grundlegenden Schritte werden beim Hinzufügen einer Regel ausgeführt:
- Klicken Sie im Abschnitt Regeln für Ingress zulassen auf +Regel hinzufügen.
- 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.
Konsole verwenden
Weitere Informationen finden Sie unter Aufgabe A: RPCs erstellen.
Durch Löschen einer RPC wird das Peering beendet. Die RPC auf der anderen Seite der Peering-Beziehung wechselt zum Status REVOKED.
- Öffnen Sie das Navigationsmenü, und klicken Sie auf Networking. Klicken Sie unter Kundenkonnektivität auf Dynamisches Routinggateway.
- Klicken Sie auf das gewünschte DRG.
- Klicken Sie unter Ressourcen auf Remote-Peering-Verbindungen.
- Klicken Sie auf die gewünschte RPC.
- Klicken Sie auf Beenden.
- Bestätigen Sie den Vorgang, wenn Sie dazu aufgefordert werden.
Nachdem Sie eine RPC gelöscht (und somit ein Peering beendet) haben, sollten Sie die Routentabellen und Sicherheitsregeln prüfen, um alle Regeln zu entfernen, die den Traffic mit dem anderen VCN aktiviert haben.