Samouczek: zabezpieczanie koncentratora wirtualnego przy użyciu Azure PowerShell

  • Artykuł

W tym samouczku utworzysz wystąpienie Virtual WAN z koncentratorem wirtualnym w jednym regionie i wdrożysz Azure Firewall w koncentratonie wirtualnym w celu zabezpieczenia łączności. W tym przykładzie przedstawiono bezpieczną łączność między sieciami wirtualnymi. Ruch między sieciami wirtualnymi i oddziałami typu lokacja-lokacja, punkt-lokacja lub ExpressRoute jest obsługiwany również przez wirtualne centrum zabezpieczeń.

Ten samouczek zawiera informacje na temat wykonywania następujących czynności:

  • Wdrażanie wirtualnej sieci WAN
  • Wdrażanie Azure Firewall i konfigurowanie routingu niestandardowego
  • Testowanie łączności

Ważne

Virtual WAN to kolekcja centrów i usług udostępnianych w centrum. Możesz wdrożyć dowolną liczbę potrzebnych wirtualnych sieci WAN. W centrum Virtual WAN istnieje wiele usług, takich jak VPN, ExpressRoute itd. Każda z tych usług jest automatycznie wdrażana w Azure Firewall Strefy dostępnościexcept, jeśli region obsługuje Strefy dostępności. Aby uaktualnić istniejącą usługę Azure Virtual WAN Hub do bezpiecznego centrum i mieć Azure Firewall używać Strefy dostępności, należy użyć Azure PowerShell, zgodnie z opisem w dalszej części tego artykułu.

Wymagania wstępne

Logowanie do platformy Azure

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

Początkowe wdrożenie Virtual WAN

W pierwszym kroku należy ustawić pewne zmienne i utworzyć grupę zasobów, wystąpienie 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
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 piastą jako szprychami:

# 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

W tym momencie masz w pełni funkcjonalną Virtual WAN zapewniającą łączność typu dowolny-dowolny. Aby zwiększyć jej bezpieczeństwo, należy wdrożyć Azure Firewall w każdym koncentratoście wirtualnym. Zasady zapory mogą służyć do wydajnego zarządzania wystąpieniem wirtualnej sieci WAN Azure Firewall. Dlatego zasady zapory są tworzone również w tym przykładzie:

# 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

Uwaga

Następujące polecenie tworzenia zapory nie używa Strefy dostępności. Jeśli chcesz użyć tej funkcji, wymagany jest dodatkowy parametr -Zone . Przykład znajduje się w sekcji uaktualniania na końcu tego artykułu.

Włączenie rejestrowania z Azure Firewall do usługi Azure Monitor jest opcjonalne, ale w tym przykładzie użyjesz dzienników zapory, aby udowodnić, że ruch przechodzi przez zaporę:

# 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

Wdrażanie Azure Firewall i konfigurowanie routingu niestandardowego

Uwaga

Jest to konfiguracja wdrożona podczas zabezpieczania łączności z witryny Azure Portal przy użyciu programu Azure Firewall Manager, gdy ustawienie "Inter-hub" jest ustawione na wyłączone. Aby uzyskać instrukcje dotyczące konfigurowania routingu przy użyciu programu PowerShell, gdy opcja "Inter-hub" jest ustawiona na włączoną, zobacz Włączanie intencji routingu.

Teraz masz Azure Firewall w centrum, ale nadal musisz zmodyfikować routing, aby Virtual WAN wysył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 propagowania do tabeli routingu None . Efektem tej konfiguracji jest to, że inne sieci wirtualne i gałęzie nie będą uczyć się ich prefiksów, dlatego nie ma routingu do nich.
  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 Azure Firewall.

Zacznij od pierwszego kroku, aby skonfigurować połączenia sieci wirtualnej w celu propagowania ich do None tabeli tras:

# 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

Teraz możesz kontynuować drugi krok, aby dodać trasy statyczne do Default tabeli tras. W tym przykładzie zastosujesz konfigurację domyślną, która Azure Firewall Manager będzie generowana podczas zabezpieczania łączności w Virtual WAN, ale można zmienić listę prefiksów na trasie statycznej, aby dopasować się do określonych wymagań:

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

Uwaga

Ciąg "all_traffic" jako wartość parametru "-Name" w poleceniu New-AzVHubRoute powyżej ma specjalne znaczenie: jeśli używasz tego dokładnego ciągu, konfiguracja zastosowana w tym artykule zostanie prawidłowo odzwierciedlona w witrynie Azure Portal (Firewall Manager --> Koncentratory wirtualne --> [Twoje centrum] --> Konfiguracja zabezpieczeń). Jeśli zostanie użyta inna nazwa, wymagana konfiguracja zostanie zastosowana, ale nie zostanie odzwierciedlona w witrynie Azure Portal.

Włączanie intencji routingu

Jeśli chcesz wysyłać ruch między centrami i między regionami za pośrednictwem Azure Firewall wdrożonych w centrum Virtual WAN, możesz zamiast tego włączyć funkcję intencji routingu. Aby uzyskać więcej informacji na temat intencji routingu, zobacz dokumentację dotyczącą intencji routingu.

Uwaga

