Tutoriel : Sécuriser votre hub virtuel avec Azure PowerShell

Dans ce tutoriel, vous allez créer une instance de WAN virtuel avec un hub virtuel dans une région, et vous allez déployer un pare-feu Azure dans le hub virtuel pour sécuriser la connectivité. Dans cet exemple, vous allez illustrer la connectivité sécurisée entre des réseaux virtuels. Le trafic entre les réseaux virtuels et les branches de site à site, de point à site ou ExpressRoute est également pris en charge par le Hub virtuel sécurisé.

Dans ce tutoriel, vous allez apprendre à :

Prerequisites

• Si vous n’avez pas d’abonnement Azure, créez un compte gratuit avant de commencer.

• PowerShell 7 ou version ultérieure

  Ce tutoriel nécessite l’exécution locale d’Azure PowerShell sur PowerShell 7 ou version ultérieure. Pour installer PowerShell 7, consultez Migration de Windows PowerShell 5.1 vers PowerShell 7.

• La version du module « Az.Network » doit être la version 4.17.0 ou une version ultérieure.

Connexion à Azure

Connect-AzAccount
Select-AzSubscription -Subscription "<sub name>"

Déploiement du WAN virtuel initial

Pour commencer, vous devez définir des variables et créer le groupe de ressources, l’instance virtual WAN et le hub virtuel :

# Variable definition
$RG = "vwan-rg"
$Location = "westeurope"
$VwanName = "vwan"
$HubName =  "hub1"
$FirewallTier = "Standard" # or "Premium"

# Create Resource Group, Virtual WAN and Virtual Hub using the New-AzVirtualWan and New-AzVirtualHub cmdlets
New-AzResourceGroup -Name $RG -Location $Location
$Vwan = New-AzVirtualWan -Name $VwanName -ResourceGroupName $RG -Location $Location -AllowVnetToVnetTraffic -AllowBranchToBranchTraffic -VirtualWANType "Standard"
$Hub = New-AzVirtualHub -Name $HubName -ResourceGroupName $RG -VirtualWan $Vwan -Location $Location -AddressPrefix "192.168.1.0/24" -Sku "Standard"

• Créez deux réseaux virtuels et connectez-les au hub en tant qu’embranchements à l’aide du cmdlet New-AzVirtualHubVnetConnection. Les réseaux virtuels sont créés avec les préfixes 10.1.1.0/24 d’adresse et 10.1.2.0/24.

# Create Virtual Network
$Spoke1 = New-AzVirtualNetwork -Name "spoke1" -ResourceGroupName $RG -Location $Location -AddressPrefix "10.1.1.0/24"
$Spoke2 = New-AzVirtualNetwork -Name "spoke2" -ResourceGroupName $RG -Location $Location -AddressPrefix "10.1.2.0/24"
# Connect Virtual Network to Virtual WAN
$Spoke1Connection = New-AzVirtualHubVnetConnection -ResourceGroupName $RG -ParentResourceName  $HubName -Name "spoke1" -RemoteVirtualNetwork $Spoke1 -EnableInternetSecurityFlag $True
$Spoke2Connection = New-AzVirtualHubVnetConnection -ResourceGroupName $RG -ParentResourceName  $HubName -Name "spoke2" -RemoteVirtualNetwork $Spoke2 -EnableInternetSecurityFlag $True

À ce stade, votre virtual WAN est entièrement opérationnel et fournit n’importe quelle connectivité. Pour sécuriser cet environnement, déployez un pare-feu Azure dans chaque hub virtuel. Vous pouvez gérer de manière centralisée ces pare-feu à l’aide de stratégies de pare-feu.

Dans cet exemple, vous allez également créer une stratégie de pare-feu pour gérer l’instance de pare-feu Azure dans le hub Virtual WAN à l’aide de l’applet New-AzFirewallPolicy de commande. Le Pare-feu Azure sera déployé dans le hub à l’aide du cmdlet New-AzFirewall.

