Objectifs

• Comprenez les concepts sous-jacents à un modèle de concentrateur et de serveur spoke basé sur VPC.
• Comprendre l'implémentation d'un routeur pare-feu et d'un environnement VPC de transit.
• Comprendre le routage d'entrée et de sortie VPC.
• Identifiez et, le cas échéant, résolvez les problèmes de routage asymétrique.
• Connectez des VPC via un Transit Gateway.

Avant de commencer

Pour ce tutoriel, vous devez disposer des éléments suivants :

• de terraform afin d'utiliser l'infrastructure en tant que code pour mettre à disposition les ressources,
• python pour exécuter éventuellement les commandes pytest,
• L'implémentation d'un pare-feu-router nécessite que vous activiez des contrôles d'usurpation d'adresse IP,
• Une clé SSH pour se connecter aux serveurs virtuels. Si vous n'avez pas de clé SSH, suivez les instructions pour créer une clé pour le VPC.

Voir les prérequis pour quelques options incluant un fichier Dockerfile afin de créer facilement l'environnement prérequis.

De plus :

• Vérifiez les autorisations d'utilisateur. Assurez-vous que votre compte utilisateur dispose des droits suffisants pour créer et gérer toutes les ressources de ce tutoriel. Voir la liste des:
  • droits requis pour VPC.
  • droits requis pour la création de Transit Gateway.
  • droits requis pour les vérifications d'usurpation d'adresse IP.

Présentation de l'adresse IP et du sous-réseau

Dans cette étape, vous allez mettre à disposition les ressources réseau VPC. Planifiez soigneusement en concevant un plan d'adressage pour un VPC et utilisez des blocs CIDR qui ne se chevauchent pas.

Il est tentant de diviser d'abord l'espace CIDR par VPC, mais cela complique le routage. Au lieu de considérer une zone de disponibilité comme un bloc CIDR unique et chaque VPC comme consommant une tranche de celle-ci.

Ce diagramme montre plus en détail la zone 1. Les tailles de sous-réseau et la présentation sont identiques dans les autres zones:

Au-dessus de l'entreprise se trouve à gauche et IBM Cloud à droite. Dans IBM Cloud pour la décision simple, une seule zone est représentée pour le VPC de transit et Spoke 0. Notez que les blocs CIDR ne se chevauchent pas et que les VPC consomment tous un bloc CIDR dans chaque zone:

• Le routage CIDR sur site est 192.168.0.0/16.
• Les zones de cette région multizone sont 10.*.0.0/16. Le deuxième chiffre : 1, 2, 3 est le numéro de la zone (illustré pour Dallas/us-sud):
  • 10.10.1.0.0/16, zone 1, Dallas 1, us-south-1.
  • 10.10.2.0.0/16, zone 2, Dallas 2, us-south-2.
  • 10.10.3.0.0/16, zone 3, Dallas 3, us-south-3.
• Le VPC de transit consomme des routages CIDR 10.*.15.0/24:
  • 10.1.15.0/24, zone 1.
  • 10.2.15.0/24, zone 2.
  • 10.3.15.0/24, zone 3.
• Spoke 0 consomme 10.*.0.0/24 ou des routages CIDR:
  • 10.1.0.0/24, zone 1.
  • 10.2.0.0/24, zone 2.
  • 10.3.0.0/24, zone 3.
• Les CIDR de sous-réseau divisent davantage le /24 en /26.

Les sous-réseaux en transit et en satellite sont destinés aux différents types de ressource:

• Instances VPC, équilibreurs de charge, Red Hat OpenShift, etc. Les instances VPC sont démontrées dans ce tutoriel.
• dns-dispositifs d'emplacement DNS Services utilisés dans la deuxième partie.
• vpe- VPE for VPC utilisé dans la deuxième partie.
• Instances VPC fw-firewall-router (uniquement en transit).

Mise à disposition de ressources réseau VPC

1. Le référentiel GitHub associé contient les fichiers source permettant d'implémenter l'architecture. Dans un shell de bureau, clonez le référentiel:

   git clone https://github.com/IBM-Cloud/vpc-transit
   cd vpc-transit
   

2. Le répertoire config_tf contient les variables de configuration que vous devez configurer.

   cp config_tf/template.terraform.tfvars config_tf/terraform.tfvars
   

