Documentation Oracle Cloud Infrastructure

Accès à d'autres réseaux cloud virtuels : appairage

L'appairage VCN est le processus de connexion de nombreux réseaux cloud virtuels (VCN). Quatre types d'appairage VCN sont disponibles :

Vous pouvez utiliser l'appairage VCN pour diviser un réseau étendu en plusieurs réseaux cloud virtuels (par exemple, en fonction des services ou des secteurs d'activité), chaque VCN disposant d'un accès direct et privé aux autres. Le trafic n'a pas besoin de circuler sur Internet ou via un réseau sur site au moyen d'un VPN site à page ou de FastConnect. Vous pouvez également placer des ressources partagées dans un même réseau cloud virtuel auquel tous les autres réseaux cloud virtuels peuvent accéder de manière privée.

Chaque VCN peut avoir jusqu'à 10 passerelles d'appairage local et ne peut être attaché qu'à un seul DRG. Un seul DRG prend en charge jusqu'à 300 pièces jointes VCN, ce qui permet au trafic entre elles de circuler comme indiqué par les tables de routage du DRG. Nous vous recommandons d'utiliser le DRG si vous devez homologue avec de nombreux réseaux cloud virtuels. Si vous souhaitez obtenir la bande passante la plus élevée possible et un trafic à très faible latence entre deux réseaux cloud virtuels de la même région, utilisez le scénario décrit dans Appairage VCN local à l'aide de passerelles d'appairage local. L'appairage VCN local via un DRG mis à niveau vous offre plus de flexibilité dans le routage en raison du plus grand nombre de pièces jointes.

Etant donné que l'appairage VCN distant croise des régions, vous pouvez l'utiliser (par exemple) pour mettre en miroir ou sauvegarder des bases de données dans une région vers une autre.

Présentation de l'appairage local de réseaux cloud virtuels

L'appairage VCN local est le processus consistant à connecter deux réseaux Cloud virtuels d'une même région afin que leurs ressources puissent communiquer avec des adresses IP privées sans acheminer le trafic sur Internet ou via un réseau sur site. Les réseaux cloud virtuels peuvent appartenir à la même location d'Oracle Cloud Infrastructure ou à des emplacements différents. Sans appairage, un VCN particulier aurait besoin d'une passerelle Internet et d'adresses IP publiques pour les instances qui doivent communiquer avec un autre VCN.

L'appairage VCN local via un DRG mis à niveau vous offre plus de flexibilité dans le routage et la gestion simplifiée, mais au prix d'une augmentation de la latence (par microsecondes) du routage du trafic via un routeur virtuel, le DRG.

Conséquences importantes liées à l'appairage

Cette section récapitule certaines conséquences en matière de contrôle d'accès, de sécurité et de performances pour les réseaux cloud virtuels appairés. En général, vous pouvez contrôler l'accès et le trafic entre deux réseaux cloud virtuels appairés à l'aide de stratégies IAM, de tables de routage dans chaque VCN et de listes de sécurité dans chaque VCN.

Contrôle de l'établissement des appairages

Avec les stratégies IAM, vous pouvez contrôler :

Contrôle du flux de trafic sur la connexion

Même si une connexion d'appairage a été établie entre un VCN et un autre, vous pouvez contrôler le flux de paquets sur la connexion avec les tables de routage dans le VCN. Par exemple, vous pouvez limiter le trafic uniquement à des sous-réseaux spécifiques de l'autre réseau cloud virtuel.

Sans mettre fin à l'appairage, vous pouvez arrêter le flux de trafic vers l'autre VCN en supprimant les règles de routage qui dirigent le trafic d'un VCN vers l'autre VCN. Vous pouvez également arrêter le trafic en enlevant toute règle de liste de sécurité qui autorise le trafic entrant ou sortant avec l'autre réseau cloud virtuel. Cela n'arrête pas le trafic qui passe sur la connexion d'appairage, mais arrête celui au niveau de la carte d'interface réseau virtuelle.

Pour plus d'informations sur le routage et les listes de sécurité, reportez-vous aux points abordés dans les sections suivantes :

Appairage local de réseaux cloud virtuels à l'aide de groupes d'appairage local :

Appairage à distance de réseaux cloud virtuels à l'aide d'une connexion d'appairage à distance :

Appairage VCN local à l'aide d'une passerelle de routage dynamique (DRG) :

