Oracle Cloud Infrastructure - Dokumentation

Transitrouting in einem Hub-VCN

Transitrouting bezieht sich auf eine Netzwerktopologie, bei der Ihr On-Premise-Netzwerk über eine Zwischenstation auf Oracle-Ressourcen oder -Services oder VCNs zugreifen kann. Die Zwischenstation kann ein VCN oder ein dynamisches Routinggateway (DRG) sein, an das Ihr On-Premise-Netzwerk bereits angehängt ist. Sie verbinden das On-Premise-Netzwerk mit FastConnect oder Site-to-Site-VPN mit einem DRG und konfigurieren dann das Routing so, dass der Traffic durch die Zwischenstation zu seinem Ziel weitergeleitet wird.

Die drei primären Transitroutingszenarios sind:

  • Zugriff zwischen mehreren Netzwerken über ein einzelnes DRG mit einer Firewall zwischen Netzwerken: In diesem Szenario wird das DRG als Hub verwendet. Dabei ist das Routing so konfiguriert, dass Pakete über eine Firewall in einem VCN gesendet werden, bevor sie an ein anderes Netzwerk gesendet werden können. Siehe Traffic über eine zentrale Netzwerk-Virtual-Appliance weiterleiten. Dieses Szenario ist nur für eine Implementierung mit einem aktualisierten DRG verfügbar.
  • Zugriff auf mehrere VCNs in derselben Region: Das in diesem Thema behandelte Szenario. Dieses Szenario verwendet ein VCN als Hub und ermöglicht die Kommunikation zwischen Ihrem On-Premise-Netzwerk und mehreren VCNs (über lokales Peering verbunden) in derselben Region über einen einzelnen privaten Virtual Circuit von FastConnect oder über Site-to-Site-VPN. Oracle empfiehlt, stattdessen das vorherige Szenario zu verwenden. Dieses Szenario ist für eine Implementierung mit einem Legacy-System oder einem aktualisierten DRG verfügbar.
  • Privater Zugriff auf Oracle-Services: In diesem Szenario wird ein VCN als Hub verwendet, und Ihr On-Premise-Netzwerk erhält privaten Zugriff auf Oracle-Services, sodass Ihre On-Premise-Hosts ihre privaten IP-Adressen verwenden können und der Traffic nicht über das Internet geleitet wird. Weitere Informationen finden Sie unter Privater Zugriff auf Oracle-Services. Dieses Szenario ist für eine Implementierung verfügbar, die entweder ein Legacy-DRG oder ein upgegradetes DRG verwendet.

Highlights

  • Sie können eine einzelne FastConnect- oder Site-to-Site-VPN-Verbindung zwischen Ihrem On-Premise-Netzwerk in einer Hub-and-Spoke-Topologie mit mehreren VCNs in derselben Region verwenden.
  • Die VCNs müssen sich in derselben Region befinden, können sich jedoch in unterschiedlichen Mandanten befinden. Für ein genaues Routing dürfen sich die CIDR-Blöcke der verschiedenen Subnetze im On-Premise-Netzwerk und den VCNs nicht überschneiden.
  • Das VCN, das als Hub fungiert, verwendet ein dynamisches Routinggateway (DRG) zur Kommunikation mit dem On-Premise-Netzwerk. Dieses Hub-VCN stellt Peering-Beziehungen zu jedem VCN her, das als Spoke fungiert (in diesem Thema als Spoke-VCNs bezeichnet). Die Hub- und Spoke-VCNs verwenden lokale Peering-Gateways (LPGs) zur Kommunikation.
  • Um den beabsichtigten Traffic vom On-Premise-Netzwerk über das Hub-VCN zu einem Spoke-VCN-Peer zu ermöglichen, implementieren Sie Routingregeln für den DRG-Anhang und das LPG des Hub-DRG oder des Hub-VCN und für die Subnetze des Spoke-VCN.
  • Bei Bedarf können Sie das Transitrouting über eine private IP im Hub-VCN einrichten. Beispiel: Sie möchten den Traffic zwischen dem On-Premise-Netzwerk und einem Spoke-VCN filtern oder prüfen. In diesem Fall leiten Sie den Traffic zu einer privaten IP auf einer Instanz im Hub-VCN zur Prüfung weiter, und der daraus resultierende Traffic wird zum Ziel weitergeleitet. In diesem Thema werden beide Situationen behandelt: direktes Transitrouting zwischen Gateways im Hub-VCN und Transitrouting über eine private IP.
  • Durch die Konfiguration von Routentabellen im Hub-VCN können Sie steuern, ob ein bestimmtes Subnetz in einem per Peering angebundenen Spoke-VCN im On-Premise-Netzwerk angeboten wird und ob ein bestimmtes Subnetz im On-Premise-Netzwerk in einem per Peering angebundenen Spoke-VCN angeboten wird.
Tipp

Es gibt noch ein weiteres Szenario, mit dem Sie Ihr On-Premise-Netzwerk mit mehreren VCNs verbinden können. Anstatt ein einzelnes DRG und Hub-and-Spoke-Topologie zu verwenden, richten Sie ein separates DRG für jedes VCN und nur einen separaten privaten Virtual Circuit über FastConnect ein. Das Szenario kann jedoch nur mit FastConnect über einen externen Provider oder über Colocation mit Oracle verwendet werden. Die VCNs müssen sich in derselben Region und demselben Mandanten befinden. Weitere Informationen finden Sie unter FastConnect mit mehreren DRGs und VCNs.

Transitrouting - Überblick

Transitrouting leitet Traffic einfach über ein zentrales Hub-VCN an ein virtuelles Cloud-Netzwerk (VCN) oder ein On-Premise-Netzwerk weiter. Nachfolgend finden Sie ein grundlegendes Beispiel, für das Transitrouting empfohlen wird: Sie haben eine große Organisation mit unterschiedlichen Abteilungen, von denen jede ihr eigenes VCN hat. Ihr On-Premise-Netzwerk benötigt Zugriff auf die verschiedenen VCNs, Sie möchten den Administrationsaufwand für eine sichere Verbindung zwischen jedem einzelnen VCN und dem On-Premise-Netzwerk jedoch vermeiden. Stattdessen möchten Sie ein einzelnes FastConnect oder Site-to-Site-VPN verwenden.

Bei einem grundlegenden Netzwerkszenario wird Ihr On-Premise-Netzwerk über Oracle Cloud Infrastructure FastConnect oder ein Site-to-Site-VPN mit einem VCN verbunden. Die folgenden beiden grundlegenden Szenarios verdeutlichen diese Topologie: Szenario B: Privates Subnetz mit einem VPN und Szenario C: Öffentliche und private Subnetze mit einem VPN.

Dieses Szenario verwendet eine Hub-and-Spoke-Topologie, wie im folgenden Diagramm dargestellt. Der Begriff Hub bedeutet hier nur, dass ein VCN in diesem Hub-and-Spoke-Design als Hub fungiert.

Diese Abbildung zeigt das grundlegende Hub-and-Spoke-Layout von VCNs, die mit Ihrem On-Premise-Netzwerk verbunden sind.

Eines der VCNs dient als Hub (VCN-H) und stellt eine Verbindung zu Ihrem On-Premise-Netzwerk über FastConnect oder ein Site-to-Site-VPN her. Die anderen VCNs sind per lokalem Peering mit dem Hub-VCN verbunden. Der Traffic zwischen dem On-Premise-Netzwerk und den VCN-Peers durchläuft das Hub-VCN. Die VCNs müssen sich in derselben Region befinden, können sich jedoch in unterschiedlichen Mandanten befinden.

Am Transitrouting beteiligte Gateways

Das nächste Diagramm zeigt die Gateways in den VCNs. Das Hub-VCN verfügt über ein dynamisches Routinggateway (DRG), das den Kommunikationspfad mit dem On-Premise-Netzwerk darstellt. Für jedes per lokalem Peering angebundene Spoke-VCN ist ein Paar lokaler Peering-Gateways (LPGs) vorhanden, die die Peering-Beziehung verankern. Ein LPG befindet sich auf dem Hub-VCN und das andere auf dem Spoke-VCN.

Diese Abbildung zeigt das grundlegende Hub-and-Spoke-Layout von VCNs zusammen mit den erforderlichen Gateways.

Neue Konzepte für erfahrene Benutzer des Networking-Service - Übersicht

Wenn Sie bereits mit dem Networking-Service und dem lokalen VCN-Peering vertraut sind, machen Sie sich mit den folgenden wichtigsten neuen Konzepten vertraut:

  • Aktualisieren Sie für jedes Spoke-VCN-Subnetz, das mit dem On-Premise-Netzwerk kommunizieren muss, die Routentabelle des Subnetzes mit einer Regel, die das LPG des Spoke-VCN als Ziel (den nächsten Hop) für den gesamten Traffic festlegt, der für das On-Premise-Netzwerk bestimmt ist.

  • Fügen Sie dem Hub-VCN eine Routentabelle hinzu, und verknüpfen Sie sie mit dem DRG-Anhang. Fügen Sie dann eine Routingregel hinzu, die das Ziel (den nächsten Hop) für den gesamten Traffic, der für dieses Spoke-VCN (oder ein bestimmtes Subnetz in diesem VCN) bestimmt ist, auf das LPG des Hub-VCN (für diesen Spoke) setzt.

  • Fügen Sie dem Hub-VCN eine weitere Routentabelle hinzu, und verknüpfen Sie sie mit dem LPG des Hub-VCN (für diesen Spoke). Fügen Sie dann eine Routingregel hinzu, die das Ziel (den nächsten Hop) für den gesamten Traffic, der für das On-Premise-Netzwerk (oder ein bestimmtes Subnetz in diesem Netzwerk) bestimmt als, auf das DRG setzt.

