Aviatrix, pour une réconciliation du réseau avec le cloud ?

Faire du réseau sur le cloud, ce n’est quand même pas toujours facile. Des limitations à tour de bras, et peu de visibilité. Mais ça, c’était avant !

Le cloud, c’est génial. On peut pousser une machine virtuelle en un rien de temps, puis deux, puis trois… Puis on segmente, on en met à gauche, à droite, en haut, en bas.

Aïe, comment je les raccorde ? Ah et au fait, on vient de racheter une boîte. Pas de chance, ils font de l’Azure et nous, de l’AWS. Mais pas de soucis pour tout raccorder ensemble hein ?

Et non, pas si simple !

Qu’y a-t-il de compliqué à faire du réseau dans le Cloud ?

Si vous faites du réseau aujourd’hui, il y a de grandes chances pour que vous segmentiez votre réseau en sous-réseaux, puis en VLANs, VRF, avec du routage et des pares-feux entre tout ce petit monde. Et entre deux datacenters, vous avez le choix : routage ou raccordement en fibre noire par exemple…

Bref, c’est vous le patron.

Vous passez dans le Cloud ? Oubliez (presque) tout. Vous dépendez des CSP (Cloud Service Provider) comme AWS, Azure, GCP… qui ont chacun leurs propres manières de faire les choses.

Parlons transitivité

Chez tous les fournisseurs Cloud, votre Datacenter virtuel est organisé en plusieurs « Virtual Private Cloud » chez AWS/GCP, ou en « Azure Virtual Network » chez Microsoft Azure.

Chacune de ces entités contient un « CIDR » (Classless Inter-Domain Routing). Un sous-réseau IP en somme, 10.1.0.0/16 par exemple, dans lequel se trouveront vos ressources, machines virtuelles et autres.

Ces VPCs/VNETs sont habituellement découpés selon votre organisation, vous aurez par exemple un VPC/VNET pour un projet A, un autre pour un projet B, etc…

Vient le moment de les connecter ensemble. Imaginons 3 VPC/VNET :

En utilisant les mécanismes natifs de peering, on peut faire communiquer A avec B, et B avec C.

Est-ce que A peut communiquer avec C à travers B ? Et non ! La transitivité n’existe pas. Du moins pas nativement. On y reviendra.

Pour que A communique avec C, il nous faut un peering supplémentaire :

Très bien. Maintenant disons que chaque projet doive bénéficier d’un environnement de PréProd.

Aucun problème :

6 VPC donc? Cela fera 15 peerings à configurer.

10 VPC ? 45 peerings.

On en déduit de manière totalement triviale et empirique la formule suivante pour déterminer le nombre de connexions suivant le nombre de VPC/VNET ‘N’ :

Est-ce possible d’insérer un pare-feu pour filtrer les flux ? Clairement, non.

Comment fait-on ?

Allons voir du côté d’AWS.

Nous avons à notre disposition la « Transit Gateway »[i]. Comme son nom l’indique, elle permet d’interconnecter des VPCs/VPNs entre eux et d’apporter de la transitivité :

Parfait, la voilà notre solution ! Oui, mais…

• Votre Transit Gateway est une boîte noire. Vous voulez faire un test de ping, traceroute, netcat, curl ? Non. Dur dur d’être un ingénieur réseau dans le Cloud !
• Du Netflow pour visualiser vos flux ? Non plus.
• Du peering intra-region ? Alors depuis très récemment, oui ! Cette fonctionnalité a été présentée lors de l’AWS re:invent en cette fin d’année 2021 .
• Le routage inter-region doit se faire de manière manuelle.
• Et si on connectait notre site on-premise ? Ok, mais la Transit Gateway ne peut diffuser que 20 CIDRs vers l’on-premise via un lien DirectConnect, et n’en recevoir que 100 en retour . Le tout sans auto-summarization des CIDRs. L’existant doit donc bien être analysé en amont pour ne pas dépasser les quotas. En cas de dépassement, les sessions BGP sont effacées de façon aléatoire.

