Dernièrement, j’ai travaillé sur des environnements Azure qui s’appuyaient sur Azure Virtual WAN dans leurs topologies Hub & Spokes.

Je vous propose de revenir sur les concepts apportés par ce service réseau, et de regarder en quoi ce dernier pourrait être intéressant par rapport à un modèle Hub & Spoke standard avec uniquement des virtual networks.

Il y a beaucoup de matière autour de Virtual WAN, aussi je vous propose de nous limiter aux sujets suivants :

• Discovering Azure Virtual WAN
• Deploying a basic Hub and Spokes topology with Virtual WAN
• Comparing a Hub & Spoke with Virtual WAN and the standard Hub & Spoke with VNet only

Nous approfondirons très probablement dans un autre article.

 

Introduction à Azure Virtual WAN

 

Derrière le nom Virtual WAN, Microsoft propose un service qui inclut beaucoup de choses, notamment :

• De l’interconnexion avec des sites distants, à travers du VPN Site to Site, ExpressRoute ou des solutions SD-WAN partenaires ;
• Une nouvelle option pour la topologie Hub & Spoke (que nous regarderons dans cet article) ;
• Une gestion centralisée du routage ;
• Du firewalling.

 

Le service évolue beaucoup, et de nouvelles features sont ajoutées. Pour rester à jour, je vous invite à suivre le RSS feed ou consulter la page what’s new? dans la Documentation Azure.

Entrons dans le vif du sujet et regardons comment créer un Virtual WAN.

Si l’on se base sur la documentation az cli, ou encore sur le provider terraform AzureRM, nous pouvons constater que peu de paramètres sont requis :

 

Required parameters	Optional parameters
Name, Resource Group Name	Location, Type, VPN encryption, Office 365 local breakout category, Security Provider name, Branch to branch traffic, Tags

 

 

Hormis les paramètres obligatoires, le paramètre location doit également être spécifié pour permettre de choisir la région cible. Avec az cli, si la région n’est pas spécifiée, le virtual WAN est déployé par défaut dans la région du groupe de ressource.

Le paramètre type permet de choisir le sku, entre Basic et Standard. Les différences entre les 2 skus sont assez importantes. Avec Basic, la seule option pour la connectivité est Site To Site VPN. Il n’est pas non plus possible de déployer de Firewall. On notera que sans précision avec az cli, le sku par défaut est Standard.

Maintenant, concernant la gestion du routage, nous devons commencer par ajouter un Virtual Hub dans notre virtual WAN.

Créons à présent un Virtual WAN :

 

Après provisionning, nous avons un rendu comme ci-dessous dans le portail Azure :

 

A ce stade, notre Virtual WAN est vide.

Pour accéder aux options de routage, nous devons, comme discuté précédemment, ajouter un Virtual Hub.

Pour déployer cet objet, nous utiliserons encore az cli. La documentation semble nous indiquer qu’il suffit de spécifier un nom et un groupe de ressources, mais cela résulterait sur une erreur.

 

 

En spécifiant le Virtual WAN cible ainsi que le range IP à dédier au Virtual Hub, nous arrivons finalement à créer notre ressource.

 

On notera que, encore une fois, le paramètre location n’est pas obligatoire. La valeur prise par défaut est alors la région du Virtual WAN.

Un autre point intéressant est visible dans l’output du Virtual Hub :

 

La ressource en cours de création, et utilisée pour le routage, est un Azure Route Server, managé à l’intérieur de notre Virtual Hub. Cela prend un certain temps, et nous devons attendre un peu avant de jouer avec le routage.

 

Après un moment d’attente, nous pouvons obtenir les IP du Route Server.

 

Avant de commencer à jouer, voici un rapide aperçu sur le provider Terraform :

 

Il semble que les paramètres requis soient bien les mêmes, mais nous pouvons noter une différence dans l’exposition d’autres paramètres.

Arguments in the az cli only	Arguments in terraform only
–allow-b2b-traffic	route

 

 

Pour le moment, nous allons laisser ceci de côté, avancer sur notre topologie Hub & Spokes et faire un peu de routage de base.

 

Déployer un Hub & Spoke avec Virtual WAN

 

Comme vu précédemment, l’un des objectifs de Virtual WAN est de proposer une autre façon de faire du Hub & Spokes. Le Virtual Network utilisé comme Hub est ici remplacé par un Virtual Hub.

Contrairement à un Virtual Network qui nous permet de déployer un peu ce que l’on veut comme Instance IaaS, nous ne faisons pas beaucoup sur le Virtual Hub, hormis la sélection d’un range IP.

En revanche, le Virtual Hub étant plus managé par Microsoft, il est également pensé pour une meilleur scalabilité, et il est aisé d’ajouter un autre Virtual Hub dans une autre région. Par design, les Virtual Hub sont automatiquement connectés (alors qu’il faudrait réalise un peering entre deux Virtual Network Hubs).

Ajoutons un autre Virtual Hub pour illustrer notre propos.

 

On remarquera au passage le range pour les Virtual Hubs. La recommandation est de réserver au minimum un /24. Nous avons ici réservé un /23. Des IPs sont consommées par le Route Server, et potentiellement des appliances de sécurité déployées dans le Virtual Hub.

 