# New Firewall Policy
$FWPolicy = New-AzFirewallPolicy -Name "VwanFwPolicy" -ResourceGroupName $RG -Location $Location
# New Firewall Public IP
$AzFWPIPs = New-AzFirewallHubPublicIpAddress -Count 1
$AzFWHubIPs = New-AzFirewallHubIpAddress -PublicIP $AzFWPIPs
# New Firewall
$AzFW = New-AzFirewall -Name "azfw1" -ResourceGroupName $RG -Location $Location `
            -VirtualHubId $Hub.Id -FirewallPolicyId $FWPolicy.Id `
            -SkuName "AZFW_Hub" -HubIPAddress $AzFWHubIPs `
            -SkuTier $FirewallTier

L’activation de la journalisation à partir du Pare-feu Azure vers Azure Monitor est facultative. Dans cet exemple, vous utilisez les journaux de pare-feu pour vérifier que le trafic transite par le pare-feu. Créez tout d'abord un espace de travail pour Log Analytics afin de stocker les journaux. Ensuite, utilisez l’applet de commande Set-AzDiagnosticSetting pour configurer les paramètres de diagnostic et envoyer les journaux à l’espace de travail.

# Optionally, enable logging of Azure Firewall to Azure Monitor
$LogWSName = "vwan-" + (Get-Random -Maximum 99999) + "-" + $RG
$LogWS = New-AzOperationalInsightsWorkspace -Location $Location -Name $LogWSName -Sku Standard -ResourceGroupName $RG
Set-AzDiagnosticSetting -ResourceId $AzFW.Id -Enabled $True -Category AzureFirewallApplicationRule, AzureFirewallNetworkRule -WorkspaceId $LogWS.ResourceId

Déployer le Pare-feu Azure et configurer le routage personnalisé.

Vous disposez maintenant d’un pare-feu Azure dans le hub, mais vous devez encore modifier le routage de sorte que le WAN virtuel envoie le trafic en provenance des réseaux virtuels et des branches à travers le pare-feu. Cette opération s’effectue en deux étapes :

1. Configurez toutes les connexions de réseau virtuel (et les connexions de branche, le cas échéant) pour une propagation vers la table de routage None. L’effet de cette configuration est que les autres réseaux virtuels et branches n’apprendront pas leurs préfixes, et n’auront donc pas de routage pour les atteindre.
2. Vous pouvez maintenant insérer des routes statiques dans la table de routage Default (où tous les réseaux virtuels et branches sont associés par défaut), afin que tout le trafic soit envoyé au pare-feu Azure.

Commencez par configurer vos connexions de réseau virtuel pour se propager à la None table de routage. Cette étape garantit que les réseaux virtuels n’apprennent pas les préfixes d’adresse les uns des autres, ce qui empêche la communication directe entre eux. Par conséquent, tout le trafic réseau inter-virtuel doit passer par le Pare-feu Azure.

Pour ce faire, utilisez l’applet Get-AzVhubRouteTable de commande pour récupérer la None table de routage, puis mettez à jour la configuration de routage de chaque connexion de réseau virtuel avec l’applet Update-AzVirtualHubVnetConnection de commande.

# Configure Virtual Network connections in hub to propagate to None
$VnetRoutingConfig = $Spoke1Connection.RoutingConfiguration    # We take $Spoke1Connection as baseline for the future vnet config, all vnets will have an identical config
$NoneRT = Get-AzVhubRouteTable -ResourceGroupName $RG -HubName $HubName -Name "noneRouteTable"
$NewPropRT = @{}
$NewPropRT.Add('Id', $NoneRT.Id)
$PropRTList = @()
$PropRTList += $NewPropRT
$VnetRoutingConfig.PropagatedRouteTables.Ids = $PropRTList
$VnetRoutingConfig.PropagatedRouteTables.Labels = @()
$Spoke1Connection = Update-AzVirtualHubVnetConnection -ResourceGroupName $RG -ParentResourceName  $HubName -Name "spoke1" -RoutingConfiguration $VnetRoutingConfig
$Spoke2Connection = Update-AzVirtualHubVnetConnection -ResourceGroupName $RG -ParentResourceName  $HubName -Name "spoke2" -RoutingConfiguration $VnetRoutingConfig

Ensuite, passez à la deuxième étape : ajouter des itinéraires statiques à la table de routage Default. L’exemple suivant utilise la configuration par défaut appliquée par Azure Firewall Manager lors de la sécurisation de la connectivité dans un virtual WAN. Vous pouvez personnaliser la liste des préfixes dans l’itinéraire statique en fonction des besoins à l’aide de l’applet New-AzVHubRoute de commande. Dans cet exemple, tout le trafic est acheminé via le Pare-feu Azure, qui est la valeur par défaut recommandée.

# Create static routes in default Route table
$AzFWId = $(Get-AzVirtualHub -ResourceGroupName $RG -name  $HubName).AzureFirewall.Id
$AzFWRoute = New-AzVHubRoute -Name "all_traffic" -Destination @("0.0.0.0/0", "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16") -DestinationType "CIDR" -NextHop $AzFWId -NextHopType "ResourceId"
$DefaultRT = Update-AzVHubRouteTable -Name "defaultRouteTable" -ResourceGroupName $RG -VirtualHubName  $HubName -Route @($AzFWRoute)

Activation de l'intention de routage

Si vous souhaitez envoyer du trafic inter hub et interrégion via le Pare-feu Azure déployé dans le hub Virtual WAN, vous pouvez à la place activer la fonctionnalité d'intention de routage. Pour plus d'informations sur l'intention de routage, consultez la Documentation sur l'intention de routage.

# Get the Azure Firewall resource ID
$AzFWId = $(Get-AzVirtualHub -ResourceGroupName <thname> -name  $HubName).AzureFirewall.Id

# Create routing policy and routing intent
$policy1 = New-AzRoutingPolicy -Name "PrivateTraffic" -Destination @("PrivateTraffic") -NextHop $firewall.Id
$policy2 = New-AzRoutingPolicy -Name "PublicTraffic" -Destination @("Internet") -NextHop $firewall.Id
New-AzRoutingIntent -ResourceGroupName "<rgname>" -VirtualHubName "<hubname>" -Name "hubRoutingIntent" -RoutingPolicy @($policy1, $policy2)
If your Virtual WAN uses non-RFC1918 address prefixes (for example, `40.0.0.0/24` in a virtual network or on-premises), you should add an extra route to the `defaultRouteTable` after completing the routing intent configuration. Name this route **private_traffic**. If you use a different name, the route will work as expected, but the configuration will not be reflected in the Azure portal.

```azurepowershell-interactive
# Get the defaultRouteTable
$defaultRouteTable = Get-AzVHubRouteTable -ResourceGroupName routingIntent-Demo -HubName wus_hub1 -Name defaultRouteTable

