Objectifs

• Comprenez les concepts derrière un modèle de concentrateur et de serveur satellite basé sur VPC pour la gestion de l'ensemble du trafic VPC vers VPC.
• 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.
• Comprenez l'utilisation d'un équilibreur de charge réseau pour un routeur pare-feu à haute disponibilité et évolutif.
• Utilisez les règles de routage et de transfert du service DNS pour créer un système de résolution de nom à l'architecture saine.

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,

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.
  • droits requis pour gérer les autorisations.

Résumé de la première partie

Dans la première partie de ce tutoriel, nous avons soigneusement planifié l'espace adresse des VPC Transit and spoke. L'architecture basée sur les zones est présentée ci-dessous:

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

Cette opération a été effectuée avec Direct Link, Transit Gateway et le routage VPC. Toutes les zones sont configurées de la même manière et le diagramme ci-dessous montre les détails de la zone 1:

Le routage CIDR 10.1.0.0/16 couvre le transit et les rayons et est transmis via Direct Link à l'entreprise en tant que route annoncée. De même, le CIDR 192.168.0.0/24 couvre l'entreprise et est transmis via Transit Gateway aux rayons en tant que route annoncée.

Les routes de sortie dans les branches routent le trafic vers le routeur de pare-feu. Routes d'entrée dans le trafic d'entreprise de la route de transit <-> spoke via le pare-feu-router.

Mise à disposition de ressources VPC initiales pour le routage de tout le trafic VPC intra via le routeur pare-feu

Souvent, une entreprise utilise un VPC de transit pour surveiller le trafic avec le routeur de pare-feu. Dans la première partie, seul le trafic d'entreprise <-> spoke transite par le routeur pare-feu de transit. Cette section concerne le routage de tout le trafic VPC vers VPC via firewall-router.

Ce diagramme illustre le flux de trafic mis en oeuvre dans cette étape:

Tout le trafic entre les VPC passe par le pare-feu-router:

• enterprise <-> spoke.
• enterprise <-> transit.
• transit <-> spoke.
• spoke <-> spoke dans un VPC différent.

Le trafic au sein d'un VPC ne passe pas par le pare-feu.

Si vous continuez à partir de la première partie, notez spécialement la configuration dans le fichier terraform.tfvars: all_firewall = true.

Correction du routage interzone

Comme indiqué précédemment pour qu'un système soit résilient en cas de défaillance d'une zone, il est préférable d'éliminer le trafic interzone. Si la prise en charge de zones croisées est requise, des routes de sortie supplémentaires peuvent être ajoutées. Le problème du trafic de type rayon 0 à rayon 1 est illustré dans ce diagramme:

Le chemin vert est un exemple de routage vers la zone 1 10.1.1.4de la zone 2 de la branche d'origine 10.2.0.4 vers la zone 1 de la branche d'origine 10.1.1.4. La route de sortie correspondante est:

Zone	Destination	tronçon suivant
Dallas10.0.0.0/810.2.15.196

En se déplaçant de la gauche vers la droite, on sélectionne le pare-feu-routeur dans la zone centrale, zone 2, du diagramme. Sur le chemin de retour, la zone 1 est sélectionnée.

Pour résoudre ce problème, il est nécessaire d'ajouter quelques routes plus spécifiques afin de forcer les zones de nombre supérieur à router vers les pare-feux de numéro de zone inférieur lorsqu'une destination de numéro de zone inférieur est spécifiée. Lors du référencement d'une zone numérotée égale ou supérieure, le routage vers le pare-feu se poursuit dans la même zone.

Routes dans la table de routage de sortie par défaut de chaque rayon (illustré pour Dallas/us-south):

Zone	Destination	tronçon suivant
Dallas10.1.0.0/1610.1.15.196
Dallas10.1.0.0/1610.1.15.196
Dallas10.2.0.0/1610.2.15.196

Ces routes vont également corriger un problème de routage asymétrique < -- > satellite de transit similaire. Considérez l'agent de transit 10.1.15.4-> l'agent spoke 10.2.0.4. Le trafic provenant de l'agent de transit dans la zone 1 choisira le pare-feu-routeur dans la zone 1 (même zone). Lors du trajet retour au lieu du pare-feu-routeur dans la zone 2 (même zone), le pare-feu-routeur dans la zone 1 sera utilisé.