Nous avons accès à une vue de topologie depuis le portail. A ce stade, nous voyons uniquement 2 Virtual Hubs :

 

Ajoutons quelques spokes :

 

Connectons ensuite ces spokes à notre Virtual WAN, et spécifiquement, à l’un de nos Virtual Hub.

On parle ici de Network Connection, plutôt que de Vnet Peering, mais il s’agit bien d’un objet équivalent, managé depuis le Virtual WAN.

 

On connecte nos spokes avec la commande ci-après :

 

On connecte de la même manière spoke02 à vwan01-vhub01 et spoke03 à vwan01-vhub02.

Nous pouvons à présent voir depuis le menu VWAN nos Network Connections.

 

En regardant coté Spokes, nous pouvons également jeter un œil sur les propriétés du peering.

 

 

Parce que le peering est géré à travers le Virtual Hub, il est différent d’un peering standard, et son nom ne reflète pas le nom de la Network Connection coté Virtual Hub.

 

Avec l’addition des spokes, notre topologie est mise à jour.

 

Pour commencer à comprendre l’organisation du routage, observons un peu les tables de routage existantes :

 

La route par défaut est automatiquement peuplée avec nos Network Connexions.

De cette manière, le Virtual Hub et ses réseaux appairés peuvent récupérer les routes réseaux pour être joignables entre eux.

On note que seulement 2 connections sont peuplées dans cette table de routage. Cela est dû au fait que notre 3^eme spoke est connecté à notre second Virtual Hub.

 

La section Effectives Routes affiche l’écran suivant :

 

Il y a visiblement une commande disponible en az cli, mais je n’ai pas encore réussi à obtenir un résultat satisfaisant.

 

Ajoutons quelques machines pour pouvoir creuser un peu le routage.

 

Network Watcher permet de nous indiquer le nexthop en partant d’une machine.

 

Et la section Effective Routes depuis la NIC nous permet d’avoir les informations suivantes :

 

On note l’équivalent en az cli.

 

 

A partir de là, nous identifions que le next hop entre chaque spoke est l’IP publique 20.72.188.148 identifiée comme une virtualNetworkGateway.

Également, pour atteindre le range IP du virtual Hub 172.31.254.0/23, le nextHopType est de type VNetPeering.

Le point intéressant ici est la Gateway managée qui permet le trafic entre 2 spokes. Cette Gateway est-elle dépendante du Virtual WAN ou du Virtual Hub ? Un bon moyen pour y répondre est de tester le next hop entre Spoke03 et Spoke02, Spoke03 étant connecté au Virtual Hub vwan-01-vhub02.

Les routes effectives pour la Nic de vm03 nous donnent 4.175.160.48 comme IP de Gateway.

 

A partir de ce résultat, nous en concluons que la Gateway est présente dans chaque Virtual Hub.

Pour le moment nous allons nous arrêter ici avec l’étude du routage, et conclure en comparant un Hub & Spokes standard avec un Hub & Spoke Virtual WAN

 

Comparaison entre Hub & Spokes standard et Hub & Spokes Virtual WAN

 

Nous avons déployé jusqu’ici la topologie suivante :

 

Avec une topologie standard, nous avons ceci :

 

Tout d’abord, dans la topologie standard, nous devons gérer nous-mêmes le peering entre les hubs.

Ensuite, la configuration routage est centralisée dans le Virtual WAN, alors que nous devons gérer des User Defined Routes au niveau de chaque spoke dans la topologie standard.

Enfin, nous devons systématiquement ajouter une gateway dans le(s) hub(s) d’une topologie standard, pour permettre le routage inter-spokes, ce qui est entièrement géré d’un point de vue Virtual WAN, et de fait grandement simplifier.

Nous aborderons dans un autre article les notions de Secure Hub et de configuration de routage custom. Pour le moment, nous nous arrêtons sur un tableau de synthèse comparant nos deux types de topologies.

 

 

	Virtual Hub in Virtual Wan	Hub & spoke with Virtual Network
Network configuration for the hub	Spécifier le range réseau	Spécifier le range réseau et faire le découpage subnet
Spokes connection with the hub	Réalisé depuis le Virtual WAN	Réalisé depuis les propriétés du Vnet
Hub connection with other hub	Créer automatiquement à la création du nouveau Virtual Hub	Nécessite un peering additionnel entre les Hubs
Spoke connection with other spokes through the hub	S’appuie sur la Gateway gérée par Azure automatiquement et déployée à la création du Virtual Hub	Nécessite l’addition d’une Gateway pour permettre la connectivité
Spoke connections with other spokes connected to other hub	S’appuie sur la Gateway gérée par Azure automatiquement et déployée à la création du Virtual Hub	·       Nécessite l’addition d’une Gateway pour permettre la connectivité ·       Ajoute de la complexité dans la gestion du routage.
Routing management	Géré de manière centralisée depuis le Virtual Hub	Nécessite une gestion distribuée au niveau des subnets

 

 

Vous souhaitez être accompagné dans vos projets ? Contactez-nous !