Självstudie: Skydda din virtuella hubb med Hjälp av Azure PowerShell
I den här självstudien skapar du en Virtual WAN-instans med en virtuell hubb i en region och distribuerar en Azure-brandvägg i den virtuella hubben för att skydda anslutningen. I det här exemplet demonstrerar du säker anslutning mellan virtuella nätverk. Trafik mellan virtuella nätverk och grenarna plats-till-plats, punkt-till-plats eller ExpressRoute stöds också av Virtual Secure Hub.
I den här självstudien lär du dig att:
- Distribuera det virtuella WAN-nätverket
- Distribuera Azure Firewall och konfigurera anpassad routning
- Testa anslutning
Viktigt!
Ett virtuellt WAN är en samling hubbar och tjänster som görs tillgängliga i hubben. Du kan distribuera så många virtuella WAN som du behöver. I en Virtual WAN-hubb finns det flera tjänster som VPN, ExpressRoute och så vidare. Var och en av dessa tjänster distribueras automatiskt mellan tillgänglighetszoner utom Azure Firewall, om regionen stöder tillgänglighetszoner. Om du vill uppgradera en befintlig Azure Virtual WAN Hub till en säker hubb och låta Azure Firewall använda tillgänglighetszoner måste du använda Azure PowerShell, enligt beskrivningen senare i den här artikeln.
Förutsättningar
Om du inte har någon Azure-prenumeration skapar du ett kostnadsfritt konto innan du börjar.
PowerShell 7
Den här självstudien kräver att du kör Azure PowerShell lokalt på PowerShell 7. Information om hur du installerar PowerShell 7 finns i Migrera från Windows PowerShell 5.1 till PowerShell 7.
Modulversionen "Az.Network" måste vara 4.17.0 eller senare.
Logga in på Azure
Connect-AzAccount
Select-AzSubscription -Subscription "<sub name>"
Inledande Virtual WAN-distribution
Som ett första steg måste du ange några variabler och skapa resursgruppen, den virtuella WAN-instansen och den virtuella hubben:
# 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"
Skapa två virtuella nätverk och anslut dem till hubben som ekrar:
# 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
Nu har du ett fullt fungerande Virtuellt WAN som tillhandahåller alla-till-alla-anslutningar. För att förbättra säkerheten måste du distribuera en Azure-brandvägg till varje virtuell hubb. Brandväggsprinciper kan användas för att effektivt hantera den virtuella WAN Azure Firewall-instansen. Därför skapas även en brandväggsprincip i det här exemplet:
# 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
Kommentar
Följande kommando för att skapa brandväggen använder inte tillgänglighetszoner. Om du vill använda den här funktionen krävs ytterligare en parameter -Zone . Ett exempel finns i uppgraderingsavsnittet i slutet av den här artikeln.
Det är valfritt att aktivera loggning från Azure Firewall till Azure Monitor, men i det här exemplet använder du brandväggsloggarna för att bevisa att trafiken passerar brandväggen:
# 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
Distribuera Azure Firewall och konfigurera anpassad routning
Kommentar
Det här är konfigurationen som distribueras när du skyddar anslutningen från Azure-portalen med Azure Firewall Manager när inställningen "Inter-hub" är inställd på inaktiverad. Anvisningar om hur du konfigurerar routning med powershell när "Inter-hub" är inställt på aktiverat finns i Aktivera routnings avsikt.
Nu har du en Azure Firewall i hubben, men du måste fortfarande ändra routningen så att Virtual WAN skickar trafiken från de virtuella nätverken och från grenarna via brandväggen. Du gör detta i två steg:
- Konfigurera alla virtuella nätverksanslutningar (och grenanslutningar om det fanns några) för spridning till routningstabellen
None. Effekten av den här konfigurationen är att andra virtuella nätverk och grenar inte lär sig sina prefix och därför inte har någon routning för att nå dem. - Nu kan du infoga statiska vägar i routningstabellen
Default(där alla virtuella nätverk och grenar är associerade som standard), så att all trafik skickas till Azure Firewall.
Börja med det första steget för att konfigurera dina virtuella nätverksanslutningar så att de sprids till routningstabellen 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
Nu kan du fortsätta med det andra steget för att lägga till de statiska vägarna i routningstabellen Default . I det här exemplet tillämpar du den standardkonfiguration som Azure Firewall Manager skulle generera när du skyddar anslutningen i ett virtuellt WAN, men du kan ändra listan med prefix i den statiska vägen så att den passar dina specifika krav:
# 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)
Kommentar
Strängen "all_traffic" som värde för parametern "-Name" i kommandot New-AzVHubRoute ovan har en särskild betydelse: om du använder den här strängen återspeglas konfigurationen som används i den här artikeln korrekt i Azure-portalen (Firewall Manager -> Virtual Hubs --> [Din hubb] --> Säkerhetskonfiguration). Om ett annat namn används tillämpas den önskade konfigurationen, men återspeglas inte i Azure-portalen.
Aktivera routnings avsikt
Om du vill skicka trafik mellan hubbar och mellan regioner via Azure Firewall som distribueras i Virtual WAN-hubben kan du i stället aktivera funktionen för routnings avsikt. Mer information om routningssyfte finns i dokumentationen om routningssyfte.
Kommentar
Det här är konfigurationen som distribueras när du skyddar anslutningen från Azure-portalen med Azure Firewall Manager när inställningen "Interhub" är inställd på aktiverad.
# 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)
Om du använder prefix som inte är RFC1918 i ditt virtuella WAN, till exempel 40.0.0.0/24 i ditt virtuella nätverk eller lokalt, lägger du till ytterligare en väg i defaultRouteTable när konfigurationen av routnings avsikten har slutförts. Se till att du namnger den här vägen som private_traffic. Om vägen heter något annat gäller den önskade konfigurationen, men den återspeglas inte i Azure-portalen.
# 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
Testa anslutning
Nu har du en fullständigt fungerande säker hubb. För att testa anslutningen behöver du en virtuell dator i varje virtuellt ekernätverk som är anslutet till hubben:
# 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")
Standardkonfigurationen i brandväggsprincipen är att släppa allt. Därför måste du konfigurera vissa regler. Börja med DNAT-regler så att de virtuella testdatorerna är tillgängliga via brandväggens offentliga IP-adress:
# 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
Nu kan du konfigurera några exempelregler. Definiera en nätverksregel som tillåter SSH-trafik, plus en programregel som tillåter Internetåtkomst till det fullständigt kvalificerade domännamnet ifconfig.co. Den här URL:en returnerar den käll-IP-adress som visas i HTTP-begäran:
# 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
Innan du skickar någon trafik kan du inspektera de faktiska vägarna för de virtuella datorerna. De bör innehålla prefix som lärts från Virtual WAN (0.0.0.0/0 plus RFC1918), men inte prefixet för den andra ekern:
# 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
Generera nu trafik från en virtuell dator till en annan och kontrollera att den har släppts i Azure Firewall. I följande SSH-kommandon måste du acceptera fingeravtrycken för de virtuella datorerna och ange det lösenord som du definierade när du skapade de virtuella datorerna. I det här exemplet ska du skicka fem ICMP-ekobegärandepaket från den virtuella datorn i spoke1 till spoke2, plus ett TCP-anslutningsförsök på port 22 med Linux-verktyget nc (med flaggorna -vz skickar den bara en anslutningsbegäran och visar resultatet). Du bör se att pingen misslyckas och TCP-anslutningsförsöket på port 22 lyckas, eftersom det tillåts av nätverksregeln som du konfigurerade tidigare:
# 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"
Du kan också verifiera Internettrafik. HTTP-begäranden via verktyget curl till det FQDN som du tillät i brandväggsprincipen (ifconfig.co) bör fungera, men HTTP-begäranden till andra mål bör misslyckas (i det här exemplet testar du med 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"
Det enklaste sättet att kontrollera att paketen tas bort av brandväggen är att kontrollera loggarna. Eftersom du har konfigurerat Azure Firewall för att skicka loggar till Azure Monitor kan du använda Kusto Query Language för att hämta relevanta loggar från Azure Monitor:
Kommentar
Det kan ta cirka 1 minut innan loggarna visas som skickade till Azure Monitor
# 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
I föregående kommando bör du se olika poster:
- Din SSH-anslutning är DNAT'ed
- Borttagna ICMP-paket mellan de virtuella datorerna i ekrarna (10.1.1.4 och 10.1.2.4)
- Tillåtna SSH-anslutningar mellan de virtuella datorerna i ekrarna
Här visas ett exempel på utdata som genereras av kommandot ovan:
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
Om du vill se loggarna för programreglerna (som beskriver tillåtna och nekade HTTP-anslutningar) eller ändrar hur loggarna visas kan du prova med andra KQL-frågor. Du hittar några exempel i Azure Monitor-loggar för Azure Firewall.
Rensa resurser
Om du vill ta bort testmiljön kan du ta bort resursgruppen med alla inneslutna objekt:
# Delete resource group and all contained resources
Remove-AzResourceGroup -Name $RG
Distribuera en ny Azure Firewall med tillgänglighetszoner till en befintlig hubb
I föregående procedur används Azure PowerShell för att skapa en ny Azure Virtual WAN Hub och konverterar den sedan omedelbart till en skyddad hubb med hjälp av Azure Firewall. En liknande metod kan tillämpas på en befintlig Azure Virtual WAN Hub. Firewall Manager kan också användas för konverteringen, men det går inte att distribuera Azure Firewall mellan tillgänglighetszoner utan en skriptbaserad metod. Du kan använda följande kodfragment för att konvertera en befintlig Azure Virtual WAN Hub till en säker hubb med hjälp av en Azure Firewall som distribuerats i alla tre tillgänglighetszonerna.
Kommentar
Den här proceduren distribuerar en ny Azure Firewall. Du kan inte uppgradera en befintlig Azure Firewall utan tillgänglighetszoner till en med tillgänglighetszoner. Du måste först ta bort den befintliga Azure Firewall i hubben och skapa den igen med den här proceduren.
# 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
När du har kört det här skriptet bör tillgänglighetszonerna visas i egenskaperna för den skyddade hubben enligt följande skärmbild:
När Azure Firewall har distribuerats måste en konfigurationsprocedur slutföras enligt beskrivningen i föregående avsnitt distribuera Azure Firewall och konfigurera anpassad routning .
Nästa steg
Feedback
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i: https://aka.ms/ContentUserFeedback.
Skicka och visa feedback för