Samouczek: zabezpieczanie koncentratora wirtualnego przy użyciu programu Azure PowerShell

W tym samouczku utworzysz wystąpienie usługi Virtual WAN z koncentratorem wirtualnym w jednym regionie i wdrożysz usługę Azure Firewall w koncentratorze wirtualnym w celu zabezpieczenia łączności. W tym przykładzie pokazano bezpieczną łączność między sieciami wirtualnymi. Ruch między sieciami wirtualnymi a oddziałami typu lokacja-lokacja, punkt-lokacja lub expressRoute są obsługiwane również przez wirtualne centrum zabezpieczeń.

Z tego samouczka dowiesz się, jak wykonywać następujące czynności:

Prerequisites

• Jeśli nie masz subskrypcji Azure, przed rozpoczęciem utwórz darmowe konto.

• Program PowerShell 7 lub nowszy

  Ten samouczek wymaga lokalnego uruchomienia programu Azure PowerShell w programie PowerShell 7 lub nowszym. Aby zainstalować program PowerShell 7, zobacz Migrowanie z programu Windows PowerShell 5.1 do programu PowerShell 7.

• Wersja modułu "Az.Network" musi być 4.17.0 lub nowsza.

Logowanie się do platformy Azure

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

Początkowe wdrożenie usługi Virtual WAN

Aby rozpocząć, należy ustawić zmienne i utworzyć grupę zasobów, instancję wirtualnej sieci WAN i koncentrator wirtualny.

# 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"

• Utwórz dwie sieci wirtualne i połącz je z koncentratorem jako szprychy przy użyciu polecenia cmdlet New-AzVirtualHubVnetConnection. Sieci wirtualne są tworzone przy użyciu prefiksów adresów 10.1.1.0/24 i 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

Na tym etapie usługa Virtual WAN jest w pełni operacyjna i zapewnia uniwersalną łączność. Aby zabezpieczyć to środowisko, wdróż usługę Azure Firewall w każdym koncentratoście wirtualnym. Można centralnie zarządzać tymi zaporami sieciowymi za pomocą zasad zapory sieciowej.

W tym przykładzie utworzysz także politykę zapory, aby zarządzać instancją usługi Azure Firewall w koncentratorze usługi Virtual WAN za pomocą cmdlet New-AzFirewallPolicy. Azure Firewall zostanie wdrożony w centrum przy użyciu polecenia New-AzFirewall cmdlet.

# 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

Włączanie rejestrowania z usługi Azure Firewall do usługi Azure Monitor jest opcjonalne. W tym przykładzie użyjesz logów zapory sieciowej, aby zweryfikować, czy ruch przechodzi przez zaporę. Najpierw utwórz obszar roboczy usługi Log Analytics w celu przechowywania dzienników. Następnie użyj polecenia Set-AzDiagnosticSetting cmdlet, aby skonfigurować ustawienia diagnostyczne i wysłać dzienniki do obszaru roboczego.

# 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

Wdrażanie usługi Azure Firewall i konfigurowanie routingu niestandardowego

Teraz masz usługę Azure Firewall w centrum, ale nadal musisz zmodyfikować routing, aby usługa Virtual WAN wysyłała ruch z sieci wirtualnych i z gałęzi przez zaporę. Można to zrobić w dwóch krokach:

1. Skonfiguruj wszystkie połączenia sieci wirtualnej (i połączenia gałęzi, jeśli istnieją) do propagacji do None tabeli tras. Efektem tej konfiguracji jest to, że inne sieci wirtualne i gałęzie nie będą uczyć się ich prefiksów, a więc nie ma routingu, aby uzyskać do nich dostęp.
2. Teraz możesz wstawić trasy statyczne w Default tabeli tras (gdzie domyślnie są skojarzone wszystkie sieci wirtualne i gałęzie), aby cały ruch był wysyłany do usługi Azure Firewall.

Rozpocznij od skonfigurowania połączeń sieci wirtualnej, aby były przekazywane do tabeli tras None. Ten krok gwarantuje, że sieci wirtualne nie uczą się prefiksów adresów, uniemożliwiając bezpośrednią komunikację między nimi. W związku z tym cały ruch między sieciami wirtualnymi musi przechodzić przez usługę Azure Firewall.

W tym celu użyj cmdlet Get-AzVhubRouteTable, aby pobrać None Tabelę tras, a następnie zaktualizować konfigurację routingu połączeń sieci wirtualnej za pomocą cmdlet Update-AzVirtualHubVnetConnection.

# 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

Następnie przejdź do drugiego kroku: dodawanie tras statycznych do Default tabeli tras. W poniższym przykładzie użyto domyślnej konfiguracji stosowanej przez usługę Azure Firewall Manager podczas zabezpieczania łączności w usłudze Virtual WAN. Listę prefiksów można dostosować w statycznej trasie według potrzeb, używając polecenia cmdlet New-AzVHubRoute. W tym przykładzie cały ruch jest kierowany przez usługę Azure Firewall, która jest zalecaną wartością domyślną.

# 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)

Włączanie intencji routingu

Jeśli chcesz wysyłać ruch między koncentratorami i między regionami za pośrednictwem usługi Azure Firewall wdrożonego w koncentratorze usługi Virtual WAN, możesz zamiast tego włączyć funkcję intencji routingu. Aby uzyskać więcej informacji na temat intencji routingu, zobacz Dokumentację intencji routingu.

# 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

Testowanie łączności

Teraz, gdy bezpieczne centrum jest w pełni funkcjonalne, możesz przetestować łączność, wdrażając maszynę wirtualną w każdej sieci wirtualnej będącej szprychą połączoną z koncentratorem:

# 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")

Domyślnie zasady zapory blokują cały ruch. Aby zezwolić na dostęp do testowych maszyn wirtualnych, należy skonfigurować reguły tłumaczenia adresów sieciowych docelowych (DNAT). Te reguły umożliwiają łączenie się z maszynami wirtualnymi za pośrednictwem publicznego adresu IP usługi Azure 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

Następnie skonfiguruj przykładowe reguły dla polityki zapory. Najpierw utwórz regułę sieci, aby zezwolić na ruch SSH między sieciami wirtualnymi. Następnie dodaj regułę aplikacji, aby zezwolić na dostęp do Internetu tylko do w pełni kwalifikowanej nazwy domeny (FQDN), ifconfig.coktóra zwraca źródłowy adres IP widoczny w żądaniu 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

Przed wysłaniem jakiegokolwiek ruchu sprawdź obowiązujące trasy dla każdej maszyny wirtualnej. Tablice routingu powinny zawierać prefiksy uzyskane z sieci wirtualnej WAN (0.0.0.0/0 i zakresy RFC1918), ale nie powinny zawierać prefiksu adresu innej odsłoniętej sieci wirtualnej.

# 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

Wygeneruj ruch z jednej maszyny wirtualnej do drugiej i sprawdź, czy jest on filtrowany przez usługę Azure Firewall. Użyj protokołu SSH, aby nawiązać połączenie z maszynami wirtualnymi — zaakceptuj odcisk palca SSH i wprowadź hasło ustawione podczas tworzenia maszyny wirtualnej. W tym przykładzie wykonasz następujące elementy:

• Wyślij pięć żądań echo ICMP (ping) z maszyny wirtualnej w spoke1 do maszyny wirtualnej w spoke2.
• Spróbuj nawiązać połączenie TCP na porcie 22 przy użyciu nc narzędzia (netcat) z -vz flagami, które sprawdzają łączność bez wysyłania danych.

Należy zauważyć, że żądania ping kończą się niepowodzeniem (zablokowane przez zaporę), podczas gdy połączenie TCP na porcie 22 zakończy się pomyślnie, zgodnie z zasadami wcześniej skonfigurowanej reguły sieciowej.

# 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"

Możesz również przetestować dostęp do Internetu za pośrednictwem zapory. Żądania HTTP przy użyciu narzędzia curl do wysyłania żądań do dozwolonego FQDN (ifconfig.co) powinny zakończyć się powodzeniem, podczas gdy żądania do innych miejsc docelowych (takich jak bing.com) powinny być blokowane przez politykę zapory.

# 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"

Aby potwierdzić, że firewall upuszcza pakiety zgodnie z oczekiwaniami, przejrzyj dzienniki wysyłane do usługi Azure Monitor. Ponieważ usługa Azure Firewall jest skonfigurowana do wysyłania dzienników diagnostycznych do usługi Azure Monitor, możesz użyć języka Zapytań Kusto (KQL) do wykonywania zapytań i analizowania odpowiednich wpisów dziennika:

# 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

W poprzednim poleceniu powinny być widoczne różne wpisy:

• Połączenie SSH jest dnat'ed
• Porzucone pakiety ICMP między maszynami wirtualnymi w szprychach (10.1.1.4 i 10.1.2.4)
• Dozwolone połączenia SSH między maszynami wirtualnymi w szprychach

Oto przykładowe dane wyjściowe wygenerowane przez powyższe polecenie:

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

Jeśli chcesz wyświetlić dzienniki reguł aplikacji (opisujących dozwolone i niedozwolone połączenia HTTP) lub zmienić sposób wyświetlania dzienników, możesz spróbować użyć innych zapytań KQL. Kilka przykładów można znaleźć w dziennikach usługi Azure Monitor dla usługi Azure Firewall.

Aby wyczyścić środowisko testowe, usuń grupę zasobów i wszystkie skojarzone zasoby przy użyciu Remove-AzResourceGroup polecenia cmdlet . Spowoduje to usunięcie usługi Virtual WAN, koncentratora wirtualnego, usługi Azure Firewall i wszystkich innych zasobów utworzonych podczas tego samouczka.

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

Wdrażanie nowej usługi Azure Firewall ze strefami dostępności w istniejącym centrum

W poprzednich krokach pokazano, jak za pomocą programu Azure PowerShell utworzyć nowe centrum usługi Azure Virtual WAN Hub i zabezpieczyć je za pomocą usługi Azure Firewall. Możesz również zabezpieczyć istniejącą usługę Azure Virtual WAN Hub przy użyciu podobnego podejścia opartego na skryptach. Menedżer zapory może przekształcić hub w "Secured Hub", ale nie obsługuje wdrażania "Azure Firewall" w różnych strefach dostępności przez portal. Aby wdrożyć usługę Azure Firewall we wszystkich trzech strefach dostępności, użyj następującego skryptu programu PowerShell, aby przekonwertować istniejące centrum usługi Virtual WAN na zabezpieczone centrum.

# 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

Po uruchomieniu tego skryptu strefy dostępności powinny być wyświetlane we właściwościach bezpiecznego centrum, jak pokazano na poniższym zrzucie ekranu:

Po wdrożeniu usługi Azure Firewall należy wykonać kroki konfiguracji opisane we wcześniejszej sekcji Wdrażanie usługi Azure Firewall i skonfigurować routing niestandardowy w celu zapewnienia prawidłowego routingu i zabezpieczeń.

Dalsze kroki