Documentation Oracle Cloud Infrastructure

Présentation de Networking

Lorsque vous travaillez avec Oracle Cloud Infrastructure, l'une des premières étapes consiste à configurer un réseau cloud virtuel (VCN) pour les ressources cloud. Cette rubrique vous présente les composants d'Oracle Cloud Infrastructure Networking et les scénarios standard pour l'utilisation d'un réseau cloud virtuel.

Conseil

Regardez une présentation vidéo du service.

Composants de Networking

Le service Networking utilise des versions virtuelles de composants réseau classiques que vous connaissez peut-être déjà :

Réseau cloud virtuel
Réseau privé virtuel que vous configurez dans les centres de données Oracle. Il ressemble beaucoup à un réseau classique, avec des règles de pare-feu et des types de passerelle de communication spécifiques que vous pouvez décider d'utiliser. Un VCN réside dans une seule région Oracle Cloud Infrastructure et couvre un ou plusieurs blocs CIDR (IPv4 et IPv6, si activé). Reportez-vous à Taille de réseau cloud virtuel et plages d'adresses autorisées. Les termes réseau cloud virtuel, VCN et réseau cloud sont utilisés de façon interchangeable dans cette documentation. Pour plus d'informations, reportez-vous à Réseaux cloud virtuels et sous-réseaux.
Sous-réseaux

Sous-divisions définies dans un réseau cloud virtuel (par exemple, 10.0.0.0/24, 10.0.1.0/24 ou 2001:DB8::/64). Les sous-réseaux contiennent des cartes d'interface réseau virtuelles (VNIC) qui sont attachées aux instances. Chaque sous-réseau se compose d'une plage contiguë d'adresses IP (pour IPv4 et IPv6, si activé) qui ne chevauchent pas d'autres sous-réseaux dans le VCN. Vous pouvez définir un sous-réseau pour exister dans un seul domaine de disponibilité ou dans toute une région (nous vous recommandons les sous-réseaux régionaux). Les sous-réseaux agissent comme une unité de configuration dans le VCN : toutes les cartes d'interface réseau virtuelles d'un sous-réseau particulier utilisent la même table de routage, les mêmes listes de sécurité et les mêmes options DHCP (voir les définitions qui suivent). Vous pouvez définir un sous-réseau comme public ou privé lors de sa création. Le terme privé signifie que les VNIC du sous-réseau ne peuvent pas disposer d'adresses IPv4 publiques et que la communication Internet avec les adresses IPv6 est interdite. Le terme public signifie que les VNIC du sous-réseau peuvent disposer d'adresses IPv4 publiques et que la communication Internet avec les adresses IPv6 est autorisée. Reportez-vous à Accès à Internet.

