Zugriff auf Microsoft Azure
Oracle und Microsoft haben in bestimmten Regionen eine cloud-übergreifende Verbindung zwischen Oracle Cloud Infrastructure und Microsoft Azure erstellt. Mit dieser Verbindung können Sie cloud-übergreifende Workloads einrichten, ohne dass der Traffic zwischen den Clouds über das Internet geleitet wird. In diesem Thema wird beschrieben, wie virtuelle Netzwerkinfrastrukturressourcen eingerichtet werden, um diese Art von cloud-übergreifendem Deployment zu ermöglichen.
Highlights
- Sie können ein virtuelles Microsoft Azure-Netzwerk (VNet) mit einem virtuellen Oracle Cloud Infrastructure-(OCI-)Cloud-Netzwerk (VCN) verbinden und eine cloudübergreifende Workload ausführen. Im typischen Anwendungsfall stellen Sie Ihre Oracle-Datenbank in OCI bereit und stellen eine Oracle-, .NET- oder benutzerdefinierte Anwendung in Microsoft Azure bereit.
- Die beiden virtuellen Netzwerke müssen zu demselben Unternehmen gehören und dürfen keine sich überschneidenden CIDRs aufweisen. Für die Verbindung müssen Sie einen Azure ExpressRoute-Circuit und einen OCI FastConnect-Virtual Circuit erstellen.
Verfügbarkeit
Die cloudübergreifende Verbindung zwischen OCI und Azure ist nur in den unten aufgeführten Regionen und an den entsprechenden ExpressRoute-Standorten verfügbar. Weitere Informationen zu Azure-Regionsspeicherorten und Azure ExpressRoute finden Sie unter ExpressRoute Peering Locations and Connectivity Partners in der Azure-Dokumentation.
Die folgende Abbildung zeigt Regionen mit Interconnect.
Asien-Pazifik (APAC)
| OCI-Standort - Schlüssel | Azure ExpressRoute-Standort 
|
|---|---|
| Japan East (Tokyo) NRT | Tokyo |
| Singapore (Singapore) - SIN | Singapur |
| South Korea Central (Seoul) - ICN | Seoul |
Europa, Naher Osten und Afrika (EMEA)
| OCI-Standort | Azure ExpressRoute-Standort
|
|---|---|
| Germany Central (Frankfurt) - FRA | Frankfurt und Frankfurt2 |
| Netherlands Northwest (Amsterdam) - AMS | Amsterdam2 |
| UK South (London) - LHR | London |
| South Africa Central (Johannesburg) - JNB | Johannesburg |
Lateinamerika (LATAM)
| OCI-Standort | Azure ExpressRoute-Standort
|
|---|---|
| Brazil Southeast (Vinhedo) - VCP | Campinas |
Nordamerika (NA)
| OCI-Standort | Azure ExpressRoute-Standort
|
|---|---|
| Canada Southeast (Toronto) - YYZ | Toronto und Toronto2 |
| US East (Ashburn) - IAD | Washington DC und Washington DC2 |
| US East (Ashburn) - IAD | Phoenix |
| US West (San Jose) - SJC | Silicon Valley |
Überblick über unterstützten Traffic
Hier finden Sie weitere Einzelheiten zu den unterstützten Traffictypen.
VNet-zu-VCN-Verbindung: Erweiterung von einer Cloud zu einer anderen
Sie können Ihr VNet und VCN miteinander verbinden, sodass Traffic mit privaten IP-Adressen über die cloud-übergreifende Verbindung geführt wird.
Beispiel: Das folgende Diagramm zeigt ein VNet, das mit einem VCN verbunden ist. Ressourcen im VNet führen eine .NET-Anwendung aus, die auf eine Oracle-Datenbank zugreift, die auf Datenbankserviceressourcen im VCN ausgeführt wird. Der Traffic zwischen der Anwendung und der Datenbank verwendet einen logischen Circuit, der auf der cloud-übergreifenden Verbindung zwischen Azure und Oracle Cloud Infrastructure ausgeführt wird.
Um die Verbindung zwischen dem VNet und dem VCN zu aktivieren, richten Sie einen Azure ExpressRoute-Circuit und einen Oracle Cloud Infrastructure FastConnect-Virtual Circuit ein. Die Verbindung hat eine integrierte Redundanz, sodass Sie nur einen einzelnen ExpressRoute-Circuit und einen einzelnen FastConnect-Virtual Circuit einrichten müssen. Die Bandbreite für die Verbindung ist der Bandbreitenwert, den Sie für den ExpressRoute-Circuit wählen.
Anweisungen finden Sie unter VNet-zu-VCN-Verbindung einrichten.
Peer-VCNs
Mit dieser Verbindung kann der Traffic vom VNet über das verbundene VCN in ein gleichgestelltes VCN in derselben Oracle Cloud Infrastructure-Region oder einer anderen Region fließen.
Traffictypen, die nicht von der Verbindung unterstützt werden
Diese cloud-übergreifende Verbindung ermöglicht keinen Traffic zwischen Ihrem On-Premise-Netzwerk über das VCN zum VNet oder vom On-Premise-Netzwerk über das VNet zum VCN.
Wichtige Auswirkungen von Cloud-Verbindungen
In diesem Abschnitt werden einige Auswirkungen der Verbindung eines VNC mit einem VNet hinsichtlich Zugriffskontrolle, Sicherheit und Performance zusammengefasst. Im Allgemeinen können Sie den Zugriff und Traffic mit IAM-Policys, Routentabellen im VCN und mit Sicherheitsregeln im VCN steuern.
In den folgenden Abschnitten werden die Auswirkungen aus Sicht Ihres VCN beschrieben. Die Auswirkungen auf das VNet sind ähnlich. Wie beim VCN können Sie Azure-Ressourcen verwenden, wie Routentabellen und Netzwerksicherheitsgruppen, um das VNet zu sichern.
Aufbau einer Verbindung steuern
Mit den IAM-Policys von Oracle Cloud Infrastructure können Sie Folgendes steuern:
- Wer in Ihrer Organisation die Berechtigung hat, einen FastConnect-Virtual Circuit zu erstellen (siehe VNet-zu-VCN-Verbindung einrichten). Das Löschen der relevanten IAM-Policy hat keine Auswirkungen auf vorhandene Verbindungen zu einem VNet, sondern lediglich auf die Möglichkeit, eine zukünftige Verbindung zu erstellen.
- Wer Routentabellen, Netzwerksicherheitsgruppen und Sicherheitslisten verwalten kann.
Trafficfluss über die Verbindung steuern
Selbst wenn eine Verbindung zwischen Ihrem VCN und VNet hergestellt wurde, können Sie den Paketfluss über die Verbindung mit den Routentabellen in Ihrem VCN steuern. Beispiel: Sie können den Traffic nur auf bestimmte Subnetze im VNet beschränken.
Sie können den Trafficfluss zum VNet ohne Beenden der Verbindung stoppen, indem Sie einfach Routingregeln entfernen, die den Traffic vom VCN zum VNet leiten. Sie können den Traffic auch wirksam stoppen, indem Sie alle Sicherheitsregeln entfernen, die den Ingress- oder Egress-Traffic mit dem VNet ermöglichen. Dadurch wird nicht der Trafficfluss über die Verbindung, aber auf VNIC-Ebene gestoppt.
Bestimmte zulässige Traffictypen steuern
Es ist wichtig, dass Sie sicherstellen, dass der gesamte ausgehende und eingehende Traffic im VNet beabsichtigt oder erwartet und ordnungsgemäß definiert ist. Implementieren Sie Azure-Netzwerksicherheitsgruppenregeln und Oracle-Sicherheitsregeln, die explizit angeben, welche Traffictypen die Clouds untereinander versenden und akzeptieren können.
Ihre Oracle Cloud Infrastructure-Instanzen, auf denen Linux- oder Windows-Plattformimages ausgeführt werden, verfügen auch über Firewallregeln, die den Zugriff auf die Instanz steuern. Stellen Sie bei der Behebung von Fehlern beim Zugriff auf eine Instanz sicher, dass die folgenden Elemente korrekt festgelegt sind: die Netzwerksicherheitsgruppen, in denen sich die Instanz befindet, die mit dem Subnetz der Instanz verknüpften Sicherheitslisten und die Firewallregeln der Instanz.
Wenn auf Ihrer Instanz Oracle Autonomous Linux 8.x, Oracle Autonomous Linux 7, Oracle Linux 8, Oracle Linux 7 oder Oracle Linux Cloud Developer 8 ausgeführt wird, müssen Sie firewalld für die Interaktion mit den iptables-Regeln verwenden. Zu Referenzzwecken sind hier Befehle zum Öffnen eines Ports (in diesem Beispiel 1521) aufgeführt:
sudo firewall-cmd --zone=public --permanent --add-port=1521/tcp
sudo firewall-cmd --reloadBei Instanzen mit einem iSCSI-Boot-Volume kann der vorherige --reload-Befehl Probleme verursachen. Weitere Einzelheiten und einen Workaround finden Sie unter Bei den Instanzen hängt das System, nachdem "firewall-cmd --reload" ausgeführt wurde.
Neben Sicherheitsregeln und Firewalls sollten Sie andere BS-basierte Konfigurationen für die Instanzen in Ihrem VCN auswerten. Es könnten Standardkonfigurationen vorhanden sein, die nicht für das CIDR Ihres eigenen VCN gelten, sondern irrtümlicherweise für das CIDR des VNets.
Standardsicherheitslistenregeln mit VCN verwenden
Wenn die Subnetze des VCN die Standardsicherheitsliste mit den Standardregeln verwenden, erlauben zwei Regeln in dieser Liste Ingress-Traffic von überall (d.h. 0.0.0.0/0 und somit VNet):
- Regel für zustandsbehafteten Ingress, die (SSH-)Traffic über den TCP-Port 22 von 0.0.0.0/0 und allen Quellports zulässt
- Regel für zustandsbehafteten Ingress, die ICMP-Typ-3-Code-4-Traffic von 0.0.0.0/0 und allen Quellports zulässt
Prüfen Sie diese Regeln, und entscheiden Sie, ob Sie sie beibehalten oder aktualisieren möchten. Wie bereits erwähnt, müssen Sie sicherstellen, dass der gesamte zulässige eingehende oder ausgehende Traffic beabsichtigt oder erwartet und ordnungsgemäß definiert ist.
Performanceauswirkungen und Sicherheitsrisiken antizipieren
Generell sollten Sie das VCN entsprechend möglicher Auswirkungen durch das VNET einrichten. Beispiel: Die Auslastung Ihres VCN oder seiner Instanzen könnte sich erhöhen. Oder es könnte direkt vom oder über das VNet zu einem bösartigen Angriff auf Ihr VCN kommen.
Zur Performance: Wenn Ihr VCN einen Service für das VNet bereitstellt, müssen Sie den Service möglicherweise entsprechend den Anforderungen des VNet vertikal skalieren. Dies kann bedeuten, dass gegebenenfalls weitere Instanzen gestartet werden müssen. Wenn Sie über erhöhtes Aufkommen von Netzwerktraffic in Ihrem VCN besorgt sind, sollten Sie die Verwendung von zustandslose Sicherheitsregeln in Erwägung ziehen, um das Ausmaß des Verbindungstrackings zu begrenzen, das Ihr VCN ausführen muss. Außerdem können Sicherheitsregeln für zustandslosen Traffic die Auswirkungen eines Denial-of-Service-(DoS-)Angriffs eindämmen.
Zu Sicherheitsrisiken: Wenn das VNet mit dem Internet verbunden ist, kann Ihr VCN Bounce-Angriffen ausgesetzt sein. Bei einem Bounce-Angriff sendet ein böswilliger Host im Internet Traffic an Ihr VCN, wobei der Anschein erweckt wird, dass der Traffic vom VNet stammt. Um dies zu vermeiden, verwenden Sie Ihre Sicherheitsregeln, um den eingehenden Traffic vom VNet sorgfältig auf erwarteten und ordnungsgemäß definierten Traffic zu begrenzen.
VNet-zu-VCN-Verbindung einrichten
In diesem Abschnitt wird beschrieben, wie die logische Verbindung zwischen einem VNet und VCN eingerichtet wird (Hintergrundinformationen finden Sie unter Überblick über unterstützten Traffic).
Voraussetzungen: Erforderliche Ressourcen
Folgendes muss bereits vorhanden sein:
- Azure-VNet mit Subnetzen und virtuellem Netzwerkgateway
- Ein Oracle Cloud Infrastructure-VCN mit Subnetzen und einem angehängten dynamischen Routinggateway (DRG). Das Anhängen des DRG an Ihr VCN nach dem Erstellen wird schnell vergessen. Wenn Sie bereits ein Site-to-Site-VPN oder FastConnect zwischen Ihrem On-Premise-Netzwerk und dem VCN verwenden, verfügt Ihr VCN bereits über ein angehängtes DRG. Verwenden Sie dasselbe DRG beim Einrichten der Verbindung zu Azure.
In der folgenden Tabelle werden die vergleichbaren Netzwerkkomponenten auf beiden Seiten der Verbindung aufgeführt.
| Komponente | Azure | Oracle Cloud Infrastructure |
|---|---|---|
| Virtuelles Netzwerk | VNet | VCN |
| Virtual Circuit | ExpressRoute-Circuit | Privater FastConnect-Virtual Circuit |
| Gateway | Virtuelles Netzwerkgateway | Dynamisches Routinggateway (DRG) |
| Routing | Routentabellen | Routentabellen |
| Sicherheitsregeln | Netzwerksicherheitsgruppen (NSGs) | Netzwerksicherheitsgruppen (NSGs), Sicherheitslisten |
Voraussetzungen: Erforderliche BGP-Informationen
Für die Verbindung zwischen VNet und VCN wird dynamisches BGP-Routing verwendet. Wenn Sie den Virtual Circuit von Oracle einrichten, geben Sie die BGP-IP-Adressen an, die für die beiden redundanten BGP-Sessions zwischen Oracle und Azure verwendet werden:
- Ein primäres Paar von BGP-Adressen (eine IP-Adresse für die Oracle-Seite, eine IP-Adresse für die Azure-Seite)
- Ein separates, sekundäres Paar von BGP-Adressen (eine IP-Adresse für die Oracle-Seite, eine IP-Adresse für die Azure-Seite)
Für jedes Paar müssen Sie einen separaten Adressblock mit einer Subnetzmaske von /28 bis /31 angeben.
Die zweite und dritte Adresse in jedem Adressblock werden für das BGP-IP-Adresspaar verwendet. Das heißt im Einzelnen:
- Die zweite Adresse im Block bezieht sich auf die Oracle-Seite der BGP-Session.
- Die dritte Adresse im Block bezieht sich auf die Azure-Seite der BGP-Session.
Die erste und letzte Adresse im Block werden für andere interne Zwecke verwendet.
Beispiel: Wenn der CIDR-Block 10.0.0.20/30 ist, lauten die Adressen im Block:
- 10.0.0.20
- 10.0.0.21: Verwenden Sie diese für die Oracle-Seite (geben Sie in der Oracle-Konsole die Adresse als 10.0.0.21/30 ein)
- 10.0.0.22: Verwenden Sie diese für die Azure-Seite (geben Sie in der Oracle-Konsole die Adresse als 10.0.0.22/30 ein, und beachten Sie, dass diese Adresse in der Konsole als "Kunden"-Seite bezeichnet wird)
- 10.0.0.23
Beachten Sie, dass Sie auch einen zweiten Block derselben Größe für die sekundären BGP-Adressen angeben müssen. Beispiel: 10.0.0.24/30. In diesem Fall ist 10.0.0.25 für die Oracle-Seite und 10.0.0.26 für die Azure-Seite vorgesehen. In der Oracle-Konsole müssen Sie diese als 10.0.0.25/30 und 10.0.0.26/30 eingeben.
Voraussetzungen: Erforderliche IAM-Policy
Es wird davon ausgegangen, dass Sie über den erforderlichen Azure Active Directory-Zugriff und den IAM-Zugriff in Oracle Cloud Infrastructure verfügen, um die relevanten Azure - und Oracle-Netzwerkressourcen zu erstellen und mit diesen zu arbeiten. Speziell für IAM: Wenn Ihr Benutzer Mitglied der Administratorgruppe ist, haben Sie die erforderliche Berechtigung.
Ist dies nicht der Fall, deckt eine Policy wie diese in der Regel alle Netzwerkressourcen ab:
Allow group NetworkAdmins to manage virtual-network-family in tenancyUm einen Virtual Circuit nur zu erstellen und zu verwalten, benötigen Sie eine Policy wie die Folgende:
Allow group VirtualCircuitAdmins to manage drgs in tenancy
Allow group VirtualCircuitAdmins to manage virtual-circuits in tenancyWeitere Informationen finden Sie unter IAM-Policys für Networking.
Gesamtprozess
Das folgende Diagramm zeigt den allgemeinen Prozess für die Verbindung Ihres VNet und VCN.
In der ersten Aufgabe wird bestimmt, welcher Traffic zwischen den relevanten Subnetzen im VNet und VCN fließen muss. Danach werden die VNet-Sicherheitsgruppen und VCN-Sicherheitsregeln entsprechend konfiguriert. Im Folgenden werden die allgemeinen Regeltypen aufgeführt, die hinzugefügt werden sollen:
- Ingress-Regeln für die Traffictypen, die Sie in einer Cloud aus der anderen Cloud zulassen möchten, speziell aus den relevanten Subnetzen der anderen Cloud.
- Egress-Regel, mit der ausgehender Traffic von einer Cloud in die andere übertragen werden kann. Wenn das VCN-Subnetz bereits eine umfassende Egress-Regel für alle Protokolltypen an alle Ziele (0.0.0.0/0) hat, müssen Sie für den Traffic zum VNet keine spezielle Regel hinzufügen. Die Standardsicherheitsliste des VCN enthält eine umfassende Standardausgaberegel wie diese.
Im Folgenden sind die empfohlenen Traffictypen genauer aufgeführt, die zwischen VNet und VCN zulässig sind:
- Ping-Traffic in beiden Richtungen zum Testen der Verbindung von jeder Seite
- SSH (TCP-Port 22)
- Clientverbindungen zu einer Oracle-Datenbank (SQL*NET auf TCP-Port 1521)
Lassen Sie nur Traffic zwischen bestimmten relevanten Adressbereichen zu (z.B. von und an relevante Subnetze der anderen Cloud).
Für das VNet: Bestimmen Sie, welche Subnetze im VNet mit dem VCN kommunizieren müssen. Danach konfigurieren Sie die Netzwerksicherheitsgruppen für diese Subnetze so, dass Traffic zulässig ist.
Für das VCN:
Im Folgenden werden Sicherheitslisten verwendet. Sie könnten jedoch stattdessen die Sicherheitsregeln in mindestens einer Netzwerksicherheitsgruppe implementieren und die relevanten Ressourcen des VCN in NSGs platzieren.
- Bestimmen Sie, welche Subnetze im VCN mit dem VNet kommunizieren müssen.
-
Aktualisieren Sie die Sicherheitsliste für jedes dieser Subnetze mit Regeln, um Egress- oder Ingress-Traffic speziell mit dem CIDR-Block des VNets oder einem Subnetz des VNets zu ermöglichen:
- Klicken Sie in der Konsole auf Sicherheitslisten, während Sie das gewünschte VCN anzeigen.
- Klicken Sie auf die gewünschte Sicherheitsliste.
-
Klicken Sie auf Alle Regeln bearbeiten, und erstellen Sie eine oder mehrere Regeln für jeden zulässigen Traffictyp.
-
Klicken Sie unten im Dialogfeld auf Sicherheitslistenregeln speichern.
Weitere Informationen zum Einrichten von Sicherheitsregeln finden Sie unter Sicherheitsregeln.
Mit der folgenden Egress-Sicherheitsregel kann eine Instanz eine Ping-Anforderung an einen Host außerhalb des VCN starten (Echoanforderung ICMP-Typ 8). Dies ist eine Regel für zustandsbehafteten Egress, die die Antwort automatisch zulässt. Eine separate Ingress-Regel für Echoantwort ICMP-Typ 0 ist nicht erforderlich.
- Klicken Sie im Abschnitt Regeln für Egress zulassen auf + Regel hinzufügen.
- Lassen Sie das Kontrollkästchen zustandslos deaktiviert.
- Ziel-CIDR: Das relevante Subnetz im VNet (10.0.0.0/16 im vorherigen Diagramm)
- IP-Protokoll: ICMP
- Typ und Code: 8
- Beschreibung: Eine optionale Beschreibung der Regel.
Mit der folgenden Ingress-Sicherheitsregel kann eine Instanz eine Ping-Anforderung von einem Host im VNet empfangen (Echoanforderung ICMP-Typ 8). Dies ist eine Regel für zustandsbehafteten Egress, die die Antwort automatisch zulässt. Eine separate Egress-Regel für Echoantwort ICMP-Typ 0 ist nicht erforderlich.
- Klicken Sie im Abschnitt Regeln für Ingress zulassen auf + Regel hinzufügen.
- Lassen Sie das Kontrollkästchen zustandslos deaktiviert.
- Quell-CIDR: Das relevante Subnetz im VNet (10.0.0.0/16 im vorherigen Diagramm)
- IP-Protokoll: ICMP
- Typ und Code: 8
- Beschreibung: Eine optionale Beschreibung der Regel.
Mit der folgenden Ingress-Sicherheitsregel kann eine Instanz eine SSH-Verbindung (TCP-Port 22) von einem Host im VNet empfangen.
- Klicken Sie im Abschnitt Regeln für Ingress zulassen auf + Regel hinzufügen.
- Lassen Sie das Kontrollkästchen zustandslos deaktiviert.
- Quell-CIDR: Das relevante Subnetz im VNet (10.0.0.0/16 im vorherigen Diagramm)
- IP-Protokoll: TCP
- Quellportbereich: Alle
- Zielportbereich: 22
- Beschreibung: Eine optionale Beschreibung der Regel.
Die folgende Ingress-Sicherheitsregel lässt SQL*Net-Verbindungen (TCP-Port 1521) von Hosts im VNet zu.
- Klicken Sie im Abschnitt Regeln für Ingress zulassen auf + Regel hinzufügen.
- Lassen Sie das Kontrollkästchen zustandslos deaktiviert.
- Quell-CIDR: Das relevante Subnetz im VNet (10.0.0.0/16 im vorherigen Diagramm)
- IP-Protokoll: TCP
- Quellportbereich: Alle
- Zielportbereich: 1521
- Beschreibung: Eine optionale Beschreibung der Regel.
Richten Sie einen ExpressRoute-Circuit zu Oracle Cloud Infrastructure FastConnect ein. Während der Einrichtung des Circuits erhalten Sie einen Serviceschlüssel von Microsoft. Notieren Sie diesen Serviceschlüssel, denn Sie müssen ihn in der nächsten Aufgabe bei Oracle angeben.
In der nächsten Aufgabe richten Sie einen privaten FastConnect-Virtual Circuit zu Microsoft Azure: ExpressRoute ein. Wenn das Provisioning dieses Virtual Circuits beendet ist, wird der ExpressRoute-Circuit aktualisiert, um anzuzeigen, dass Private Peering aktiviert ist.
- Bestätigen Sie in der Konsole, dass Sie das Compartment anzeigen, in dem Sie arbeiten möchten. Wenn Sie nicht sicher sind, verwenden Sie das Compartment, das das DRG enthält, zu dem Sie eine Verbindung herstellen. Diese Compartment-Auswahl bestimmt zusammen mit einer entsprechenden IAM-Policy, wer Zugriff auf den Virtual Circuit hat, den Sie gerade erstellen.
-
Auf der daraufhin angezeigten FastConnect-Seite erstellen Sie einen neuen Virtual Circuit und kehren später dorthin zurück, wenn Sie den Virtual Circuit verwalten müssen.
- Klicken Sie auf Verbindung erstellen.
- Wählen Sie den FastConnect-Partner aus, und wählen Sie in der Liste Microsoft Azure: ExpressRoute aus.
-
Geben Sie Folgendes für Ihren Virtual Circuit ein:
- Name: Ein benutzerfreundlicher Name Ihrer Wahl. Der Wert muss nicht in allen Ihren Virtual Circuits eindeutig sein, und Sie können ihn später ändern. Geben Sie keine vertraulichen Informationen ein.
- Erstellen in Compartment: Übernehmen Sie die Vorgabe (das Compartment, in dem Sie derzeit arbeiten).
- Virtual-Circuit-Typ: Wählen Sie Privater Virtual Circuit aus.
- Compartment dynamisches Routinggateway: Wählen Sie das Compartment, in dem das DRG gespeichert ist (es sollte bereits ausgewählt sein).
- Dynamisches Routinggateway: Wählen Sie das DRG.
- Bereitgestellte Bandbreite: Wählen Sie dieselbe Bandbreite, die Sie für den ExpressRoute-Circuit gewählt haben (oder den nächsten verfügbaren Wert).
- Partnerserviceschlüssel: Geben Sie den Serviceschlüssel ein, den Sie von Microsoft beim Einrichten des ExpressRoute-Circuit erhalten haben.
- Primäre BGP-IP-Adresse des Kunden: Dies ist die primäre BGP-IP-Adresse von Azure. Geben Sie die dritte Adresse im von Ihnen angegebenen primären CIDR-Block (mit einer Subnetzmaske von /28 bis /31) ein, und schließen Sie die Subnetzmaske am Ende ein. Beispiel: 10.0.0.22/30. Weitere Informationen zu diesem und den nächsten Feldern finden Sie unter VNet-zu-VCN-Verbindung einrichten.
- Primäre BGP-IP-Adresse von Oracle (optional): Sie können dieses Feld leer lassen, und Oracle ruft die Adresse basierend auf dem CIDR-Block ab, den Sie für die BGP-IP-Adresse von Azure angegeben haben. In diesem Beispiel wäre der korrekte Wert 10.0.0.21/30.
- Sekundäre BGP-IP-Adresse des Kunden: Dieses Feld enthält die sekundäre BGP-IP-Adresse von Azure. Geben Sie die dritte Adresse im von Ihnen angegebenen sekundären CIDR-Block (mit einer Subnetzmaske von /28 bis /31) ein, und schließen Sie die Subnetzmaske am Ende ein. Beispiel: 10.0.0.26/30.
- Primäre BGP-IP-Adresse von Oracle (optional): Sie können dieses Feld leer lassen, und Oracle ruft die Adresse basierend auf dem CIDR-Block ab, den Sie für die BGP-IP-Adresse von Azure angegeben haben. In diesem Beispiel wäre der korrekte Wert 10.0.0.25/30.
-
Klicken Sie auf Weiter.
Der Virtual Circuit wird erstellt.
- Klicken Sie auf Schließen.
Nachdem Sie den Virtual Circuit von Oracle erstellt haben, müssen Sie sich nicht an Azure wenden, um das Provisioning des Circuits anzufordern. Es erfolgt automatisch.
Die beiden Circuits werden innerhalb weniger Minuten bereitgestellt. Überprüfen Sie:
- Bestätigen Sie für den ExpressRoute-Circuit, dass Private Peering bereitgestellt ist.
- Bestätigen Sie für den FastConnect-Virtual Circuit, dass der Status UP ist. Siehe So rufen Sie den Status Ihres FastConnect-Virtual Circuits ab.
Für das VNet: Bestimmen Sie, welche Subnetze im VNet mit dem VCN kommunizieren müssen. Danach konfigurieren Sie die Routentabellen für diese Subnetze so, dass der Traffic zum VNet-Gateway weitergeleitet wird.
Für das VCN:
- Bestimmen Sie, welche Subnetze im VCN mit dem VNet kommunizieren müssen.
-
Aktualisieren Sie die Routentabelle für jedes dieser Subnetze, um eine neue Regel aufzunehmen, die den Traffic, der für das CIDR des VNets bestimmt ist, an das DRG weiterleitet:
- Klicken Sie in der Konsole auf Routentabellen, während Sie das gewünschte VCN anzeigen.
- Klicken Sie auf die gewünschte Routentabelle.
- Klicken Sie auf Routingregeln bearbeiten.
-
Klicken Sie auf + Weitere Routingregel, 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: Das relevante Subnetz im VNet (10.0.0.0/16 im vorherigen Diagramm).
- Beschreibung: Eine optionale Beschreibung der Regel.
- Klicken Sie auf Speichern.
Jeder Subnetztraffic mit einem Ziel, das der Regel entspricht, wird an das DRG weitergeleitet. Das DRG weiß dann, dass der Traffic basierend auf den BGP-Sessioninformationen des Virtual Circuits an das VNet weiterzuleiten ist.
Wenn Sie später keine Verbindung mehr benötigen und das DRG löschen möchten, müssen Sie zuerst alle Routingregeln im VCN löschen, die das DRG als Ziel angeben.
Weitere Informationen zum Einrichten von Routingregeln finden Sie unter VCN-Routentabellen.
Je nachdem, wie Sie Ihre VNet-Sicherheitsgruppen und VCN-Sicherheitsregeln eingerichtet haben, sollten Sie eine Instanz in Ihrem VCN erstellen und von einem Host im VNet aus darauf zugreifen können. Sie sollten sich auch von der Instanz bei einem Host im VNet anmelden können. Wenn Sie dazu in der Lage sind, ist Ihre Verbindung einsatzbereit.
Wenn Sie sich entscheiden, die Verbindung zu beenden, müssen Sie einem bestimmten Prozess folgen. Siehe So beenden Sie die Verbindung mit Azure.
VNet-zu-VCN-Verbindung verwalten
-
- Wählen Sie das Compartment aus, in dem sich die Verbindung befindet, und klicken Sie auf die gewünschte Verbindung. Wenn das Symbol für den Virtual Circuit grün ist und "UP" zeigt, wird der Virtual Circuit bereitgestellt, und das BGP wurde ordnungsgemäß konfiguriert. Der Virtual Circuit ist einsatzbereit.
Sie können die folgenden Elemente für Ihren Virtual Circuit ändern:
- Den Namen
- Welches DRG verwendet wird
Wenn Ihr Virtual Circuit den Status PROVISIONED aufweist, wird bei Änderung des verwendeten DRG der Status in PROVISIONING geändert. Dies kann dazu führen, dass die Verbindung heruntergefahren wird. Sobald Oracle den Virtual Circuit erneut durch Provisioning bereitstellt, wird der Status wieder auf PROVISIONED gesetzt. Vergewissern Sie sich, dass die Verbindung wieder hergestellt ist und ordnungsgemäß funktioniert.
-
- Wählen Sie das Compartment aus, in dem sich die Verbindung befindet, und klicken Sie auf die Verbindung.
- Klicken Sie auf den Virtual Circuit.
- Klicken Sie auf Bearbeiten, und nehmen Sie die gewünschten Änderungen vor. Geben Sie keine vertraulichen Informationen ein.
- Klicken Sie auf Speichern.
Das folgende Diagramm zeigt den allgemeinen Prozess zum Beenden einer VNet-zu-VCN-Verbindung.
- Zeigen Sie im Azure-Portal den ExpressRoute-Circuit und dann seine Verbindungen an. Stellen Sie sicher, dass für den ExpressRoute-Circuit keine Verbindungen mehr vorhanden sind. Löschen Sie alle Verbindungen, bevor Sie fortfahren.
-
Löschen Sie im Oracle-Portal Ihren FastConnect-Virtual Circuit:
-
- Wählen Sie das Compartment aus, in dem sich die Verbindung befindet, und klicken Sie auf die Verbindung.
- Klicken Sie auf den Virtual Circuit.
- Klicken Sie auf Löschen.
-
Bestätigen Sie den Vorgang, wenn Sie dazu aufgefordert werden.
Der Lebenszyklusstatus des Virtual Circuits ändert sich in TERMINATING.
-
- Bestätigen Sie im Azure-Portal, dass das Private Peering für den ExpressRoute-Circuit gelöscht wurde. Bestätigen Sie außerdem, dass der Status des ExpressRoute-Circuits in "Nicht durch Provisioning bereitgestellt" geändert wurde.
- Löschen Sie im Azure-Portal den ExpressRoute-Circuit.
Die Verbindung zwischen Azure und Oracle Cloud Infrastructure wird beendet.