Weitere Informationen zum Transitrouting direkt über Gateways finden Sie in den folgenden Aufgaben:

Weitere Informationen zum Transitrouting über eine private IP finden Sie in den folgenden Aufgaben:

Beispiel: Komponenten und Routing für einen Hub mit einem einzigen Spoke

Die Beispiele in diesem Abschnitt zeigen ein VCN, das als Hub fungiert und der Einfachheit halber nur ein einziges Spoke-VCN besitzt.

Hinweis

In einem Hub-and-Spoke-Modell kann das Hub-VCN mehrere Spokes und somit mehrere LPGs (eines pro Spoke) besitzen. In diesem Thema wird der Ausdruck LPG des Hub-VCN verwendet, der somit mehrdeutig ist. In diesem Zusammenhang ist das Hub-LPG für den betreffenden Spoke gemeint. In den folgenden Diagrammen ist dies der Hub LPG-H-1. Weitere Spokes würden die Erstellung eines LPG-H-2, LPG-H-3 usw. umfassen.
Für Transitrouting direkt über Gateways

Das folgende Diagramm zeigt die erforderlichen Routentabellen und Routingregeln für den Networking-Service zur Einrichtung von Transitrouting direkt über Gateways. Auch wenn das Hub-VCN kein Subnetz für das Transitrouting benötigt, enthält das hier dargestellte Beispiel ein Subnetz mit dem Namen Subnet-H.

Diese Abbildung zeigt die Routentabellen und Routingregeln, die bei der Einrichtung des Szenarios erforderlich sind.
Callout 1: Mit Subnet-H verknüpfte Routentabelle
Ziel-CIDR Routenziel
172.16.0.0/12 DRG
192.168.0.0/16 LPG-H-1
Callout 2: Mit Subnet-1 verknüpfte Routentabelle
Ziel-CIDR Routenziel
10.0.0.0/16 LPG-1
172.16.0.0/12 LPG-1
Callout 3: Mit dem DRG-Anhang verknüpfte VCN-Routentabelle
Ziel-CIDR Routenziel
192.168.0.0/16 LPG-H-1
Callout 4: Mit LPG-H-1 verknüpfte Routentabelle
Ziel-CIDR Routenziel
172.16.0.0/12 DRG

Das Szenario im Diagramm zeigt vier Routentabellen, die jeweils mit einer anderen Ressource verknüpft sind:

  • Subnet-H:

    • Diese Routentabelle gehört zum Hub-VCN und ist mit Subnet-H verknüpft.
    • Diese Routentabelle enthält eine Regel, mit der Traffic, der für das On-Premise-Netzwerk bestimmt ist, an das DRG weitergeleitet wird. Sie enthält eine weitere Regel, mit der Traffic, der für das Spoke-VCN bestimmt ist, an LPG-H-1 weitergeleitet wird.

  • Subnet-1:

    • Diese Routentabelle gehört zum Spoke-VCN und ist mit Subnet-1 verknüpft.
    • Diese Routentabelle enthält Regeln, mit der Traffic, der für das Hub-VCN oder das On-Premise-Netzwerk bestimmt ist, an LPG-1 weitergeleitet wird.

  • VCN-Routentabelle auf dem DRG-Anhang:

    • Die Routentabelle gehört zum Hub-VCN und ist mit dem DRG-Anhang verknüpft. Warum mit dem Anhang und nicht mit dem DRG selbst? Weil das DRG eine Standalone-Ressource ist, die Sie an ein beliebiges VCN anhängen können, das sich in derselben Region und demselben Mandanten wie das DRG befindet. Das betreffende VCN wird im Anhang selbst angegeben.
    • Die Routentabelle leitet den eingehenden Traffic weiter, der aus dem On-Premise-Netzwerk stammt und für das Spoke-VCN (VCN-1) bestimmt ist. Sie konfigurieren die Regel so, dass dieser Traffic an LPG-H-1 gesendet wird.

  • VCN-Routentabelle auf LPG-H-1:

    • Diese Routentabelle gehört zum Hub-VCN und ist mit LPG-H-1 verknüpft.
    • Die Routentabelle leitet eingehenden Traffic weiter, der von VCN-1 stammt und für das On-Premise-Netzwerk bestimmt ist. Sie konfigurieren die Regel, mit der der Traffic an das DRG gesendet wird.
Für Transitrouting über eine private IP

Das folgende Diagramm zeigt die erforderlichen Routentabellen und Routingregeln für den Networking-Service zur Einrichtung von Transitrouting über eine private IP auf einer Instanz im Hub-VCN. Sie können dieses Szenario mit einer einzelnen VNIC oder mehreren VNICs implementieren. Im nächsten Diagramm sind zwei VNICs dargestellt: eine in einem Subnetz mit dem Namen Subnet-H-Frontend und eine weitere in einem Subnetz mit dem Namen Subnet-H-Backend. Die Frontend-VNIC hat die private IP 10.0.4.3, und die Backend-VNIC hat die private IP 10.0.8.3.

Diese Abbildung zeigt die Routentabellen und Routingregeln, die bei der Einrichtung des Szenarios mit einer virtuellen Netzwerk-Appliance im Hub-VCN erforderlich sind.
Callout 1: Mit Subnet-H-Frontend verknüpfte Routentabelle
Ziel-CIDR Routenziel
172.16.0.0/12 DRG
192.168.0.0/16 10.0.4.3
Callout 2: Mit Subnet-H-Backend verknüpfte Routentabelle
Ziel-CIDR Routenziel
192.168.0.0/16 LPG-H-1
172.16.0.0/12 10.0.8.3
Callout 3: Mit Subnet-1 verknüpfte Routentabelle
Ziel-CIDR Routenziel
10.0.0.0/16 LPG-1
172.16.0.0/12 LPG-1
Callout 4: Mit dem DRG-Anhang verknüpfte Routentabelle
Ziel-CIDR Routenziel
192.168.0.0/16 10.0.4.3
Callout 5: Mit LPG-H-1 verknüpfte Routentabelle
Ziel-CIDR Routenziel
172.16.0.0/12 10.0.8.3

Mit LPG-1 ist keine spezielle Routentabelle verknüpft.

Das Diagramm zeigt fünf Routentabellen, die jeweils mit einer anderen Ressource verknüpft sind:

  • DRG-Anhang:

    • Die Routentabelle gehört zum Hub-VCN und ist mit dem DRG-Anhang verknüpft. Warum mit dem Anhang und nicht mit dem DRG selbst? Weil das DRG eine Standalone-Ressource ist, die Sie an ein beliebiges VCN anhängen können, das sich in derselben Region und demselben Mandanten wie das DRG befindet. Das betreffende VCN wird im Anhang selbst angegeben.
    • Die Routentabelle leitet den eingehenden Traffic weiter, der aus dem On-Premise-Netzwerk stammt und für das Spoke-VCN (VCN-1) bestimmt ist. Sie konfigurieren die Regel so, dass der Traffic an die private IP im Frontend-Subnetz gesendet wird.

  • LPG-H-1:

    • Diese Routentabelle gehört zum Hub-VCN und ist mit LPG-H-1 verknüpft.
    • Die Routentabelle leitet eingehenden Traffic weiter, der von VCN-1 stammt und für das On-Premise-Netzwerk bestimmt ist. Sie konfigurieren die Regel so, dass dieser Traffic an die private IP im Backend-Subnetz gesendet wird.

  • Subnet-H-Frontend:

    • Diese Routentabelle gehört zum Hub-VCN und ist mit Subnet-H-Frontend verknüpft.
    • Diese Routentabelle enthält eine Regel, mit der Traffic, der für das On-Premise-Netzwerk bestimmt ist, an das DRG weitergeleitet wird.
    • Auch wenn Oracle keine Workloads in den Subnetzen des Hub-VCN empfiehlt, zeigt das Diagramm eine Routingregel an, mit der Traffic, der für das Spoke-VCN bestimmt ist, zwecks Filterung durch die Instanz zur privaten IP im Frontend-Subnetz (10.0.4.3) weitergeleitet wird. Die hier gezeigte zweite Regel dient dazu, einen umfassenderen Überblick über das Routing in diesem Beispiel zu vermitteln.

  • Subnet-H-Backend:

    • Diese Routentabelle gehört zum Hub-VCN und ist mit Subnet-H-Backend verknüpft.
    • Diese Routentabelle enthält eine Regel, mit der Traffic, der für das Spoke-VCN (VCN-1) bestimmt ist, an LPG-H-1 weitergeleitet wird.
    • Auch wenn Oracle keine Workloads in den Subnetzen des Hub-VCN empfiehlt, zeigt das Diagramm eine Routingregel, mit der Traffic, der für das On-Premise-Netzwerk bestimmt ist, zwecks Filterung durch die Instanz zur privaten IP im Backend-Subnetz (10.0.8.3) weitergeleitet wird. Die hier gezeigte zweite Regel dient dazu, einen umfassenderen Überblick über das Routing in diesem Beispiel zu vermitteln.

  • Subnet-1:

    • Diese Routentabelle gehört zum Spoke-VCN und ist mit Subnet-1 verknüpft.
    • Diese Routentabelle enthält Regeln, mit der Traffic, der für das Hub-VCN oder das On-Premise-Netzwerk bestimmt ist, an LPG-1 weitergeleitet wird.