Jest to konfiguracja wdrożona podczas zabezpieczania łączności z witryny Azure Portal za pomocą programu Azure Firewall Manager, gdy ustawienie "Interhub" jest ustawione na włączone.

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

Jeśli używasz prefiksów innych niż RFC1918 w Virtual WAN, takich jak 40.0.0.0/24 w Virtual Network lub lokalnie, dodaj dodatkową trasę w domyślnej tabeliRouteTable po zakończeniu konfiguracji intencji routingu. Upewnij się, że nazwa tej trasy jest private_traffic. Jeśli trasa ma nazwę w przeciwnym razie, wymagana konfiguracja zostanie zastosowana, ale nie zostanie odzwierciedlona w witrynie Azure Portal.

# 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 masz w pełni funkcjonalne bezpieczne centrum. Aby przetestować łączność, musisz mieć jedną maszynę wirtualną w każdej sieci wirtualnej będącej szprychą połączoną z piastą:

# 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ślną konfiguracją w zasadach zapory jest usunięcie wszystkich elementów. Dlatego należy skonfigurować niektóre reguły. Zacznij od reguł DNAT, aby testowe maszyny wirtualne były dostępne za pośrednictwem publicznego adresu IP zapory:

# 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

Teraz możesz skonfigurować przykładowe reguły. Zdefiniuj regułę sieci, która zezwala na ruch SSH oraz regułę aplikacji, która zezwala na dostęp do Internetu do w pełni kwalifikowanej nazwy ifconfig.codomeny. Ten adres URL 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 dowolnego ruchu można sprawdzić obowiązujące trasy maszyn wirtualnych. Powinny one zawierać prefiksy poznane na podstawie Virtual WAN (0.0.0.0/0 plus RFC1918), ale nie prefiks innej szprychy:

# 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

Teraz wygeneruj ruch z jednej maszyny wirtualnej do drugiej i sprawdź, czy jest on porzucony w Azure Firewall. W poniższych poleceniach SSH należy zaakceptować odciski palców maszyn wirtualnych i podać hasło zdefiniowane podczas tworzenia maszyn wirtualnych. W tym przykładzie wyślesz pięć pakietów żądań echa ICMP z maszyny wirtualnej w szprychach 1 do szprychy, a także próbę połączenia TCP na porcie 22 przy użyciu narzędzia nc systemu Linux (z -vz flagami, które po prostu wysyła żądanie połączenia i pokazuje wynik). Powinno zostać wyświetlone polecenie ping zakończone niepowodzeniem, a próba połączenia TCP na porcie 22 zakończy się pomyślnie, ponieważ jest ona dozwolona przez wcześniej skonfigurowaną regułę sieci:

# 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ż zweryfikować ruch internetowy. Żądania HTTP za pośrednictwem narzędzia curl do nazwy FQDN dozwolonej w zasadach zapory (ifconfig.co) powinny działać, ale żądania HTTP do innych miejsc docelowych powinny zakończyć się niepowodzeniem (w tym przykładzie testujesz przy bing.comużyciu polecenia ):

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

Najprostszym sposobem sprawdzenia, czy pakiety są porzucane przez zaporę, jest sprawdzenie dzienników. Ponieważ skonfigurowano Azure Firewall do wysyłania dzienników do usługi Azure Monitor, możesz użyć język zapytań Kusto do pobrania odpowiednich dzienników z usługi Azure Monitor:

Uwaga

Wysyłanie dzienników do usługi Azure Monitor może potrwać około 1 minuty

# 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ące dozwolone i niedozwolone połączenia HTTP) lub zmienić sposób wyświetlania dzienników, możesz spróbować użyć innych zapytań KQL. Niektóre przykłady można znaleźć w dziennikach usługi Azure Monitor dla Azure Firewall.

Czyszczenie zasobów

Aby usunąć środowisko testowe, możesz usunąć grupę zasobów ze wszystkimi zawartymi obiektami:

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

Uaktualnianie istniejącego centrum przy użyciu Strefy dostępności

Poprzednia procedura używa Azure PowerShell do utworzenia nowej usługi Azure Virtual WAN Hub, a następnie natychmiast konwertuje ją na zabezpieczone centrum przy użyciu Azure Firewall. Podobne podejście można zastosować do istniejącej usługi Azure Virtual WAN Hub. Menedżer zapory może być również używany do konwersji, ale nie można wdrożyć Azure Firewall w Strefy dostępności bez podejścia opartego na skryptach. Poniższy fragment kodu umożliwia przekonwertowanie istniejącego centrum usługi Azure Virtual WAN Hub na zabezpieczone centrum przy użyciu Azure Firewall wdrożonego we wszystkich trzech Strefy dostępności.

# 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 pojawić się we właściwościach bezpiecznego centrum, jak pokazano na poniższym zrzucie ekranu:

Zrzut ekranu przedstawiający zabezpieczone strefy dostępności koncentratora wirtualnego.

Po wdrożeniu Azure Firewall należy wykonać procedurę konfiguracji zgodnie z opisem w poprzedniej sekcji Wdrażanie Azure Firewall i skonfigurować routing niestandardowy.

Następne kroki

Dowiedz się więcej o zaufanych partnerach zabezpieczeń