Documentation sur Oracle Cloud Infrastructure

Utilisation du RPV site à site

Cette rubrique contient des détails sur l'utilisation d'un RPV site à site et des composants connexes. Voir également ces rubriques :

Modification des routes statiques

Vous pouvez modifier les routes statiques pour une connexion IPSec existante. Vous pouvez fournir jusqu'à 10 routes statiques.

N'oubliez pas qu'une connexion IPSec peut utiliser un routage statique, un routage dynamique BGP ou un routage basé sur des politiques. Lors de l'utilisation du routage statique, vous associez les routes statiques à la connexion IPSec globale, et non aux tunnels individuels. Si une connexion IPSec est associée à des routes statiques, Oracle utilise celles-ci pour diriger le trafic d'un tunnel uniquement si le tunnel lui-même est configuré pour utiliser le routage statique. S'il est configuré pour utiliser le routage dynamique BGP, les routes statiques de la connexion IPSec sont ignorées.

Important

La connexion IPSec s'arrête pendant son reprovisionnement à l'aide des changements de route statique.

Voir Mise à jour d'une connexion IPSec pour connaître les étapes nécessaires pour modifier les routes statiques.

Passage du routage statique au routage dynamique BGP

Pour remplacer un RPV site à site existant par un routage statique par un routage dynamique BGP, voir Mise à jour d'un tunnel IPSec.

Attention

Lorsque vous modifiez le type de routage d'un tunnel, le statut IPSec de celui-ci ne change pas pendant le reprovisionnement. Cependant, le routage par le tunnel est affecté. Le trafic est temporairement interrompu jusqu'à ce qu'un ingénieur réseau configure le dispositif CPE conformément à la modification du type d'acheminement. Si un RPV site à site existant est configuré pour n'utiliser qu'un seul tunnel, ce processus interrompt la connexion à Oracle. Si un RPV site à site utilise plusieurs tunnels, nous vous recommandons de reconfigurer un tunnel à la fois pour éviter d'interrompre la connexion à Oracle.

Migration vers un RPV basé sur des politiques

Le service RPV site-à-site v2 d'Oracle Cloud Infrastructure prend entièrement en charge les RPV IPSec basés sur des politiques, avec jusqu'à 50 domaines de chiffrement par tunnel.

Pour éviter les interruptions de trafic potentielles, si vous avez été migré du service RPV site à site v1 vers le RPV site à site v2 et que vous avez configuré un équipement local d'abonné avec plusieurs domaines de chiffrement, modifiez les configurations de tunnel du côté OCI de la connexion pour qu'elles correspondent à la configuration de l'équipement local d'abonné. Cet article explique pourquoi cette modification est si importante et les étapes requises pour configurer OCI afin qu'il utilise des RPV IPSec basés sur des politiques.

Pourquoi migrer vers la fonction RPV basée sur des politiques?

Le service RPV site-à-site v1 est toujours configuré en tant que RPV basé sur des routes et utilise un domaine de chiffrement de tout type pour BGP et les types de routage statique. Pour l'interopérabilité RPV basée sur des politiques, le RPV site à site v1 prend en charge un équipement local d'abonné configuré pour des RPV basés sur des politiques si l'équipement local d'abonné agit en tant qu'initiateur et qu'un seul domaine de chiffrement est envoyé à OCI. La configuration de plusieurs domaines de chiffrement dans ce scénario entraîne l'instabilité du tunnel où vous pouvez observer le battement du tunnel ou que le trafic traversant le tunnel a une accessibilité instable.

Le service RPV site-à-site v2 utilise une option de type de routage basée sur des politiques en plus des types de routage BGP et statique. Le protocole BGP du RPV site à site v2 et les types de routage statique restent basés sur des routes et prennent en charge un seul domaine de chiffrement, quel qu'il soit. Ces options fonctionnent avec une configuration d'équipement local d'abonné basée sur une politique de domaine de chiffrement unique. Toutefois, cela n'est pas recommandé et l'envoi de plusieurs domaines de chiffrement entraîne l'instabilité du tunnel.

Le type de routage basé sur des politiques disponible pour le RPV site à site v2 est un RPV basé sur des politiques doté de fonctions complètes qui vous permet de configurer le côté OCI pour qu'il corresponde entièrement à la configuration basée sur des politiques d'un équipement local d'abonné et d'accepter toutes les associations de sécurité individuelles requises pour un tunnel RPV IPSec stable.

Pour plus d'informations sur les domaines de chiffrement et les différents types de tunnel RPV IPSec, voir Domaine de chiffrement ou mandataire pris en charge.

Une fois que les tunnels ont été migrés du RPV site à site v1 vers v2, ils continuent d'utiliser le même type de routage (BGP ou statique) que celui configuré avant la migration. Consultez le processus étape par étape pour modifier les tunnels basés sur des routes existants afin d'utiliser un routage basé sur des politiques.

