Pour obtenir une liste complète des composantes, consultez la présentation des solutions relatives au réseau.

• Pour un bref tutoriel sur la façon de lancer une instance dans un réseau en nuage virtuel dans Oracle Cloud Infrastructure, consultez le guide de démarrage.

Consultez également les sujets suivants :

• Présentation des solutions relatives au réseau
• Réseaux en nuage virtuels et sous-réseaux

Lorsque vous créez votre réseau en nuage virtuel, vous attribuez un bloc de CIDR IPv4 contigu de votre choix. Les tailles de réseau en nuage virtuel allant de /16 (65 533 adresses IP) à /30 (1 adresse IP) sont permises. Exemple : 10.0.0.0/16, 192.168.0.0/24.

Nous recommandons d’utiliser un bloc CIDR à partir des plages d’adresses privées spécifiées par RFC1918. Si vous utilisez un bloc CIDR non conforme à RFC1918, notez qu’il est toujours traité comme une plage d’adresses IP privées et qu’il n’est pas acheminable à partir d’Internet par l’intermédiaire de la passerelle Internet d’Oracle.

Vous créez des sous-réseaux en subdivisant la plage d’adresses du réseau en nuage virtuel en blocs CIDR IPv4 contigus. Le bloc CIDR d’un sous-réseau doit se trouver dans le bloc CIDR du réseau en nuage virtuel. Lorsque vous lancez une instance dans un sous-réseau, l’adresse IP privée de l’instance est attribuée à partir du bloc CIDR du sous-réseau.

Oui. Lorsque vous créez un sous-réseau, vous pouvez préciser son type d’accès : privé ou public. Un sous-réseau est créé par défaut avec un accès public, auquel cas les instances du sous-réseau peuvent recevoir une adresse IP publique. Les instances lancées dans un sous-réseau avec accès privé ne peuvent pas avoir des adresses IP publiques, ce qui permet de s’assurer que ces instances n’ont pas d’accès direct à Internet.

Oui.

Les sous-réseaux peuvent couvrir plusieurs domaines de disponibilité, mais pas plusieurs réseaux en nuage virtuels. Si vous créez un sous-réseau régional, les ressources du sous-réseau peuvent résider dans n’importe quel domaine de disponibilité (AD) de la région. Toutefois, si vous créez un sous-réseau propre au domaine de disponibilité, les ressources du sous-réseau doivent résider dans le domaine de disponibilité particulier du sous-réseau.

Oui. Cependant, si vous avez l’intention de connecter un réseau en nuage virtuel à votre réseau sur place ou à un autre réseau en nuage virtuel, nous vous recommandons de vous assurer que les plages d’adresses IP ne se chevauchent pas.

Pour connaître les limites actuelles de tous les services et les directives pour demander une augmentation de limite de service, consultez la documentation d’aide sur les limites de service.

Oui. Vous pouvez modifier le nom du sous-réseau et changer la table de routage, les listes de sécurité et l’ensemble d’options DHCP qui y sont associées. Cependant, vous ne pouvez pas modifier le bloc CIDR du sous-réseau.

Les serveurs des centres de données d’Oracle Cloud Infrastructure sont dotés de cartes d’interface réseau physiques (NIC). Lorsque vous lancez une instance sur l’un de ces serveurs, l’instance communique à l’aide des cartes d’interface réseau virtuelles (VNIC) associées aux cartes réseau physiques. Une carte VNIC permet de connecter une instance de calcul à un réseau en nuage virtuel et détermine la façon dont l’instance communique avec des points d’extrémité à l’intérieur et à l’extérieur du réseau virtuel.

Chaque carte VNIC est située dans un sous-réseau et possède la configuration suivante :

• Une adresse IPv4 privée principale du sous-réseau dans lequel la carte VNIC se trouve, attribuée par vous ou par Oracle
• Jusqu’à 31 adresses privées IPv4 secondaires du sous-réseau dans lequel la carte VNIC se trouve, attribuée par vous ou par Oracle
• Adresse IPv4 publique facultative pour chaque adresse IP privée
• Nom d’hôte facultatif de DNS pour chaque adresse IP privée (voir la documentation à propos du DNS dans votre réseau en nuage virtuel)
• Adresse MAC
• Étiquette VLAN affectée par Oracle et disponible lorsque l’association de la carte VNIC à l’instance est terminée (pertinente uniquement pour les instances sans système d’exploitation)

Pour en savoir plus, consultez la documentation sur les cartes d’interface réseau virtuel (VNIC).

Chaque instance de votre réseau en nuage virtuel est créée avec une VNIC, qui possède une adresse IP privée (attribuée par vous ou par Oracle) dans le sous-réseau, fournie lors de la création de l’instance, ainsi qu’une adresse IP publique correspondante. Cette carte réseau est appelée la carte VNIC principale, et son adresse IP privée est l’adresse IP privée principale.

La carte VNIC principale ne peut pas être dissociée de l’instance. Elle est automatiquement supprimée lorsqu’on met fin à l’instance.

Chaque instance de votre réseau en nuage virtuel comporte au moins une carte réseau, qui est son réseau VNIC principale. Vous pouvez associer des cartes VNIC supplémentaires, appelées cartes VNIC secondaires, à une instance. Les cartes VNIC secondaires peuvent appartenir à différents réseaux en nuage virtuels ou sous-réseaux.

La limite quant au nombre d’associations de cartes VNIC à une instance varie selon la forme. Pour ces limites, voir la documentation de soutien pour les formes de calcul.

Oui. Faites une requête sur le service de métadonnées d’instance disponible à l’adresse http://169.254.169.254/opc/v1/vnics/.

Oui. Dans le cas de la carte VNIC principale, vous pouvez spécifier l’adresse IP privée au lancement de l’instance. Dans le cas des cartes VNIC secondaires, vous pouvez spécifier une adresse IP privée lorsque vous associez la carte VNIC à une instance. L’adresse IP privée spécifiée doit appartenir au même sous-réseau associé à la carte VNIC et ne doit pas être utilisée.