3. Editez config_tf/terraform.tfvars et utilisez les commentaires de ce fichier comme guide.

4. Etant donné qu'il est important que chaque couche soit installée dans le bon ordre et que certaines étapes de ce tutoriel installent plusieurs couches, une commande shell ./apply.sh est fournie. L'aide suivante s'affiche:

   ./apply.sh
   

5. Vous pouvez appliquer toutes les couches configurées en exécutant ./apply.sh : :. Les deux-points sont abrégés pour le premier (ou config_tf) et le dernier (power_tf). -p imprime les couches:

   ./apply.sh -p : :
   

   Elle devrait être similaire à ceci :

   directories: config_tf enterprise_tf transit_tf spokes_tf transit_spoke_tgw_tf test_instances_tf test_lbs_tf enterprise_link_tf firewall_tf transit_ingress_tf spokes_egress_tf all_firewall_tf all_firewall_asym_tf dns_tf vpe_transit_tf vpe_spokes_tf power_tf
   

6. Si vous n'en avez pas encore, obtenez une clé API pour la plate-forme et exportez-la pour qu'elle soit utilisée par Terraform :

   export IBMCLOUD_API_KEY=YourAPIKEy
   

7. Dans cette première étape, appliquez dans config_tf, enterprise_tf, transit_tf, porte-paroles et transit_spoke_tgw_tf:

   ./apply.sh : transit_spoke_tgw_tf
   

Les VPC et les sous-réseaux ont été créés. Les VPC de transit et les VPC satellites ont été connectés via un Transit Gatewaymis à disposition. Ouvrez les Clouds privés virtuels dans le navigateur. Ouvrez le VPC de transit et notez les blocs CIDR pour les préfixes d'adresse et les sous-réseaux. Examinez également les VPC d'entreprise et les VPC satellites. Ouvrez Transit Gateway et cliquez sur la passerelle Transit Gateway pour afficher la connexion entre les VPC Transit et spoke.

Créer des instances de test

Les instances de serveur virtuel VPC, les instances de serveur virtuel, sont mises à disposition pour tester la connectivité du réseau. Une instance de test sera ajoutée à chacun des sous-réseaux worker (un par zone) dans l'entreprise, le transit et chacun des rayons. Si la configuration par défaut de 3 zones et 2 branches est utilisée, 12 instances seront mises à disposition.

1. Créer les instances de test

   ./apply.sh test_instances_tf
   

Il peut être intéressant d'explorer les ressources créées à chaque étape dans la console IBM Cloud. Vous pouvez éventuellement ouvrir les Clouds privés virtuels. Cliquez avec le bouton gauche de la souris sur les instances de serveur virtuel et remarquez les instances qui ont été créées.

Tests

Ce tutoriel va ajouter des chemins de communication couche par couche. Une suite de tests pytest sera utilisée pour tester de manière exhaustive les chemins de communication. A la fin du tutoriel, tous les tests doivent réussir.

Le lecteur n'a pas besoin d'utiliser pytest pour vérifier les résultats. Suivez le tutoriel, appliquez les couches et faites confiance aux résultats décrits dans le tutoriel. Le lecteur peut toujours explorer les ressources VPC telles que les instances de serveur virtuel, les sous-réseaux et les tables de routage après leur création.

Chaque test pytest effectue une connexion SSH à l'une des instances et effectue un type de test de connectivité, comme l'exécution d'une commande curl sur l'une des autres instances. L'environnement SSH par défaut est utilisé pour se connecter aux instances. Si vous voyez des résultats de test inattendus, essayez la section pytest troubleshooting.

