Udostępnij za pośrednictwem

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

  • Artykuł

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:

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

Ważne

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

Wymagania wstępne

Logowanie się do platformy Azure

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

Początkowe wdrożenie usługi 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ą usługę Virtual WAN zapewniającą łączność typu dowolny-dowolny. Aby zwiększyć jej bezpieczeństwo, należy wdrożyć usługę Azure Firewall w każdym koncentratoście wirtualnym. Zasady zapory mogą służyć do wydajnego zarządzania wirtualnym wystąpieniem usługi Azure Firewall sieci WAN. Dlatego zasady zapory są również tworzone 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 stref 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 usługi Azure Firewall do usługi Azure Monitor jest opcjonalne, ale w tym przykładzie dzienniki zapory służą do udowodnienia, że ruch przechodzi przez zaporę:

# 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

Uwaga

Jest to konfiguracja wdrożona podczas zabezpieczania łączności z witryny Azure Portal za pomocą usługi 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 włączona, zobacz Włączanie intencji routingu.

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.

Zacznij od pierwszego kroku, aby skonfigurować połączenia sieci wirtualnej do propagowania 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órą usługa Azure Firewall Manager wygeneruje podczas zabezpieczania łączności w usłudze Virtual WAN, ale możesz zmienić listę prefiksów w trasie statycznej, aby dopasować je 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 (Menedżer zapory --> Koncentratory wirtualne -- [Twoje centrum] -->> Konfiguracja zabezpieczeń). Jeśli zostanie użyta inna nazwa, zostanie zastosowana żądana konfiguracja, ale nie zostanie odzwierciedlona w witrynie Azure Portal.

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.

Uwaga

Jest to konfiguracja wdrożona podczas zabezpieczania łączności z witryny Azure Portal za pomocą usługi 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 usłudze Virtual WAN, takich jak 40.0.0.0/24 w sieci wirtualnej lub lokalnej, 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, żądana 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 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ślną konfiguracją zasad 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 zawierać prefiksy poznane w usłudze 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 usłudze 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 żądania echa ICMP z maszyny wirtualnej w szprychach do szprychy 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 innego miejsca docelowego powinny zakończyć się niepowodzeniem (w tym przykładzie testujesz za pomocą bing.compolecenia ):

# 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 usługę 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

Wyświetlenie 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ą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.

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

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

Poprzednia procedura używa programu Azure PowerShell do utworzenia nowego centrum usługi Azure Virtual WAN Hub, a następnie natychmiast konwertuje ją na zabezpieczone centrum przy użyciu usługi 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ć usługi Azure Firewall w strefach dostępności bez podejścia opartego na skryptach. Poniższy fragment kodu umożliwia przekonwertowanie istniejącego koncentratora usługi Azure Virtual WAN na zabezpieczone centrum przy użyciu usługi Azure Firewall wdrożonej we wszystkich trzech strefach dostępności.

Uwaga

Ta procedura umożliwia wdrożenie nowej usługi Azure Firewall. Nie można uaktualnić istniejącej usługi Azure Firewall bez stref dostępności do jednej ze strefami dostępności. Musisz najpierw usunąć istniejącą usługę Azure Firewall w centrum i utworzyć ją ponownie przy użyciu tej procedury.

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

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

Po wdrożeniu usługi Azure Firewall należy wykonać procedurę konfiguracji zgodnie z opisem w poprzedniej sekcji Wdrażanie usługi Azure Firewall i konfigurowanie routingu niestandardowego .

Następne kroki

Dowiedz się więcej o zaufanych partnerach zabezpieczeń