Azure : Les nouvelles fonctions des VNET par la pratique (Regional Networks, VNET2VNET, Réservation de VIP, Internal Load Balancing)

Article
05/28/2014

Salut à tous,

Vous avez vu les annonces de Microsoft à TechEd ? Azure dispose de nombreuses nouvelles fonctionnalités sur les réseaux virtuels dans Azure. Entre autre :

Nouveaux "Regional Networks" tirant parti de toutes les nouveautés réseau
Possibilité d'avoir des adresses IP internes statiques (on savait déjà le faire depuis Build 2014)
Possibilité de tirer plusieurs VPN à partir d'une même passerelle
Possibilité de relier plusieurs VNET dans Azure par de multiples VPN
Réservation d'adresses IP publiques
Load Balancer internes (sans passer par les VIP)

Génial non ?.La plupart de ces fonctions sont disponibles via PowerShell uniquement pour le moment. Reste donc à passer à la pratique. Je vous propose donc de découvrir ces fonctionnalités pas la pratique.

Les Regional Networks

Les nouveaux VNET Azure sont appelés des Régional Networks. Les "Locations" remplacent les "Affinity Groups" pour les nouveaux VNET. Ils permettent d'associer à un VNET l'ensemble des ressources d'un Datacenter Azure. Pour créer un VNET nouvelle génération, il faut suivre l’explication et la procédure décrite ici : https://azure.microsoft.com/blog/2014/05/14/regional-virtual-networks/

La migration des anciens VNET vers les Regional Networks n’est pour le moment pas directe. Il faut exporter la configuration du VNET, la modifier pour passer en Regional Network, et créer un nouveau VNET à partir de la même config modifiée. En revance, un ancien VNET peut être connecté à un Regional Network, et deux anciens VNET peuvent être connectés par un tunnel VPN

Quelques précisions au sujet de l'article.

Le code XML décrivant le regional network contient des erreurs XML. Voici un exemple avec 2 regional networks qui fonctionne :

Attention à ne pas modifier la déclaration du subnet "GatewaySubnet" dans chaque VNET. C'est important pour la suite, si vous voulez créer une passerelle de VPN

</AddressSpace>

</Subnet>

</Subnet>

</Subnet>

</Subnets>

</VirtualNetworkSite>

</AddressSpace>

</Subnet>

</Subnet>

</Subnet>

</Subnets>

</VirtualNetworkSite>

Si vous voulez spécifier d'autres DataCenters, voici la liste complète des noms de DC acceptés : asiaeast, East Asia, asiasoutheast, Southeast Asia, europenorth, North Europe, europewest, West Europe, useast, East US, uswest, West US, japaneast, Japan East, japanwest, Japan West, brazilsouth, Brazil South, usnorth, North Central US, ussouth, South Central US

Il est préférable d'utiliser une bonne commande powershell pour modifier les VNET d'une souscription. Voici comment faire :

1- Exporter la configuration dans un fichier XML. Exemple : Get-AzureVNETConfig -ExportToFile "C:\Users\swoillez\Desktop\netcfg.xml"

2- Modifier la configuration avec l'exemple que je vous ai donné plus haut

3- Réimporter la configuration en PowerShell. Exemple : Set-AzureVNETConfig -ConfigurationPath "C:\Users\swoillez\Desktop\netcfg.xml"

Et voici ce que ca donne dans la console Azure :

A noter qu'on peut identifier un Regional Network à la colonne "Location" qui contient juste le nom du DataCenter, alors qu'un VNET classique affiche dans cette colonne le nom du groupe d'affinité avec entre parenthèses le nom du datacenter

La connectivité entre VNET

Maintenant que j'ai mes VNET nouvelle génération, ca serait cool de les interconnecter de manière à créer un seul réseau. Si vous regardez avec attention ma config VNET ci dessus, vous verrez que j'en ai créé deux. Un VNET en Europe et un autre aux US.

Donc pour créer une interconnexion entre VNET, il faut se référer à la doc pour bien comprendre. Elle se trouve ici : https://msdn.microsoft.com/en-us/library/azure/dn690122.aspx

Bon, en clair, cela se fait en 3 étapes :