1. Exécutez les tests curl de zone 1 dans la suite à l'aide de l'indicateur -m (marqueurs). Choisissez les tests marqués curl, lz1 (zone de gauche 1) et rz1 (zone de droite 1).

   Vos résultats attendus sont les suivants: La connectivité au sein d'un VPC, comme enterprise <-> enterprise sera PASSED. La connectivité entre le transit et les rayons sera Passée. Cross VPC from enterprise-> transit ou rayons sera ECHEC.

   pytest -m "curl and lz1 and rz1"
   

   Voici un exemple de résultat :

   root@ea28970e0897:/usr/src/app# pytest -m "curl and lz1 and rz1"
   ===================================================== test session starts ======================================================
   platform linux -- Python 3.12.3, pytest-8.1.1, pluggy-1.4.0 -- /usr/local/bin/python
   cachedir: .pytest_cache
   rootdir: /usr/src/app
   configfile: pytest.ini
   testpaths: py
   plugins: xdist-3.5.0
   collected 36 items / 20 deselected / 16 selected
   
   py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-enterprise-z1-worker] PASSED                                   [  6%]
   py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-transit-z1-worker] FAILED                                      [ 12%]
   py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-spoke0-z1-worker] FAILED                                       [ 18%]
   py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-spoke1-z1-worker] FAILED                                       [ 25%]
   py/test_transit.py::test_curl[l-transit-z1-worker -> r-enterprise-z1-worker] FAILED                                      [ 31%]
   py/test_transit.py::test_curl[l-transit-z1-worker -> r-transit-z1-worker] PASSED                                         [ 37%]
   py/test_transit.py::test_curl[l-transit-z1-worker -> r-spoke0-z1-worker] PASSED                                          [ 43%]
   py/test_transit.py::test_curl[l-transit-z1-worker -> r-spoke1-z1-worker] PASSED                                          [ 50%]
   py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-enterprise-z1-worker] FAILED                                       [ 56%]
   py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-transit-z1-worker] PASSED                                          [ 62%]
   py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-spoke0-z1-worker] PASSED                                           [ 68%]
   py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-spoke1-z1-worker] PASSED                                           [ 75%]
   py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-enterprise-z1-worker] FAILED                                       [ 81%]
   py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-transit-z1-worker] PASSED                                          [ 87%]
   py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-spoke0-z1-worker] PASSED                                           [ 93%]
   py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-spoke1-z1-worker] PASSED                                           [100%]
   
   =================================================== short test summary info ====================================================
   FAILED py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-transit-z1-worker] - assert False
   FAILED py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-spoke0-z1-worker] - assert False
   FAILED py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-spoke1-z1-worker] - assert False
   FAILED py/test_transit.py::test_curl[l-transit-z1-worker -> r-enterprise-z1-worker] - assert False
   FAILED py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-enterprise-z1-worker] - assert False
   FAILED py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-enterprise-z1-worker] - assert False
   ========================================= 6 failed, 10 passed, 20 deselected in 38.76s =========================================
   

Une modification de la configuration réseau peut prendre plusieurs exécutions de test pour que le système réseau VPC sous-jacent devienne cohérent. Si vous ne voyez pas les résultats attendus au départ, préparez-vous à réexécuter le test plusieurs fois.

Les r- et l- représentent r ight et l eft. La partie centrale du nom identifie l'entreprise, le transit, spoke0, spoke1, ... Les zones z1, z2, ... identifient la zone. Le test va établir une connexion SSH à l'instance de gauche. Sur l'instance de gauche, la connectivité à l'instance de droite est tentée. test_curl effectue une connectivité curl sur l'instance de gauche vers l'instance de droite.

En résumé, le test test_curl[l-enterprise-z1 -> r-transit-z1] :

1. Connexion SSH à une instance de test dans la zone d'entreprise 1.
2. Exécutez une boucle pour la zone de transit 1.
3. Affirmez que la chaîne de retour contient l'ID de la zone de transit 1 pour marquer la réussite ou l'échec.

Le fichier README.md du référentiel GitHub associé contient plus de détails et le code source.

Connectez Enterprise à Transit via Direct Link et Transit Gateway

Mettez à disposition un IBM Cloud® Direct Link à l'aide de Transit Gateway.

IBM Cloud® Direct Link est un chemin de données sécurisé à haut débit permettant de connecter une entreprise à IBM Cloud. Dans ce tutoriel, Transit Gateway est utilisé pour la distribution. L'utilisation de Transit Gateway est facultative pour une connexion sur site.

L'entreprise dans ce tutoriel est simulée avec un autre VPC. La connexion de cette entreprise simulée (en fait un autre VPC) via Transit Gateway garantit une expérience très proche de celle que vous feriez avec un Direct Link.

1. Appliquez la couche enterprise_link_tf:

   ./apply.sh enterprise_link_tf
   

