Nouvelles Chroniques d'Amethyste

Penser au Sens, pas au Verbe

Créer un réseau virtuel sous Azure

Poster un commentaire

Les réseaux virtuels sont des outils importants de l’offre Azure. Les services Azures que l’on peut relier via un VNET sont actuellement:

  • Cloud services
  • VM
  • Web Apps
  • D’autres réseaux

Les réseaux virtuels sont indispensables pour mettre en place certains scénarios de VM tels:

  • équilibrage de charge interne
  • communication de VM inter service
  • IP privée persistante
  • Active Directory
  • Autoscaling
  • Résolution de noms

On a également besoin de VM pour construire des infrastructures hybrides dans lesquelles vous distribuez vos ressources entre on premises et Azure.

Azure supporte les connectivités suivantes:

  • Site to site
    On va relier des réseaux entre eux y compris on premises à l’aide de périphériques VPN.
    La connexion a lieu sur IPSec
  • Point to point
    Connexion d’un poste de travail on premises ou une VM à un réseau via un client VPN et des certificats.
    La connexion a liu sur SSTP qui apparaîtra comme une liaison HTTPS et peut donc traverser proxies et pare feu
  • ExpressRoute

Disons un mot de ExpressRoute qui est un peu particulier. Il s’agit d’une liaison sécurisée privée qui ne passe pas par le réseau Internet public. La liaison est fournie par un opérateur (Orange en France). Ce mode concerne surtout les entreprises qui ont besoin d’une sécurité renforcée et/ou de gros volumes de bande passante.

Une présentation plus complète:

http://blogs.microsoft.fr/azure/windows-azure-expressroute-profitez-dune-connexion-windows-azure-prive-et-plus-rapide.html

Cet article va se focaliser sur les réseaux point à site car c’est le seul scénario facile à mettre en œuvre pour un développeur.

Si vous souhaitez monter un réseau site à site voici des informations:

  • Sur l’équipement supporté par Azure:

https://msdn.microsoft.com/fr-fr/library/azure/jj156075.aspx

 

Des informations complémentaires pour décider de la mise en œuvre d’un réseaux Azure:

https://msdn.microsoft.com/library/azure/jj156007.aspx

Et une FAQ:

https://msdn.microsoft.com/fr-fr/library/azure/dn133803.aspx

 

Au programme donc:

  • Cas des VM dans un même service
  • Création d’un réseau point à site
  • Ajouter des sous-réseaux
  • Se connecter en VPN
  • Le support PowerShell

Le cas des VMs dans un même service cloud

Ce cas est très simple car vous avez pas grand chose à faire. On monte le scénario suivant:

2015-04-28_09-16-17

On déploie deux VMs dans un même service cloud. Une troisième VM AmethysteVM3 est disposée à l’extérieur de ce service. Sur chaque VM on va activer le rôle IIS et modifier la page par défaut du site par défaut afin d’afficher le nom du serveur qui l’héberge afin d’avoir un visuel simple.

On se connecte à AmethysteVM1 en RDP et on lance un navigateur. Faisons ensembles les expériences qui suivent:

 

http://amethystevm2/

Affiche:

2015-04-28_13-39-25

Note 1: Si vous invoquez directement l’adresse IP interne  de AmethysteVM2 vous obtiendrez le même résultat.

Note 2 : Si vous essayez maintenant avec l’adresse publique:

2015-04-28_13-40-57

Ce qui est normal puisque l’on a pas de point de terminaison sur le port 80.

 

Maintenant on lance:

http://amethystevm3/

2015-04-28_13-40-57

Pour rappel, AmethysteVM3, n’est pas dans le même cloud service. Essayons d’ouvrir un point de terminaison posé sur le port 80 de la VM AmethysteVM3 et recommençons:

2015-04-28_13-40-57

Essayez de remplacer le nom du serveur par son IP publique:

2015-04-28_13-46-17

Que conclure de tout cela?

  • Lorsque des VMs partagent un même service cloud, alors elles peuvent nativement communiquer entre elles sans qu’il soit nécessaire de créer un réseau virtuel
  • Azure met en place un service de résolution de noms par défaut qui peut être utilisé pour des VMs partageant le même service cloud

Par conséquent, dans le cadre de cette étude sur les réseaux virtuels Azure, nous allons plutôt nous intéresser au cas des VMs situées sur des services différents.

Pour plus d’informations sur la résolution des noms:

https://msdn.microsoft.com/fr-fr/library/azure/jj156088.aspx

Création d’une réseau point à site

Je vais m’inspirer de cet article:

http://blogs.technet.com/b/cbernier/archive/2013/08/21/windows-azure-how-to-point-to-site-vpn-walk-through.aspx

Et de celui-ci:

https://msdn.microsoft.com/library/azure/dn133792.aspx

 