Non. Actuellement, les cartes VNCI sont toujours liées à l’instance et n’existent pas de façon indépendante. La carte VNIC principale est créée et détruite avec l’instance. Toutes les cartes VNIC secondaires sont créées et détruites lorsqu’elles sont associées et dissociées respectivement.

Oui. Cependant, le fait d’associer plusieurs cartes VNIC du même bloc CIDR de sous-réseau à une instance peut introduire un routage asymétrique, particulièrement dans les cas utilisant une variante de Linux. Si vous avez besoin de ce type de configuration, Oracle recommande d’attribuer plusieurs adresses IP privées à une carte VNIC ou d’utiliser un routage basé sur les politiques. Par exemple, consultez le script sous Linux : Configuration du système d’exploitation pour les cartes VNIC secondaires.

Non. Toutes les cartes VNIC doivent appartenir à des sous-réseaux dotés du même domaine de disponibilité que l’instance. Lors de l’utilisation de sous-réseaux régionaux, les cartes VNIC doivent être créées dans le même domaine de disponibilité que l’instance.

Oui. Vous pouvez associer des cartes VNIC secondaires qui appartiennent à un sous-réseau d’un réseau en nuage virtuel différent de celui de la carte principale.

Chaque instance de calcul de votre réseau un nuage virtuel est créée avec une carte d’interface réseau virtuelle (VNIC), et une adresse IP privée dans le sous-réseau est fournie lors du lancement de l’instance. Il s’agit d’une carte VNIC principale, et de son adresse IP privée principale, respectivement. Vous pouvez également joindre des VNIC supplémentaires à une instance, appelées VNIC secondaires. Ces dernières possèdent aussi une adresse IP privée principale.

Vous pouvez laisser Oracle choisir l’adresse IP privée ou vous pouvez la choisir dans le groupe d’adresses disponibles du sous-réseau. Si l’adresse que vous spécifiez est déjà utilisée, la demande de lancement échouera.

De plus, vous pouvez attribuer des adresses IP privées secondaires à une carte VNIC. De façon similaire aux adresses IP privées principales, une adresse IP privée secondaire offre une connectivité à des destinations au sein de votre réseau en nuage virtuel ou sur place (lorsqu’il y a une connectivité par l’intermédiaire de votre réseau privé virtuel ou d’Oracle Cloud Infrastructure FastConnect).

Oui. Vous pouvez déplacer une adresse IP privée secondaire d’une carte VNIC d’une instance vers une autre carte, à condition que les cartes appartiennent au même sous-réseau et que l’opération soit autorisée. Lors de l’utilisation de sous-réseaux régionaux, l’adresse IP privée secondaire peut également être déplacée vers une carte VNIC d’un autre domaine de disponibilité.

Actuellement, vous pouvez affecter jusqu’à 31 adresses IP privées secondaires à une carte VNIC.

Non. Le système d’exploitation ne peut pas détecter l’adresse IP privée secondaire au moyen de mécanismes tels DHCP. Vous devez configurer les adresses IP privées secondaires au moyen d’une procédure spécifique au système d’exploitation. Pour en savoir plus, consultez les scripts fournis dans Virtual Network interface Cards (VNIC).

Une adresse IP publique est une adresse IPv4 qu’on peut atteindre par Internet (une adresse IP routable sur Internet). Une instance de votre réseau en nuage virtuel communique avec les hôtes sur Internet par l’intermédiaire d’une adresse IP publique. Une adresse IP privée n’est pas routable sur Internet. Les instances à l’intérieur du réseau en nuage virtuel communiquent entre elles en utilisant des adresses IP privées.

Vous pouvez attribuer une adresse IP publique à une adresse IP privée pour une instance de calcul, ou pour une instance d’équilibreur de charge, afin de permettre de communiquer sur Internet. Pour qu’une adresse IP publique puisse être atteignable par Internet, le réseau en nuage virtuel associé doit avoir une passerelle Internet, et le sous-réseau public doit avoir des tables de routage et des listes de sécurité configurées en conséquence.

Il existe deux types d’adresses IP publiques :

• Adresses IP publiques éphémères : Considérez-les comme temporaires et existants pour la durée de vie de l’instance. À votre demande, Oracle en affectera une à partir du groupe d’adresses IP publiques d’Oracle. Cette adresse IP publique est liée au cycle de vie de l’adresse IP privée. Si vous annulez l’affectation d’adresse IP publique explicitement, annulez l’affectation de l’adresse IP privée de la carte VNIC ou mettez fin à l’instance correspondante, cette adresse IP publique sera retournée au groupe d’adresses disponibles. Par la suite, si vous demandez de nouveau d’attribuer une adresse IP publique, il se peut que cette adresse soit différente de celle d’avant.
• Adresses IP publiques réservées : Considérez-les comme des adresses IP publiques mobiles qui se trouvent dans un compartiment de votre choix. Elles sont persistantes et existent au-delà de la durée de vie des instances qui leur sont associées. Elles appartiennent à une région en particulier. Vous pouvez attribuer une adresse IP publique réservée dans votre compartiment ou l’attribuer à une adresse IP privée pour une instance ou un équilibreur de charge dans la même région où elle a été créée. Vous pouvez également la déplacer vers une autre adresse IP privée dans la même région.

Pour plus de détails et un tableau comparant les deux types, consultez la documentation d’aide sur les adresses IP publiques.

Une adresse IP publique devient l’identité de votre service pour les clients qui ne peuvent pas utiliser DNS FQDN. Une adresse IP publique réservée vous permet de conserver cette identité, peu importe les changements apportés aux ressources sous-jacentes. Voici quelques scénarios particuliers qui peuvent tirer profit de l’utilisation d’une adresse IP publique réservée :

• Isoler vos clients de toute défaillance propre à l’instance : Vous pouvez attribuer une adresse IP publique réservée à votre instance et la déplacer facilement vers une autre instance en cas de défaillance. Vos clients sont isolés de ce changement alors qu’ils continuent de se connecter à la même adresse IP publique.
• Optimiser l’utilisation des ressources informatiques sans aucune incidence sur les utilisateurs : Que vous vouliez changer la taille d’une instance ou mettre fin à vos instances en fonction des tendances d’utilisation pour économiser des coûts, une adresse IP publique réservée vous permet d’exposer la même adresse IP publique à vos clients.

