FAQ sur les réseaux en nuage virtuels

Questions d’ordre général

Qu’est-ce qu’un réseau en nuage virtuel (VCN)?

Un VCN est un réseau privé personnalisable dans Oracle Cloud Infrastructure (OCI). Tout comme un réseau de centres de données traditionnel, un réseau en nuage virtuel vous offre un contrôle complet sur votre environnement réseau. Cela inclut l'attribution de votre propre espace d'adresses IP privées, la création de sous-réseaux, la création de tables de routage et la configuration de contrôles de sécurité par des règles de sécurité, des groupes de sécurité réseau (NSG) ou le routage de paquets Zero Trust (ZPR). Une même instance de location (un compte OCI) peut disposer de plusieurs VCN, ce qui permet de regrouper et d'isoler les ressources associées. Par exemple, vous pouvez utiliser plusieurs réseaux en nuage virtuels pour séparer les ressources dans différents services de votre entreprise.

Quels sont les composants principaux d’un réseau en nuage virtuel?

Pour obtenir la liste complète des composants, consultez notre documentation générale sur les réseaux.

Comment démarrer avec réseau en nuage virtuel?

Pour un didacticiel rapide sur la manière de lancer une instance au sein d'un VCN dans Oracle Cloud Infrastructure, consultez notre Guide de démarrage.

Consultez également la documentation suivante :

• Présentation générale des réseaux
• Gestion des réseaux virtuels (VCN) et des sous-réseaux

Quelles adresses IP puis-je utiliser à l’intérieur de mon réseau en nuage virtuel?

Un VCN dans OCI prend en charge l'adressage IPv4 et IPv6. Un VCN et ses sous-réseaux peuvent comporter plusieurs préfixes IPv4 et IPv6. Vous créez des sous-réseaux au sein du VCN en subdivisant la plage d'adresses de ce dernier en préfixes IP contigus et non chevauchants. Chaque préfixe CIDR IPv4 ou IPv6 d'un sous-réseau d'un VCN doit appartenir respectivement à l'un des préfixes CIDR IPv4 ou IPv6 de ce VCN. Lorsque vous lancez une ressource, comme une instance de calcul ou un équilibreur de charge réseau (NLB), dans un sous-réseau, les adresses IPv4/v6 privées de cette ressource doivent appartenir à l'un des préfixes IPv4/v6 du sous-réseau.

Dans le cadre d'un VCN, l'adressage IPv4 va de /16 (65 533 adresses IP utilisables) à /30 (1 adresse IP utilisable). Exemple : 10.0.0.0/16, 192.168.0.0/24. Nous recommandons d'utiliser un bloc CIDR IPv4 issu des plages d'adresses privées définies par la RFC 1918. En ce qui concerne l'adressage IPv4, si vous utilisez un bloc CIDR IPv4 non conforme à la norme RFC 1918 (en particulier des blocs IPv4 publics) pour un sous-réseau, notez qu'il est toujours considéré comme une plage d'adresses IP privées et qu'il n'est pas routable depuis Internet par la passerelle Internet d'OCI. D'une manière générale, il n'existe aucune configuration permettant d'attribuer à un VCN OCI (ou à ses sous-réseaux) des plages CIDR IPv4 routables sur Internet. Les adresses IPv4 publiques sont toujours attribuées individuellement à une ressource de votre sous-réseau public. Notez également que certaines plages d'adresses IPv4 privées, comme celles des classes D et E, sont réservées à OCI et ne peuvent donc pas être attribuées à un VCN ni à ses sous-réseaux.

Un VCN doit être activé pour l'adressage IPv6, soit lors de sa création, soit ultérieurement. Les VCN compatibles IPv6 peuvent comporter trois types de préfixes IPv6, comme indiqué ci-dessous :

1. Oracle GUA IPv6 : ce type de préfixe correspond à un préfixe d'adresse IPv6 globale de diffusion univoque (GUA) de type /56 attribué par Oracle. Le nombre de préfixes Oracle GUA est limité à un par VCN.
2. GUA BYOIPv6 : Chaque préfixe IPv6 de ce type est un préfixe GUA BYOIPv6 de type /64 ou supérieur. Chaque préfixe de ce type doit provenir d'un préfixe BYOIPv6 GUA de type /48 ou supérieur déjà importé dans votre environnement. Un VCN peut comporter plusieurs préfixes IPv6 de type GUA BYOIPv6.
3. ULA IPv6 : Chaque préfixe IP de ce type est un préfixe d'adresse locale unique (ULA) de type /64 ou supérieur. Un VCN peut comporter plusieurs préfixes IPv6 de type ULA.

Nous vous recommandons d'attribuer des préfixes ULA aux sous-réseaux privés. Même si vous attribuez une plage GUA sous le type de préfixe IPv6 « ULA » à un VCN, celui-ci ne sera toujours pas accessible depuis Internet, car il sera considéré uniquement comme un préfixe IPv6 privé.

Lorsque le protocole IPv6 est activé pour un VCN, vous pouvez créer un sous-réseau comportant uniquement un préfixe IPv4, ou à la fois des préfixes IPv4 et IPv6. Par conséquent, un VCN peut comporter à la fois des sous-réseaux exclusivement IPv4 et des sous-réseaux combinant IPv4 et IPv6.
Tous les sous-réseaux compatibles IPv6 ne peuvent disposer que de préfixes IPv6 de type /64. En ce qui concerne l'adressage IPv6, seules les adresses IPv6 GUA (issues des types de préfixes GUA « Oracle » ou « BYOIPv6 ») peuvent être accessibles depuis Internet, et ce uniquement si elles sont attribuées à un sous-réseau public.
Si des préfixes IPv6 GUA sont attribués à un sous-réseau privé, ceux-ci ne disposeront pas d'une connexion à Internet. Dans ce cas, les adresses issues de ces préfixes GUA ne peuvent être utilisées que pour des communications privées. Nous vous recommandons d'utiliser exclusivement le type de préfixe IPv6 « ULA » pour les sous-réseaux privés d'un VCN prenant en charge IPv6.

Combien de préfixes IP peut-on attribuer à un VCN et à son sous-réseau?

Le tableau ci-dessous présente les limites de service concernant le nombre maximal de préfixes IP pour un VCN et ses sous-réseaux, conformément au schéma d'adressage IP. Vous pouvez demander une augmentation de la limite depuis la console OCI.

Quelles sont les restrictions de taille applicables aux préfixes IP attribués à un VCN et à son sous-réseau?

Voici les tailles minimale et maximale des préfixes pour les VCN et les sous-réseaux dans OCI :

Un VCN prend-il en charge l'adressage IPv6 en pile unique?

À l'heure actuelle, vous pouvez créer un VCN de type « pile simple » avec un adressage IPv4 ou de type « pile double » prenant en charge à la fois les adresses IPv4 et IPv6. Par conséquent, chaque VCN dispose toujours d'au moins un CIDR IPv4 privé. Si un VCN est créé avec uniquement un adressage IPv4 en pile unique, vous pouvez activer IPv6 ultérieurement à tout moment. Un sous-réseau d'un VCN, qu'il prenne en charge ou non le protocole IPv6, doit toujours disposer d'au moins un CIDR IPv4.

Puis-je marquer un sous-réseau comme étant privé?

Oui, Lorsque vous créez un sous-réseau, vous pouvez définir son type d'accès comme « privé » ou « public ». Un sous-réseau est créé par défaut avec un accès public ; dans ce cas, les instances ou ressources (comme l'équilibreur de charge OCI) présentes dans ce sous-réseau peuvent se voir attribuer une adresse IPv4 publique ou une adresse IPv6 GUA publique. Les ressources comme les instances de calcul et les équilibreurs de charge lancées dans un sous-réseau privé ne peuvent pas disposer d'adresses IPv4 publiques. Cela permet de s'assurer que ces ressources ne disposent d'aucun accès direct à Internet. Une fois créé, le type d'accès du sous-réseau ne peut plus être modifié.

Dans quels cas une ressource d'un VCN est-elle directement accessible depuis Internet?

Seules les ressources dotées d'une interface réseau virtuelle (VNIC) ou d'une ressource réseau (NLB, équilibreur de charge [LB], etc.) qui remplissent toutes les conditions suivantes sont accessibles pour les connexions entrantes directes depuis Internet :

1. La ressource VNIC se trouve dans un sous-réseau public et ce sous-réseau dispose d'une route vers la passerelle Internet de son VCN.
2. VNIC/resource dispose d'au moins une adresse IPv4 publique ou une adresse IPv6 GUA publique.
3. Le VNIC/ressource dispose d'un NSG et/ou d'un ZPR et/ou de listes de sécurité qui autorisent l'accès entrant depuis Internet.

Un réseau en nuage virtuel peut-il couvrir plusieurs domaines de disponibilité?

Oui, un VCN s'étend toujours sur tous les domaines de disponibilité (AD) de sa région. Il s'agit donc d'une entité régionale. Un sous-réseau, en revanche, peut être soit spécifique à l'AD, soit régional.

Un sous-réseau peut-il couvrir plusieurs domaines de disponibilité ou plusieurs réseaux en nuage virtuels?

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 de ce sous-réseau peuvent se trouver dans n'importe quel domaine de disponibilité de la région. Lorsque vous créez des ressources dans un sous-réseau régional, vous pouvez choisir le domaine Active Directory de votre choix pour l'emplacement physique de cette ressource. 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. OCI vous recommande de toujours créer des sous-réseaux régionaux afin de garantir une flexibilité future.

Puis-je créer deux VCN dont les plages d'adresses IP se chevauchent? Les réseaux VCN peuvent-ils présenter un chevauchement d'adresses IP avec mon réseau sur site?

Oui, Chaque VCN constitue un réseau isolé jusqu'à ce que vous l'établissiez en appairage avec d'autres VCN ou que vous le connectiez à votre réseau sur site. Toutefois, si vous prévoyez de connecter un VCN à votre réseau sur site ou à un autre VCN, nous vous recommandons vivement de vous assurer que les plages d'adresses IP ne se chevauchent pas. Si ces réseaux se chevauchent et que le routage IP n'est pas conçu avec soin, cela peut entraîner une transmission inattendue de paquets.

Les VCN ou sous-réseaux « pile unique » exclusivement IPv6 sont-ils pris en charge?

OCI prend en charge aussi bien les VCN/sous-réseaux « pile unique » (IPv4 uniquement) que les VCN/sous-réseaux « pile double » (IPv4 et IPv6). Par conséquent, chaque VNIC d'un sous-réseau d'un VCN disposera toujours, dès sa création, d'exactement une adresse IPv4 privée, appelée « adresse IPv4 principale ».

Combien de réseaux en nuage virtuels, de sous-réseaux et d’autres ressources en réseau puis-je créer?

Pour connaître les limites actuelles de tous les services et obtenir des instructions sur la manière de demander une augmentation de ces limites, consultez la documentation relative aux limites des services.

Puis-je modifier mon sous-réseau après l’avoir créé?

Oui, Vous pouvez modifier le nom du sous-réseau, sa table de routage, ses listes de sécurité et l'ensemble des options DHCP qui lui sont associées. Vous pouvez agrandir ou réduire le masque IPv4 du sous-réseau, à condition que le nouveau masque n'exclue pas une adresse IP en cours d'utilisation attribuée à une ressource. Vous ne pouvez pas modifier le préfixe IPv6 du sous-réseau une fois qu'il a été attribué, mais vous pouvez le supprimer et en attribuer un nouveau. Les préfixes IPv6 d'un sous-réseau sont toujours de type /64. Vous pouvez ajouter un nouveau préfixe IP à un sous-réseau, dans la limite des restrictions en vigueur. Vous pouvez également supprimer le CIDR IP ou le préfixe existant du sous-réseau, à condition qu'aucune ressource au sein de ce sous-réseau n'utilise une adresse IP issue de celui-ci.

Passerelle de routage dynamique (DRG) 

Qu'est-ce qu'un DRG amélioré et un DRG existant?

Les DRG créés avant le 17 mai 2021 sont appelés « DRG existants ». Vous devez mettre à niveau les DRG hérités en suivant la procédure décrite dans la documentation relative aux DRG. Un DRG amélioré est la nouvelle version des DRG, dotée de fonctionnalités supplémentaires. Tous les DRG de toutes les régions de tous les royaumes créés après le 17 mai 2021 sont des DRG améliorés. Les DRG hérités ne sont plus pris en charge et ne peuvent plus être créés. Toute mention des DRG dans la documentation publique de l'OCI fait référence aux DRG améliorés.

Et si je souhaite continuer à utiliser mon DRG existant tel quel et que je n'ai pas besoin des fonctionnalités avancées du DRG?

Vous pouvez continuer à utiliser un DRG hérité, car le comportement par défaut du DRG n'a pas changé. Vous devez activer explicitement les nouvelles fonctionnalités en passant à la version améliorée de DRG. Après la mise à niveau d'un DRG classique vers un DRG amélioré, l'état par défaut de ce dernier reproduira le comportement du DRG classique; il n'est donc pas nécessaire de modifier la configuration pour rétablir le flux de trafic.

Quels sont les avantages du DRG amélioré par rapport au DRG existant?

Contrairement aux DRG existants, le DRG amélioré présente les caractéristiques suivantes :

1. Il est possible de connecter jusqu'à 300 VCN en tant que périphériques dans une même région. Cela permet de se passer des passerelles d'appairage locales (LPG) pour l'appairage VCN au sein d'une même région.
2. Les environnements sur site connectés par OCI FastConnect ou VPN à une région OCI peuvent accéder aux ressources situées dans d'autres régions OCI par le réseau fédérateur privé d'OCI.
3. Des tables de routage personnalisées sont autorisées pour chaque connexion, ce qui permet un contrôle précis de la manière dont le trafic circule entre les réseaux.
4. Le routage de transit est pris en charge, ce qui permet de mettre en place des topologies « Centre et étoile » avancées dans lesquelles le trafic entre les VCN « étoile» peut être acheminé de manière centralisée via un appareil virtuel de réseau (NVA) ou un pare-feu à des fins d'inspection.

Comment mettre à niveau mon DRG pour pouvoir utiliser la nouvelle fonctionnalité ?

Veuillez consulter la section Mise à niveau d'un DRG de notre documentation.

Comment puis-je contrôler quels VCN peuvent communiquer entre eux?

Les communications entre les périphériques DRG (y compris les VCN) sont gérées par des tables de routage et les distributions de routes d'importation qui leur sont associées. La table de routage et les politiques de répartition des routes par défaut des connexions VCN sont générées automatiquement pour les connexions VCN d'un DRG. Ces paramètres par défaut permettent à tous les VCN associés de communiquer entre eux. Vous pouvez modifier les politiques de distribution des routes associées afin d'isoler les VCN, comme indiqué dans la documentation relative au DRG.

Quelle est la différence entre la répartition par voie d'importation et la répartition par voie d'exportation?

La distribution des itinéraires d'importation et celle des itinéraires d'exportation s'appliquent toutes deux au tableau des itinéraires DRG d'une pièce jointe, mais elles contrôlent la propagation des itinéraires dans des directions opposées.