Wichtige Einschränkungen des Transitroutings

Dieser Abschnitt enthält weitere wichtige Details zum Routing:

  • Routentabelle für den DRG-Anhang:

    • Eine mit einem DRG-Anhang verknüpfte VCN-Routentabelle kann nur Regeln enthalten, die auf ein Servicegateway, eine private IP oder ein lokales Peering-Gateway ausgerichtet sind.
    • Mit einem DRG-Anhang ist immer eine Routentabelle verknüpft. Sie können jedoch eine andere Routentabelle verknüpfen, die Regeln der Tabelle bearbeiten sowie einige oder alle Regeln löschen.

  • Routentabelle für ein LPG:

    • Eine mit einem DRG-Anhang verknüpfte VCN-Routentabelle kann nur Regeln enthalten, die auf ein Servicegateway, eine private IP oder ein lokales Peering-Gateway ausgerichtet sind.
    • Ein LPG kann auch ohne zugehörige Routentabelle vorhanden sein. Sobald Sie eine Routentabelle jedoch mit einem LPG verknüpft haben, muss immer eine Routentabelle mit ihm verknüpft sein. Sie können jedoch eine andere Routentabelle mit dem LPG verknüpfen. Sie können auch die Regeln der Tabelle bearbeiten sowie einige oder alle Regeln löschen.
  • Traffic durch das Hub-VCN: Die hier erläuterten Routentabellen sind nur für die Weiterleitung von Traffic durch das Hub-VCN zwischen Geräten im On-Premise-Netzwerk und Geräten im Spoke-VCN bestimmt. Wenn Sie eine private IP in dem Hub verwenden, konfigurieren Sie diese Routentabellen so, dass die private IP in diesen Trafficpfad platziert wird, der durch den Hub führt.
  • Im Hub-VCN eingehender Traffic: Die vorhergehende Aussage ist zwar zutreffend (für Traffic durch den Hub), doch ist der in Subnetzen innerhalb des Hub-VCN eingehende Traffic immer zulässig. Sie müssen keine expliziten Regeln für diesen eingehenden Traffic in der Routentabelle des DRG-Anhangs oder der Routentabelle des Hub-LPG einrichten. Wenn diese Art des eingehenden Traffics das DRG oder das Hub-LPG erreicht, wird der Traffic automatisch über das lokale VCN-Routing an das Ziel im Hub-VCN weitergeleitet. Aufgrund des lokalen VCN-Routings können Sie für Routentabellen, die zu einem bestimmten VCN gehören, keine Regel erstellen, die das VCN-CIDR (oder einen Unterabschnitt) als Ziel der Regel auflistet.
  • Hub-VCN-Traffic beim Transitrouting über eine private IP: Die unmittelbar vorhergehende Aussage zum lokalen VCN-Routing bedeutet, dass Sie das Hub-VCN für den Transit zwischen dem On-Premise-Netzwerk und den Spoke-VCNs verwenden sollten. Richten Sie keine Workloads im Hub-VCN selbst ein. Genauer gesagt: Wenn Sie Transitrouting über eine private IP im Hub-VCN einrichten, können Sie nicht gleichzeitig den Traffic des Hub-VCN über diese private IP leiten. Beispiel: Wenn Sie im vorherigen Diagramm die Routingregel in der Routentabelle von LPG-H-1 ändern, sodass das Ziel-CIDR 0.0.0.0/0 anstelle von 172.16.0.0/12 lautet, wird nur der Traffic von VCN-1, der für Adressen außerhalb des CIDR-Blocks des Hub-VCN bestimmt ist, über die private IP weitergeleitet. Aufgrund des lokalen VCN-Routings wird der gesamte Traffic, der für Adressen innerhalb des VCN bestimmt ist, automatisch direkt an die IP-Zieladresse weitergeleitet. Das lokale VCN-Routing hat Vorrang vor der Routentabelle von LPG-H-1 (im Allgemeinen vor allen Routentabellen des VCN).

  • Der folgende Trafficfluss wird nicht unterstützt:

    nicht unterstützter Routenpfad
    • Traffic durchläuft DRG-1 aus einem Anhang an VCN-1.
    • Der Traffic gleicht eine Regel in der Ingress-Routentabelle des Anhangs mit LPG-1 ab, das per Peering mit LPG-2 in VCN-2 verbunden ist.
    • Der Traffic gleicht eine Regel in der Ingress-Routentabelle von LPG-2 mit DRG-2 ab (angehängt an VCN-2).

    Auch wenn diese Methode scheinbar funktioniert, wird sie nicht unterstützt. Die unterstützte Methode zum Verschieben des Traffics zwischen zwei DRGs in derselben Region ist die Verwendung einer Remote-Peering-Verbindung innerhalb einer Region.

CIDR-Überschneidungen

In diesem Beispiel weisen die verschiedenen Netzwerke keine sich überschneidenden CIDR-Blöcke auf (172.16.0.0/12 im Vergleich zu 10.0.0.0/16 und 192.168.0.0/16). Der Networking-Service lässt kein lokales VCN-Peering zwischen zwei VCNs mit sich überschneidenden CIDRs zu. Das heißt, kein Spoke darf sich mit dem Hub überschneiden.

Der Networking-Service validiert jedoch nicht, ob sich die Spoke-VCNs überschneiden oder ob sich eines der VCNs mit dem On-Premise-Netzwerk überschneidet. Stellen Sie sicher, dass sich die CIDRs für alle Subnetze, die miteinander kommunizieren müssen, nicht überschneiden. Andernfalls wird der Traffic gelöscht.

Eine Routentabelle des Networking-Service darf nicht zwei Regeln mit genau demselben Ziel-CIDR enthalten. Wenn jedoch zwei Regeln in derselben Routentabelle sich überschneidende Ziel-CIDRs aufweisen, wird die spezifischste Regel in der Tabelle für das Trafficrouting verwendet (d.h. die Regel mit der längsten Präfixübereinstimmung).

Routen-Advertisement zum On-Premise-Netzwerk und zu Spoke-VCNs

Aus Sicherheitsgründen können Sie das Routen-Advertisement steuern, sodass den Spoke-VCNs nur bestimmte Subnetze im On-Premise-Netzwerk angeboten werden. Genauso können Sie steuern, welche Subnetze in den Spoke-VCNs dem On-Premise-Netzwerk angeboten werden.

Die dem On-Premise-Netzwerk angebotenen Routen bestehen aus:

  • Den in der Routentabelle aufgeführten Regeln, die mit dem DRG-Anhang verknüpft sind (192.168.0.0/16 im vorherigen Diagramm)
  • Den einzelnen Subnetzen im Hub-VCN

Die dem Spoke-VCN angebotenen Routen bestehen aus:

  • Den einzelnen Subnetzen im Hub-VCN
  • Den in der Routentabelle aufgeführten Regeln, die mit dem LPG des Hub-VCN für den Spoke verknüpft sind (172.16.0.0/12 im vorherigen Diagramm)

Daher kann nur der Administrator des Hub-VCN steuern, welche Routen dem On-Premise-Netzwerk und den Spoke-VCNs angeboten werden.

Im vorherigen Beispiel verwenden die relevanten Routen den vollständigen CIDR-Block des On-Premise-Netzwerks (172.16.0.0/12) und des Spoke-VCN (192.168.0.0/16) als Ziel. Stattdessen können sie auch ein Subnetz dieser Netzwerke verwenden, um das Routing auf bestimmte Subnetze zu beschränken.

Details zum Routing für verschiedene Trafficpfade

Um das Routing im vorhergehenden Beispiel näher zu erläutern, wird nachfolgend näher auf verschiedene Trafficpfade eingegangen. Dabei werden dieselben Diagramme erneut verwendet.

Zunächst betrachten wir das Transitrouting direkt über Gateways im Hub-VCN:

Diese Abbildung zeigt die Routentabellen und Routingregeln, die bei der Einrichtung des Szenarios erforderlich sind.
Callout 1: Mit Subnet-H verknüpfte Routentabelle
Ziel-CIDR Routenziel
172.16.0.0/12 DRG
192.168.0.0/16 LPG-H-1
Callout 2: Mit Subnet-1 verknüpfte Routentabelle
Ziel-CIDR Routenziel
10.0.0.0/16 LPG-1
172.16.0.0/12 LPG-1
Callout 3: Mit dem DRG-Anhang verknüpfte Routentabelle
Ziel-CIDR Routenziel
192.168.0.0/16 LPG-H-1
Callout 4: Mit LPG-H-1 verknüpfte Routentabelle
Ziel-CIDR Routenziel
172.16.0.0/12 DRG

