Реализация звездообразной топологии сети в AzureImplement a hub-spoke network topology in Azure

На схеме эталонной архитектуры представлены сведения о том, как реализовать звездообразную топологию в Azure.This reference architecture shows how to implement a hub-spoke topology in Azure. Концентратор является виртуальной сетью в Azure, которая выступает в качестве центральной точки подключения к вашей локальной сети.The hub is a virtual network (VNet) in Azure that acts as a central point of connectivity to your on-premises network. Периферийные зоны — это виртуальные сети, которые устанавливают пиринг с концентратором и могут использоваться для изоляции рабочих нагрузок.The spokes are VNets that peer with the hub, and can be used to isolate workloads. Трафик передается между локальным центром обработки данных и концентратором через подключение ExpressRoute или VPN-шлюз.Traffic flows between the on-premises datacenter and the hub through an ExpressRoute or VPN gateway connection. Разверните это решение.Deploy this solution.

00

Скачать файл Visio этой архитектурыDownload a Visio file of this architecture

До преимуществ этой топологии можно отнести:The benefits of this topology include:

  • Сокращение затрат путем централизации служб, которые могут совместно использоваться несколькими рабочими нагрузками, такими как сетевые виртуальные устройства (NVA) и DNS-серверы в одном расположении.Cost savings by centralizing services that can be shared by multiple workloads, such as network virtual appliances (NVAs) and DNS servers, in a single location.
  • Превышение лимитов подписки путем пиринга виртуальных сетей из разных подписок к центральному концентратору.Overcome subscriptions limits by peering VNets from different subscriptions to the central hub.
  • Разделение областей ответственности между центральным ИТ-отделом (SecOps, InfraOps) и рабочими нагрузками (DevOps).Separation of concerns between central IT (SecOps, InfraOps) and workloads (DevOps).

Типичные способы использования этой архитектуры:Typical uses for this architecture include:

  • Рабочая нагрузка, развернутая в разных средах, например в среде для разработки, тестирования и в рабочей среде, для которых требуются общие службы, например DNS, IDS, NTP или AD DS.Workloads deployed in different environments, such as development, testing, and production, that require shared services such as DNS, IDS, NTP, or AD DS. Общие службы размещаются в виртуальной сети концентратора, в то время как каждая среда развертывается в периферийной зоне для обеспечения изоляции.Shared services are placed in the hub VNet, while each environment is deployed to a spoke to maintain isolation.
  • Рабочие нагрузки, которые не требуют подключения друг к другу, но требуют доступа к общим службам.Workloads that do not require connectivity to each other, but require access to shared services.
  • Предприятия, которые требуют централизованного контроля над аспектами безопасности, такими как брандмауэр в концентраторе, таком как сеть периметра, и отдельного управления для рабочих нагрузок в каждой периферийной зоне.Enterprises that require central control over security aspects, such as a firewall in the hub as a DMZ, and segregated management for the workloads in each spoke.

АрхитектураArchitecture

Архитектура состоит из следующих компонентов:The architecture consists of the following components.

  • Локальная сеть.On-premises network. Частная локальная сеть, работающая внутри организации.A private local-area network running within an organization.

  • VPN-устройство.VPN device. Устройство или служба, предоставляющая возможность внешнего подключения к локальной сети.A device or service that provides external connectivity to the on-premises network. VPN-устройство может быть аппаратным устройством или программным решением, таким как служба маршрутизации и удаленного доступа (RRAS) в Windows Server 2012.The VPN device may be a hardware device, or a software solution such as the Routing and Remote Access Service (RRAS) in Windows Server 2012. Список поддерживаемых VPN-устройств и сведения о настройке выбранных VPN-устройств для подключения к Azure см. в статье о VPN-устройствах для подключений VPN-шлюзов типа "сеть — сеть".For a list of supported VPN appliances and information on configuring selected VPN appliances for connecting to Azure, see About VPN devices for Site-to-Site VPN Gateway connections.

  • Сетевой шлюз виртуальной сети VPN или шлюз ExpressRoute.VPN virtual network gateway or ExpressRoute gateway. Шлюз виртуальной сети позволяет виртуальной сети подключаться к VPN-устройству или к каналу ExpressRoute, которые используются для подключения к вашей локальной сети.The virtual network gateway enables the VNet to connect to the VPN device, or ExpressRoute circuit, used for connectivity with your on-premises network. Дополнительные сведения см. в статье подключение локальной сети к Microsoft Azure виртуальной сети.For more information, see Connect an on-premises network to a Microsoft Azure virtual network.

