Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В рамках работы с этим учебником вы создадите экземпляр Виртуальной глобальной сети с виртуальным концентратором в одном регионе, а также развернете Брандмауэр Azure в концентраторе для безопасного подключения. В этом примере показано, как можно настроить безопасное подключение между виртуальными сетями. Защищенный виртуальный концентратор также поддерживает трафик между виртуальными сетями и соединениями типа "сеть-сеть", "точка-сеть" и ExpressRoute.
В этом руководстве описано следующее:
- развертывать виртуальную глобальную сеть;
- развертывать Брандмауэр Azure и настраивать пользовательскую маршрутизацию.
- Проверка подключения
Important
Виртуальная глобальная сеть представляет собой набор концентраторов и служб, доступных внутри концентратора. Вы можете развернуть столько Виртуальных глобальных сетей, сколько вам нужно. В концентраторе Виртуальной глобальной сети доступно несколько служб, таких как VPN, ExpressRoute и т. д. Каждая из этих служб автоматически развертывается в зонах доступности, кроме брандмауэра Azure, если регион поддерживает зоны доступности. Чтобы обновить существующий концентратор Azure Виртуальной глобальной сети до Безопасного концентратора и использовать Брандмауэр Azure с зонами доступности, необходимо использовать Azure PowerShell, как описано далее в этой статье.
Prerequisites
Если у вас нет подписки на Azure, создайте бесплатную учетную запись перед началом.
PowerShell 7 или более поздней версии
В этом руководстве требуется локально запустить Azure PowerShell в PowerShell 7 или более поздней версии. Дополнительные сведения об установке PowerShell 7 см. в статье Миграция с Windows PowerShell 5.1 на PowerShell 7.
Модуль Az.Network должен иметь версию 4.17.0 или выше.
Вход в Azure
Connect-AzAccount
Select-AzSubscription -Subscription "<sub name>"
Начальное развертывание виртуальной глобальной сети
Чтобы начать, необходимо задать переменные и создать группу ресурсов, экземпляр виртуальной глобальной сети и виртуальный концентратор:
# 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"
- Создайте две виртуальные сети и подключите их к концентратору как периферийные устройства с помощью командлета
New-AzVirtualHubVnetConnection. Виртуальные сети создаются с префиксами10.1.1.0/24адресов и10.1.2.0/24.
# Create Virtual Network
$Spoke1 = New-AzVirtualNetwork -Name "spoke1" -ResourceGroupName $RG -Location $Location -AddressPrefix "10.1.1.0/24"
Add-AzVirtualNetworkSubnetConfig -Name "AzureBastionSubnet" -VirtualNetwork $Spoke1 -AddressPrefix "10.1.1.64/26"
$Spoke1 | Set-AzVirtualNetwork
$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
На этом этапе виртуальная глобальная сеть полностью работает и обеспечивает любое подключение. Чтобы защитить эту среду, разверните брандмауэр Azure в каждом виртуальном концентраторе. Эти брандмауэры можно централизованно управлять с помощью политик брандмауэра.
В этом примере вы также создадите политику брандмауэра для управления экземпляром брандмауэра Azure в концентраторе виртуальной глобальной сети с помощью командлета New-AzFirewallPolicy . Брандмауэр Azure будет развернут в центре с помощью командлета New-AzFirewall .
# 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
Note
Следующая команда создания брандмауэра не использует зоны доступности. Если вы хотите использовать эту функцию, требуется дополнительный параметр -Zone . Пример приведен в разделе об обновлении в конце этой статьи.
Настройка ведения журнала из брандмауэра Azure в Azure Monitor является необязательной. В этом примере журналы брандмауэра используются для проверки передачи трафика через брандмауэр. Сначала создайте рабочую область Log Analytics для хранения журналов. Затем используйте командлет Set-AzDiagnosticSetting для настройки диагностических параметров и отправки журналов в рабочую область.
# 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
развертывать Брандмауэр Azure и настраивать пользовательскую маршрутизацию.
Note
Это конфигурация, развернутая при обеспечении безопасности подключения из портала Azure с помощью диспетчера Azure Firewall Manager, когда параметр "Inter-hub" отключен. Инструкции по настройке маршрутизации с помощью PowerShell, когда параметр "Меж концентратор" установлен на включено, см. в разделе Включение намерения маршрутизации.
Теперь у вас есть Брандмауэр Azure в концентраторе, но по-прежнему необходимо изменить маршрутизацию, чтобы Виртуальная глобальная сеть отправляла трафик из виртуальных сетей и из ветвей через брандмауэр. Это необходимо выполнять в два этапа.
- Настройте все подключения к виртуальной сети (и подключения ветвей, если они есть) для распространения в таблицу маршрутизации
None. Эффект этой конфигурации заключается в том, что другие виртуальные сети и филиалы не смогут узнать их префиксы и, следовательно, не будут иметь маршрут для достижения их. - Теперь можно вставить статические маршруты в таблицу маршрутизации
Default(где все виртуальные сети и ветви связаны по умолчанию), чтобы весь трафик отправлялся в Брандмауэр Azure.
Начните с настройки подключений виртуальной сети для распространения в таблицу None маршрутов. Этот шаг гарантирует, что виртуальные сети не учат префиксы адресов друг друга, предотвращая прямую связь между ними. В результате весь трафик между виртуальными сетями должен проходить через брандмауэр Azure.
Для этого используйте Get-AzVhubRouteTable командлет для получения None таблицы маршрутов, а затем обновите конфигурацию маршрутизации каждого подключения виртуальной сети с помощью командлета Update-AzVirtualHubVnetConnection .
# Configure Virtual Network connections in hub to propagate to None
$VnetRoutingConfig = $Spoke1Connection.RoutingConfiguration # We take $Spoke1Connection as baseline for the future vnet config, all vnets will have an identical config
$NoneRT = Get-AzVhubRouteTable -ResourceGroupName $RG -HubName $HubName -Name "noneRouteTable"
$NewPropRT = @{}
$NewPropRT.Add('Id', $NoneRT.Id)
$PropRTList = @()
$PropRTList += $NewPropRT
$VnetRoutingConfig.PropagatedRouteTables.Ids = $PropRTList
$VnetRoutingConfig.PropagatedRouteTables.Labels = @()
$Spoke1Connection = Update-AzVirtualHubVnetConnection -ResourceGroupName $RG -ParentResourceName $HubName -Name "spoke1" -RoutingConfiguration $VnetRoutingConfig
$Spoke2Connection = Update-AzVirtualHubVnetConnection -ResourceGroupName $RG -ParentResourceName $HubName -Name "spoke2" -RoutingConfiguration $VnetRoutingConfig
Затем перейдите к второму шагу: добавление статических маршрутов в таблицу Default маршрутов. В следующем примере используется конфигурация по умолчанию, которая применяется диспетчером брандмауэра Azure при защите подключения в виртуальной глобальной сети. Список префиксов в статическом маршруте можно настроить с помощью командлета New-AzVHubRoute . В этом примере весь трафик направляется через брандмауэр Azure, что является рекомендуемым вариантом по умолчанию.
# 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)
Note
Строка "all_traffic" в качестве значения параметра "-Name" в приведенной выше команде New-AzVHubRoute имеет особое значение: если вы используете эту точную строку, конфигурация, примененная в этой статье, будет правильно отражена на портале Azure (диспетчер брандмауэров -> Виртуальные центры -> [Ваш концентратор] -> Конфигурация безопасности). Если будет использоваться другое имя, будет применена требуемая конфигурация, но не будет отражена на портале Azure.
Включение намерения маршрутизации
Если вы хотите отправлять трафик между концентраторами и регионами через Azure Firewall, развернутый в узле Виртуальной глобальной сети, можно вместо этого включить функцию намерения маршрутизации. Для получения дополнительной информации о намерении маршрутизации см. документацию по намерению маршрутизации.
Note
Это конфигурация, развернутая при защите подключения с портала Azure с помощью диспетчера брандмауэра Azure при включении параметра Interhub.
# 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
Проверка подключения
Теперь, когда безопасный концентратор полностью работает, вы можете проверить подключение, развернув виртуальную машину в каждой периферийной виртуальной сети, подключенной к концентратору.
Сначала создайте ключи SSH для проверки подлинности:
# Generate SSH key pair for VM authentication
ssh-keygen -t rsa -b 4096 -f ~/.ssh/vwan-lab-key -N ""
$sshPublicKey = Get-Content ~/.ssh/vwan-lab-key.pub
Теперь создайте виртуальные машины без общедоступных IP-адресов:
# Create VMs in spokes for testing
$VMLocalAdminUser = "azureuser"
$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 "Ubuntu2204" -Size $VMSize `
-VirtualNetworkName "spoke1" -SubnetName "vm" `
-PublicIpAddressName "" -OpenPorts 22,80 `
-GenerateSshKey -SshKeyName "spoke1-ssh-key"
$NIC1 = Get-AzNetworkInterface -ResourceId $($VM1.NetworkProfile.NetworkInterfaces[0].Id)
$Spoke1VMPrivateIP = $NIC1.IpConfigurations[0].PrivateIpAddress
# 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 "Ubuntu2204" -Size $VMSize `
-VirtualNetworkName "spoke2" -SubnetName "vm" `
-PublicIpAddressName "" -OpenPorts 22,80 `
-GenerateSshKey -SshKeyName "spoke2-ssh-key"
$NIC2 = Get-AzNetworkInterface -ResourceId $($VM2.NetworkProfile.NetworkInterfaces[0].Id)
$Spoke2VMPrivateIP = $NIC2.IpConfigurations[0].PrivateIpAddress
Развертывание Бастиона Azure
Разверните Azure Bastion в виртуальной сети Spoke-01, чтобы безопасно подключаться к виртуальным машинам без использования общедоступных IP-адресов или правил DNAT.
# Deploy Azure Bastion for secure VM access
$BastionPip = New-AzPublicIpAddress -ResourceGroupName $RG -Name "bastion-pip" `
-Location $Location -AllocationMethod Static -Sku Standard
$Spoke1 = Get-AzVirtualNetwork -ResourceGroupName $RG -Name "spoke1"
$BastionSubnet = Get-AzVirtualNetworkSubnetConfig -Name "AzureBastionSubnet" -VirtualNetwork $Spoke1
New-AzBastion -ResourceGroupName $RG -Name "spoke1-bastion" `
-PublicIpAddress $BastionPip -VirtualNetwork $Spoke1 -Sku "Basic"
Note
Развертывание Бастиона Azure может занять около 10 минут.
По умолчанию политика брандмауэра блокирует весь трафик. Чтобы разрешить доступ между периферийными виртуальными машинами и Интернетом, необходимо настроить правила брандмауэра. Сначала создайте сетевое правило, чтобы разрешить трафик SSH между виртуальными сетями. Затем добавьте правило приложения, чтобы разрешить доступ к Интернету только к полному доменному имени (FQDN), ifconfig.coкоторый возвращает исходный IP-адрес, который отображается в 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
Перед отправкой трафика проверьте действующие маршруты для каждой виртуальной машины. Таблицы маршрутов должны отображать префиксы, полученные из виртуальной глобальной сети (0.0.0.0/0 и RFC1918 диапазонов), но не должны включать префикс адреса другой периферийной виртуальной сети.
# 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
Создайте трафик из одной виртуальной машины в другую и убедитесь, что она фильтруется брандмауэром Azure. Используйте Бастион Azure для подключения к виртуальным машинам. В этом примере вы будете:
- Подключитесь к spoke1-vm с использованием Azure Bastion через портал Azure.
- Отправьте пять эхо-запросов ICMP (пингов) из ВМ в spoke1 в ВМ в spoke2.
- Попытка подключения TCP через порт 22 с помощью
ncслужебной программы (netcat) с-vzфлагами, которая проверяет подключение без отправки данных.
Обратите внимание, что ping-запросы терпят неудачу (заблокированы брандмауэром), в то время как TCP-соединение на порту 22 успешно завершено, как разрешено ранее заданным правилом сети.
Чтобы проверить подключение, выполните приведенные действия.
- На портале Azure перейдите к виртуальной машине spoke1-vm.
- Выберите Подключить>Подключение через бастион.
- Укажите имя пользователя azureuser и отправьте файл закрытого ключа, созданный ранее.
- Выберите "Подключиться" , чтобы открыть сеанс SSH.
- Выполните следующие команды в сеансе SSH:
# Ping should fail (blocked by firewall)
ping $Spoke2VMPrivateIP -c 5
# SSH connectivity check should succeed (allowed by firewall)
nc -vz $Spoke2VMPrivateIP 22
Замените $Spoke2VMPrivateIP на настоящий частный IP-адрес spoke2-vm (отображается в выходных данных PowerShell).
Вы также можете проверить доступ к Интернету через брандмауэр. HTTP-запросы, с использованием служебной программы curl для разрешенного полного доменного имени (ifconfig.co), должны выполняться успешно, а запросы к другим адресам (например, bing.com) должны быть заблокированы политикой брандмауэра.
Из того же сеанса SSH на spoke1-vm:
# This HTTP request should succeed, since it is allowed in an app rule in the AzFW, and return the public IP of the FW
curl -s4 ifconfig.co
# This HTTP request should fail, since the FQDN bing.com is not in any app rule in the firewall policy
curl -s4 bing.com
Чтобы убедиться, что брандмауэр отклоняет пакеты, как и ожидалось, просмотрите журналы, отправленные в Azure Monitor. Так как брандмауэр Azure настроен для отправки журналов диагностики в Azure Monitor, вы можете использовать язык запросов Kusto (KQL) для запроса и анализа соответствующих записей журнала:
Note
Для того чтобы журналы стали видны в Azure Monitor, может потребоваться около 1 минуты.
# 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
В предыдущей команде вы увидите различные записи:
- Удалены ICMP-пакеты между виртуальными машинами в периферийных зонах (10.1.1.4 и 10.1.2.4).
- Разрешены SSH-подключения между ВМ в спицах.
Ниже приведен пример выходных данных, созданных командой.
TimeGenerated Protocol SourceIP SourcePort TargetIP TargetPort Action NatDestination Resource
------------- -------- -------- ---------- -------- ---------- ------ -------------- --------
2020-10-04T20:53:07.045Z TCP 10.1.1.4 35932 10.1.2.4 22 Allow N/A AZFW1
2020-10-04T20:52:47.475Z TCP 10.1.1.4 53748 10.1.2.4 22 Allow N/A AZFW1
2020-10-04T20:51:04.682Z ICMP Type=8 10.1.1.4 N/A 10.1.2.4 N/A Deny N/A 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
Если вы хотите просмотреть правила приложений в журналах (описывающих разрешенные и запрещенные HTTP-соединения) или изменить способ отображения журналов, попробуйте использовать другие запросы KQL. Некоторые примеры можно найти в журналах Azure Monitor для Брандмауэра Azure.
Чтобы очистить тестовую среду, удалите группу ресурсов и все связанные ресурсы с помощью командлета Remove-AzResourceGroup . Это приведет к удалению виртуальной глобальной сети, виртуального концентратора, брандмауэра Azure и других ресурсов, созданных во время работы с этим руководством.
# Delete resource group and all contained resources
Remove-AzResourceGroup -Name $RG
Развернуть новый Azure Firewall с зонами доступности в имеющемся хабе
В предыдущих шагах показано, как использовать Azure PowerShell для создания нового виртуального глобального концентратора Azure и защиты его с помощью брандмауэра Azure. Вы также можете защитить существующий концентратор виртуальной глобальной сети Azure с помощью аналогичного подхода на основе скриптов. Хотя диспетчер брандмауэра может преобразовать концентратор в защищенный центр, он не поддерживает развертывание брандмауэра Azure в зонах доступности через портал. Чтобы развернуть брандмауэр Azure во всех трех зонах доступности, используйте следующий сценарий PowerShell для преобразования существующего виртуального глобального концентратора в защищенный концентратор.
Note
Эта процедура развертывает новый Брандмауэр Azure. Невозможно обновить существующий Брандмауэр Azure без зон доступности до одного с зонами доступности. Сначала необходимо удалить существующие Брандмауэр Azure в концентраторе и снова создать его с помощью этой процедуры.
# 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
После запуска этого скрипта зоны доступности должны отображаться в свойствах защищенного концентратора, как показано на следующем снимке экрана:
После развертывания брандмауэра Azure необходимо выполнить действия по настройке, описанные в предыдущем развертывании брандмауэра Azure, и настроить пользовательский раздел маршрутизации , чтобы обеспечить правильную маршрутизацию и безопасность.