Blog

Azure Networking – TP – Part 2 - vNet Peering

nice abstract image

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 traffic.
$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 example) 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.