Vous trouverez ci-dessous une comparaison détaillée.

Puis-je associer directement un VCN provenant d'un autre environnement à mon DRG?

Oui, Cela nécessite toutefois la configuration de politiques IAM spécifiques inter-locataires. Pour plus d'informations, consultez la documentation Politiques IAM pour le routage entre les VCN.

Quelle est la configuration de routage par défaut dans le DRG ?

Le DRG dispose de deux tables de routage par défaut générées automatiquement. L'une concerne vos connexions FastConnect, vos VPN IPsec de site à site et vos connexions d'appairage à distance, tandis que l'autre concerne les connexions VCN.

La distribution des routes d'importation pour les tables de routes par défaut des connexions RPC, FastConnect et VPN IPsec site à site importe les routes provenant de toutes les connexions VCN au sein du même groupe de routes de défaillance (DRG).

Cela permet à ces périphériques de se connecter à tous les réseaux virtuels (VCN) du groupe de redondance (DRG).

La distribution des routes d'importation pour les tables de routes par défaut des connexions VCN importe les routes provenant de toutes les connexions situées sur le même DRG. Cela permet aux VCN de connecter tous les autres périphériques, quels que soient leurs types, sur le même DRG.

Dans quelle mesure les tables de routage et les répartitions des routes d'importation du DRG influencent-elles le routage au sein du DRG ?

Le DRG prend en charge le routage dynamique et statique entre ses connexions (réseaux connectés) et vous permet de disposer d'une table de routage personnalisée pour chaque connexion. Chaque table de routage personnalisée peut, à son tour, disposer de sa propre répartition personnalisée des routes d'importation.

La distribution des routes d'importation vous permet de spécifier les autres points de raccordement à partir desquels les routes sont importées dynamiquement dans la table de routage associée et deviennent ainsi routables/accessibles pour ce point de raccordement. Cela vous permet de contrôler les routes de manière très précise pour chaque point de connexion, sans aucune intervention manuelle, et de mettre facilement en place une isolation de couche 3 entre des points de connexion spécifiques. Les routes déterminent l'attachement de saut suivant en fonction de l'adresse IP de destination du paquet. En d'autres termes, les tables de routage des DRG des nœuds de connexion déterminent le prochain saut pour les paquets entrants vers le DRG depuis le nœud de connexion, et ce prochain saut correspond toujours à un autre nœud de connexion sur le même DRG.

Cette importation dynamique des itinéraires dans les tables d'itinéraires DRG élimine presque entièrement les étapes manuelles nécessaires à la configuration de la connectivité entre les périphériques.

Comment les tables de routage DRG résolvent-elles les conflits de routage?

Chaque point de connexion DRG dispose de sa propre table de routage DRG afin d'acheminer le trafic entrant vers le DRG depuis ce point de connexion et dont la destination finale est un autre VCN ou un environnement sur site. Les règles de routage de la table de routage DRG déterminent vers quelle connexion du DRG le trafic doit être acheminé en tant que prochain saut. Comme dans toute table de routage, s’il n’existe qu’une seule route correspondant au préfixe le plus long (LPM) pour une adresse IP de destination donnée d’un paquet, c’est cette route qui est sélectionnée.

Des conflits de routage surviennent lorsque la table de routage DRG de la connexion comporte au moins deux routes ayant un préfixe IP identique (et donc le même LPM).

Dans ce cas, le mécanisme de résolution des conflits de la table de routage DRG prend en compte les facteurs suivants, par ordre de priorité, pour les routes comparées :

1. Que l'itinéraire soit statique ou dynamique
2. Le type de pièce jointe de la source de l'itinéraire
3. La longueur de l'AS-Path de la route, etc.

Pour plus d'informations sur la gestion des conflits de routes, veuillez consulter la documentation OCI consacrée à la résolution des conflits de routes DRG.

Comment les routes sont-elles propagées dans le DRG ?

Chaque point de connexion DRG est associé à sa propre table de routage DRG, qui détermine la manière dont le trafic entrant dans le DRG depuis ce point de connexion est acheminé. La table de routage de l'attachement est capable d'apprendre et d'installer de manière dynamique les routes annoncées par d'autres attachements pairs sur le DRG, permettant ainsi d'accéder aux réseaux accessibles via ces attachements pairs. Vous pouvez affiner le choix des routes à apprendre en configurant la politique « import route distribution » appliquée à chaque table de routage DRG.

Avec les distributions de routes d'importation par défaut, les routes sont propagées comme suit :

Routes propagées vers/depuis les réseaux sur site : Lorsque vous connectez des VPN IPsec de site à site ou des circuits virtuels FastConnect à un DRG, les routes sont propagées entre le DRG et votre routeur sur site via le protocole BGP ou de manière statique, selon votre configuration.
Routes propagées à partir des VCN : Lorsque vous associez un VCN au DRG, les tables de routage DRG de toutes les autres associations sur ce DRG importent l'ensemble des routes suivantes :
- Les CIDR des sous-réseaux de ce VCN (par défaut) ou les CIDR de ce VCN
- Le contenu de la table de routage d’entrée du DRG associée au VCN (applicable uniquement dans les configurations avancées)
Routes propagées vers les tables de routage des VCN/sous-réseaux : Les routes du DRG ne sont pas automatiquement propagées vers les tables de routage des sous-réseaux de votre VCN. Vous devez créer des routes statiques explicites dans les tables de routage de votre VCN/sous-réseau pour le trafic à destination de réseaux sur site ou d'autres VCN connectés au même DRG, en indiquant le DRG comme prochain saut. Cela vaut également pour les tables de routage d'entrée des passerelles du VCN. Ces tables de routage sont gérées dans le cadre de la configuration du VCN.

Outre ces routes dynamiques, vous pouvez également ajouter des routes statiques à une table de routes DRG.

Puis-je créer des routes statiques dans une table de routage DRG?

Oui, Vous pouvez créer des routes statiques dans la table de routage DRG pour n'importe quel préfixe de destination. Les routes statiques doivent avoir comme prochain saut un VCN, un RPC ou une connexion VCN/RPC inter-locataires. Les routes statiques dont le saut suivant est un IPSec ou un circuit virtuel ne sont pas prises en charge. Il n'est pas possible d'avoir plusieurs routes statiques dans la même table de routage DRG pour un même préfixe IP de destination.

Puis-je connecter des VCN OCI ayant des préfixes IP de VCN/sous-réseau identiques au même DRG?

Vous pouvez connecter deux réseaux virtuels OCI (VCN) dont les préfixes IP se chevauchent au même groupe de récupération (DRG). La table de routage du DRG prend une décision de routage déterministe et cohérente afin de déterminer quelle connexion VCN constitue le prochain saut pour les préfixes IP de sous-réseau/VCN en conflit. Cet ordre de préférence n'est pas déterminé par le client. En raison de la complexité liée à la gestion de ce comportement, il n'est pas recommandé que les préfixes IP des connexions DRG se chevauchent.

Puis-je utiliser un seul circuit virtuel FastConnect pour connecter mon réseau sur site à tous les réseaux virtuels OCI (VCN), quelle que soit la région?

Oui, le DRG vous permet d'utiliser un circuit virtuel FastConnect dans une région pour communiquer avec des ressources situées dans un VCN de cette même région ou dans un VCN d'une autre région. Dans ce dernier scénario de rampe d'accès à distance, le DRG doté de la connexion de circuit virtuel disposera d'une connexion d'appairage à distance vers un autre DRG situé dans une autre région.

Mon réseau sur site peut-il se connecter à Internet par FastConnect ou le VPN site à site OCI?

Non. Le routage de transit de passerelle à passerelle entre DRG et IGW (ou NATGW) n'est pas autorisé. Ainsi, le trafic provenant du réseau sur site ne peut pas transiter directement vers Internet par le DRG.

Puis-je relier deux réseaux sur site entre eux par FastConnect ou un VPN site à site?

Non. Les DRG ne proposent pas d'itinéraires reliant un réseau sur site (VPN site à site ou circuit virtuel) à un autre réseau sur site. Cela vaut même pour les DRG associés à des RPC. Par conséquent, les DRG ne permettent pas au trafic provenant de vos installations de se connecter à un autre de vos réseaux ou sites sur site.

Quelles sont les limites ou les quotas par défaut pour le DRG?

Pour plus de détails sur les limites et les quotas, consultez notre documentation.
Si vous deviez dépasser ces limites, veuillez créer un dossier d'assistance.

Le DRG prend-il en charge IPv6?

Oui. Le DRG prend en charge l'association de VCN avec des préfixes IPv6. Le DRG prend également en charge la connectivité aux réseaux sur site via n'importe quel VPN site à site ou circuit virtuel FastConnect utilisant le protocole IPv6.

Dois-je utiliser la passerelle d'appairage locale (LPG) ou la DRG pour permettre la communication entre des VCN situés dans la même région?

Chaque VCN peut disposer de 10 passerelles d'appairage locales au maximum et d'une seule DRG au maximum. Un seul DRG prend en charge jusqu'à 300 pièces jointes VCN. Nous recommandons d'utiliser le DRG dans tous les cas de figure d'appairage VCN afin d'améliorer l'évolutivité, la facilité de gestion et l'observabilité.

De plus, si vous souhaitez bénéficier d'une bande passante extrêmement élevée et d'une latence très faible pour le trafic entre deux VCN situés dans la même région, suivez la procédure décrite dans Appairage entre VCN locaux à l'aide de passerelles d'appairage locales. L'établissement d'une connexion d'appairage entre deux VCN situés dans la même région via un DRG vous offre davantage de flexibilité en matière de routage, mais s'accompagne d'une latence légèrement plus élevée et d'une bande passante potentiellement réduite. Pour la plupart des charges de travail, la différence en termes de latence et de bande passante est négligeable.

Quel est le nombre maximal de chemins pris en charge par le routage à coûts égaux (ECMP)?

La limite actuelle est fixée à huit chemins actifs pour l'ECMP dans les tables de routage DRG.

Cartes d'interface réseau virtuelles (VNIC)

Qu'est-ce qu'une carte d'interface réseau virtuelle?

Les serveurs des centres de données OCI sont équipés de cartes d'interface réseau (NIC) physiques. Lorsque vous lancez une instance sur l'un de ces serveurs, celle-ci communique via les cartes réseau virtuelles (VNIC) du service réseau, 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.

Pour ces communications, les VNIC utilisent l'objet IP qui leur est attribué. Ces objets IP peuvent être soit une adresse IP d'hôte (adresse IP unique), soit une adresse IP au format CIDR. Les adresses IP CIDR permettent d'attribuer une plage contiguë d'adresses IP d'hôtes au format CIDR à une carte réseau virtuelle (VNIC) à l'aide d'un seul paramètre de configuration. Toutes les cartes réseau virtuelles (VNIC) de l'instance se trouvent toujours dans le même domaine Active Directory que celui de l'instance à laquelle elles sont associées.

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

