Interconnect pour Azure
Oracle Interconnect pour Azure vous permet de créer une connexion internuage entre Oracle Cloud Infrastructure et Microsoft Azure dans certaines régions. Cette connexion vous permet de configurer des charges de travail internuages sans que le trafic entre ces nuages passe par Internet. Cette rubrique décrit comment configurer des ressources d'infrastructure de réseau virtuel pour permettre ce type de déploiement internuage.
Pour plus d'informations sur les déploiements multinuages d'Oracle Database qui utilisent Oracle Cloud Infrastructure et Microsoft Azure, voir Oracle Database@Azure. Ce service héberge des bases de données Oracle Exadata dans des centres de données Azure pour une latence la plus faible possible.
Points saillants
- Vous pouvez connecter un réseau en nuage virtuel (VCN) Oracle Cloud Infrastructure (OCI) à un réseau virtuel Microsoft Azure (VNet) et exécuter une charge de travail internuage. Dans le cas d'utilisation typique, vous déployez une base de données Oracle Database sur OCI et une application Oracle, .NET ou personnalisée dans Microsoft Azure.
- Les deux réseaux virtuels doivent appartenir à la même entreprise et leurs blocs CIDR ne doivent pas se chevaucher. Oracle Interconnect pour Azure requiert la création d'un circuit Azure ExpressRoute et d'un circuit virtuel OCI FastConnect.
Disponibilité
Oracle Interconnect pour Azure est seulement disponible dans les régions OCI et les emplacements ExpressRoute affichés. Pour plus d'informations sur les emplacements de région Azure et Azure ExpressRoute, voir Emplacements d'appairage et partenaires de connectivité ExpressRoute dans la documentation sur Azure.
L'image suivante présente les régions avec Oracle Interconnect pour Azure, affichant toutes les régions OCI et notant les régions avec interconnexion à Azure et GCP. Les régions Azure participantes sont également répertoriées dans les tableaux suivants.
Asie-Pacifique (APAC)
Emplacement OCI - Clé | Emplacement Azure ExpressRoute |
---|---|
Japon - Est (Tokyo) NRT | Tokyo |
Singapour (Singapour) - SIN | Singapour |
Corée - Centre (Seoul) - ICN | Séoul |
Europe, Moyen-Orient, Afrique (EMEA)
Emplacement OCI | Emplacement Azure ExpressRoute |
---|---|
Allemagne - Centre (Francfort) - FRA | Francfort et Francfort2 |
Pays-Bas - Nord-Ouest (Amsterdam) - AMS | Amersterdam2 |
Royaume-Uni - Sud (Londres) - LHR | Londres |
Afrique du Sud - Centre (Johannesburg) - JNB | Johannesbourg |
Amérique latine (LATAM)
Emplacement OCI | Emplacement Azure ExpressRoute |
---|---|
Brésil - Sud-Est (Vinhedo) - VCP | Campinas |
Amérique du Nord (AN)
Emplacement OCI | Emplacement Azure ExpressRoute |
---|---|
Canada - Sud-Est (Toronto) (YYZ) | Toronto et Toronto2 |
États-Unis - Est (Ashburn) - IAD | Washington DC et Washington DC2 |
États-Unis - Ouest (Phoenix) - PHX | Phoenix |
États-Unis - Ouest (San Jose) - SJC | Silicon Valley |
Aperçu du trafic pris en charge
Voici plus de détails sur les types de trafic pris en charge.
Connexion VCN-to-VNet : extension d'un nuage à un autre
Vous pouvez connecter un réseau VCN et VNet afin que le trafic qui utilise des adresses IP privées passe par la connexion internuage.
Par exemple, le diagramme suivant présente un VCN connecté à un VNet. Les ressources de VNet exécutent une application .NET qui accède à une base de données Oracle exécutée sur des ressources de service de base de données du réseau VCN. Le trafic entre l'application et la base de données utilise un circuit logique exécuté sur la connexion internuage entre Azure et Oracle Cloud Infrastructure.
Pour activer la connexion entre le VCN et VNet, configurez à la fois un circuit virtuel Oracle Cloud Infrastructure FastConnect et un circuit ExpressRoute Azure. La connexion a une redondance intégrée. Il suffit donc de configurer un seul circuit virtuel FastConnect et un seul circuit ExpressRoute. La bande passante pour la connexion est la valeur sélectionnée pour le circuit ExpressRoute.
Pour obtenir des instructions, voir Configuration d'une connexion.
Réseaux en nuage virtuels appairés
La connexion permet au flux de trafic depuis VNet au moyen du réseau VCN connecté vers un réseau VCN pair dans la même région Oracle Cloud Infrastructure ou dans une autre.
Types de trafic non pris en charge par la connexion
Cette connexion internuage ne permet pas le trafic entre le réseau sur place, passant par le réseau VCN vers VNet, ou depuis le réseau sur place, passant par VNet vers le réseau VCN.
Implications importantes liées à la connexion de nuages
Cette section résume certaines implications en matière de contrôle d'accès, de sécurité et de performance d'Oracle Interconnect pour Azure. En général, vous pouvez contrôler l'accès et le trafic à l'aide de politiques IAM, de tables de routage dans le VCN et de règles de sécurité dans le VCN.
Les sections qui suivent traitent des implications du point de vue du réseau VCN. Des implications similaires affectent le VNet. Comme avec le VCN, vous pouvez utiliser des ressources Azure, telles que des tables de routage et des groupes de sécurité de réseau pour sécuriser VNet.
Contrôle de l'établissement d'une connexion
Avec les politiques du service IAM d'Oracle Cloud Infrastructure, vous pouvez contrôler :
- Qui dans l'organisation a l'autorisation de créer un circuit virtuel FastConnect (voir Configuration d'une connexion). La suppression de la politique IAM pertinente n'a aucune incidence sur les connexions existantes à VNet, mais uniquement sur la possibilité de créer une connexion future.
- Qui peut gérer les tables de routage, les groupes de sécurité de réseau et les listes de sécurité.
Contrôle du flux de trafic sur la connexion
Même si une connexion a été établie entre le VCN et VNet, vous pouvez contrôler le flux du paquet sur la connexion à l'aide de tables de routage dans le VCN. Par exemple, vous pouvez restreindre le trafic à certains sous-réseaux du VNet.
Sans supprimer la connexion, vous pouvez arrêter le flux du trafic vers VNet en supprimant les règles de routage qui dirigent le trafic du VCN vers VNet. Vous pouvez également arrêter le trafic en supprimant toutes les règles de sécurité qui permettent le trafic entrant ou sortant au moyen du réseau VNet. Cela n'arrête pas le flux du trafic sur la connexion, mais l'interrompt au niveau de la carte vNIC.
Contrôle des types spécifiques de trafic autorisés
Assurez-vous que tout le trafic sortant et entrant avec VNet est prévu ou attendu et tel que défini. Effectuez la mise en oeuvre du groupe de sécurité de réseau Azure et de règles de sécurité Oracle qui indiquent explicitement les types de trafic qu'un nuage peut envoyer à un autre, et accepter de lui.
Les instances Oracle Cloud Infrastructure exécutant des images de plate-forme Linux ou Windows disposent également de règles de pare-feu qui contrôlent leur accès. Lors du dépannage de l'accès à une instance, assurez-vous que tous les éléments suivants sont définis correctement : groupes de sécurité de réseau où se trouve l'instance, listes de sécurité associées au sous-réseau de l'instance et règles de pare-feu de celle-ci.
Si une instance exécute Oracle Autonomous Linux 8.x, Oracle Autonomous Linux 7, Oracle Linux 8, Oracle Linux 7 ou Oracle Linux Cloud Developer 8, vous devez utiliser firewalld pour interagir avec les règles iptables. À titre de référence, voici les commandes d'ouverture d'un port (1521 dans cet exemple) :
sudo firewall-cmd --zone=public --permanent --add-port=1521/tcp
sudo firewall-cmd --reload
Pour les instances dotées d'un volume de démarrage iSCSI, la commande --reload
précédente peut provoquer des problèmes. Pour plus d'informations et une solution de rechange, voir Le système des instances se bloque après l'exécution de firewall-cmd --reload.
En plus des règles de sécurité et des pare-feu, évaluez d'autres configurations en fonction du système d'exploitation sur les instances du réseau VCN. Certaines configurations par défaut peuvent ne pas s'appliquer au CIDR du réseau VCN, mais à celui du réseau VNet.
Utilisation des règles de liste de sécurité par défaut avec le réseau VCN
Si les sous-réseaux du réseau VCN utilisent la liste de sécurité par défaut avec les règles par défaut, deux règles de cette liste autorisent le trafic entrant de n'importe où (0.0.0.0/0, et donc de VNet) :
- Règle de trafic entrant avec état qui autorise le trafic du port TCP 22 (SSH) à partir de 0.0.0.0/0 et de tout port source
- Règle de trafic entrant avec état qui autorise le trafic de type ICMP 3, code 4 à partir de 0.0.0.0/0 et de tout port source
Évaluez ces règles et décidez de les conserver ou de les mettre à jour. Comme indiqué précédemment, assurez-vous que tout le trafic entrant ou sortant autorisé est prévu ou attendu et tel que défini.
Préparation aux incidences sur la performance et aux risques de sécurité
En règle générale, préparez le VCN aux effets que pourrait avoir sur lui VNet. Par exemple, la charge sur le réseau VCN ou ses instances peut augmenter. Ou le VCN peut subir une attaque malveillante directement de ou par l'intermédiaire de VNet.
En ce qui concerne la performance : Si le réseau VCN fournit un service à VNet, soyez prêt à augmenter le service afin de répondre aux exigences de VNet. Vous pouvez ainsi créer des instances supplémentaires si nécessaire. Ou si vous êtes préoccupé par les niveaux élevés de trafic réseau entrant dans le VCN, envisagez d'utiliser des règles de sécurité sans état pour limiter le niveau de suivi de connexion que le VCN doit effectuer. Les règles de sécurité sans état peuvent également aider à ralentir l'incidence d'un déni de service (DoS).
En ce qui concerne les risques de sécurité : si VNet est connecté à Internet, le VCN peut être exposé à des attaques par rebond. Une attaque par non-transmission implique qu'un hôte malveillant sur Internet envoie du trafic au VCN qui semble provenir de VNet. Pour prévenir cette situation, comme mentionné précédemment, utilisez des règles de sécurité pour limiter soigneusement le trafic entrant provenant de VNet au trafic attendu et tel que défini.
Configuration d'une connexion
Cette section décrit comment configurer la connexion logique entre un réseau VCN et VNet (pour en savoir plus, voir Aperçu du trafic pris en charge).
Préalables : Ressources nécessaires
Vous devez déjà disposer des éléments suivants :
- Un VNet Azure avec des sous-réseaux et une passerelle de réseau virtuel
- Un réseau VCN Oracle Cloud Infrastructure avec des sous-réseaux et une passerelle de routage dynamique (DRG) associée. N'oubliez pas d'attacher la passerelle DRG au VCN après l'avoir créée. Si vous disposez déjà d'un RPV site à site ou de FastConnect entre le réseau sur place et le VCN, le VCN est déjà associé à une passerelle DRG. Vous utiliserez cette passerelle DRG ici lors de la configuration de la connexion à Azure.
Ce tableau aide-mémoire répertorie les composants de réseau comparables intervenant de chaque côté de la connexion.
Composant | Azure | Oracle Cloud Infrastructure |
---|---|---|
Réseau virtuel | VNet | VCN |
Circuit virtuel | Circuit ExpressRoute | Circuit virtuel privé FastConnect |
Passerelle | Passerelle de réseau virtuel | Passerelle de routage dynamique (DRG) |
Routage | tables de routage | tables de routage |
Règles de sécurité | groupes de sécurité de réseau | groupes de sécurité de réseau, listes de sécurité |
Préalables : Informations BGP nécessaires
La connexion entre le réseau VCN et VNet utilise un routage dynamique BGP. Lorsque vous configurez le circuit virtuel Oracle, vous fournissez les adresses IP BGP utilisées pour les deux sessions BGP redondantes entre Oracle et Azure :
- Une paire principale d'adresses BGP (une adresse IP pour le côté Oracle, une adresse IP pour le côté Azure)
- Une paire secondaire distincte d'adresses BGP (une adresse IP pour le côté Oracle, une adresse IP pour le côté Azure)
Pour chaque paire, vous devez fournir un bloc d'adresses distinct avec un masque de sous-réseau compris entre /28 et /31.
Les deuxième et troisième adresses de chaque bloc sont utilisées pour la paire d'adresses IP BGP :
- La deuxième adresse du bloc est destinée au côté Oracle de la session BGP
- La troisième adresse du bloc est destinée au côté Azure de la session BGP
La première adresse et dernière adresse du bloc sont utilisées à d'autres fins internes.
Par exemple, si le bloc CIDR est 10.0.0.20/30, les adresses qu'il contient sont :
- 10.0.0.20
- 10.0.0.21 : À utiliser pour le côté Oracle (dans la console Oracle, entrez l'adresse 10.0.0.21/30)
- 10.0.0.22 : À utiliser pour le côté Azure (dans la console Oracle, entrez l'adresse 10.0.0.22/30 et notez que cette adresse est référencée en tant que côté client dans la console)
- 10.0.0.23
N'oubliez pas que vous devez aussi fournir un deuxième bloc de même taille pour les adresses BGP secondaires. Par exemple : 10.0.0.24/30. Dans ce cas, l'adresse 10.0.0.25 est destinée au côté Oracle, et l'adresse 10.0.0.26, au côté Azure. Dans la console Oracle, vous devez entrer les valeurs suivantes : 10.0.0.25/30 et 10.0.0.26/30.
Préalables : Politique IAM requise
Vous disposez probablement de l'accès Azure Active Directory nécessaire et de l'accès IAM pour Oracle Cloud Infrastructure pour créer et utiliser les ressources de réseau Azure et Oracle pertinentes. Pour IAM : Si votre compte d'utilisateur fait partie du groupe Administrateurs, vous disposez de l'autorisation requise. Sinon, cette politique couvre toutes les ressources de réseau :
Allow group NetworkAdmins to manage virtual-network-family in tenancy
Pour seulement créer et gérer un circuit virtuel, vous devez disposer d'une politique telle que suivante :
Allow group VirtualCircuitAdmins to manage drgs in tenancy
Allow group VirtualCircuitAdmins to manage virtual-circuits in tenancy
Pour plus d'informations, voir Politiques de gestion des identités et des accès pour le service de réseau.
Processus global
Le diagramme suivant présente le processus global de connexion du VCN et de VNet.
La première tâche consiste à décider quel trafic doit circuler entre les sous-réseaux pertinents au sein du réseau VCN et VNet, puis à configurer les règles de sécurité pour qu'elles correspondent. Voici les types généraux de règle à ajouter :
- Règles de trafic entrant pour les types de trafic que vous voulez autoriser à partir des sous-réseaux pertinents de l'autre nuage.
- Règle autorisant le trafic sortant d'un nuage vers un autre. Si le sous-réseau du VCN comporte déjà une règle de trafic sortant large pour tous les types de protocole vers toutes les destinations (0.0.0.0/0), vous n'avez pas besoin d'en ajouter une particulière pour le trafic vers le réseau VNet. La liste de sécurité par défaut du réseau VCN comprend une grande règle de trafic sortant par défaut.
Voici les types de trafic autorisés entre VNet et VCN :
- Le trafic ping dans les deux directions pour tester la connexion de chaque côté
- SSH (port TCP 22)
- Connexions clients à une base de données Oracle (SQL*NET sur le port TCP 1521)
Autorisez uniquement le trafic vers et depuis les intervalles d'adresses voulus (par exemple, les sous-réseaux pertinents de l'autre nuage).
Pour le VCN :
La procédure suivante utilise des listes de sécurité, mais vous pouvez également mettre en oeuvre les règles de sécurité dans un ou plusieurs groupes de sécurité de réseau, puis placer les ressources pertinentes du réseau VCN dans les groupes de sécurité de réseau.
Pour VNet : Décidez quels sous-réseaux dans VNet doivent communiquer avec le VCN. Configurez ensuite les groupes de sécurité de réseau pour que ces sous-réseaux autorisent le trafic.
- Déterminez quels sous-réseaux du VCN doivent communiquer avec VNet.
-
Mettez à jour la liste de sécurité de chaque sous-réseau pour inclure des règles autorisant le trafic sortant ou entrant avec le bloc CIDR du réseau VNet ou un sous-réseau de VNet :
- Dans la console, lors de la consultation du réseau VCN qui vous intéresse, sélectionnez Listes de sécurité.
- Sélectionnez la liste de sécurité qui vous intéresse.
-
Sélectionnez Modifier toutes les règles et créez des règles, chacune pour le type de trafic souhaité. Voir les exemples de règles qui suivent.
-
Sélectionnez enregistrer les règles de la liste de sécurité au bas de la boîte de dialogue.
Pour plus d'informations sur la configuration des règles de sécurité, voir Règles de sécurité.
La règle de sécurité de trafic sortant suivante permet à une instance de créer une demande ping à un hôte externe au réseau VCN (demande d'écho ICMP type 8). Il s'agit d'une règle avec état qui autorise automatiquement la réponse. Aucune règle de trafic entrant distincte pour la réponse d'écho ICMP de type 0 n'est requise.
- Dans la section Autoriser les règles pour le trafic sortant, sélectionnez +Add Règle.
- Laissez la case sans état désélectionnée.
- CIDR de destination : Sous-réseau pertinent du VNet (10.0.0.0/16 dans le diagramme précédent)
- Protocole IP : ICMP
- Type et code : 8
- Description : Description facultative de la règle.
La règle de sécurité de trafic entrant suivante permet à une instance de recevoir une demande ping d'un hôte du réseau VNet (demande d'écho ICMP type 8). Il s'agit d'une règle avec état qui autorise automatiquement la réponse. Aucune règle de trafic sortant distincte pour la réponse ICMP de type 0 n'est requise.
- Dans la section Autoriser les règles pour le trafic entrant, sélectionnez +Add Règle.
- Laissez la case sans état désélectionnée.
- CIDR source : Sous-réseau pertinent du VNet (10.0.0.0/16 dans le diagramme précédent)
- Protocole IP : ICMP
- Type et code : 8
- Description : Description facultative de la règle.
La règle de sécurité de trafic entrant suivante permet à une instance de recevoir une connexion SSH (port TCP 22) à partir d'un hôte du réseau VNet.
- Dans la section Autoriser les règles pour le trafic entrant, sélectionnez +Add Règle.
- Laissez la case sans état désélectionnée.
- CIDR source : Sous-réseau pertinent du VNet (10.0.0.0/16 dans le diagramme précédent)
- Protocole IP : TCP
- Intervalle de ports sources : Tous
- Intervalle de ports de destination : 22
- Description : Description facultative de la règle.
La règle de sécurité de trafic entrant suivante autorise les connexions SQL*Net (port TCP 1521) à partir d'hôtes du réseau VNet.
- Dans la section Autoriser les règles pour le trafic entrant, sélectionnez +Add Règle.
- Laissez la case sans état désélectionnée.
- CIDR source : Sous-réseau pertinent du VNet (10.0.0.0/16 dans le diagramme précédent)
- Protocole IP : TCP
- Intervalle de ports sources : Tous
- Intervalle de ports de destination : 1521
- Description : Description facultative de la règle.
Configurez un circuit ExpressRoute pour Oracle Cloud Infrastructure FastConnect. Lors de la configuration du circuit, vous recevrez une clé de service de Microsoft. Enregistrez-la car vous devrez la fournir à Oracle lors de la tâche suivante.
Dans la prochaine tâche, vous configurez un circuit virtuel privé FastConnect pour Microsoft Azure : ExpressRoute. À la fin du provisionnement du circuit virtuel, le circuit ExpressRoute est mis à jour pour indiquer que l'appairage privé est activé.
- Dans la console, vérifiez que vous voyez le compartiment dans lequel vous voulez travailler. Si vous ne savez pas lequel, utilisez le compartiment qui contient la passerelle DRG. Ce choix de compartiment, ainsi qu'une politique IAM correspondante, contrôle qui peut accéder au circuit virtuel que vous êtes sur le point de créer.
- Ouvrez le menu de navigation et sélectionnez Service de réseau. Sous Connectivité client, sélectionnez FastConnect.
La page FastConnect qui s'ouvre vous permet de créer un circuit virtuel. Vous pourrez y revenir plus tard pour gérer ce dernier.
- Sélectionnez Créer une connexion.
- Sélectionnez FastConnect Partner et sélectionnez Microsoft Azure : ExpressRoute dans la liste.
-
Entrez les informations suivantes pour le circuit virtuel :
- Nom : Nom convivial. Il n'est pas nécessaire que cette valeur soit unique pour tous les circuits virtuels et vous pouvez la modifier ultérieurement. Évitez d'entrer des informations confidentielles.
- Créer dans le compartiment : Laissez tel quel (le compartiment dans lequel vous travaillez).
- Type de circuit virtuel : Sélectionnez Circuit virtuel privé.
- Compartiment de la passerelle de routage dynamique : Sélectionnez le compartiment dans lequel réside la passerelle DRG (déjà sélectionnée).
- Passerelle de routage dynamique : Sélectionnez la passerelle DRG.
- Bande passante provisionnée : Sélectionnez le même niveau de bande passante que pour le circuit ExpressRoute (ou la valeur la plus proche disponible).
- Clé Partner Service : Entrez la clé de service que vous avez reçue de Microsoft lorsque vous configurez le circuit ExpressRoute.
- Adresse IP BGP principale du client : Il s'agit de l'adresse IP BGP principale d'Azure. Entrez la troisième adresse dans le bloc CIDR principal (avec un masque de sous-réseau compris entre /28 et /31) que vous fournissez et incluez ce masque à la fin. Par exemple : 10.0.0.22/30. Pour plus d'informations sur ce champ et les suivants, voir Configuration d'une connexion.
- Adresse IP BGP principale d'Oracle (facultatif) : Vous pouvez laisser ce champ vide et Oracle déduira l'adresse à partir du bloc CIDR fourni pour l'adresse IP BGP Azure. Dans cet exemple, la valeur correcte est 10.0.0.21/30.
- Adresse IP BGP secondaire du client : Il s'agit de l'adresse IP BGP secondaire d'Azure. Entrez la troisième adresse dans le bloc CIDR secondaire (avec un masque de sous-réseau compris entre /28 et /31) que vous fournissez et incluez ce masque à la fin. Par exemple : 10.0.0.26/30.
- Adresse IP BGP principale d'Oracle (facultatif) : Vous pouvez laisser ce champ vide et Oracle déduira l'adresse à partir du bloc CIDR fourni pour l'adresse IP BGP Azure. Dans cet exemple, la valeur correcte est 10.0.0.25/30.
-
Sélectionnez Continuer.
Le circuit virtuel est créé.
- Sélectionnez Fermer.
Après avoir créé le circuit virtuel Oracle, vous n'avez pas besoin de communiquer avec Azure pour demander le provisionnement du circuit. Il s'effectue automatiquement.
Les deux circuits sont provisionnés en quelques minutes. Pour vérifier :
- Pour le circuit ExpressRoute, vérifiez que l'appairage privé est provisionné.
- Pour le circuit virtuel FastConnect, vérifiez que son statut est ACTIF. Voir Pour obtenir le statut du circuit virtuel FastConnect.
Pour le VCN :
- Déterminez quels sous-réseaux du VCN doivent communiquer avec VNet.
-
Mettez à jour la table de routage pour chacun de ces sous-réseaux afin d'inclure une nouvelle règle qui dirige le trafic destiné au CIDR du VNet vers la passerelle DRG :
- Dans la console, lors de la consultation du réseau VCN qui vous intéresse, sélectionnez Tables de routage.
- Sélectionnez la table de routage qui vous intéresse.
- Sélectionnez Modifier les règles de routage.
-
Sélectionnez + Une autre règle de routage et entrez les données suivantes :
- Type de cible : Passerelle de routage dynamique. La passerelle DRG attachée au réseau VCN est automatiquement sélectionnée en tant que cible et vous n'avez pas besoin de définir cette dernière.
- Bloc CIDR de destination : Sous-réseau pertinent du VNet (10.0.0.0/16 dans le diagramme précédent).
- Description : Description facultative de la règle.
- Sélectionnez enregistrer.
Pour VNet : Décidez quels sous-réseaux dans VNet doivent communiquer avec le VCN. Ensuite, configurez les tables de routage pour les sous-réseaux afin d'acheminer le trafic vers la passerelle VNet.
Tout trafic de sous-réseau avec une destination correspondant à la règle est dirigé vers la passerelle DRG. La passerelle DRG dirige ensuite le trafic vers le VNet en fonction des informations de session BGP du circuit virtuel.
Si vous n'avez plus besoin de la connexion et souhaitez supprimer la passerelle DRG, vous devez d'abord supprimer toutes les règles de routage du réseau VCN qui l'indiquent comme cible.
Pour plus d'informations sur la configuration des règles de routage, voir Tables de routage de VCN.
Si les groupes de sécurité VNet et les règles de sécurité de VCN sont configurés correctement, vous pouvez créer une instance dans le VCN et y accéder à partir d'un hôte dans VNet ou vous connecter à partir de l'instance à un hôte dans VNet. Dans ce cas, la connexion est prête à l'emploi.
: Si vous décidez de mettre fin à la connexion, vous devez suivre une procédure particulière. Voir Pour mettre fin à la connexion à Azure.
Gestion d'Oracle Interconnect pour Azure
- Ouvrez le menu de navigation et sélectionnez Service de réseau. Sous Connectivité client, sélectionnez FastConnect.
- Sélectionnez le compartiment dans lequel réside la connexion, puis sélectionnez la connexion qui vous intéresse. Si l'icône du circuit virtuel est verte et indique ACTIF, le circuit virtuel est provisionné et le protocole BGP a été configuré correctement. Le circuit virtuel est prêt à l'emploi.
Vous pouvez modifier les éléments suivants pour le circuit virtuel :
- Le nom
- La passerelle DRG à utiliser
Si le circuit virtuel est à l'état Provisionné, la modification de la passerelle DRG utilisée fait passer l'état à Provisionnement et pourrait provoquer l'arrêt de la connexion. Une fois le circuit virtuel reprovisionné, il retourne à l'état PROVISIONNÉ. Vérifiez que la connexion est rétablie.
- Ouvrez le menu de navigation et sélectionnez Service de réseau. Sous Connectivité client, sélectionnez FastConnect.
- Sélectionnez le compartiment dans lequel réside la connexion, puis sélectionnez-la.
- Sélectionnez le circuit virtuel.
- Sélectionnez Modifier et effectuez des modifications. Évitez d'entrer des informations confidentielles.
- Sélectionnez enregistrer.
Le diagramme suivant présente le processus global d'arrêt d'une connexion VCN-VNet.
- Dans le portail Azure, affichez le circuit ExpressRoute, puis consultez ses connexions. Vérifiez qu'aucune connexion n'existe encore pour le circuit ExpressRoute. Supprimez toutes les connexions avant de poursuivre.
-
Dans le portail Oracle, supprimer le circuit virtuel FastConnect :
- Ouvrez le menu de navigation et sélectionnez Service de réseau. Sous Connectivité client, sélectionnez FastConnect.
- Sélectionnez le compartiment dans lequel réside la connexion, puis sélectionnez-la.
- Sélectionnez le circuit virtuel.
- Sélectionnez Supprimer.
-
Confirmez à l'invite.
L'état de cycle de vie du circuit virtuel passe à FIN D'EXECUTION.
- Dans le portail Azure, vérifiez que l'appairage privé pour le circuit ExpressRoute a été supprimé. Vérifiez également que le statut du circuit ExpressRoute est maintenant "Non provisionné".
- Dans le portail Azure, supprimez le circuit ExpressRoute.
La connexion entre Azure et Oracle Cloud Infrastructure est interrompue.