Dans les deux VNET à connecter, Créer la déclaration de l'autre réseau (déclaration en Local Network) et un champ pour déclarer la Gateway
Dans la console Azure démarrer les deux passerelles VPN
Reconfigurer les deux passerelles avec leurs adresses IP (obtenues à l'étape 2) et leur injecter une clé d'encryption commune

Première étape donc, reconfigurer les deux réseaux pour qu'ils se connaissent l'un l'autre et puissent créer deux Gateway pour interconnecter les deux VNET. Il faut pour cela modifier la configuration des VNET avec la même procédure que décrite précédemment : Exporter la configuration du VNET en XML, la modifier, puis ré importer la configuration dans la souscription Azure. Les deux modifications à apporter sont :

- La déclaration de "Local Networks" qui permettent à la passerelle VPN de connaître l'adresse de la passerelle VPN distante et la plage d'adresses IP distante. Pour le moment on ne connaît pas l'adresse IP publique de la passerelle distante, il faudra donc la modifier dans un second temps. Pour nos deux réseaux, ca donne donc ca :

</AddressSpace>

</LocalNetworkSite>

</AddressSpace>

</LocalNetworkSite>

</LocalNetworkSites>

Comme je le disais, les adresses IP publiques des passerelles VPN sont temporaires car les passerelles n'ont pas encore été créées

Ensuite il, faut modifier chaque VNET pour y ajouter la déclaration de la passerelle. Modifs en rouge dans le code XML suivant :

</AddressSpace>

</Subnet>

</Subnet>

</Subnet>

</Subnets>

<Gateway>

<ConnectionsToLocalNetwork>

<LocalNetworkSiteRefname="NGVnetUS">

<Connectiontype="IPsec" />

</LocalNetworkSiteRef>

</ConnectionsToLocalNetwork>

</Gateway>

</VirtualNetworkSite>

</AddressSpace>

</Subnet>

</Subnet>

</Subnet>

</Subnets>

<Gateway>

<ConnectionsToLocalNetwork>

<LocalNetworkSiteRefname="NGVnetEurope">

<Connectiontype="IPsec" />

</LocalNetworkSiteRef>

</ConnectionsToLocalNetwork>

</Gateway>

</VirtualNetworkSite>

Pensez bien à croiser les déclarations de réseaux. Dans mon exemple, la passerelle du VNET Europe pointe sur le Local Network US, et vice versa :

Deuxième étape, après la réimportation du fichier XML dans Azure, créer les deux passerelles VPN pour obtenir leur adresse IP publique de manière à pouvoir terminer leur configuration. Il faut le faire dans la console web Azure. Une fois fait, ca donne ca pour chaque résau:

Troisième étape; terminer la configuration des deux passerelles, en injectant dans la configuration des deux "Local Networks" les bonnes adresses IP publiques des passerelles (qu'on vient juste d'obtenir après leur création). Même principe, export XML, modif de la config, import XML. On obtient une configuration valide :

Dernière étape, injecter dans chaque passerelle la même clé de chiffrement IPSEC. Deux commandes Powershell pour faire ca :

Set-AzureVNetGatewayKey -VNetName VNet1 -LocalNetworkSiteName VNet2 -SharedKey <clé de chiffrement>

Set-AzureVNetGatewayKey -VNetName VNet2 -LocalNetworkSiteName VNet1 -SharedKey <clé de chiffrement>

Les deux commandes passent avec succès et on peut alors redémarrer les 2 passerelles VPN à partir de la console Azure :

Reste à créer une VM de chaque coté pour vérifier que la magie fonctionne vraiment...

Et ca marche !!! Et même plutôt bien. Les deux VM que j'ai créé dans chaque VNET peuvent se voir (attention aux firewalls des VM pendant vos tests, les pings sont bloqués par défaut)

Une petite question intéressant pour terminer. Et je vous laisse réfléchir à la réponse. Les deux VNET sont bien l'un en Europe et l'autre aux US, il n'y a pas de doute; et une liaison transatlantique sur le net délivre dans les 350ms de latence....

Alors comment se fait-il que mon ping délivre une latence beaucoup beaucoup plus faible, de l'ordre de 80ms.. ???

Voilà pour ce post. La suite de mes aventures réseau dans un prochain post.

Stéphane.

Share via

Azure : Les nouvelles fonctions des VNET par la pratique (Regional Networks, VNET2VNET, Réservation de VIP, Internal Load Balancing)

Les Regional Networks

La connectivité entre VNET

Additional resources