Interconnexion pour Azure
Oracle Interconnect for Azure vous permet de créer une connexion inter-cloud entre Oracle Cloud Infrastructure et Microsoft Azure dans certaines régions. Cette connexion vous permet de configurer des charges globales inter-cloud sans que le trafic entre les clouds ne passe par Internet. Cette rubrique explique comment configurer des ressources d'infrastructure de fonctions de réseau virtuel pour permettre ce type de déploiement inter-cloud.
Pour plus d'informations sur les déploiements Oracle Database multicloud qui utilisent Oracle Cloud Infrastructure et Microsoft Azure, reportez-vous à Oracle Database@Azure. Ce service héberge les bases de données Oracle Exadata dans les centres de données Azure pour la latence la plus faible possible.
Points clés
- Vous pouvez connecter un réseau cloud virtuel (VCN) Oracle Cloud Infrastructure (OCI) à un réseau virtuel Microsoft Azure (VNet) et exécuter une charge de travail inter-cloud. Dans un cas d'emploi standard, vous pouvez déployer une instance Oracle Database sur OCI, puis déployer une application Oracle, .NET ou une application personnalisée dans Microsoft Azure.
- Les deux réseaux virtuels doivent appartenir à la même société et ne doivent pas présenter un chevauchement de CIDR. Oracle Interconnect for Azure requiert la création d'un circuit ExpressRoute Azure et d'un circuit virtuel OCI FastConnect.
Disponibilité
Oracle Interconnect for Azure est uniquement disponible dans les régions OCI et les emplacements ExpressRoute affichés. Pour plus d'informations sur les emplacements de région Azure et sur Azure ExpressRoute, reportez-vous à ExpressRoute, ainsi qu'aux partenaires de connectivité dans la documentation Azure.
L'image suivante présente les régions avec Oracle Interconnect for Azure, montrant 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 |
---|---|
Est du Japon (Tokyo) - NRT | Tokyo |
Singapour (Singapour) - SIN | Singapour |
Centre de la Corée du Sud (Séoul) - ICN | Séoul |
Europe, Moyen-Orient, Afrique (EMEA)
Emplacement OCI | Emplacement Azure ExpressRoute |
---|---|
Allemagne centrale (Francfort) - FRA | Francfort et Francfort2 |
Nord-ouest des Pays-Bas (Amsterdam) - AMS | Amersterdam2 |
Sud du Royaume-Uni (Londres) - LHR | Londres |
Centre de l'Afrique du Sud (Johannesburg) - JNB | Johannesburg |
Amérique latine (LATAM)
Emplacement OCI | Emplacement Azure ExpressRoute |
---|---|
Sud-est du Brésil (Vinhedo) - VCP | Campinas |
Amérique du Nord (NA)
Emplacement OCI | Emplacement Azure ExpressRoute |
---|---|
Sud-est du Canada (Toronto) - YYZ | Toronto et Toronto2 |
Est des Etats-Unis (Ashburn) - IAD | Washington DC et Washington DC2 |
Ouest des Etats-Unis (Phoenix) - PHX | Phoenix |
Ouest des Etats-Unis (San José) - SJC | Silicon Valley |
Présentation du trafic pris en charge
Vous trouverez ci-après plus d'informations sur les types de trafic pris en charge.
Connexion de VCN à VNet : extension d'un cloud à un autre
Vous pouvez connecter un VCN et VNet de sorte que le trafic qui utilise des adresses IP privées passe par la connexion inter-cloud.
Par exemple, le diagramme suivant montre un VCN connecté à un VNet. Les ressources dans VNet exécutent une application .NET qui accède à une base de données Oracle qui s'exécute sur les ressources du service Database dans le VCN. Le trafic entre l'application et la base de données utilise un circuit logique exécuté sur la connexion entre Azure et Oracle Cloud Infrastructure.
Pour activer la connexion entre le VCN et VNet, vous configurez à la fois un circuit virtuel Oracle Cloud Infrastructure FastConnect et un circuit Azure ExpressRoute. La connexion présente une redondance intégrée, ce qui signifie que vous ne devez configurer qu'un seul circuit virtuel FastConnect et un seul circuit ExpressRoute. La bande passante pour la connexion correspond à la valeur de bande passante sélectionnée pour le circuit ExpressRoute.
Pour obtenir des instructions, reportez-vous à la section Setting Up a Connection.
Réseaux cloud virtuels appairés
La connexion permet au trafic de circuler depuis VNet via le VCN connecté vers un VCN appairé dans la même région Oracle Cloud Infrastructure ou dans une autre région.
Types de trafic non pris en charge par la connexion
Cette connexion inter-cloud n'autorise pas le trafic entre le réseau sur site via le VCN vers le VNet, ou depuis le réseau sur site via le VNet vers le VCN.
Conséquences importantes liées à la connexion des clouds
Cette section récapitule certaines implications en matière de contrôle d'accès, de sécurité et de performances d'Oracle Interconnect for Azure. En général, vous pouvez contrôler l'accès et le trafic à l'aide de stratégies 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 VCN. Des implications similaires affectent VNet. Comme pour le VCN, vous pouvez utiliser des ressources Azure telles que des tables de routage et des groupes de sécurité réseau pour sécuriser VNet.
Contrôle de l'établissement d'une connexion
Avec les stratégies Oracle Cloud Infrastructure IAM, vous pouvez contrôler les éléments suivants :
- Qui, dans l'organisation, est autorisé à créer un circuit virtuel FastConnect (reportez-vous à Configuration d'une connexion). La suppression de la stratégie IAM concernée n'a aucune incidence sur les connexions existantes à une instance VNet, mais seulement sur la possibilité de créer une connexion ultérieure.
- Les utilisateurs pouvant gérer les tables de routage, les groupes de sécurité 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 de paquets sur la connexion avec les tables de routage dans le VCN. Par exemple, vous pouvez limiter le trafic uniquement à des sous-réseaux spécifiques du réseau virtuel.
Sans supprimer la connexion, vous pouvez arrêter le flux de 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 enlevant toute règle de sécurité qui autorise le trafic entrant ou sortant avec le réseau virtuel. Cela n'arrête pas le trafic qui passe sur la connexion, mais arrête celui au niveau de la carte d'interface réseau virtuelle.
Contrôle des types de trafic spécifiques autorisés
Assurez-vous que l'ensemble du trafic entrant et sortant avec VNet est prévu ou attendu et tel que défini. Mettez en oeuvre un groupe de sécurité réseau Azure et des règles de sécurité Oracle qui indiquent explicitement les types de trafic que l'un des clouds peut envoyer à l'autre et accepter de l'autre.
Les instances Oracle Cloud Infrastructure exécutant des images de plateforme Linux ou Windows comportent également des règles d'un pare-feu qui contrôlent l'accès à l'instance. Lors du dépannage de l'accès à une instance, assurez-vous que les éléments suivants sont définis correctement : les groupes de sécurité réseau dans lesquels l'instance se trouve, les listes de sécurité associées au sous-réseau de l'instance et les règles de pare-feu de l'instance.
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. Pour référence, voici les commandes permettant d'ouvrir un port (1521 dans cet exemple) :
sudo firewall-cmd --zone=public --permanent --add-port=1521/tcp
sudo firewall-cmd --reload
En ce qui concerne les instances comportant un volume d'initialisation iSCSI, la commande --reload
précédente peut entraîner des problèmes. Pour obtenir des détails et une solution de contournement, reportez-vous à Le système 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 basées sur le système d'exploitation sur les instances du VCN. Il peut y avoir des configurations par défaut qui ne s'appliquent pas au CIDR du VCN, mais qui s'appliquent par inadvertance au CIDR du réseau virtuel.
Utilisation des règles de liste de sécurité par défaut avec le VCN
Si les sous-réseaux du 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 à partir de n'importe où (0.0.0.0/0, et donc VNet) :
- Règle entrante avec conservation de statut autorisant le trafic sur le port TCP 22 (SSH) à partir de 0.0.0.0/0 et de n'importe quel port source
- Règle entrante avec conservation de statut autorisant le trafic ICMP de type 3 et de code 4 à partir de 0.0.0.0/0 et de n'importe quel port source
Evaluez ces règles et déterminez si vous voulez les conserver ou 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 à l'impact sur les performances et aux risques de sécurité
En général, préparez le VCN pour les façons dont il pourrait être affecté par le VNet. Par exemple, la charge sur le VCN ou ses instances pourrait augmenter. Ou le VCN pourrait subir une attaque malveillante directement à partir de ou par le biais de VNet.
En ce qui concerne les performances : si le VCN fournit un service à VNet, préparez-vous à augmenter le service pour répondre aux demandes de VNet. Cela peut signifier être préparé à créer davantage d'instances si nécessaire. Ou si vous êtes préoccupé par les niveaux élevés de trafic réseau à destination du 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. Ces règles de sécurité sans conservation de statut peuvent également ralentir l'impact d'une attaque par déni de service (DoS).
En ce qui concerne les risques de sécurité : si VNet est connecté à Internet, le VCN peut être exposé aux attaques par refus. Une attaque de rebond implique un hôte malveillant sur Internet envoyant du trafic vers le VCN qui semble provenir de VNet. Pour éviter cette situation, comme mentionné précédemment, utilisez des règles de sécurité afin de limiter soigneusement le trafic entrant à partir 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 VCN et VNet (pour plus d'informations, reportez-vous à Présentation du trafic pris en charge).
Prérequis : 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 VCN Oracle Cloud Infrastructure avec des sous-réseaux et une passerelle de routage dynamique (DRG) attachée. N'oubliez pas de attacher le DRG au VCN après l'avoir créé. Si vous disposez déjà d'un VPN site à site ou d'un FastConnect entre le réseau sur site et le VCN, le VCN dispose déjà d'un DRG attaché. Vous utilisez cette même passerelle ici pour configurer la connexion à Azure.
Pour rappel, voici un tableau répertoriant les composants de fonctions de réseau comparables impliqués de chaque côté de la connexion.
Composant | Azure | Oracle Cloud Infrastructure |
---|---|---|
Réseau virtuel | Réseau virtuel (VNet) | Réseau cloud virtuel |
Circuit virtuel | Circuit ExpressRoute | Circuit virtuel privé FastConnect |
Passerelle | passerelle de réseau virtuel | Passerelle de routage dynamique |
Routage | tables de routage | tables de routage |
Règles de sécurité | groupes de sécurité réseau | groupes de sécurité réseau, listes de sécurité |
Prérequis : informations BGP nécessaires
La connexion entre le VCN et VNet utilise le 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 d'adresses BGP principale (une adresse IP pour le côté Oracle, une adresse IP pour le côté Azure)
- Une paire d'adresses BGP distincte et secondaire (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 de /28 à /31.
La deuxième et la troisième adresses dans chaque bloc d'adresses sont utilisées pour la paire d'adresses IP BGP:
- La deuxième adresse du bloc concerne le côté Oracle de la session BGP
- La troisième adresse du bloc concerne le côté Azure de la session BGP
La première et la dernière adresse du bloc sont utilisées à d'autres fins internes.
Par exemple, si le CIDR est 10.0.0.20/30, les adresses dans le bloc sont les suivantes :
- 10.0.0.20
- 10.0.0.21 : utilisez cette adresse pour le côté Oracle (dans la console Oracle, saisissez l'adresse sous la forme 10.0.0.21/30).
- 10.0.0.22 : permet d'utiliser cette adresse pour le côté Azure (dans la console Oracle, entrez l'adresse sous la forme 10.0.0.22/30. Cette adresse est désignée comme le côté client dans la console).
- 10.0.0.23
N'oubliez pas que vous devez également fournir un second bloc de même taille pour les adresses BGP secondaires. Par exemple : 10.0.0.24/30. Dans ce cas, 10.0.0.25 est destiné au côté Oracle et 10.0.0.26 au côté Azure. Dans la console Oracle, vous devez les saisir comme suit : 10.0.0.25/30 et 10.0.0.26/30.
Prérequis : stratégie IAM requise
Vous disposez probablement des accès Azure Active Directory et Oracle Cloud Infrastructure IAM nécessaires pour créer et utiliser les ressources réseau Azure et Oracle appropriées. Pour IAM : si votre compte utilisateur fait partie du groupe Administrateurs, vous disposez des autorisations requises. Sinon, cette stratégie couvre toutes les ressources Networking :
Allow group NetworkAdmins to manage virtual-network-family in tenancy
Pour créer et gérer uniquement un circuit virtuel, vous devez disposer d'une stratégie telle que la suivante :
Allow group VirtualCircuitAdmins to manage drgs in tenancy
Allow group VirtualCircuitAdmins to manage virtual-circuits in tenancy
Pour plus d'informations, reportez-vous à Stratégies IAM pour Networking.
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 VCN et de VNet, puis à configurer les règles de sécurité pour qu'elles correspondent. Voici les types généraux de règles à ajouter :
- Règles entrantes pour les types de trafic à autoriser à partir des sous-réseaux appropriés de l'autre cloud.
- Règle sortante autorisant le trafic sortant d'un cloud vers l'autre. Si le sous-réseau du réseau cloud virtuel comporte déjà une règle sortante générale pour tous les types de protocole vers toutes les destinations (0.0.0.0/0), alors il n'est pas nécessaire d'ajouter une règle spéciale pour le trafic vers le réseau virtuel. La liste de sécurité par défaut du VCN inclut une règle sortante par défaut large.
Voici les types de trafic recommandés à autoriser entre le VNet et le VCN :
- Trafic de type ping dans les deux directions pour tester la connexion de chaque côté
- SSH (port TCP 22)
- Connexions client à une base de données Oracle (SQL*NET sur le port TCP 1521)
Autorisez uniquement le trafic vers et depuis des plages d'adresses spécifiques qui vous intéressent (par exemple, les sous-réseaux appropriés de l'autre cloud).
Pour le réseau cloud virtuel :
La procédure suivante utilise des listes de sécurité, mais vous pouvez aussi implémenter des règles de sécurité dans plusieurs groupes de sécurité réseau, puis placer les ressources appropriées du réseau cloud virtuel dans ces groupes de sécurité réseau.
Pour VNet : déterminez les sous-réseaux dans VNet qui doivent communiquer avec le VCN. Ensuite, configurez les groupes de sécurité réseau pour ces sous-réseau de sorte à autoriser le trafic.
- Décidez des sous-réseaux du VCN qui 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 virtuel ou un sous-réseau de VNet :
- Dans la console, lors de l'affichage du 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, une pour chaque type de trafic spécifique que vous voulez autoriser. Reportez-vous aux exemples de règles qui suivent.
-
Sélectionnez Enregistrer les règles de liste de sécurité en bas de la boîte de dialogue.
Pour plus d'informations sur la configuration des règles de sécurité, reportez-vous à Règles de sécurité.
La règle de sécurité sortante suivante permet à une instance de créer une demande ping vers un hôte en dehors du VCN (demande d'écho ICMP type 8). Il s'agit d'une règle avec conservation de statut qui autorise automatiquement la réponse. Aucune règle entrante distincte pour la réponse d'écho ICMP de type 0 n'est requise.
- Dans la section Règles d'autorisation pour la sortie, sélectionnez +Add Règle.
- Ne cochez pas la case sans conservation de statut.
- CIDR de destination : sous-réseau pertinent dans le réseau virtuel (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é entrante suivante permet à une instance de recevoir une demande ping à partir d'un hôte dans le réseau virtuel (demande d'écho ICMP de type 8). Il s'agit d'une règle avec conservation de statut qui autorise automatiquement la réponse. Aucune règle sortante distincte pour la réponse d'écho ICMP de type 0 n'est requise.
- Dans la section Règles d'autorisation pour l'entrée, sélectionnez +Add Règle.
- Ne cochez pas la case sans conservation de statut.
- CIDR source : sous-réseau pertinent dans le réseau virtuel (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é entrante suivante permet à une instance de recevoir une connexion SSH (port TCP 22) à partir d'un hôte dans le réseau virtuel.
- Dans la section Règles d'autorisation pour l'entrée, sélectionnez +Add Règle.
- Ne cochez pas la case sans conservation de statut.
- CIDR source : sous-réseau pertinent dans le réseau virtuel (10.0.0.0/16 dans le diagramme précédent)
- Protocole IP : TCP
- Plage de ports source : tous
- Plage de ports de destination : 22
- Description : description facultative de la règle.
La règle de sécurité entrante suivante autorise les connexions SQL*Net (port TCP 1521) à partir des hôtes dans le réseau virtuel.
- Dans la section Règles d'autorisation pour l'entrée, sélectionnez +Add Règle.
- Ne cochez pas la case sans conservation de statut.
- CIDR source : sous-réseau pertinent dans le réseau virtuel (10.0.0.0/16 dans le diagramme précédent)
- Protocole IP : TCP
- Plage de ports source : tous
- Plage de ports de destination : 1521
- Description : description facultative de la règle.
Configurez un circuit ExpressRoute vers Oracle Cloud Infrastructure FastConnect. Lors de la configuration du circuit, vous recevez une clé de service de Microsoft. Enregistrez cette clé de service car vous devrez la fournir à Oracle dans la tâche suivante.
Dans la tâche suivante, vous configurez un circuit virtuel privé FastConnect vers Microsoft Azure : ExpressRoute. Lorsque le provisionnement du circuit virtuel est terminé, le circuit ExpressRoute est mis à jour pour indiquer que l'appairage privé est activé.
- Dans la console, vérifiez que vous visualisez le compartiment dans lesquels vous voulez travailler. Si vous ne savez pas lequel, utilisez le compartiment qui contient le DRG. Ce choix de compartiment, accompagné d'une stratégie IAM correspondante, permet de déterminer l'accès au circuit virtuel qui vous êtes sur au point de créer.
- Ouvrez le menu de navigation et sélectionnez Fonctions de réseau. Sous Connectivité client, sélectionnez FastConnect.
La page FastConnect obtenue est l'endroit où vous créez un circuit virtuel et où vous reviendrez lorsque vous aurez besoin de le gérer.
- Sélectionnez Créer une connexion.
- Sélectionnez FastConnect, partenaire et sélectionnez Microsoft Azure : ExpressRoute dans la liste.
-
Entrez les éléments suivants pour le circuit virtuel :
- Nom : nom convivial. Il n'est pas nécessaire que la valeur soit unique parmi les circuits virtuels. Vous pouvez la modifier ultérieurement. Evitez de saisir des informations confidentielles.
- Créer dans le compartiment : à laisser tel quel ( compartiment dans lequel vous travaillez).
- Type de circuit virtuel : sélectionnez Circuit virtuel privé.
- Compartiment de passerelle de routage dynamique : sélectionnez le compartiment dans lequel réside le DRG (déjà sélectionné).
- Passerelle de routage dynamique : sélectionnez la passerelle de routage dynamique.
- Bande passante provisionnée : sélectionnez le même niveau de bande passante que celui choisi pour le circuit ExpressRoute (ou la valeur la plus proche disponible).
- Clé Partner Service : entrez la clé de service reçue de Microsoft lors de la configuration du circuit ExpressRoute.
- Adresse IP BGP principale client : ce champ correspond à l'adresse IP BGP principale Azure. Saisissez la troisième adresse du bloc CIDR principal (avec un masque de sous-réseau de /28 à /31) que vous fournissez et incluez le masque de sous-réseau à la fin. Par exemple : 10.0.0.22/30. Pour plus d'informations sur ce champ et les suivants, reportez-vous à Configuration d'une connexion.
- adresse IP BGP principale Oracle : (facultatif) vous pouvez laisser ce champ vide. Oracle déduit l'adresse en fonction 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 client : ce champ correspond à l'adresse IP BGP secondaire Azure. Saisissez la troisième adresse du bloc CIDR secondaire (avec un masque de sous-réseau de /28 à /31) que vous fournissez et incluez le masque de sous-réseau à la fin. Par exemple : 10.0.0.26/30.
- Adresse IP BGP principale Oracle : (facultatif) vous pouvez laisser ce champ vide. Oracle déduit l'adresse en fonction 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 contacter Azure pour demander son provisionnement. Cette opération est automatique.
Les deux circuits sont provisionnés en quelques minutes. Pour vérifier, procédez comme suit :
- Pour le circuit ExpressRoute, vérifiez que l'appairage privé est provisionné.
- Vérifiez que le statut du circuit virtuel FastConnect est UP. Reportez-vous à Pour obtenir le statut du circuit virtuel FastConnect.
Pour le réseau cloud virtuel :
- Décidez des sous-réseaux du VCN qui doivent communiquer avec VNet.
-
Mettez à jour la table de routage de chacun de ces sous-réseaux pour inclure une nouvelle règle qui dirige le trafic destiné au CIDR du réseau virtuel vers le DRG :
- Dans la console, lors de l'affichage du 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 saisissez les éléments suivants :
- Type de cible : passerelle de routage dynamique. La passerelle de routage dynamique attachée du réseau cloud virtuel est automatiquement sélectionnée en tant que cible. Vous n'avez pas besoin d'indiquer de cible.
- Bloc CIDR de destination : sous-réseau approprié dans le réseau virtuel (10.0.0.0/16 dans le diagramme précédent).
- Description : description facultative de la règle.
- Sélectionnez Sauvegarder.
Pour VNet : déterminez les sous-réseaux dans VNet qui doivent communiquer avec le VCN. Ensuite, configurez les tables de routage de ces sous-réseaux de sorte à acheminer le trafic vers la passerelle du réseau virtuel.
Tout trafic de sous-réseau dont la destination correspond à la règle est routé vers le DRG. La passerelle de routage dynamique a ensuite la capacité d'acheminer le trafic vers le réseau virtuel en fonction des informations de session BGP du circuit virtuel.
Plus tard, si vous n'avez plus besoin de la connexion et que vous souhaitez supprimer le DRG, vous devez d'abord supprimer toutes les règles de routage dans le VCN qui spécifient le DRG comme cible.
Pour plus d'informations sur la configuration des règles de routage, reportez-vous à Tables de routage de réseau cloud virtuel.
Si les groupes de sécurité VNet et les règles de sécurité 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. Si vous le pouvez, la connexion est prête à être utilisée.
Si vous décidez de mettre fin à la connexion, vous devez suivre un processus particulier. Reportez-vous à Procédure de terminaison de la connexion à Azure.
Gestion d'Oracle Interconnect pour Azure
- Ouvrez le menu de navigation et sélectionnez Fonctions de réseau. Sous Connectivité client, sélectionnez FastConnect.
- Sélectionnez le compartiment dans lequel réside la connexion, puis la connexion qui vous intéresse. Si l'icône du circuit virtuel est verte et indique UP, le circuit virtuel est provisionné et BGP est configuré correctement. Le circuit virtuel est prêt à être utilisé.
Vous pouvez modifier ces éléments pour le circuit virtuel :
- Nom
- Passerelle de routage dynamique utilisée
Si le circuit virtuel est à l'état PROVISIONED, la modification du DRG qu'il utilise fait passer l'état à PROVISIONING et peut provoquer l'arrêt de la connexion. Une fois qu'Oracle a reprovisionné le circuit virtuel, son état revient à PROVISIONED. Vérifiez que la connexion est de nouveau active et fonctionnelle.
- Ouvrez le menu de navigation et sélectionnez Fonctions 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. Evitez de saisir des informations confidentielles.
- Sélectionnez Sauvegarder.
Le diagramme suivant présente le processus global de terminaison d'une connexion VCN à VNet.
- Sur le portail Azure, affichez le circuit ExpressRoute, puis ses connexions. Vérifiez qu'aucune connexion n'existe encore pour le circuit ExpressRoute. Supprimez toutes les connexions avant de continuer.
-
Dans le portail Oracle, supprimez le circuit virtuel FastConnect :
- Ouvrez le menu de navigation et sélectionnez Fonctions 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électionnezSupprimer.
-
Confirmez l'opération lorsque vous y êtes invité.
L'état de cycle de vie du circuit virtuel passe à TERMINATING.
- Sur 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 passé à "Non provisionné".
- Sur le portail Azure, supprimez le circuit ExpressRoute.
La connexion entre Azure et Oracle Cloud Infrastructure a pris fin.
Dépannage
Reportez-vous à Problèmes de terminaison de la connexion Azure.