Примечание

В сценариях развертывания для этой эталонной архитектуры используется VPN-шлюз для подключения, а виртуальная сеть в Azure используется для имитации вашей локальной сети.The deployment scripts for this reference architecture use a VPN gateway for connectivity, and a VNet in Azure to simulate your on-premises network.

  • Виртуальная сеть концентратора.Hub VNet. Виртуальная сеть Azure используется в качестве концентратора в звездообразной топологии.Azure VNet used as the hub in the hub-spoke topology. Концентратор является центральной точкой подключения к вашей локальной сети и местом для размещения служб, которые могут использоваться различными рабочими нагрузками, размещенными в виртуальных сетях.The hub is the central point of connectivity to your on-premises network, and a place to host services that can be consumed by the different workloads hosted in the spoke VNets.

  • Подсеть шлюза.Gateway subnet. Шлюзы виртуальных сетей хранятся в одной подсети.The virtual network gateways are held in the same subnet.

  • Виртуальные сети периферийных зон.Spoke VNets. Одна или несколько виртуальных сетей Azure, которые используются в качестве периферийных зон в звездообразной топологии.One or more Azure VNets that are used as spokes in the hub-spoke topology. Периферийные зоны можно использовать для изоляции рабочих нагрузок в их виртуальных сетях, управляемых отдельно от других периферийных зон.Spokes can be used to isolate workloads in their own VNets, managed separately from other spokes. Каждая рабочая нагрузка может содержать несколько уровней с несколькими подсетями, подключенными через подсистемы балансировки нагрузки Azure.Each workload might include multiple tiers, with multiple subnets connected through Azure load balancers. Дополнительные сведения о инфраструктуре приложений см. в статье выполнение рабочих нагрузок виртуальных машин Windows и Запуск рабочих нагрузок виртуальных машин Linux.For more information about the application infrastructure, see Running Windows VM workloads and Running Linux VM workloads.

  • Пиринговая связь между виртуальными сетями.VNet peering. Два виртуальных сетей можно подключить с помощью однорангового соединения.Two VNets can be connected using a peering connection. Пиринговые подключения представляют собой нетранзитивные подключения между виртуальными подсетями с низкой задержкой.Peering connections are non-transitive, low latency connections between VNets. После установки пирингового подключения виртуальные сети обмениваются трафиком по магистрали Azure без необходимости использования маршрутизатора.Once peered, the VNets exchange traffic by using the Azure backbone, without the need for a router. В звездообразной топологии сети пиринг виртуальной сети используется для подключения концентратора к каждой периферийной зоне.In a hub-spoke network topology, you use VNet peering to connect the hub to each spoke. Пиринг можно создать между виртуальными сетями в одном или в разных регионах.You can peer virtual networks in the same region, or different regions. Дополнительные сведения см. в разделе требования и ограничения.For more information, see Requirements and constraints.

Примечание

В этой статье рассматриваются только развертывания Resource Manager, но вы также можете подключить классическую виртуальную сеть к виртуальной сети Resource Manager в той же подписке.This article only covers Resource Manager deployments, but you can also connect a classic VNet to a Resource Manager VNet in the same subscription. Таким образом, ваши периферийные зоны могут размещать классические развертывания и по-прежнему пользоваться преимуществами общих служб в концентраторе.That way, your spokes can host classic deployments and still benefit from services shared in the hub.

РекомендацииRecommendations

Следующие рекомендации применимы для большинства ситуаций.The following recommendations apply for most scenarios. Следуйте этим рекомендациям, если они не противоречат особым требованиям для вашего случая.Follow these recommendations unless you have a specific requirement that overrides them.

Группы ресурсовResource groups