En Preview, AWS propose la solution Cloud WAN . Cette solution permet en partie de pallier les points de douleur ci-dessus. A voir lors de sa sortie en production ! A première vue (à prendre avec des pincettes), pas de support pour les recouvrements de plans IP, et les limitations en termes d’annoncent CIDR devraient suivre celles de la Transit Gateway car Cloud WAN s’appuie sur celles-ci.

Et côté Microsoft Azure ?

Microsoft prône le peering entre VNets . Comme vu au-dessus, cette solution est peu recommandable dès lors qu’on ait à connecter un grand nombre de VNets.
Une autre solution applicable également aux autres Cloud providers consiste à dédier un VNet au transit et d’y incorporer des équipements NVA (Network Virtual Appliance) qui se chargeront du routage inter-VNet. Typiquement, des pares-feux, avec du routage manuel sur les VNets en périphérie (les « Spoke VNets ») :

Qui dit pare-feu dit failover, des problématiques de montée en charge/scaling, etc. Des problématiques d’exploitation relativement classiques, mais qu’il faut adresser et qui peuvent poser problème au fur et à mesure que les infrastructures évoluent.

En novembre 2019, Microsoft a sorti le produit « Azure Virtual WAN »[i]. L’idée ? Proposer un hub permettant d’interconnecter des VNets, VPNs, tout en automatisant la partie routage interne. Une sorte de backbone WAN managé par Microsoft :

Quelques points d’attention :

• Pas de NAT pour supporter des recouvrements de subnets IP : problématique dès lors que vous avez des sites distants qui partagent le même plan IP.
• Peu de visibilité et d’outils de troubleshooting. Microsoft propose une dashboard à installer via Workbooks… Une solution palliative relativement difficile à exploiter au quotidien.

Finissons par Google Cloud Platform (GCP)

L’originalité côté Google, c’est la régionalité des VPC. En effet chez les autres fournisseurs Cloud, un VPC/VNet est attaché à une région géographique à la création. Les subnets sous-jacents sont donc forcément liés à la région du VPC/VNet.

Chez Google, un VPC est global. Ce sont les subnets qui sont régionaux. Cela peut s’avérer pratique pour des projets avec un nombre d’intervenants limité, mais l’idée est quand même de segmenter les VPC par projets, créer un « Shared VPC » qui hébergerait les services communs à tous les projets, etc.

Sauf cas exceptionnels, Google recommande d’ailleurs de bien segmenter ses VPC par région et Business Units, comme sur les autres fournisseurs Cloud :

En conclusion de cette entrée en matière

S’implanter sur le Cloud signifie utiliser les outils et services fournis par un fournisseur tiers. Aucun n’est parfait tout comme aucune architecture on-premise n’est parfaite.

Les avantages et inconvénients de chacun sont à pondérer et des compromis doivent être faits. La difficulté pour un ingénieur réseau aujourd’hui qui ouvre la porte du Cloud, c’est de composer avec les spécificités de chaque fournisseur Cloud, et de laisser sa boîte à outils de côté.

Adieu ping, traceroute, tables ARP, tout ça est de l’histoire ancienne. Fournir des preuves pour contrecarrer le fameux « C’est la faute au réseau ! » relève de l’épreuve.

Et Aviatrix dans tout ça ?

Aviatrix a été fondée en 2014, soit quelques années après Amazon Web Services (2006), Google Cloud Platform (2008), Alibaba Cloud (2009), Microsoft Azure (2010), et avant Oracle Cloud Infrastructure (2016).

Aviatrix se place « au-dessus » de chaque fournisseur Cloud et fournit un niveau d’abstraction supplémentaire afin de gérer les problématiques réseau et sécurité afin d’adresser les points suivants :