Appairage à distance de réseaux cloud virtuels à l'aide d'une passerelle de routage dynamique :

Contrôle des types de trafic spécifiques autorisés

Chaque administrateur VCN s'assure que tout le trafic sortant et entrant avec l'autre VCN est prévu ou attendu et défini. En pratique, cela signifie mettre en oeuvre des règles de liste de sécurité qui désignent explicitement les types de trafic qu'un VCN peut envoyer à l'autre et accepter de l'autre.

Important

Les instances de calcul exécutant des images de plateforme comportent également des règles du pare-feu du système d'exploitation qui contrôlent l'accès à l'instance. Lors de la résolution d'un problème d'accès à une instance, assurez-vous que les éléments suivants sont définis correctement :

  • Règles des groupes de sécurité réseau dans lesquels l'instance se trouve
  • Règles des listes de sécurité associées au sous-réseau de l'instance
  • Règles de pare-feu de système d'exploitation de l'instance

Si une instance exécute Oracle Autonomous Linux 8.x, Oracle Autonomous Linux 7, Oracle Linux 8, Oracle Linux 7 ou Oracle Linux Cloud Developer 8, vous devez utiliser firewalld pour interagir avec les règles iptables. Pour référence, voici les commandes permettant d'ouvrir un port (1521 dans cet exemple) :

sudo firewall-cmd --zone=public --permanent --add-port=1521/tcp
								
sudo firewall-cmd --reload

En ce qui concerne les instances comportant un volume d'initialisation iSCSI, la commande --reload précédente peut entraîner des problèmes. Pour obtenir des détails et une solution de contournement, reportez-vous à Le système se bloque après l'exécution de firewall-cmd --reload.

Outre les listes de sécurité et les pare-feu, évaluez d'autres configurations basées sur le système d'exploitation sur les instances du VCN local. Il peut y avoir des configurations par défaut qui ne s'appliquent pas au CIDR du VCN local, mais qui s'appliquent par inadvertance au CIDR de l'autre VCN.

Utilisation des règles de liste de sécurité par défaut

Si les sous-réseaux locaux du VCN utilisent la liste de sécurité par défaut avec les règles par défaut qu'elle fournit, tenez compte de deux règles qui autorisent le trafic entrant de n'importe où (0.0.0.0/0 et donc l'autre VCN) :

  • Règle entrante avec conservation de statut autorisant le trafic sur le port TCP 22 (SSH) à partir de 0.0.0.0/0 et de n'importe quel port source
  • Règle entrante avec conservation de statut autorisant le trafic ICMP de type 3 et de code 4 à partir de 0.0.0.0/0 et de n'importe quel port source

Evaluez ces règles et déterminez si vous voulez les conserver ou les mettre à jour. Comme indiqué plus haut, vérifiez que tout le trafic entrant ou sortant que vous autoriez est prévu ou attendu et défini.

Préparation à l'impact sur les performances et aux risques de sécurité

En général, préparez le VCN local à la manière dont il pourrait être affecté par l'autre VCN. Par exemple, la charge sur le VCN local ou ses instances pourrait augmenter. Ou le VCN local pourrait subir une attaque malveillante directement à partir ou par le biais de l'autre VCN.

Concernant les performances : si le VCN local fournit un service à un autre, préparez-vous à augmenter le service pour répondre aux demandes de l'autre VCN. Vous pouvez ainsi être prêt à créer davantage d'instances Compute si nécessaire. Ou si vous êtes préoccupé par les niveaux élevés de trafic réseau vers le VCN local, envisagez d'utiliser des règles de liste de sécurité sans état pour limiter le niveau de suivi de connexion que le VCN local doit effectuer. Ces règles de liste de sécurité sans conservation de statut peuvent également ralentir l'impact d'une attaque par déni de service (DoS).

Concernant les risques de sécurité : vous ne pouvez pas nécessairement contrôler si l'autre VCN est connecté à Internet, ce qui pourrait exposer le VCN local à des attaques de rebond dans lesquelles un hôte malveillant sur Internet envoie du trafic au VCN local qui semble provenir du VCN avec lequel vous êtes appairé. Pour éviter cela, comme mentionné précédemment, utilisez des listes de sécurité pour limiter soigneusement le trafic entrant de l'autre VCN au trafic attendu et défini.