Voir Mise à jour d'un tunnel IPSec pour des étapes spécifiques de migration vers un RPV basé sur une politique.

Modification de l'identificateur IKE de CPE utilisé Oracle

Si l'équipement local d'abonné est derrière un appareil NAT, vous devrez peut-être donner à Oracle l'identificateur IKE. Vous pouvez le définir lors de la création de la connexion IPSec ou changer sa valeur lorsque vous modifiez la connexion par la suite. Pour Oracle, la valeur doit être une adresse IP ou un nom de domaine complet. Lorsque vous la définissez, vous spécifiez également son type.

Important

La connexion IPSec s'arrête pendant son reprovisionnement afin d'utiliser l'identificateur IKE.

Voir Mise à jour d'une connexion IPSec pour connaître les étapes nécessaires pour modifier l'identificateur IKE de l'équipement local d'abonné utilisé par Oracle.

Utilisation de IKEv2

Oracle prend en charge Internet Key Exchange (IKE) version 1 et version 2 (IKEv2).

Pour utiliser IKEv2 avec un équipement local d'abonné qui le prend en charge, vous devez :

Mise à niveau d'une connexion IPSec existante vers IKEv2

Important

Nous vous recommandons d'effectuer le processus suivant pour un tunnel à la fois afin d'éviter toute interruption d'une connexion IPSec. Si la connexion n'est pas redondante (par exemple, ne comporte pas de tunnels redondants), prévoyez un temps d'arrêt pendant que vous passez à IKEv2.
  1. Modifiez la version IKE du tunnel dans la console Oracle pour utiliser IKEv2 et les paramètres de chiffrement connexes pris en charge par le CPE. Pour obtenir la liste des paramètres pris en charge par Oracle, voir Paramètres IPSec pris en charge.
  2. Si les clés ne sont pas renouvelées immédiatement pour les associations de sécurité, forcez ce renouvellement pour ce tunnel du CPE. Pour ce faire, effacez les associations de sécurité de la phase 1 et de la phase 2, et n'attendez pas qu'elles expirent. Certains appareils CPE attendent l'expiration des associations de sécurité avant de renouveler la clé. Forcer le renouvellement de la clé vous permet de confirmer immédiatement l'exactitude de la configuration de la version IKE.
  3. Pour vérifier, assurez-vous que le renouvellement de clé des associations de sécurité pour le tunnel est effectué correctement. Si ce n'est pas le cas, vérifiez que la version correcte d'IKE est définie dans la console Oracle et sur le CPE, et que celui-ci utilise les paramètres appropriés.

Après avoir confirmé que le premier tunnel est à nouveau opérationnel, répétez les étapes précédentes pour le second tunnel.

Modification de la clé secrète partagée utilisée par un tunnel IPSec

Lorsque vous configurez un RPV site à site, Oracle fournit par défaut la clé secrète partagée (également appelée clé prépartagée) de chaque tunnel. Vous pouvez remplacer cette clé secrète partagée par celle que vous voulez utiliser. Vous pouvez définir une clé secrète partagée pour chaque tunnel lorsque vous créez la connexion IPSec. Vous pouvez également modifier les tunnels, puis fournir une nouvelle clé secrète partagée à chacun. Seuls les chiffres, lettres et espaces sont autorisés pour la clé secrète partagée. Nous vous recommandons d'utiliser une clé secrète partagée différente pour chaque tunnel.

Important

Lorsque vous modifiez la clé secrète partagée d'un tunnel, la connexion IPSec globale et le tunnel passent à l'état En provisionnement pendant que le tunnel est reprovisionné avec la nouvelle clé secrète partagée. L'autre tunnel dans la connexion IPSec demeure à l'état Disponible. Toutefois, lors du reprovisonnement du premier tunnel, vous ne pouvez pas modifier la configuration du second.

Voir Obtention des détails d'un tunnel IPSec pour connaître les étapes nécessaires pour modifier la clé secrète partagée utilisée par un tunnel IPSec.

Surveillance du RPV site à site

Vous pouvez surveiller l'état, la capacité et la performance des ressources Oracle Cloud Infrastructure à l'aide de mesures, d'alarmes et d'avis. Pour plus d'informations, voir Surveillance et Avis.

Pour des informations sur la surveillance d'une connexion, voir Mesures du RPV site à site.

Messages de journal du RPV site à site

Vous pouvez activer la journalisation et voir les messages de journal générés pour divers aspects opérationnels du RPV site à site, notamment les négociations qui surviennent lors de l'affichage d'un tunnel IPSec. Vous pouvez activer et accéder aux messages de journal d'un RPV site à site à l'aide de ce dernier ou du service de journalisation.

Pour activer la journalisation des messages, voir Obtention des détails de la connexion IPSec.

Pour voir les messages du journal, voir Obtention des détails de la connexion IPSec.