• Une adresse IPv4 privée principale issue du sous-réseau dans lequel se trouve la VNIC, choisie soit par vous, soit par Oracle – Elle doit être attribuée au moment de la création de la VNIC. Il s'agit toujours d'une adresse IP d'hôte unique ; il ne peut s'agir d'une adresse IP au format CIDR. Une fois créée, elle ne peut être ni modifiée ni déplacée vers une autre interface réseau virtuelle (VNIC).
• Jusqu'à 64 objets IPv4 secondaires, attribués soit par vous, soit par Oracle – Les objets/adresses IPv4 secondaires ne peuvent être attribués qu'après la création de la VNIC. Tous les objets/adresses IPv4 secondaires peuvent être déplacés à tout moment vers une autre interface réseau virtuelle (VNIC) au sein du même sous-réseau à l'aide des API, du SDK ou de l'interface en ligne de commande (CLI).
• Jusqu'à 32 objets IPv6 issus du sous-réseau dans lequel se trouve la VNIC, attribués soit par vous, soit par Oracle. Contrairement à IPv4, les objets/adresses IPv6 ne font pas l'objet d'une classification en adresses principales et secondaires. Un seul objet/adresse IPv6 peut être attribué à une VNIC lors de sa création. Un objet/une adresse IPv6 peut être attribué(e) à une interface réseau virtuelle (VNIC) à tout moment après sa création. Tous les objets/adresses IPv6 peuvent être déplacés à tout moment vers une autre interface réseau virtuelle (VNIC) au sein du même sous-réseau à l'aide des API, du SDK ou de l'interface en ligne de commande (CLI).
• Adresse IPv4 publique facultative pour chaque adresse IPv4 privée d'hôte – Cette option s'applique si la VNIC se trouve dans un sous-réseau public.
• Nom d'hôte facultatif pour le DNS pour chaque adresse IPv4 privée – Pour plus d'informations, consultez la documentation sur le DNS dans les VCN. Veuillez noter qu'il n'existe actuellement aucun nom d'hôte DNS pour les adresses IPv6.
• Une seule adresse MAC
• Une balise VLAN attribuée par Oracle – Cette balise est disponible une fois que l'association de la carte réseau virtuelle (VNIC) à l'instance est terminée (cela ne concerne que les instances « sans système d'exploitation »)

Pour plus d'informations, consultez notre documentation sur les cartes d'interface réseau virtuelles.

À quoi correspond la carte VNIC principale d’une instance?

Chaque instance de votre VCN est créée avec une carte réseau virtuelle (VNIC) appelée « carte réseau virtuelle 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 VNIC, qu'il soit principal ou secondaire, dispose toujours de sa propre adresse IPv4 privée principale.

À quoi correspondent les cartes VNIC secondaires dans une 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 VNIC supplémentaires à une instance ; celles-ci sont appelées « VNIC secondaires ». Les cartes VNIC secondaires peuvent appartenir à différents réseaux en nuage virtuels ou sous-réseaux. Les VNIC secondaires ne peuvent être ajoutées qu'après la création de l'instance via l'appel d'API LaunchInstance.  

Quel est le nombre maximal de cartes VNIC pris en charge dans une instance?

Le nombre maximal de VNIC pouvant être associées à une instance varie en fonction de la configuration et est souvent (mais pas toujours) linéairement proportionnel au nombre d'OCPU disponibles pour cette configuration. Pour plus d'informations sur ces limites, consultez la documentation sur les formes de calcul.

Y a-t-il des limites de bande passante pour chaque VNIC d'une instance de calcul?

Non. Une limite de bande passante spécifique est attribuée à l'ensemble de l'instance et est souvent (mais pas toujours) linéairement proportionnelle au nombre d'OCPU correspondant à la configuration de votre instance de calcul. L'ensemble des VNIC de l'instance de calcul se partage l'intégralité de cette bande passante allouée. Par exemple, si une instance de calcul dotée de 10 OCPU dispose d'une bande passante allouée de 10 Gb/s et qu'une seule de ses cartes réseau virtuelles (VNIC) est utilisée, cette VNIC peut consommer la totalité des 10 Gb/s. Pour plus d'informations, consultez la documentation sur Compute Shapes.

Puis-je obtenir des renseignements sur la carte VNIC à partir de l’instance?

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/.

Puis-je attribuer une adresse IP privée particulière à une carte VNIC?

Oui, Dans le cas de la VNIC principale, vous pouvez définir l'adresse IP privée au moment de la création de l'instance. Pour les VNIC secondaires, vous pouvez spécifier une adresse IP privée lorsque vous associez la VNIC à une instance. L'adresse IP privée indiquée doit appartenir au même sous-réseau que la VNIC et ne doit pas être déjà utilisée.

Puis-je déplacer une carte VNIC d’une instance à une autre?

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 réseau virtuelles secondaires (VNIC) sont créées et supprimées respectivement lorsqu'elles sont connectées ou déconnectées, ou lorsque leur instance de calcul est arrêtée.

Puis-je associer deux cartes VNIC du même sous-réseau à une instance?

Oui, Cependant, l'association à une instance de plusieurs VNIC provenant du même préfixe IP de sous-réseau peut entraîner un routage asymétrique, en particulier sur les instances fonctionnant sous une variante de Linux. Si vous avez besoin de ce type de configuration, Oracle recommande d'attribuer plusieurs adresses IP privées à une seule carte réseau virtuelle (VNIC) ou d'utiliser le routage basé sur des règles. À titre d'exemple, consultez le script disponible sous Linux : Configuration du système d'exploitation pour les VNIC secondaires dans la documentation .

Les cartes réseau virtuelles (VNIC) associées à une instance peuvent-elles appartenir à des sous-réseaux situés dans des domaines de disponibilité (AD) différents?

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.

Les cartes VNIC associées à une instance peuvent-elles appartenir à des sous-réseaux de différents réseaux en nuage virtuels?

Oui, Vous pouvez associer des VNIC secondaires appartenant à un sous-réseau d'un VCN différent du VCN et/ou du sous-réseau de la VNIC principale.

Quelles interfaces réseau virtuelles (VNIC) sont utilisées pour les opérations d'E/S vers les volumes en bloc de l'instance?

Les opérations d'E/S vers les volumes de blocs iSCSI, s'ils sont associés à l'instance, utilisent exclusivement sa carte réseau virtuelle (VNIC) principale. Les opérations d'E/S vers les volumes de blocs para-virtualisés de l'instance n'utilisent aucune carte réseau virtuelle (VNIC) de l'instance. Toutes les opérations d'E/S en mode bloc (iSCSI et PV) utilisent la totalité de la bande passante réseau allouée à l'instance.

Adresse IP

Puis-je attribuer une ou plusieurs adresses IP privées de mon choix à mon instance de calcul?

Chaque instance de calcul de votre VCN est créée avec une carte réseau virtuelle (VNIC) et se voit attribuer une adresse IPv4 privée issue du sous-réseau fourni lors du lancement de l'instance. Il s'agit respectivement de la VNIC principale et de son adresse IPv4 privée principale. Vous pouvez également associer des VNIC supplémentaires à une instance; on les appelle VNIC secondaires, et chacune d'entre elles dispose également toujours d'une adresse IPv4 privée principale.

Vous pouvez laisser Oracle choisir l'adresse IPv4 privée, ou la sélectionner parmi les blocs CIDR IPv4 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 objets IPv4 privés secondaires à une interface réseau virtuelle (VNIC). À l'instar des adresses IPv4 privées primaires, un objet IPv4 privé secondaire permet de se connecter à des destinations au sein de votre VCN et/ou sur site (lorsqu'une connexion est établie via le VPN site à site OCI ou OCI FastConnect). Un objet IPv4 privé secondaire peut être une adresse IP d'hôte ou une adresse IP au format CIDR. Vous pouvez également attribuer des objets IPv6 à une interface réseau virtuelle (VNIC) lorsque celle-ci se trouve dans un réseau virtuel (VCN) ou un sous-réseau prenant en charge IPv6. Un objet IPv6 attribué à une VNIC peut être une adresse IPv6 d'hôte ou une adresse IPv6 CIDR.

Puis-je déplacer un objet IP d'une interface réseau virtuelle (VNIC) à une autre?

Objets IPv4 : vous pouvez déplacer n'importe quel objet IPv4 privé secondaire d'une interface réseau virtuelle (VNIC) d'une instance vers une interface réseau virtuelle (VNIC) de la même instance ou d'une autre instance, à condition que ces deux interfaces réseau virtuelles appartiennent au même sous-réseau. L'adresse IPv4 principale d'une carte réseau virtuelle (VNIC) ne peut pas être déplacée. Pour les adresses IPv4 principales, vous devez supprimer la VNIC ; ce n'est qu'alors que la même adresse IPv4 privée pourra être attribuée à une autre VNIC.
Objets IPv6 : vous pouvez déplacer n'importe quel objet IPv6 d'une interface réseau virtuelle (VNIC) d'une instance vers une interface réseau virtuelle (VNIC) de la même instance ou d'une autre instance, à condition que ces deux interfaces appartiennent au même sous-réseau.

Veuillez noter qu'ici, le terme « déplacer » désigne le retrait d'un objet IP d'une interface réseau virtuelle (VNIC) et l'attribution de cette même adresse IP hôte (ou adresse IP CIDR) en tant que nouvel objet IP à une autre interface réseau virtuelle (VNIC) à l'aide de l'API, du SDK ou de l'interface en ligne de commande (CLI) d'OCI. Lorsqu'on utilise des sous-réseaux régionaux, l'objet IP peut également être déplacé vers une carte réseau virtuelle (VNIC) située dans un autre domaine Active Directory.

Puis-je attribuer une plage d'adresses IP à une carte réseau virtuelle (VNIC)?

Oui, c'est possible. Une interface réseau virtuelle (VNIC) dispose d'une seule adresse IPv4 principale, qui correspond à l'adresse IP de l'hôte. De plus, une carte réseau virtuelle (VNIC) peut se voir attribuer plusieurs adresses IPv4 et IPv6 secondaires en tant qu'adresses IP d'hôte. Toutes les adresses IP des hôtes ont une longueur de préfixe implicite de /32 pour les adresses IPv4 et de /128 pour les adresses IPv6. Pour attribuer une plage contiguë d'adresses IP d'hôte à une carte réseau virtuelle (VNIC), utilisez une adresse IP au format CIDR. Une adresse IP CIDR est une adresse IP accompagnée de la longueur du préfixe de réseau, exprimée en notation CIDR (par exemple, 10.0.0.32/28), qui attribue à la VNIC toutes les adresses IP des hôtes compris dans ce préfixe. Vous pouvez attribuer des adresses IP au format CIDR à n'importe quelle interface réseau virtuelle (VNIC) d'une instance de calcul en tant qu'objet IP secondaire.

Pour plus d'informations, consultez Objets IP privés et Attribution d'adresses IPv6 à une carte réseau virtuelle (VNIC).

Quelles sont les contraintes relatives à l'attribution d'adresses IP au format CIDR à une carte réseau virtuelle (VNIC)?

Voici les contraintes relatives aux adresses IP CIDR attribuées à une carte réseau virtuelle (VNIC)  :

• Il s'agit toujours d'objets IP secondaires; ils ne peuvent pas être une adresse IP principale attribuée à une VNIC.
• Il est interdit d'inclure toute adresse IP actuellement utilisée ou réservée par des utilisateurs ou par OCI.
• Il doit être entièrement contenu dans l'un des blocs CIDR IPv4 ou l'un des préfixes IPv6 du sous-réseau.
• La longueur du préfixe d'adresse CIDR IPv4 doit être comprise entre /18 et /32 et être supérieure d'au moins 2 bits au masque de sous-réseau lui-même; pour IPv6, le préfixe doit être compris entre /80 et /128, ces valeurs incluses.
• Doit commencer à une limite de réseau valide tant pour IPv4 que pour IPv6; pour IPv6, doit être incrémenté d'un chiffre hexadécimal (limite de nibble ou de 4 bits)

Pour plus d'informations, veuillez consulter la documentation OCI Networking.

Quelles sont les limites des adresses IP au format CIDR?

Voici les restrictions applicables aux adresses IP au format CIDR :

• Aucune association IPv4 publique n'est prévue pour les adresses IPv4 définies au sein d'une adresse IP CIDR; l'utilisation d'une passerelle NAT est nécessaire pour accéder à Internet via IPv4
• Prise en charge uniquement sur les VNIC de calcul
• La création de noms de domaine complets (FQDN) n'est pas prise en charge par le DNS VCN pour les adresses relevant de l'espace d'adressage IP CIDR.
• Non pris en charge sur les cartes réseau virtuelles (VNIC) L2/VLAN
• Les requêtes provenant d'objets IP privés secondaires (y compris les adresses IP CIDR) ne sont pas prises en charge par le service de métadonnées des instances.

Pour plus d'informations, veuillez consulter la documentation OCI Networking.

Le système d’exploitation de l’instance peut-il détecter et configurer automatiquement l’adresse IP privée secondaire (en utilisant DHCP)?

Le système d'exploitation ne parvient pas à détecter les adresses IPv4 privées secondaires attribuées à l'une des cartes réseau virtuelles (VNIC) de l'instance par des mécanismes comme le DHCP. Vous devez configurer les adresses IPv4 privées secondaires en suivant une procédure spécifique à votre système d'exploitation. Le système d'exploitation peut détecter les adresses IPv6 sur n'importe quelle carte réseau virtuelle (VNIC) à l'aide du protocole DHCPv6.

Le protocole DHCP ne s'applique pas aux adresses IP au format CIDR attribuées à une interface réseau virtuelle (VNIC). De manière générale, pour les systèmes d'exploitation Linux et Windows, consultez les scripts fournis dans la documentation Attribution d'une nouvelle adresse IP privée secondaire à une VNIC. Pour Oracle Linux, nous proposons également l'utilitaire CLI oci-network-config qui permet de configurer facilement des VNIC secondaires et des adresses IP.

Qu’est-ce qu’une adresse IP publique et en quoi est-elle différente d’une adresse IP privée?

Une adresse IP publique est une adresse IP accessible depuis Internet (c'est-à-dire 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 au sein du VCN communiquent entre elles à l'aide d'adresses IPv4 privées ou IPv6 (ULA/GUA).

En ce qui concerne l'adressage IPv4, si vous utilisez un bloc CIDR IPv4 public (non conforme à la norme RFC 1918) pour un sous-réseau, notez qu'il est toujours considéré comme une plage d'adresses IPv4 privées et qu'il n'est pas routable en natif vers et depuis Internet (par la passerelle Internet d'OCI).

Vous pouvez attribuer une adresse IP publique à une ressource (par exemple, une instance de calcul ou un équilibreur de charge) et lui permettre ainsi de communiquer avec Internet. Une adresse IPv4 privée attribuée à une carte réseau virtuelle (VNIC) nécessite toujours une association avec une adresse IPv4 publique pour permettre la connexion à Internet via une passerelle Internet.

IPv6 n'impose pas cette contrainte ; les préfixes GUA IPv6 attribués aux VNIC dans les sous-réseaux publics peuvent être routés de manière native vers et depuis Internet par une passerelle Internet.

Toutes les adresses IP publiques et leurs préfixes IP respectifs constituent des ressources régionales et ne peuvent donc pas être transférées d'une région à une autre au sein d'OCI. De même, les préfixes BYOIP sont importés dans une région spécifique d'OCI, mais peuvent être transférés ultérieurement vers une autre région.

Une adresse IP attribuée à une ressource est accessible aux connexions entrantes provenant d'Internet si toutes les conditions suivantes sont remplies :

1. Il s'agit soit d'une adresse IPv6 (provenant d'un préfixe de type GUA BYOIPv6 ou d'un préfixe IPv6 Oracle GUA du VCN), soit d'une adresse IPv4 publique (provenant d'un préfixe BYOIPv4 ou attribuée par Oracle).
2. Elle est attribuée à une ressource/VNIC disposant d'une route vers la passerelle Internet du VCN dans la table de routage de son sous-réseau.
3. Elle est attribuée à une interface réseau virtuelle (VNIC) située dans un sous-réseau public
4. Il dispose de listes de sécurité, de NSG ou de règles ZPR autorisant la connectivité réseau

Quels sont les différents types d'adresses IPv4 publiques?

Il existe deux types d'adresses IPv4 publiques attribuées à vos ressources dans le VCN : les adresses éphémères et les adresses réservées.

• Les adresses IPv4 publiques éphémères sont essentiellement temporaires et n'existent que pendant la durée de vie de la ressource à laquelle elles sont attribuées.
  Vous ne pouvez pas sélectionner l'adresse IPv4 éphémère. Au lieu de cela, à votre demande, Oracle vous en attribuera une automatiquement à partir de son parc d'adresses IPv4 publiques disponibles. Cela ne peut pas provenir de vos préfixes BYOIPv4.
  Une adresse IPv4 publique éphémère est toujours liée au cycle de vie de l'adresse IPv4 privée d'une carte réseau virtuelle (VNIC) d'une instance ou d'une autre ressource réseau, telle qu'un équilibreur de charge (LB). Si vous désaffectez explicitement l'adresse IPv4 publique ou si vous mettez fin à la ressource correspondante (LB/NATGW, etc.), l'adresse IPv4 publique est réintégrée dans le pool OCI. Si vous demandez à nouveau une adresse IPv4 publique ultérieurement, il se peut que celle-ci soit différente de la précédente. Les adresses IPv4 publiques éphémères ne peuvent pas être transférées d'une interface réseau virtuelle (VNIC) ou d'une adresse IP à une autre.
• Les adresses IPv4 publiques réservées sont essentiellement des adresses IPv4 publiques « flottantes » qui se trouvent dans un compartiment et une région de votre choix. Elles sont persistantes et continuent d'exister au-delà de la durée de vie des ressources auxquelles elles sont associées. Vous pouvez laisser une adresse IPv4 publique réservée non attribuée au sein de votre compartiment, ou l'attribuer à une adresse IPv4 privée d'une instance ou d'un équilibreur de charge situé dans la même région que celle où elle a été créée. Vous pouvez également le déplacer vers n'importe quelle autre ressource de votre tenant, au sein de la même région. Les adresses IPv4 publiques réservées peuvent provenir du pool d'adresses IPv4 publiques mis à disposition par Oracle. Elles peuvent également provenir de votre pool d'adresses IPv4 publiques spécifique, dérivé de l'un de vos préfixes BYOIPv4.

Une adresse IPv4 publique, quel que soit son type, ne peut être associée qu'à une adresse IPv4 privée d'hôte attribuée à une ressource située dans un sous-réseau public d'un VCN. À l'exception d'une passerelle NAT (NATGW), l'association ou l'attribution d'une adresse IPv4 publique, quel que soit son type, correspond toujours à une adresse IPv4 privée. Un NATGW peut disposer d'une adresse IPv4 publique sans qu'aucune adresse IPv4 privée ne lui soit associée. Pour plus de détails et pour consulter un tableau comparatif des deux types, consultez la documentation sur les adresses IP publiques.

Quels sont les différents types d'adresses IPv6 publiques?

Une adresse IPv6 publique provient toujours de l'un des préfixes GUA IPv6 attribués à votre VCN. L'adresse IPv6 publique de votre ressource VCN proviendra toujours de l'un des deux types de préfixes GUA IPv6 suivants :

• Préfixe IPv6 GUA attribué par Oracle
• Votre préfixe GUA BYOIPv6 importé

Le préfixe IPv6 GUA attribué par Oracle à votre VCN reste associé à ce dernier jusqu'à ce que vous le supprimiez de la VCN ou que celle-ci soit supprimée. Si vous essayez de réattribuer un préfixe GUA appartenant à Oracle à ce VCN après sa suppression, la situation pourrait être différente. Par conséquent, la notion d'« éphémère » ne s'applique pas directement aux adresses IPv6 publiques individuelles. Cependant, vous pouvez faire réserver une adresse IPv6 individuelle, mais cette réservation s'applique toujours à un sous-réseau. Cela diffère des adresses IPv4 publiques, pour lesquelles une réservation est limitée à un espace de location. Les adresses IPv6 GUA réservées peuvent provenir d'un préfixe GUA appartenant à Oracle ou de votre préfixe GUA BYOIPv6 importé. Lorsqu'elle est attribuée à des ressources situées dans un sous-réseau privé d'un VCN, l'adresse IPv6 publique ne permet pas d'accéder à Internet. Pour plus d’informations, consultez Adresses IPv6.

Pourquoi ai-je besoin de réserver des 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 cas de figure spécifiques dans lesquels l'utilisation d'une adresse IP publique réservée peut s'avérer utile :

• Protéger les clients contre toute défaillance spécifique à une instance : Vous pouvez attribuer une adresse IP publique réservée à votre instance et la transférer de manière transparente 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 de calcul sans impact sur les utilisateurs : Que vous souhaitiez modifier la taille d'une instance ou mettre fin à vos instances en fonction de vos habitudes d'utilisation afin de réduire vos coûts, une adresse IP publique réservée vous permet de continuer à fournir la même adresse IP publique à vos clients.
• Liste blanche basée sur les adresses IP : Il arrive parfois que des points de terminaison publics externes imposent des contrôles d'accès basés sur des adresses IP statiques à des fins de sécurité. Cela implique que vous utilisiez systématiquement des adresses IP fixes tout au long du cycle de vie de votre architecture.

Combien d'adresses IPv4 publiques réservées puis-je attribuer à une instance?

Vous ne pouvez attribuer qu'une seule adresse IPv4 publique réservée à chaque adresse IPv4 privée principale ou secondaire d'une carte réseau virtuelle (VNIC). Cependant, vous pouvez attribuer plusieurs adresses IPv4 privées à chaque carte réseau virtuelle (VNIC) associée à votre instance. Vous pouvez ensuite attribuer ou associer une adresse IPv4 publique réservée à chacune de ces adresses IPv4 privées.

Le nombre maximal d'adresses IPv4 publiques réservées que vous pouvez créer dans votre environnement est limité. Pour plus d'informations, consultez la documentation sur les limites du service.

Combien d'adresses IPv4 publiques éphémères puis-je attribuer à une instance?

Vous ne pouvez attribuer qu'une seule adresse IPv4 publique éphémère à chaque adresse IPv4 privée principale de la VNIC. Toutefois, vous pouvez créer et joindre plusieurs cartes VNIC à votre instance. Vous pouvez ensuite attribuer une adresse IPv4 publique éphémère à l'adresse IPv4 privée principale de chaque VNIC. Il n'est pas possible d'attribuer une adresse IPv4 publique éphémère à une adresse IPv4 privée secondaire d'une VNIC.

Le nombre maximal d'adresses IPv4 publiques éphémères pouvant être attribuées à une instance est limité. Pour plus d'informations, consultez la documentation sur les limites du service.

Puis-je transférer une adresse IPv4 publique éphémère d'une VNIC/instance à une autre?

Non. Une adresse IPv4 publique éphémère ne peut être associée qu'à une adresse IPv4 privée principale de la VNIC. Une adresse IPv4 privée principale ne peut pas être transférée d'une interface réseau virtuelle (VNIC) à une autre; l'adresse IPv4 publique éphémère qui lui est associée ne peut pas non plus être transférée. Vous pouvez à tout moment associer ou dissocier l'adresse IPv4 publique éphémère à l'adresse IPv4 privée principale de la carte réseau virtuelle (VNIC) de l'instance.

Puis-je transférer une adresse IPv4 publique réservée d'une VNIC/instance vers une autre?

Oui, Vous pouvez le déplacer d'un domaine de disponibilité, d'un VCN ou d'un sous-réseau à un autre, mais uniquement au sein de la même région.

Il existe deux façons de transférer une adresse IPv4 publique réservée :

• Vous pouvez dissocier l'adresse IPv4 publique réservée de l'adresse IPv4 privée qui lui est associée, puis la réattribuer à une autre adresse IPv4 privée. L'adresse IPv4 privée nouvellement choisie peut se trouver sur une interface réseau virtuelle (VNIC) appartenant à un domaine de disponibilité ou à un réseau virtuel (VCN)/sous-réseau différent de celui de la VNIC d'origine. Notez que cette nouvelle interface réseau virtuelle (VNIC) doit se trouver dans le sous-réseau public.
• Si l'adresse IPv4 publique réservée est attribuée à une adresse IPv4 privée secondaire, vous pouvez déplacer cette adresse IPv4 privée vers une autre interface réseau virtuelle (VNIC) (qui doit se trouver dans le même sous-réseau public). Cette opération associe l'adresse IPv4 publique à la nouvelle interface réseau virtuelle (VNIC).

Quand une adresse IPv4 publique éphémère est-elle libérée?

Dans les cas suivants, l'adresse IPv4 publique éphémère attribuée à une ressource sera restituée au pool d'adresses IPv4 publiques d'OCI :

• Lorsque vous désassignez une adresse IPv4 publique éphémère d'une adresse IPv4 privée principale d'une VNIC, l'adresse IP publique éphémère correspondante est libérée.
• Lorsque vous déconnectez ou supprimez une interface réseau virtuelle secondaire (VNIC) d'une instance, toute adresse IPv4 publique éphémère associée sera libérée.
• Lorsque vous mettez fin à l'instance, toutes ses cartes réseau virtuelles (VNIC) sont également désactivées, y compris la carte réseau virtuelle principale. Ainsi, toutes les adresses IPv4 éphémères associées à chaque VNIC connectée sont également libérées. Notez que le redémarrage de l'instance n'a aucune incidence sur les adresses IPv4 publiques éphémères correspondantes.
• Lorsque vous supprimez la ressource associée à une adresse IPv4 publique éphémère (comme un LB, un NLB ou un NATGW), cette adresse IPv4 éphémère sera libérée.

Quelles adresses IP s'affichent lorsque je me connecte à mon instance de calcul?

Lorsque vous vous connectez à une instance, vous verrez, dans les interfaces réseau de votre système d'exploitation, toutes les adresses IP attribuées à leurs VNIC respectives, à l'exception des adresses IPv4 publiques.

Pour les adresses IPv4 publiques, le service réseau fournit une traduction NAT statique un-à-un au niveau de la passerelle Internet vers votre adresse IPv4 privée associée. Les adresses IPv6 GUA et ULA sont directement visibles sur la carte réseau du système d'exploitation. Il n'existe pas de NAT IPv6 statique de type « un-à-un » pour les adresses IPv6 publiques de la GUA.

Comment le trafic lié à une adresse IPv4 publique s'affiche-t-il sur l'instance?

Au niveau de l'instance du système d'exploitation, seules les adresses IPv4 privées de toutes les cartes réseau virtuelles (VNIC) associées à l'instance sont visibles. Pour tout trafic sortant à destination d'une adresse IPv4 publique externe, une passerelle Internet effectuera une traduction d'adresse source (NAT) un-à-un entre une adresse IPv4 privée de la VNIC et l'adresse IPv4 publique qui lui est associée. Pour tout trafic entrant provenant d'Internet et destiné à l'adresse IPv4 publique d'une VNIC, une passerelle Internet effectuera une traduction NAT de destination un-à-un entre l'adresse IPv4 publique de la VNIC et l'adresse IPv4 privée qui lui est associée. Par conséquent, du point de vue de votre instance, celle-ci communique avec une adresse IPv4 publique externe par l'intermédiaire d'une adresse IPv4 privée de sa carte réseau virtuelle (VNIC).

Puis-je affecter une adresse MAC à mon instance de calcul?

Non. Le service de mise en réseau OCI attribue l'adresse MAC à une interface réseau virtuelle (VNIC) d'une instance. Les utilisateurs ne peuvent ni l'attribuer lors de la création de la VNIC, ni le modifier par la suite.

IPv6 est-il pris en charge?

Oui, IPv6 est pris en charge. Pour plus d’informations, consultez Adresses IPv6.

Prenez-vous en charge la diffusion multiple d’IP ou la diffusion dans le réseau en nuage virtuel?

Non, pas actuellement.

Est-ce qu’un réseau en nuage virtuel prend en charge la prise de contrôle transparente au moyen de GARP?

Non, pas actuellement.

Peut-on réserver une adresse IPv4 privée?

Oui, La réservation d'une adresse IPv4 privée est limitée à un seul sous-réseau d'un seul VCN. Les adresses IPv4 privées réservées sont exclues de l'attribution automatique d'adresses IP par OCI lors de la création d'une nouvelle ressource dans le même sous-réseau. Cela vous permet de transférer de manière explicite et en toute sécurité l'adresse IPv4 réservée d'une ressource à une autre lors de scénarios de basculement. Ainsi, l'adresse IPv4 réservée fait office de point de terminaison privé stable pour vos services.

Peut-on réserver une adresse IPv6?

Oui, Une adresse IPv6 de n'importe quel type (GUA appartenant à Oracle, ULA ou GUA BYOIPv6) peut être réservée au niveau du sous-réseau. OCI ne prend pas en charge les adresses IPv6 publiques réservées à l'échelle de l'instance, contrairement à ce qu'il fait pour les adresses IPv4 publiques. Les adresses IPv6 réservées sont exclues de l'attribution automatique d'adresses IP par OCI lors de la création d'une nouvelle ressource au sein du même sous-réseau. Cela vous permet de transférer de manière explicite et en toute sécurité l'adresse IPv6 réservée d'une ressource à une autre lors de scénarios de basculement. Ainsi, l'adresse IPv6 réservée fait office de point de terminaison stable pour vos services.

Bring Your Own IP Address (BYOIP)

Qu’est-ce que la fonction Bring Your Own IP Address (BYOIP) ?

BYOIP vous permet d'importer dans Oracle Cloud Infrastructure des préfixes IP routables publiquement (blocs CIDR IPv4 ou préfixes GUA IPv6) dont vous êtes propriétaire (ou que vous louez). Une fois vos préfixes IP importés dans OCI, vos ressources OCI, comme les instances de calcul, les passerelles NAT (NATGW) et les équilibreurs de charge (LB), peuvent les utiliser.

Quels sont les avantages de la fonction BYOIP ?

Les adresses IP publiques constituent des actifs gérés et contrôlés avec soin par une organisation. Voici quelques raisons justifiant une gestion et un contrôle granulaires des adresses IP :

• Applications nécessitant une bonne réputation IP pour l'envoi de courriels
• Politiques de contrôle d'accès déjà définies
• Dépendances d'applications liées à des adresses IP spécifiques

La migration d’un préfixe IP d’une infrastructure sur site vers OCI vous permet de minimiser l’impact sur vos clients et vos applications tout en profitant de tous les avantages d’Oracle Cloud Infrastructure. BYOIP dans OCI vous permettra de minimiser les temps d’arrêt pendant la migration en annonçant simultanément votre préfixe d’adresse IP à OCI et en le retirant de l’environnement sur site.

Comment commencer avec BYOIP ?

Le préfixe IP que vous souhaitez importer dans OCI dans le cadre du service BYOIP doit répondre aux critères suivants :

1. Le préfixe ou la plage de réseau doit appartenir à votre organisation ou vous avoir été loué.
2. Pour un CIDR IPv4, il doit s'agir d'un /24 ou d'une taille supérieure. Un préfixe IPv6 doit être de type /48 ou supérieur.

La procédure de transfert d'un préfixe IP en vue de son utilisation dans OCI commence dans la console OCI, sous « Réseau » > « Gestion des adresses IP ». Elle peut également être lancée par l'API. À partir de là, il vous suffit de suivre les étapes suivantes :

1. Lancer la demande d'importation d'un préfixe IP vers OCI.
2. Enregistrez le jeton de validation généré à partir de la requête auprès du service du registre Internet régional (RIR) (ARIN, RIPE ou APNIC). Consultez la documentation pour plus de détails sur cette étape.
3. Une fois votre jeton enregistré, retournez dans la console OCI et cliquez sur Valider le bloc CIDR afin qu'Oracle puisse mener à bien le processus de validation. Oracle vérifie ensuite que votre préfixe IP a bien été enregistré pour le transfert, puis met en service votre service BYOIP. Cette étape peut prendre jusqu’à 10 jours ouvrables. Vous serez averti par courriel lorsque le processus est terminé. Vous pouvez également vérifier l’avancement de cette étape dans vos demandes de travaux.

Pour plus d'informations sur le processus d'importation, veuillez consulter la documentation de BYOIP.

Que dois-je faire avec le jeton de validation émis par Oracle?

Dans le cadre du processus d'importation de blocs CIDR BYOIP, Oracle vous fournira un jeton de validation. Une fois que vous aurez obtenu votre jeton, vous devrez le modifier légèrement en y ajoutant les informations indiquées ci-dessous. Vous pouvez utiliser n'importe quel éditeur de texte pour cette étape.

OCITOKEN:: <CIDRblock> : <validation_token>

En fonction de votre RIR, vous devez suivre la procédure suivante pour envoyer le jeton de validation :

Comment utiliser les adresses BYOIP avec les ressources OCI ? Quelles ressources OCI peuvent être utilisées avec un préfixe BYOIP?

Une fois le préfixe IP validé, vous en avez le contrôle total.

Pour le préfixe IPv6 BYOIP (BYOIPv6), les sous-préfixes sont attribués directement en tant que préfixes IPv6 à un VCN ou à un sous-réseau. Les adresses IPv6 issues des préfixes de sous-réseau peuvent ensuite être attribuées à des ressources au sein de votre VCN, comme des instances de calcul, des équilibreurs de charge réseau et des équilibreurs de charge.

Par conséquent, vous pouvez utiliser ces préfixes IP avec des ressources situées dans des VCN appartenant à la même région que celle où ces préfixes ont été importés.

Dois-je contrôler la publicité du préfixe BYOIP après son intégration ?

Une fois le préfixe IP intégré à OCI, c'est vous qui gérez sa publication et son retrait.

Combien de temps dure la validation et l’intégration BYOIP ?

La validation et le provisionnement de BYOIP peuvent prendre jusqu'à 10 jours ouvrables. Vous serez averti par courriel lorsque le processus est terminé.

Un préfixe BYOIP peut-il être déplacé entre les régions OCI ?

Non. Le préfixe BYOIP est attribué à une région OCI spécifique. De plus, elle ne sera annoncée sur Internet (par le BGP) que pour la région à laquelle elle est rattachée. Par conséquent, le trafic Internet destiné aux adresses IP du préfixe BYOIP sera acheminé vers la région OCI spécifique prévue pour son intégration. Cependant, vous pouvez supprimer le préfixe BYOIP intégré à une région OCI, puis le créer ou l'intégrer dans une autre région OCI, ce qui revient à déplacer votre préfixe BYOIP d'une région à l'autre.

Quels sont les préfixes de taille minimale et maximale que je peux utiliser pour BYOIP ?

Dans le cadre du BYOIP, le CIDR IPv4 doit être compris entre /24 au minimum et /8 au maximum. Un préfixe IPv6 doit être d'au moins /48 et d'au plus /8. Vous n'êtes pas obligé de transférer l'intégralité de votre espace IP vers OCI. Si vous possédez un bloc IP plus important, vous pouvez choisir les préfixes à apporter à OCI.

Comment puis-je répartir mon préfixe BYOIP en plages d'adresses IP?

Une fois votre préfixe IPv4 public intégré, vous gérez l'attribution des adresses et les règles au sein de votre environnement OCI. Vous pouvez conserver l'intégralité du préfixe IPv4 que vous avez importé dans un seul parc d'adresses IP, ou bien subdiviser ce préfixe en segments de type /28 et conserver chaque sous-préfixe dans son propre parc d'adresses IP. La taille minimale d'un bloc IPv4 pour les pools d'adresses IP peut être de /28. Les plages d'adresses IP publiques ne sont prises en charge que pour le protocole IPv4. Une adresse IPv4 publique issue de votre préfixe BYOIPv4 ne peut être utilisée qu'après avoir été intégrée à un bloc IPv4 d'un pool d'adresses IP. Les parcs d'adresses IP offrent un mécanisme d'organisation et de contrôle des politiques IAM pour vos préfixes IPv4 importés. Lorsque des adresses IPv4 publiques issues d'un parc d'adresses IP sont attribuées à une ressource, elles sont attribuées individuellement et non sous forme de CIDR. Par exemple, vous ne pouvez pas attribuer un CIDR issu du parc d'adresses IP comme préfixe à votre VCN.

Vos adresses IPv6 BYOIPv6 n'utilisent pas la fonctionnalité de parc d'adresses IP. Vous pouvez au contraire attribuer directement ces préfixes (ou leurs subdivisions) aux VCN et aux sous-réseaux. Les adresses IPv6 GUA issues de vos préfixes BYOIPv6 ne peuvent être attribuées à votre ressource que si le préfixe IPv6 qui les contient est attribué à leur VCN/sous-réseau parent.

Puis-je créer des adresses IP réservées à partir de mon préfixe BYOIP ?

Vous pouvez créer une adresse IPv4 publique réservée, au niveau d'une instance de location, à partir d'un pool d'adresses IPv4 issu d'un CIDR BYOIPv4.

Vous pouvez créer une adresse IPv6 publique réservée à partir d'un préfixe BYOIPv6 dès qu'une plage de sous-préfixes ::/64 issue de ce même préfixe BYOIPv6 a été attribuée à un sous-réseau. La réservation d'une adresse IPv6 publique s'effectue toujours au niveau du sous-réseau.

Puis-je continuer à utiliser les adresses IP éphémères et réservées appartenant à Oracle si j'apporte mon propre préfixe sur OCI?

Oui, Vous pouvez toujours utiliser les adresses IP éphémères et réservées appartenant à Oracle, ainsi que les adresses IP issues de vos propres plages BYOIP importées dans OCI. Les limites normales s'appliquent aux adresses appartenant à Oracle.

Les adresses IP issues des plages BYOIP peuvent-elles être utilisées comme adresses IP CIDR pour une interface réseau virtuelle (VNIC) d'une instance?

Les adresses IPv6 issues des préfixes BYOIPv6 peuvent être utilisées comme adresses IP CIDR pour les VNIC des instances, à condition que le préfixe IPv6 qui les contient soit attribué à un sous-réseau et à un VCN dans lesquels réside la VNIC.
Les adresses IPv4 publiques issues d'un bloc CIDR de tout type (BYOIP ou appartenant à Oracle) sont toujours attribuées individuellement à une ressource réseau (NLB/LB) ou à une interface réseau virtuelle (VNIC) d'une instance. Par conséquent, aucun sous-préfixe d'un pool IPv4 public ou d'un bloc CIDR BYOIPv4 ne peut être attribué en tant qu'adresse IP CIDR à une interface réseau virtuelle (VNIC) d'une instance.

Les ressources OCI dotées d'adresses IP publiques issues d'un préfixe BYOIP sont-elles accessibles via OCI FastConnect avec un appairage public?

Oui, vos ressources OCI dotées d'adresses IP publiques issues de votre préfixe BYOIPv4/6 sont accessibles via FastConnect grâce à un appairage public vers la même région que celle dans laquelle votre préfixe IP a été importé.

Connectivité

Quelles sont les options de connectivité disponibles pour les instances exécutées dans mon réseau en nuage virtuel?

Les instances peuvent se connecter à ce qui suit :

• Internet (par une passerelle Internet ou une passerelle NAT)
• Votre centre de données sur place utilisant une connexion VPN site à site OCI 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)
• Les services Oracle Cloud Infrastructure comme Object Storage ou Autonomous Data Warehouse (par une passerelle de service, des points de terminaison privés ou un accès privé au service)