# Get the routes automatically created by routing intent. If private routing policy is enabled, this is the route named _policy_PrivateTraffic. If internet routing policy is enabled, this is the route named _policy_InternetTraffic. 
$privatepolicyroute = $defaultRouteTable.Routes[1]


# Create new route named private_traffic for non-RFC1918 prefixes
$private_traffic = New-AzVHubRoute -Name "private-traffic" -Destination @("30.0.0.0/24") -DestinationType "CIDR" -NextHop $AzFWId -NextHopType ResourceId

# Create new routes for route table
$newroutes = @($privatepolicyroute, $private_traffic)

# Update route table
Update-AzVHubRouteTable -ResourceGroupName <rgname> -ParentResourceName <hubname> -Name defaultRouteTable -Route $newroutes

Tester la connectivité

Maintenant que votre hub sécurisé est entièrement opérationnel, vous pouvez tester la connectivité en déployant une machine virtuelle dans chaque réseau virtuel spoke connecté au hub :

# Create VMs in spokes for testing
$VMLocalAdminUser = "lab-user"
$VMLocalAdminSecurePassword = ConvertTo-SecureString -AsPlainText -Force
$VMCredential = New-Object System.Management.Automation.PSCredential ($VMLocalAdminUser, $VMLocalAdminSecurePassword);
$VMSize = "Standard_B2ms"
# Spoke1
$Spoke1 = Get-AzVirtualNetwork -ResourceGroupName $RG -Name "spoke1"
Add-AzVirtualNetworkSubnetConfig -Name "vm" -VirtualNetwork $Spoke1 -AddressPrefix "10.1.1.0/26"
$Spoke1 | Set-AzVirtualNetwork
$VM1 = New-AzVM -Name "spoke1-vm" -ResourceGroupName $RG -Location $Location `
            -Image "UbuntuLTS" -credential $VMCredential `
            -VirtualNetworkName "spoke1" -SubnetName "vm" -PublicIpAddressName "spoke1-pip"