Vous pouvez attribuer une seule adresse IP publique réservée à une adresse IP privée (principale ou secondaire). Cependant, vous pouvez affecter plusieurs adresses IP privées à chaque carte VNIC connectée à votre instance. Vous pouvez ensuite attribuer une adresse IP publique réservée à chacune de ces adresses IP privées.

Il y a une limite au nombre maximal d’adresses IP publiques réservées que vous pouvez créer dans votre location. Voir la documentation d’aide sur les limites de service.

Vous pouvez affecter une seule adresse IP publique éphémère à toute adresse IP privée principale de la carte VNIC. Toutefois, vous pouvez créer et joindre plusieurs cartes VNIC à votre instance. Vous pouvez ensuite attribuer une adresse IP privée éphémère à chacune des adresses IP principales de chaque carte VNIC.

Il y a une limite au nombre maximal d’adresses IP publiques éphémères qui peuvent être attribuées à une instance. Voir la documentation d’aide sur les limites de service.

Oui, mais seulement si elle est affectée à une adresse IP privée secondaire sur une carte VNIC. Si vous déplacez cette IP privée secondaire vers une autre carte VNIC (qui doit être dans le même sous-réseau), l’IP publique éphémère l’accompagne.

Oui, et vous pouvez la déplacer d’un domaine de disponibilité ou d’un réseau en nuage virtuel à un autre. Les réseaux en nuage virtuels doivent se trouver dans la même région.

Il y a deux façons de déplacer une adresse IP publique réservée :

• Dissocier l’adresse IP publique réservée, puis la réaffecter à une autre adresse IP privée. L’adresse IP privée peut être activée sur une carte VNIC dans un domaine de disponibilité ou dans un réseau en nuage virtuel différent de celui de la carte VNIC d’origine.
• Si l’adresse IP publique réservée est affectée à une IP privée secondaire, vous pouvez déplacer l’adresse IP privée vers une autre carte VNIC (qui doit être dans le même sous-réseau), et l’adresse IP publique réservée l’accompagne.

Lorsque vous l’attribuez explicitement. Et dans les circonstances suivantes :

• Lorsque vous supprimez une adresse IP privée, son adresse IP publique éphémère correspondante est libérée.
• Lorsque vous dissociez une carte VNIC secondaire, toutes les adresses IP publiques éphémères correspondantes sont libérées.
• Lorsque vous mettez fin à l’instance, les adresses IP éphémères correspondantes sont libérées.

Notez que lorsque vous redémarrez l’instance, cela n’a aucune incidence sur les adresses IP publiques éphémères correspondantes.

Vous ne voyez que l’adresse IP privée de votre instance de calcul. Si une adresse IP publique est attribuée à l’instance, le service de réseau fournit une traduction d’adresse réseau biunivoque (NAT statique) entre les adresses IP privées et publiques lorsque l’instance tente de communiquer avec une destination sur Internet (par l’intermédiaire de la passerelle Internet).

Au niveau du système d’exploitation de l’instance, vous ne voyez que l’adresse IP privée de la carte VNIC associée à l’instance. Lorsque le trafic transmis à l’adresse IP publique est reçu, le service de réseau effectue une traduction d’adresse réseau (NAT) de l’adresse IP publique, vers l’adresse IP privée correspondante. Le trafic se présente à l’intérieur de votre instance, et l’adresse IP de destination est réglée à l’adresse IP privée.

Non. C’est le service de réseau affecte l’adresse MAC.

L’adressage IPv6 n’est actuellement pris en charge que dans le nuage gouvernemental. Pour plus d’informations, voir la documentation à propos des adresses IPv6.

Non, pas actuellement.

Non, pas actuellement.

Les instances peuvent se connecter à ce qui suit :

• Internet (par une passerelle Internet)
• Votre centre de données sur place utilisant une connexion de réseau privé virtuelle IPSec ou FastConnect (par une passerelle de routage dynamique)
• Les instances des réseaux en nuage virtuels appairées (dans la même région ou une autre région)
• Oracle Cloud Infrastructure, comme le stockage d’objets, ADW (par l’intermédiaire d’une passerelle de service)

Une passerelle Internet est un routeur défini par logiciel, hautement disponible et tolérant aux pannes qui offre une connectivité Internet publique pour les ressources à l’intérieur de votre réseau en nuage virtuel. À l’aide d’une passerelle Internet, une instance informatique, avec l’adresse IP publique qui lui est attribuée, peut communiquer avec les hôtes et les services sur Internet.

Au lieu d’utiliser une passerelle Internet, vous pouvez connecter votre réseau en nuage virtuel à votre centre de données sur place, à partir duquel vous pouvez acheminer le trafic vers Internet par l’intermédiaire de vos points réseau sortants existants.

Une passerelle NAT est un routeur fiable et très disponible qui offre une connectivité Internet pour les ressources à l’intérieur de votre réseau en nuage virtuel. Avec une passerelle NAT, les instances privées (avec seulement une adresse IP privée) peuvent établir des connexions aux hôtes et aux services sur Internet, mais ne reçoivent pas de connexions entrantes provenant d’Internet.

Non. La limite par défaut est d’une passerelle NAT par réseau en nuage virtuel. Nous anticipons que cela soit suffisant pour la grande majorité des applications.

Si vous souhaitez affecter plus d’une passerelle NAT dans un réseau en nuage virtuel particulier, demandez une augmentation de limite. Pour savoir comment demander une augmentation des limites, voir la documentation sur les limites de service.

Les instances obtiennent le même débit avec la passerelle NAT que lorsqu’elles sont acheminées par une passerelle Internet. De plus, un seul flux de trafic à travers la passerelle NAT est limité à 1 Gbit/s (ou moins pour les formes destinées aux petites instances).

Oui. Il y a une limite d’environ 20 000 connexions simultanées à une adresse IP et à un port de destination uniques. Cette limite est la somme de toutes les connexions initiées par les instances de réseau en nuage virtuel qui utilisent la passerelle NAT.