Qu’est-ce qu’une passerelle Internet?

Une passerelle Internet est une passerelle définie par logiciel, hautement disponible et tolérante aux pannes, qui assure la connectivité à l'Internet public pour les ressources situées au sein de votre VCN. À 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.

Vous pouvez également connecter votre VCN à votre centre de données sur site à l'aide de FastConnect, ce qui vous permettra d'acheminer le trafic vers Internet par les points de sortie de votre réseau sur place existant. Cette option utilisera un espace d'adresses IP privées.

Qu’est-ce qu’une passerelle NAT?

Une passerelle NAT est une passerelle fiable et hautement disponible qui offre une connectivité Internet exclusivement sortante aux ressources situées au sein de votre VCN. Avec une passerelle NAT, les instances privées (disposant uniquement d'une adresse IP privée) peuvent établir des connexions vers des hôtes et des services sur Internet, mais ne peuvent pas recevoir de connexions entrantes provenant d'Internet. Veuillez noter qu'à l'heure actuelle, les passerelles NAT OCI ne peuvent disposer que d'une seule adresse IP publique et ne prennent en charge que les protocoles TCP (Transmission Control Protocol), UDP (User Datagram Protocol) et ICMP (Internet Control Message Protocol).

Puis-je avoir plus d’une passerelle NAT par réseau en nuage virtuel?

Non. La limite par défaut est d’une passerelle NAT par réseau en nuage virtuel. Cela devrait suffire pour la plupart des applications.
Si vous souhaitez attribuer plusieurs passerelles NAT dans un réseau virtuel (VCN) spécifique, vous pouvez demander une augmentation de la limite. Pour savoir comment demander une augmentation, consultez la documentation sur les limites du service.

Y a-t-il de nouvelles limites de débit lorsque vous utilisez une passerelle NAT?

Les instances obtiennent le même débit avec la passerelle NAT que lorsqu’elles sont acheminées par une passerelle Internet.

Y a-t-il une limite de connexions simultanées lors de l’utilisation d’une passerelle NAT?

Oui,

Le nombre de connexions simultanées vers une destination unique sur Internet est limité à environ 20 000 pour l'ensemble des clients d'un domaine Active Directory (AD) au sein d'une région OCI comptant trois domaines AD. Cette limite correspond au total de toutes les connexions établies par les instances du réseau virtuel (VCN) appartenant à un domaine Active Directory (AD) donné et utilisant la passerelle NAT de ce VCN. Pour une région OCI mono-AD, la limite est d'environ 65 000. Veuillez noter qu'ici, par « destination unique sur Internet », nous entendons une combinaison unique de l'adresse IP publique de la destination, le port de destination et le protocole.

Qu'est-ce qu'une passerelle de routage dynamique (DRG)?

Une passerelle de routage dynamique est un routeur virtuel défini par logiciel, hautement disponible et tolérant aux pannes, que vous pouvez associer à vos réseaux virtuels (VCN).

Il offre un chemin sécurisé pour les cas suivants :
- le trafic est-ouest entre un VCN et d’autres VCN situés dans la même région OCI
- le trafic est-ouest entre des VCN situés dans différentes régions OCI et connectés via un appairage à distance
- le trafic nord-sud entre des VCN et des réseaux sur site via Internet, à l’aide d’une connexion IPsec de site à site, ou via une ligne dédiée utilisant des circuits virtuels FastConnect

Ainsi, un DRG fait office de plaque tournante centrale capable de faciliter une communication sécurisée via un espace IP privé pour l'ensemble de votre réseau, y compris les VCN situés dans différentes régions OCI et vos réseaux sur site.

Qu’est-ce qu’un équipement de client sur place (CPE) et quelle est son utilité?

Vous utilisez cet objet lorsque vous configurez un VPN IPsec de site à site. Il s'agit d'une représentation virtuelle du routeur physique qui se trouve sur site, c'est-à-dire de votre côté du VPN. Lorsque vous créez cet objet dans le cadre de la configuration d'un VPN IPsec de site à site, vous devez indiquer l'adresse IP publique de votre routeur sur site.

Ai-je besoin d'une passerelle Internet pour mettre en place un VPN IPsec de site à site vers mon centre de données sur site?

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.

Quels routeurs ou passerelles installés chez le client avez-vous testés avec le VPN site à site OCI?

Consultez la liste des configurations d'appareils testées.

Je dispose d'un routeur VPN IPsec qui ne figure pas dans la liste ci-dessus des équipements testés. Puis-je utiliser ce routeur pour me connecter à mon réseau en nuage virtuel?

Oui, à condition que la configuration de votre CPE générique prenne en charge les paramètres IPsec de phase 1 et de phase 2 pris en charge par le service VPN IPsec site à site d'OCI. Consultez notre liste des paramètres pris en charge pour plus d'informations. Nous prenons en charge plusieurs options de configuration afin de maximiser l’interopérabilité avec les différents dispositifs de réseau privé virtuel.

Comment puis-je garantir la disponibilité de ma connexion VPN IPsec de site à site entre Oracle Cloud Infrastructure et mon centre de données sur place?

Oracle met en place deux tunnels VPN dans le cadre de la connexion IPsec. Les deux tunnels au sein d'une même connexion IPsec sont conçus pour être automatiquement redondants du côté OCI, chacun aboutissant à un périphérique VPN différent. 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 CPE dans votre centre de données sur site, chacun étant configuré pour deux tunnels.

Puis-je utiliser un réseau privé virtuel logiciel pour me connecter à mon réseau en nuage virtuel?

Le VPN IPsec est un protocole ouvert, basé sur des normes ; par conséquent, les VPN IPsec logiciels sont interopérables avec le service VPN site à site d'OCI. Vous devez vérifier que votre logiciel VPN IPsec prend en charge au moins un paramètre IPsec compatible avec le VPN site à site OCI dans chaque groupe de configuration, conformément à la configuration générique du CPE. Pour plus de détails, consultez la documentation sur les paramètres IPsec pris en charge.

Le trafic entre deux adresses IP publiques gérées par OCI reste-t-il au sein d'OCI?

Oui, Veuillez noter que les adresses IP publiques gérées par OCI comprennent à la fois les adresses IP publiques appartenant à Oracle et les adresses BYOIP des clients d'Oracle. Au sein d'un domaine OCI, le trafic entre les adresses IP publiques gérées par OCI reste toujours confiné à ce domaine OCI et ne transite pas par Internet. Cela vaut quelle que soit la passerelle VCN se trouvant sur le chemin du trafic.

Plus précisément, le trafic entre deux adresses IP publiques gérées par OCI dans une même région reste confiné à cette région OCI. En revanche, lorsque les adresses IP publiques se trouvent dans différentes régions OCI d'un même domaine, le trafic transite par un réseau fédérateur OCI privé de ce domaine. Pour en savoir plus sur le réseau fédérateur de l'OCI.

Bien entendu, le trafic entre une adresse IP publique gérée par OCI et une adresse IP privée au sein d'un VCN reste également confiné au domaine OCI.

La liste complète des adresses IP publiques de l'OCI est disponible ici : https://docs.oracle.com/en-us/iaas/tools/public_ip_ranges.json.

Accès privé aux services

Qu’est-ce que le réseau de services Oracle?

Oracle Services Network est un réseau conceptuel dans Oracle Cloud Infrastructure qui est réservé aux services Oracle. Le réseau comprend une liste de blocs CIDR publics spécifiques à chaque région, appartenant à Oracle. Chaque service du réseau Oracle Services Network expose un point de terminaison de service qui utilise des adresses IP publiques issues de la plage d'adresses IP réservée à ce réseau. La quasi-totalité des services Oracle sont disponibles sur ce réseau (voir la liste complète), et d'autres services viendront s'y ajouter à l'avenir, au fur et à mesure de leur déploiement sur OCI.

Qu’est-ce qu’une passerelle de service?

Une passerelle de service (SGW) permet aux ressources de votre VCN d'accéder, de manière privée et sécurisée, aux services Oracle du réseau Oracle Services Network, comme OCI Object Storage, Database, Monitoring, Identity, Logging, etc. Le trafic entre une instance du VCN et un service Oracle pris en charge utilise l'adresse IP privée de l'instance pour le routage; il transite par le réseau OCI et ne passe jamais par Internet. Tout comme la passerelle Internet ou la passerelle NAT, la passerelle de service est un périphérique virtuel hautement disponible et évolutif de manière dynamique. Avec SGW, les ressources de votre VCN ne peuvent accéder qu'au réseau Oracle Services Network et à aucun autre réseau, comme Internet. Avec SGW, vous pouvez également connecter vos ressources sur site aux services Oracle du réseau Oracle Services Network par le routage de transit.

Quels services d’Oracle Cloud Infrastructure puis-je accéder au moyen d’une passerelle de service?

La quasi-totalité des services PaaS ou SaaS d'OCI sont disponibles sur Oracle Services Network (OSN) et sont accessibles via une passerelle de services.

J’utilise actuellement une passerelle Internet ou une passerelle NAT pour accéder à un service Oracle, comme ADW. Comment puis-je utiliser la passerelle de service pour accéder au même point d’extrémité de service Oracle?

• Créez une passerelle de service pour le réseau en nuage virtuel.
• Mettez à jour le routage du VCN/sous-réseau afin de rediriger tout le trafic destiné aux services Oracle au sein du réseau Oracle Services Network via la passerelle de service, plutôt que via la passerelle Internet ou la passerelle NAT.
• Autoriser le trafic vers l'espace CIDR OSN à l'aide de SL/NSG.

Pour plus d'informations, consultez Accès au 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. Il se peut que vos applications aient encore besoin d'accéder à des points de terminaison publics, par exemple pour des mises à jour ou des correctifs. Assurez-vous de disposer d'une passerelle NAT ou d'un autre moyen d'accès à Internet, si nécessaire, au sein de votre VCN.

Qu’est-ce qu’une étiquette CIDR de service?

La passerelle de services utilise le concept d'étiquette CIDR de service, appelée « moniker », qui est une chaîne de caractères représentant l'ensemble des plages d'adresses IP publiques régionales associées au service ou au groupe de services. Par exemple, « OCI IAD Services » dans le réseau Oracle Services Network correspond aux blocs CIDR régionaux de ce réseau situés dans la zone 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 plus d'informations, consultez Accès aux services Oracle : Service Gateway.

Puis-je configurer la passerelle de service pour accéder aux services exécutés dans une autre région?

Non. SGW est un service régional. En d'autres termes, les ressources du VCN dotées d'une passerelle de service ne peuvent accéder qu'aux services OCI de cette région. Si un VCN situé dans une région OCI souhaite accéder à des services PaaS ou SaaS OCI dans une autre région, vous pouvez utiliser le routage de transit.

Puis-je autoriser l'accès à un service de stockage d'objets uniquement à partir de certains VCN ou sous-réseaux?

Oui, Vous pouvez utiliser les règles de sortie dans les groupes de sécurité SL/NSG pour contrôler quels sous-réseaux/VNIC ou ressources de votre VCN peuvent accéder à l'OSN ou, plus précisément, au service de stockage d'objets. Vous pouvez également utiliser la fonctionnalité Sources réseau d'OCI IAM.

Pour un exemple de politique IAM, consultez Accès au stockage d'objets : passerelle de service.

Puis-je avoir plusieurs passerelles de service dans mon réseau en nuage virtuel?

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

Puis-je utiliser une passerelle de service avec l’appairage de réseau en nuage virtuel?

Non, si deux VCN situés dans la même région sont appairés avec une passerelle d'appairage locale. Oui, lorsque les deux VCN situés dans la même région sont appairés avec un DRG et qu’un routage de transit est configuré pour un VCN avec un SGW. Oui, si deux VCN situés dans des régions différentes sont appairés avec deux DRG via des RPC et si le routage de transit est configuré pour un VCN avec un SGW.

Depuis mon réseau sur place, comment puis-je me connecter aux services OCI via une passerelle SGW associée à mon réseau virtuel (VCN)?

Oui, vous pouvez utiliser FastConnect ou le service VPN IPSec avec routage de transit pour le VCN central associé à un DRG. Pour plus d'informations, veuillez consulter la documentation Accès privé aux services Oracle.

Puis-je bénéficier d'un accès direct et dédié aux services OCI publics sur OSN, comme Fusion Apps, sans passer par Internet ni par un SGW?

Oui, Vous pouvez utiliser FastConnect en mode d'appairage public et connecter vos réseaux sur site aux services OCI sans passer par Internet, un SGW ou un DRG. Grâce à l'appairage public FastConnect vers une région, votre réseau sur site bénéficie d'une connectivité dédiée à toutes les adresses IP publiques gérées par OCI au sein de cette région. Pour plus d'informations, veuillez consulter la documentation FastConnect.

Y a-t-il de nouvelles limites de débit lorsque vous utilisez une passerelle de service?

Non. Les instances bénéficient du même débit avec la passerelle de service que lorsque le trafic est acheminé via une passerelle Internet. Un SGW est un parc de serveurs à évolutivité horizontale et à haute disponibilité dans chaque région OCI.

Combien coûte la passerelle de service?

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

Quelles sont les différences entre les trois méthodes d'accès privé aux services OCI : OCI Service Gateway, OCI Private Endpoint et OCI Private Service Access?

Ces trois méthodes d'accès privé ne nécessitent pas de connexion Internet depuis votre VCN pour accéder aux services OCI; par conséquent, le trafic ne transite jamais par Internet. Ces trois méthodes d'accès privé sont régionales et s'inscrivent au niveau d'un VCN.

Consultez le tableau ci-dessous pour une comparaison détaillée de chaque méthode d'accès privé.

Ces trois méthodes d'accès privé peuvent-elles coexister au sein d'un même VCN?

Oui,

Quelles sont les recommandations à suivre pour choisir la méthode appropriée d'accès privé aux services OCI?

D'une manière générale :

Accès au service privé OCI : À utiliser lorsque vous avez besoin d'un accès privé sans modification du code ni recours à des adresses IP publiques, que vous souhaitez bénéficier des fonctionnalités de sécurité ZPR et que vous avez besoin de statistiques sur le trafic.

Points de terminaison privés OCI : Cette option est particulièrement adaptée lorsque vous devez limiter l'accès à des compartiments spécifiques ou à des ressources/instances propres à un service (par exemple, un espace de noms ou un compartiment de stockage d'objets, OCI Streams) pour certains clients ; elle est idéale pour un contrôle précis et l'utilisation de noms de domaine complets (FQDN) dédiés.