$NIC1 = Get-AzNetworkInterface -ResourceId $($VM1.NetworkProfile.NetworkInterfaces[0].Id)
$Spoke1VMPrivateIP = $NIC1.IpConfigurations[0].PrivateIpAddress
$Spoke1VMPIP = $(Get-AzPublicIpAddress -ResourceGroupName $RG -Name "spoke1-pip")
# Spoke2
$Spoke2 = Get-AzVirtualNetwork -ResourceGroupName $RG -Name "spoke2"
Add-AzVirtualNetworkSubnetConfig -Name "vm" -VirtualNetwork $Spoke2 -AddressPrefix "10.1.2.0/26"
$Spoke2 | Set-AzVirtualNetwork
$VM2 = New-AzVM -Name "spoke2-vm" -ResourceGroupName $RG -Location $Location `
            -Image "UbuntuLTS" -credential $VMCredential `
            -VirtualNetworkName "spoke2" -SubnetName "vm" -PublicIpAddressName "spoke2-pip"
$NIC2 = Get-AzNetworkInterface -ResourceId $($VM2.NetworkProfile.NetworkInterfaces[0].Id)
$Spoke2VMPrivateIP = $NIC2.IpConfigurations[0].PrivateIpAddress
$Spoke2VMPIP = $(Get-AzPublicIpAddress -ResourceGroupName $RG -Name "spoke2-pip")

Par défaut, la stratégie de pare-feu bloque tout le trafic. Pour autoriser l’accès à vos machines virtuelles de test, vous devez configurer des règles DNAT (Traduction d’adresses réseau de destination). Ces règles vous permettent de vous connecter aux machines virtuelles via l’adresse IP publique du Pare-feu Azure :

# Adding DNAT rules for virtual machines in the spokes
$AzFWPublicAddress = $AzFW.HubIPAddresses.PublicIPs.Addresses[0].Address
$NATRuleSpoke1 = New-AzFirewallPolicyNatRule -Name "Spoke1SSH" -Protocol "TCP" `
        -SourceAddress "*" -DestinationAddress $AzFWPublicAddress -DestinationPort 10001 `
        -TranslatedAddress $Spoke1VMPrivateIP -TranslatedPort 22
$NATRuleSpoke2 = New-AzFirewallPolicyNatRule -Name "Spoke2SSH" -Protocol "TCP" `
        -SourceAddress "*" -DestinationAddress $AzFWPublicAddress -DestinationPort 10002 `
        -TranslatedAddress $Spoke2VMPrivateIP -TranslatedPort 22
