Esercitazione: Proteggere l'hub virtuale con Azure PowerShell
In questa esercitazione si crea un'istanza di rete WAN virtuale con un hub virtuale in un'area, quindi si distribuisce un'istanza di Firewall di Azure nell'hub virtuale per proteggere la connettività. In questo esempio viene illustrata la connettività sicura tra reti virtuali. L'hub virtuale sicuro protegge il traffico tra reti virtuali e anche tra rami da sito a sito, da punto a sito o ExpressRoute.
In questa esercitazione verranno illustrate le procedure per:
- Distribuire la rete WAN virtuale
- Distribuire Firewall di Azure e configurare il routing personalizzato
- Testare la connettività
Importante
Un rete WAN virtuale è una raccolta di hub e servizi resi disponibili all'interno dell'hub. È possibile distribuire tutti i WAN virtuali necessari. In un hub rete WAN virtuale sono disponibili più servizi, ad esempio VPN, ExpressRoute e così via. Ognuno di questi servizi viene distribuito automaticamente in zone di disponibilitàexcept Firewall di Azure, se l'area supporta zone di disponibilità. Per aggiornare un hub di Azure rete WAN virtuale esistente a un hub sicuro e usare zone di disponibilità Firewall di Azure, è necessario usare Azure PowerShell, come descritto più avanti in questo articolo.
Prerequisiti
Se non si ha una sottoscrizione di Azure, creare un account gratuito prima di iniziare.
PowerShell 7
Per questa esercitazione è necessario eseguire Azure PowerShell in locale in PowerShell 7. Per installare PowerShell 7, vedere Migrazione da Windows PowerShell 5.1 a PowerShell 7.
La versione del modulo "Az.Network" deve essere 4.17.0 o successiva.
Accedere ad Azure
Connect-AzAccount
Select-AzSubscription -Subscription "<sub name>"
Distribuzione iniziale della rete WAN virtuale
Come primo passaggio, è necessario impostare alcune variabili e creare il gruppo di risorse, l'istanza della rete WAN virtuale e l'hub virtuale:
# Variable definition
$RG = "vwan-rg"
$Location = "westeurope"
$VwanName = "vwan"
$HubName = "hub1"
$FirewallTier = "Standard" # or "Premium"
# Create Resource Group, Virtual WAN and Virtual Hub
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"
Creare due reti virtuali e connetterle all'hub come spoke:
# 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
A questo punto, è disponibile una rete WAN virtuale completamente funzionante che fornisce connettività Any-To-Any. Per migliorare la sicurezza, è necessario distribuire un'istanza di Firewall di Azure in ogni hub virtuale. Per gestire efficientemente l'istanza di Firewall di Azure nella rete WAN virtuale, è possibile usare i criteri firewall. Quindi in questo esempio viene creato anche un criterio firewall:
# 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
Nota
Il comando di creazione del firewall seguente non usa zone di disponibilità. Se si vuole usare questa funzionalità, è necessario un parametro aggiuntivo -Zone . Viene fornito un esempio nella sezione relativa all'aggiornamento alla fine di questo articolo.
L'abilitazione della registrazione da Firewall di Azure a Monitoraggio di Azure è facoltativa, ma in questo esempio si usano i log di Firewall per dimostrare che il traffico attraversa il firewall:
# Optionally, enable looging 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
Distribuire Firewall di Azure e configurare il routing personalizzato
Nota
Questa è la configurazione distribuita quando si protegge la connettività dal portale di Azure con Firewall di Azure Manager quando l'impostazione "Inter-hub" è impostata su disabilitata. Per istruzioni su come configurare il routing tramite PowerShell quando l'opzione "Inter-hub" è impostata su abilitata, vedere Abilitazione della finalità di routing.
A questo punto è disponibile un'istanza di Firewall di Azure nell'hub, ma è comunque necessario modificare il routing in modo che la rete WAN virtuale invii il traffico proveniente dalle reti virtuali e dai rami attraverso il firewall. A questo scopo, eseguire due passaggi:
- Configurare tutte le connessioni di rete virtuale (e le connessioni ai rami, se presenti), in modo che vengano propagate alla tabella di route
None. L'effetto di questa configurazione è che altre reti virtuali e rami non riconosceranno i prefissi e quindi non verranno raggiunte da alcun routing. - È ora possibile inserire route statiche nella tabella di route
Default(in cui tutte le reti virtuali e tutti i rami sono associati per impostazione predefinita), in modo che tutto il traffico venga inviato a Firewall di Azure.
Iniziare con il primo passaggio per configurare le connessioni di rete virtuale da propagare alla tabella di route None:
# 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
È ora possibile continuare con il secondo passaggio per aggiungere le route statiche alla tabella di route Default. In questo esempio viene applicata la configurazione predefinita che verrà generata da Gestione firewall di Azure per la protezione della connettività in una rete WAN virtuale, ma è possibile cambiare l'elenco dei prefissi nella route statica per soddisfare requisiti specifici:
# 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)
Nota
La stringa "all_traffic" come valore per il parametro "-Name" nel comando New-AzVHubRoute precedente ha un significato speciale: se si usa questa stringa esatta, la configurazione applicata in questo articolo verrà riflessa correttamente nel portale di Azure (Gestione firewall --> Hub virtuale -> [Hub] --> Configurazione della sicurezza). Se verrà usato un nome diverso, verrà applicata la configurazione desiderata, ma non verrà riflessa nel portale di Azure.
Abilitazione della finalità di routing
Se si vuole inviare il traffico tra hub e tra aree tramite Firewall di Azure distribuito nell'hub rete WAN virtuale, è invece possibile abilitare la funzionalità di finalità di routing. Per altre informazioni sulla finalità di routing, vedere la documentazione relativa alla finalità di routing.
Nota
Questa è la configurazione distribuita quando si protegge la connettività dal portale di Azure con Firewall di Azure Manager quando l'impostazione "Interhub" è impostata su abilitato.
# 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)
Se si usano prefissi non RFC1918 nel rete WAN virtuale, ad esempio 40.0.0.0/24 nel Rete virtuale o in locale, aggiungere un'altra route nell'oggetto defaultRouteTable al termine della configurazione della finalità di routing. Assicurarsi di denominare questa route come private_traffic. Se la route è denominata in caso contrario, verrà applicata la configurazione desiderata, ma non verrà riflessa nel portale di Azure.
# 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
Testare la connettività
A questo punto è disponibile un hub sicuro completamente operativo. Per testare la connettività, è necessario avere una macchina virtuale in ogni rete virtuale spoke connessa all'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")
La configurazione predefinita nei criteri firewall prevede l'eliminazione di tutto il traffico. Quindi è necessario configurare alcune regole. Iniziare con le regole DNAT, in modo che le macchine virtuali di test siano accessibili tramite l'indirizzo IP pubblico del firewall:
# 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
Ora è possibile configurare alcune regole di esempio. Definire una regola di rete che consenta il traffico SSH, oltre a una regola dell'applicazione che consenta l'accesso a Internet al nome di dominio completo ifconfig.co. Questo URL restituisce l'indirizzo IP di origine visualizzato nella richiesta 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
Prima di inviare effettivamente il traffico, è possibile esaminare le route effettive delle macchine virtuali. Dovrebbero contenere i prefissi riconosciuti dalla WAN virtuale (0.0.0.0/0 più RFC1918), ma non il prefisso dell'altro 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
Generare ora il traffico da una macchina virtuale all'altra e verificare che venga eliminato in Firewall di Azure. Nei comandi SSH seguenti è necessario accettare le impronte digitali delle macchine virtuali e fornire la password definita al momento della relativa creazione. In questo esempio si invieranno cinque pacchetti di richiesta echo ICMP dalla macchina virtuale in spoke1 a spoke2, oltre a eseguire un tentativo di connessione TCP sulla porta 22 con l'utilità Linux nc (con i flag -vz viene semplicemente inviata una richiesta di connessione e viene visualizzato il risultato). Si noterà che il ping non riesce, mentre il tentativo di connessione TCP sulla porta 22 riesce, perché è consentito dalla regola di rete configurata in precedenza:
# 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"
È anche possibile verificare il traffico Internet. Le richieste HTTP tramite l'utilità curl al nome di dominio completo consentito nei criteri firewall (ifconfig.co) dovrebbero funzionare, ma le richieste HTTP inviate a qualsiasi altra destinazione avranno esito negativo (in questo esempio si esegue il test con bing.com):
# 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"
Il modo più semplice per verificare se i pacchetti vengono eliminati dal firewall consiste nel controllare i log. Poiché Firewall di Azure è stato configurato per l'invio di log a Monitoraggio di Azure, è possibile usare il linguaggio di query Kusto per recuperare i log appropriati da Monitoraggio di Azure:
Nota
Può essere necessario circa 1 minuto prima che i log vengano inviati a Monitoraggio di Azure
# 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
Nel comando precedente dovrebbero essere visualizzate voci diverse:
- La connessione SSH sottoposta a regole DNAT
- I pacchetti ICMP eliminati tra le VM negli spoke (10.1.1.4 e 10.1.2.4)
- Le connessioni SSH consentite tra le VM negli spoke
Ecco un output di esempio prodotto dal comando precedente:
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
Per visualizzare i log per le regole dell'applicazione, che includono le connessioni HTTP consentite e negate, o per cambiare la modalità di visualizzazione dei log, è possibile provare altre query KQL. Per altri esempi, vedere Log di Monitoraggio di Azure per Firewall di Azure.
Pulire le risorse
Per eliminare l'ambiente di test, è possibile rimuovere il gruppo di risorse con tutti gli oggetti che contiene:
# Delete resource group and all contained resources
Remove-AzResourceGroup -Name $RG
Aggiornare un hub esistente con zone di disponibilità
La procedura precedente usa Azure PowerShell per creare un nuovo hub di Azure rete WAN virtuale e quindi lo converte immediatamente in un hub protetto usando Firewall di Azure. Un approccio simile può essere applicato a un hub di Azure rete WAN virtuale esistente. Gestione firewall può essere usato anche per la conversione, ma non è possibile distribuire Firewall di Azure tra zone di disponibilità senza un approccio basato su script. È possibile usare il frammento di codice seguente per convertire un hub di Azure rete WAN virtuale esistente in un hub protetto, usando un Firewall di Azure distribuito in tutti e tre i zone di disponibilità.
# 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
Dopo aver eseguito questo script, zone di disponibilità dovrebbe essere visualizzato nelle proprietà dell'hub protetto, come illustrato nello screenshot seguente:
Dopo aver distribuito il Firewall di Azure, è necessario completare una procedura di configurazione come descritto nella sezione precedente Deploy Firewall di Azure and configure custom routing (Distribuisci Firewall di Azure).
Passaggi successivi
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per