VCN-Routentabellen

Mit Routentabellen und Routingregeln arbeiten

Jedes VCN ist automatisch mit einer standardmäßigen Routentabelle mit impliziten Regeln ausgestattet, die die Routen für VCN-CIDRs enthalten. Wenn Sie nichts anderes angeben, verwendet jedes Subnetz die Standardroutentabelle des VCN. Wenn Sie Routingregeln zu einem VCN hinzufügen, können Sie sie der Standardtabelle hinzufügen. Bei Bedarf können Sie jedoch benutzerdefinierte Routentabellen für jedes Subnetz erstellen. Beispiel: Wenn Sie ein öffentliches Subnetz und ein privates Subnetz in einem VCN verwenden (ein Beispiel dafür finden Sie in Szenario C: Öffentliche und private Subnetze mit einem VPN), müssen Sie verschiedene Routentabellen für die Subnetze verwenden, da die Routingregeln für die Subnetze unterschiedlich sein müssen.

Jedes Subnetz in einem VCN verwendet eine einzige Routentabelle. Beim Erstellen des Subnetzes geben Sie an, welche Tabelle verwendet werden soll. Sie können jederzeit ändern, welche Routentabelle das Subnetz verwenden soll. Sie können auch die Regeln einer Routentabelle bearbeiten oder alle Regeln aus der Tabelle entfernen.

Bei der Erstellung einer benutzerdefinierten Routentabelle können Sie ihr optional einen aussagekräftigen Namen zuweisen. Er muss nicht eindeutig sein und kann später geändert werden. Oracle weist der Routentabelle automatisch eine eindeutige ID zu, die als Oracle Cloud-ID (OCID) bezeichnet wird. Weitere Informationen finden Sie unter Ressourcen-IDs.

Eine Routingregel gibt einen Ziel-CIDR-Block und das Ziel (den nächsten Hop) für allen Traffic an, der mit diesem CIDR übereinstimmt. Im Folgenden werden die zulässigen Zieltypen für eine Routingregel aufgeführt:

• Dynamisches Routinggateway (DRG): Für Subnetze, die privaten Zugriff auf Netzwerke benötigen, die mit einem VCN verbunden sind (Beispiel: ein On-Premise-Netzwerk, das mit einem Site-to-Site-VPN oder FastConnect verbunden ist, ein Peer-VCN in derselben Region oder ein Peer-VCN in einer anderen Region).
• Internetgateway: Für öffentliche Subnetze, die direkten Zugriff auf das Internet benötigen.
• NAT-Gateway: Für Subnetze mit Instanzen, die keine öffentlichen IP-Adressen haben, aber Zugriff auf das Internet benötigen.
• Servicegateway: Für Subnetze, die privaten Zugriff auf Oracle-Services wie Object Storage benötigen.
• Lokales Peering-Gateway (LPG): Für Subnetze, die privaten Zugriff auf ein Peer-VCN in derselben Region benötigen.
• Private IP: Für Subnetze, die Traffic an eine Instanz im VCN weiterleiten müssen. Weitere Informationen finden Sie unter Private IP als Routingziel verwenden. Siehe auch Routing in einem VCN - Überblick.

Wenn Sie eine Routingregel zu einer Routentabelle hinzufügen, geben Sie den Ziel-CIDR-Block und das Ziel (sowie das Compartment , in dem das Ziel gespeichert ist) an. Ausnahme: Wenn das Ziel ein Servicegateway  ist, geben Sie anstelle eines Ziel-CIDR-Blocks eine von Oracle bereitgestellte Zeichenfolge an, die die öffentlichen Endpunkte für den betreffenden Service darstellt. Auf diese Weise müssen Sie nicht alle CIDR-Blöcke des Service kennen, die sich im Laufe der Zeit ändern können.

Wenn Sie eine Regel falsch konfigurieren (z.B. den falschen Ziel-CIDR-Block eingeben), kann der zu routende Netzwerktraffic unterbrochen (verworfen) oder an ein unbeabsichtigtes Ziel gesendet werden.