Passerelle de services OCI : À utiliser lorsque vous avez besoin d'une bande passante plus élevée ou d'un accès simple et étendu aux services OCI, avec une granularité moindre et moins de contrôles de sécurité.

Sécurité VCN

Que sont les listes de sécurité et quelle est leur utilité?

Une liste de sécurité définit les politiques de sécurité permettant de contrôler le trafic entrant et sortant des instances de calcul ou d'autres ressources réseau hébergées dans les réseaux virtuels OCI (VCN). Chaque liste de sécurité appartient à un VCN et peut être appliquée à un ou plusieurs sous-réseaux au sein de ce VCN. Une fois appliquée, la liste de sécurité impose ses règles à toutes les interfaces réseau virtuelles (VNIC) du sous-réseau, autorisant ou refusant le trafic au niveau de chaque VNIC.

Une liste de sécurité est constituée de règles d'entrée et de sortie qui régissent le trafic entrant et sortant des VNIC dans les sous-réseaux. Chaque règle définit des critères de correspondance, comme les adresses IP CIDR source ou destination, les protocoles IP et les ports source ou destination. Les règles d'entrée définissent les critères applicables au trafic entrant (CIDR de l'adresse IP source, protocole IP, ports source et de destination), tandis que les règles de sortie définissent les critères applicables au trafic sortant (CIDR de l'adresse IP de destination, protocole IP, ports source et de destination).