2. Exécutez les tests curl de la zone 1 dans la suite my à l'aide de l'indicateur -m (marqueurs). Choisissez les tests marqués curl, lz1 (zone de gauche 1) et rz1 (zone de droite 1).

   Vos résultats attendus sont les suivants: Connectivité au sein d'un VPC, transit <-> spoke (s), entreprise <-> transit, spoke (s) <-> réussite (s) spoke (s) mais échec (s) de l'entreprise <-> spoke (s).

   pytest -m "curl and lz1 and rz1"
   

Connecter l'entreprise à Spoke (s) via Transit NFV Firewall-Routeur

La motivation pour un VPC de transit pour le trafic <-> cloud d'entreprise consiste généralement à router, inspecter, surveiller et consigner le trafic réseau. Dans cette étape, un dispositif pare-feu-routeur sera installé dans chaque zone du VPC de transit.

Routeur NFV

Mettez à disposition les dispositifs de routeur de pare-feu. Une table de routage d'entrée pour Transit Gateway a été ajoutée au VPC de transit comme indiqué par les lignes en pointillés. Un sous-réseau a été créé dans chacune des zones du VPC de transit pour contenir le pare-feu-router.

La connectivité entre l'entreprise et un serveur satellite est assurée via une instance de routeur de pare-feu NFV, Network Function Virtualization, dans le cloud privé virtuel de transit. En production, vous pouvez en choisir un dans le catalogue ou apporter le vôtre. Cette démonstration utilise une image stockée Ubuntu avec des tables IP de noyau configurées pour transférer tous les paquets de la source vers la destination. Dans ce tutoriel, aucune inspection de pare-feu n'est effectuée.

La configuration Terraform va configurer l'instance firewall-router avec allow_ip_spoofing. Vous devez activer les contrôles d'usurpation d'adresse IP avant de continuer.

1. Appliquez la couche firewall_tf:

   ./apply.sh firewall_tf
   

2. Exécutez la suite de tests.

   Vos résultats attendus sont les suivants: Connectivité au sein d'un VPC, entreprise-> transit, entreprise <-> passe de la même zone. Mais tous les transits-> parlés, tous les transits-> entreprises échouent en raison de problèmes de routage asymétrique.

   pytest -m "curl and lz1 and (rz1 or rz2)"
   

   La deuxième partie de ce tutoriel achemine tout le trafic VPC <-> différent via le routeur pare-feu et résout ces problèmes. Mais d'abord, il est important d'apprendre ce qui se passe.

Suppression du pare-feu pour le trafic de destination Transit

IBM Cloud VPC utilise le routage basé sur l'état des normes de l'industrie pour le suivi des connexions TCP sécurisées. Il est nécessaire que les connexions TCP utilisent le même chemin d'accès sur le chemin d'accès que sur le chemin de sortie. Une exception est Direct Server Return utilisé par des routeurs tels que Network Load Balancers. Il permet aux connexions entrantes de l'entreprise de passer par le pare-feu vers l'instance de test de transit, puis de revenir directement à l'émetteur.

Cela n'aide pas le trafic provenant de l'instance de test de transit passant par Transit Gateway, puis revenant via le routage Ingress vers le pare-feu-router. Cette connexion est bloquée au niveau du pare-feu-routeur (3) et ne sera pas réacheminée vers l'agent comme indiqué en rouge ci-dessous. Le trafic de transit-> entreprise et de transit-> satellite sont défaillants.

Une solution possible consiste à arrêter d'envoyer du trafic destiné au VPC de transit vers le routeur pare-feu. Les routes d'entrée larges pour le transit acheminent actuellement le trafic vers le routeur pare-feu. Des routes plus spécifiques peuvent être ajoutées pour le transit vers Déléguer au comportement par défaut-envoyer directement à la destination prévue au lieu du pare-feu-routeur.

Ce diagramme illustre le flux de trafic souhaité pour cette étape. Seule l'entreprise <-> spoke passe par le pare-feu:

1. enterprise <-> transit
2. spoke <-> transit
3. spoke <-> spoke
4. entreprise <--transit firewall-router--> parlé

Ce routage peut être réalisé en ajoutant ces routes à la table des routes d'entrée de transit:

1. Pour observer la valeur en cours de la table de routage Ingress, consultez les tables de routage pour VPC dans la console IBM Cloud. Sélectionnez le VPC transit dans la liste déroulante, puis sélectionnez la table de routage tgw-ingress.

2. Apportez les modifications à la table de routage en appliquant la couche transit_ingress:

./apply.sh transit_ingress_tf

1. Actualisez l'affichage du navigateur de la table de routage pour observer les nouvelles routes.

2. Exécutez la suite de tests.

   Vos résultats attendus sont: Tous les tests aboutiront à REUSSITE.

   pytest -m "curl and lz1 and (rz1 or rz2)"
   

Il est intéressant de noter la façon dont le trafic interzones circule entre l'entreprise et les rayons dans la configuration. L'entreprise envoie le trafic à la zone appropriée et via le pare-feu-routeur via le routage Ingress dans le VPC de transit. Transit Gateway a appris que 192.168.0.0/16 est disponible dans toutes les zones et sera routée vers le VPC de transit à l'aide des routes d'entreprise annoncées dans la même zone que le satellite, comme illustré dans le diagramme ci-dessous:

Récapitulatif de routage

Le routage de base est terminé:

• enterprise <-> transit
• transit <-> rayon (s)
• enterprise < -- (pare-feu de transit-routeur)-- > spoke

Notes et conclusions sur la production

L' architecture de référence VPC pour IBM Cloud for Financial Services contient beaucoup plus de détails sur la sécurisation des charges de travail dans IBM Cloud.

Quelques changements évidents à apporter:

• Les blocs CIDR ont été choisis pour plus de clarté et de facilité d'explication. Les zones de disponibilité de la région multizone peuvent être 10.0.0.0/10, 10.64.0.0/10, 10.128.0.0/10 pour conserver l'espace adresse. L'espace adresse des noeuds worker peut être étendu aux dépens de l'espace de pare-feu, DNS et VPE.
• Les groupes de sécurité de chacune des interfaces réseau pour les instances de serveur virtuel d'agent, les passerelles de noeud final privé virtuel, les emplacements DNS et les pare-feux doivent tous être soigneusement pris en compte.
• Les listes de contrôle d'accès au réseau pour chaque sous-réseau doivent être soigneusement prises en compte.

Des adresses IP flottantes ont été connectées à toutes les instances de test pour prendre en charge les tests de connectivité via SSH. Cela n'est pas requis ou souhaitable en production.

Implémentez des règles de restrictions contextuelles pour contrôler davantage l'accès à toutes les ressources.

Dans ce tutoriel, vous avez créé un VPC concentrateur et un ensemble de VPC satellites. Vous avez identifié les zones de disponibilité requises pour l'architecture et créé un ensemble de sous-réseaux dans les VPC. Vous avez créé un pare-feu VPC de transit dans chaque zone pour acheminer le trafic. Des instances de test ont été utilisées pour vérifier la connectivité et identifier les problèmes potentiels. Des routes de table de routage ont été utilisées pour identifier les chemins de trafic requis.

Suppression de ressources

Il n'est pas nécessaire de supprimer les ressources si vous prévoyez de poursuivre avec la deuxième partie de ce tutoriel.

Exécutez terraform destroy dans tous les répertoires dans l'ordre inverse à l'aide de la commande ./apply.sh :

./apply.sh -d : spokes_egress_tf

Extension du tutoriel

Il est recommandé de passer à la deuxième partie de ce tutoriel, dans laquelle tout le trafic VPC est acheminé via le routeur de pare-feu, VPE for VPC et DNS sont examinés.

Votre architecture sera probablement différente de celle présentée, mais elle sera probablement construite à partir des composants fondamentaux discutés ici. Idées pour développer ce tutoriel:

• Intégrez l'accès Internet public entrant à l'aide de IBM Cloud® Internet Services.
• Ajoutez la capture des journaux de flux dans le transit.
• Placez chacun des rayons dans un compte distinct dans une entreprise.
• Forcez une partie du trafic parlé à parler à travers le pare-feu et d'autres pas à travers le pare-feu.
• Remplacez les instances de serveur virtuel d'agent par Red Hat OpenShift on IBM Cloud et l'équilibreur de charge VPC.
• Forcez tout le trafic sortant via le pare-feu dans le VPC de transit et via des passerelles publiques.

Contenu connexe

• IBM Cloud for Financial Services
• Comment déployer des charges de travail isolées sur plusieurs emplacements et régions
• Public front end et private backend dans un cloud privé virtuel,
• Virtualisation de la fonction réseau
• Concentrateur privé et satellite avec VNF transparent et trafic satellite à satellite