Carte d'interface réseau virtuelle
Carte d'interface réseau virtuelle (VNIC) attachée à une instance et résidant dans un sous-réseau pour permettre une connexion au réseau cloud virtuel du sous-réseau. Une VNIC est le composant utilisé par l'instance pour se connecter avec des adresses à l'intérieur et à l'extérieur du VCN. Chaque instance dispose d'une carte d'interface réseau virtuelle principale créée lors de la création de l'instance et ne peut pas être enlevée. Vous pouvez ajouter des VNIC secondaires à une instance existante (dans le même domaine de disponibilité que la VNIC principale) et les enlever si nécessaire. Chaque VNIC secondaire peut se trouver dans un sous-réseau du même VCN que la VNIC principale, ou dans un sous-réseau différent, soit dans le même VCN, soit dans un autre. Toutefois, elles doivent toutes se trouver dans le même domaine de disponibilité que l'instance. Pour plus d'informations, reportez-vous à Cartes d'interface réseau virtuelles (VNIC). Une adresse IPv6 peut éventuellement être affectée à une carte d'interface réseau virtuelle attachée à une instance Compute et résidant dans un sous-réseau compatible IPv6.
Adresse IP privée
Adresse IPv4 privée et informations associées pour l'adressage d'une instance (par exemple, un nom d'hôte pour DNS). Chaque carte d'interface réseau virtuelle comporte une adresse IP privée principale. Vous pouvez également ajouter et enlever des adresses IP privées secondaires. L'adresse IP privée principale d'une instance ne change pas au cours de la durée de vie de l'instance et ne peut pas être enlevée de celle-ci. Pour plus d'informations, reportez-vous à Adresses IP privées.
Adresse IP publique
Adresse IPv4 publique et informations associées. Vous pouvez éventuellement affecter une adresse IP publique à des instances ou à d'autres ressources disposant d'une adresse IP privée. Les adresses IP publiques peuvent être éphémères ou réservées. Pour plus d'informations, reportez-vous à Adresses IP publiques.
IPv6
Adresse IPv6 et informations associées. L'adressage IPv6 est pris en charge pour toutes les régions commerciales et gouvernementales. Pour plus d'informations, reportez-vous à Adresses IPv6.
Passerelle de routage dynamique
Routeur virtuel facultatif que vous pouvez ajouter à un VCN. Il fournit un chemin pour le trafic réseau privé entre un VCN et un réseau sur site. Vous pouvez l'utiliser avec d'autres composants de réseau et un routeur d'un réseau sur site pour établir une connexion au moyen d'un VPN site à site ou d'Oracle Cloud Infrastructure FastConnect. Il peut également fournir un chemin pour le trafic de réseau privé entre un VCN et un autre VCN dans une autre région. Pour plus d'informations, reportez-vous à Accès à votre réseau sur site, à Passerelles de routage dynamique et à Appairage VCN distant à l'aide d'un DRG hérité.
Passerelle Internet
Un autre routeur virtuel facultatif que vous pouvez ajouter à un VCN pour un accès Internet direct. Pour plus d'informations, reportez-vous à Accès à Internet et à Scénario A : sous-réseau public.
Passerelle NAT (Network Address Translation)
Un autre routeur virtuel facultatif que vous pouvez ajouter à un VCN. Cette passerelle fournit aux ressources cloud sans adresse IP publique un accès à Internet sans exposition aux connexions Internet entrantes. Pour plus d'informations, reportez-vous à Sous-réseaux publics et privés et également à Passerelle NAT.
Passerelle de service
Un autre routeur virtuel facultatif que vous pouvez ajouter à un VCN. Il fournit un chemin pour le trafic réseau privé entre un VCN et des services pris en charge dans Oracle Services Network (exemples : Oracle Cloud Infrastructure Object Storage et Autonomous Database). Par exemple, les systèmes de base de données d'un sous-réseau privé dans un VCN peuvent sauvegarder des données dans Object Storage sans avoir besoin d'adresses IP publiques ni d'un accès à Internet. Pour plus d'informations, reportez-vous à Accès aux services Oracle : passerelle de service.
Passerelle d'appairage local
Un autre routeur virtuel facultatif que vous pouvez ajouter à un VCN. Il permet d'appairer un réseau cloud virtuel avec un autre réseau cloud virtuel situé dans la même région. L'appairage signifie que les réseaux cloud virtuels communiquent à l'aide d'adresses IP privées, sans que le trafic ne passe par Internet ou ne soit routage via un réseau sur site. Un VCN doit avoir une passerelle d'appairage local distincte pour chaque appairage qu'il établit. Pour plus d'informations, reportez-vous à Appairage local de réseaux cloud virtuels à l'aide de passerelles d'appairage local.
Connexion d'appairage à distance
Composant que vous pouvez ajouter à une passerelle de routage dynamique. Il permet d'appairer un réseau cloud virtuel avec un autre réseau cloud virtuel situé dans une autre région. Pour plus d'informations, reportez-vous à la section Appairage à distance de réseaux cloud virtuels à l'aide d'une passerelle de routage dynamique héritée.
Tables de routage
Tables de routage virtuelles pour un VCN. Elles disposent de règles pour acheminer le trafic des sous-réseaux vers des destinations situées en dehors du réseau cloud virtuel au moyen de passerelles ou d'instances spécialement configurées. Un VCN est livré avec une table de routage par défaut vide, et vous pouvez ajouter des tables de routage personnalisées. Pour plus d'informations, reportez-vous à Tables de routage de réseau cloud virtuel.
Règles de sécurité
Règles de pare-feu virtuel pour un VCN. Les règles entrantes et sortantes indiquent les types de trafic (port et protocole) autorisés vers et depuis les instances. Vous pouvez décider si une règle particulière est avec ou sans conservation de statut. Par exemple, vous pouvez autoriser le trafic SSH entrant de n'importe quel emplacement vers un ensemble d'instances en configurant une règle entrante avec conservation de statut dont le CIDR source est 0.0.0.0/0 et le port TCP de destination est 22. Pour implémenter des règles de sécurité, vous pouvez utiliser des groupes de sécurité réseau ou des listes de sécurité. Un groupe de sécurité réseau se compose d'un ensemble de règles de sécurité qui s'appliquent uniquement aux ressources de ce groupe. Les règles d'une liste de sécurité s'appliquent, quant à elles, à toutes les ressources contenues dans n'importe quel sous-réseau utilisant la liste. Un VCN est livré avec une liste de sécurité par défaut avec des règles de sécurité par défaut. Pour plus d'informations, reportez-vous à Règles de sécurité.
Options DHCP
Informations de configuration automatiquement fournies aux instances lors de leur initialisation. Pour plus d'informations, reportez-vous à Options DHCP.
NOTATION CIDR
Méthode compacte permettant de spécifier des adresses IP ou des plages d'adresses et des masques réseau. Par exemple, si vous utilisez IPv4, la plage d'adresses IP privées 10.0.0.0/24 représente toutes les adresses comprises entre 10.0.0.0 et 10.0.0.255. Le /24 représente un masque de sous-réseau de 255.255.255.0 car les 24 premiers bits sont masqués. IPv6 utilise une notation similaire à celle des blocs d'adresses. Pour plus d'informations, reportez-vous à RFC1817 et RFC1519.

Taille de réseau cloud virtuel et plages d'adresses autorisées

Un VCN couvre un ou plusieurs blocs CIDRIPv4 CIDR IPv4 ou préfixes IPv6. La plage autorisée de tailles pour le réseau cloud virtuel est comprise entre /16 et /30. Exemple : 10.0.0.0/16. Le service Networking réserve les deux premières adresses IP et la dernière sur le CIDR de chaque sous-réseau. Vous pouvez activer IPv6 pour les réseaux cloud virtuels lorsque vous les créez. Vous pouvez également activer IPv6 sur les réseaux cloud virtuels uniquement IPv4 existants. Si vous décidez d'utiliser un préfixe IPv6 alloué par Oracle, vous recevez toujours un préfixe de taille /56. Vous pouvez également importer votre propre préfixe IPv6 BYOIP, à partir duquel affecter n'importe quel préfixe de taille /64 ou plus à un réseau cloud virtuel, ou affecter un préfixe ULA de taille /64 ou plus. Les plages GUA peuvent aller jusqu'à 2000::/3 et les plages ULA jusqu'à fc00::/7. La taille des sous-réseaux IPv6 est toujours égale à /64.

Pour un VCN, nous vous recommandons d'utiliser les plages d'adresses IP privées spécifiées dans RFC 1918 (la RFC recommande 10.0/8 ou 172.16/12, mais Oracle ne prend pas en charge ces tailles, utilisez donc 10.0/16, 172.16/16 et 192.168/16). Cependant, vous pouvez utiliser une plage routable publiquement. Quoi qu'il en soit, cette documentation utilise le terme adresse IP privée pour faire référence aux adresses IP dans le CIDR d'un VCN. Les plages d'adresses non autorisées sont décrites dans Adresses IP réservées à une utilisation par Oracle. Pour les réseaux cloud virtuels compatibles IPv6, Oracle peut allouer un préfixe GUA (adresse unicast globale) /56 ou vous pouvez créer un réseau cloud virtuel avec un préfixe BYOIPv6.

Les blocs CIDR du VCN ne doivent pas se chevaucher les uns avec les autres, avec des CIDR dans un réseau sur site connecté ou avec les CIDR d'un autre VCN avec lequel vous appliquez un pair. Les sous-réseaux d'un VCN particulier ne doivent pas se chevaucher. Pour référence, voici un calculateur de CIDR.

L'adressage IPv6 est pris en charge pour toutes les régions commerciales et gouvernementales. Pour plus d'informations, reportez-vous à Adresses IPv6.

Domaines de disponibilité et réseaux cloud virtuels

Un VCN réside dans une seule région Oracle Cloud Infrastructure. Une région peut disposer de plusieurs domaines de disponibilité pour assurer l'isolement et la redondance. Pour plus d'informations, reportez-vous à Régions et domaines de disponibilité.

Les sous-réseaux étaient initialement conçus pour couvrir un seul domaine de disponibilité dans une région. Ils étaient tous propres à un domaine de disponibilité, ce qui signifie que les ressources du sous-réseau devaient résider dans un domaine de disponibilité particulier. Désormais, les sous-réseaux peuvent être propres à un domaine de disponibilité ou régionaux. Vous sélectionnez le type du sous-réseau lors de sa création. Les deux types de sous-réseaux peuvent coexister dans le même VCN. Dans le diagramme suivant, les sous-réseaux 1 à 3 sont propres à un domaine de disponibilité et le sous-réseau 4 est régional.

Cette image présente un réseau cloud virtuel comportant un sous-réseau régional et trois sous-réseaux propres à un domaine de disponibilité.

Outre la suppression de la contrainte liée aux domaines de disponibilité, les sous-réseaux régionaux se comportent de la même façon que les sous-réseaux propres à un domaine de disponibilité. Nous vous recommandons d'utiliser des sous-réseaux régionaux car ils sont plus flexibles. Ils facilitent la division efficace d'un VCN en sous-réseaux tout en concevant pour la panne du domaine de disponibilité.

Lorsque vous créez une ressource telle qu'une instance Compute, vous décidez dans quel domaine de disponibilité elle se trouve. Du point de vue des réseaux virtuels, vous devez également décider dans quel VCN et sous-réseau se trouve l'instance. Vous pouvez sélectionner un sous-réseau régional ou un sous-réseau spécifique d'un domaine de disponibilité qui correspond au domaine de disponibilité que vous avez choisi pour l'instance.

Composants par défaut associés à un VCN

Un VCN est automatiquement fourni avec les composants par défaut suivants :

Vous ne pouvez pas supprimer ces composants par défaut. Vous pouvez cependant modifier leur contenu (par exemple, les règles de la liste de sécurité par défaut). Vous pouvez également créer des versions personnalisées de chaque type de composant dans un VCN. Il existe des limites quant au nombre de règles que vous pouvez créer et au nombre maximal de règles. Pour plus d'informations, reportez-vous à Limites de service.

Chaque sous-réseau est toujours associé aux composants suivants :

  • Une table de routage
  • Des listes de sécurité (pour connaître le nombre maximal, reportez-vous à Limites de service)
  • Un ensemble d'options DHCP

Lors de la création du sous-réseau, vous pouvez décider de la table de routage, de la liste de sécurité et de l'ensemble d'options DHCP qu'il utilise. Si vous n'indiquez aucun composant particulier, le sous-réseau utilise automatiquement le composant par défaut du réseau cloud virtuel. Vous pouvez modifier les composants utilisés par le sous-réseau à tout moment.

Conseil

Les listes de sécurité constituent un moyen de contrôler le trafic entrant et sortant des ressources du réseau cloud virtuel. Vous pouvez également utiliser des groupes de sécurité réseau

Options de connectivité

Vous pouvez déterminer si les sous-réseaux sont publics ou privés, et si les instances obtiennent des adresses IP publiques. Vous pouvez configurer un VCN pour avoir accès à Internet si nécessaire. Vous pouvez également connecter de manière privée un VCN à des services Oracle Cloud Infrastructure publics tels qu'Object Storage, à un réseau sur site ou à un autre VCN.

Sous-réseaux publics et privés

Lorsque vous créez un sous-réseau, il est considéré par défaut comme public, ce qui signifie que les instances de ce sous-réseau sont autorisées à comporter des adresses IPv4 publiques et que la communication Internet avec les adresses IPv6 est autorisée. L'utilisateur qui lance l'instance choisit si elle dispose d'une adresse IPv4 publique ou si une adresse IPv6 doit être affectée à partir du préfixe alloué. Vous pouvez modifier ce comportement lors de la création du sous-réseau et demander à ce que ce dernier soit privé, ce qui empêche l'utilisation d'adresses IPv4 publiques et la communication Internet avec des adresses IPv6. Les administrateurs réseau peuvent ainsi s'assurer que les instances du sous-réseau n'ont pas d'accès à Internet, même si le réseau cloud virtuel dispose d'une passerelle Internet opérationnelle, et que des règles de sécurité et de pare-feu autorisent le trafic.

Mode d'affectation des adresses IP

Chaque instance dispose d'une carte d'interface réseau virtuelle principale créée lors du lancement de l'instance et ne pouvant pas être enlevée. Vous pouvez ajouter des cartes d'interface réseau virtuelles secondaires à une instance existante (dans le même domaine de disponibilité que la carte d'interface réseau virtuelle principale) et les enlever à votre convenance.

Chaque carte d'interface réseau virtuelle possède une adresse IP privée fournie par le CIDR du sous-réseau associé. Vous pouvez choisir une adresse IP particulière (lors du lancement de l'instance ou de la création de la carte d'interface réseau virtuelle secondaire) ou laisser Oracle choisir pour vous. L'adresse IP privée ne change pas au cours de la durée de vie de l'instance et ne peut pas être enlevée. Vous pouvez également ajouter des adresses IPv4 privées secondaires ou des adresses IPv6 secondaires à une carte d'interface réseau virtuelle.

Si la carte d'interface réseau virtuelle se trouve dans un sous-réseau public, vous pouvez affecter à votre convenance une adresse IPv4 ou IPv6 publique à chaque adresse IP privée de cette carte d'interface réseau virtuelle. Pour IPv4, Oracle choisit l'adresse IP particulière. Pour IPv6, vous pouvez spécifier l'adresse IP. Il existe deux types d'adresse IP publique : éphémère et réservée. Une adresse IP publique éphémère n'existe que pour la durée de vie de l'adresse IP privée à laquelle elle est affectée. Une adresse IP publique réservée, quant à elle, existe aussi longtemps que vous voulez. Vous pouvez gérer un pool d'adresses IP publiques réservées et les allouer à vos instances à votre convenance. Vous pouvez les déplacer d'une ressource à une autre dans une région selon vos besoins.

Accès à Internet

Il existe deux passerelles facultatives (routeurs virtuels) que vous pouvez ajouter à votre réseau cloud virtuel en fonction du type d'accès Internet dont vous avez besoin :

  • Passerelle Internet : pour les ressources avec des adresses IP publiques qui doivent être atteintes à partir d'Internet (par exemple, un serveur Web) ou qui doivent initier des connexions à Internet.
  • Passerelle NAT : pour les ressources sans adresse IP publique qui doivent initier des connexions à Internet (par exemple, pour les mises à jour logicielles), mais qui doivent être protégées des connexions entrantes en provenance d'Internet.

Le simple fait d'avoir une passerelle Internet n'expose pas les instances des sous-réseaux de votre réseau cloud virtuel directement sur Internet. Les conditions suivantes doivent également être remplies :

Conseil

Pour accéder à des services publics tels qu'Object Storage à partir de votre VCN sans que le trafic ne passe par Internet, utilisez une passerelle de service.

Notez également que le trafic via une passerelle Internet entre un VCN et une adresse IP publique faisant partie d'Oracle Cloud Infrastructure (telle qu'Object Storage) est acheminé sans être envoyé sur Internet.

Vous pouvez également donner à un sous-réseau un accès indirect à Internet en configurant un proxy Internet dans votre réseau sur site, puis en connectant ce réseau à votre réseau cloud virtuel à l'aide d'une passerelle de routage dynamique. Pour plus d'informations, reportez-vous à Accès au réseau sur site.

Accès aux services Oracle Cloud Infrastructure publics

Vous pouvez utiliser une passerelle de service avec votre VCN pour activer l'accès privé aux services Oracle Cloud Infrastructure publics tels qu'Object Storage. Par exemple, les systèmes de base de données d'un sous-réseau privé de votre VCN peuvent sauvegarder des données dans Object Storage sans avoir besoin d'adresses IP publiques ni d'un accès à Internet. Aucune passerelle Internet ou NAT n'est requise. Pour plus d'informations, reportez-vous à Accès aux services Oracle : passerelle de service.

Accès au réseau sur site

Vous pouvez connecter votre réseau sur site à Oracle Cloud Infrastructure de deux manières :

  • VPN site à site : offre plusieurs tunnels IPSec entre la périphérie de votre réseau existant et votre VCN, par le biais d'un DRG que vous créez et attachez à votre VCN.
  • Oracle Cloud Infrastructure FastConnect : offre une connexion privée entre la périphérie de votre réseau existant et Oracle Cloud Infrastructure. Le trafic ne passe pas par Internet. L'appairage privé et l'appairage public sont tous deux pris en charge. Cela signifie que vos hôtes sur site peuvent accéder à des adresses IPv4 ou IPv6 privées dans votre VCN ainsi qu'à des adresses IPv4 ou IPv6 publiques régionales dans Oracle Cloud Infrastructure (par exemple, Object Storage ou des équilibreurs de charge publics dans votre VCN).

Vous pouvez utiliser les deux types de connexion ci-avant, ou un seul. Si vous employez les deux, vous pouvez les utiliser simultanément ou dans une configuration redondante. Ces connexions sont transmises à votre réseau cloud virtuel via une passerelle de routage dynamique unique que vous créez et attachez à votre réseau cloud virtuel. Sans l'attachement de la passerelle de routage dynamique et sans règle de routage pour cette dernière, le trafic ne circule pas entre votre réseau cloud virtuel et votre réseau sur site. A tout moment, vous pouvez détacher la passerelle de routage dynamique de votre réseau cloud virtuel, tout en conservant l'ensemble des autres composants qui constituent le reste de la connexion. Vous pouvez ensuite attacher de nouveau la passerelle de routage dynamique, ou l'attacher à un autre réseau cloud virtuel.

Accès à un autre réseau cloud virtuel

Vous pouvez connecter votre réseau cloud virtuel à un autre réseau cloud virtuel à l'aide d'une connexion privée qui n'exige pas que le trafic passe par Internet. En général, ce type de connexion est appelé appairage de réseaux cloud virtuels. Chaque réseau cloud virtuel doit disposer de composants spécifiques pour permettre l'appairage. Ils doivent également comporter des stratégies IAM, des règles de routage et des règles de sécurité spécifiques permettant d'établir la connexion et de faire circuler le trafic réseau voulu sur celle-ci. Pour plus d'informations, reportez-vous à Accès à d'autres réseaux cloud virtuels : appairage.

Connexion à Microsoft Azure

Oracle et Microsoft ont créé une connexion entre le 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. Pour plus d'informations, reportez-vous à Interconnexion pour Azure.

Connexion à d'autres clouds avec Libreswan

Vous pouvez connecter votre VCN à un autre fournisseur cloud à l'aide d'un VPN site à site avec une machine virtuelle Libreswan en tant que CPE (Customer-Premise Equipment). Pour plus d'informations, reportez-vous à Accès à d'autres clouds avec Libreswan.

Scénarios de configuration réseau

Cette documentation inclut quelques scénarios de réseau de base pour vous aider à comprendre le service Networking et la façon dont les composants fonctionnent ensemble en général. Reportez-vous aux rubriques suivantes :

Routage de transit

Les scénarios A à C affichent un réseau sur site connecté à des réseaux cloud virtuels via un DRG et FastConnect ou un VPN site à site, et accédant uniquement aux ressources de ces réseaux cloud virtuels.

Les scénarios de routage avancés suivants donnent un accès réseau sur site au-delà des ressources du VCN connecté. Le trafic circule d'un réseau sur site vers le DRG, puis transite le DRG vers sa destination. Reportez-vous aux rubriques suivantes :

  • Routage de transit dans un VCN hub : un réseau sur site a accès à plusieurs réseaux cloud virtuels de la même région sur un seul circuit virtuel privé FastConnect ou VPN site à site. La passerelle de routage dynamique et les réseaux cloud virtuels attachés sont dans une topologie hub-and-spoke, où le réseau sur site est connecté à la passerelle de routage dynamique qui agit comme un hub. Les réseaux cloud virtuels spoke sont appairés.
  • Accès privé aux services Oracle : un réseau sur site dispose d'un accès privé aux services Oracle dans Oracle Services Network au moyen d'un VCN connecté et de la passerelle de service du VCN. Le trafic ne passe pas par Internet.

Régions et domaines de disponibilité

Un VCN réside dans une seule région Oracle Cloud Infrastructure. Chaque sous-réseau réside dans un seul domaine de disponibilité. Les domaines de disponibilité sont conçus pour assurer l'isolation et la redondance dans le VCN, comme illustré dans le scénario B et le scénario C mentionnés précédemment. Par exemple, vous pouvez configurer un ensemble principal de sous-réseaux dans un seul AD, puis configurer un ensemble de sous-réseaux dupliqué dans un AD secondaire. Les deux domaines de disponibilité sont isolés l'un de l'autre au sein des centres de données Oracle, de sorte que si l'un tombe en panne, vous pouvez facilement basculer vers l'autre. Pour plus d'informations, reportez-vous à Regions and Availability Domains.

Plages d'adresses IP publiques

Pour obtenir la liste des plages d'adresses IP publiques Oracle Cloud Infrastructure, reportez-vous à Plages d'adresses IP.

Adresses IP réservées à une utilisation par Oracle

Certaines adresses IP sont réservées à Oracle Cloud Infrastructure et ne peuvent pas être utilisées dans un modèle de numérotation des adresses.

169.254.0.0/16

Ces adresses sont utilisées pour les connexions iSCSI aux volumes d'initialisation et de blocs, aux métadonnées d'instance et aux autres services.

Classe D et classe E

Toutes les adresses de 224.0.0.0 à 239.255.255.255 (classe D) sont interdites pour une utilisation dans un VCN, elles sont réservées aux assignations d'adresses multicast dans les normes IP. Pour plus d'informations, reportez-vous à la norme RFC 3171.

Toutes les adresses de 240.0.0.0 à 255.255.255.255 (classe E) sont interdites pour une utilisation dans un VCN, elles sont réservées pour une utilisation future dans les normes IP. Pour plus d'informations, reportez-vous à la norme RFC 1112, Section 4.

Trois adresses IP dans chaque sous-réseau

Ces adresses représentent :

  • la première adresse IP dans le CIDR (adresse réseau),
  • la dernière adresse IP dans le CIDR (adresse de diffusion),
  • la première adresse d'hôte dans le CIDR (adresse de passerelle par défaut du sous-réseau).

Par exemple, dans un sous-réseau avec le CIDR 192.168.0.0/24, les adresses suivantes sont réservées :

  • 192.168.0.0 (adresse réseau)
  • 192.168.0.255 (adresse de diffusion)
  • 192.168.0.1 (adresse de passerelle par défaut du sous-réseau)

Les autres adresses du CIDR (192.168.0.2 à 192.168.0.254) sont disponibles.

Création d'une automatisation avec des événements

Vous pouvez créer l'automatisation en fonction des modifications d'état apportées aux ressources Oracle Cloud Infrastructure à l'aide de types d'événement, de règles et d'actions. Pour plus d'informations, reportez-vous à Présentation d'Events.

Identificateurs de ressource

La plupart des types de ressource Oracle Cloud Infrastructure possèdent un identificateur unique affecté par Oracle appelé ID Oracle Cloud (OCID). Pour plus d'informations sur le format OCID et d'autres façons d'identifier vos ressources, reportez-vous à Identificateurs de ressource.

Méthodes d'accès à Oracle Cloud Infrastructure

Vous pouvez accéder à Oracle Cloud Infrastructure (OCI) à l'aide de la console (interface Web), de l'API REST ou de l'interface de ligne de commande OCI. Les instructions d'utilisation de la console, de l'API et de l'interface de ligne de commande sont incluses dans les rubriques de cette documentation. Pour obtenir la liste des kits SDK disponibles, reportez-vous à Kits Software Development et interface de ligne de commande.

Pour accéder à la console, vous devez utiliser un navigateur pris en charge. Pour accéder à la page de connexion à la console, ouvrez le menu de navigation en haut de cette page et sélectionnez Console Infrastructure. Vous êtes invité à saisir votre locataire cloud, votre nom utilisateur et votre mot de passe.

Pour obtenir des informations générales sur l'utilisation de l'API, reportez-vous à API REST.

Authentification et autorisation

Chaque service d'Oracle Cloud Infrastructure s'intègre à IAM à des fins d'authentification et d'autorisation pour toutes les interfaces (console, kit SDK ou interface de ligne de commande et API REST).

Un administrateur d'une organisation doit configurer des groupes , des compartiments et des stratégies qui déterminent quels utilisateurs peuvent accéder à ces services, à ces ressources et au type d'accès. Par exemple, les stratégies déterminent qui peut créer des utilisateurs, créer et gérer le réseau cloud, créer des instances, créer des buckets, télécharger des objets, etc. Pour plus d'informations, reportez-vous à Gestion des domaines d'identité. Afin d'obtenir des détails spécifiques sur l'élaboration de stratégies pour chacun des différents services, reportez-vous à Référence de stratégie.

Si vous êtes un utilisateur standard (pas un administrateur) et que vous avez besoin des ressources Oracle Cloud Infrastructure de l'entreprise, demandez à un administrateur de configurer pour vous un ID utilisateur. L'administrateur peut confirmer les compartiments que vous pouvez utiliser.

Stratégies IAM pour Networking

La méthode la plus simple pour accorder l'accès à Networking est d'utiliser la stratégie répertoriée dans Autoriser les administrateurs réseau à gérer un réseau cloud. Elle couvre le réseau cloud et tous les autres composants Networking (sous-réseaux, listes de sécurité, tables de routage, passerelles, etc.). Pour permettre aux administrateurs réseau de créer des instances (afin de tester la connectivité réseau), reportez-vous à Autoriser les utilisateurs à lancer des instances de calcul.

Si vous ne connaissez pas les stratégies, reportez-vous à Gestion des domaines d'identité et à Stratégies courantes.

Afin d'obtenir des documents de référence sur l'écriture de stratégies plus détaillées pour Networking, reportez-vous à Détails des services de base.

Types de ressource individuelle

Vous pouvez écrire des stratégies qui se concentrent sur des types de ressource individuelle (par exemple, uniquement les listes de sécurité) au lieu du type virtual-network-family plus large. Le type de ressource instance-family inclut également plusieurs droits pour les cartes d'interface réseau virtuelles, qui résident dans un sous-réseau mais qui sont attachées à une instance. Pour plus d'informations, reportez-vous à Détails des combinaisons de verbe et de type de ressource et à Cartes d'interface réseau virtuelles (VNIC).

Un type de ressource appelé local-peering-gateways est inclus dans virtual-network-family et inclut deux autres types de ressource liés à l'appairage VCN local (dans la région) :

  • local-peering-from
  • local-peering-to

Le type de ressource local-peering-gateways couvre tous les droits d'accès relatifs aux passerelles d'appairage local. Les types de ressource local-peering-from et local-peering-to permettent d'accorder le droit de connexion à deux passerelles d'appairage local et de définir une relation d'appairage au sein d'une seule région. Pour plus d'informations, reportez-vous à Appairage local à l'aide d'une passerelle d'appairage local (réseaux cloud virtuels dans la même location) ou à Appairage local à l'aide d'une passerelle d'appairage local (réseaux cloud virtuels dans différentes locations).

De même, un type de ressource appelé remote-peering-connections est inclus dans virtual-network-family et inclut deux autres types de ressource liés à l'appairage VCN distant (entre les régions) :

  • remote-peering-from
  • remote-peering-to

Le type de ressource remote-peering-connections couvre tous les droits d'accès relatifs aux connexions d'appairage à distance. Les types de ressource remote-peering-from et remote-peering-to permettent d'accorder le droit de connecter deux RPC et de définir une relation d'appairage entre des régions. Pour plus d'informations, reportez-vous à Appairage à distance avec un DRG hérité et à Appairage à distance avec un DRG mis à niveau.

Nuances des différents verbes

Vous pouvez écrire des stratégies qui limitent le niveau d'accès en utilisant un verbe de stratégie différent (manage au lieu de use, etc.). Si vous le faites, voici quelques nuances à comprendre sur les verbes de stratégie pour Networking.

Gardez à l'esprit que le verbe inspect ne renvoie pas uniquement des informations générales sur les composants du réseau cloud (par exemple, le nom et l'OCID d'une liste de sécurité ou d'une table de routage). Il inclut également le contenu du composant (par exemple, les règles réelles dans la liste de sécurité, les routages de la table de routage, etc.).