Центральную виртуальную сеть и каждую периферийную виртуальную сеть, можно реализовать в разных группах ресурсов и даже в разных подписках.The hub VNet, and each spoke VNet, can be implemented in different resource groups, and even different subscriptions. Если вы устанавливаете пиринг виртуальных сетей в разных подписках, обе подписки могут быть связаны с одним и тем же или с разными клиентами Azure Active Directory.When you peer virtual networks in different subscriptions, both subscriptions can be associated to the same or different Azure Active Directory tenant. Это позволяет осуществлять децентрализованное управление каждой рабочей нагрузкой при совместном использовании служб, поддерживаемых в концентраторе виртуальной сети.This allows for a decentralized management of each workload, while sharing services maintained in the hub VNet.

Виртуальная сеть и подсеть шлюзаVNet and GatewaySubnet

Создание подсети с именем GatewaySubnet с диапазоном адресов /27.Create a subnet named GatewaySubnet, with an address range of /27. Эта подсеть необходима для шлюза виртуальной сети.This subnet is required by the virtual network gateway. Выделение 32 адресов этой подсети поможет предотвратить достижение ограничения размера шлюза в будущем.Allocating 32 addresses to this subnet will help to prevent reaching gateway size limitations in the future.

Дополнительные сведения о настройке шлюза см. в следующих статьях с данными об эталонных архитектурах в зависимости от типа подключения:For more information about setting up the gateway, see the following reference architectures, depending on your connection type:

Для обеспечения высокой доступности вы можете использовать ExpressRoute вместе с VPN для отработки отказа.For higher availability, you can use ExpressRoute plus a VPN for failover. См. статью подключение локальной сети к Azure с помощью ExpressRoute с отработкой отказа VPN.See Connect an on-premises network to Azure using ExpressRoute with VPN failover.

Звездообразная топология может также использоваться без шлюза, если вам не требуется связь с локальной сетью.A hub-spoke topology can also be used without a gateway, if you don't need connectivity with your on-premises network.

Пиринговая связь между виртуальными сетямиVNet peering

Пиринговая связь между виртуальными сетями — это нетранзитивная связь между двумя виртуальными сетями.VNet peering is a non-transitive relationship between two VNets. Если вам требуется, чтобы периферийные зоны соединялись друг с другом, подумайте над добавлением отдельного пирингового подключения между ними.If you require spokes to connect to each other, consider adding a separate peering connection between those spokes.

Тем не менее, если у вас есть несколько периферийных узлов, которые должны подключаться друг к другу, очень быстро будут выполняться все возможные одноранговые соединения из-за ограничения на число одноранговых виртуальных сетей в каждой виртуальной сети.However, if you have several spokes that need to connect with each other, you will run out of possible peering connections very quickly due to the limitation on number of VNets peerings per VNet. В этом случае рассмотрите возможность использования определяемых пользователем маршрутов (определяемые пользователем маршруты) для принудительной отправки трафика, предназначенного для периферийного сервера, в брандмауэр Azure или NVA, действующего в качестве маршрутизатора в виртуальной сети концентратора.In this scenario, consider using user defined routes (UDRs) to force traffic destined to a spoke to be sent to Azure Firewall or an NVA acting as a router at the hub VNet. Это позволит периферийным зонам подключаться друг к другу.This will allow the spokes to connect to each other.

Вы также можете настроить периферийные зоны для использования шлюза виртуальной сети концентратора для подключения к удаленным сетям.You can also configure spokes to use the hub VNet gateway to communicate with remote networks. Чтобы разрешить передачу трафика шлюза из периферийной зоны в концентратор и подключение к удаленным сетям, требуется сделать следующее:To allow gateway traffic to flow from spoke to hub, and connect to remote networks, you must:

  • Настроить пиринговую связь между виртуальными сетями в концентраторе, чтобы разрешить транзит шлюзов.Configure the VNet peering connection in the hub to allow gateway transit.
  • Настроить пиринговое подключение виртуальной сети к каждой периферийной зоне для использования удаленных шлюзов.Configure the VNet peering connection in each spoke to use remote gateways.
  • Настроить все пиринговые соединения виртуальных сетей, чтобы разрешить перенаправление трафика.Configure all VNet peering connections to allow forwarded traffic.

РекомендацииConsiderations