1. Appliquez la couche all_firewall_asym:

   ./apply.sh all_firewall_asym_tf
   

2. Exécutez la suite de tests.

   Vos résultats attendus sont: tous les tests PASSÉS, exécutez-les en parallèle (-n 10):

   pytest -n 10 -m curl
   

Tout le trafic entre les VPC est désormais acheminé via les routeurs de pare-feu.

Pare-feu haute disponibilité (HA)-Routeur

Pour éviter qu'un routeur de pare-feu ne devienne le goulot d'étranglement des performances ou un point de défaillance unique, il est possible d'ajouter un équilibreur de charge réseau VPC pour distribuer le trafic aux routeurs de pare-feu zonaux afin de créer un routeur de pare-feu à haute disponibilité et haute disponibilité. Consultez la documentation de votre routeur de pare-feu pour vérifier qu'il prend en charge cette architecture.

Ce diagramme illustre une zone unique avec un équilibreur de charge de réseau (NLB) configuré en mode route devant deux routeurs de pare-feu. Pour voir cette construction, il est nécessaire de modifier la configuration et de l'appliquer à nouveau.

1. Modifiez ces deux variables dans config_tf/terraform.tfvars:

   firewall_nlb                 = true
   number_of_firewalls_per_zone = 2
   

   Cette modification entraîne le changement de l'adresse IP du routeur de pare-feu à partir de l'instance de routeur de pare-feu utilisée précédemment vers l'adresse IP de l'équilibreur de charge de réseau. Le changement d'adresse IP doit être appliqué à un certain nombre de routes de table de routes VPC dans les VPC de transit et satellites. Il est préférable d'appliquer toutes les couches précédemment appliquées:

2. Appliquez toutes les couches via la couche all_firewall_asy_tf:

   ./apply.sh : all_firewall_asym_tf
   

Observez les modifications apportées:

1. Ouvrez les équilibreurs de charge pour VPC.
2. Sélectionnez l'équilibreur de charge dans la zone 1 (Dallas 1/us-south-1), il a le suffixe fw-z1-s3.
3. Notez les adresses IP privées.

Comparez les adresses IP privées avec celles de la table de routes d'entrée VPC de transit:

1. Ouvrez les clouds privés virtuels.
2. Sélectionnez le VPC de transit.
3. Cliquez sur Gérer les tables de routage.
4. Cliquez sur la table de routage tgw-ingress. Notez que l'adresse IP du tronçon suivant correspond à l'une des adresses IP privées de l'équilibreur de charge de réseau.

Vérifiez la résilience:

1. Exécutez les tests de la zone 1 du rayon 0:

   pytest -k r-spoke0-z1 -m curl
   

2. Ouvrez les instances de serveur virtuel pour VPC
3. Arrêtez le trafic vers l'instance de pare-feu 0 en spécifiant un groupe de sécurité qui n'autorisera pas le port entrant 80. Localisez l'instance avec le suffixe fw-z1-s3-0 et ouvrez la vue de détails:
   1. Faites défiler l'écran vers le bas et appuyez sur la touche de modification du crayon en regard de l'interface réseau
   2. Décochez la case x-fw-inall-outall
   3. Vérifiez x-fw-in22-outall
   4. Cliquez sur Sauvegarder.
4. Exécutez à nouveau le pytest. Il indique les échecs. Il faut quelques minutes à l'équilibreur de charge de réseau pour arrêter le routage du trafic vers l'instance qui ne répond pas, auquel cas tous les tests réussiront. Continuez à attendre et à exécuter pytest jusqu'à ce que tous les tests aient réussi.

Le pare-feu d'équilibreur de charge de réseau n'est plus requis. Retirez le pare-feu d'équilibreur de charge de réseau:

1. Modifiez ces deux variables dans config_tf/terraform.tfvars:

   firewall_nlb                 = false
   number_of_firewalls_per_zone = 1
   

2. Appliquez toutes les couches via la couche all_firewall_asy_tf:

   ./apply.sh : all_firewall_asym_tf
   

Remarque sur l'équilibreur de charge de réseau configuré en mode de routage

Le mode de routage NLB réécrit les entrées de la table de routage-en conservant toujours l'adresse IP du dispositif NLB actif dans la table de routage lors d'un basculement. Mais cela n'est effectué que pour les routes dans le VPC de transit qui contient l'équilibreur de charge de réseau. Le satellite possède des routes de sortie qui ont été initialisées avec l'une des adresses IP du dispositif NLB. Le prochain tronçon spoke ne sera pas mis à jour lors de la reprise en ligne du dispositif d'équilibreur de charge de réseau.

