Implémentation du mode BYOIP (Bring Your Own IP)
Ce tutoriel décrit l'utilisation de l'infrastructure classique. La plupart des charges de travail peuvent être implémentées à l'aide des ressources IBM Cloud® Virtual Private Cloud. Utilisez IBM Cloud VPC pour créer votre propre environnement de calcul de type cloud privé sur une infrastructure de cloud public partagé. Un VPC permet à une entreprise de définir et de contrôler un réseau virtuel qui est logiquement isolé de tous les autres locataires de cloud public, créant ainsi un endroit privé et sécurisé sur le cloud public. Plus précisément, vous pouvez apportez votre propre sous-réseau la plage d'adresses IP à IBM Cloud VPC.
Ce tutoriel peut entraîner des coûts. Utilisez l'Estimateur de coûts pour générer une estimation du coût en fonction de votre utilisation projetée.
Ce tutoriel présente un bref aperçu des modèles d'implémentation BYOIP pouvant être utilisés avec IBM Cloud et un arbre de décisions permettant d'identifier le modèle approprié lors de la réalisation de l'enceinte sécurisée, comme décrit dans le tutoriel Isolation de charges de travail à l'aide d'un réseau privé sécurisé. La configuration peut nécessiter des informations supplémentaires de la part de votre équipe réseau sur site, du support technique IBM Cloud ou des services IBM.
L'approche BYOIP (Bring Your own IP) est une exigence fréquente lorsque vous souhaitez connecter les réseaux client existants à l'infrastructure mise à disposition sur IBM Cloud. L'intention est généralement de minimiser les modifications apportées à la configuration et aux opérations de routage réseau du client avec l'adoption d'un seul espace d'adressage IP, basé sur le schéma d'adressage IP existant du client.
Objectifs
- Comprendre les modèles d'implémentation BYOIP.
- Sélectionner le modèle d'implémentation pour IBM Cloud
Adressage IP IBM Cloud
IBM Cloud utilise un certain nombre de plages d'adresses privées, plus particulièrement 10.0.0.0/8, et dans certains cas, ces plages peuvent entrer en conflit avec les réseaux client existants. Si des conflits d'adresses se produisent, un certain nombre de modèles permettent de prendre en charge BYOIP pour garantir l'interopérabilité avec le réseau IBM Cloud.
- Conversion d'adresses réseau (NAT)
- Tunnellisation GRE (Generic Routing Encapsulation)
- Tunnellisation GRE avec alias d'adresse IP
- Réseau superposé virtuel
Le choix du modèle est déterminé par les applications destinées à être hébergées sur IBM Cloud. Il existe deux aspects essentiels, la sensibilité des applications à la mise en oeuvre du modèle et l'étendue du chevauchement des plages d'adresses entre le réseau client et IBM Cloud. Des considérations supplémentaires s'appliquent également si l'intention d'utiliser une connexion à IBM Cloud via un réseau privé dédiée est envisagée. La documentation de IBM Cloud® Direct Link est une lecture recommandée à tous les utilisateurs qui envisagent le BYOIP. Pour les utilisateurs d'IBM Cloud® Direct Link, les instructions associées doivent être appliquées en tenant compte des informations présentées ici.
Présentation des modèles de mise en oeuvre
-
NAT: traduction d'adresse NAT au niveau du routeur du client sur site. Effectuer un NAT sur site pour traduire le plan d'adressage du client vers les adresses IP attribuées par IBM Cloud aux services IaaS provisionnés.
-
Tunnel GRE: Le plan d'adressage est unifié en routant le trafic IP sur un tunnel GRE entre IBM Cloud et le réseau sur site, généralement via un VPN. Il s'agit du scénario illustré dans le tutoriel VPN dans un réseau privé sécurisé.
Il existe deux sous-modèles en fonction de l'éventualité de chevauchement des espaces adresse.
- Absence de chevauchement d'adresses : il n'y a pas de chevauchement d'adresses dans les plages d'adresses et de risques de conflit entre les réseaux.
- Chevauchement d'adresses partiel : les espaces adresse IP du client et d'IBM Cloud utilisent la même plage d'adresses et il existe un risque de chevauchement et de conflit. Dans ce cas, les adresses de sous-réseau client qui ne se chevauchent pas dans le réseau privé d'IBM Cloud sont choisies.
-
Tunnel GRE + alias IP: Le plan d'adressage est unifié en routant le trafic IP sur un tunnel GRE entre le réseau sur site et les adresses IP alias attribuées aux serveurs sur le IBM Cloud Il s'agit d'un cas particulier du scénario illustré dans le tutoriel VPN into a secure private network. Une interface et un alias IP supplémentaires pour un sous-réseau IP compatible sont créés sur les serveurs virtuels et bare metal mis à disposition sur IBM Cloud, pris en charge par une configuration de routage appropriée sur le dispositif VRA.
-
Réseau virtuel superposé: IBM Cloud Virtual Private Cloud(VPC) prend en charge le BYOIP pour les environnements entièrement virtuels sur le IBM Cloud. Il peut être considéré comme une alternative au boîtier de réseau privé sécurisé décrit dans le tutoriel d'isolement de charges de travail à l'aide d'un réseau privé sécurisé.
Vous pouvez également envisager une autre solution telle que VMware NSX qui implémente un réseau superposé virtuel dans une couche sur le réseau IBM Cloud. Toutes les adresses BYOIP du réseau superposé virtuel sont indépendantes des plages d'adresses réseau IBM Cloud. Voir Getting started with VMware and IBM Cloud.
Arbre de décisions de modèle d'implémentation
L'arbre de décisions représenté ici peut être utilisé pour déterminer le modèle d'implémentation approprié.
{: caption="
Les remarques suivantes fournissent des indications supplémentaires :
La conversion NAT pose-t-elle un problème pour vos applications ?
Vous trouverez ci-dessous deux cas distincts dans lesquels la conversion NAT peut poser un problème. Dans ces cas, la conversion NAT ne doit pas être utilisée.
- Certaines applications telles que la communication de domaine Microsoft AD et les applications P2P peuvent rencontrer des problèmes techniques avec la conversion NAT.
- Lorsque des serveurs inconnus doivent communiquer avec le IBM Cloud ou que des centaines de connexions bidirectionnelles entre IBM Cloud et des serveurs sur site sont nécessaires. Dans ce cas, une partie du mappage ne peut pas être configurée sur la table NAT/routeur du client, car il est impossible d'identifier le mappage au préalable.
Aucun chevauchement d'adresses
10.0.0.0/8 est-il utilisé dans le réseau de l'entreprise ? Lorsqu'il n'y a pas de chevauchement d'adresses entre le réseau privé sur site et le réseau privé IBM Cloud, le tunnelage GRE tel que décrit dans ce tutoriel peut être utilisé entre le réseau sur site et IBM Cloud pour éviter la nécessité d'une traduction NAT. Cela nécessite un examen de l'utilisation des adresses réseau avec l'équipe réseau sur place.
Chevauchement d'adresses partiel
Si une partie de la plage 10.0.0.0/8 est utilisée sur le réseau sur site, existe-t-il des sous-réseaux non chevauchants disponibles sur le réseau IBM Cloud? Examinez l'utilisation des adresses réseau existantes avec l'équipe réseau sur site et contactez le service commercial IBM Cloud pour identifier les réseaux disponibles qui ne se chevauchent pas.
L'attribution d'alias d'IP est-elle problématique ?
S'il n'existe aucune adresse protégée contre le chevauchement, l'attribution d'alias d'IP peut être implémentée sur des serveurs virtuels et bare metal déployés dans l'enceinte de réseau privé sécurisé. L'attribution d'alias d'IP affecte plusieurs adresses de sous-réseau sur une ou plusieurs interfaces réseau de chaque serveur.
L'attribution d'alias d'IP est une technique couramment utilisée, bien qu'il soit recommandé de passer en revue les configurations du serveur et des applications pour déterminer si elles fonctionnent correctement avec des configurations à emplacements multiples et d'alias IP.
Une configuration supplémentaire du routage sur le VRA sera nécessaire pour créer des routes dynamiques (par exemple BGP) ou des routes statiques pour les sous-réseaux BYOIP.