$NATCollection = New-AzFirewallPolicyNatRuleCollection -Name "SSH" -Priority 100 `
        -Rule @($NATRuleSpoke1, $NATRuleSpoke2) -ActionType "Dnat"
$NATGroup = New-AzFirewallPolicyRuleCollectionGroup -Name "NAT" -Priority 100 -RuleCollection $NATCollection -FirewallPolicyObject $FWPolicy

Ensuite, configurez des exemples de règles pour votre stratégie de pare-feu. Tout d’abord, créez une règle de réseau pour autoriser le trafic SSH entre les réseaux virtuels. Ensuite, ajoutez une règle d’application pour autoriser l’accès Internet uniquement au nom de domaine complet (FQDN), ifconfig.coqui retourne l’adresse IP source affichée dans la requête HTTP :

# Add Network Rule
$SSHRule = New-AzFirewallPolicyNetworkRule -Name PermitSSH -Protocol TCP `
        -SourceAddress "10.0.0.0/8" -DestinationAddress "10.0.0.0/8" -DestinationPort 22
$NetCollection = New-AzFirewallPolicyFilterRuleCollection -Name "Management" -Priority 100 -ActionType Allow -Rule $SSHRule
$NetGroup = New-AzFirewallPolicyRuleCollectionGroup -Name "Management" -Priority 200 -RuleCollection $NetCollection -FirewallPolicyObject $FWPolicy
# Add Application Rule
$ifconfigRule = New-AzFirewallPolicyApplicationRule -Name PermitIfconfig -SourceAddress "10.0.0.0/8" -TargetFqdn "ifconfig.co" -Protocol "http:80","https:443"
$AppCollection = New-AzFirewallPolicyFilterRuleCollection -Name "TargetURLs" -Priority 300 -ActionType Allow -Rule $ifconfigRule
$NetGroup = New-AzFirewallPolicyRuleCollectionGroup -Name "TargetURLs" -Priority 300 -RuleCollection $AppCollection -FirewallPolicyObject $FWPolicy

Avant d’envoyer un trafic, vérifiez les itinéraires effectifs pour chaque machine virtuelle. Les tables de routage doivent afficher les préfixes appris depuis le WAN virtuel (0.0.0.0/0) et les plages de RFC1918, mais ne doivent pas inclure le préfixe d’adresse de l’autre réseau virtuel spoke.

# Check effective routes in the VM NIC in spoke 1
# Note that 10.1.2.0/24 (the prefix for spoke2) should not appear
Get-AzEffectiveRouteTable -ResourceGroupName $RG -NetworkInterfaceName $NIC1.Name | ft
# Check effective routes in the VM NIC in spoke 2
# Note that 10.1.1.0/24 (the prefix for spoke1) should not appear
Get-AzEffectiveRouteTable -ResourceGroupName $RG -NetworkInterfaceName $NIC2.Name | ft

Générez le trafic d’une machine virtuelle vers l’autre et vérifiez qu’il est filtré par le Pare-feu Azure. Utilisez SSH pour vous connecter aux machines virtuelles : acceptez l’empreinte SSH et entrez le mot de passe que vous avez défini lors de la création de la machine virtuelle. Dans cet exemple, vous allez :

• Envoyez cinq requêtes d’écho ICMP (pings) de la machine virtuelle en spoke1 à la machine virtuelle en spoke2.
• Essayez une connexion TCP sur le port 22 à l’aide de l’utilitaire nc (netcat) avec les -vz indicateurs, qui vérifie la connectivité sans envoyer de données.

Vous devez observer que les requêtes ping échouent (bloquées par le pare-feu), tandis que la connexion TCP sur le port 22 réussit, comme autorisé par la règle réseau précédemment configurée.

# Connect to one VM and ping the other. It should not work, because the firewall should drop the traffic, since no rule for ICMP is configured
ssh $AzFWPublicAddress -p 10001 -l $VMLocalAdminUser "ping $Spoke2VMPrivateIP -c 5"
# Connect to one VM and send a TCP request on port 22 to the other. It should work, because the firewall is configured to allow SSH traffic (port 22)
ssh $AzFWPublicAddress -p 10001 -l $VMLocalAdminUser "nc -vz $Spoke2VMPrivateIP 22"

Vous pouvez également tester l’accès à Internet via le pare-feu. Les requêtes HTTP utilisant l’utilitaire curl vers le nom de domaine complet autorisé (ifconfig.co) doivent réussir, tandis que les requêtes adressées à d’autres destinations (par exemple bing.com) doivent être bloquées par la stratégie de pare-feu :