Une passerelle de routage dynamique est un routeur défini par logiciel, hautement disponible et tolérant aux défaillances que vous pouvez ajouter à un réseau en nuage virtuel. Elle offre un chemin privé pour le trafic entre le réseau en nuage virtuel et d’autres réseaux à l’extérieur de la région du réseau en nuage virtuel, comme votre centre de données sur place ou un réseau en nuage virtuel appairé dans une autre région. Pour connecter votre réseau en nuage virtuel à votre centre de données sur place, vous pouvez configurer un réseau privé virtuel IPSec ou FastConnect à la passerelle de routage dynamique du réseau en nuage virtuel. La connexion permet à vos hôtes sur place et à vos instances de communiquer en toute sécurité.

Vous utilisez cet objet si vous configurez un réseau privé virtuel IPSec. Il s’agit d’une représentation virtuelle du routeur qui se trouve sur place, à votre établissement, à la fin du réseau privé virtuel. Lorsque vous créez cet objet dans le cadre de la configuration d’un réseau privé virtuel IPSec, vous spécifiez l’adresse IP publique de votre routeur sur place.

Non. Vous n’avez qu’à provisionner une passerelle de routage dynamique, l’attacher à votre réseau en nuage virtuel, configurer l’objet d’équipement de client sur place et la connexion IPSec, et configurer les tables de routage.

Consultez la liste des configurations de dispositifs testés.

Oui. Si vous utilisez les informations de configuration génériques d’équipement de client sur place. Nous prenons en charge plusieurs options de configuration afin de maximiser l’interopérabilité avec les différents dispositifs de réseau privé virtuel.

Oracle provisionne deux tunnels de réseau privé virtuel dans le cadre de la connexion IPSec. Assurez-vous de configurer les deux tunnels de votre équipement de client sur place pour la redondance.

De plus, vous pouvez déployer deux routeurs d’équipement de client sur place dans votre centre de données sur place, chacun étant configuré pour les deux tunnels.

Un réseau privé virtuel IPSec est un réseau à norme ouverte qui offre une interopérabilité avec Oracle Cloud Infrastructure. Vous devez vérifier que votre logiciel de réseau privé virtuel IPSec accepte au moins un paramètre IPSec pris en charge dans chaque groupe de configuration, selon les informations de configuration génériques d’équipement de client sur place.

Le réseau de services d’Oracle est un réseau conceptuel dans Oracle Cloud Infrastructure qui est réservé aux services d’Oracle. Le réseau comprend une liste de blocs CIDR régionaux. Chaque service du réseau d’Oracle expose un point d’extrémité qui utilise des adresses IP publiques du réseau. Un grand nombre de services Oracle sont actuellement disponibles dans ce réseau (voir la liste complète), et d’autres services seront ajoutés à l’avenir, au fur et à mesure qu’ils seront déployés sur Oracle Cloud Infrastructure.

Une passerelle de service permet aux ressources de votre réseau en nuage virtuel d’accéder aux services Oracle de façon privée et sécurisée dans le réseau de services d’Oracle, comme Oracle Cloud Infrastructure Object Storage, ADW et ATP. Le trafic entre une instance du réseau en nuage virtuel et un service Oracle pris en charge utilise l’adresse IP privée de l’instance pour le routage. Il est acheminé sur la structure d’Oracle Cloud Infrastructure et ne doit jamais traverser Internet. Tout comme la passerelle Internet ou la passerelle NAT, la passerelle de service est un appareil virtuel qui est hautement disponible et qui effectue des mises à l’échelle dynamiques pour prendre en charge la bande passante de votre réseau en nuage virtuel.

Actuellement, vous pouvez configurer la passerelle de service pour accéder aux services Oracle dans le réseau de services Oracle. Un grand nombre de services Oracle sont actuellement disponibles dans ce réseau (voir la liste complète), et d’autres services seront ajoutés à l’avenir, au fur et à mesure qu’ils seront déployés sur Oracle Cloud Infrastructure.

• Créez une passerelle de service pour le réseau en nuage virtuel.
• Mettez à jour le routage du réseau en nuage virtuel pour acheminer tout le trafic des services Oracle dans le réseau de services Oracle au moyen de la passerelle de service, au lieu d’utiliser la passerelle Internet ou la passerelle NAT.

Pour obtenir des instructions, reportez-vous à la documentation sur l’accès au service de stockage d’objets : Passerelle de service. Veuillez noter que la passerelle de service permet l’accès aux services d’Oracle au sein de la région pour protéger vos données de l’Internet. Vos applications peuvent nécessiter l’accès à des points d’extrémité publics ou à des services qui ne sont pas pris en charge par la passerelle de service, par exemple, pour les mises à jour ou les correctifs. Assurez-vous d’avoir une passerelle NAT ou un autre accès à Internet, au besoin.

La passerelle de service utilise le concept d’étiquette CIDR de service, c’est-à-dire une chaîne qui représente toutes les plages d’adresses IP publiques régionales pour le service ou un groupe de services (par exemple, les services OCI IAD dans le réseau de services d’Oracle est l’étiquette qui correspond aux blocs CIDR régionaux dans le réseau de services Oracle de US-ashburn-1). Vous utilisez l’étiquette CIDR de service lorsque vous configurez la passerelle de service et les règles de routage/de sécurité. Pour obtenir des instructions, reportez-vous à la documentation sur l’accès aux services d’Oracle : Passerelle de service.

Non. La passerelle de service est régionale et ne peut accéder qu’aux services exécutés dans la même région.

Oui. Si vous utilisez une passerelle de service, vous pouvez définir une politique IAM qui permet l’accès à un seau uniquement si les demandes proviennent d’un réseau en nuage virtuel ou d’une plage CIDR spécifique. La politique IAM ne fonctionne que pour le trafic acheminé par la passerelle de service. L’accès est bloqué si la politique IAM est en place et que le trafic passe plutôt par une passerelle Internet. De plus, sachez que la politique IAM vous empêche d’accéder au seau par l’intermédiaire de la console. L’accès est autorisé par programmation uniquement à partir des ressources du réseau en nuage virtuel.

