Remoteverbindung

Überblick

In diesem Szenario wird die Verbindung zwischen VCNs und dem On-Premise-Netzwerk hergestellt, jedoch nicht zwischen den VCNs. Diese Routing-Policy wird implementiert, indem die Routingtabellen des dynamischen Routinggateways  (DRG) konfiguriert werden. Ansonsten ähnelt dieses Szenario dem Remote-Peering.

Dieses Szenario ist nur für ein upgegradetes DRG verfügbar.

Übersicht über Networking-Komponenten für eine Einzelverbindung

Allgemein erforderliche Networking-Servicekomponenten für eine Einzelverbindung:

• Zwei VCNs mit sich nicht überschneidenden CIDRs in verschiedenen Regionen.

  Hinweis
  
  

  Keine VCN-CIDRs dürfen sich überschneiden.

  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.

  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 dynamisches Routinggateway (DRG), das an jedes VCN in der Peering-Beziehung angehängt ist. Ihr VCN verfügt bereits über ein DRG, wenn Sie ein Site-to-Site-VPN oder einen privaten Virtual Circuit von Oracle Cloud Infrastructure FastConnect verwenden.
• Zwei benutzerdefinierte DRG-Routentabellen: eine, die Traffic zu den VCNs leitet, und eine, die Traffic zum On-Premise-Netzwerk leitet. Die DRG-Standardroutentabellen (eine für lokale VCN-Anhänge und eine für alle anderen Anhänge) werden nach Abschluss der Konfiguration nicht verwendet.
• Eine Remote-Peering-Verbindung (RPC) auf jedem DRG in der Peering-Beziehung.
• Eine hergestellte Remote-Peering-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. VCN-1 ist optional, wenn Sie in erster Linie auf VCN-2 zugreifen möchten. Unterstützende Routentabellen und Sicherheitsregeln sind in jedem VCN erforderlich, um Traffic zu ermöglichen.

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 das Routing zwischen VCNs.

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 Bestandteil Remote des Begriffs Remote Peering gibt an, dass sich die VCNs 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:

• 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. Die VCNs können sich in demselben oder in verschiedenen Mandanten befinden.

Weitere Informationen zu den erforderlichen Policys und der VCN-Konfiguration finden Sie unter IAM-Policys für das Routing zwischen VCNs.

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. Der Requestor muss Informationen zur Identifizierung jeder RPC haben (wie Region und OCID  der RPC).

Beide VCN-Administratoren können ein Peering beenden, indem sie ihre RPC löschen. In diesem Fall wechselt der Status der anderen RPC zu REVOKED. Der Administrator kann stattdessen die Funktionsfähigkeit der Verbindung unterbinden, indem er die Routingregeln entfernt, mit denen Traffic über die Verbindung fließen kann (weitere Informationen im nächsten Abschnitt).

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 On-Premise-Netzwerk 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.

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.

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.

Einzelverbindung einrichten

Bevor Sie versuchen, dieses Szenario zu implementieren, stellen Sie Folgendes sicher:

1. VCN-1 ist wie unter VCN an ein DRG anhängen beschrieben an DRG-1 in Region 1 angehängt.
2. VCN-2 ist wie unter VCN an ein DRG anhängen beschrieben an DRG-2 in Region 2 angehängt.
3. VCN-2 wird per Peering mit VCN-1 verbunden, wie unter Remote-VCN-Peering über ein upgegradetes DRG beschrieben.
4. Beide DRGs sind ansonsten unverändert.
5. Der FastConnect-Virtual Circuit 1 befindet sich in Region 1 und ist gemäß der entsprechenden Methode je nach Quelle des Virtual Circuits (Oracle-Partner, Oracle-Colocation, Drittanbieter) mit DRG-1 verbunden, wie in der Dokumentation für FastConnect beschrieben.

Das folgende Diagramm zeigt den Anfangszustand vor der Implementierung dieses Szenarios. VCN-1 und VCN-2 sind Peers. 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 basierend auf der Regel in der Routentabelle von Subnetz A an DRG-1 weitergeleitet. Von dort wird der Traffic über die RPCs an DRG-2 und von dort anschließend an das Ziel im Subnetz X weitergeleitet. Das On-Premise-Netzwerk kann Ressourcen in VCN-1, aber nicht in VCN-2 adressieren.

Das im nächsten Diagramm beschriebene implementierte Verbindungsszenario lässt nicht zu, dass die VCNs Traffic zueinander weiterleiten. VCN-1 und VCN-2 sind Peers. Traffic von einer On-Premise-Ressource in Ihrem Netzwerk (172.16.0.10), die für eine Instanz in VCN-2 (192.168.0.15) bestimmt ist, wird basierend auf der Regel in der IPSEC_TUNNEL-Anhangsroutentabelle für den Traffic zu On Premise an DRG-1 weitergeleitet. Von dort wird der Traffic über den RPC-Anhang an DRG-2 und anschließend an das Ziel in Subnetz X weitergeleitet.

Schritte

Alle folgenden Schritte werden auf DRG-1 ausgeführt: