Tutorial: Sichern Ihres virtuellen Hubs mithilfe von Azure PowerShell

In diesem Tutorial erstellen Sie eine virtuelle WAN-Instanz mit einem virtuellen Hub in einer Region, und Sie stellen eine Azure Firewall im virtuellen Hub bereit, um die Konnektivität zu sichern. In diesem Beispiel veranschaulichen Sie die sichere Konnektivität zwischen virtuellen Netzwerken. Der Datenverkehr zwischen virtuellen Netzwerken und Site-to-Site-, Point-to-Site- oder ExpressRoute-Zweigstellen wird ebenfalls von Virtual Secure Hub unterstützt.

In diesem Tutorial lernen Sie Folgendes:

Prerequisites

• Wenn Sie noch kein Azure-Abonnement haben, erstellen Sie ein kostenloses Konto, bevor Sie beginnen.

• PowerShell 7 oder höher

  In diesem Lernprogramm müssen Sie Azure PowerShell lokal auf PowerShell 7 oder höher ausführen. Informationen zur Installation von PowerShell 7 finden Sie unter Migrieren von Windows PowerShell 5.1 zu PowerShell 7.

• Die Version des Moduls „Az.Network“ muss 4.17.0 oder höher sein.

Anmelden bei Azure

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

Anfängliche Virtual WAN-Bereitstellung

Zunächst müssen Sie Variablen festlegen und die Ressourcengruppe, die virtuelle WAN-Instanz und den virtuellen Hub erstellen:

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

• Erstellen Sie zwei virtuelle Netzwerke und verbinden Sie diese mit dem Hub als Speichen mithilfe des New-AzVirtualHubVnetConnection Cmdlets. Die virtuellen Netzwerke werden mit den Adresspräfixen 10.1.1.0/24 und 10.1.2.0/24 erzeugt.

# 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

In dieser Phase ist Ihr virtuelles WAN vollständig betriebsbereit und bietet beliebige-zu-beliebige Konnektivität. Um diese Umgebung zu schützen, stellen Sie eine Azure-Firewall in jedem virtuellen Hub bereit. Sie können diese Firewalls zentral mithilfe von Firewallrichtlinien verwalten.

In diesem Beispiel erstellen Sie auch eine Firewallrichtlinie zum Verwalten der Azure Firewall-Instanz im virtuellen WAN-Hub mithilfe des New-AzFirewallPolicy Cmdlets. Die Azure Firewall wird mithilfe des New-AzFirewall Cmdlets im Hub bereitgestellt.

# 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

Das Aktivieren der Protokollierung von Azure Firewall in Azure Monitor ist optional. In diesem Beispiel verwenden Sie Firewallprotokolle, um zu überprüfen, ob Datenverkehr die Firewall durchläuft. Erstellen Sie zunächst einen Log Analytics-Arbeitsbereich, um die Protokolle zu speichern. Verwenden Sie dann das Set-AzDiagnosticSetting Cmdlet, um Diagnoseeinstellungen zu konfigurieren und die Protokolle an den Arbeitsbereich zu senden.

# 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

Bereitstellen der Azure Firewall und Konfigurieren des benutzerdefinierten Routings

Jetzt verfügen Sie über eine Azure Firewall im Hub, aber Sie müssen noch das Routing ändern, sodass das virtuelle WAN den Datenverkehr aus den virtuellen Netzwerken und aus den Zweigstellen durch die Firewall leitet. Dies erfolgt in zwei Schritten:

1. Konfigurieren Sie alle virtuellen Netzwerkverbindungen (und Zweigstellenverbindungen, falls es welche gab) so, dass sie an die Routingtabelle None weitergegeben werden. Der Effekt dieser Konfiguration ist, dass andere virtuelle Netzwerke und Zweigstellen ihre Präfixe nicht kennen lernen und somit kein Routing aufweisen, um sie zu erreichen.
2. Jetzt können Sie statische Routen in die Routingtabelle Default einfügen (in der alle virtuellen Netzwerke und Zweigstellen standardmäßig zugeordnet sind), damit der gesamte Datenverkehr an die Azure Firewall gesendet wird.