Mit LPG-1 ist keine spezielle Routentabelle verknüpft.

Als Nächstes betrachten wir das Transitrouting über eine private IP im Hub-VCN:

Diese Abbildung zeigt die Routentabellen und Routingregeln, die bei der Einrichtung des Szenarios mit einer virtuellen Netzwerk-Appliance im Hub-VCN erforderlich sind.
Callout 1: Mit Subnet-H-Frontend verknüpfte Routentabelle
Ziel-CIDR Routenziel
172.16.0.0/12 DRG
192.168.0.0/16 10.0.4.3
Callout 2: Mit Subnet-H-Backend verknüpfte Routentabelle
Ziel-CIDR Routenziel
192.168.0.0/16 LPG-H-1
172.16.0.0/12 10.0.8.3
Callout 3: Mit Subnet-1 verknüpfte Routentabelle
Ziel-CIDR Routenziel
10.0.0.0/16 LPG-1
172.16.0.0/12 LPG-1
Callout 4: Mit dem DRG-Anhang verknüpfte Routentabelle
Ziel-CIDR Routenziel
192.168.0.0/16 10.0.4.3
Callout 5: Mit LPG-H-1 verknüpfte Routentabelle
Ziel-CIDR Routenziel
172.16.0.0/12 10.0.8.3

Mit LPG-1 ist keine spezielle Routentabelle verknüpft.

Traffic vom On-Premise-Netzwerk zum Spoke-VCN
  1. Der Traffic verlässt das On-Premise-Netzwerk und erreicht das DRG. Das Ziel des Traffics befindet sich in Subnet-1 (Beispiel: 192.168.0.5).

  2. Die mit dem DRG-Anhang verknüpfte Routentabelle enthält eine Regel für 192.168.0.0/16. Dies stimmt mit dem Ziel überein, und daher sendet die Regel den Traffic an das Routingziel:

    • Transitrouting direkt über Gateways: Das Ziel der Regel ist LPG-H-1.
    • Transitrouting über eine private IP: Das Ziel der Regel ist die private IP 10.0.4.3. Die Instanz empfängt und verarbeitet den Traffic und versendet allen daraus resultierenden Traffic von der VNIC des Backend-Subnetzes. Die Routentabelle des Backend-Subnetzes sendet diesen Traffic an LPG-H-1.

    Beachten Sie, dass Sie über die Regeln in der Routentabelle des DRG-Anhangs steuern können, welche Subnetze im Spoke-VCN dem On-Premise-Netzwerk angeboten werden. Stattdessen können Sie die Regel so einrichten, dass nur ein Subnetz des Spoke-VCN aufgelistet wird.

  3. LPG-H-1 empfängt den Traffic.
  4. Egress-Traffic, der ein VCN über ein LPG verlässt, wird automatisch an den LPG-Peer des LPG weitergeleitet, der in diesem Fall LPG-1 ist. Dieses Routing erfolgt automatisch aufgrund der Peering-Verbindung zwischen den beiden LPGs.
  5. LPG-1 empfängt den Traffic.
  6. Traffic, der über das LPG bei einem VCN eingeht, wird aufgrund des lokalen VCN-Routings automatisch an das Ziel innerhalb des VCN weitergeleitet. Es sind keine expliziten Routingregeln erforderlich.
Traffic vom Spoke-VCN zum On-Premise-Netzwerk
  1. Traffic geht von einer Instanz in Subnet-1 im Spoke-VCN ein. Das Ziel des Traffics befindet sich im On-Premise-Netzwerk (Beispiel: 172.16.0.3).
  2. Die verknüpfte Routentabelle von Subnet-1 enthält eine Regel für 172.16.0.0/12. Dies stimmt mit dem Ziel überein, und daher sendet die Regel den Traffic an das Routingziel LPG-1.
  3. LPG-1 empfängt den Traffic.
  4. Egress-Traffic, der ein VCN über ein LPG verlässt, wird automatisch an den LPG-Peer des LPG weitergeleitet, der in diesem Fall LPG-H-1 ist. Dieses Routing erfolgt automatisch aufgrund der Peering-Verbindung zwischen den beiden LPGs.
  5. LPG-H-1 empfängt den Traffic.

  6. Die mit LPG-H-1 verknüpfte Routentabelle enthält eine Regel für 172.16.0.0/12. Dies stimmt mit dem Ziel überein, und daher sendet die Regel den Traffic an das Routingziel:

    • Transitrouting direkt über Gateways: Das Ziel der Regel ist das DRG.
    • Transitrouting über eine private IP: Das Ziel der Regel ist die private IP 10.0.8.3. Die Instanz empfängt und verarbeitet den Traffic und versendet allen daraus resultierenden Traffic von der VNIC des Frontend-Subnetzes. Die Routentabelle des Frontend-Subnetzes sendet diesen an das DRG.

    Beachten Sie, dass Sie über die Regeln in der Routentabelle des LPG steuern können, welche Subnetze im On-Premise-Netzwerk dem Spoke-VCN angeboten werden. Stattdessen können Sie die Regel so einrichten, dass nur ein Subnetz des On-Premise-Netzwerks aufgelistet wird.

  7. Das DRG empfängt den Traffic.
  8. Egress-Traffic, der das VCN über das DRG verlässt, wird basierend auf der Site-to-Site-VPN- und FastConnect-Konfiguration weitergeleitet. Es werden keine expliziten Regeln in der Routentabelle des DRG-Anhangs benötigt.

Beachten Sie, dass Subnet-1 im Spoke-VCN und LPG-H-1 beide Routingregeln mit 172.16.0.0/12 als Ziel-CIDR aufweisen. Diese Regeln müssen nicht genau denselben CIDR-Block verwenden. Stellen Sie jedoch sicher, dass beide Regeln den Traffic abdecken, den Sie vom Spoke zum On-Premise-Netzwerk weiterleiten möchten. Die Regel in der Routentabelle von Subnet-1 steuert, welcher Traffic von Subnet-1 zu LPG-H-1 geleitet wird. Die Regel in der Routentabelle von LPG-H-1 steuert, welcher Traffic vom Spoke-VCN zum On-Premise-Netzwerk geleitet wird. Wenn die Routingregel von LPG-H-1 restriktiver ist als die Routingregel von Subnet-1, kann ein Teil des Traffics, der das Subnetz verlässt, letztendlich gelöscht werden und das DRG nicht erreichen.

Traffic vom Spoke-VCN zu einem Subnetz im Hub-VCN (nur über Routing direkt zwischen Gateways)

Je nach Situation möchten Sie eventuell Traffic zwischen Instanzen im Hub-VCN und einem Spoke-VCN ermöglichen und nicht nur Traffic zwischen dem On-Premise-Netzwerk und einem Spoke-VCN. Dies können Sie tun, wenn Sie Routing direkt zwischen Gateways einsetzen. Sie können Traffic von einem Spoke-VCN nicht über die private IP zu anderen Instanzen im Hub-VCN weiterleiten. Im Hinweis am Ende dieses Abschnitts wird der Grund dafür erläutert.

Der Traffic fließt dabei wie folgt vom Spoke-VCN zu einem Ziel mit einer Adresse im Hub-VCN:

  1. Traffic geht von einer Instanz in Subnet-1 im Spoke-VCN ein. Das Ziel des Traffics befindet sich in einem Subnetz im Hub-VCN (Beispiel: 10.0.0.3).
  2. Die verknüpfte Routentabelle von Subnet-1 enthält eine Regel für 10.0.0.0/16. Dies stimmt mit dem Ziel überein, und daher sendet die Regel den Traffic an das Routingziel LPG-1.
  3. LPG-1 empfängt den Traffic.
  4. Egress-Traffic, der ein VCN über ein LPG verlässt, wird automatisch an den LPG-Peer des LPG weitergeleitet, der in diesem Fall LPG-H-1 ist. Dieses Routing erfolgt automatisch aufgrund der Peering-Verbindung zwischen den beiden LPGs.
  5. LPG-H-1 empfängt den Traffic.
  6. Traffic, der über ein LPG bei einem VCN eingeht und für eine Adresse im VCN bestimmt ist, wird automatisch durch das lokale VCN-Routing an das Ziel weitergeleitet. Es sind keine expliziten Routingregeln erforderlich.

Eine ähnliche Abfolge von Routingschritten erfolgt für Traffic von Subnet-H zu Subnet-1, jedoch in umgekehrter Richtung. Die Routentabelle von Subnet-H enthält eine Regel, die mit dem CIDR (192.168.0.0/16) des Spoke-VCN übereinstimmt und den Traffic an LPG-H-1 sendet, das ihn wiederum an LPG-1 weiterleitet.

Hinweis:

Wenn Sie Transitrouting über eine private IP im Hub-VCN einrichten, beachten Sie, dass die Routentabelle von LPG-H-1 nur das Routing von Traffic steuert, der für Adressen außerhalb des Hub-VCN bestimmt ist. Traffic, der für Adressen innerhalb des VCN bestimmt ist, wird vom lokalen Routing des Hub-VCN verarbeitet, das Vorrang hat und den Traffic immer direkt an die Zieladresse des Pakets weiterleitet. Das bedeutet, dass Sie Traffic, der für Adressen innerhalb des Hub-VCN bestimmt ist, nicht über die private IP leiten können, die für den Transittraffic durch den Hub verwendet wird. Selbst wenn die Routingregel von LPG-H-1 Destination = 0.0.0.0/0 und Ziel = 10.0.8.3 verwendet, hat das lokale Routing im Hub-VCN Vorrang und leitet den Traffic direkt an die Destination im Hub-VCN und nicht an die private IP weiter.

Erforderliche IAM Policy

Um Oracle Cloud Infrastructure zu verwenden, muss Ihnen ein Administrator in einer Policy  Sicherheitszugriff erteilen. Dieser Zugriff ist erforderlich, unabhängig davon, ob Sie die Konsole oder die REST-API mit einem SDK, einer CLI oder einem anderen Tool verwenden. Wenn Sie eine Nachricht erhalten, dass Sie keine Berechtigung haben oder nicht autorisiert sind, fragen Sie den Administrator, welcher Zugriffstyp Ihnen erteilt wurde und in welchem Compartment  Sie arbeiten sollen.

Wenn Sie Mitglied der Administratorengruppe sind, besitzen Sie bereits die erforderliche Zugriffsberechtigung zur Einrichtung des Transitroutings. Andernfalls müssen Sie auf den Networking-Service zugreifen und Instanzen starten können. Siehe IAM-Policys für Networking.

VCN-Transitrouting in der Konsole einrichten

In diesem Abschnitt wird gezeigt, wie Sie über die Konsole Transitrouting mit einem VCN einrichten, um Ihrem On-Premise-Netzwerk Zugriff auf mehrere VCNs in derselben Region zu gewähren.

Für direktes Routing zwischen Gateways
Tipp

Viele der für dieses erweiterte Szenario erforderlichen Netzwerkkomponenten und Verbindungen sind möglicherweise bereits eingerichtet. Daher können Sie einige der folgenden Aufgaben eventuell überspringen. Wenn Sie bereits über eine Netzwerktopologie verfügen, bei der ein Hub-VCN mit Ihrem On-Premise-Netzwerk verbunden ist und Spoke-VCNs per lokalem Peering mit dem Hub-VCN verbunden sind, sind Aufgabe 5 und Aufgabe 6 am wichtigsten für Sie. Mit ihnen kann Traffic zwischen Ihrem On-Premise-Netzwerk und dem Spoke-VCN weitergeleitet werden.
Aufgabe 1: Hub-VCN einrichten
Diese Abbildung zeigt Aufgabe 1: Hub-VCN einrichten.

In dieser Aufgabe richten Sie das Hub-VCN ein. Ein Subnetz im Hub-VCN ist optional. Dieses Beispiel enthält jedoch eines. Das Subnetz kann Cloud-Ressourcen enthalten, die Ihr On-Premise-Netzwerk oder Spoke-VCN verwenden muss.

Weitere Informationen und Anweisungen finden Sie unter:

Aufgabe 2: Hub-VCN mit dem On-Premise-Netzwerk verbinden
Diese Abbildung zeigt Aufgabe 2: Hub-VCN mit dem On-Premise-Netzwerk verbinden.
Callout 1: Mit Subnet-H verknüpfte Routentabelle
Ziel-CIDR Routenziel
172.16.0.0/12 DRG
In dieser Aufgabe richten Sie entweder FastConnect oder Site-to-Site-VPN zwischen Ihrem Hub-VCN und Ihrem On-Premise-Netzwerk ein. Im Rahmen dieses Vorgangs hängen Sie ein DRG an das Hub-VCN an und richten das Routing zwischen dem Hub-VCN und Ihrem On-Premise-Netzwerk ein. Beachten Sie, dass Sie die die mit dem DRG-Anhang verknüpfte Routentabelle noch nicht erstellen. Dies erfolgt in einem späteren Schritt. Weitere Informationen und Anweisungen:
Aufgabe 3: Spoke-VCN mit mindestens einem Subnetz einrichten
Diese Abbildung zeigt Aufgabe 3: Spoke-VCN einrichten.

In dieser Aufgabe richten Sie das Spoke-VCN mit mindestens einem Subnetz ein. Weitere Informationen und Anweisungen finden Sie unter:

Aufgabe 4: Lokales Peering zwischen Hub-VCN und Spoke-VCN einrichten
Diese Abbildung zeigt Aufgabe 4: Lokales Peering zwischen Hub-VCN und Spoke-VCN einrichten.
Callout 1: Mit Subnet-H verknüpfte Routentabelle
Ziel-CIDR Routenziel
172.16.0.0/12 DRG
192.168.0.0/16 LPG-H-1
Callout 2: Mit Subnet-1 verknüpfte Routentabelle
Ziel-CIDR Routenziel
10.0.0.0/16 LPG-1
In dieser Aufgabe fügen Sie jedem VCN ein LPG hinzu, stellen eine Verbindung zwischen den LPGs her und richten das Routing ein, mit dem Ressourcen in einem VCN mit Ressourcen im anderen VCN kommunizieren können.
Wichtig

Stellen Sie beim Einrichten des lokalen Peerings zwischen zwei VCNs sicher, dass Sie die Verbindung zwischen den LPGs herstellen. Dieser Teil des Verfahrens kann leicht übersehen werden.
Beachten Sie, dass Sie die die mit dem LPG im Hub-VCN (LPG-H-1) verknüpfte Routentabelle noch nicht erstellen. Dies erfolgt in einem späteren Schritt. Weitere Informationen und Anweisungen:
Aufgabe 5: Dem Subnetz des Spoke-VCN eine Routingregel hinzufügen
Diese Abbildung zeigt Aufgabe 5: Dem Subnetz des Spoke-VCN eine Routingregel hinzufügen.
Callout 1: Mit Subnet-H verknüpfte Routentabelle
Ziel-CIDR Routenziel
172.16.0.0/12 DRG
192.168.0.0/16 LPG-H-1
Callout 2: Mit Subnet-1 verknüpfte Routentabelle
Ziel-CIDR Routenziel
10.0.0.0/16 LPG-1
172.16.0.0/12 LPG-1
In dieser Aufgabe fügen Sie der Routentabelle, die mit dem Subnetz des Spoke-VCN verknüpft ist, eine Regel hinzu. Diese Regel leitet den Traffic, der für das On-Premise-Netzwerk bestimmt ist, an das LPG des Spoke-VCN weiter (LPG-1 im Diagramm).Voraussetzungen: Sie verfügen bereits über ein LPG für das Spoke-VCN und eine mit dem Subnetz verknüpfte Routentabelle (im Spoke-VCN), die mit dem On-Premise-Netzwerk kommunizieren muss.
  1. Zeigen Sie für das Spoke-VCN die Liste der Subnetze an.
  2. Prüfen Sie die Details des betreffenden Subnetzes, und klicken Sie auf den Link für die zugehörige Routentabelle.

  3. Fügen Sie der Routentabelle eine Regel hinzu, die Traffic an das On-Premise-Netzwerk sendet:

    1. Klicken Sie auf Routingregeln hinzufügen.

    2. Geben Sie die folgenden Informationen für die Routingregel ein:

      • Zieltyp: Lokales Peering-Gateway.
      • Ziel-CIDR-Block: Das CIDR des On-Premise-Netzwerks (172.16.0.0/12 im vorherigen Beispiel).
      • Compartment: Das Compartment, in dem sich das LPG des Spoke-VCN befindet.
      • Lokales Ziel-Peering-Gateway: Das LPG des Spoke-VCN.
      • Beschreibung: Eine optionale Beschreibung der Regel.
    3. Klicken Sie auf Routingregeln hinzufügen.
Aufgabe 6: Ingress-Routing für das DRG und LPG im Hub-VCN einrichten
Diese Abbildung zeigt Aufgabe 7: Ingress-Routing zwischen dem DRG und dem LPG auf dem Hub-VCN einrichten.
Callout 1: Mit Subnet-H verknüpfte Routentabelle
Ziel-CIDR Routenziel
172.16.0.0/12 DRG
192.168.0.0/16 LPG-H-1
Callout 2: Mit Subnet-1 verknüpfte Routentabelle
Ziel-CIDR Routenziel
10.0.0.0/16 LPG-1
172.16.0.0/12 LPG-1
Callout 3: Mit dem DRG-Anhang verknüpfte Routentabelle
Ziel-CIDR Routenziel
192.168.0.0/16 LPG-H-1
Callout 4: Mit LPG-H-1 verknüpfte Routentabelle
Ziel-CIDR Routenziel
172.16.0.0/12 DRG

In dieser Aufgabe richten Sie die Routentabellen für den DRG-Anhang und das LPG für das Hub-VCN für den betreffenden Spoke (LPG-H-1) ein.

