Je continue ma série sur les personnes de qualité avec qui je suis toujours en contact, d’une façon ou d’une autre, et ce depuis des années. Aujourd’hui, il s’agit de Timo Sugliani, architecte/expert cloud et accessoirement insider VMware pendant au moins 15 ans le crois bien.
Nous exploitons déjà depuis plus de deux ans un cluster Kubernetes basé sur un empilement très complexe de couches OpenShift, mais aussi vSphere/VSAN/NSX-T, qui apporte un niveau de sécurité élevé avec le CNI Antrea (qui s’occupe du réseau du cluster Kube). Cela nécessite aussi un niveau d’expertise globalement très élevé, sans même parler du prix de ces couches…
J’étais passé à coté lors de la sortie de NSX-T 3.1 et ça valait le coup d’en parler : vous pouvez désormais créer vos propres listes blanches de domaines accessibles à vos machines dans vos règles NSX. Voyons ça de plus près.
Rappelez-vous. Mais si, rappelez-vous là, il y a quelques jours, on avait mis le doigt sur un comportement très bizarre et inquiétant du NAT NSX-T. Nous venons d’avoir un retour officiel du support VMware. C’est bien un bug connu, mais sa portée est plus large qu’initialement constaté par les équipes NSX. petite explication …
Salut les loulous ^^ . Il y a quelques jours, nous avons été alerté par la cellule Cyberveille santé au sujet d’une IP publique sous notre responsabilité ayant un comportement pour le moins étrange : des centaines de ports TCP y apparaissaient « ouverts » et répondaient donc à leurs scans automatisés. Ceci fut le début d’une enquête qui a duré plus d’une semaine, pour aboutir à une découverte assez fondamentale sur NSX-T … prenez la pillule rouge avec moi …
Hello mesdames/messieurs, nous en étions resté à un souci assez compliqué à expliquer et comprendre techniquement au sujet de l’implémentation de NSX-T sur du distributed vSwitch 7.0. Apparemment mes explications ont été suffisamment claires pour que des experts me ping/contactent sur Twitter et Slack. Et on a fini par trouver ! Enfin, quand je dis « on » … mais trêve d’intro, passons aux explications hyper-intéressantes.
Je vous ai menti, je m’en veux, j’en suis désolé. A la fin de la partie 1 de cette chronique, tout semblait rouler et les problèmes d’installation de NSX-T étaient en passe d’être résolus, étant donné que la cause, le MTU, était identifiée. Mais en fait non, le problème était plus profond que cela. Je vous explique.
Hello les gens ! un grand bonjour, après plus de 3 mois de pause motivation, changement de perspective et re-faisage de monde. La rentrée est là, et les chantier techniques reprennent, avec des jolis projets, notamment, le recyclage de nos vieux VxRail et la mise en place d’un environnement tout neuf avec du VSAN, du NSX-T, du Cloud Director 10.3. Ce billet sera peut-être un peu « fourre-tout », mais il me permet de me remettre le pied à l’étrier du « RETEX » (ça me manquait, en fait) à la sauce vBlog.io ^^.
Notre production NSX-T évolue et s’adapte de plus en plus à toutes nos contraintes opérationnelles. Récemment, il nous a fallu préparer l’arrivée d’une interconnexion entre des segments et un prestataire externe chargé de la supervision des machines connectées. Il a donc fallu se plonger rapidement dans le fonctionnement et l’implémentation d’IPsec pour mettre en place les tunnels associés. C’est comme si c’était fait !
Quel meilleur timing que cette fin de confinement annoncée pour donner signe de vie et essayer de reprendre un rythme de publication plus digne de vous sur ce blog ? Je vous propose donc de relancer tout cela aujourd’hui avec un article technique sur NSX-T, encore, et plus spécifiquement au sujet de la fameuse directive « Apply-To » qu’on trouve dans la section des stratégies et règles de sécurité.