À l'heure actuelle, les listes de sécurité OCI ne prennent en charge que les règles d'autorisation. Par défaut, tout trafic est bloqué, sauf s'il est explicitement autorisé par une règle, ce qui permet d'appliquer une politique de sécurité fondée sur une liste blanche.

Quelles listes de sécurité s’appliquent à une instance donnée? En quoi consiste la liste de sécurité par défaut d’un réseau en nuage virtuel?

Les cartes réseau virtuelles (VNIC) des instances de calcul et les ressources réseau — comme les équilibreurs de charge réseau, les équilibreurs de charge en tant que service, les pare-feu de nouvelle génération ou les points de terminaison privés — sont soumises aux listes de sécurité associées au sous-réseau dans lequel elles sont déployées.

Chaque VCN dispose d'une liste de sécurité par défaut, et les clients peuvent créer des listes de sécurité supplémentaires selon leurs besoins. Un sous-réseau peut être associé à plusieurs listes de sécurité, mais doit en comporter au moins une. Lors de la création d'un sous-réseau, vous pouvez indiquer les listes de sécurité à lui associer. Si vous ne spécifiez aucune liste de sécurité lors de la création du sous-réseau, la liste de sécurité par défaut du VCN sera automatiquement associée à ce sous-réseau.

Les listes de sécurité sont appliquées au niveau du sous-réseau, mais leurs règles sont mises en œuvre au niveau de la carte réseau virtuelle (VNIC).

Puis-je modifier les listes de sécurité utilisées par mon sous-réseau après avoir créé le sous-réseau?

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é.

Combien de listes de sécurité et de règles puis-je configurer?

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 obtenir des instructions sur la manière de demander une augmentation de ces limites, consultez la documentation relative aux limites de service.

Puis-je utiliser les règles de type « deny » (refus) dans les listes de garanties?

Non. Les listes de sécurité n’utilisent que des règles d’autorisation. Par défaut, tout trafic est bloqué. Seul le trafic réseau correspondant aux attributs spécifiés dans les règles est autorisé.

Quels types de règles sont pris en charge dans les listes de sécurité?

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, dès qu'un paquet réseau correspondant à la règle est autorisé, le suivi de connexion est activé et tous les paquets réseau suivants appartenant à cette connexion seront automatiquement autorisés. Si vous créez une règle d'Ingress avec état, le trafic entrant correspondant à cette règle ainsi que le trafic sortant (réponse) correspondant seront tous deux autorisés.

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

Pour plus d'informations, consultez la documentation d'aide sur les listes de sécurité.

Que sont les groupes de sécurité réseau et en quoi sont-ils différents des listes de sécurité?

Les groupes de sécurité réseau et les listes de sécurité constituent deux méthodes distinctes pour mettre en œuvre des règles de sécurité, c'est-à-dire des règles qui contrôlent le trafic entrant et sortant autorisé vers et depuis les VNIC.

Les listes de sécurité vous permettent de définir un ensemble de règles de sécurité qui s'appliquent à toutes les interfaces réseau virtuelles (VNIC) d'un sous-réseau donné. Les groupes de sécurité réseau (NSG) vous permettent de définir un ensemble de règles de sécurité qui s'appliquent à un groupe de VNIC de votre choix, comme un groupe d'instances de calcul présentant le même niveau de sécurité. Les groupes de sécurité réseau et les listes de sécurité sont tous deux des ressources propres à un VCN.

Pour plus d'informations, consultez la documentation suivante :

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

Y a-t-il un ordre ou une priorité des règles de sécurité dans les groupes de sécurité réseau par rapport aux listes de sécurité?

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é applicables à tous les groupes NSG dont fait partie le VNIC

Quels services Oracle sont pris charge pour l’utilisation des groupes de sécurité réseau?

Les cartes réseau virtuelles (VNIC) des instances de calcul, les équilibreurs de charge réseau (NLB), les équilibreurs de charge en tant que service (LBaaS), les pare-feu de nouvelle génération, les passerelles API, les services de streaming et les services de base de données peuvent tous être associés à des groupes de sécurité réseau (NSG). Lorsque vous provisionnez ces ressources dans votre VCN, vous pouvez spécifier un ou plusieurs groupes de sécurité de réseau (NSG) du VCN afin de contrôler le trafic entrant et sortant de ces ressources.

Les points de terminaison privés d'un VCN correspondent aux services OCI pour lesquels ils sont déployés. À chaque point de terminaison privé est attribuée une interface réseau virtuelle (VNIC) au sein du sous-réseau VCN. Tout comme les VNIC des instances de calcul, ces VNIC de points de terminaison privés prennent également en charge l'association avec des groupes de sécurité (NSG).

Avec l'introduction de la fonctionnalité NSG, avons-nous besoin d'une liste de sécurité?

La fonctionnalité des listes de sécurité reste inchangée avec l'introduction des NSG. Les NSG et les listes de sécurité s'appliquent à des portées différentes et offrent des niveaux de granularité variables. En fonction des exigences de votre politique de sécurité, vous pouvez utiliser l'une ou l'autre, ou les deux à la fois.

Les listes de sécurité s'appliquent aux sous-réseaux. Toutes les adresses VNIC et toutes les ressources réseau d'un sous-réseau sont soumises aux règles définies dans les listes de sécurité associées. Utilisez les listes de sécurité pour définir des politiques de sécurité communes qui doivent s'appliquer à chaque VNIC ou ressource au sein d'un sous-réseau.

Les NSG, quant à elles, s'appliquent directement aux VNIC ou à des ressources spécifiques, offrant ainsi un contrôle plus fin. Les groupes de sécurité (NSG) vous permettent de définir et d'attribuer des politiques de sécurité distinctes à des ressources individuelles au sein d'un même sous-réseau, ou de réutiliser le même groupe de sécurité pour des ressources situées dans différents sous-réseaux. Cela vous permet de dissocier les politiques de sécurité des limites des sous-réseaux.

Une meilleure pratique consiste à utiliser des listes de sécurité pour les politiques générales qui s'appliquent à des sous-réseaux entiers, et des groupes de sécurité réseau (NSG) pour un contrôle d'accès détaillé et spécifique aux ressources.

Les listes de sécurité et les NSG s'appliquent de manière cumulative lors de l'application des règles sur une interface réseau virtuelle (VNIC) ou une ressource spécifique. Pour une VNIC ou une ressource donnée, le trafic est autorisé s'il correspond à une règle figurant soit dans la ou les listes de sécurité du sous-réseau, soit dans le ou les NSG attribués à la ressource. Étant donné que ces deux mécanismes ne prennent en charge que les règles d'autorisation, le trafic est refusé par défaut, sauf s'il est explicitement autorisé par au moins une règle dans l'un ou l'autre de ces types de politique.

Pouvons-nous définir un groupe de sécurité réseau à titre de source ou de destination pour les règles de sécurité?

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 deux NSG doivent se trouver dans le même VCN.

Puis-je rédiger des règles de sécurité qui contrôlent explicitement le trafic entre les groupes de sécurité réseau dans différents réseaux en nuage virtuels?

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 reste vrai même si l'autre NSG se trouve dans un VCN en appairage.

Les listes de sécurité vous permettent de définir un ensemble de règles de sécurité qui s'appliquent à toutes les interfaces réseau virtuelles (VNIC) d'un sous-réseau entier, tandis que les groupes de sécurité réseau (NSG) vous permettent de définir un ensemble de règles de sécurité qui s'appliquent à un groupe de VNIC de votre choix (y compris les VNIC des équilibreurs de charge ou des systèmes de bases de données) au sein d'un réseau virtuel (VCN).

Existe-t-il des limites au suivi des connexions pour les règles de sécurité des groupes de sécurité réseau (NSG) et des listes de sécurité?

Oui, Les limites de suivi des connexions (ou la taille de la table conntrack) d'une instance de calcul dépendent de sa configuration, comme indiqué dans cette table de suivi des connexions.

Comment le ZPR empêche-t-il les mouvements latéraux si une ressource est compromise?

La solution OCI Zero Trust Packet Routing (ZPR) empêche les mouvements latéraux en dissociant la sécurité de la topologie du réseau grâce à des attributs de sécurité.

Dans un réseau traditionnel, si un pirate parvient à prendre le contrôle d'une adresse IP, il peut s'en servir comme point d'appui pour accéder à n'importe quelle autre adresse IP autorisée par le pare-feu. ZPR évite ce problème en utilisant des attributs de sécurité (par exemple, app : database ou env : production).
Logique de la politique : Au lieu de dire « Autoriser 10.0.0.5 à communiquer avec 10.0.0.10 », une politique ZPR stipule : « Dans le VCN-A, autoriser « app: web-server » à se connecter à « app: database » sur le port 1521 ».
Application : Étant donné que l'infrastructure réseau d'OCI associe à chaque paquet l'attribut d'identité/sécurité de la source, même si l'attaquant modifie son adresse IP ou si l'architecture réseau change, le paquet sera rejeté car il ne dispose pas de l'attribut de sécurité requis. Cela permet de garantir que seules les identités autorisées puissent communiquer, quel que soit leur emplacement sur le réseau.
Étant donné que les constructions ZPR s'appliquent à plusieurs VCN interconnectés et sont basées sur l'intention, le ZPR contribue à réduire les erreurs de configuration susceptibles de se produire dans les déploiements de réseaux à grande échelle.