# This HTTP request should succeed, since it is allowed in an app rule in the AzFW, and return the public IP of the FW
ssh $AzFWPublicAddress -p 10001 -l $VMLocalAdminUser "curl -s4 ifconfig.co"
# This HTTP request should fail, since the FQDN bing.com is not in any app rule in the firewall policy
ssh $AzFWPublicAddress -p 10001 -l $VMLocalAdminUser "curl -s4 bing.com"

Pour confirmer que le pare-feu supprime les paquets comme prévu, examinez les journaux de suivi envoyés à Azure Monitor. Étant donné qu’Azure Firewall est configuré pour envoyer des journaux de diagnostic à Azure Monitor, vous pouvez utiliser Kusto Query Language (KQL) pour interroger et analyser les entrées de journal appropriées :

# Getting Azure Firewall network rule Logs
$LogWS = Get-AzOperationalInsightsWorkspace -ResourceGroupName $RG
$LogQuery = 'AzureDiagnostics
| where Category == "AzureFirewallNetworkRule"
| where TimeGenerated >= ago(5m)
| parse msg_s with Protocol " request from " SourceIP ":" SourcePortInt:int " to " TargetIP ":" TargetPortInt:int *
| parse msg_s with * ". Action: " Action1a
| parse msg_s with * " was " Action1b " to " NatDestination
| parse msg_s with Protocol2 " request from " SourceIP2 " to " TargetIP2 ". Action: " Action2
| extend SourcePort = tostring(SourcePortInt),TargetPort = tostring(TargetPortInt)
| extend Action = case(Action1a == "", case(Action1b == "",Action2,Action1b), Action1a),Protocol = case(Protocol == "", Protocol2, Protocol),SourceIP = case(SourceIP == "", SourceIP2, SourceIP),TargetIP = case(TargetIP == "", TargetIP2, TargetIP),SourcePort = case(SourcePort == "", "N/A", SourcePort),TargetPort = case(TargetPort == "", "N/A", TargetPort),NatDestination = case(NatDestination == "", "N/A", NatDestination)
| project TimeGenerated, Protocol, SourceIP,SourcePort,TargetIP,TargetPort,Action, NatDestination, Resource
| take 25 '
$(Invoke-AzOperationalInsightsQuery -Workspace $LogWS -Query $LogQuery).Results | ft

Dans la commande précédente, vous devriez voir différentes entrées :

• Traduction DNAT appliquée à votre connexion SSH.
• Suppression des paquets ICMP entre les machines virtuelles dans les spokes (10.1.1.4 et 10.1.2.4).
• Connexions SSH autorisées entre les machines virtuelles dans les spokes.

Voici un exemple de sortie produit par la commande ci-dessus :

TimeGenerated            Protocol    SourceIP       SourcePort TargetIP      TargetPort Action  NatDestination Resource
-------------            --------    --------       ---------- --------      ---------- ------  -------------- --------
2020-10-04T20:53:02.41Z  TCP         109.125.122.99 62281      51.105.224.44 10001      DNAT'ed 10.1.1.4:22    AZFW1
2020-10-04T20:53:07.045Z TCP         10.1.1.4       35932      10.1.2.4      22         Allow   N/A            AZFW1
2020-10-04T20:53:50.119Z TCP         109.125.122.99 62293      51.105.224.44 10001      DNAT'ed 10.1.2.4:22    AZFW1
2020-10-04T20:52:47.475Z TCP         109.125.122.99 62273      51.105.224.44 10001      DNAT'ed 10.1.2.4:22    AZFW1
2020-10-04T20:51:04.682Z TCP         109.125.122.99 62200      51.105.224.44 10001      DNAT'ed 10.1.2.4:22    AZFW1
2020-10-04T20:51:17.031Z ICMP Type=8 10.1.1.4       N/A        10.1.2.4      N/A        Deny    N/A            AZFW1
2020-10-04T20:51:18.049Z ICMP Type=8 10.1.1.4       N/A        10.1.2.4      N/A        Deny    N/A            AZFW1
2020-10-04T20:51:19.075Z ICMP Type=8 10.1.1.4       N/A        10.1.2.4      N/A        Deny    N/A            AZFW1
2020-10-04T20:51:20.097Z ICMP Type=8 10.1.1.4       N/A        10.1.2.4      N/A        Deny    N/A            AZFW1
2020-10-04T20:51:21.121Z ICMP Type=8 10.1.1.4       N/A        10.1.2.4      N/A        Deny    N/A            AZFW1
2020-10-04T20:52:52.356Z TCP         10.1.1.4       53748      10.1.2.4      22         Allow   N/A            AZFW1