Voraussetzungen:

  • Es ist bereits ein DRG an das Hub-VCN angehängt.
  • Es ist bereits ein LPG für das Hub-VCN für den betreffenden Spoke vorhanden.

  1. Erstellen Sie eine Routentabelle für den DRG-Anhang:

    1. Zeigen Sie in der Konsole die Details des Hub-VCN an.
    2. Klicken Sie unter Ressourcen auf Routentabellen, um die Routentabellen des VCN anzuzeigen.
    3. Klicken Sie auf Routentabelle erstellen.

    4. Geben Sie Folgendes ein:

      • Name: Ein aussagekräftiger Name für die Routentabelle. Beispiel: DRG-Routentabelle. Geben Sie keine vertraulichen Informationen ein.
      • Erstellen in Compartment: Übernehmen Sie die Vorgabe.

    5. Klicken Sie auf + Weitere Routingregel, und geben Sie die folgenden Informationen für die Routingregel ein:

      • Zieltyp: Lokales Peering-Gateway.
      • Ziel-CIDR-Block: Das CIDR dieses Spoke-VCN (192.168.0.0/16 im vorherigen Beispiel). Beachten Sie, dass Sie über die Routen in dieser Tabelle steuern können, welche Subnetze im Spoke-VCN dem On-Premise-Netzwerk angeboten werden. Stattdessen können Sie die Regel so einrichten, dass nur ein bestimmtes Subnetz des Spoke-VCN aufgeführt wird, das vom On-Premise-Netzwerk angeboten wird.
      • Compartment: Das Compartment, in dem sich das LPG des Hub-VCN befindet.
      • Ziel: Das LPG des Hub-VCN.
      • Beschreibung: Eine optionale Beschreibung der Regel.

    6. Klicken Sie auf Routentabelle erstellen.

      Die Routentabelle wird erstellt und in der Liste angezeigt.

  2. Verknüpfen Sie die Routentabelle (in diesem Beispiel als DRG-Routentabelle bezeichnet) mit dem DRG-Anhang des Hub-VCN:

    1. Zeigen Sie die Details des VCN-Hub an, und klicken Sie auf Dynamische Routinggateways, um das angehängte DRG anzuzeigen.
    2. Klicken Sie auf das Menü Aktionen (Menü "Aktionen") Routentabelle verknüpfen.
    3. Wählen Sie die Routentabelle aus.

    4. Klicken Sie auf Routentabelle verknüpfen.

      Die Routentabelle wird mit dem DRG-Anhang verknüpft.

  3. Erstellen Sie eine Routentabelle für das LPG des Hub-VCN für diesen Spoke:

    1. Zeigen Sie die Details des Hub-VCN an, und klicken Sie auf Routentabellen.
    2. Klicken Sie auf Routentabelle erstellen.

    3. Geben Sie Folgendes ein:

      • Erstellen in Compartment: Übernehmen Sie die Vorgabe.
      • Name: Ein aussagekräftiger Name für die Routentabelle. Beispiel: Routentabelle für Hub-LPG-# (wobei # den Spoke angibt). Geben Sie keine vertraulichen Informationen ein.

    4. Klicken Sie auf + Weitere Routingregel, und geben Sie die folgenden Informationen für die Routingregel 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: Das CIDR des On-Premise-Netzwerks (172.16.0.0/12 im vorherigen Beispiel). Beachten Sie, dass Sie über die Routen in dieser Tabelle steuern können, welche Subnetze im On-Premise-Netzwerk diesem Spoke-VCN angeboten werden. Stattdessen können Sie die Regel so einrichten, dass nur ein Subnetz des On-Premise-Netzwerks aufgeführt wird, das mit diesem Spoke kommunizieren muss.
      • Beschreibung: Eine optionale Beschreibung der Regel.

    5. Klicken Sie auf Routentabelle erstellen.

      Die Routentabelle wird erstellt und in der Liste angezeigt.

  4. Verknüpfen Sie die Routentabelle (in diesem Beispiel als Routentabelle für Hub-LPG-# bezeichnet) mit dem LPG des Hub-VCN für den betreffenden Spoke:

    1. Zeigen Sie die Details des VCN-Hub an, und klicken Sie auf Lokale Peering-Gateways, um das LPG des Hub-VCN für diesen Spoke anzuzeigen.
    2. Klicken Sie für das gewünschte LPG auf das Menü Aktionen (Menü "Aktionen") und dann auf Mit Routentabelle verknüpfen.

    3. Geben Sie Folgendes ein:

      • Routentabellen-Compartment: Wählen Sie das Compartment der Routentabelle für das LPG aus.
      • Routentabelle: Wählen Sie die Routentabelle für das LPG aus.

    4. Klicken Sie auf Verknüpfen.

      Die Routentabelle wird mit dem LPG verknüpft.

Wenn Sie später weitere Spoke-VCNs benötigen
  1. Wiederholen Sie die Aufgaben 3 bis 5 für das neue Spoke-VCN.

  2. Wiederholen Sie Aufgabe 6 mit folgenden Änderungen:

    • Bei Schritt 1: Anstatt eine Routentabelle für den DRG-Anhang zu erstellen, nehmen Sie in die vorhandene Routentabelle eine neue Regel für das neue Spoke-VCN auf. Das Ziel-CIDR ist das CIDR des Spoke-VCN (oder ein Subnetz darin). Das Ziel ist das LPG des Hub-VCN für den neuen Spoke.
    • Bei Schritt 2: Überspringen Sie diesen Schritt vollständig, weil der DRG-Anhang bereits mit der dazugehörigen Routentabelle verknüpft ist.
    • Bei Schritt 3: Wiederholen Sie den Schritt wie beschrieben. Benennen Sie die neue Routentabelle entsprechend dem Spoke, auf den sich die Routentabelle bezieht (Beispiel: Routentabelle für Hub-LPG-2 für den zweiten Spoke).
    • Bei Schritt 4: Wiederholen Sie den Schritt wie beschrieben. Verknüpfen Sie die in Schritt 3 erstellte neue Routentabelle mit dem LPG des Hub-VCN für den neuen Spoke.
Für Routing über eine private IP
Tipp

Viele der für dieses erweiterte Szenario erforderlichen Netzwerkkomponenten und Verbindungen sind möglicherweise bereits eingerichtet. Daher können Sie einige der folgenden Aufgaben eventuell überspringen. Wenn Sie bereits über eine Netzwerktopologie verfügen, bei der ein Hub-VCN mit Ihrem On-Premise-Netzwerk verbunden ist und Spoke-VCNs per lokalem Peering mit dem Hub-VCN verbunden sind, sind die Aufgaben 5 bis 7 am wichtigsten für Sie. Mit ihnen kann Traffic zwischen Ihrem On-Premise-Netzwerk und dem Spoke-VCN weitergeleitet werden.
Aufgabe 1: Hub-VCN einrichten
Diese Abbildung zeigt Aufgabe 1: Hub-VCN einrichten.

In dieser Aufgabe richten Sie das Hub-VCN ein. Das Hub-VCN muss zwei Subnetze haben: eines für die Frontend-VNIC auf der Instanz und eines für die Backend-VNIC auf der Instanz. Oracle empfiehlt die Verwendung von regionalen privaten Subnetzen, es sei denn, das Frontend-Subnetz enthält Ressourcen, die Internetzugriff benötigen.

Weitere Informationen und Anweisungen finden Sie unter:

Aufgabe 2: Hub-VCN mit dem On-Premise-Netzwerk verbinden
Diese Abbildung zeigt Aufgabe 2: Hub-VCN mit dem On-Premise-Netzwerk verbinden.
Callout 1: Mit Subnet-H-Frontend verknüpfte Routentabelle
Ziel-CIDR Routenziel
172.16.0.0/12 DRG
192.168.0.0/16 10.0.4.3
In dieser Aufgabe richten Sie entweder FastConnect oder Site-to-Site-VPN zwischen Ihrem Hub-VCN und Ihrem On-Premise-Netzwerk ein. Im Rahmen dieses Vorgangs hängen Sie ein DRG an das Hub-VCN an und richten das Routing zwischen dem Hub-VCN und Ihrem On-Premise-Netzwerk ein. Beachten Sie, dass Sie die die mit dem DRG-Anhang verknüpfte Routentabelle noch nicht erstellen. Dies erfolgt in einem späteren Schritt. Weitere Informationen und Anweisungen:
Aufgabe 3: Spoke-VCN mit mindestens einem Subnetz einrichten
Diese Abbildung zeigt Aufgabe 3: Spoke-VCN einrichten.
Callout 1: Mit Subnet-H-Frontend verknüpfte Routentabelle
Ziel-CIDR Routenziel
172.16.0.0/12 DRG
192.168.0.0/16 10.0.4.3

In dieser Aufgabe richten Sie das Spoke-VCN mit mindestens einem Subnetz ein. Weitere Informationen und Anweisungen finden Sie unter:

Aufgabe 4: Lokales Peering zwischen Hub-VCN und Spoke-VCN einrichten
Diese Abbildung zeigt Aufgabe 4: Lokales Peering zwischen Hub-VCN und Spoke-VCN einrichten.
Callout 1: Mit Subnet-H-Frontend verknüpfte Routentabelle
Ziel-CIDR Routenziel
172.16.0.0/12 DRG
192.168.0.0/16 10.0.4.3
Callout 2: Mit Subnet-H-Backend verknüpfte Routentabelle
Ziel-CIDR Routenziel
192.168.0.0/16 LPG-H-1
172.16.0.0/12 10.0.8.3
Callout 3: Mit Subnet-1 verknüpfte Routentabelle
Ziel-CIDR Routenziel
10.0.0.0/16 LPG-1
172.16.0.0/12 LPG-1
In dieser Aufgabe fügen Sie jedem VCN ein LPG hinzu, stellen eine Verbindung zwischen den LPGs her und richten das Routing ein, mit dem Ressourcen in einem VCN mit Ressourcen im anderen VCN kommunizieren können.
Wichtig

Stellen Sie beim Einrichten des lokalen Peerings zwischen zwei VCNs sicher, dass Sie die Verbindung zwischen den LPGs herstellen. Dieser Teil des Verfahrens kann leicht übersehen werden.
Beachten Sie, dass Sie die die mit dem LPG im Hub-VCN (LPG-H-1) verknüpfte Routentabelle noch nicht erstellen. Dies erfolgt in einem späteren Schritt. Weitere Informationen und Anweisungen:
Aufgabe 5: Dem Subnetz des Spoke-VCN eine Routingregel hinzufügen
Diese Abbildung zeigt Aufgabe 5: Dem Subnetz des Spoke-VCN eine Routingregel hinzufügen.
Callout 1: Mit Subnet-H-Frontend verknüpfte Routentabelle
Ziel-CIDR Routenziel
172.16.0.0/12 DRG
192.168.0.0/16 10.0.4.3
Callout 2: Mit Subnet-H-Backend verknüpfte Routentabelle
Ziel-CIDR Routenziel
192.168.0.0/16 LPG-H-1
172.16.0.0/12 10.0.8.3
Callout 3: Mit Subnet-1 verknüpfte Routentabelle
Ziel-CIDR Routenziel
10.0.0.0/16 LPG-1
172.16.0.0/12 LPG-1
In dieser Aufgabe fügen Sie der Routentabelle, die mit dem Subnetz des Spoke-VCN verknüpft ist, eine Regel hinzu. Diese Regel leitet den Traffic, der für das On-Premise-Netzwerk bestimmt ist, an das LPG des Spoke-VCN weiter (LPG-1 im Diagramm).Voraussetzungen: Sie verfügen bereits über ein LPG für das Spoke-VCN und eine mit dem Subnetz verknüpfte Routentabelle (im Spoke-VCN), die mit dem On-Premise-Netzwerk kommunizieren muss.
  1. Zeigen Sie für das Spoke-VCN die Liste der Subnetze an.
  2. Prüfen Sie die Details des betreffenden Subnetzes, und klicken Sie auf den Link für die zugehörige Routentabelle.

  3. Fügen Sie der Routentabelle eine Regel hinzu, die Traffic an das On-Premise-Netzwerk sendet:

    1. Klicken Sie auf Routingregeln hinzufügen.

    2. Geben Sie die folgenden Informationen für die Routingregel ein:

      • Zieltyp: Lokales Peering-Gateway.
      • Ziel-CIDR-Block: Das CIDR des On-Premise-Netzwerks (172.16.0.0/12 im vorherigen Beispiel).
      • Compartment: Das Compartment, in dem sich das LPG des Spoke-VCN befindet.
      • Lokales Ziel-Peering-Gateway: Das LPG des Spoke-VCN.
      • Beschreibung: Eine optionale Beschreibung der Regel.
    3. Klicken Sie auf Routingregeln hinzufügen.
Aufgabe 6: Private IPs in einer Instanz im Hub-VCN einrichten
Diese Abbildung zeigt Aufgabe 6: Instanz im Hub-VCN einrichten.
Callout 1: Mit Subnet-H-Frontend verknüpfte Routentabelle
Ziel-CIDR Routenziel
172.16.0.0/12 DRG
192.168.0.0/16 10.0.4.3
Callout 2: Mit Subnet-H-Backend verknüpfte Routentabelle
Ziel-CIDR Routenziel
192.168.0.0/16 LPG-H-1
172.16.0.0/12 10.0.8.3
Callout 3: Mit Subnet-1 verknüpfte Routentabelle
Ziel-CIDR Routenziel
10.0.0.0/16 LPG-1
172.16.0.0/12 LPG-1

In dieser Aufgabe richten Sie die Instanz mit zwei privaten IPs ein.

Voraussetzungen:

  1. Falls noch nicht geschehen, erstellen Sie die Instanz im Hub-VCN. Siehe Instanz erstellen. Die primäre VNIC wird im angegebenen Subnetz erstellt.
  2. Erstellen Sie eine sekundäre VNIC für das andere Subnetz, und konfigurieren Sie deren Verwendung im Betriebssystem. Siehe Konsole verwenden.
  3. Deaktivieren Sie die Quell-/Zielprüfung für jede der VNICs. Siehe VNICs und physische NICs - Überblick.
  4. Legen Sie für jede VNIC fest, welche private IP als Routingziel verwendet werden soll. Wenn Sie anstelle der primären privaten IP der VNIC eine sekundäre private IP verwenden möchten, weisen Sie diese sekundäre private IP zu, und konfigurieren Sie deren Verwendung im Betriebssystem. Siehe Neue sekundäre private IP zu einer VNIC zuweisen.
  5. Notieren Sie für jede der von Ihnen erstellten privaten IPs die private IP-Adresse (Beispiel: 10.0.4.3).
  6. Konfigurieren Sie die Instanz nach Bedarf für den ausgeführten Job (Beispiel: Konfigurieren Sie die Firewall oder ein Angriffserkennungssystem in der Instanz).
Aufgabe 7: Ingress-Routing für das DRG und LPG im Hub-VCN einrichten
Diese Abbildung zeigt die Routentabellen und Routingregeln, die bei der Einrichtung des Szenarios mit einer virtuellen Netzwerk-Appliance im Hub-VCN erforderlich sind.
Callout 1: Mit Subnet-H-Frontend verknüpfte Routentabelle
Ziel-CIDR Routenziel
172.16.0.0/12 DRG
192.168.0.0/16 10.0.4.3
Callout 2: Mit Subnet-H-Backend verknüpfte Routentabelle
Ziel-CIDR Routenziel
192.168.0.0/16 LPG-H-1
172.16.0.0/12 10.0.8.3
Callout 3: Mit Subnet-1 verknüpfte Routentabelle
Ziel-CIDR Routenziel
10.0.0.0/16 LPG-1
172.16.0.0/12 LPG-1
Callout 4: Mit dem DRG-Anhang verknüpfte Routentabelle
Ziel-CIDR Routenziel
192.168.0.0/16 10.0.4.3
Callout 5: Mit LPG-H-1 verknüpfte Routentabelle
Ziel-CIDR Routenziel
172.16.0.0/12 10.0.8.3

Mit LPG-1 ist keine spezielle Routentabelle verknüpft.

In dieser Aufgabe richten Sie die Routentabellen für den DRG-Anhang und das LPG für das Hub-VCN für den betreffenden Spoke (LPG-H-1) ein.

Voraussetzungen:

  • Es ist bereits ein DRG an das Hub-VCN angehängt.
  • Es ist bereits ein LPG für das Hub-VCN für den betreffenden Spoke vorhanden.
  • Sie verfügen bereits über die zwei privaten IPs, die als Routingziele verwendet werden sollen (siehe vorherige Aufgabe).

  1. Erstellen Sie eine Routentabelle für den DRG-Anhang:

    1. Zeigen Sie in der Konsole die Details des Hub-VCN an.
    2. Klicken Sie unter Ressourcen auf Routentabellen, um die Routentabellen des VCN anzuzeigen.
    3. Klicken Sie auf Routentabelle erstellen.

    4. Geben Sie Folgendes ein:

      • Name: Ein aussagekräftiger Name für die Routentabelle. Beispiel: DRG-Routentabelle. Geben Sie keine vertraulichen Informationen ein.
      • Erstellen in Compartment: Übernehmen Sie die Vorgabe.

    5. Klicken Sie auf + Weitere Routingregel, und geben Sie die folgenden Informationen für die Routingregel ein:

      • Zieltyp: Private IP.
      • Ziel-CIDR-Block: Das CIDR dieses Spoke-VCN (192.168.0.0/16 im vorherigen Beispiel). Beachten Sie, dass Sie über die Routen in dieser Tabelle steuern können, welche Subnetze im Spoke-VCN dem On-Premise-Netzwerk angeboten werden. Stattdessen können Sie die Regel so einrichten, dass nur ein bestimmtes Subnetz des Spoke-VCN aufgeführt wird, das vom On-Premise-Netzwerk angeboten wird.
      • Compartment: Das Compartment, in dem sich die private IP des Frontend-Subnetzes befindet.
      • Ziel: Die private IP des Frontend-Subnetzes, die Sie sich in der vorherigen Aufgabe notiert haben (Beispiel: 10.0.4.3).
      • Beschreibung: Eine optionale Beschreibung der Regel.

    6. Klicken Sie auf Routentabelle erstellen.

      Die Routentabelle wird erstellt und in der Liste angezeigt.

  2. Verknüpfen Sie die Routentabelle (in diesem Beispiel als DRG-Routentabelle bezeichnet) mit dem DRG-Anhang des Hub-VCN:

    1. Zeigen Sie die Details des VCN-Hub an, und klicken Sie auf Dynamische Routinggateways, um das angehängte DRG anzuzeigen.
    2. Klicken Sie auf das Menü Aktionen (Menü "Aktionen") und dann auf Mit Routentabelle verknüpfen.

    3. Geben Sie Folgendes ein:

      • Routentabellen-Compartment: Wählen Sie das Compartment der Routentabelle für den DRG-Anhang aus.
      • Routentabelle: Wählen Sie die Routentabelle für den DRG-Anhang aus.

    4. Klicken Sie auf Verknüpfen.

      Die Routentabelle wird mit dem DRG-Anhang verknüpft.

  3. Erstellen Sie eine Routentabelle für das LPG des Hub-VCN für diesen Spoke:

    1. Zeigen Sie die Details des Hub-VCN an, und klicken Sie auf Routentabellen.
    2. Klicken Sie auf Routentabelle erstellen.

    3. Geben Sie Folgendes ein:

      • Erstellen in Compartment: Übernehmen Sie die Vorgabe.
      • Name: Ein aussagekräftiger Name für die Routentabelle. Beispiel: Routentabelle für Hub-LPG-# (wobei # den Spoke angibt). Geben Sie keine vertraulichen Informationen ein.

    4. Klicken Sie auf + Weitere Routingregel, und geben Sie die folgenden Informationen für die Routingregel ein:

      • Zieltyp: Private IP.
      • Ziel-CIDR-Block: Das CIDR des On-Premise-Netzwerks (172.16.0.0/12 im vorherigen Beispiel). Beachten Sie, dass Sie über die Routen in dieser Tabelle steuern können, welche Subnetze im On-Premise-Netzwerk diesem Spoke-VCN angeboten werden. Stattdessen können Sie die Regel so einrichten, dass nur ein Subnetz des On-Premise-Netzwerks aufgeführt wird, das mit diesem Spoke kommunizieren muss.
      • Compartment: Das Compartment, in dem sich die private IP befindet.
      • Ziel: Die private IP des Backend-Subnetzes, die Sie sich in der vorherigen Aufgabe notiert haben (Beispiel: 10.0.8.3).
      • Beschreibung: Eine optionale Beschreibung der Regel.

    5. Klicken Sie auf Routentabelle erstellen.

      Die Routentabelle wird erstellt und in der Liste angezeigt.

  4. Verknüpfen Sie die Routentabelle (in diesem Beispiel als Routentabelle für Hub-LPG-# bezeichnet) mit dem LPG des Hub-VCN für den betreffenden Spoke:

    1. Zeigen Sie die Details des VCN-Hub an, und klicken Sie auf Lokale Peering-Gateways, um das LPG des Hub-VCN für diesen Spoke anzuzeigen.
    2. Klicken Sie für das gewünschte LPG auf das Menü Aktionen (Menü "Aktionen") und dann auf Mit Routentabelle verknüpfen.

    3. Geben Sie Folgendes ein:

      • Routentabellen-Compartment: Wählen Sie das Compartment der Routentabelle für das LPG aus.
      • Routentabelle: Wählen Sie die Routentabelle für das LPG aus.

    4. Klicken Sie auf Verknüpfen.

      Die Routentabelle wird mit dem LPG verknüpft.

Auch wenn Oracle keine Workloads in den Subnetzen des Hub-VCN empfiehlt, zeigt das Diagramm zwei zusätzliche Routingregeln in den Subnetzroutentabellen des Hub-VCN, um Ihnen einen besseren Überblick über das Routing in dem Beispiel zu vermitteln. Für das Frontend-Subnetz gibt es eine Routingregel, mit der der Traffic, der für das Spoke-VCN bestimmt ist, zwecks Filterung durch die Instanz zur privaten IP im Frontend-Subnetz (10.0.4.3) weitergeleitet wird. Für das Backend-Subnetz gibt es eine Routingregel, mit der der Traffic, der für das On-Premise-Netzwerk bestimmt ist, zwecks Filterung durch die Instanz zur privaten IP im Backend-Subnetz (10.0.8.3) weitergeleitet wird. Das folgende Verfahren fügt diese beiden Routingregeln hinzu.

  1. Zeigen Sie für das Spoke-VCN die Liste der Subnetze an.
  2. Prüfen Sie die Details des Frontend-Subnetzes, und klicken Sie auf den Link für die zugehörige Routentabelle.

  3. Fügen Sie der Routentabelle des Frontend-Subnetzes eine Regel hinzu, die Traffic, der für das Spoke-VCN bestimmt ist, an die private IP im Frontend-Subnetz sendet:

    1. Klicken Sie auf Routingregeln hinzufügen.

    2. Geben Sie die folgenden Informationen für die Routingregel ein:

      • Zieltyp: Private IP.
      • Ziel-CIDR-Block: Das CIDR dieses Spoke-VCN (192.168.0.0/16 im vorherigen Beispiel).
      • Compartment: Das Compartment, in dem sich die private IP des Frontend-Subnetzes befindet.
      • Ziel: Die private IP des Frontend-Subnetzes, die Sie sich in der vorherigen Aufgabe notiert haben (Beispiel: 10.0.4.3).
      • Beschreibung: Eine optionale Beschreibung der Regel.
    3. Klicken Sie auf Routingregeln hinzufügen.
  4. Prüfen Sie die Details des Backend-Subnetzes, und klicken Sie auf den Link für die zugehörige Routentabelle.

  5. Fügen Sie der Routentabelle des Backend-Subnetzes eine Regel hinzu, die Traffic, der für das On-Premise-Netzwerk bestimmt ist, an die private IP im Backend-Subnetz sendet:

    1. Klicken Sie auf Routingregeln hinzufügen.

    2. Geben Sie die folgenden Informationen für die Routingregel ein:

      • Zieltyp: Private IP.
      • Ziel-CIDR-Block: Das CIDR des On-Premise-Netzwerks (172.16.0.0/12 im vorherigen Beispiel).
      • Compartment: Das Compartment, in dem sich die private IP des Backend-Subnetzes befindet.
      • Ziel: Die private IP des Backend-Subnetzes, die Sie sich in der vorherigen Aufgabe notiert haben (Beispiel: 10.0.8.3).
      • Beschreibung: Eine optionale Beschreibung der Regel.
    3. Klicken Sie auf Routingregeln hinzufügen.
Wenn Sie später weitere Spoke-VCNs benötigen
  1. Wiederholen Sie die Aufgaben 3 bis 5 für das neue Spoke-VCN.

  2. Wiederholen Sie Aufgabe 7 mit folgenden Änderungen:

    • Bei Schritt 1: Anstatt eine Routentabelle für den DRG-Anhang zu erstellen, nehmen Sie in die vorhandene Routentabelle eine neue Regel für das neue Spoke-VCN auf. Das Ziel-CIDR ist das CIDR des Spoke-VCN (oder ein Subnetz darin). Das Ziel ist die private IP 10.0.4.3 des Frontend-Subnetzes.
    • Bei Schritt 2: Überspringen Sie diesen Schritt vollständig, weil der DRG-Anhang bereits mit der dazugehörigen Routentabelle verknüpft ist.
    • Bei Schritt 3: Wiederholen Sie den Schritt wie beschrieben. Benennen Sie die neue Routentabelle entsprechend dem Spoke, auf den sich die Routentabelle bezieht (Beispiel: Routentabelle für Hub-LPG-2 für den zweiten Spoke).
    • Bei Schritt 4: Wiederholen Sie den Schritt wie beschrieben. Verknüpfen Sie die in Schritt 3 erstellte neue Routentabelle mit dem LPG des Hub-VCN für den neuen Spoke.

Transitrouting deaktivieren

Um das Transitrouting zu deaktivieren, entfernen Sie die Regeln aus:

  • Der Routentabelle, die mit dem DRG-Anhang verknüpft ist.
  • Der Routentabelle, die mit den einzelnen LPGs im Hub-VCN verknüpft ist.

Eine Routentabelle kann mit einer Ressource verknüpft sein, ohne jedoch Regeln aufzuweisen. Ohne mindestens eine Regel führt eine Routentabelle keine Aktion durch.

Ein DRG-Anhang oder ein LPG kann ohne zugehörige Routentabelle vorhanden sein. Sobald Sie einen DRG-Anhang oder ein LPG jedoch mit einer Routentabelle verknüpft haben, muss immer eine Routentabelle damit verknüpft sein. Sie können jedoch eine andere Routentabelle mit dem LPG verknüpfen. Sie können auch die Regeln der Tabelle bearbeiten sowie einige oder alle Regeln löschen.

Änderungen an der API

Informationen über Änderungen an der API des Networking-Service zur Unterstützung von Transitrouting finden Sie in den Versionshinweisen zum Transitrouting.