Il sera nécessaire de gérer une route d'entrée dans le VPC de transit qui sera réécrite par l'équilibreur de charge de réseau pour refléter le dispositif actif. La route de sortie du rayon va délivrer des paquets à la zone correcte du VPC de transit. Le routage dans la zone VPC de transit trouvera la règle d'entrée correspondante qui contiendra le dispositif actif.

Vous trouverez ci-dessous la table de routage VPC Ingress de transit dont il a été question précédemment. Le prochain tronçon sera mis à jour avec le dispositif NLB actif. Notez que Dallas 3 a un changement écrit par le service NLB route mode pour refléter l'appliance active.

L'équilibreur de charge de réseau requiert la création d'une autorisation IAM qui permet à l'équilibreur de charge de réseau d'écrire dans le VPC. Cette autorisation a été créée par le script apply.sh. Voir Création d'un équilibreur de charge de réseau avec le mode de routage pour plus de détails sur la configuration effectuée par le script.

Le pool d'équilibreur de charge de réseau en mode route doit être configuré avec Type de persistance de session défini sur null.

DNS

Le service IBM Cloud DNS Services est utilisé pour convertir des noms en adresses IP. Dans cet exemple, un service DNS est créé dans le cloud. La zone DNS cloud.example.com est créée et le VPC de transit est ajouté en tant que réseau autorisé. Les enregistrements DNS des instances de cloud sont ajoutés à cloud.example.com. Par exemple, un enregistrement A est créé pour l'agent spoke de 0 dans la zone 1 qui aurait le nom complet spoke0-z1-worker.cloud.example.com.

Consultez A propos du partage DNS pour les passerelles VPE. Le VPC de transit est activé en tant que concentrateur DNS. Chaque VPC satellite est configuré avec une liaison de résolution DNS au concentrateur VPC de transit. Cette opération va configurer les paramètres DHCP de cloud privé virtuel à rayons pour que les serveurs DNS soient les résolveurs personnalisés de cloud privé virtuel de transit.

./apply.sh dns_tf

pytest -n 10 -m dns

passerelles de point de terminaison virtuel

VPC permet un accès privé aux services IBM Cloud via Virtual Private Endpoint (VPE) for VPC. Les passerelles VPE permettent le contrôle d'accès au réseau à granularité fine via des contrôles IBM Cloud VPC standard:

• Security Groups.
• Listes de contrôle d'accès au réseau VPC.
• Tables de routage et routes.

Une zone DNS est créée pour chaque passerelle VPC VPE. La zone DNS est automatiquement ajoutée au service DNS privé associé au VPC. Chaque VPC satellite possède une configuration DNS bound pour le VPC de transit. Cela permet de partager la zone DNS VPE spoke avec le VPC de transit.

1. Créez une instance IBM Cloud Databases for PostgreSQL et des VPE pour le transit et chacun des VPC satellites, en appliquant les couches vpe_transit_tf et vpe_porte-parole:

   ./apply.sh vpe_transit_tf vpe_spokes_tf
   

2. Il existe un ensemble de tests vpe et vpedns qui sont disponibles dans le script pytest. Le test vpedns vérifie que le nom DNS d'une instance Databases for PostgreSQL se trouve dans le bloc CIDR privé du VPC conteneur. Le test vpe exécute une commande psql pour accéder à l'instance Databases for PostgreSQL à distance. Test vpe et vpedns de la zone 1 du rayon 0:

   • Résultats attendus tous les tests ont réussi

   pytest -m 'vpe or vpedns' -k spoke0-z1
   

Tous les tests de ce tutoriel doivent maintenant réussir. Il y en a pas mal. Exécutez-les en parallèle:

pytest -n 10

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.1.0.0/10, 10.64.0.0/10, 10.128.0.0/10 pour économiser de l'espace adresse. De même, 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 acheminé tout le trafic VPC via un pare-feu VPC de transit. Un service DNS a été créé pour le concentrateur VPC de transit et chaque VPC satellite était lié au VPC de transit.

Suppression de ressources

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

./apply.sh -d : :

Extension du tutoriel

Votre architecture peut ne pas être la même que 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 Flow Logs for VPC 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