Dans les deux premières parties de ma série “NSX-T pour les nuls”, nous avons découvert d’abord comment installer le minimum vital pour un environnement fonctionnel. Je vous propose de découvrir dans cette troisième partie la création d’un segment “service”, l’ajout d’un service DHCP à notre routeur TIER0 et enfin l’intégration d’une VM dans cet environnement.
Pour commencer et pour plus de lisibilité, je vous conseille de lire les deux précédents articles, histoire de pouvoir suivre la progression et, si vous débutez, comprendre les concepts que l’on va manipuler. Vous pouvez trouver le premier ici, le second là.
Nous sommes arrivé à monter un routeur TIER0 opérationnel en fin d’article précédent. Son interface de sortie est branchée sur un VLAN/Subnet dédié 192.168.1.0/24 et il a l’IP 192.168.1.250. Il dispose d’une route par défaut qui pointe vers mon routeur global sous pfSense. De même, ce dernier connait l’identité du routeur TIER0 et sait qu’il peut atteindre des réseaux de type 10.10.10.0/24 via cette nouvelle gateway :
Dans la pratique cela signifie que le routeur TIER0 est capable d’être connecté “coté virtualisation” à des segments qui sont dans ce sous-réseau, sans être obligé de jouer du NAT, uniquement via du routage (static pour le coup, pas de BGP ici, cela nous emmènerait trop loin pour ces tutos). Si vous avez le schéma en tête, on peut continuer, sinon, refaite une petite lecture de la partie 2 ^^ !
Création du segment et configuration du DHCP
Nous allons créer un nouveau segment en 10.10.10.16/28 (histoire que ce soit plus fun qu’un banal /24 qui commence par 0 !). Ce segment/logical-switch va nous permettre d’héberge quelques VMs de test. On se retrouve dans la section “Networking”, partie “Segments” et on lance la création.
Le segment dispose d’une gateway par défaut (qui est en fait l’interface du routeur tier0) à 10.10.10.30. Nous avons à notre disposions un range de 14 machines disponible. Tant qu’à faire on va créer un DHCP pour ce segment, histoire de simplifier la configuration des VMs que l’on va connecter dessus. Première chose à faire, déclarer le fameux DHCP. Dans la section “Networking->Ip Address management->DHCP”, on va créer notre “dhcp0”. On choisi une IP en dehors de notre petit subnet de test, histoire de ne pas griller d’IP dedans. Je n’ai pas trop creusé, mais j’imagine que dans ce cas, le tier0 agit comme un DHCP helper vers les segments sur lesquels il est connecté. Une fois créé, on va le rattacher à notre routeur tier0, pour l’activer.
Enfin, et pour terminer, il va falloir indiquer au dhcp quel range il doit servir. On retourne dans notre segment et dans la partie “subnet”, nous allons ajouter un range DHCP à celui que nous avons créé au départ. Job’s done, notre dhcp est connecté à notre tier0, il sait quel range il doit servir. C’est encore un peu “roots” car le dhcp n’est pas en état de fournir des infos complémentaires comme le fqdn, les serveurs DNS etc. , mais bon, c’est déjà ça. Je n’ai pas encore creusé cet aspect des choses, mais pour le moment, la seule solution que j’ai trouvé en mode interface graphique est de “sortir” des nouveau menus de NSX Manager et aller éditer le dhcp directement dans la section “Advanced Networking & Security”.
Connexion d’une VM
Et si on testait l’ajout d’un VM, maintenant ? La c’est plutôt simple, puisqu’il suffit de retourner dans vSphere et connecter l’interface de la machine sur le logical switch créé tout à l’heure. La je vous laisse juste avec les screenshot, vous savez faire ça, vous êtes déjà tous des experts vSphere !!
Vous noterez que la VM récupère correctement une IP dhcp et qu’elle ping son routeur (interface du tier0) ainsi que le routeur pfSense, en dehors du périmètre NSX-T ! Ca marche du premier coup ? Pffff… c’est tellement simple quand on écrit sur un blog, tout le monde vous crois sur parole… ou pas :)
Conclusion
Plus sérieusement, il m’a fallut quelques essais pour faire les choses parfaitement “dans l’ordre” conformément à la logique NSX-T. Certes la documentation est vraiment bien faite sur VMware.com, mais le cheminement, il, est assez obscure au début.
D’une manière générale, NSX-T est un véritable monde et l’objectif de cette série d’article était juste de vous faire “toucher du doigt” la philosophie globale du produit ainsi que l’ergonomie du NSX Manager. Cependant, pour vraiment tirer pleinement partie d’un tel produit, il est impossible de passer à coté de son jeu d’API REST, qui sont, au final, la meilleur façon de consommer du réseau virtuel. Après l’installation chez nous (rendez-vous sur le premier billet de chronique pour en savoir plus), il faudra qu’on s’attelle à cette nouveau dimension… une autre paire de manche que de faire des copies d’écran et de cliquer sur des menus ^^
Je vous ferais peut-être un quatrième article “bonus” pour vous présenter notre travail actuel sur la mise en place des règles générales de micro-segmentation, mais ce ne sera pas tout suite, j’attends d’être plus acéré sur ce sujet avant de vous en parler !