Déplacement d'une connexion IPSec ou d'un objet CPE vers un autre compartiment

Vous pouvez déplacer des ressources d'un compartiment à un autre. Après que la ressource a été déplacée dans un nouveau compartiment, les politiques inhérentes s'appliquent immédiatement et ont une incidence sur l'accès à la ressource au moyen de la console. Le déplacement de l'objet CPE vers un autre compartiment n'a aucune incidence sur la connexion entre un centre de données sur place et Oracle Cloud Infrastructure. Pour plus d'informations, voir Utilisation des compartiments.

Pour plus de détails, voir Déplacement d'une connexion IPSec entre des compartiments et Déplacement d'un équipement local d'abonné vers un autre compartiment.

Maintenance des tunnels IPSec

Pour assurer la sécurité, la stabilité et la performance de notre système, Oracle met régulièrement à jour les logiciels sur l'ensemble de la plate-forme OCI. Ces mises à jour incluent des correctifs critiques tels que des correctifs de vulnérabilité, de nouvelles fonctionnalités et des correctifs de bogues, ce qui améliore les fonctionnalités et la fiabilité globales. Lors du processus de mise à jour, un tunnel IPSec est déplacé d'une tête de réseau RPV vers une autre tête de réseau, ce qui entraîne la réinitialisation de la connexion IPSec lorsqu'un seul tunnel est utilisé. Un seul tunnel IPSec dans une connexion IPSec est déplacé. Bien que nous ne puissions pas empêcher cette brève interruption du tunnel, nous avons optimisé le mécanisme de mise à jour pour minimiser le temps d'arrêt. Lorsque l'équipement local d'abonné (CPE) tente continuellement de rétablir la connexion, le temps d'arrêt normal du tunnel IPSec est inférieur à une minute. Cette conception permet à Oracle de maintenir un équilibre entre la sécurité et la fiabilité du système tout en minimisant les interruptions de connectivité. La restauration du tunnel IPSec peut parfois prendre jusqu'à 10 minutes :

  • Lorsque le tunnel est défini en tant que répondant uniquement du côté OCI et que l'équipement local d'abonné n'essaie pas d'activer le tunnel immédiatement
  • Lorsque le CPE ne répond pas à la négociation IKE lancée par le côté OCI

Bien que le volet de tunnel IPSec lors des mises à jour logicielles soit inévitable, OCI fournit des tunnels redondants. Ces tunnels redondants sont conçus pour maintenir un flux de trafic continu, même pendant la courte période où un tunnel subit un temps d'arrêt. Si la redondance a été configurée correctement, tout le trafic acheminé par le tunnel principal passe de manière transparente au tunnel redondant pendant un volet de tunnel. Ce mécanisme de basculement garantit que les services restent ininterrompus et que le flux de trafic est préservé sans retards importants. OCI garantit que les tunnels redondants atterrissent sur deux têtes de réseau RPV distinctes. Lors de nos mises à jour logicielles, un seul tunnel est touché à la fois.

Nous vous recommandons de tester la redondance en supprimant le tunnel RPV principal, à la fois lors de la configuration initiale et à une fréquence régulière par la suite. Vérifiez que les instances de VCN restent accessibles pendant que le tunnel principal est hors ligne et que le trafic passe au tunnel redondant. La section Redondance RPV de ce guide sur la redondance fournit des informations supplémentaires sur la configuration de la redondance pour les tunnels RPV dans différents cas d'utilisation.

Vous pouvez utiliser les étapes suivantes pour désactiver temporairement un tunnel vous-même afin de tester le basculement de redondance d'un tunnel IPSec principal vers un tunnel IPSec secondaire :

  1. Allez à la page des détails du tunnel comme décrit sous Mise à jour d'un tunnel IPSec et modifiez la clé secrète partagée.
  2. Pour désactiver temporairement un tunnel :
    1. Coupez le texte dans le champ de clé secrète partagée et remplacez-le par quelques lettres ou chiffres aléatoires. Cela entraîne l'arrêt de la session BGP et le basculement du trafic vers l'autre tunnel. Ce champ ne peut être vide.
      Collez la chaîne initiale dans le champ de clé secrète partagée dans un fichier texte. Vous en avez besoin pour rétablir la session BGP après avoir confirmé que la redondance fonctionnait comme prévu.
    2. Sélectionnez enregistrer les modifications.
    3. Vérifiez que le trafic circule toujours sur le tunnel IPSec secondaire dans la connexion.
  3. Pour restaurer un tunnel temporairement désactivé :
    1. Allez à la page des détails du tunnel comme décrit sous Mise à jour d'un tunnel IPSec et modifiez la clé secrète partagée.
    2. Collez le texte d'origine dans le champ de clé secrète partagée.
    3. Sélectionnez enregistrer les modifications.
    4. Attendez que la session BGP soit rétablie.