On se rend dans le portail puis on sélectionne l’onglet NETWORKS:

2014-06-26_23-50-12

Il s’ouvre:

2015-04-28_14-36-41

On fait NEW puis CUSTOM CREATE:

2014-06-26_23-53-16

C’est le premier formulaire de l’assistant de création. On appellera NetworkAmethyste le réseau. Faites OK:

2014-06-26_23-55-43

Si vous disposez d’un DNS, vous pouvez l’utiliser pour gérer la résolution des noms. Nous n’allons pas le faire ici.

Sélectionnez CONFIGURE A POINT TO SITE VPN, mais testez les différentes combinaisons pour voir l’évolution des écrans.

Le schéma en bas de l’écran représente le réseau une fois que la passerelle et les clients auront été définis.

On fait OK, on parvient au formulaire de déclaration des espaces d’adressage du réseau:

2014-06-27_00-03-58

Par défaut, l’assistant ajoute l’espace d’adressage 10.0.0.0/8. On peut bien entendu le modifier ou ajouter d’autres espaces d’adressage. Nous allons laisser les choses ainsi.

Note: si ce réseau doit se connecter à un réseau on premises, il faudra veiller à ce que les espaces d’adressage ne se recoupent pas.

Faire OK pour ouvrir le formulaire de déclaration des sous réseaux:

2014-06-27_00-07-55

Ici aussi des valeurs par défaut que nous allons modifier le nom du sous réseau pour que ce soit plus lisible et renommer en MainNetwork le sous réseau:

2015-04-28_14-47-39

Le plus petit sous-réseau possible est /29 et le plus grand est /8. Les adresses du sous-réseau se trouvent dans l’espace d’adressage du réseau virtuel.

On peut aussi noter qu’il n’est possible d’ajouter des sous-réseau que par ordre de taille décroissante.

 

On clique sur le bouton ADD GATEWAY SUBNET pour configurer la passerelle et on laisse les paramètres par défaut:

2015-04-28_14-52-21

On fait OK pour lancer la création du réseau.

2015-04-28_14-56-32

Allons sur le panneau de contrôle:

2015-04-28_14-59-56

Il nous faut maintenant créer la passerelle de routage. Auparavant, allez dans l’onglet CONFIGURE pour vérifier les paramètres du réseau.

2014-06-27_00-19-57

La création de la passerelle demande environ 15 minutes au bout desquelles le panneau de contrôle affiche:

2015-04-28_16-30-15

On se préoccupera du certificat plus tard.

Un dernier point: un réseau virtuel est imité à une seule région. Il n’y a pas non plus de possibilité d’ACL sur un sous-réseau.

Ajouter des VMs à un réseau

Il est impossible de le faire sur des VMs existantes, cela ne peut se faire qu’à la création. Il est tout de même possible de déplacer des VM d’un sous réseau vers un autre.

Commençons avec le portail.

On créé une VM depuis la galerie. Lors de l’étape de la configuration de la VM:

2015-04-28_23-13-33

Note: Quick Create ne permet pas de rattacher une VM à un réseau

On sélectionne le réseau de rattachement. On construit de la même façon une VM dans un autre service cloud.

On peut vérifier que l’IP interne de nos VM se trouve bien dans le sous-réseau:

2015-04-28_23-28-39

Tandis que dans les paramètres de configuration:

2015-04-28_23-30-12

Et dans le panneau de contrôle du réseau on voit nos deux VMs:

2015-04-28_23-56-01

Testons maintenant.

On se connecte à AmethysteVM3 et si on recommence le test du premier chapitre avec l’IP interne de AmethysteVM3 on voit s’afficher:

2015-04-28_23-45-42

L’adresse IP toujours car il n’y a pas de résolution de noms par défaut entre deux services différents. Il faut fournir son propre DNS.

Une autre solution consiste à créer un répertoire partagé dans AmethysteVM1 et vérifier qu’il soit visible depuis AmethysteVM3:

2015-04-29_23-27-47

 

Intéressons nous à l’IP affectée à chaque VM. On a lancé dans l’ordre AmethysteVM1 et AmethysteVM3 et trouvé:

2015-04-28_23-56-01Si je lance les VMs dans l’ordre inverse:

2015-04-29_09-41-04

Les IPs sont attribuées dans l’ordre de lancement des VM et les 4 premières valeurs sont réservées. Si on a besoin d’assurer un contrôle, on peut affecter aux VM une adresse statique. La valeur de l’adresse statique devra bien sûr être dans la plage d’IP du sous-réseau. Mais il faut savoir qu’il s’agit d’une requête, pas d’une affectation en fait. Si l’adresse demandée est déjà allouée, alors un message d’erreur se produira.

 