Sie können eine Routentabellen von einem Compartment in ein anderes verschieben. Das Verschieben einer Routentabelle wirkt sich nicht auf ihre Verbindung zu VCNs oder Subnetzen aus. Wenn Sie eine Routentabelle in ein neues Compartment verschieben, werden inhärente Policys sofort wirksam, wodurch der Zugriff auf die Routentabelle beeinflusst wird. Weitere Informationen finden Sie unter Zugriffskontrolle.

Sie können die Standardroutentabelle eines VCN nicht löschen. Um eine benutzerdefinierte Routentabelle zu löschen, darf diese nicht mit einem Subnetz oder einem Gateway verknüpft sein, wie DRG, LPG, IGW, NGW oder SGW.

In den Servicelimits finden Sie eine Liste der jeweiligen Limits sowie Anweisungen dazu, wie Sie eine Erhöhung beantragen.

Intra-VCN-Routing

Mit dem Intra-VCN-Routing können Sie die standardmäßigen Routingentscheidungen überschreiben, die auf Traffic angewendet werden, der für IP-Adressen im VCN-CIDR-Block bestimmt ist. Intra-VCN-Routing bietet die folgenden Funktionen:

• Lokale Routen: Jedes VCN leitet den Traffic innerhalb des VCN und zwischen den VCN-Subnetzen automatisch weiter, sofern Sie keine anderen Routingregeln hinzufügen. Der lokale Traffic verwendet die Routentabelle, die mit dem Subnetz verknüpft ist, einschließlich des lokalen Routings innerhalb des VCN-CIDR.
• Benutzerdefinierte Intra-VCN-Routen: Dies sind Routingregeln, die Sie in der VCN- oder Subnetzroutentabelle für Intra-VCN-Traffic erstellen und normale lokale Routen außer Kraft setzen können. Alle benutzerdefinierten Intra-VCN-Routen haben ein Ziel (DRG, LPG oder private IP im VCN) und den Routentyp Statisch.
• Beste Route auswählen: Die längste Präfixübereinstimmung (oder die spezifischste Route) wird ausgewählt. Wenn mehrere Routen für dasselbe Präfix möglich sind, wird die beste Route basierend auf der folgenden Routentyppriorität ausgewählt:
  1. Statische Routen (benutzerdefiniert)
  2. In der Routentabelle nicht sichtbare implizite lokale Routen (werden automatisch von OCI erstellt)
• IPv6: OCI unterstützt das Intra-VCN-Routing für IPv6-VCN-Präfixe.

Verwendung des Intra-VCN-Routings

Die folgende Abbildung zeigt ein Beispiel für internes Routing:

Routing pro Ressource

Mit dem Ressourcen-Routing können Sie einer oder mehreren VNICs oder bestimmten IP-Adressen in einer VNIC eine benutzerdefinierte VCN-Routentabelle zuweisen. Eine IP-Adresse mit einer zugewiesenen Routentabelle kann eine primäre oder sekundäre IP-Adresse für die VNIC sein. Beim Routing pro Ressource gilt eine hierarchische Voreinstellung in Bezug auf die Routentabelle, die für den Routing-Lookup verwendet werden soll: Die Routentabelle in der IP-Adresse wird der Routentabelle in der VNIC vorgezogen, und die Routentabelle in einer VNIC wird der Routentabelle im Subnetz vorgezogen. Der Auswahlprozess für die Routentabelle lautet wie folgt:

1. Wenn der VNIC-IP-Adresse eine eigene Routentabelle zugeordnet ist, wird diese Routentabelle verwendet, um Traffic von der IP-Adresse weiterzuleiten.
2. Wenn eine VNIC-IP-Adresse keine eigene Routentabelle aufweist, wird die Routentabelle auf VNIC-Ebene verwendet, um Traffic von der IP-Adresse weiterzuleiten.
3. Wenn eine VNIC über eine verknüpfte Route verfügen kann, verwenden alle IP-Adressen in der VNIC, denen keine Routentabelle zugeordnet ist, die VNIC-Routentabelle.
4. Wenn einer VNIC keine Routentabelle zugeordnet ist, verwenden alle IP-Adressen der VNIC, denen keine Routentabelle zugeordnet ist, die Routentabelle des Subnetzes.