Подключение периферийной зоныSpoke connectivity

Если требуется подключение между периферийными серверами, рассмотрите возможность развертывания брандмауэра Azure или NVA для маршрутизации в концентраторе и использование определяемые пользователем маршруты на периферийном сервере для перенаправления трафика в концентратор.If you require connectivity between spokes, consider deploying Azure Firewall or an NVA for routing in the hub, and using UDRs in the spoke to forward traffic to the hub. Приведенные ниже шаги развертывания включают необязательный шаг, который настраивает эту конфигурацию.The deployment steps below include an optional step that sets up this configuration.

22

В этом случае необходимо настроить пиринговые соединения, чтобы разрешить перенаправленный трафик.In this scenario, you must configure the peering connections to allow forwarded traffic.

Кроме того, следует учитывать, какие службы используются совместно в концентраторе, чтобы убедиться, что концентратор масштабируется в соответствии с большим количеством периферийных зон.Also consider what services are shared in the hub, to ensure the hub scales for a larger number of spokes. Например, если ваш концентратор предоставляет службы брандмауэра, рассмотрите возможность ограничения пропускной способности решения брандмауэра при добавлении нескольких периферийных зон.For instance, if your hub provides firewall services, consider the bandwidth limits of your firewall solution when adding multiple spokes. Возможно, вам захочется перенести некоторые из этих общих служб на второй уровень концентраторов.You might want to move some of these shared services to a second level of hubs.

Развертывание решенияDeploy the solution

Развертывание для этой архитектуры доступно на сайте GitHub.A deployment for this architecture is available on GitHub. В нем используются виртуальные машины в каждой виртуальной сети для проверки возможности подключения.It uses VMs in each VNet to test connectivity. В подсети shared-services в виртуальной сети концентратора нет настоящих служб.There are no actual services hosted in the shared-services subnet in the hub VNet.

Развертывание создает в вашей подписке следующие группы ресурсов:The deployment creates the following resource groups in your subscription:

  • hub-vnet-rghub-vnet-rg
  • onprem-jb-rgonprem-jb-rg
  • onprem-vnet-rgonprem-vnet-rg
  • spoke1-vnet-rgspoke1-vnet-rg
  • spoke2-vnet-rgspoke2-vnet-rg

Файлы параметров шаблона ссылаются на эти имена, поэтому, если вы их изменяете, соответствующим образом обновите файлы параметров.The template parameter files refer to these names, so if you change them, update the parameter files to match.

Предварительные требованияPrerequisites

  1. Клонируйте или скачайте ZIP-файл с эталонными архитектурами в репозитории GitHub либо создайте для него вилку.Clone, fork, or download the zip file for the reference architectures GitHub repository.

  2. Установите Azure CLI 2.0.Install Azure CLI 2.0.

  3. Установите Node.js и NPMInstall Node and NPM

  4. Установите пакет npm стандартных блоков Azure.Install the Azure building blocks npm package.

    npm install -g @mspnp/azure-building-blocks
    
  5. Из командной строки, строки bash или строки PowerShell войдите в свою учетную запись Azure, как показано ниже:From a command prompt, bash prompt, or PowerShell prompt, sign into your Azure account as follows:

    az login
    

Развертывание имитации локального центра обработки данныхDeploy the simulated on-premises datacenter

Чтобы развернуть имитацию локального центра обработки данных в виртуальной сети Azure, следуйте этим инструкциям:To deploy the simulated on-premises datacenter as an Azure VNet, follow these steps:

  1. Перейдите в папку hybrid-networking/hub-spoke в репозитории эталонных архитектур.Navigate to the hybrid-networking/hub-spoke folder of the reference architectures repository.

  2. Откройте файл onprem.json .Open the onprem.json file. Замените значения для adminUsername и adminPassword.Replace the values for adminUsername and adminPassword.

    "adminUsername": "<user name>",
    "adminPassword": "<password>",
    
  3. Для развертывания Linux установите osType как Linux (необязательно).(Optional) For a Linux deployment, set osType to Linux.

  4. Выполните следующую команду:Run the following command:

    azbb -s <subscription_id> -g onprem-vnet-rg -l <location> -p onprem.json --deploy
    
  5. Дождитесь завершения развертывания.Wait for the deployment to finish. При развертывании создается виртуальная сеть, виртуальная машина и VPN-шлюз.This deployment creates a virtual network, a virtual machine, and a VPN gateway. Для создания VPN-шлюза может потребоваться около 40 минут.It can take about 40 minutes to create the VPN gateway.