Beginnen Sie, indem Sie Ihre virtuellen Netzwerkverbindungen so konfigurieren, dass sie an die None Route-Tabelle weitergegeben werden. Dieser Schritt stellt sicher, dass die virtuellen Netzwerke nicht die Adresspräfixe der anderen lernen und die direkte Kommunikation zwischen ihnen verhindern. Daher muss der gesamte inter-virtuelle Netzwerkverkehr über die Azure-Firewall geleitet werden.

Verwenden Sie dazu das Get-AzVhubRouteTable Cmdlet, um die None Route-Tabelle abzurufen, und aktualisieren Sie dann die Routingkonfiguration jeder virtuellen Netzwerkverbindung mit dem Update-AzVirtualHubVnetConnection Cmdlet.

# 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

Fahren Sie als Nächstes mit dem zweiten Schritt fort: Hinzufügen statischer Routen zur Default Routentabelle. Im folgenden Beispiel wird die Standardkonfiguration verwendet, die Azure Firewall Manager beim Sichern der Konnektivität in einem virtuellen WAN anwendet. Sie können die Liste der Präfixe in der statischen Route nach Bedarf mithilfe des New-AzVHubRoute Cmdlets anpassen. In diesem Beispiel wird der gesamte Datenverkehr über die Azure-Firewall geleitet, was die empfohlene Standardeinstellung ist.

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

Aktivieren der Routingabsicht

Wenn Sie Hub- und regionsübergreifenden Datenverkehr über Azure Firewall senden möchten, die im Virtual WAN Hub bereitgestellt werden, können Sie stattdessen die Routingabsicht aktivieren. Weitere Informationen zur Routingabsicht finden Sie in der Dokumentation zur Routingabsicht.

# 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

Testen der Konnektivität

Nachdem Ihr sicherer Hub nun vollständig betriebsbereit ist, können Sie die Konnektivität testen, indem Sie einen virtuellen Computer in jedem mit dem Hub verbundenen virtuellen Speichennetzwerk bereitstellen:

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

Standardmäßig blockiert die Firewallrichtlinie den gesamten Datenverkehr. Um den Zugriff auf Ihre virtuellen Testcomputer zu ermöglichen, müssen Sie DNAT-Regeln (Destination Network Address Translation) konfigurieren. Mit diesen Regeln können Sie über die öffentliche IP-Adresse der Azure-Firewall eine Verbindung mit den virtuellen Computern herstellen:

# 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

Konfigurieren Sie als Nächstes Beispielregeln für Ihre Firewallrichtlinie. Erstellen Sie zunächst eine Netzwerkregel, um SSH-Datenverkehr zwischen den virtuellen Netzwerken zuzulassen. Fügen Sie dann eine Anwendungsregel hinzu, um den Internetzugriff nur auf den vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) ifconfig.cozuzulassen, der die in der HTTP-Anforderung angezeigte Quell-IP-Adresse zurückgibt:

# 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

Überprüfen Sie vor dem Senden von Datenverkehr die effektiven Routen für jeden virtuellen Computer. Die Routentabellen sollten die Präfixe anzeigen, die aus dem Virtual WAN stammen (0.0.0.0/0 und RFC1918-Bereiche), aber nicht das Adresspräfix des anderen virtuellen Spoke-Netzwerks enthalten.

# 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

Generieren Sie Datenverkehr von einem virtuellen Computer zum anderen, und stellen Sie sicher, dass er von der Azure Firewall gefiltert wird. Verwenden Sie SSH, um eine Verbindung mit den virtuellen Computern herzustellen– akzeptieren Sie den SSH-Fingerabdruck, und geben Sie das Kennwort ein, das Sie während der VM-Erstellung festgelegt haben. In diesem Beispiel führen Sie folgende Schritte aus:

