Accès à Microsoft Azure
Oracle et Microsoft ont créé 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 Oracle Database multinuages 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 virtuel Microsoft Azure (VNet) à un réseau en nuage virtuel (VCN) Oracle Cloud Infrastructure (OCI) et exécuter une charge de travail internuage. Généralement, vous déployez votre base de données Oracle sur OCI, puis 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. La connexion requiert la création d'un circuit Azure ExpressRoute et d'un circuit virtuel OCI FastConnect.
Disponibilité
La connexion internuage entre OCI et Azure n'est disponible que dans les emplacements de région et ExpressRoute listés ci-dessous. Pour plus d'informations sur les emplacements de région Azure et Azure ExpressRoute, voir ExpressRoute Emplacements d'appairage et partenaires de connectivité dans la documentation sur Azure.
L'illustration suivante présente les régions avec interconnexion.
Asie-Pacifique (APAC)
| Emplacement OCI - Clé | Emplacement Azure ExpressRoute 
|
|---|---|
| Japon - Est (Tokyo) NRT | Tokyo |
| Singapour - SIN | Singapour |
| Corée - Centre (Séoul) - 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 (Montréal) (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 VNet à VCN : extension d'un nuage à un autre
Vous pouvez connecter votre réseau VNet et votre réseau VCN afin que le trafic qui utilise des adresses IP privées passe par la connexion internuage.
Par exemple, le diagramme suivant présente une connexion entre un réseau VNet et un réseau VCN. Les ressources du réseau 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 suit un circuit logique exécuté sur la connexion internuage entre Azure et Oracle Cloud Infrastructure.
Pour activer la connexion entre le réseau VNet et le réseau VCN, configurez un circuit Azure ExpressRoute et un circuit virtuel FastConnect Oracle Cloud Infrastructure. La connexion a une redondance intégrée. Il suffit donc de configurer un seul circuit ExpressRoute et un seul circuit virtuel FastConnect. La bande passante pour la connexion est la valeur choisie pour le circuit ExpressRoute.
Pour obtenir des instructions, voir Configuration d'une connexion VNet à VCN.
Réseaux en nuage virtuels appairés
La connexion permet au trafic partant du réseau VNet de passer par le réseau VCN connecté pour arriver à un réseau VCN appairé 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 partant de votre réseau sur place, passant par le réseau VCN pour arriver au réseau VNet, ou partant de votre réseau sur place, passant par le réseau VNet pour arriver au réseau VCN.
Implications importantes liées à la connexion de nuages
Cette section résume certaines implications relatives au contrôle d'accès, à la sécurité et à la performance de la connexion de votre réseau VCN à un réseau VNet. En général, vous pouvez contrôler l'accès et le trafic au moyen de politiques GIA, de tables de routage et de règles de sécurité dans le réseau VCN.
Les sections qui suivent détaillent les implications du point de vue de votre réseau VCN. Des implications similaires affectent votre réseau VNet. Comme avec votre réseau 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 votre réseau VNet.
Contrôle de l'établissement d'une connexion
Avec les politiques GIA d'Oracle Cloud Infrastructure, vous pouvez contrôler :
- Qui dans votre organisation a l'autorisation de créer un circuit virtuel FastConnect (voir Configuration d'une connexion VNet à VCN). La suppression de la politique GIA appropriée n'affecte aucune connexion existante à un réseau VNet, uniquement la capacité 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 vos réseaux VCN et VNet, vous pouvez contrôler le flux du paquet sur la connexion à l'aide de tables de routage dans votre réseau VCN. Par exemple, vous pouvez restreindre le trafic à certains sous-réseaux du VNet.
Sans interrompre la connexion, vous pouvez arrêter le flux du trafic vers le réseau VNet en supprimant simplement les règles de routage qui dirigent le trafic de votre réseau VCN vers le réseau 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
Il est important de vérifier que tout le trafic sortant et entrant du réseau VNet est prévu ou attendu, et correctement 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 votre 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 --reloadPour 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-feux, vous devez tester d'autres configurations en fonction du système d'exploitation sur les instances de votre réseau VCN. Il est possible que certaines configurations par défaut ne s'appliquent pas au bloc CIDR de votre réseau VCN, mais à celui du réseau VNet.
Utilisation des règles de liste de sécurité par défaut avec votre réseau VCN
Si les sous-réseaux de votre 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ù (c'est-à-dire, 0.0.0.0/0 et donc du réseau 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, vous devez vous assurer que tout le trafic entrant ou sortant autorisé est attendu et défini correctement.
Préparation aux incidences sur la performance et aux risques de sécurité
En règle générale, préparez votre réseau VCN aux effets éventuels qu'aurait sur lui le réseau VNet. Par exemple, la charge sur votre réseau VCN ou ses instances peut augmenter. Ou votre réseau VCN peut subir une attaque malveillante directement du réseau VNet ou par son intermédiaire.
En ce qui concerne la performance : si votre réseau VCN fournit un service au réseau VNet, soyez prêt à augmenter votre service afin de répondre aux exigences du réseau VNet. Il vous faudra donc lancer des instances supplémentaires si nécessaire. Ou si vous vous inquiétez des niveaux élevés de trafic réseau qui viennent sur votre réseau VCN, envisagez l'utilisation de règles de sécurité sans état pour réduire le niveau de suivi de connexion que votre réseau 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, votre VCN peut être exposé à des attaques par rebond. Une attaque de rebond consiste en l'envoi à votre VCN, par un hôte malveillant sur Internet, de trafic qui semble provenir de VNet. Pour prévenir cette situation, comme mentionné précédemment, utilisez vos règles de sécurité pour limiter soigneusement le trafic entrant provenant du réseau VNet au trafic attendu et bien défini.
Configuration d'une connexion VNet à VCN
Cette section décrit comment configurer la connexion logique entre un réseau VNet et un réseau VCN (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 réseau 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. Il est facile d'oublier d'attacher la passerelle DRG à votre réseau VCN après sa création. Si vous disposez déjà de RPV site à site ou de FastConnect entre votre réseau sur place et votre réseau en nuage virtuel, ce dernier est déjà associé à une passerelle. 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 VNet et le réseau VCN utilise un routage dynamique BGP. Lorsque vous configurez le circuit virtuel Oracle, vous fournissez les adresses IP BGP qui seront 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. Plus précisément :
- 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 GIA requise
Il est supposé que vous disposez de l'accès nécessaire au répertoire Azure Active Directory et d'un accès Oracle Cloud Infrastructure - GIA pour créer et utiliser les ressources de réseau Azure et Oracle appropriées. Plus précisément pour la politique GIA : Si votre utilisateur appartient au groupe Administrateurs, vous disposez de l'autorité requise.
Dans le cas contraire, une politique semblable à celle-ci couvre généralement toutes les ressources de réseau :
Allow group NetworkAdmins to manage virtual-network-family in tenancyPour seulement créer et gérer un circuit virtuel, vous devez disposer d'une politique semblable à celle-ci :
Allow group VirtualCircuitAdmins to manage drgs in tenancy
Allow group VirtualCircuitAdmins to manage virtual-circuits in tenancyPour 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 réseau VNet et du réseau en nuage virtuel.
La première tâche consiste à déterminer le trafic qui doit circuler entre les sous-réseaux pertinents au sein du réseau VNet et du réseau VCN, puis à configurer les groupes de sécurité VNet et les règles de sécurité VCN en conséquence. Voici les types généraux de règle à ajouter :
- Règles de trafic entrant pour les types de trafic que vous voulez autoriser dans un nuage à partir d'un autre, en particulier à 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 règle de trafic sortant large par défaut.
Plus précisément, voici les types de trafic autorisés entre les réseaux 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 VNet : Déterminez quels sous-réseaux de votre réseau VNet doivent communiquer avec le réseau VCN. Configurez ensuite les groupes de sécurité de réseau pour ces sous-réseaux afin d'autoriser le trafic.
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.
- Déterminez quels sous-réseaux de votre réseau en nuage virtuel doivent communiquer avec le réseau VNet.
-
Mettez à jour la liste de sécurité de chacun des sous-réseaux afin d'inclure des règles autorisant le trafic sortant ou entrant spécifiquement avec le bloc CIDR du réseau VNet ou un sous-réseau de ce dernier :
- Dans la console, lorsque vous consultez le réseau VCN qui vous intéresse, cliquez sur Listes de sécurité.
- Cliquez sur la liste de sécurité qui vous intéresse.
-
Cliquez sur Modifier toutes les règles et créez des règles (une pour chaque type de trafic souhaité).
-
Cliquez sur 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 lancer une commande 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, cliquez sur +Ajouter une 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, cliquez sur +Ajouter une 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, cliquez sur +Ajouter une 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, cliquez sur +Ajouter une 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, votre 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 choisir, utilisez le compartiment qui contient la passerelle DRG à laquelle vous vous connecterez. Ce choix de compartiment, ainsi qu'une politique GIA correspondante, contrôle qui peut accéder au circuit virtuel que vous allez créer.
-
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.
- Cliquez sur Créer une connexion.
- Sélectionnez Partenaire FastConnect et choisissez Microsoft Azure: ExpressRoute dans la liste.
-
Entrez les informations suivantes pour votre circuit virtuel :
- Nom : Nom convivial de votre choix. Cette valeur n'est pas nécessairement unique pour un circuit virtuel 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 actuellement).
- 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 (il devrait déjà être sélectionné).
- Passerelle de routage dynamique : Sélectionnez la passerelle DRG.
- Bande passante provisionnée : Choisissez le même niveau de bande passante que pour le circuit ExpressRoute (ou la valeur la plus proche disponible).
- Clé du service du partenaire : Entrez la clé du service que vous avez reçue de Microsoft lors de la configuration du 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 VNet à VCN.
- Adresse IP BGP principale d'Oracle (facultative) : Vous pouvez laisser ce champ vide et Oracle déduira l'adresse à partir du bloc CIDR fourni pour l'adresse IP BGP d'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 (facultative) : Vous pouvez laisser ce champ vide et Oracle déduira l'adresse à partir du bloc CIDR fourni pour l'adresse IP BGP d'Azure. Dans cet exemple, la valeur correcte est 10.0.0.25/30.
-
Cliquez sur Continuer.
Le circuit virtuel est créé.
- Cliquez sur Fermer.
Une fois le circuit virtuel Oracle créé, vous n'avez pas besoin de communiquer avec Azure pour demander le provisionnement du circuit. Il s'effectue automatiquement.
Après quelques minutes, les deux circuits doivent être provisionnés. Pour vérifier :
- Pour le circuit ExpressRoute, vérifiez que l'appairage privé est provisionné.
- Pour le circuit virtuel FastConnect, vérifiez que le statut est ACTIF. Voir Pour obtenir le statut de votre circuit virtuel FastConnect.
Pour VNet : Déterminez quels sous-réseaux de votre réseau VNet doivent communiquer avec le réseau VCN. Ensuite, configurez les tables de routage pour les sous-réseaux afin d'acheminer le trafic vers la passerelle VNet.
Pour le VCN :
- Déterminez quels sous-réseaux de votre réseau en nuage virtuel doivent communiquer avec le réseau VNet.
-
Mettez à jour la table de routage pour chaque sous-réseau afin d'inclure une nouvelle règle qui dirige le trafic destiné au CIDR du VNet vers votre DRG :
- Dans la console, lorsque vous consultez le réseau VCN qui vous intéresse, cliquez sur Tables de routage.
- Cliquez sur la table de routage qui vous intéresse.
- Cliquez sur Modifier les règles de routage.
-
Cliquez sur + 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.
- Cliquez sur Save (Enregistrer).
Tout le trafic de sous-réseau dont la destination correspond à la règle est acheminé vers votre passerelle DRG. La passerelle DRG dirige ensuite le trafic vers le VNet en fonction des informations de session BGP du circuit virtuel.
Lorsque vous n'aurez plus besoin de la connexion et voudrez supprimer votre passerelle DRG, vous devrez 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.
Selon la configuration de vos groupes de sécurité VNet et de vos règles de sécurité VCN, vous devez être en mesure de créer une instance dans votre service VCN et d'y accéder à partir d'un hôte du VNet. Ou vous devez pouvoir vous connecter de l'instance à un hôte du VNet. Dans ce cas, votre 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'une connexion VNet à VCN
-
- Sélectionnez le compartiment dans lequel réside la connexion, puis cliquez sur 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 ces éléments de votre circuit virtuel :
- Le nom
- La passerelle DRG à utiliser
Si votre circuit virtuel est à l'état PROVISIONNÉ, la modification de la passerelle DRG utilisée fait passer l'état à PROVISIONNEMENT et peut 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.
-
- Sélectionnez le compartiment dans lequel réside la connexion, puis cliquez sur cette dernière.
- Cliquez sur le circuit virtuel.
- Cliquez sur Modifier et effectuez vos changements. Évitez d'entrer des informations confidentielles.
- Cliquez sur Save (Enregistrer).
Le diagramme suivant présente le processus global d'arrêt d'une connexion VNet à VCN.
- Dans le portail Azure, affichez le circuit ExpressRoute, puis consultez ses connexions. Vérifiez qu'il n'existe plus aucune connexion pour le circuit ExpressRoute. Supprimez toutes les connexions avant de poursuivre.
-
Dans le portail Oracle, supprimez votre circuit virtuel FastConnect :
-
- Sélectionnez le compartiment dans lequel réside la connexion, puis cliquez sur cette dernière.
- Cliquez sur le circuit virtuel.
- Cliquez sur 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.