Mickael Lopes et moi avons animé une session au Global Azure Bootcamp intitulée : “Le réseau dans Azure : Cas d’usage et Retour d’expériences”.
Les slides de  notre session sont dispo sur slideshare ici : Slideshare de Mickael
Comme prévu, voici des TP pour aller avec notre présentation, a faire vous même 🙂
Ce post est la suite de la partie 1, qui part du principe que vous avez déjà la partie 1 de faite sur votre tenant, dans toutes les versions (Powershell, Azure Cli 2.0 et ARM Template).

vNet Peering

L’objectif est de connecter nos 3 Vnets, avec nos 3 outils :

  • vnet-test-ps
  • vnet-test-az
  • vnet-test-json

Powershell

Nous allons créer le lien entre vnet-test-ps et vnet-test-az :

$vnetPS = Get-AzureRmVirtualNetwork -ResourceGroupName RG-Vnet-Exo-PS -Name vnet-test-ps
$vnetAZ = Get-AzureRmVirtualNetwork -ResourceGroupName RG-Vnet-Exo-AZ -Name vnet-test-az

Puis nous créons le lien PS2AZ :

Add-AzureRmVirtualNetworkPeering -Name PS2AZ -VirtualNetwork $vnetPS -RemoteVirtualNetworkId $vnetAZ.Id
Add-AzureRmVirtualNetworkPeering -Name AZ2PS -VirtualNetwork $vnetAZ -RemoteVirtualNetworkId $vnetPS.Id

nous pouvons vérifié si le peering est fonctionnel via la commande Powershell :

 Get-AzureRmVirtualNetworkPeering -VirtualNetworkName vnetPS -ResourceGroupName vnetPS -Name PS2AZ

en l’état, notre peering est configuré mais certaines options ne sont pas activées :

  • Forwarded Traffic
  • Gateway Transit
  • Remote Gateways

Dans notre cas, nous avons besoin d’activer le transfert du trafic.

$ps2az = Get-AzureRmVirtualNetworkPeering -VirtualNetworkName vnetPS -ResourceGroupName vnetPS -Name PS2AZ
$ps2az.AllowForwardedTraffic = $true
Set-AzureRmVirtualNetworkPeering -VirtualNetworkPeering $ps2az

Azure CLI 2.0

Avec Azure CLI, il faudra recupéré l’id du réseau distant pour le peering avec la commande :

az network vnet list -g RG-Vnet-Exo-JSON

et vous recuperez un objets json, cherchez votre id qui sera du type :

/subscriptions/VOTREIDDESOUSCRPTION/resourceGroups/RG-Vnet-Exo-JSON/providers/Microsoft.Network/virtualNetworks/vnet-test-json

Si vous utilisez le bash (Ubuntu on Windows par exemple) créer une variable comme ceci :

JSON_VNET_ID="/subscriptions/VOTREIDDESOUSCRPTION/resourceGroups/RG-Vnet-Exo-JSON/providers/Microsoft.Network/virtualNetworks/vnet-test-json"

Ce sera beaucoup plus simple pour l’appeler dans la commande suivante :

 az network vnet peering create --name AZ2JSON \
   --remote-vnet-id ${$JSON_VNET_ID} \
   --resource-group RG-Vnet-Exo-AZ \
   --vnet-name vnet-test-az \ 
   --allow-forwarded-traffic \
   --allow-vnet-access \

Théoriquement, nous pourrions executer la commande pour effectuer le peering dans l’autre sens, mais nous allons la faire avec notre template de la partie 1.

ARM Template

Pour déclarer un vnet peering dans un template ARM, à l’heure actuelle, via le portail ou la ligne de commande (Powershell ou Azure CLI 2.0) il n’est pas possible dans le “contexte” de manipuler deux Resource Group. Du coup, il faut le faire d’un coté puis de l’autre, ou utiliser des templates “nested” c’est à dire un template “parent” puis deux “enfants”. Nous n’allons (pas encore ;)) aborder ce type de template. (Stay Tuned !)

Donc, reprenons notre template et ajoutons un nouveau type de resource Azure “Microsoft.Network/virtualNetworks/virtualNetworkPeerings”

{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"vnetname": {
"type": "string",
"metadata": {
"description": "Nom du Vnet"
},
"defaultValue": "vnet-test-json"
},
"vNetRemote": {
"type": "string",
"metadata": {
"description": "Nom du Vnet distant"
},
"defaultValue": "vnet-test-az"
},
"RGvNetRemote": {
"type": "string",
"metadata": {
"description": "Nom du Resource Group"
},
"defaultValue": "RG-Vnet-Exo-AZ"
},
"addressSpacePrefix": {
"type": "string",
"metadata": {
"description": "IP v4 (RFC1918)"
},
"defaultValue": "10.0.2.0/24"
},
"subnetName": {
"type": "string",
"metadata": {
"description": "Nom du Subnet"
},
"defaultValue": "jsonfrontend"
},
"subnetPrefix": {
"type": "string",
"metadata": {
"description": "IP v4 du Subnet"
},
"defaultValue": "10.0.2.0/26"
}
},
"variables": {},
"resources": [
{
"apiVersion": "2015-06-15",
"type": "Microsoft.Network/virtualNetworks",
"name": "[parameters('VnetName')]",
"location": "[resourceGroup().location]",
"tags": {
"displayName": "JSON-VNET"
},
"properties": {
"addressSpace": {
"addressPrefixes": [
"[parameters('addressSpacePrefix')]"
]
},
"subnets": [
{
"name": "[parameters('subnetName')]",
"properties": {
"addressPrefix": "[parameters('subnetPrefix')]"
}
}
]
}
},
{
"apiVersion": "2017-03-01",
"type": "Microsoft.Network/virtualNetworks/virtualNetworkPeerings",
"name": "[concact( parameters('VnetName') , '/JSON2AZ')]",
"location": "[resourceGroup().location]",
"properties": {
"allowVirtualNetworkAccess": true,
"allowForwardedTraffic": true,
"allowGatewayTransit": false,
"useRemoteGateways": false,
"remoteVirtualNetwork": {
"id": "[resourceId( subscription().subscriptionid, parameters('RGvNetRemote') , 'Microsoft.Network/virtualNetworks', parameters('vNetRemote'))]"
}
}
}
],
"outputs": {}
}

La méthode de déploiement reste la même que dans la partie 1.

5 comments on “Azure Networking – TP – Part 2 – vNet Peering

Leave a Reply

Your email address will not be published. Required fields are marked *