• Senden Sie fünf ICMP-Echoanforderungen (Pings) von der VM in Spoke1 an die VM in Spoke2.
• Versuchen Sie, eine TCP-Verbindung auf Port 22 mit dem nc Hilfsprogramm (netcat) mit den -vz Flags zu verwenden, wodurch die Konnektivität überprüft wird, ohne Daten zu senden.

Beachten Sie, dass die Pinganforderungen fehlschlagen (blockiert durch die Firewall), während die TCP-Verbindung an Port 22 erfolgreich ist, wie dies durch die zuvor konfigurierte Netzwerkregel zulässig ist.

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

Sie können den Internetzugriff auch über die Firewall testen. HTTP-Anforderungen mit dem curl-Hilfsprogramm an den zulässigen FQDN (ifconfig.co) sollten erfolgreich sein, während Anforderungen an andere Ziele (z. B. bing.com) durch die Firewallrichtlinie blockiert werden sollten:

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

Um zu bestätigen, dass die Firewall Pakete erwartungsgemäß abbricht, überprüfen Sie die protokolle, die an Azure Monitor gesendet wurden. Da Azure Firewall so konfiguriert ist, dass Diagnoseprotokolle an Azure Monitor gesendet werden, können Sie kusto Query Language (KQL) verwenden, um die relevanten Protokolleinträge abzufragen und zu analysieren:

# 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

Im vorherigen Befehl sollten Sie andere Einträge sehen:

• Ihre SSH-Verbindung mit DNAT
• Verworfene ICMP-Pakete zwischen den VMs in den Spokes (10.1.1.4 und 10.1.2.4)
• Zulässige SSH-Verbindungen zwischen den VMs in den Spokes

Hier sehen Sie eine Beispielausgabe, die vom obigen Befehl generiert wird:

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

Wenn Sie die Protokolle für die Anwendungsregeln sehen (die die zulässigen und verweigerten HTTP-Verbindungen beschreiben) oder die Art und Weise ändern möchten, wie die Protokolle angezeigt werden, können Sie es mit anderen KQL-Abfragen versuchen. Einige Beispiele finden Sie unter Azure Monitor-Protokolle für Azure Firewall.

Um die Testumgebung zu bereinigen, löschen Sie die Ressourcengruppe und alle zugehörigen Ressourcen mithilfe des Remove-AzResourceGroup Cmdlets. Dadurch werden das virtuelle WAN, der virtuelle Hub, die Azure-Firewall und alle anderen Ressourcen entfernt, die während dieses Lernprogramms erstellt wurden.

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

Bereitstellen einer neuen Azure-Firewall mit Verfügbarkeitszonen auf einem vorhandenen Hub

In den vorherigen Schritten wurde gezeigt, wie Sie Azure PowerShell verwenden, um einen neuen virtuellen Azure WAN Hub zu erstellen und mit Azure Firewall zu schützen. Sie können auch einen vorhandenen virtuellen Azure-WAN-Hub mit einem ähnlichen skriptbasierten Ansatz sichern. Der Firewall-Manager kann zwar einen Hub in einen gesicherten Hub konvertieren, aber die Bereitstellung von Azure Firewall über die Verfügbarkeitszonen über das Portal wird nicht unterstützt. Um Azure Firewall in allen drei Verfügbarkeitszonen bereitzustellen, verwenden Sie das folgende PowerShell-Skript, um Ihren vorhandenen virtuellen WAN-Hub in einen gesicherten Hub zu konvertieren.

# 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

Nachdem Sie dieses Skript ausgeführt haben, sollten Verfügbarkeitszonen in den Eigenschaften des gesicherten Hubs erscheinen, wie im folgenden Screenshot gezeigt:

Nach der Bereitstellung von Azure Firewall müssen Sie die konfigurationsschritte ausführen, die im vorherigen Abschnitt "Bereitstellen von Azure Firewall" beschrieben sind, und den Abschnitt "Benutzerdefiniertes Routing konfigurieren ", um ein ordnungsgemäßes Routing und die richtige Sicherheit sicherzustellen.

Nächste Schritte