Pour un exemple de politique IAM, consultez la documentation sur l’accès au service de stockage d’objets : Passerelle de service.

Non. Un réseau en nuage virtuel ne peut avoir qu’une seule passerelle de service à l’heure actuelle.

Non. Un réseau en nuage virtuel appairé à un autre réseau en nuage virtuel doté d’une passerelle de service ne peut pas utiliser cette passerelle de service pour accéder aux services Oracle.

Non. Cependant, vous pouvez utiliser le service d’appairage public FastConnect pour ce faire (sans devoir passer par Internet).

Non. Les instances obtiennent le même débit avec la passerelle de service que lorsque le trafic est acheminé par une passerelle Internet.

La passerelle de service est gratuite pour tous les clients d’Oracle Cloud Infrastructure.

Une liste de sécurité fournit, par exemple, un pare-feu virtuel avec des règles d’entrée et de sortie qui précisent les types de trafic autorisés dans l’instance et hors de celle-ci. Vous pouvez sécuriser votre instance de calcul en utilisant des listes de sécurité. Vous configurez vos listes de sécurité au niveau du sous-réseau, ce qui signifie que toutes les instances du sous-réseau sont assujetties aux mêmes règles de liste de sécurité. Les règles sont appliquées au niveau de l’instance et contrôlent le trafic au niveau du paquet.

Une carte VNIC particulière d’une instance est assujettie aux listes de sécurité associées au sous-réseau de la carte VNIC. Lorsque vous créez un sous-réseau, vous spécifiez une ou plusieurs listes de sécurité à associer à celui-ci, et cela peut inclure la liste de sécurité par défaut pour le réseau en nuage virtuel. Si vous ne spécifiez pas au moins une liste de sécurité pendant la création du sous-réseau, la liste de sécurité par défaut du réseau en nuage virtuel est associée au sous-réseau. Les listes de sécurité sont associées au niveau du sous-réseau, mais les règles s’appliquent au trafic de la carte VNIC au niveau des paquets.

Oui. Vous pouvez modifier les propriétés du sous-réseau afin d’ajouter ou de supprimer des listes de sécurité. Vous pouvez également modifier les règles individuelles dans une liste de sécurité.

Il y a une limite au nombre de listes de sécurité que vous pouvez créer, au nombre de listes que vous pouvez associer à un sous-réseau et au nombre de règles que vous pouvez ajouter à une liste donnée. Pour connaître les limites de service actuelles et les instructions sur la façon de demander une augmentation des limites, consultez la documentation d’aide sur les limites de service.

Non. Les listes de sécurité n’utilisent que des règles d’autorisation. Tout le trafic est refusé par défaut, et seul le trafic réseau correspondant aux attributs spécifiés dans les règles est autorisé.

Chaque règle est avec ou sans état, de plus elle est soit une règle d’entrée ou de sortie.

Avec les règles avec état, une fois qu’un paquet réseau correspondant à la règle est autorisé, le suivi de connexion est utilisé, et tous les autres paquets réseau associés à cette connexion sont automatiquement autorisés. Ainsi, si vous créez une règle d’entrée avec état, le trafic entrant correspondant à la règle et le trafic sortant (réponse) correspondant sont autorisés.

Avec les règles sans état, seuls les paquets réseau correspondant à la règle sont autorisés. Ainsi, si vous créez une règle d’entrée sans état, seul le trafic entrant est autorisé. Vous devez créer une règle de sortie sans état correspondante pour correspondre au trafic sortant (réponse) en question.

Pour en savoir plus, consultez la documentation d’aide sur les listes de sécurité.

Les groupes de sécurité réseau et les listes de sécurité sont deux façons différentes de mettre en œuvre des règles de sécurité, qui sont des règles qui contrôlent le trafic entrant et sortant de la carte VNIC.

Les listes de sécurité permettent de définir un ensemble de règles de sécurité qui s’appliquent à toutes les cartes VNIC d’un sous-réseau donné. Les groupes de sécurité réseau (NSG) permettent de définir un ensemble de règles de sécurité qui s’appliquent à un groupe de cartes VNIC de votre choix. Par exemple : un groupe d’instances de calcul ayant la même situation de sécurité.

POUR EN SAVOIR PLUS, CONSULTEZ :

• Règles de sécurité
• Groupes de sécurité réseau

Non. Par défaut, tout le trafic est refusé. Les règles de sécurité ne permettent que le trafic. L’ensemble de règles qui s’appliquent à une carte VNIC particulière est l’intersection de ces éléments :

• Les règles de sécurité dans les listes de sécurité associées au sous-réseau de la carte VNIC
• Les règles de sécurité de tous les groupes de sécurité de réseau dans lesquelles se trouve la carte VNIC

Calcul, équilibrage de charge et services de base de données. Cela signifie que lorsque vous créez une instance de calcul, un équilibreur de charge ou un système de base de données, vous pouvez spécifier un ou plusieurs groupes de sécurité réseau pour contrôler le trafic de ces ressources.

Avec l’introduction des groupes de sécurité réseau, il n’y a aucun changement apporté au comportement de la liste de sécurité. Votre réseau en nuage virtuel dispose toujours une liste de sécurité par défaut, que vous pouvez utiliser avec les sous-réseaux de votre réseau en nuage virtuel.

Lorsque vous écrivez des règles pour un groupe de sécurité réseau, vous avez l’option de préciser un groupe comme étant source du trafic (pour les règles d’entrée) ou destination du trafic (pour les règles de sortie). La possibilité de spécifier un groupe de sécurité réseau signifie que vous pouvez facilement rédiger des règles afin de contrôler le trafic entre deux groupes différents. Les groupes de sécurité réseau doivent être dans le même réseau en nuage virtuel.

Non. Lorsque vous écrivez une règle de sécurité de groupe de sécurité réseau qui précise un autre groupe à titre de source ou de destination, ce groupe doit être dans le même réseau en nuage virtuel. Cela est vrai même si l’autre groupe de sécurité réseau se trouve dans une liste de sécurité d’un autre réseau en nuage virtuel appairé.