En outre, les types de fonction suivants sont disponibles uniquement avec le verbe manage, et non avec le verbe use :

  • Mettre à jour (activer/désactiver) internet-gateways
  • Mettre à jour security-lists
  • Mettre à jour route-tables
  • Mettre à jour dhcp-options
  • Attachement d'une passerelle de routage dynamique (DRG) à un réseau cloud virtuel (VCN)
  • Créer une connexion IPSec entre une passerelle de routage dynamique et un CPE (Customer-Premises Equipment)
  • Appairer des réseaux cloud virtuels
Important

Chaque réseau cloud virtuel dispose de divers composants qui affectent directement le comportement du réseau (tables de routage, listes de sécurité, options DHCP, passerelle Internet, etc.). Lorsque vous créez l'un de ces composants, vous établissez une relation entre ce composant et le réseau cloud virtuel, ce qui signifie qu'une stratégie doit vous autoriser à créer le composant et à gérer le réseau cloud virtuel. Cependant, la possibilité de mettre à jour ce composant (pour modifier les règles de routage, les règles de liste de sécurité, etc.) n'exige pas l'autorisation de gérer le VCN lui-même, même si la modification de ce composant peut affecter directement le comportement du réseau. Cette divergence est conçue pour vous donner la flexibilité d'accorder le moindre privilège aux utilisateurs, et ne vous oblige pas à accorder un accès excessif au VCN afin que l'utilisateur puisse gérer d'autres composants du réseau. Gardez à l'esprit qu'en donnant à un utilisateur la possibilité de mettre à jour un type de composant particulier, vous lui faites implicitement confiance en ce qui concerne le contrôle du comportement du réseau.

Pour plus d'informations sur les verbes de stratégie, reportez-vous à Notions de base relatives aux stratégies.

Stratégies d'appairage

Pour connaître les stratégies utilisées lors de la connexion d'un DRG aux réseaux cloud virtuels et aux passerelles de routage dynamique dans d'autres régions et locations, reportez-vous à Stratégies IAM pour le routage entre les réseaux cloud virtuels.

Limites relatives aux composants de mise en réseau

Reportez-vous aux limites de service pour obtenir la liste des limites applicables et des instructions de demande d'augmentation de limite.