• Fournir les moyens de bâtir une architecture multi-cloud
• Pallier les manques de chaque fournisseur Cloud en termes de performances. Par exemple, activer le chiffrement IPSEC sur n’importe quel type de liaison de n’importe quel fournisseur Cloud bride le débit à 1.25Gbps (oui…Même sur une liaison à 10Gbps). Aviatrix permet de monter ce débit jusqu’à faire du line rate en parallélisant les tunnels.[i]
• Offrir la visibilité réseau dont nous disposions sur les réseaux on-premise
• Permettre aux équipes de se concentrer sur leur métier afin d’apporter de la valeur. Ça me fait mal de dire ça, mais personne n’a envie de perdre son temps avec le réseau. C’est le socle et il est nécessaire, mais ça n’apporte rien d’un point de vue business. Moins on a à s’en occuper, mieux on se porte !

…Et concrètement ?

Aviatrix se compose de :

• Un contrôleur
• Des passerelles (« Gateway »)
• Un outil de monitoring & troubleshooting (Aviatrix CoPilot)

Le contrôleur orchestre les différentes passerelles qui sont placées dans votre ou vos Cloud, au sein de vos VPCs/VNets. Leur interconnexion permet de faire communiquer les VPC/VNets entre eux. Et ce peu importe le fournisseur Cloud choisi.

Vous pouvez déployer la solution pour orchestrer un Cloud, ou même plusieurs Cloud différents entre eux. L’idée est de manipuler non plus des objets AWS/Azure/GCP avec chacun leurs spécificités, Comment sont implémentés ces objets sur chaque Cloud ? Ce n’est pas notre affaire. C’est comme conduire une voiture : vous utilisez un volant et des pédales. Comment ces commandes pilotent le moteur et la liaison au sol suivant la marque et modèle de votre voiture – vous n’avez pas à vous en préoccuper.

L’implémentation de ces objets sur chaque fournisseur Cloud est prise en charge par le contrôleur via API. Nul besoin donc d’être un expert transverse AWS/Azure/GCP/OCI/Alibaba pour commencer à interconnecter plusieurs Cloud ou pour diagnostiquer un problème de connexion d’un point A à un point B.

Et ma boîte à outils réseau, elle continue de prendre la poussière ?

Et non ! Chaque instance de passerelle dispose des outils de troubleshooting que l’on connaît bien : ping, traceroute, table de routage…Comme à la maison.

Aviatrix propose un outil savamment nommé « FlightPath » permettant, pour une machine source et destination, d’étudier le flux et d’identifier les éléments de configuration sur le chemin afin d’orienter l’exploitant vers le point de blocage potentiel. Nous verrons si l’outil tient ses promesses.

L’idée me plaît (ou pas), on peut voir tout ça en action ?

Absolument, c’est parti !

Prenons cette architecture en exemple :

C’est une architecture hub-and-spoke classique, qui s’étend sur deux cloud providers distincts. Par soucis de simplicité, ce schéma montre le strict minimum, mais voici quelques points à garder en tête :

• Les hubs peuvent interconnecter des VPC/VNets, mais aussi des sites distants on-premise, et utilisateurs VPN
• Cette architecture ne comporte pas de pares-feux : il est néanmoins possible (et recommandé !) de les incorporer au niveau des hubs. Ils pourront alors filtrer le trafic est/ouest entre les VPC, et même vers Internet.
• Les passerelles peuvent offrir de la redondance suivant un mode de fonctionnement actif/actif

Considérons le flux suivant :

On désire qu’une machine se situant dans le Spoke1 Azure communique avec une machine dans le Spoke1 AWS. Un spoke représenterait un projet, une Business Unit, un environnement…

Voici les grandes étapes pour arriver à l’état voulu :

• Création du « socle » : VPCs, VNets, subnets, security groups. Ceci peut être fait à la main ou de préférence en Infrastructure as Code avec Terraform
• Création des passerelles Aviatrix dans chaque VPC/VNets : via le contrôleur Aviatrix sur l’interface, ou en Infrastructure as
• Code grâce au provider Terraform Aviatrix
• Peering des gateways spoke avec la transit gateway ad hoc, se trouvant dans les VPC/VNets “Hub”
• Peering de la transit gateway AWS avec celle d’Azure
• Et bingo, on a notre infrastructure multi-cloud !

Nickel, tout marche. Comment fait-on pour visualiser tout ce petit monde ?

