Tutorial: Sichern Sie Ihren virtuellen Hub 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:
- Bereitstellen des virtuellen WANs
- Bereitstellen der Azure Firewall und Konfigurieren des benutzerdefinierten Routings
- Testen der Konnektivität
Wichtig
Virtual WAN ist eine Sammlung von Hubs und Diensten, die innerhalb des Hubs zur Verfügung gestellt werden. Sie können so viele virtuelle WANs bereitstellen, wie Sie benötigen. In einem Virtual WAN-Hub gibt es mehrere Dienste wie VPN, ExpressRoute usw. Wenn die Region Verfügbarkeitszonen unterstützt, wird jeder dieser Dienste (außer Azure Firewall) automatisch in allen Verfügbarkeitszonen bereitgestellt. Um einen vorhandenen Azure Virtual WAN Hub zu einem Secure Hub zu aktualisieren und damit die Azure Firewall Verfügbarkeitszonen verwendet, müssen Sie Azure PowerShell verwenden, wie später in diesem Artikel beschrieben.
Voraussetzungen
Wenn Sie kein Azure-Abonnement besitzen, können Sie ein kostenloses Konto erstellen, bevor Sie beginnen.
PowerShell 7
Für dieses Tutorial müssen Sie Azure PowerShell lokal unter PowerShell 7 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
In einem ersten Schritt müssen Sie einige 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
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 sie als Spokes mit dem Hub:
# 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
An diesem Punkt verfügen Sie über ein voll funktionsfähiges Virtual WAN mit Any-to-Any-Konnektivität. Um die Sicherheit zu erhöhen, müssen Sie jedem virtuellen Hub eine Azure Firewall zur Verfügung stellen. Zur effizienten Verwaltung der Azure Firewall-Instanz des virtuellen WANs können Richtlinien für die Firewall verwendet werden. Daher wird in diesem Beispiel auch eine Firewallrichtlinie erstellt:
# 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
Hinweis
Der folgende Befehl zur Erstellung einer Firewall verwendet keine Verfügbarkeitszonen. Wenn Sie dieses Feature verwenden möchten, ist ein zusätzlicher Parameter -Zone erforderlich. Ein Beispiel wird im Abschnitt zu Upgrades am Ende dieses Artikels gezeigt.
Das Aktivieren der Protokollierung von der Azure Firewall zu Azure Monitor ist optional, aber in diesem Beispiel verwenden Sie die Firewall-Protokolle, um nachzuweisen, dass Datenverkehr die Firewall durchquert:
# 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
Hinweis
Dies ist die Konfiguration, die bereitgestellt wird, wenn die Konnektivität vom Azure-Portal mit Azure Firewall Manager gesichert wird während die Einstellung „Inter-Hub“ deaktiviert ist. Anweisungen zum Konfigurieren des Routings mithilfe von PowerShell, wenn „Inter-Hub“ aktiviert ist, finden Sie unter Aktivieren der Routingabsicht.
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:
- Konfigurieren Sie alle virtuellen Netzwerkverbindungen (und Zweigstellenverbindungen, falls es welche gab) so, dass sie an die Routingtabelle
Noneweitergegeben 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. - Jetzt können Sie statische Routen in die Routingtabelle
Defaulteinfügen (in der alle virtuellen Netzwerke und Zweigstellen standardmäßig zugeordnet sind), damit der gesamte Datenverkehr an die Azure Firewall gesendet wird.
Beginnen Sie mit dem ersten Schritt, um Ihre virtuellen Netzwerkverbindungen so zu konfigurieren, dass sie an die Routingtabelle None weitergegeben werden:
# 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
Jetzt können Sie mit dem zweiten Schritt fortfahren, um die statischen Routen zur Routingtabelle Default hinzuzufügen. In diesem Beispiel wenden Sie die Standardkonfiguration an, die Azure Firewall Manager beim Sichern der Konnektivität in einem virtuellen WAN generieren würde, aber Sie können die Liste der Präfixe in der statischen Route ändern, um sie an Ihre spezifischen Anforderungen anzupassen:
# 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)
Hinweis
Die Zeichenfolge „all_traffic“ als Wert für den Parameter „-Name“ im obigen Befehl „New-AzVHubRoute“ hat eine besondere Bedeutung: Wenn Sie genau diese Zeichenfolge verwenden, wird die in diesem Artikel angewendete Konfiguration ordnungsgemäß im Azure-Portal widergespiegelt (Firewall Manager --> Virtuelle Hubs --> [Ihr Hub] --> Sicherheitskonfiguration). Wenn ein anderer Name verwendet wird, wird die gewünschte Konfiguration angewendet, aber nicht im Azure-Portal widergespiegelt.
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.
Hinweis
Dies ist die Konfiguration, die bereitgestellt wird, wenn die Konnektivität vom Azure-Portal mit Azure Firewall Manager gesichert wird während „Inter-Hub“ aktiviert ist.
# 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)
Wenn Sie in Ihrem virtuellen WAN nicht-RFC1918-Präfixe wie 40.0.0.0/24 in Ihrem virtuellen Netzwerk oder vor Ort verwenden, fügen Sie nach Abschluss der Konfiguration der Routingabsicht eine zusätzliche Route in der defaultRouteTable hinzu. Stellen Sie sicher, dass Sie diese Route als private_traffic benennen. Wenn die Route einen anderen Namen hat, gilt die gewünschte Konfiguration, aber sie wird nicht im Azure-Portal widerspiegelt.
# 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
Jetzt verfügen Sie über einen voll funktionsfähigen sicheren Hub. Um die Konnektivität zu testen, benötigen Sie einen virtuellen Computer in jedem virtuellen Spoke-Netzwerk, das mit dem Hub verbunden ist:
# 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")
Die Standardkonfiguration in der Firewallrichtlinie besteht darin, alles abzulegen. Daher müssen Sie einige Regeln konfigurieren. Beginnen Sie mit DNAT-Regeln, sodass die getesteten virtuellen Computer über die öffentliche IP-Adresse der Firewall zugänglich sind:
# 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
Jetzt können Sie einige Beispielregeln konfigurieren. Definieren Sie eine Netzwerkregel, die SSH-Datenverkehr gestattet, sowie eine Anwendungsregel, die den Internetzugriff auf den vollqualifizierten Domänennamen ifconfig.co erlaubt. Diese URL gibt die Quell-IP-Adresse zurück, die sie in der HTTP-Anforderung erkennt:
# 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
Bevor Sie tatsächlich Datenverkehr senden, können Sie die effektiven Routen der virtuellen Computer überprüfen. Sie sollten die Präfixe enthalten, die aus dem Virtual WAN (0.0.0.0/0 plus RFC1918) gelernt wurden, aber nicht das Präfix der anderen Spoke:
# 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 jetzt Datenverkehr von einem virtuellen Computer zum anderen und vergewissern Sie sich, dass er in der Azure Firewall abgelegt wurde. In den folgenden SSH-Befehlen müssen Sie die Fingerabdrücke der virtuellen Computer akzeptieren und das Kennwort angeben, das Sie bei der Erstellung der virtuellen Computer definiert haben. In diesem Beispiel werden Sie fünf ICMP-Echoanforderungspakete von dem virtuellen Computer in Spoke1 an Spoke2 senden, sowie einen TCP-Verbindungsversuch an Port 22 mithilfe des Linux-Hilfsprogramms nc durchführen (mit den -vz-Flags sendet es einfach eine Verbindungsanforderung und zeigt das Ergebnis an). Sie sollten erkennen, dass beim Ping ein Fehler auftritt und der TCP-Verbindungsversuch an Port 22 erfolgreich ist, da dies von der zuvor konfigurierten Netzwerkregel erlaubt wird:
# 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 auch den Internetdatenverkehr überprüfen. HTTP-Anforderungen über das Hilfsprogramm curl an den FQDN, den Sie in der Firewallrichtlinie (ifconfig.co) zugelassen haben, sollten funktionieren, bei HTTP-Anforderungen für jedes andere Ziel sollten jedoch Fehler auftreten (in diesem Beispiel testen Sie mit bing.com):
# This HTTP request should succeed, since it is allowed in an app rule in the AzFW, and return the public IP of the FW
ssh $AzFWPublicAddress -p 10001 -l $VMLocalAdminUser "curl -s4 ifconfig.co"
# This HTTP request should fail, since the FQDN bing.com is not in any app rule in the firewall policy
ssh $AzFWPublicAddress -p 10001 -l $VMLocalAdminUser "curl -s4 bing.com"
Der einfachste Weg zu überprüfen, ob die Pakete von der Firewall verworfen wurden, ist die Überprüfung der Protokolle. Da Sie die Azure Firewall so konfiguriert haben, dass sie Protokolle an Azure Monitor sendet, können Sie die Kusto-Abfragesprache verwenden, um die relevanten Protokolle von Azure Monitor abzurufen:
Hinweis
Es kann etwa 1 Minute dauern, bis die Protokolle an Azure Monitor gesendet werden.
# 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.
Bereinigen von Ressourcen
Zum Löschen der Testumgebung können Sie die Ressourcengruppe mit allen enthaltenen Objekten entfernen:
# Delete resource group and all contained resources
Remove-AzResourceGroup -Name $RG
Bereitstellen einer neuen Azure-Firewall mit Verfügbarkeitszonen auf einem vorhandenen Hub
Das vorherige Verfahren verwendet Azure PowerShell, um einen neuen Azure Virtual WAN Hub zu erstellen, und wandelt es dann sofort mithilfe von Azure Firewall in einen Secured Hub um. Ein ähnlicher Ansatz kann auf einen vorhandenen Azure Virtual WAN Hub angewendet werden. Der Firewall Manager kann ebenfalls für die Konvertierung verwendet werden, es ist jedoch nicht möglich, Azure Firewall über Verfügbarkeitszonen hinweg ohne einen skriptbasierten Ansatz bereitzustellen. Sie können den folgenden Codeschnipsel verwenden, um einen vorhandenen Azure Virtual WAN Hub in einen Secured Hub zu konvertieren, indem Sie eine Azure Firewall verwenden, die über alle drei Verfügbarkeitszonen hinweg bereitgestellt wurde.
Hinweis
Dieses Verfahren stellt eine neue Azure-Firewall bereit. Sie können keine vorhandene Azure-Firewall ohne Verfügbarkeitszonen auf eine mit Verfügbarkeitszonen aktualisieren. Sie müssen zuerst die vorhandene Azure-Firewall im Hub löschen und mit diesem Verfahren erneut erstellen.
# 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:
Nachdem die Azure Firewall bereitgestellt wurde, muss eine Konfigurationsprozedur abgeschlossen werden, wie im vorherigen Abschnitt Bereitstellen einer Azure Firewall und Konfigurieren eines benutzerdefinierten Routings beschrieben wird.