Remote-VCN-Peering über ein upgegradetes DRG
In diesem Thema wird Remote-VCN-Peering behandelt.
In diesem Fall bedeutet Remote, dass die virtuellen Cloud-Netzwerke (VCNs) jeweils an ein anderes dynamisches Routinggateway (DRG) angehängt sind, das sich in einer anderen Region befindet. Wenn sich die zu verbindenden VCNs in derselben Region befinden, lesen Sie Lokales VCN-Peering über ein upgegradetes DRG.
Dieses Szenario ist für ein upgegradetes oder Legacy-DRG verfügbar, mit der Ausnahme, dass Legacy-DRGs die Verbindung von DRGs in verschiedenen Mandanten nicht unterstützen. Eine Aufschlüsselung der möglichen DRG-Versionen finden Sie unter DRG-Versionen.
Bevor Sie versuchen, dieses Szenario zu implementieren, stellen Sie Folgendes sicher:
- VCN A ist an DRG A in Region 1 angehängt.
- VCN B ist an DRG B in Region 2 angehängt.
- Die Routingkonfiguration in beiden DRGs ist unverändert.
- Angemessene IAM-Berechtigungen werden für VCNs angewendet, die sich entweder in demselben oder in verschiedenen Mandanten befinden.
Remote-VCN-Peering - Überblick
Mit Remote-VCN-Peering wird eine Verbindung zwischen zwei VCNs in verschiedenen Regionen hergestellt. 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. Die VCNs können sich sowohl im selben als auch in verschiedenen Oracle Cloud Infrastructure-Mandanten befinden. 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.
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 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 im anderen VCN oder in Ihrem On-Premise-Netzwerk erreichen, wenn das DRG eine Verbindung zu einem On-Premise-CPE hergestellt hat. 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.
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.
Spoke-zu-Spoke: Remote-Peering mit Transitrouting (nur Legacy-DRGs)
Das in diesem Abschnitt erwähnte Szenario wird weiterhin unterstützt. Oracle empfiehlt jedoch, dass Sie die unter Traffic über eine zentrale virtuelle Netzwerk-Appliance weiterleiten beschriebene DRG-Transitroutingmethode 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.
Spoke-zu-Spoke: Remote-Peering mit Transitrouting (upgegradetes DRG)
Im Szenario in diesem Abschnitt wird die unter Traffic über eine zentrale virtuelle Netzwerk-Appliance weiterleiten beschriebene DRG-Transitroutingmethode verwendet.
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 Region werden über gegenseitige Verbindungen zum DRG lokal per Peering mit dem Hub-DRG/VCN-Paar in derselben Region verbunden.
Sie können Remote-Peering zwischen den beiden Hub-VCNs einrichten. Sie können dann auch Transitrouting für das DRG des Hub-VCN einrichten, wie unter Routing von Traffic über eine zentrale virtuelle Appliance beschrieben. 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.
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:
- 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).
- 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 1: Routentabelle von Subnetz A Ziel-CIDR Routenziel 0.0.0.0/0 Internetgateway 192.168.0.0/16 DRG-1 Callout 2: 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 das nicht der Fall, lesen Sie Regionen verwalten.
- Es ist bereits ein VCN an Ihr DRG angehängt. Andernfalls lesen Sie Dynamische Routinggateways.
- Sie haben bereits die erforderlichen IAM-Policys für die Verbindung eingerichtet. IAM-Policys für Remote-Peering in demselben Mandanten und zwischen Mandanten unterscheiden sich. Siehe IAM-Policys für das Routing zwischen VCNs
Überblick über die erforderlichen Schritte:
- 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.
- Verbindung herstellen: Der Requestor verbindet die beiden RPCs (unter Wichtige Konzepte für das Remote-Peering finden Sie die Definitionen der Begriffe Requestor und Acceptor).
- Routentabellen aktualisieren: Jeder Administrator aktualisiert die Routentabellen seines VCN, um den Traffic zwischen den Peer-VCNs wie gewünscht zu ermöglichen.
- Sicherheitsregeln aktualisieren: Jeder Administrator aktualisiert die Sicherheitsregeln seines VCN, um den Traffic zwischen den Peer-VCNs wie gewünscht zu ermöglichen.
Gegebenenfalls können Administratoren die Aufgaben 4 und 5 ausführen, bevor die Verbindung hergestellt wird. Jeder Administrator muss den CIDR-Block oder bestimmte Subnetze aus dem VCN der jeweils anderen Seite kennen und diese in Aufgabe 2 weitergeben.
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.
-
- Klicken Sie auf das gewünschte DRG.
- Klicken Sie unter Ressourcen auf Remote-Peering-Verbindungen - Anhänge.
- 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 die beiden VCNs in unterschiedlichen Mandanten befinden, notieren Sie die Mandanten-OCID (befindet sich in der Konsole unten auf der Seite). Geben Sie die OCID später an den anderen Administrator weiter.
Diese Aufgabe ist spezifisch für eine mandantenübergreifende Verbindung. Wenn sich Ihre Verbindung im selben Mandanten befindet, können Sie zur nächsten Aufgabe wechseln.
-
Als Acceptor müssen Sie dem Requestor die folgenden Informationen bereitstellen (beispielsweise per E-Mail oder über eine andere Out-of-Band-Methode):
- Die Region, in der sich Ihr VCN befindet (der Mandant des Requestors muss ein Abonnement für diese Region besitzen).
- Die OCID Ihrer RPC.
- Die CIDR-Blöcke für Subnetze in Ihrem VCN, die für das andere VCN verfügbar sein sollen. Der Requestor benötigt diese Informationen beim Einrichten des Routings für sein VCN.
- Wenn sich die VCNs in verschiedenen Mandanten befinden: die OCID für Ihren Mandanten.
-
Als Requestor müssen Sie dem Acceptor die folgenden Informationen bereitstellen:
- Die Region, in der sich Ihr VCN befindet (der Mandant des Acceptors muss ein Abonnement für diese Region besitzen).
- Wenn sich die VCNs in demselben Mandanten befinden: Der Name der IAM-Gruppe, der die Berechtigung zum Erstellen einer Verbindung im Compartment des Acceptors erteilt wird (im Beispiel in der nächsten Aufgabe lautet die Gruppe RequestorGrp).
- Wenn sich die VCNs in verschiedenen Mandanten befinden: die OCID für Ihren Mandanten.
- Die CIDR-Blöcke für Subnetze in Ihrem VCN, die für das andere VCN verfügbar sein sollen. Der Acceptor benötigt diese Informationen beim Einrichten des Routings für sein VCN.
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.
- Die OCID des Mandanten des Acceptors (nur wenn sich das VCN des Acceptors in einem anderen Mandanten befindet)
- 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.
-
- Klicken Sie auf das gewünschte DRG.
- Klicken Sie unter Ressourcen auf Remote-Peering-Verbindungen.
- Zeigen Sie die Details für die RPC des Requestors an, die Sie mit der RPC des Acceptors verbinden möchten. Klicken Sie dazu in der Spalte Remote-Peering-Verbindung auf den Namen des RPC-Anhangs, den Sie in Aufgabe A erstellt haben.Hinweis
Wenn es sich um eine RPC in demselben Mandanten handelt, ist es unerheblich, ob sie vom Requestor oder vom Acceptor eingerichtet wird. - Klicken Sie auf Verbindung herstellen.
-
Geben Sie Folgendes ein:
- Region: Die Region, die das VCN des Acceptors enthält. Die Liste enthält nur 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. Verwenden Sie im Allgemeinen denselben CIDR-Block, 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 die 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:
- Zeigen Sie das gewünschte VCN an, und klicken Sie in der Konsole auf Sicherheitslisten.
- 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 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.