Die folgende Abbildung zeigt ein Beispiel für die Verwendung von Ressourcen-Routing:

In diesem Beispiel wird für eine OCI Compute-Instanz mit zwei VNICs im selben Subnetz eine Anwendung ausgeführt, die Zugriff auf das Internet sowie auf Datenbanken oder andere Ressourcen im On-Premise-Data Center benötigt. Die Anwendung verwendet VNIC A für den gesamten Traffic, der für ein On-Premise-Netzwerk und VNIC B für den gesamten internetgebundenen Traffic gebunden ist. Der Cloud-Netzwerkadministrator kann eine benutzerdefinierte Routentabelle mit VNIC A verknüpfen, wobei die Standardroute das DRG als Ziel enthält, und den gesamten Traffic von VNIC A an das DRG weiterleiten. Eine zweite benutzerdefinierte Routentabelle ist mit VNIC B verknüpft, wobei die Standardroute das Internetgateway als Ziel aufweist und den gesamten Traffic von VNIC B an das Internetgateway weiterleitet.

Ein Vorteil hierbei ist, dass die Regeln aufgrund statischer Regeln vor Änderungen in den CIDR-Blöcken isoliert sind, die im On-Premise-Data Center verwendet werden. Alle Änderungen in der On-Premise-Umgebung werden mit BGP-Advertisement für das DRG freigegeben, und die VCN-Routentabellen können einfach und stabil sein.

Gateway-Ingress-Routing

Erforderliche IAM Policy

Allgemeine Anwendungsfälle

OCI verwendet die Routentabelle eines Subnetzes, um Traffic an eine Ziel-IP-Adresse außerhalb des Subnetzes weiterzuleiten. Wenn sich das Ziel außerhalb des VCN befindet, richten Sie in der Regel eine Routingregel ein, um den Traffic an ein Gateway im VCN weiterzuleiten (z.B. ein DRG, das mit einem On-Premise-Netzwerk oder einem anderen VCN verbunden ist, oder ein Internetgateway, das mit dem Internet verbunden ist). Wenn sich das Ziel in einem anderen Subnetz desselben VCN befindet, wird der Traffic standardmäßig mit der lokalen Route für das VCN-CIDR weitergeleitet. Möglicherweise möchten Sie diesen Traffic jedoch zuerst über eine Instanz im VCN weiterleiten. In diesem Fall können Sie eine private IP im VCN anstelle eines Gateways im VCN als Ziel verwenden. Dies kann beispielsweise folgende Gründe haben:

• Zur Implementierung einer virtuellen Netzwerk-Appliance (NVA) wie einer Firewall oder zur Angriffserkennung, um ausgehenden Traffic aus Instanzen zu filtern.
• Zur Verwaltung eines Overlay-Netzwerks im VCN, mit dem Sie Containerorchestrierungs-Workloads ausführen können.
• Zur Implementierung von NAT (Network Address Translation) im VCN. Oracle empfiehlt stattdessen die Verwendung eines NAT-Gateways für das VCN. Im Allgemeinen schafft NAT ausgehende Internetzugänge für Instanzen, die keine direkte Internetkonnektivität besitzen.

Um diese Anwendungsfälle zu implementieren, ist mehr als das Routing von Traffic an die Instanz erforderlich. Die Konfiguration ist auch für die Instanz selbst erforderlich.

Anforderungen zur Verwendung einer privaten IP als Ziel

• Die private IP muss sich in demselben VCN wie die Routentabelle befinden.
• Die VNIC der privaten IP muss so konfiguriert werden, dass die Quell-/Zielprüfung übersprungen wird, damit die VNIC Traffic weiterleiten kann. Standardmäßig ist diese Prüfung auf den VNICs konfiguriert. Weitere Informationen finden Sie unter VNICs und physische NICs - Überblick.
• Sie müssen die Instanz selbst so konfigurieren, dass Pakete weitergeleitet werden.