Развертывание концентратора виртуальной сетиDeploy the hub VNet

Чтобы развернуть концентратор виртуальной сети, выполните следующие действия.To deploy the hub VNet, perform the following steps.

  1. Откройте файл hub-vnet.json .Open the hub-vnet.json file. Замените значения для adminUsername и adminPassword.Replace the values for adminUsername and adminPassword.

    "adminUsername": "<user name>",
    "adminPassword": "<password>",
    
  2. Для развертывания Linux установите osType как Linux (необязательно).(Optional) For a Linux deployment, set osType to Linux.

  3. Найдите оба экземпляра sharedKey и введите общий ключ для подключения VPN.Find both instances of sharedKey and enter a shared key for the VPN connection. Значения должны совпадать.The values must match.

    "sharedKey": "",
    
  4. Выполните следующую команду:Run the following command:

    azbb -s <subscription_id> -g hub-vnet-rg -l <location> -p hub-vnet.json --deploy
    
  5. Дождитесь завершения развертывания.Wait for the deployment to finish. В ходе этого развертывания создается виртуальная сеть, виртуальная машина, VPN-шлюз и подключение к шлюзу.This deployment creates a virtual network, a virtual machine, a VPN gateway, and a connection to the gateway. Для создания VPN-шлюза может потребоваться около 40 минут.It can take about 40 minutes to create the VPN gateway.

Проверка возможности подключения к виртуальной сети концентратора (развертывание Windows)Test connectivity to the hub VNet — Windows deployment

Чтобы проверить возможность подключения из моделируемой локальной среды к виртуальной сети концентратора с помощью виртуальных машин Windows, выполните следующие действия.To test connectivity from the simulated on-premises environment to the hub VNet using Windows VMs, follow these steps:

  1. Используйте портал Azure для поиска в группе ресурсов onprem-jb-rg виртуальной машины с именем jb-vm1.Use the Azure portal to find the VM named jb-vm1 in the onprem-jb-rg resource group.

  2. Нажмите Connect, чтобы открыть сеанс удаленного рабочего стола для виртуальной машины.Click Connect to open a remote desktop session to the VM. Используйте пароль, указанный в файле параметров onprem.json.Use the password that you specified in the onprem.json parameter file.

  3. Откройте консоль PowerShell в виртуальной машине и используйте командлет Test-NetConnection, чтобы убедиться, что вы можете подключиться к виртуальной машине Jumpbox в виртуальной сети концентратора.Open a PowerShell console in the VM, and use the Test-NetConnection cmdlet to verify that you can connect to the jumpbox VM in the hub VNet.

    Test-NetConnection 10.0.0.68 -CommonTCPPort RDP
    

Результат должен выглядеть следующим образом.The output should look similar to the following:

ComputerName     : 10.0.0.68
RemoteAddress    : 10.0.0.68
RemotePort       : 3389
InterfaceAlias   : Ethernet 2
SourceAddress    : 192.168.1.000
TcpTestSucceeded : True

Примечание

По умолчанию виртуальные машины Windows Server не разрешают трафик ICMP в Azure.By default, Windows Server VMs do not allow ICMP responses in Azure. Если вы хотите использовать команду ping для проверки возможности подключения, включите трафик ICMP в расширенном брандмауэре Windows для каждой виртуальной машины.If you want to use ping to test connectivity, you need to enable ICMP traffic in the Windows Advanced Firewall for each VM.

Проверка возможности подключения к виртуальной сети концентратора (развертывание Linux)Test connectivity to the hub VNet — Linux deployment