Les listes de sécurité permettent de définir un ensemble de règles de sécurité qui s’appliquent à toutes les cartes VNIC d’un sous-réseau, tandis que les groupes de sécurité réseau (NSG) permettent de définir un ensemble de règles de sécurité qui s’appliquent à un groupe de cartes VNIC de votre choix (y compris les équilibreurs de charge ou les systèmes de base de données des cartes VNIC) dans un réseau en nuage virtuel.

Une table de routage de réseau en nuage virtuel contient des règles pour acheminer le trafic dont la destination finale correspond à des emplacements à l’extérieur du réseau en nuage virtuel.

Chaque règle d’une table de routage est dotée d’un bloc CIDR de destination et d’une cible. Lorsque le trafic sortant du sous-réseau correspond au bloc CIDR de destination de la règle de routage, le trafic est acheminé à la cible. Voici des exemples de cibles d’acheminement : une passerelle Internet ou une passerelle de routage dynamique.

Pour en savoir plus, voir la documentation sur les tables de routage.

Une carte VNIC particulière d’une instance est assujettie à la table de routage associé au sous-réseau de la carte. Lorsque vous créez un sous-réseau, vous spécifiez une table de routage à associer avec celui-ci, qui peut être la table de routage par défaut du réseau en nuage virtuel ou une autre table que vous avez déjà créée. Si vous ne spécifiez pas de table de routage au cours de la création du sous-réseau, la table de routage par défaut du réseau en nuage virtuel est associée au sous-réseau. La table de routage est associée au niveau du sous-réseau, mais les règles s’appliquent au trafic de la carte au niveau des paquets.

Non. Actuellement, vous pouvez ajouter une règle de routage uniquement pour un bloc CIDR qui ne chevauche pas l’espace d’adresse du réseau en nuage virtuel.

Oui. Vous pouvez modifier les propriétés du sous-réseau afin de modifier la table de routage. Vous pouvez également modifier les règles individuelles dans une table de routage.

Non. Pas actuellement.

Il y a une limite au nombre de règles dans une table de routage. Voir la documentation d’aide sur les limites de service.

Oui. Vous pouvez utiliser une adresse IP privée comme cible d’une règle de routage dans les situations où vous voulez acheminer le trafic d’un sous-réseau vers une autre instance du même réseau en nuage virtuel. Pour connaître les exigences et d’autres détails, voir la documentation sur l’utilisation d’une adresse IP privée comme cible d’acheminement.

L’appairage de réseaux en nuage virtuels est un processus de connexion de deux réseaux en nuage virtuels permettant une connectivité privée et un flux de trafic entre les deux réseaux. Il existe deux types généraux d’appairage :

• Appairage de réseaux en nuage virtuels local (ou intrarégion) : Les deux réseaux en nuage virtuels se trouvent dans la même région. Ils peuvent être dans la même location (dans les mêmes compartiments ou différents) ou dans différents types de location.
• Appairage de réseaux en nuage virtuels à distance (ou interrégion) : Les deux réseaux en nuage virtuels se trouvent dans différentes régions.

Pour en savoir plus, consultez la documentation sur l’accès à d’autres réseaux en nuage virtuels : Appairage.

• Le service d’appairage de réseaux en nuage virtuels local (intrarégion) est pris en charge dans toutes les régions.
• Le service d’appairage de réseaux en nuage virtuels à distance (interrégion) est actuellement pris en charge. La liste des régions pour la prise en charge se trouve dans la documentation de produit.

• Grâce à l’appairage de réseaux en nuage virtuels local, vous pouvez organiser vos ressources en vue de séparer les réseaux en nuage virtuels et de respecter les exigences de gouvernance et de présence régionale, tout en offrant une connectivité privée entre ces réseaux. Grâce à l’appairage de réseaux en nuage virtuel local entre plusieurs locations, vous pouvez organiser vos ressources dans des réseaux en nuage virtuels dans des locations différentes, tout en offrant une connectivité privée entre ces réseaux virtuels. Vous pouvez également activer un modèle de fournisseur de services en offrant un accès privé à vos services pour plusieurs réseaux en nuage virtuels de consommateurs (dans différentes sociétés) situés dans la même région.
• Grâce à l’appairage de réseaux en nuage virtuels à distance, vous pouvez organiser vos ressources en vue de séparer les réseaux en nuage virtuels et de répondre aux exigences en matière de gouvernance, de présence dans plusieurs régions et de reprise après sinistre, tout en offrant une connectivité privée entre ces réseaux dans différentes régions.

• Solution de rechange fiable et sans frais aux modèles de connectivité, comme un réseau privé virtuel, permettant d’éliminer les passerelles Internet, les adresses IP publiques pour les instances, le chiffrement et les goulots d’étranglement de performance.
• Facilité d’activation de l’appairage entre les réseaux en nuage virtuels, sans temps d’arrêt programmé.
• Connectivité privée pour les ressources de réseau en nuage virtuel appairée à l’aide de liens hautement redondants d’Oracle Cloud Infrastructure, avec une bande passante et une latence prévisibles.

Pour obtenir des instructions, consultez la section sur l’appairage de réseaux en nuage virtuels local.

Non. Les deux réseaux en nuage virtuels d’une relation d’appairage locale ne peuvent pas avoir des CIDR qui se chevauchent.

Oui. Si VCN-1 est appairé à deux autres réseaux en nuage virtuels (VCN-2 et VCN-3), ces deux derniers (VCN-2 et VCN-3) peuvent avoir des CIDR qui se chevauchent.

Oui.

Un réseau en nuage virtuel particulier peut présenter un maximum de dix appairages locaux à la fois.

• Solution de rechange fiable et peu coûteuse aux modèles de connectivité, comme un réseau privé virtuel, permettant d’éliminer les passerelles Internet, les adresses IP publiques pour les instances, le chiffrement et les goulots d’étranglement de performance.
• Facilité d’activation de l’appairage entre les réseaux en nuage virtuels, sans temps d’arrêt programmé.
• Connectivité privée pour les ressources de réseau en nuage virtuel appairée à l’aide de liens dorsaux hautement redondants d’Oracle Cloud Infrastructure, avec une bande passante et une latence prévisibles.