• Die Routingregel muss die OCID der privaten IP und nicht die IP-Adresse selbst als Ziel angeben. Ausnahme: Wenn Sie die Konsole verwenden, können Sie stattdessen die private IP-Adresse selbst als Ziel angeben. Die Konsole verwendet dann die OCID, die der privaten IP-Adresse in der Regel entspricht.

  Wichtig
  
  

  Eine Routingregel mit einem privaten IP-Ziel kann in folgenden Fällen zum Verwerfen des Traffics führen:

  • Die Instanz, der die private IP zugewiesen ist, wird gestoppt oder beendet
  • Die VNIC, der die private IP zugewiesen ist, wird aktualisiert, um die Quell-/Zielprüfung zu aktivieren, oder wird gelöscht
  • Die Zuweisung der privaten IP zur VNIC wird aufgehoben

  Wenn ein privates IP-Ziel beendet wird, wird in der Konsole in der Routingregel ein Hinweis angezeigt, dass die Ziel-OCID nicht mehr vorhanden ist.

  Bei Failover: Wenn eine Zielinstanz beendet wird, bevor Sie die sekundäre private IP in eine Standby-Datenbank verschieben können, müssen Sie die Routingregel so aktualisieren, dass die OCID des neuen privaten IP-Ziels in der Standby-Datenbank verwendet wird. Die Regel verwendet die OCID des Ziels und nicht die private IP-Adresse selbst.

Allgemeiner Setupprozess

1. Entscheiden Sie, welche Instanz Sie den Traffic erhalten und weiterleiten möchten.
2. Wählen Sie eine private IP für die Instanz (kann sich auf der primären VNIC der Instanz oder auf einer sekundären VNIC befinden). Um Failover zu implementieren, richten Sie eine sekundäre private IP auf einer der VNICs in der Instanz ein.
3. Deaktivieren Sie die Quell-/Zielprüfung für die VNIC der privaten IP. Siehe VNICs und physische NICs - Überblick.
4. Rufen Sie die OCID für die private IP ab. Wenn Sie die Konsole verwenden, können Sie entweder die OCID oder die private IP-Adresse selbst zusammen mit dem Namen des Compartments der privaten IP abrufen.
5. Zeigen Sie für das Subnetz, das Traffic an die private IP weiterleiten muss, die Routentabelle des Subnetzes an. Wenn die Tabelle bereits eine Regel mit demselben Ziel-CIDR, aber einem anderen Ziel enthält, löschen Sie diese Regel.

6. Fügen Sie eine Routingregel mit folgenden Angaben hinzu:

   • Zieltyp: Siehe Liste der Zieltypen unter Routing im Überblick über ein VCN. Wenn der Zieltyp ein DRG ist, wird das an das VCN angehängte DRG automatisch als Ziel ausgewählt, und Sie müssen das Ziel nicht selbst angeben. Wenn das Ziel ein privates IP-Objekt ist, müssen Sie vor der Angabe des Ziels zuerst die Quell-/Zielprüfung für die VNIC deaktivieren, die dieses private IP-Objekt verwendet. Weitere Informationen finden Sie unter Private IP als Routingziel verwenden.
   • Ziel-CIDR-Block: Nur verfügbar, wenn das Ziel kein Servicegateway ist. Dieser Wert entspricht dem Ziel-CIDR-Block für den Traffic. Sie können einen bestimmten Ziel-CIDR-Block angeben. Verwenden Sie 0.0.0.0/0, wenn der gesamte Traffic, der das Subnetz verlässt, an das in dieser Regel angegebene Ziel weitergeleitet werden muss.
   • Zielservice: Nur verfügbar, wenn das Ziel ein Servicegateway ist. Dieser Wert entspricht dem gewünschten Service-CIDR-Label.
   • Compartment: Das Compartment mit dem Ziel.
   • Ziel: Das Ziel. Wenn das Ziel ein privates IP-Objekt ist, geben Sie die zugehörige OCID ein. Sie können auch die private IP-Adresse selbst eingeben. In diesem Fall sucht die Konsole die entsprechende OCID und verwendet sie als Ziel für die Routingregel.
   • Beschreibung: Eine optionale Beschreibung der Regel.

Wie bereits erwähnt, müssen Sie die Instanz selbst so konfigurieren, dass Pakete weitergeleitet werden.