Il est possible d’assigner un serveur DNS au niveau du service cloud plutôt qu’au niveau du réseau. On utilisera New-AzureDNS. Voici quelques exemples:

http://www.codit.eu/blog/2013/06/07/windows-azure-iaas-%E2%80%93-automatic-provisioning-of-a-virtual-biztalk-environment/

http://www.alexwinner.com/articles/azure/91-creationvmazureposh.html

http://michaelwasham.com/2012/07/13/connecting-windows-azure-virtual-machines-with-powershell/

On peut spécifier jusqu’à 12 DNS. Cette étape est de toute façon nécessaire pour rattacher une VM à un domaine. Cette opération peut également être faite depuis le portail:

2015-05-02_09-49-40

 

 

Vous avez peut être remarqué qu’à aucun moment il nous a été demandé de choisir un sous-réseau. D’un autre côté il y en a qu’un seul. Essayons d’en ajouter un autre.

2015-04-29_09-45-41

Dans le formulaire de création d’une VM il apparaît une nouvelle liste déroulante:

2015-04-29_09-47-55

Dans laquelle vous choisissez le sous réseau.

 

Regardons encore une fois cette figure:

2015-04-29_09-45-41

 

On lit par exemple /29 (3) ce qui signifie que l’on a à notre disposition 3 adresses dans le sous réseau SecondNetwork.

Pourtant le calcul donne 8 IP. Les IP perdues sont en fait réservées par Azure et ne sont pas disponibles en réalité.

Connexion en client VPN

Nous allons essayer de nous connecter en VPN sur ce réseau. Vous vous souvenez de cet écran?

2015-04-28_16-30-15

Il nous faut charger un certificat. Ce certificat, au format .cer, est utilisé pour l’authentification des clients VPN. Il est préférable d’avoir un certificat délivré par une CA, mais un certificat auto-signé peut faire l’affaire.

 

On se rend dans l’onglet CERTIFICATES:

2015-04-28_16-32-23

Avant de continuer il faudra générer des certificats. La procédure à suivre est la suivante:

  1. Générer un certificat auto-signé
  2. télécharger le certificat sur le portail
  3. Générer un certificat client
  4. Exporter et installer le certificat client

 Certificat auto signé

On  lance la commande:

makecert -sky exchange -r -n « CN=AmethysteRootCertificate » -pe -a sha1 -len 2048 -ss My « AmethysteRootCertificate.cer« 

Il s’agit d’un fichier .cer qui ne contient donc pas la clef privée.

Certificat client

Sur la même machine où a été créé le certificat racine:

makecert.exe -n « CN=AmethysteClientCertificate » -pe -sky exchange -m 96 -ss My -in « AmethysteRootCertificate » -is my -a sha1

Exporter les certificats

Dans le magasin on trouve ceci:

2014-06-27_16-37-19

On va les exporter. Le certificat racine au format *.cer (sans clef privée), le certificat client au format *.pfx (avec clef privée).

2014-06-26_23-24-40

Télécharger le certificat racine

On revient dans le portail à l’écran déjà vu et on clique sur UPLOAD:

2015-04-28_19-31-30Sélectionner le certificat racine et faites OK.

2014-06-27_00-17-56

Un retour au tableau de bord montre ceci:

2014-06-27_00-45-31

En l’état, le portail nous signale qu’aucun client n’est connecté au réseau.

On remarque deux liens dans la zone Quick Glance. Ces liens nous permettent de télécharger les clients VPN en fonction de son environnement 32/64 bits.

On en profite pour justement télécharger un de ces clients.

Exporter et installer le certificat client

Cette étape a lieu sur chaque machine cliente. Nous allons créer une autre VM AmethysteVM4 qui ne se trouve pas dans le réseau.

Commencez par vérifier que AmethysteVM3 n’est pas accessible via son IP interne.

 

Ensuite on se connecte, on installe le certificat client (.pfx) en double cliquant sur le fichier et le client VPN en lançant l’exécutable.

On se rend dans les paramètres réseau et on trouve:

2015-04-29_00-05-13

Notre réseau apparaît. On clique dessus. On lance le navigateur et on vérifie que l’on peut se connecter à AmethysteVM3 depuis son IP interne.

2015-04-28_23-45-42

On peut connecter ainsi jusqu’à 128 clients VPN.

Le support PowerShell

Récupérer la liste des réseaux

La cmdlet est Get-AzureVNetSite:

2015-05-01_11-24-19

On peut cibler un réseau particulier avec VnetName.

Création et configuration

Le support PowerShell pour configurer un réseau est très rudimentaire puisqu’il consiste en deux commandes.

  1. Get-AzureVnetConfig
    Exporte un fichier XML avec l’ensemble des paramètres du réseau, ou des réseaux s’il y en a plusieurs. On ne peut pas cibler!
  2. Set-AzureVNetConfig
    Importe le fichier XML précédent après avoir été modifié