Non. Vous devez établir une connexion d’appairage à distance à l’aide d’une passerelle de routage dynamique (DRG).

Pour obtenir des instructions, consultez la section sur l’appairage de réseaux en nuage virtuels à distance.

Non. Les deux réseaux en nuage virtuels d’une relation d’appairage à distance ne peuvent pas avoir des CIDR qui se chevauchent.

Non. Si VCN-1 est appairé à distance à deux autres réseaux en nuage virtuels (VCN-2 et VCN-3), ces deux derniers (VCN-2 et VCN-3) ne peuvent pas avoir des CIDR qui se chevauchent.

Non.

Oui. Le trafic de l’appairage de réseaux en nuage virtuels à distance utilise un chiffrement de liaison conforme aux normes de l’industrie.

Un réseau en nuage virtuel particulier peut présenter un maximum de dix appairages à distance à la fois.

Oui. Vous pouvez utiliser les tables de routage et les listes de sécurité de VCN-A pour contrôler la connectivité au réseau appairé à VCN-B. Vous pouvez permettre la connectivité à la plage d’adresses complète de VCN-B ou la limiter à un ou à plusieurs sous-réseaux.

Oui. Une fois l’appairage local ou distant établi, les instances dans VCN-B peuvent envoyer le trafic à la gamme complète d’adresses de VCN-A. Cependant, vous pouvez limiter l’accès des instances de VCN-B à un sous-réseau spécifique dans VCN-A en utilisant les règles d’entrée appropriées dans les listes de sécurité du sous-réseau.

Non. Le débit et le temps d’attente s’approchent de ceux des connexions entre réseaux en nuage virtuels. Le trafic associé à l’appairage local présente des contraintes de disponibilité et de bande passante semblables à celles du trafic entre les instances d’un réseau en nuage virtuel.

L’appairage de réseau en nuage virtuel utilise les liens dorsaux d’Oracle Cloud Infrastructure entre les régions. Celui-ci est conçu pour offrir des caractéristiques de performance et de disponibilité supérieures, ainsi qu’un niveau de disponibilité de 99,5 % pour la connectivité interrégions. En règle générale, Oracle offre un débit de plus de 75 Mbit/s et une latence de moins de 60 ms entre les régions des États-Unis, 80 ms entre l’UE et les États-Unis, 175 ms entre les États-Unis et l’APAC et 275 ms entre l’UE et l’APAC.

• Appairage local (intrarégion) : Aucuns frais.
• Appairage à distance (interrégion) : Les tarifs sont basés sur le transfert de données sortant. Reportez-vous à la tarification la plus récente en matière de « transfert de données sortant ».

La solution de routage de transit de réseau en nuage virtuel (VTR) est basée sur une topologie en étoile et permet au concentrateur du réseau en nuage virtuel de fournir une connectivité de transit entre les réseaux en nuage virtuel plusieurs rayons (dans la région) et les réseaux sur place. Un seul réseau FastConnect ou réseau privé virtuel IPSec (connecté au concentrateur du réseau en nuage virtuel) est requis pour que le réseau sur place communique avec tous rayons des réseaux en nuage virtuels.

Voir les instructions de configuration du routage de transit de réseau en nuage virtuel dans la console.

Actuellement, les rayons des réseaux en nuage virtuels peuvent accéder à vos réseaux sur place à l’aide du concentrateur du réseau en nuage virtuel.

Non. La solution de routage de transit de réseau en nuage virtuel prend uniquement en charge la connectivité consolidée entre les réseaux en nuage virtuels de la même région.

Oui. Vous contrôlez cela à l’aide de la table de routage associée à la passerelle d’appairage locale sur le concentrateur du réseau en nuage virtuel. Vous pouvez configurer des règles de routage restrictives qui ne précisent que les sous-réseaux sur place que vous voulez mettre à la disposition aux rayons du réseau en nuage virtuel. Les routes annoncées aux rayons du réseau en nuage virtuel sont celles de la table de routage et du CIDR du concentrateur du réseau en nuage virtuel.

Oui. Vous contrôlez cela à l’aide de la table de routage associée à la passerelle de routage dynamique sur le concentrateur du réseau en nuage virtuel. Vous pouvez configurer des règles de routage restrictives qui précisent uniquement les rayons des sous-réseaux en nuage virtuel dont vous voulez mettre à la disposition du réseau sur place. Les routes annoncées sur le réseau sur place sont celles de la table de routage et du CIDR du concentrateur du réseau en nuage virtuel.

Oui. Le concentrateur de réseaux en nuage virtuels est limité à un maximum de 10 appairages locaux avec les rayons des réseaux en nuage virtuels.

Oui. Vous pouvez ajouter une passerelle de service à un réseau en nuage virtuel connecté à votre réseau sur place au moyen de FastConnect ou de VPN Connect. Vous pouvez ensuite configurer les règles de routage sur les tables de routage associées à la passerelle de routage dynamique et à la passerelle de service du réseau en nuage virtuel afin de diriger le trafic sur les lieux par l’intermédiaire du réseau en nuage virtuel vers les services d’intérêt d’Oracle. Vos hôtes sur place peuvent utiliser leur adresse IP privée lorsqu’ils communiquent avec les services Oracle, et le trafic ne passe pas par Internet.

Pour obtenir de plus amples renseignements, reportez-vous à la documentation sur l’acheminement de transit : Accès privé aux services Oracle.

Oui. Vous pouvez configurer le routage de transit par une adresse IP privée dans le concentrateur de réseau en nuage virtuel. Dans ce cas, vous acheminez le trafic vers une adresse IP privée sur l’instance du pare-feu dans le concentrateur du réseau en nuage virtuel. L’instance de pare-feu peut inspecter tout le trafic entre votre réseau sur place et les rayons des réseaux en nuage virtuels.

Si vous utilisez une instance de pare-feu (ou tout autre appareil virtuel de réseau) dans le concentrateur de réseau en nuage virtuel, les limites de performance sont basées sur les caractéristiques d’E/S de l’appareil virtuel de réseau. Si vous n’acheminez pas le trafic par un appareil virtuel réseau, et que vous passez directement par les passerelles du concentrateur de réseau en nuage virtuel, il n’y a pas de limite de performance. Les passerelles sont des appareils virtuels hautement disponibles et pouvant être mis à l’échelle dynamiquement afin de prendre en charge les besoins en bande passante du réseau.