J’en ai sur Azure, sur AWS, un peu compliqué de s’y retrouver…

CoPilot, à toi de jouer !

Faisons un petit tour sur CoPilot, l’outil de supervision et de troubleshooting :

Petit tour d’horizon de mon environnement : Azure aux Etats-Unis, AWS en Europe. Quatre gateways (ie celles attachées aux VPCs/VNets), et deux transit gateways (ie les gateways qui interconnectent les spokes entre eux au sein d’un même Cloud)

Sur l’onglet Topology :

Je retrouve une vue graphique de ce que j’ai déployé.

En creusant un peu :

Je retrouve :

• Mes gateways
• Mes transit gateways
• La latence des interconnexions

En creusant encore un petit peu, je peux afficher les instances déployées :

(Les trucs verts pas très beaux, c’est moi)

À tout moment, si j’ai un doute je peux sélectionner une passerelle pour faire une opération de diagnostic :

Maintenant, le moment tant attendu…Ca ping ou pas ?

Alors…Oui. Faites-moi confiance.

Et le http entre les machines ? Ah, eh bien non ! Hum…

Qu’est-ce qui peut bloquer sur le chemin ? J’ai potentiellement des Security Groups côté AWS qui peuvent bloquer, des Network Security Groups côté Azure, qui peuvent être appliqués à l’interface réseau ou au subnet entier… Cela va prendre un peu de temps pour démêler tous ces éléments.

Et maintenant au tour de FlightPath

Oui, mais heureusement, c’est là que FlightPath entre en scène.

L’idée, c’est que je renseigne l’instance source, l’instance destination, le protocole voulu, et le contrôleur Aviatrix se charge de faire les contrôles des éléments de configuration qui peuvent bloquer sur le chemin.

Exemple :

Ce qui nous donne après quelques secondes de moulinage :

Le rapport détaille tous les éléments : Security Groups, tables de routage de chacune des gateways sur le chemin…En l’occurrence, c’est un Security Group qui bloque côté AWS. Le port TCP/80 n’est pas autorisé depuis ma source en 10.1.2.4/24.

Corrigeons cela :

Et voilà !

Et ce n’est pas tout sur Aviatrix…

Je vous ai montré ici les bases d’une architecture Aviatrix. Tout n’aurait pas tenu en un article mais voici d’autres aspects que l’on pourrait aborder :

• Le MCNS, ou « Multi Cloud Network Segmentation », pour segmenter les VPCs au niveau routage. On crée par exemple un segment Rouge, un Bleu. Tous les VPC intra-segment communiquent entre eux par défaut. Entre segments, on définit une politique de sécurité pour autoriser Rouge vers Bleu. Simple mais efficace !
• L’insertion de Firewall via Firenet : Aviatrix se charge de déployer votre cluster de Firewall. Il ne reste plus qu’à créer les politiques de sécurité !
• Le recouvrement de plans IPs en utilisant du NAT 1 pour 1 sur les passerelles Aviatrix pour connecter vos partenaires
• Les solutions de sécurité Aviatrix : Threat IQ avec ThreatGuard, véritable IDS et IPS qui s’appuie sur les données Netflow des passerelles Aviatrix pour repérer et potentiellement bloquer tout trafic malicieux.

AWS a d’ailleurs reconnu Aviatrix officiellement en attribuant deux « compétences » : une pour le réseau, et une pour la sécurité.

Ce qui identifie Aviatrix officiellement comme partenaire de choix pour ces problématiques plus que jamais importantes pour le Cloud.

Aviatrix organise régulièrement des « Hands-on labs » accessibles à tous vous permettant de manipuler l’infrastructure et de construire une architecture multi-cloud. C’est par ici !

Si vous vous interrogez sur votre capacité à maîtriser votre cloud d’un point de vue design et sécurité réseau, visibilité, troubleshooting, flux et ouverture au multi-cloud, METANEXT peut vous accompagner et vous montrer ce dont Aviatrix est capable !

Serge SERBILADZE – Ingénieur Réseau & Sécurité