Il n’existe pas d’import partiel, on doit renvoyer l’intégralité de la configuration. Soyez donc très prudent et testez, retestez et sauvegardez bien l’état initial.

On peut aussi faire l’export depuis le portail avec la commande EXPORT.

2015-05-01_11-20-55

On pourrait exporter le fichier XML de la façon suivante:

Get-AzureVNetConfig -ExportToFile « c:\temp\NetworkAmethyste.xml »

L’import est un peu plus planqué:

2015-05-02_17-54-17

Si vous créez un réseau avec la commande d’import, la passerelle ne sera pas créée.

2015-04-28_14-59-56

Soit on le fait comme précédemment depuis le portail, soit on lance la commande:

New-AzureVNetGateway -VNetName « NetworkAmethyste » -GatewayType DynamicRouting

Pour un réseau point à site on choisira une passerelle dynamique. En fait statique est restreint au cas UN réseau local vers UN réseau virtuel Azure.

 

Puisque la suite consistera à manipuler du XML, je pense qu’il est plus facile de le faire avec ce fichier sous les yeux. On peut également lire le schéma documenté ici:

https://msdn.microsoft.com/fr-fr/library/azure/jj157100.aspx

Pour suivre plus facilement le script voici mon réseau:

2015-05-01_11-40-01

Voici un script qui ajoute un nouveau sous-réseau au réseau.

$networkName = »NetworkAmethyste »
$subnetName = « ThirdNetwork »
$subnetIP = « 10.0.1.48/28 »

# récupère la configuration de réseaux
$reseaux = Get-AzureVnetConfig
[xml]$xml = $reseaux.XMLConfiguration

# obtient la liste des réseaux virtuels
[Xml.XmlElement]$netSites = $xml.NetworkConfiguration.VirtualNetworkConfiguration.VirtualNetworkSites

foreach($netSite in $netSites)
{
    if ($netSite.VirtualNetworkSite.name -eq $networkName)
    {
        # on a trouvé le réseau à reconfigurer, on créée le sous-réseau ThirdNetwork

        $newSubnet = $xml.CreateElement(« Subnet », »http://schemas.microsoft.com/ServiceHosting/2011/07/NetworkConfiguration ») 
        $newSubnet.SetAttribute(« name »,$subnetName)
        # déclare la plage IP du sous réseau
        $newAddressPrefix = $xml.CreateElement(« AddressPrefix », »http://schemas.microsoft.com/ServiceHosting/2011/07/NetworkConfiguration »)
        $newAddressPrefix.InnerText=$subnetIP
        $newSubnet.appendchild($newAddressPrefix)

       $netSite.VirtualNetworkSite.Subnets.appendchild($newSubnet)
    }
}

# sauvegarde du nouveau fichier de configuration
$tempFileName = Join-Path $env:TEMP « NetworkAmethyste.xml »
$xml.Save($tempFileName)

# reconfigure les réseaux de l’abonnement
set-AzureVNetConfig -configurationpath $tempFileName

# nettoyage
Remove-Item $tempFileName

 

Et on obtient le résultat attendu:

2015-05-01_15-09-08

Note: En l’état ce script n’est pas très industrialisé. Il faudrait valider que les différents éléments manipulés soient non nul, qu’un sous réseau du même nom n’existe pas, que la place d’IP est valide, avoir la possibilité de sélectionner un abonnement. Si on créée un nouveau réseau il faudrait vérifier les quotas par abonnement, qu’il soit créé dans une région accessible avec l’abonnement…

Rattacher une VM à un réseau

On dispose de la cmdlet Set-AzureSubnet qui rattache la VM à un sous-réseau et le paramètre VnetName de Set-AzureVM qui déclare le réseau lui-même. Voici un exemple de script:

$familyName= « Windows Server 2012 R2 Datacenter »
$size= « Small »
$vmName= « AmethysteVM1 »
$serviceName= »serviceAmethyste »
$location = « West Europe »
$user=
$pwd=

New-AzureService -ServiceName $serviceName -Location $location
$imageName = get-azurevmimage | where {$_.ImageFamily -eq $familyName}| sort PublishedDate -Descending|select -ExpandProperty ImageName -First 1

$Config = New-AzureVMConfig -Name $vmName -InstanceSize $size -ImageName $imageName
$Config | Add-AzureProvisioningConfig -Windows -AdminUsername $user -Password $pwd
$Config | Set-AzureSubnet ‘MainNetwork’
$config | New-AzureVM -ServiceName $serviceName –VNetName ‘NetworkAmethyste’  -WaitForBoot

Et le résultat:

2015-05-01_00-14-43

Bibliographie

 

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s