Le protocole DHCP (Dynamic Host Configuration Protocol) fournit un cadre pour transmettre les données de configuration aux hôtes sur un réseau IP. Les paramètres de configuration et autres informations de contrôle sont transmis à l’instance dans le champ d’options (RFC 2132) du message DHCP. Chaque sous-réseau d’un réseau en nuage virtuel peut être associé à un ensemble unique d’options DHCP.

Vous pouvez configurer deux options qui contrôlent la façon pour la résolution des noms d’hôte des instances de votre système de nom de domaine (DNS) :

• Domaine de recherche. Vous pouvez préciser un seul domaine de recherche.
• Type de DNS. Choisissez une des options suivantes :
  • Internet et résolveur de réseau en nuage virtuel (par défaut)
  • Résolveur personnalisé (vous pouvez spécifier jusqu’à trois serveurs de DNS de votre choix, que vous configurez, gérez et tenez à jour)

Lors de la résolution d’une requête de DNS, le système d’exploitation de l’instance utilise les serveurs de DNS spécifiés avec le type DNS et ajoute le domaine de recherche à la valeur recherchée. Pour en savoir plus, consultez les options DHCP.

Oui. Vous pouvez modifier les propriétés du sous-réseau pour changer le jeu d’options DHCP utilisé par le sous-réseau. Vous pouvez également modifier les valeurs des options DHCP.

Lorsque vous lancez une instance, vous pouvez spécifier un nom d’hôte pour l’instance, ainsi qu’un nom d’affichage. Ce nom d’hôte, combiné au nom de domaine du sous-réseau, devient le nom de domaine complet (FQDN) de votre instance. Ce FQDN est unique dans le réseau en nuage virtuel et résout l’adresse IP privée de votre instance. Pour plus de détails, consultez la documentation de DNS sur votre réseau en nuage virtuel.

Notez que pour spécifier un nom d’hôte pour l’instance, le réseau en nuage virtuel et le sous-réseau doivent être configurés pour activer les noms d’hôte DNS.

Lorsque vous créez un réseau en nuage virtuel, vous pouvez spécifier son étiquette DNS. Ce nom, combiné au domaine parent oraclevcn.com, devient le nom de domaine du réseau en nuage virtuel.

Lorsque vous créez un sous-réseau, vous pouvez spécifier son étiquette de DNS. Ce nom, combiné au nom de domaine réseau en nuage virtuel, devient le nom de domaine du sous-réseau.

Vous pouvez activer un nom d’hôte pour une instance de calcul uniquement si le réseau en nuage virtuel et le sous-réseau sont tous deux créés avec une étiquette DNS.

Un nom d’hôte de DNS est un nom qui correspond à l’adresse IP d’une instance connectée à un réseau. Dans le cas d’un réseau en nuage virtuel utilisé avec Oracle Cloud Infrastructure, chaque instance peut être configurée avec un nom d’hôte DNS correspondant à l’adresse privée de l’instance.

Un nom de domaine entièrement qualifié (FQDN) d’une instance ressemble à ceci : hostname.subnetdnslabel.vcndnslabel.oraclevcn.com, où hostname est l’hôte DNS de l’instance et où subnetdnslabel et vcndnslabel sont les étiquettes de DNS du sous-réseau de l’instance et du réseau en nuage virtuel respectivement.

Le domaine parent oraclevcn.com est réservé à l’utilisation avec les noms d’hôte DNS créés dans Oracle Cloud Infrastructure.

Oui.

Non.

Oui. Les noms d’hôte DNS sont créés pour les instances, peu importe le type de DNS sélectionné pour le sous-réseau.

Non. L’instance peut résoudre les noms d’hôte uniquement des instances dans le même réseau en nuage virtuel.

Oui, vous pouvez le faire avec des serveurs DNS personnalisés configurés dans le réseau en nuage virtuel. Vous pouvez configurer les serveurs de DNS personnalisés pour utiliser 169.254.169.254 comme transitaire pour le domaine du réseau en nuage virtuel (comme contoso.oraclevcn.com).

Veuillez noter que les serveurs de DNS personnalisés doivent être configurés dans un sous-réseau qui utilise « internet and VCN resolver » comme type de DNS (pour permettre l’accès à l’adresse IP 169.254.169.254).

Pour un exemple de mise en œuvre avec le fournisseur Oracle Terraform, voir la documentation de configuration de DNS hybride.

Il n’y a aucuns frais pour la création et l’utilisation des réseaux en nuage virtuels. Toutefois, les frais d’utilisation des autres services Oracle Cloud Infrastructure (y compris les instances de calcul et les volumes par blocs) et les frais de transfert de données s’ajoutent aux tarifs publiés. Il n’y a pas de frais de transfert de données pour les communications entre les ressources d’un réseau en nuage virtuel.

Seuls les frais de transfert de données sortantes d’Oracle Cloud Infrastructure sont facturés. Il n’y a pas de frais de connexion au réseau privé virtuel par heure ou par mois.

Vous n’avez pas à payer de frais de transfert de données lorsque vous accédez à d’autres services publics d’Oracle Cloud Infrastructure, comme le stockage d’objets, dans la même région. Le trafic réseau par l’intermédiaire d’une adresse IP privée ou publique entre vos instances et d’autres ressources à l’intérieur de votre réseau en nuage virtuel, comme une base de données ou un équilibreur de charge, est exempt de frais de transfert de données.

Si vous accédez aux ressources publiques d’Oracle Cloud Infrastructure par l’intermédiaire de votre RPV IPSec depuis l’intérieur de votre réseau privé virtuel, vous devrez payer les frais de transfert de données sortantes.

Sauf indication contraire, les tarifs d’Oracle Cloud Infrastructure, y compris les frais de transfert de données sortants, excluent les taxes et les droits applicables, y compris la TVA et toute taxe de vente applicable.