Qu'advient-il du trafic existant lorsque j'applique l'attribut de sécurité d'un ZPR à une ressource?

Le trafic est immédiatement bloqué en raison du comportement implicite par défaut de ZPR, à savoir « Refuser TOUT ». Dès que vous appliquez un attribut de sécurité à une ressource (comme une base de données autonome ou une instance de calcul), cette ressource passe en mode protégé par ZPR. Même si vos listes de sécurité et vos groupes de sécurité de nom (NSG) autorisent tout le trafic, toutes les communications seront interrompues jusqu'à ce que vous rédigiez et déployiez une politique ZPR explicite autorisant le chemin ou le flux de trafic spécifique.

Quelles sont toutes les listes de contrôle de sécurité pour une VNIC?

Pour qu'un paquet puisse parvenir de la carte réseau virtuelle source S à la carte réseau virtuelle de destination D au sein d'un réseau virtuel de l'OCI, les trois conditions suivantes doivent être remplies :

1. Sortie autorisée : Autorisée par au moins une règle de sécurité pour la sortie, soit dans les listes de sécurité d'un sous-réseau de la carte réseau virtuelle S, soit dans les groupes de sécurité réseau (NSG) de la carte réseau virtuelle S (uniquement si des NSG s'appliquent à S).
2. Autorisation d'entrée : Autorisé par au moins une règle de sécurité pour l'entrée, soit dans les listes de sécurité d'un sous-réseau de la carte réseau virtuelle (VNIC) D, soit dans les groupes de sécurité réseau (NSG) de la carte réseau virtuelle (VNIC) D (uniquement si des groupes de sécurité réseau sont appliqués à D).
3. Autorisation ZPR (uniquement si cette fonctionnalité est activée) : Si l'une des interfaces réseau virtuelles (VNIC) S ou D est marquée ZPR, le trafic doit également être autorisé par une politique ZPR.

De plus, vous pouvez également disposer d'un pare-feu réseau OCI ou d'un pare-feu d'applications Web OCI pour mettre en œuvre des mesures de sécurité plus variées. Pour plus de détails, consultez la documentation.

Routage VCN

Dans quel contexte peut-on appliquer une table de routage VCN?

Une table de routage VCN peut être appliquée à un sous-réseau, à une carte réseau virtuelle (VNIC) ou à une passerelle associée au VCN (passerelle Internet, passerelle NAT, passerelle d’appairage locale, passerelle de service ou DRG). Lorsqu'elle est associée à un sous-réseau ou à une interface réseau virtuelle (VNIC), la table de routage détermine la manière dont le trafic provenant de ce sous-réseau ou de cette interface est acheminé vers l'extérieur du sous-réseau. Lorsqu'il est associé à une passerelle, il gère le routage entrant, c'est-à-dire la manière dont la passerelle achemine le trafic provenant de l'extérieur vers le VCN.

Les VNIC étant déployées au sein de sous-réseaux, il existe une relation hiérarchique entre les tables de routage appliquées à une VNIC et celles appliquées à son sous-réseau. Si une interface réseau virtuelle (VNIC) dispose de sa propre table de routage VCN, elle utilise cette table pour contrôler le routage sortant. Si une interface réseau virtuelle (VNIC) ne dispose pas d'une table de routage dédiée, elle utilise par défaut la table de routage du sous-réseau pour contrôler le trafic sortant. Par défaut, les VNIC ne disposent pas de table de routage associée et héritent donc de celle du sous-réseau pour le contrôle du routage. Pour plus d'informations, consultez Tables de routage VCN.

Puis-je créer des règles de routage personnalisées dans une table de routage de sous-réseau pour le trafic dont la destination se trouve au sein du même sous-réseau?

Non, les règles de routage personnalisées pour le routage intra-sous-réseau ne sont pas prises en charge sur OCI. Le trafic au sein d'un sous-réseau est toujours acheminé directement vers sa destination. Par conséquent, les règles de routage vers des destinations situées au sein du sous-réseau ne sont pas autorisées dans la table de routage du sous-réseau.

Puis-je modifier la table de routage utilisée par mon sous-réseau après avoir créé le sous-réseau?

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 de la table de routage du sous-réseau.

Le réseau en nuage virtuel prend-il en charge l’acheminement basé sur la source?

Non, pas actuellement. Cependant, OCI prend actuellement en charge une fonctionnalité similaire appelée routage par ressource.

Combien de règles de routage puis-je créer dans une seule table de routage?

Il y a une limite au nombre de règles dans une table de routage. Pour plus d'informations, consultez la documentation sur les limites du service.

Puis-je utiliser une adresse IP privée comme cible de routage dans la règle de routage du réseau en nuage virtuel?

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 consulter les exigences et autres détails, consultez Utilisation d’une adresse IP privée comme cible de routage.

Qu'est-ce qu'une table de routage d'entrée de passerelle?

Une table de routage d'entrée de passerelle est une table de routage VCN associée à une passerelle spécifique. Il détermine la manière dont le trafic entrant dans le VCN via cette passerelle est acheminé vers le saut suivant dès son arrivée à cette passerelle. Par conséquent, elle n'est utilisée que pour le trafic entrant qui arrive dans le VCN par cette passerelle, et non pour le trafic provenant de l'intérieur du VCN.

Les tables de routage d'entrée des passerelles permettent les deux cas d'utilisation avancés suivants en matière de routage de transit :

1. De passerelle à passerelle : Cela fait référence aux cas d'utilisation dans lesquels le trafic doit transiter directement d'une passerelle d'un VCN vers une autre passerelle du même VCN, contournant ainsi les VNIC et les adresses IP au sein de ce VCN. Selon le type de passerelle, certaines restrictions s'appliquent. Pour plus d'informations, consultez le document « Learn Routing in OCI ».
2. Redirection : Cela concerne les cas d'utilisation dans lesquels le trafic doit transiter par une adresse IP privée du VCN, comme celle d'un appareil réseau virtuel (pare-feu, routeur virtuel, etc.) ou par l'OCI Flexible Network Load Balancer.

Pour plus d'informations, consultez la documentation sur les itinéraires de transport en commun.

Qu'est-ce que le routage par ressource?

Le routage par ressource est une fonctionnalité du réseau virtuel OCI qui vous permet d'attribuer une table de routage VCN personnalisée à une carte réseau virtuelle (VNIC) spécifique d'une instance de calcul ou à une adresse IP spécifique sur une carte réseau virtuelle (VNIC) d'une instance de calcul.

Ce faisant, il permet d'exercer le contrôle précis nécessaire dans les configurations très sophistiquées. En savoir plus sur le routage par ressource.

Quelles sont les destinations prises en charge (ou les sauts suivants) pour les règles de routage de la table de routage d'un sous-réseau?

En ce qui concerne les règles de routage de la table de routage d'un sous-réseau, les sauts suivants possibles peuvent être l'un des éléments suivants :

• Une passerelle (DRG, LPG, NATGW, etc.) associée au même VCN, acheminant ainsi le trafic vers l'extérieur du VCN
• Une adresse IP privée située dans le même VCN

Quelles sont les destinations prises en charge (ou les sauts suivants) pour les règles de routage des tables de routage d'entrée des passerelles?

• Une autre passerelle associée au même VCN
• Une adresse IP privée d'une interface réseau virtuelle (VNIC) (pouvant appartenir à une instance ou à un NLB) située dans le même réseau virtuel (VCN)

Selon le type de passerelle, certaines restrictions s'appliquent. Pour plus d'informations, consultez « Apprendre le routage dans OCI » (PDF).

Faut-il définir des règles de routage pour le trafic intra-VCN?

Chaque table de routage VCN comprend une règle de routage locale implicite pour le CIDR du VCN, qui achemine directement le trafic vers des destinations situées au sein du VCN. Par conséquent, vous n'avez pas besoin de créer de règles de routage supplémentaires pour le trafic intra-VCN si le routage local par défaut répond à vos besoins.

Cependant, vous pouvez préférer définir des règles de routage personnalisées afin de rediriger le trafic via un nœud intermédiaire, comme un pare-feu ou un équilibreur de charge. Cette fonctionnalité est prise en charge pour le trafic intra-VCN entre deux sous-réseaux, c'est-à-dire lorsque la destination se trouve dans un sous-réseau différent de celui de la source. Dans ce cas, vous pouvez ajouter des règles de routage à la table de routage du sous-réseau source, en spécifiant comme destination le saut intermédiaire souhaité (par exemple, l'adresse IP privée d'un pare-feu dans le VCN).

Il convient de noter que, pour le trafic intra-VCN au sein d'un même sous-réseau, celui-ci est toujours acheminé directement vers sa destination. Les règles de routage personnalisées ne sont pas prises en charge dans ce scénario. Pour plus d'informations, consultez Tables de routage VCN.

Appairage VCN

Qu’est-ce que l’appairage de réseaux en nuage virtuels?

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 VCN local (ou appairage intra-régional) : Les deux VCN se trouvent dans la même région. Ils peuvent être dans la même entité (dans le même compartiment ou dans des compartiments différents), ou dans des entités différentes. L'appairage VCN local peut être mis en place à l'aide d'une passerelle d'appairage locale (LPG) ou d'une passerelle de routage dynamique (DRG).
• Appairage VCN à distance (ou appairage VCN interrégional) : Les deux VCN se trouvent dans des régions différentes. Ils peuvent faire partie du même bail (dans des compartiments identiques ou différents), voire de baux différents. L'appairage VCN à distance est configuré avec un DRG par sa fonctionnalité d'appairage à distance (RPC).

Pour plus d'informations, voir Accès à d'autres réseaux en nuage virtuels : appairage.

Le service d’appairage de réseaux en nuage virtuels est-il pris en charge dans toutes les régions?

• L'appairage VCN local (avec LPG ou DRG) est pris en charge dans toutes les régions et tous les domaines.
• L'appairage VCN à distance (avec DRG) est pris en charge dans toutes les régions et tous les domaines.

Pourquoi ai-je besoin d’un appairage de réseaux en nuage virtuels?

• Grâce au appairage VCN local, vous bénéficiez de la flexibilité nécessaire pour organiser vos ressources en VCN distincts et respecter les exigences en matière de gouvernance et de présence régionale, tout en assurant une connectivité privée entre ces VCN. Grâce à l’appairage entre réseaux VCN locaux inter-locataires, vous pouvez organiser vos ressources en réseaux VCN distincts au sein de différents locataires, tout en assurant une connectivité privée entre ces réseaux VCN. Vous pouvez également activer un modèle de fournisseur de services en accordant un accès privé à vos services à plusieurs réseaux virtuels (VCN) de clients (appartenant à différents locataires) situés dans la même région.
• Grâce au appairage VCN à distance, vous pouvez organiser vos ressources en VCN distincts et répondre à vos besoins en matière de gouvernance, de présence multirégionale et de reprise après sinistre, tout en assurant une connectivité privée entre ces VCN situés dans différentes régions.

Quels sont les avantages de l’appairage de réseaux en nuage virtuels local?

L'appairage VCN local offre les avantages suivants :

• Une alternative gratuite et fiable aux modèles de connectivité comme le VPN, obtenue en supprimant les passerelles Internet, les adresses IP publiques pour les instances, le chiffrement et les goulots d'étranglement au niveau des performances
• 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 des réseaux virtuels (VCN) en appairage, grâce aux liaisons hautement redondantes offrant une bande passante et une latence prévisibles, propres à l'infrastructure réseau OCI.

Puis-je établir un appairage à distance (RPC) entre deux DRG situés dans la même région?

Dans la quasi-totalité des cas, toutes les extensions situées dans une même région peuvent être rattachées à un seul DRG amélioré afin d'assurer leur interconnectivité, ce qui évite l'appairage de deux DRG au sein de la même région.

Cependant, vous pouvez utiliser un appairage à distance entre deux DRG situés dans la même région. Cela peut s'avérer utile dans certains cas administratifs exceptionnels. Parmi ces scénarios, on peut citer :

• Vous disposez déjà de plusieurs VCN sur deux DRG distincts au sein d'une même région, et vous avez désormais besoin d'une interconnectivité sans interruption de service pour vos charges de travail existantes.
• Vous disposez déjà de deux réseaux sur deux DRG différents au sein d'une même région et vous devez désormais connecter ces réseaux tout en contrôlant la répartition des routes entre eux. À cette fin, vous devriez appliquer des politiques de répartition des routes d'importation plus restrictives aux DRG situés de part et d'autre du RPC.
• Les réseaux de chaque DRG doivent relever de la gestion des accès IAM de différentes équipes d'administration réseau.

Puis-je établir l’appairage local entre deux réseaux en nuage virtuels avec des plages d’adresses qui se chevauchent?

Lorsqu'ils sont en appairage local avec un LPG, deux VCN ne peuvent pas avoir de plages d'adresses (préfixes IP) qui se chevauchent. De plus, une fois que deux VCN sont appairés à un LPG, vous ne pouvez plus ajouter de nouveaux préfixes IP à l'un des VCN appairés qui pourraient entrer en chevauchement avec ceux d'un autre VCN.
En revanche, deux VCN effectuant un appairage local avec un DRG peuvent avoir des préfixes IP qui se chevauchent. Cependant, bien que cela soit autorisé, cela peut entraîner des conflits d'itinéraires et n'est donc pas recommandé.

Puis-je établir un appairage local de mon réseau en nuage virtuel à deux autres réseaux en nuage virtuels dont les plages d’adresses IP se chevauchent?

Oui, Si votre VCN est appairé à deux autres VCN via des LPG, ces deux VCN peuvent avoir des plages CIDR IP qui se chevauchent.

Combien d’appairages locaux puis-je établir par réseau en nuage virtuel?

Un VCN donné peut avoir au maximum 10 appairages locaux à la fois lorsqu'il utilise un LPG. Un VCN donné peut avoir au maximum 300 appairages locaux simultanés lorsqu'il utilise un DRG.

Quels sont les avantages d’un appairage de réseaux en nuage virtuels à distance?

L'appairage VCN à distance offre les avantages suivants :

• Une alternative économique et fiable aux modèles de connectivité comme le VPN, obtenue en supprimant les passerelles Internet, les adresses IP publiques pour les instances, le chiffrement et les goulots d'étranglement au niveau des performances
• 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 des réseaux virtuels (VCN) en appairage, grâce aux liaisons de dorsale hautement redondantes d'OCI, offrant une bande passante et une latence prévisibles

Ai-je besoin d’une passerelle Internet pour créer une connexion d’appairage à distance?

Non. Vous établissez un appairage à distance entre deux passerelles de routage dynamique. Les VCN connectés à chacun de ces DRG peuvent communiquer entre eux via le réseau fédérateur OCI grâce à cet appairage à distance.

Comment puis-je établir un appairage de réseaux en nuage virtuels à distance entre deux réseaux en nuage virtuels?

Pour plus d'informations, consultez Appairage VCN à distance.

Puis-je établir l’appairage distance entre deux réseaux en nuage virtuels avec des plages d’adresses qui se chevauchent?