Чтобы проверить возможность подключения из моделируемой локальной среды к виртуальной сети концентратора с помощью виртуальных машин Linux, выполните следующие действия.To test connectivity from the simulated on-premises environment to the hub VNet using Linux VMs, follow these steps:

  1. Используйте портал Azure для поиска в группе ресурсов onprem-jb-rg виртуальной машины с именем jb-vm1.Use the Azure portal to find the VM named jb-vm1 in the onprem-jb-rg resource group.

  2. Нажмите Connect и скопируйте команду ssh, показанную на портале.Click Connect and copy the ssh command shown in the portal.

  3. В командной строке Linux запустите ssh, чтобы подключиться к моделируемой локальной среде.From a Linux prompt, run ssh to connect to the simulated on-premises environment. Используйте пароль, указанный в файле параметров onprem.json.Use the password that you specified in the onprem.json parameter file.

  4. Используйте команду nc для проверки подключения к виртуальной машине Jumpbox в виртуальной сети концентратора:Use the nc command to test connectivity to the jumpbox VM in the hub VNet:

    nc -vzw 1 10.0.0.68 22
    

Развертывание виртуальных сетей периферийных зонDeploy the spoke VNets

Чтобы развернуть виртуальные сети периферийных зон, сделайте следующее.To deploy the spoke VNets, perform the following steps.

  1. Откройте файл spoke1.json .Open the spoke1.json file. Замените значения для adminUsername и adminPassword.Replace the values for adminUsername and adminPassword.

    "adminUsername": "<user name>",
    "adminPassword": "<password>",
    
  2. Для развертывания Linux установите osType как Linux (необязательно).(Optional) For a Linux deployment, set osType to Linux.

  3. Выполните следующую команду:Run the following command:

    azbb -s <subscription_id> -g spoke1-vnet-rg -l <location> -p spoke1.json --deploy
    
  4. Повторите шаги 1–2 для файла spoke2.json.Repeat steps 1-2 for the spoke2.json file.

  5. Выполните следующую команду:Run the following command:

    azbb -s <subscription_id> -g spoke2-vnet-rg -l <location> -p spoke2.json --deploy
    
  6. Выполните следующую команду:Run the following command:

    azbb -s <subscription_id> -g hub-vnet-rg -l <location> -p hub-vnet-peering.json --deploy
    

Проверка возможности подключения к виртуальным сетям периферийных зон (развертывание Windows)Test connectivity to the spoke VNets — Windows deployment

Чтобы проверить возможность подключения из моделируемой локальной среды к периферийной виртуальных сетей с помощью виртуальных машин Windows, выполните следующие действия.To test connectivity from the simulated on-premises environment to the spoke VNets using Windows VMs, perform the following steps:

  1. Используйте портал Azure для поиска в группе ресурсов onprem-jb-rg виртуальной машины с именем jb-vm1.Use the Azure portal to find the VM named jb-vm1 in the onprem-jb-rg resource group.

  2. Нажмите Connect, чтобы открыть сеанс удаленного рабочего стола для виртуальной машины.Click Connect to open a remote desktop session to the VM. Используйте пароль, указанный в файле параметров onprem.json.Use the password that you specified in the onprem.json parameter file.

  3. Откройте консоль PowerShell в виртуальной машине и используйте командлет Test-NetConnection, чтобы проверить возможность подключения к виртуальным машинам Jumpbox в виртуальных сетях периферийных зон.Open a PowerShell console in the VM, and use the Test-NetConnection cmdlet to verify that you can connect to the jumpbox VMs in the spoke VNets.

    Test-NetConnection 10.1.0.68 -CommonTCPPort RDP
    Test-NetConnection 10.2.0.68 -CommonTCPPort RDP
    

Проверка возможности подключения к виртуальным сетям периферийных зон (развертывание Linux)Test connectivity to the spoke VNets — Linux deployment

