Vous avez un frontal web qui publie une application non sécurisée ? vous voulez centraliser la gestion de vos certificats publics ? Les fonctions de load balancing de NSX-T sont là pour vous aider. Petit tutoriel pour réaliser un offloading SSL très simplement en quelques minutes.
Quand on lit la documentation de NSX-T en diagonal pour en faire le tour des fonctions “au cas zoo”, on passe souvent à coté de petites perles qui simplifient la vie et permettent surtout de gagner du temps et de l’argent. Le “offloading SSL”, c’est à dire la possibilité de mettre en place un frontal reverse-proxy assurant la sécurisation SSL à la place des serveurs applicatifs, fait partie de ces spécificités bien venues et très pratiques au sein de la fonction beaucoup plus large de load balancing.
On importe le certificat SSL
Un petit use case chez nous m’a donné l’idée de creuser un peu cet aspect en vLab que j’avais déjà repéré auparavant. La première chose à faire consiste à importer le certificat SSL que l’on va utiliser frontalement avant de rediriger le flux HTTP sur la machine cible. Pour se faire, allez dans le menu “system” de votre NSX et rendez vous dans la section “Certificates”. Importez votre crt et votre clef privée en suivant les instructions de la boite de dialogue. A noter ici que vous pouvez intégrer dans le champ “certificate” toute la chaine de certification en faisant attention à bien la concaténer dans le sens serveur-cert->intermédiaire-cert->rootca-cert. Laissez bien activé l’option “service certificate” pour pouvoir ensuite l’utiliser dans la définition de votre service.
On définit notre loadbalancer
Ensuite, on va créer notre load balancer, dans la section “Network->Load Balancing”. Vous devez indiquer le router TIER1 qui va porter ledit LB. On peut voir cela comme une sorte de conteneur dans lequel vous allez intégrer ensuite des “virtual servers”, définitions plus opérationnelles des services de LB. Ensuite on va s’attaquer à la création d’un pool de serveurs. Derrière ce pool se cache l’ensemble des serveurs sur lesquels on va rediriger le traffic fontal et la méthode d’équilibrage, mais ici, notre objectif est beaucoup plus simple, tout le traffic sera redirigé sur une seule machine. Le pool ne se compose donc que d’un serveur cible, qui pour le test est accédé via son port HTTP/80 (un service nginX sur une Debian), non sécurisé, donc. Vous noterez ici qu’on créé un pool “L7-HTTP”, ce qui va nous donner la possibilité, justement, de faire du offloading. Les autres options sur la couche transport (L4) sont là pour du load balancing pur TCP/UDP sans intelligence particulière dans le contenu des payloads.
Création du virtual server
Enfin, on arrive à la partie la plus intéressante, la création du virtual serveur. Ce virtual server va être rattaché au loadbalancer précédemment créé et utilisera le pool de serveur décrit plus haut. On indique une IP d’accès, à prendre où vous le souhaitez, en fonction de vos besoins. N’oubliez pas de créer/ajuster vos règles de firewall pour donner l’accès à cette IP aux clients souhaités. Pensez- aussi que la fonction LB peut vous aider à sécuriser aussi l’accès aux serveurs au sein du pool, vous ouvrez l’accès à l’IP frontale, mais les serveurs eux-mêmes peuvent rester totalement interdits d’accès et donc protégés (hormis le service exposé bien sûr).
Cliquez enfin sur le bouton “SSL configuration” et choisissez, dans la partie “Client SSL”, le certificat précédemment importé. C’est fini ! La fonction LB est installée et assure la fonction de reverse-proxy et offloading SSL. Vous pouvez aussi noter qu’il est possible de demander en complément à chaque client un certificat personnel qui sera vérifié à la volée, mais c’est un autre sujet ^^
Nous on s’amuse bien, alors, amusez-vous bien aussi !
PS : petite pensée pour nos collègues de Rouen… qui ne s’amusent pas du tout en ce moment, par contre…
4.5