Si vous souhaitez afficher les journaux des règles d’application (décrivant les connexions HTTP autorisées et refusées) ou modifier la façon dont les journaux sont affichés, vous pouvez essayer d’autres requêtes KQL. Vous trouverez des exemples dans Journaux Azure Monitor pour Pare-feu Azure.

Pour nettoyer l’environnement de test, supprimez le groupe de ressources et toutes les ressources associées à l’aide de l’applet Remove-AzResourceGroup de commande. Cela supprimera le Virtual WAN, le Virtual Hub, le Pare-feu Azure et toutes les autres ressources créées au cours de ce tutoriel.

# Delete resource group and all contained resources
Remove-AzResourceGroup -Name $RG

Déployer une instance Pare-feu Azure avec des zones de disponibilité sur un hub existant

Les étapes précédentes ont montré comment utiliser Azure PowerShell pour créer un hub Azure Virtual WAN et le sécuriser avec le Pare-feu Azure. Vous pouvez également sécuriser un hub Azure Virtual WAN existant à l’aide d’une approche basée sur des scripts similaire. Bien que Firewall Manager puisse convertir un hub en hub sécurisé, il ne prend pas en charge le déploiement du Pare-feu Azure sur les zones de disponibilité via le portail. Pour déployer le Pare-feu Azure dans les trois zones de disponibilité, utilisez le script PowerShell suivant pour convertir votre hub Virtual WAN existant en hub sécurisé.

# Variable definition
$RG = "vwan-rg"
$Location = "westeurope"
$VwanName = "vwan"
$HubName =  "hub1"
$FirewallName = "azfw1"
$FirewallTier = "Standard" # or "Premium"
$FirewallPolicyName = "VwanFwPolicy"

# Get references to vWAN and vWAN Hub to convert #
$Vwan = Get-AzVirtualWan -ResourceGroupName $RG -Name $VwanName
$Hub = Get-AzVirtualHub -ResourceGroupName  $RG -Name $HubName

# Create a new Firewall Policy #
$FWPolicy = New-AzFirewallPolicy -Name $FirewallPolicyName -ResourceGroupName $RG -Location $Location

# Create a new Firewall Public IP #
$AzFWPIPs = New-AzFirewallHubPublicIpAddress -Count 1
$AzFWHubIPs = New-AzFirewallHubIpAddress -PublicIP $AzFWPIPs

# Create Firewall instance #
$AzFW = New-AzFirewall -Name $FirewallName -ResourceGroupName $RG -Location $Location `
            -VirtualHubId $Hub.Id -FirewallPolicyId $FWPolicy.Id `
            -SkuName "AZFW_Hub" -HubIPAddress $AzFWHubIPs `
            -SkuTier $FirewallTier `
            -Zone 1,2,3

Après avoir exécuté ce script, les zones de disponibilité doivent apparaître dans les propriétés du hub sécurisé, comme illustré dans la capture d’écran suivante :

Après avoir déployé le Pare-feu Azure, vous devez effectuer les étapes de configuration décrites dans le pare-feu Azure précédent et configurer la section de routage personnalisée pour garantir un routage et une sécurité appropriés.

Étapes suivantes