Чтобы проверить возможность подключения из моделируемой локальной среды к периферийной виртуальных сетей с помощью виртуальных машин Linux, выполните следующие действия.To test connectivity from the simulated on-premises environment to the spoke VNets using Linux VMs, perform the following steps:

  1. Используйте портал Azure для поиска в группе ресурсов onprem-jb-rg виртуальной машины с именем jb-vm1.Use the Azure portal to find the VM named jb-vm1 in the onprem-jb-rg resource group.

  2. Нажмите Connect и скопируйте команду ssh, показанную на портале.Click Connect and copy the ssh command shown in the portal.

  3. В командной строке Linux запустите ssh, чтобы подключиться к моделируемой локальной среде.From a Linux prompt, run ssh to connect to the simulated on-premises environment. Используйте пароль, указанный в файле параметров onprem.json.Use the password that you specified in the onprem.json parameter file.

  4. Используйте команду nc, чтобы проверить возможность подключения к виртуальным машинам jumpbox в каждой периферийной зоне.Use the nc command to test connectivity to the jumpbox VMs in each spoke:

    nc -vzw 1 10.1.0.68 22
    nc -vzw 1 10.2.0.68 22
    

Добавление подключения между периферийными зонамиAdd connectivity between spokes

Этот шаг не является обязательным.This step is optional. Если вы хотите разрешить подключение периферийных серверов друг к другу, используйте брандмауэр Azure , чтобы принудительно установить трафик с периферийных серверов на маршрутизатор при попытке подключения к другому периферийному серверу.If you want to allow spokes to connect to each other, use Azure Firewall to force traffic from spokes to the router when trying to connect to another spoke. Чтобы развернуть брандмауэр Azure вместе с определяемыми пользователем маршрутами (определяемые пользователем маршруты), чтобы разрешить подключение двух периферийных виртуальных сетей, выполните следующие действия.To deploy Azure Firewall, along with user-defined routes (UDRs) to allow the two spoke VNets to connect, perform the following steps:

  1. Добавьте подсеть для брандмауэра Azure в виртуальную сеть концентратора.Add a subnet for Azure Firewall to the hub virtual network.

    az network vnet subnet create -g hub-vnet-rg --vnet-name hub-vnet -n AzureFirewallSubnet --address-prefixes 10.0.0.128/26
    
  2. Развертывание брандмауэра Azure:Deploy Azure Firewall:

    az group deployment create -g hub-vnet-rg --template-file hub-firewall.json
    
  3. Выполните следующую команду, чтобы получить privateIPAddress брандмауэра, созданного на шаге 2.Run the following command to get the privateIPAddress of the firewall created in step 2:

    az resource show -g hub-vnet-rg -n hub-firewall --resource-type Microsoft.Network/azureFirewalls --query properties.ipConfigurations[0].properties.privateIPAddress
    
  4. Измените файл Hub-Firewall-Routes. JSON и замените все вхождения <azure_firewall_private_ip> на IP-адрес из предыдущей команды.Edit the hub-firewall-routes.json file and replace all occurrences of <azure_firewall_private_ip> with the IP Address from the previous command. Сохраните Hub-Firewall-Routes. JSON, а затем выполните следующую команду.Save hub-firewall-routes.json and then run the following command.

    azbb -s <subscription_id> -g hub-vnet-rg -l <location> -p hub-firewall-routes.json --deploy
    
  5. Выполните следующую команду, чтобы отключить распространение маршрутов BGP для таблиц маршрутов, связанных с подсетями с периферийными серверами.Run the following command to disable BGP route propagation for the route tables associated with the spoke subnets:

    az network route-table update -g hub-vnet-rg -n spoke1-rt --disable-bgp-route-propagation true
    az network route-table update -g hub-vnet-rg -n spoke2-rt --disable-bgp-route-propagation true
    

Чтобы проверить подключение, выполните следующие действия.To verify connectivity, perform the following steps:

  1. Войдите в виртуальную машину jb-vm1 с именем onprem-jb-rg в группе ресурсов.Log into the VM named jb-vm1 in the onprem-jb-rg resource group.

  2. В этом сеансе входа войдите в виртуальную машину Jumpbox для лучевой-1.From this login session, log into the jumpbox VM for spoke-1. Частный IP-адрес — 10.1.0.68.The private IP address is 10.1.0.68.

  3. Используйте командлет (Windows) или nc команду (Linux), чтобы проверить возможность подключения к 10.2.0.68, которая является виртуальной машиной Jumpbox для лучевой-2. Test-NetConnectionUse the Test-NetConnection cmdlet (Windows) or nc command (Linux) to test connectivity to 10.2.0.68, which is the jumpbox VM for spoke-2.