Deux réseaux VCN établissant un appairage avec des DRG par une connexion d'appairage à distance peuvent avoir des préfixes IP qui se chevauchent. Cependant, bien que cela soit autorisé, cela peut entraîner des conflits d'itinéraires et n'est donc pas recommandé.

Puis-je établir un appairage à distance de mon réseau en nuage virtuel à deux autres réseaux en nuage virtuels dont les plages d’adresses IP se chevauchent?

Oui, si votre VCN est en appairage à distance avec deux autres VCN via un DRG, ces deux VCN peuvent avoir des préfixes IP qui se chevauchent. Cependant, cela peut entraîner des conflits d'itinéraires et n'est donc pas recommandé.

Puis-je établir une connexion d’appairage à distance à un réseau en nuage virtuel qui appartient à un autre compte?

Oui, Pour plus d'informations, consultez L'appairage VCN à distance via un DRG mis à niveau et La connexion à des VCN dans d'autres locataires.

Le trafic de l’appairage de réseaux en nuage virtuels à distance est-il chiffré?

Oui, Lorsque vous connectez deux VCN situés dans deux régions différentes à l'aide d'un RPC, toutes les communications entre ces deux VCN transitent par le réseau fédérateur d'OCI. Ces communications sont sécurisées par le protocole de chiffrement MACsec, norme de référence du secteur, qui contribue à garantir la confidentialité de toutes les transactions entre les centres de données Oracle. Grâce à ce niveau de chiffrement, vos données sont protégées lors de leur transit sur le réseau fédérateur. Lorsque vous connectez deux VCN situés dans la même région via un appairage local ou à l'aide d'un RPC, toutes les communications restent au sein de la région. Il n'utilise pas le réseau fédérateur OCI et n'est pas chiffré au niveau de la couche de liaison.

En tant qu'administrateur du VCN-A, puis-je limiter la connectivité à un sous-réseau spécifique du VCN-B lors de l'appairage?

Oui, Vous pouvez utiliser les tables de routage du VCN-A et différents mécanismes de sécurité (SL, NSG, ZPR, par exemple) pour contrôler la connectivité avec le VCN-B avec lequel il est en appairage. Vous pouvez permettre la connectivité à la plage d’adresses complète de VCN-B ou la limiter à un ou à plusieurs sous-réseaux.

Que ce soit dans le cadre d'un appairage local ou distant, quelles que soient les passerelles utilisées pour l'appairage, les tables de routage des sous-réseaux de n'importe quel VCN ne sont pas mises à jour automatiquement. Vous devez créer des routes statiques dans les tables de routage des sous-réseaux de chaque VCN pour le trafic à destination d'autres VCN en appairage. Vous devrez donc de toute façon mettre à jour les tables de routage de VCN-A, et vous pourrez alors limiter l'accès à certains sous-réseaux spécifiques de VCB-B.

Il va sans dire que, dans le même ordre d'idées, l'administrateur du VCN-B peut contrôler la connectivité avec le VCN-A.

Y a-t-il une incidence sur la performance concernant le débit et la latence en ce qui concerne l’appairage local établi entre deux réseaux en nuage virtuels?

Non. Le débit et le temps d’attente s’approchent de ceux des connexions entre réseaux en nuage virtuels. Le trafic transitant par l'appairage local est soumis à des contraintes de disponibilité et de bande passante similaires à celles du trafic entre les instances d'un VCN.

Comment puis-je mesurer la latence entre des VCN situés dans différentes régions et appairés par un RPC?

L'appairage VCN à distance utilise le réseau fédérateur interrégional d'OCI, conçu pour offrir des performances supérieures et une haute disponibilité. Oracle publie et met régulièrement à jour le tableau de bord sur la latence interrégionale, accessible directement depuis votre compte Oracle Cloud. Pour plus de détails, veuillez consulter la documentation.

Quel est le tarif associé à l’appairage de réseaux en nuage virtuels?

• Appairage local (au sein d'une même région) : gratuit.
• Appairage à distance (entre régions) : l'appairage à distance n'entraîne en soi aucun frais. Seul le transfert de données sortant est facturé au-delà d'un certain seuil. Consultez les derniers tarifs publiés concernant le transfert de données sortantes.

Routage de transit VCN

Qu’est-ce que l’acheminement de transit de réseau en nuage virtuel (VTR)?

Le routage de transit VCN (VTR) repose sur une topologie en étoile, qui permet au VCN central d'assurer la connectivité de transit entre plusieurs VCN périphériques (au sein de la région) et les réseaux sur site. Une seule connexion VPN FastConnect ou IPSec reliée à un DRG suffit pour qu'un réseau sur site puisse communiquer avec tous les VCN « en étoile» par le VCN « central ». Le VTR peut être configuré uniquement avec un DRG ou avec une combinaison de DRG et de LPG. Dans cette configuration, le concentrateur VCN est toujours connecté au DRG.

Comment puis-je commencer à utiliser le routage de transit VCN?

Consultez les instructions dans Configuration du routage de transit VCN dans la console.

Quels types de réseaux à distance peuvent accéder aux rayons des réseaux en nuage virtuels à l’aide du concentrateur de réseau en nuage virtuel?

Les VCN « en étoile » peuvent accéder à vos réseaux sur site via le VCN « central ». Les VCN « en étoile » distants, connectés au VCN « central » via un appairage à distance, peuvent également accéder à d'autres VCN « en étoile » directement rattachés au DRG du VCN « central ».

Puis-je configurer le VCN « central » pour qu'il assure la connectivité avec les VCN « en étoile » situés dans des régions OCI distantes?

Si elle est conçue avec des LPG et des DRG hérités, la routage de transit VCN ne prend en charge que la connectivité consolidée entre les VCN d'une même région. Cependant, vous pouvez concevoir une topologie « Centre et étoile » multi-régions grâce aux DRG améliorés.

Puis-je configurer le VCN « central » de manière à ce qu’un VCN « en étoile » ne puisse accéder qu’à certains sous-réseaux du réseau sur site?

Oui, Vous pouvez contrôler la diffusion des annonces de routage vers les réseaux sur site en personnalisant les tables de routage du VCN central et/ou de ses passerelles. Vous pouvez également contrôler l'accès à l'aide de SL et de NSG spécifiques sur des sous-réseaux ou des VNIC afin de n'autoriser le trafic vers et depuis que les préfixes réseau sélectionnés des réseaux sur place.

Puis-je configurer le VCN « central » de manière à ce que le réseau sur site ne puisse accéder qu'à certains sous-réseaux du VCN « en étoile »?

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 spécifiques qui définissent uniquement les sous-réseaux VCN « en étoile » que vous souhaitez rendre accessibles au réseau sur place. Les routes issues de la table de routes d'entrée associée à la connexion du VCN du hub sont ensuite importées dans la table de routes DRG afin d'être diffusées vers le réseau sur site.

Y a-t-il une limite au nombre de rayons du réseau en nuage virtuel que le concentrateur de réseau en nuage virtuel peut atteindre?

Oui, Dans une architecture VTR exclusivement basée sur le protocole LPG, le VCN du nœud central est limité à un maximum de 10 VCN de nœuds en étoile, car 10 correspond à la limite d'appairage LPG par VCN. La conception du VTR exclusivement basée sur les DRG permet de prendre en charge jusqu’à 299 VCN « en étoile » (en se basant sur la limite de 300 VCN par DRG, avec un VCN «  entral »).

Puis-je configurer le VCN du hub de manière à ce que le réseau sur site puisse accéder aux services Oracle?

Oui, Vous devez suivre toutes les étapes suivantes :

1. Ajoutez une passerelle de service au réseau virtuel (VCN) du hub qui est connecté à votre réseau sur site via FastConnect ou un VPN site à site.
2. Configurez une table de routage d'entrée de passerelle dans la table de routage du VCN du centre associée à la connexion DRG, en indiquant le moniker de service OSN souhaité et un SGW comme prochain saut.
3. Configurez une table de routage d'entrée de passerelle sur la passerelle de service OCI associée au réseau virtuel central (VCN) du hub, de manière à ce que l'attachement DRG serve de saut suivant pour les préfixes IP de destination de votre réseau sur site.

Les serveurs sur place peuvent utiliser leurs adresses IP privées pour communiquer avec les services Oracle. Ce trafic ne transite pas par Internet. Pour plus d'informations, voir Routage de transit : accès privé aux services Oracle.

Puis-je activer le routage par un appareil virtuel de réseau (comme une instance de pare-feu) dans le concentrateur de réseau en nuage virtuel?

Oui, Vous pouvez configurer le routage du transit via une adresse IP privée dans le VCN hub. 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 l'ensemble du trafic entre votre réseau sur site et les VCN « en étoile ».

Consultez la documentation pour plus de détails sur le routage de transit via une adresse IP privée.

Y a-t-il des limites de performance liées à l’acheminement de transit de réseau en nuage virtuel?

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. Ces passerelles sont des périphériques virtuels hautement disponibles, capables de s'adapter dynamiquement pour répondre aux besoins en bande passante de votre réseau.

Options DHCP

Quelles sont les options DHCP?

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 d’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 VCN doit être associé à un seul ensemble d'options DHCP.

Comment les adresses IP sont-elles configurées sur les interfaces réseau d'un système d'exploitation utilisant le DHCP de VCN?

Pour que les applications puissent exploiter les adresses IP attribuées aux VNIC, celles-ci doivent être correctement configurées sur les interfaces réseau au niveau du système d'exploitation ou de l'instance. Vous constaterez qu'il existe une correspondance biunivoque entre les VNIC et les interfaces réseau au niveau du système d'exploitation, en faisant correspondre leurs adresses MAC.

Pour les adresses IP des VNIC principales, les clients DHCP des systèmes d'exploitation/instances communiqueront avec le service DHCP géré par les VCN et les configureront automatiquement.

Les détails figurent dans le tableau ci-dessous :

**Les utilisateurs doivent configurer explicitement et de manière statique l'adresse IP, le masque de réseau et le routage des interfaces réseau au niveau du système d'exploitation.

Notez également que la plupart des images OCI désactivent par défaut le DHCP sur les interfaces non principales. Pour plus d'informations, veuillez consulter la documentation OCI : Configuration du système d'exploitation de l'instance pour les VNIC secondaires et Adresses IP privées. Spécifiquement pour Oracle Linux, OCI fournit des utilitaires destinés à simplifier la configuration des adresses IP et des interfaces réseau au niveau du système d'exploitation.

Quelles options DHCP puis-je configurer?

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 spécifier un seul domaine de recherche.
• Type de DNS - Choisissez l'une des options suivantes :
  • Internet et résolveur de réseau en nuage virtuel (par défaut)
  • Résolveur personnalisé (vous pouvez indiquer jusqu'à trois serveurs DNS de votre choix, que vous configurez, gérez et entretenez vous-même)

Lors de la résolution d'une requête DNS, le système d'exploitation de l'instance utilise les serveurs DNS spécifiés par le type de DNS. Sur la plupart des images Linux, la configuration du résolveur dans /etc/resolv.conf (y compris les options comme ndots) détermine la manière dont le système d'exploitation traite les noms courts (non FQDN) et à quel moment il ajoute le domaine de recherche fourni par DHCP lors de la résolution de ces noms courts. Il s'agit d'un comportement standard du résolveur du système d'exploitation, qui n'est pas propre à OCI. Pour plus d'informations, voir Options DHCP.

Puis-je modifier les options DHCP utilisées par mon sous-réseau après l'avoir créé?

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.

Système de noms de domaine (DNS)

Comment dois-je configurer un nom d’hôte DNS pour mon instance?

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 d'informations, consultez Le DNS dans un 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.

Comment puis-je configurer le réseau en nuage virtuel et le sous-réseau pour activer les noms d’hôte?

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

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.

Quel est le nom d’hôte DNS d’une instance de calcul?

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 VCN OCI, chaque instance peut être configurée avec un nom d'hôte DNS correspondant à son adresse privée.

Le nom de domaine complet (FQDN) d'une instance se présente sous la forme hostname.subnetdnslabel.vcndnslabel.oraclevcn.com, où hostname correspond au nom d'hôte DNS de l'instance, et subnetdnslabel, vcndnslabel sont respectivement les étiquettes DNS du sous-réseau et du VCN de l'instance.

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

Puis-je renommer le nom d’hôte de mon instance?

Oui, vous pouvez le modifier depuis la console OCI ou par l'API. Si vous modifiez le nom d'hôte directement sur l'instance, le nom de domaine complet (FQDN) de celle-ci n'est pas mis à jour.

Puis-je renommer l’étiquette DNS d’un réseau en nuage virtuel existant ou d’un sous-réseau?

Non.

Si mon sous-réseau est configuré pour utiliser un résolveur DNS personnalisé, des noms d'hôte DNS sont-ils créés pour les instances de ce sous-réseau ?

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.

Mon instance peut-elle résoudre les noms d’hôte des instances dans d’autres réseaux en nuage virtuels?

Non, pas par défaut. Par défaut, l'instance ne peut résoudre que les noms d'hôte des instances situées au sein du même VCN. Pour résoudre les noms d'hôte entre différents VCN, il faut soit associer des vues privées au résolveur VCN, soit configurer des points de terminaison d'écoute, des points de terminaison de transfert et des règles de transfert.

Puis-je configurer mes serveurs de DNS personnalisés pour résoudre les noms d’hôte DNS interne du 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 vos serveurs DNS personnalisés pour qu'ils utilisent 169.254.169.254 comme serveur de transfert pour le domaine VCN (par exemple contoso.oraclevcn.com).

Notez que les serveurs DNS personnalisés doivent être configurés dans un sous-réseau qui utilise « Internet et résolveur VCN » comme type DNS (pour permettre l’accès à l’adresse IP 169.254.169.254).

Pour découvrir un exemple de mise en œuvre avec le fournisseur OCI Terraform, consultez Configuration DNS hybride.

Facturation

Est-ce qu’on me facture pour l’utilisation d’un réseau en nuage virtuel?

La création et l'utilisation des VCN sont gratuites. Toutefois, les frais d'utilisation des autres services OCI (notamment les ressources de calcul et les volumes de stockage) ainsi que les frais de transfert de données s'appliquent 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.

Comment serai-je facturé pour l'utilisation du VPN site à site OCI afin de me connecter à mon VCN?

Le VPN site à site d'OCI est un service géré gratuit. Il n'y a ni frais par tunnel ni frais de transfert de données pour le trafic VPN.

Quels sont les frais d’utilisation si j’utilise d’autres ressources, comme une base de données ou un service de stockage d’objets, à partir d’instances de mon réseau en nuage virtuel?

Vous n'encourez aucun frais de transfert de données lorsque vous accédez à d'autres services OCI publics, comme le stockage d'objets, situés 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 à des ressources OCI publiques par votre VPN depuis l'intérieur de votre VCN, vous devrez vous acquitter des frais de transfert de données sortants indiqués.

Est-ce que la tarification inclut les taxes?

Sauf indication contraire, les tarifs OCI — y compris les frais de transfert de données sortants — s'entendent hors taxes et droits applicables, notamment la TVA et toute taxe sur les ventes applicable.