Проектирование сети для Microsoft Azure IaaSDesigning networking for Microsoft Azure IaaS

Сводка: Понять, как Разработка оптимизированного сети для рабочих нагрузок в Microsoft Azure IaaS.Summary: Understand how to design optimized networking for workloads in Microsoft Azure IaaS.

Оптимизация сетей для выполнения ИТ-задач в Azure IaaS требует понимания виртуальных сетей, пространств адресов, маршрутизации, DNS и балансировки нагрузки Azure.Optimizing networking for IT workloads hosted in Azure IaaS requires an understanding of Azure virtual networks (VNets), address spaces, routing, DNS, and load balancing.

Этапы планирования для любой виртуальной сетиPlanning steps for any VNet

Ниже перечислены шаги, которыми следует руководствоваться при планировании виртуальной сети любого типа.Follow these steps for any type of VNet.

Шаг 1. Подготовьте интрасеть для облачных служб (Майкрософт).Step 1: Prepare your intranet for Microsoft cloud services.

Выполните действия по подготовке сети для облачных служб (Майкрософт), описанные в статье Общие элементы подключения к облаку Майкрософт.Go through the Steps to prepare your network for Microsoft cloud services section in Common elements of Microsoft cloud connectivity.

Шаг 2. Оптимизируйте пропускную способность канала доступа в Интернет.Step 2: Optimize your Internet bandwidth.

Оптимизируйте скорость интернет-соединения, выполнив действия 2–4 из раздела Действия по подготовке сети для служб Microsoft SaaS статьи Проектирование сети для Microsoft SaaS.Optimize your Internet bandwidth using steps 2 - 4 of the Steps to prepare your network for Microsoft SaaS services section in Designing networking for Microsoft SaaS.

Шаг 3. Выберите тип виртуальной сети (только облачная или распределенная).Step 3: Determine the type of VNet (cloud-only or cross-premises).

Только облачные сети не подключаются к локальным сетям. Пример:A cloud-only VNet has no connection to an on-premises network. Here is an example.

Рис. 1. Только облачная виртуальная сетьFigure 1: A cloud-only VNet

Рис. 1. Виртуальная сеть в Azure, полностью размещенная в облаке

На рисунке 1 показан набор виртуальных машин в только облачной виртуальной сети.Figure 1 shows a set of virtual machines in a cloud-only VNet.

В распределенной виртуальной сети имеется подключение VPN типа "сеть-сеть" или ExpressRoute к локальной сети через шлюз Azure. Пример:A cross-premises VNet has a site-to-site (S2S) VPN or ExpressRoute connection to an on-premises network through an Azure gateway. Here is an example.

Рис. 2. Распределенная виртуальная сетьFigure 2: A cross-premises VNet

Рис. 2. Распределенная виртуальная сеть в Azure

На рисунке 2 представлен набор виртуальных машин в распределенной виртуальной сети, которая подключена к локальной сети.Figure 2 shows a set of virtual machines in a cross-premises VNet, which is connected to an on-premises network.

Дополнительные сведения см. в разделе Этапы планирования для распределенной виртуальной сети далее в этой статье.See the additional Planning steps for a cross-premises VNet section in this article.

Шаг 4. Определите адресное пространство для виртуальной сети.Step 4: Determine the address space of the VNet.

В таблице 1 показаны адресные пространства для различных типов виртуальных сетей.Table 1 shows the address spaces for the different types of VNets.

Тип виртуальной сетиType of VNet Адресное пространство виртуальной сетиVirtual network address space
Только облачнаяCloud-only
Произвольное частное адресное пространствоArbitrary private address space
Только облачная с межсоединениямиInterconnected cloud-only
Произвольный private, но не совпадает с другими подключенных VNetsArbitrary private, but not overlapping with other connected VNets
РаспределеннаяCross-premises
Частное адресное пространство, не перекрывающееся с локальными сетямиPrivate, but not overlapping with on-premises
Распределенная с межсоединениямиInterconnected cross-premises
Частное адресное пространство, не перекрывающееся с другими локальными сетями и другими подключенными виртуальными сетямиPrivate, but not overlapping with on-premises and other connected VNets

Таблица 1. Типы виртуальных сетей и соответствующие адресные пространстваTable 1: Types of VNets and their corresponding address space

Виртуальным машинам назначаются конфигурации адресов из адресного пространства подсети. За это отвечает сервер DHCP:Virtual machines are assigned an address configuration from the address space of the subnet by DHCP:

  • Адрес/маска подсетиAddress/subnet mask

  • Шлюз по умолчаниюDefault gateway

  • IP-адреса DNS-серверовDNS server IP addresses

Кроме того, можно зарезервировать статический IP-адрес.You can also reserve a static IP address.

Виртуальным машинам также можно назначать общедоступные IP-адреса. Это можно сделать как отдельно для каждой машины, так и из облачной службы, содержащей виртуальные машины (только для машин, развернутых классическим способом).Virtual machines can also be assigned a public IP address, either individually or from the containing cloud service (for classic deployment machines only).

Шаг 5. Определите подсети в виртуальной сети и назначьте адресное пространство каждой из них.Step 5: Determine the subnets within the VNet and the address spaces assigned to each.

В виртуальных сетях существует два типа подсетей: подсеть шлюза и подсеть с размещенными виртуальными машинами.There are two types of subnets in a VNet, a gateway subnet and a virtual machine-hosting subnet.

Рис. 3. Два типа подсетей в AzureFigure 3: The two types of subnets in Azure

Рис. 3. Два типа подсетей в Azure

На рисунке 3 представлена виртуальная сеть с подсетью шлюза, в которой имеется шлюз Azure, и набором подсетей с размещенными виртуальными машинами.Figure 3 shows a VNet containing a gateway subnet that contains an Azure gateway and a set of virtual machine-hosting subnets containing virtual machines.

Подсеть шлюза Azure требуется службе Azure для размещения двух виртуальных машин шлюза Azure. Длина префикса для указываемого адресного пространства должна составлять хотя бы 29 бита (например: 192.168.15.248/29). Рекомендуется использовать префикс длиной 28 бита или менее, особенно, если планируется использовать ExpressRoute.The Azure gateway subnet is needed by Azure to host the two virtual machines of your Azure gateway. Specify an address space with at least a 29-bit prefix length (example: 192.168.15.248/29). A 28-bit or smaller prefix length is recommended, especially if you are planning to use ExpressRoute.

Ниже представлены рекомендации по определению адресного пространства для подсети шлюза Azure.A best practice for determining the address space of the Azure gateway subnet is the following:

  1. Выберите размер подсети шлюза.Decide on the size of the gateway subnet.

  2. В переменных битах в адресном пространстве виртуальной сети задайте для битов, используемых для подсети шлюза, значение 0, а для оставшихся битов — значение 1.In the variable bits in the address space of the VNet, set the bits used for the gateway subnet to 0 and set the remaining bits to 1.

  3. Преобразуйте полученный результат в десятичный формат и выразите его как адресное пространство, длина префикса которого соответствует размеру подсети шлюза.Convert to decimal and express as an address space with the prefix length set to the size of the gateway subnet.

При использовании этого метода адресное пространство для подсети шлюза всегда будет находиться в самом конце адресного пространства виртуальной сети.With this method, the address space for the gateway subnet is always at the farthest end of the VNet address space.

Вот пример определения префикса адреса для подсети шлюза: адресное пространство виртуальной сети — 10.119.0.0/16. Организация изначально будет использовать VPN-подключение типа "сеть-сеть", но в итоге перейдет на ExpressRoute. В таблице 2 представлены действия по определению префикса адреса для подсети шлюза в нотации сетевых префиксов и результаты этих действий.Here is an example of defining the address prefix for the gateway subnet: The address space of the VNet is 10.119.0.0/16. The organization will initially use a site-to-site VPN connection, but will eventually get ExpressRoute. Table 2 shows the steps and results of determining the gateway subnet address prefix in network prefix notation (also known as CIDR).

Ниже приведены действия и пример определения префикс адреса подсети шлюза.Here are the steps and example of determining the gateway subnet address prefix:

  1. Определите размер шлюза подсети. Для этого примера следует выбрать /28.Decide on the size of the gateway subnet. For our example, we chose /28.
  2. Значение двоичных файлов в переменную часть VNet адресного пространства (b) 0 для шлюза бит подсети (G), в противном случае — 1 (V). Для этого примера мы используем 10.119.0.0/16 адресное пространство для VNet.Set the bits in the variable portion of the VNet address space (b) to 0 for the gateway subnet bits (G), otherwise 1 (V). For our example, we are using the 10.119.0.0/16 address space for the VNet.

    10.119. bbbbbbbb. bbbbbbbb10.119. bbbbbbbb . bbbbbbbb
    10.119. VVVVVVVV. VVVVGGGG10.119. VVVVVVVV . VVVVGGGG
    10.119. 11111111. 1111000010.119. 11111111 . 11110000

  3. Преобразуйте результат на шаге 2 в десятичное и express как адресное пространство. Для этого примера 10.119. 11111111. 11110000 — 10.119.255.240, а длина префикса из шага 1, (28 в нашем примере), полученный префикс адреса подсети шлюза — 10.119.255.240/28.Convert the result from step 2 to decimal and express as an address space. For our example, 10.119. 11111111 . 11110000 is 10.119.255.240, and with the prefix length from step 1, (28 in our example), the resulting gateway subnet address prefix is 10.119.255.240/28.

Для получения дополнительных сведений в разделе Калькулятор пространства адресов для подсетей Azure шлюза .See Address space calculator for Azure gateway subnets for more information.

Подсети с размещенными виртуальными машинами — это сети, в которых размещаются виртуальные машины Azure, что можно сделать, руководствуясь стандартными инструкциями для локальных сетей, например, используя общую роль, уровень приложений или инструкции по изоляции подсети.Virtual machine-hosting subnets are where you place Azure virtual machines, which you can do according to typical on-premises guidelines, such as a common role or tier of an application or for subnet isolation.

Azure использует сначала 3 адреса для каждой подсети. Таким образом число возможных адресов в Azure подсети — 2n - 5, где n — число бит узла. В таблице 3 показано ряду виртуальных машин требуется, число, где размещается бит необходимые и соответствующий размер подсети.Azure uses the first 3 addresses on each subnet. Therefore, the number of possible addresses on an Azure subnet is 2n - 5, where n is the number of host bits. Table 3 shows the range of virtual machines required, the number of hosts bits needed, and the corresponding subnet size.

Необходимо виртуальных машинVirtual machines required Биты узловHost bits Размер подсетиSubnet size
1–31-3
3 3
/29/29
4–114-11
4 4
/28/28
12–2712-27
5 5
/27/27
28–5928-59
6 6
/26/26
60–12360-123
7 7
/25/25

Таблица 3. Требования к виртуальным машинам и размерам подсетиTable 3: Virtual machine requirements and their subnet sizes

Дополнительные сведения о максимальный объем виртуальных машин в подсети или VNet можно Ограничения для сети.For more information about the maximum amount of virtual machines on a subnet or VNet, see Networking Limits.

Для получения дополнительных сведений см Планирование и проектирование виртуальные сети Azure.For more information, see Plan and design Azure Virtual Networks.

Шаг 6. Определите конфигурацию DNS-сервера и адреса DNS-серверов для назначения виртуальным машинам в виртуальной сети.Step 6: Determine the DNS server configuration and the addresses of the DNS servers to assign to VMs in the VNet.

Azure назначает виртуальным машинам адреса DNS-серверов с помощью сервера DHCP. DNS-серверы могут:Azure assigns virtual machines the addresses of DNS servers by DHCP. DNS servers can be:

  • предоставляться Azure: регистрация локального имени, а также разрешение локальных и интернет-имен;Supplied by Azure: Provides local name registration and local and Internet name resolution

  • указываться вами: регистрация локального или интернет-имени, а также разрешение имен в интрасети или Интернете.Provided by you: Provides local or intranet name registration and either intranet or Internet name resolution

В таблице 4 представлены различные конфигурации DNS-сервера для каждого типа виртуальной сети.Table 4 shows the different configurations of DNS servers for each type of VNet.

Тип виртуальной сетиType of VNet DNS-серверDNS server
Только облачнаяCloud-only
Разрешение локальных и интернет-имен службой AzureAzure-supplied for local and Internet name resolution
Виртуальная машина Azure для разрешения локальных и интернет-имен (переадресация DNS)Azure virtual machine for local and Internet name resolution (DNS forwarding)
РаспределеннаяCross-premises
Разрешение локальных и интернет-имен локальной службойOn-premises for local and intranet name resolution
Виртуальная машина Azure для разрешения локальных имен и имен в интрасети (репликация и переадресация DNS)Azure virtual machine for local and intranet name resolution (DNS replication and forwarding)

Таблица 4. Варианты DNS-серверов для двух различных типов виртуальных сетейTable 4: DNS server options for the two different types of VNets

Для получения дополнительных сведений см Разрешение имен для виртуальных машин и роль экземпляров.For more information, see Name Resolution for VMs and Role Instances.

Шаг 7. Определите конфигурацию балансировки нагрузки (для внутреннего или интернет-трафика).Step 7: Determine the load balancing configuration (Internet-facing or internal).

В некоторых случаях входящий трафик требуется распределить по нескольким серверам, которым назначена одна и та же роль. В Azure IaaS имеются встроенные средства для этого в отношении внутреннего и интернет-трафика.In some cases, you want to distribute incoming traffic to a set of servers that have the same role. Azure IaaS has a built-in facility to do this for Internet-facing and internal traffic loads.

Подсистема балансировки нагрузки Azure для интернет-трафика случайным образом распределяет нежелательный входящий трафик из Интернета среди участников набора балансировки нагрузки. Azure Internet-facing load balancing randomly distributes unsolicited incoming traffic from the Internet to the members of a load-balanced set.

Рис. 4. Внешний балансировщик нагрузки в AzureFigure 4: An external load balancer in Azure

Рис. 4. Внешний балансировщик нагрузки в Azure

На рисунке 4 показано балансировки нагрузки в Azure, которая распределяет входящий трафик на входящий правила преобразования сетевых адресов или конечную точку в набор виртуальных машин в набор подсистемы балансировки нагрузки.Figure 4 shows an external load balancer in Azure that distributes incoming traffic on an inbound NAT rule or endpoint to a set of virtual machines in a load-balanced set.

Подсистема балансировки нагрузки Azure для внутреннего трафика случайным образом распределяет незапрошенный входящий трафик от других виртуальных машин или компьютеров в интрасети среди участников набора балансировки нагрузки. Azure internal load balancing randomly distributes unsolicited incoming traffic from other Azure VMs or from intranet computers to the members of a load-balanced set.

Рис. 5. Внутренний балансировщик нагрузки в AzureFigure 5: An internal load balancer in Azure

Рис. 5. Внутренний балансировщик нагрузки в Azure

На рисунке 5 показано балансировки нагрузки внутренних в Azure, которая распределяет входящий трафик на входящий правила преобразования сетевых адресов или конечную точку в набор виртуальных машин в набор подсистемы балансировки нагрузки.Figure 5 shows an internal load balancer in Azure that distributes incoming traffic on an inbound NAT rule or endpoint to a set of virtual machines in a load-balanced set.

Для получения дополнительных сведений см Балансировки нагрузки для Azure.For more information, see Azure Load Balancer.

Шаг 8. Определите порядок использования виртуальных модулей и пользовательских маршрутов в Azure.Step 8: Determine the use of virtual appliances and user-defined routes.

Если требуется перенаправить трафик на виртуальные модули в виртуальной сети, возможно, в подсеть потребуется добавить один или несколько пользовательских маршрутов.If you need to forward traffic to virtual appliances in your VNet, you may need to add one or more user-defined routes to a subnet.

Рис. 6. Виртуальные устройства и пользовательские маршруты в AzureFigure 6: Virtual appliances and user-defined routes in Azure

Рис. 6. Виртуальные устройства и пользовательские маршруты в Azure

На рисунке 6 представлена распределенная виртуальная сеть и пользовательский маршрут, назначенный подсети с размещенными виртуальными машинами, которая указывает на виртуальный модуль.Figure 6 shows a cross-premises VNet and a user-defined route assigned to a virtual machine-hosting subnet that points to a virtual appliance.

Для получения дополнительных сведений см маршруты определенных пользователей и IP-адрес переадресации.For more information, see User Defined Routes and IP Forwarding.

Шаг 9. Определите, как компьютеры из Интернета будут автоматически подключаться к виртуальным машинам.Step 9: Determine how computers from the Internet will connect to virtual machines.

Существуют различные способы предоставить виртуальным машинам в виртуальной сети доступ к Интернету, который включает доступ из сети организации через прокси-сервер или другое пограничное устройство.There are multiple ways to provide Internet access to the virtual machines on a VNet, which includes access from your organization network through your proxy server or other edge device.

В таблице 5 перечислены способы фильтрации или проверки незапрошенного входящего трафика.Table 5 lists the methods for filtering or inspecting unsolicited incoming traffic.

СпособMethod Модель развертыванияDeployment model
1. Конечные точки и списки управления доступом, настроенные в облачных службах1. Endpoints and ACLs configured on cloud services
КлассическаяClassic
2. Группы безопасности сети2. Network security groups
Классическая с использованием диспетчера ресурсовResource Manager and classic
3. Подсистема балансировки нагрузки для интернет-трафика с правилами NAT для входящего трафика3. Internet-facing load balancer with inbound NAT rules
Руководитель ресурсовResource Manager
4. сетевых устройств безопасности в Azure Marketplace (не отображается)4. Network security appliances in the Azure Marketplace (not shown)
Классическая с использованием диспетчера ресурсовResource Manager and classic

Таблица 5. Способы подключения к виртуальным машинам и соответствующие модели развертывания AzureTable 5: Methods of connecting to virtual machines and their corresponding Azure deployment models

Рис. 7. Подключение к виртуальным машинам Azure через ИнтернетFigure 7: Connecting to Azure virtual machines over the Internet

Рис. 7. Подключение к виртуальным машинам Azure через Интернет

На рисунке 7 показано подключение компьютера с доступом в Интернет к виртуальной машине в облачной службе через конечную точку, к виртуальной машине в подсети с помощью группы безопасности сети, а также к виртуальной машине в подсети с помощью внешней подсистемы балансировки нагрузки и правил NAT для входящего трафика.Figure 7 shows an Internet-connected computer connecting to a virtual machine in a cloud service using an endpoint, a virtual machine on a subnet using a network security group, and a virtual machine on a subnet using an external load balancer and inbound NAT rules.

Дополнительная безопасность обеспечивается за счет следующего:Additional security is provided by:

  • Подключение удаленного рабочего стола и подключение SSH, которые зашифрованы и используют проверку подлинности.Remote Desktop and SSH connections, which are authenticated and encrypted.

  • Сеансы удаленной среды PowerShell, которые зашифрованы и используют проверку подлинности.Remote PowerShell sessions, which are authenticated and encrypted.

  • Режим транспорта IPsec, который можно использовать для сквозного шифрования.IPsec transport mode, which you can use for end-to-end encryption.

  • Защита Azure от атак DDoS, позволяющая предотвратить внешние и внутренние атаки.Azure DDOS protection, which helps prevent external and internal attacks

Для получения дополнительных сведений см Microsoft Cloud для архитекторов корпоративной Безопасности сети Azure.For more information, see Microsoft Cloud Security for Enterprise Architects and Azure Network Security.

Шаг 10. Если имеется несколько виртуальных сетей, определите топологию подключения "виртуальная сеть–виртуальная сеть".Step 10: For multiple VNets, determine the VNet-to-VNet connection topology.

Виртуальные сети можно подключать между собой, используя для этого такие же топологии, что и для подключения сайтов организации.VNets can be connected to each other using topologies similar to those used for connecting the sites of an organization.

Гирляндная конфигурация подразумевает последовательное подключение виртуальных сетей.A daisy chain configuration connects the VNets in a series.

Рис. 8. Конфигурация с последовательным подключением виртуальных сетейFigure 8: A daisy-chained configuration for VNets

Рис. 8. Последовательная конфигурация для виртуальных сетей Azure

На рисунке 8 показана пять VNets подключен последовательно с помощью конфигурации последовательно.Figure 8 shows five VNets connected in series using a daisy-chained configuration.

Звездообразная конфигурация подразумевает подключение нескольких виртуальных сетей к ряду центральных виртуальных сетей, соединенных между собой.A spoke and hub configuration connects multiple VNets to a set of central VNets, which are themselves connected to each other.

Рис. 9. Звездообразная конфигурация виртуальных сетейFigure 9: A spoke and hub configuration for VNets

Рис. 9. Звездообразная конфигурация и конфигурация с концентратором для виртуальных сетей Azure

На рисунке 9 показаны шесть виртуальных сетей, где две из которых являются центральными сетями, соединенными между собой, а остальные виртуальные сети подключены к этим центральным сетям.Figure 9 shows six VNets, two VNets are hubs that are connected to each other and also two other spoke VNets.

В конфигурации полной сетки все виртуальные сети соединены непосредственно друг с другом.A full mesh configuration connects every VNet to each other.

Рис. 10. Конфигурация полной сетки для виртуальных сетейFigure 10: A full mesh configuration for VNets

Рис. 10. Сеточная конфигурация для виртуальных сетей Azure

На рисунке 10 показаны четыре виртуальные сети, которые подключены непосредственно друг к другу с помощью шести подключений типа "виртуальная сеть–виртуальная сеть".Figure 10 shows four VNets that are all connected to each other, using a total of six VNet-to-VNet connections.

Этапы планирования для распределенной виртуальной сетиPlanning steps for a cross-premises VNet

Ниже перечислены шаги, которыми следует руководствоваться при планировании распределенной виртуальной сети.Follow these steps for a cross-premises VNet.

Совет

Сведения о том, как создать имитацию гибридной среды разработки и тестирования в Azure, см. в статье Simulated cross-premises virtual network in Azure.To create a simulated cross-premises dev/test environment, see Simulated cross-premises virtual network in Azure.

Шаг 1. Определите тип подключения к распределенной виртуальной сети (подключение VPN типа "сеть–сеть" или ExpressRoute).Step 1: Determine the cross-premises connection to the VNet (S2S VPN or ExpressRoute).

В таблице 6 перечислены различные типы подключений.Table 6 lists the different types of connections.

Тип подключенияType of connection НазначениеPurpose
VPN типа "сеть–сеть"Site-to-Site (S2S) VPN
Подключение сайтов 1-10 (в том числе других VNets) к одной VNet.Connect 1-10 sites (including other VNets) to a single VNet.
ExpressRouteExpressRoute
Закрытое, защищенное подключение к Azure через поставщика услуг обмена интернет-трафиком (IXP) или поставщика сетевых услуг (NSP).A private, secure link to Azure via an Internet Exchange Provider (IXP) or a Network Service Provider (NSP).
Подключение VPN типа "точка–сеть"Point-to-Site (P2S) VPN
Подключение отдельного компьютера к виртуальной сети.Connects a single computer to a VNet.
Пиринговая виртуальная сеть или VNet-to-VNet (V2V) VPN VNet peering or VNet-to-VNet (V2V) VPN
Подключение одной виртуальной сети к другой.Connects a VNet to another VNet.

Таблица 6. Типы подключений для распределенных виртуальных сетейTable 6: The types of connections for cross-premises VNets

Дополнительные сведения о максимальное число подключений содержатся в разделе Ограничения для сети.For more information on the maximum number of connections, see Networking Limits.

Дополнительные сведения о VPN-устройства можно VPN-устройства для подключения к веб сайта виртуальной сети.For more information about VPN devices, see VPN devices for site-to-site virtual network connections.

Дополнительные сведения о VNet авторами можно VNet авторами.For more information about VNet peering, see VNet peering.

Рис. 11. Четыре способа подключения к распределенной виртуальной сетиFigure 11: The four ways to connect to a cross-premises VNet

Рис. 11. Три способа подключения к распределенной виртуальной сети Azure

На рисунке 11 показаны VNet с четырьмя типами подключений: подключение P2S с компьютера, подключение к виртуальной частной сети S2S из локальной сети, подключения к ExpressRoute из локальной сети и VNet-VNet подключения из другой VNet.Figure 11 shows a VNet with the four types of connections: a P2S connection from a computer, an S2S VPN connection from an on-premises network, an ExpressRoute connection from an on-premises network, and a VNet-to-VNet connection from another VNet.

Подключиться к виртуальным машинам в виртуальной сети можно следующими способами:You can connect to VMs in a VNet in the following ways:

  • Администрирование виртуальных машин в виртуальной сети из локальной сети или через ИнтернетAdministration of VNet VMs from your on-premises network or the Internet

  • Доступ к рабочей ИТ-нагрузке из локальной сетиIT workload access from your on-premises network

  • Расширение сети с помощью дополнительных виртуальных сетейExtension of your network through additional VNets

Безопасность подключений обеспечивается за счет следующего:Security for connections is provided by the following:

  • Для подключения типа "точка–сеть" используется протокол Secure Socket Tunneling Protocol (SSTP) P2S uses the Secure Socket Tunneling Protocol (SSTP)

  • Для подключений VPN типа "сеть–сеть" и "виртуальная сеть–виртуальная сеть" используется туннельный режим IPsec с шифрованием AES256S2S and VNet-to-VNet VPN connections use IPsec tunnel mode with AES256

  • ExpressRoute представляет собой частное подключение WANExpressRoute is a private WAN connection

Для получения дополнительных сведений см Microsoft Cloud для архитекторов корпоративной Безопасности сети Azure.For more information, see Microsoft Cloud Security for Enterprise Architects and Azure Network Security.

Шаг 2. Определите локальное VPN-устройство или маршрутизатор.Step 2: Determine the on-premises VPN device or router.

Локальное VPN-устройство или маршрутизатор выступает в качестве:Your on-premises VPN device or router acts as:

  • оконечного узла IPsec подключения VPN типа "сеть–сеть" от шлюза Azure;An IPsec peer, terminating the S2S VPN connection from the Azure gateway.

  • узла BPG и оконечной точки для частного пирингового подключения ExpressRoute.The BPG peer and termination point for the private peering ExpressRoute connection.

Рис. 12. Локальный маршрутизатор или устройство VPNFigure 12: The on-premises VPN router or device

Рис. 12. Локальный маршрутизатор или устройство VPN

На рисунке 12 показана распределенная виртуальная сеть, подключенная к локальному VPN-устройству или маршрутизатору.Figure 12 shows a cross-premises VNet connected to an on-premises VPN router or device.

Для получения дополнительных сведений см шлюза о VPN.For more information, see About VPN gateway.

Шаг 3: Добавление маршрутов для интрасети, чтобы сделать доступным адресное пространство VNet.Step 3: Add routes to your intranet to make the address space of the VNet reachable.

Маршрут к виртуальной сети из локальной сети включает следующее:Routing to VNets from on-premises consists of the following:

  1. Маршрут для адресного пространства виртуальной сети до вашего VPN-устройства.A route for the VNet address space that points toward your VPN device.

  2. Маршрут для адресного пространства виртуальной сети на VPN-устройстве до подключения VPN типа "сеть–сеть"или подключения ExpressRoute.A route for the VNet address space on your VPN device that points across the S2S VPN or ExpressRoute connection

Рис. 13. Локальные маршруты, необходимые для того, чтобы сделать виртуальную сеть доступнойFigure 13: The on-premises routes needed to make a VNet reachable

Рис. 13. Локальные маршруты, необходимые для обеспечения доступности виртуальной сети Azure

На рисунке 13 показаны сведения о маршрутах, необходимые локальным маршрутизаторам и VPN-устройству или маршрутизатору, представляющему адресное пространство виртуальной сети.Figure 13 shows the routing information needed by the on-premises routers and the VPN router or device that represents the address space of the VNet.

Шаг 4. Если используется подключение ExpressRoute, спланируйте новое подключение вместе со своим поставщиком.Step 4: For ExpressRoute, plan for the new connection with your provider.

Создать частное пиринговое соединение ExpressRoute между локальной сетью и облаком Майкрософт можно тремя различными способами:You can create an ExpressRoute connection with private peering between your on-premises network and the Microsoft cloud in three different ways:

  • Совместное размещение в облачном обменникеCo-located at a cloud exchange

  • Подключение типа "точка-точка" через EthernetPoint-to-point Ethernet connections

  • Подключение типа "любой-к-любому" (IP-VPN)Any-to-any (IP VPN) networks

Рис. 14. Использование ExpressRoute для подключения к распределенной виртуальной сетиFigure 14: Using ExpressRoute to connect to a cross-premises VNet

Рис. 14. Подключение к распределенной виртуальной сети Azure с помощью ExpressRoute

На рисунке 14 показана распределенная виртуальная сеть и подключение ExpressRoute от локального маршрутизатора к Microsoft Azure.Figure 14 shows a cross-premises VNet and an ExpressRoute connection from an on-premises router to Microsoft Azure.

Дополнительные сведения см. в статье ExpressRoute для подключения к Microsoft Cloud.For more information, see ExpressRoute for Microsoft cloud connectivity.

Шаг 5. Определите адресное пространство локальной сети для шлюза Azure.Step 5: Determine the Local Network address space for the Azure gateway.

Для маршрутизации трафика в локальную сеть или другие виртуальные сети Azure переадресовывает его через шлюз Azure, соответствующий адресному пространству локальной сети, которое назначено шлюзу.For the routing to on-premises or other VNets from a VNet, Azure forwards traffic across an Azure gateway that matches the Local Network address space assigned to the gateway.

Рис. 15. Адресное пространство локальной сети для распределенной виртуальной сетиFigure 15: The Local Network address space for a cross-premises VNet

Рис. 15. Адресное пространство локальной сети для распределенной виртуальной сети Azure

На рисунке 15 показаны распределенная виртуальная сеть и адресное пространство локальной сети на шлюзе Azure, которое представляет собой достижимое адресное пространство локальной сети. Figure 15 shows a cross-premises VNet and the Local Network address space on the Azure gateway, which represents the reachable address space on the on-premises network.

Ниже перечислены способы определения адресного пространства локальной сети.You can define the Local Network address space in the following ways:

  • Способ 1. Создание списка префиксов адресного пространства, которые требуются или используются (этот список необходимо обновлять при добавлении новых подсетей).Option 1: The list of prefixes for the address space currently needed or in use (updates might be needed when you add new subnets).

  • Способ 2. Использование всего адресного пространства локальной сети (этот список необходимо обновлять только при добавлении нового адресного пространства).Option 2: Your entire on-premises address space (updates only needed when you add new address space).

Поскольку шлюз Azure не поддерживает суммированные маршруты, необходимо определить адресное пространство локальной сети для способа 2, исключив из него адресное пространство виртуальной сети.Because the Azure gateway does not allow summarized routes, you must define the Local Network address space for option 2 so that it does not include the VNet address space.

Рис. 16. Пробел в адресном пространстве, созданный адресным пространством виртуальной сетиFigure 16: The address space hole created by the VNet address space

Рис. 16. Пробел в адресном пространстве, созданный адресным пространством виртуальной сети

На рисунке 16 представлено адресное пространство с корневым пространством и адресным пространством виртуальной сети.Figure 16 shows a representation of an address space, with the root space and the VNet address space.

Ниже приведен пример определения префиксы для локальной сети адресного пространства вокруг адресное пространство «дыра», созданный с VNet:Here is an example of defining the prefixes for the Local Network address space around the address space "hole" created by the VNet:

  • Организация использует фрагменты частного адресного пространства (10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16) в своей локальной сети. Был выбран способ 2, а в качестве адресного пространства виртуальной сети — пространство 10.100.100.0/24.An organization uses portions of the private address space (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16) across their on-premises network. They chose option 2 and 10.100.100.0/24 as their VNet address space.

В таблице 7 представлены действия и полученные в их результате префиксы, определяющие адресное пространство локальной сети для этого примера.Table 7 shows the steps and resulting prefixes that define the Local Network address space for this example.

ШагStep РезультатыResults
1. Создание списка префиксов, которые отсутствуют в корневом пространстве, для адресного пространства виртуальной сети.1. List the prefixes that are not the root space for the VNet address space.
172.16.0.0/12 и 192.168.0.0/16172.16.0.0/12 and 192.168.0.0/16
2. список префиксов без перекрытия для переменной октетов до, но не включая последний использованный октета в VNet адресного пространства.2. List the non-overlapping prefixes for variable octets up to but not including the last used octet in the VNet address space.
10.0.0.0/16, 10.1.0.0/16... 10.99.0.0/16, 10.101.0.0/16... 10.254.0.0/16 10.255.0.0/16 (255 префиксов, пропуск 10.100.0.0/16)10.0.0.0/16, 10.1.0.0/16…10.99.0.0/16, 10.101.0.0/16…10.254.0.0/16, 10.255.0.0/16 (255 prefixes, skipping 10.100.0.0/16)
3. список префиксы без перекрытия в последний использованный октета VNet адресного пространства.3. List the non-overlapping prefixes within the last used octet of the VNet address space.
10.100.0.0/24, 10.100.1.0/24... 10.100.99.0/24, 10.100.101.0/24... 10.100.254.0/24 10.100.0.255.0/24 (255 префиксов, пропуск 10.100.100.0/24)10.100.0.0/24, 10.100.1.0/24…10.100.99.0/24, 10.100.101.0/24…10.100.254.0/24, 10.100.0.255.0/24 (255 prefixes, skipping 10.100.100.0/24)

Таблица 7. Пример сетевого пространства локальных адресовTable 7: Example Local Address network space

Шаг 6. Настройте локальные DNS-серверы на репликацию DNS с помощью DNS-серверов, размещенных в Azure.Step 6: Configure on-premises DNS servers for DNS replication with DNS servers hosted in Azure.

Чтобы локальные компьютеры могли разрешать имена серверов, размещенных в Azure, а последние могли разрешать имена локальных компьютеров, настройте следующее:To ensure that on-premises computers can resolve the names of Azure-based servers and Azure-based servers can resolve the names of on-premises computers, configure:

  • DNS-серверы в вашей виртуальной сети на переадресацию на локальные DNS-серверы;The DNS servers in your VNet to forward to on-premises DNS servers

  • репликацию DNS для соответствующих зон между DNS-серверами локальной и виртуальной сетей.DNS replication of the appropriate zones between DNS servers on-premises and in the VNet

Рис. 17. Репликация и переадресация DNS для DNS-сервера в распределенной виртуальной сетиFigure 17: DNS replication and forwarding for a DNS server in a cross-premises VNet

Рис.17. Репликация и переадресация DNS для DNS-сервера в распределенной виртуальной сети Azure

На рисунке 17 показана распределенная виртуальная сеть с DNS-серверами в локальной сети и подсети в виртуальной сети. Между этими двумя DNS-серверами настроены репликация и переадресация DNS.Figure 17 shows a cross-premises VNet with DNS servers in the on-premises network and on a subnet in the VNet. DNS replication and forwarding has been configured between the two DNS servers.

Шаг 7. Определите использование принудительного туннелирования.Step 7: Determine the use of forced tunneling.

Указывает маршрут системы по умолчанию для Azure подсетей в Интернет. Чтобы убедиться, что все из виртуальных машин проходит через подключение между организациями, создайте таблицу маршрутизации с маршрутом по умолчанию, использующий Azure шлюза в качестве его адрес следующего прыжка. В таблице Маршрут затем свяжите с подсетью. Это называется Принудительное туннелирование. Дополнительные сведения можно настроить Принудительное туннелирование.The default system route for Azure subnets points to the Internet. To ensure that all traffic from virtual machines travels across the cross-premises connection, create a routing table with the default route that uses the Azure gateway as its next-hop address. You then associate the route table with the subnet. This is known as forced tunneling. For more information, see Configure forced tunneling.

Рис. 18. Пользовательские маршруты и принудительное туннелирование для распределенной виртуальной сетиFigure 18: User-defined routes and forced tunneling for a cross-premises VNet

Рис. 18. Пользовательские маршруты и принудительное туннелирование для распределенной виртуальной сети Azure

На рисунке 18 показан VNet между организациями с помощью пользовательских маршрут к подсети с указанием Azure шлюза.Figure 18 shows a cross-premises VNet with a user-defined route for a subnet pointing to the Azure gateway.

Ферма SharePoint Server 2016 в AzureSharePoint Server 2016 farm in Azure

Пример интрасети рабочей нагрузки ИТ, размещенные в Azure IaaS — в ферме SharePoint Server 2016 высокой доступностью, многоуровневые.An example of an intranet IT workload hosted in Azure IaaS is a highly-available, multi-tier SharePoint Server 2016 farm.

Рисунок 19. Высокодоступная ферма SharePoint Server 2016 в интрасети в Azure IaaSFigure 19: A highly-available intranet SharePoint Server 2016 farm in Azure IaaS

Высокодоступная ферма SharePoint Server 2016 в Azure IaaS

На рисунке 19 показан девяти серверов SharePoint Server 2016 фермы, развернутой в VNet между организациями, поддерживающей подсистемы балансировки нагрузки внутренних уровни переднего плана и данных. Дополнительные сведения, включая пошаговые проектирования и инструкции по развертыванию можно 2016 сервера SharePoint в Microsoft Azure.Figure 19 shows the nine servers of a SharePoint Server 2016 farm deployed in a cross-premises VNet that uses internal load balancers for the front-end and data tiers. For more information, including step-by-step design and deployment instructions, see SharePoint Server 2016 in Microsoft Azure.

Совет

Создание фермы SharePoint Server 2016 одним сервером в VNet имитации между организациями, видеть интрасети 2016 сервера SharePoint в среде Azure разработку и тестирование.To create a single-server SharePoint Server 2016 farm in a simulated cross-premises VNet, see Intranet SharePoint Server 2016 in Azure dev/test environment.

Дополнительные примеры рабочих нагрузок ИТ, развернутых на виртуальных машинах в виртуальной среде Azure распределенной сети гибридных сценариев облака для Azure IaaSсм.For additional examples of IT workloads deployed on virtual machines in a cross-premises Azure virtual network, see Hybrid cloud scenarios for Azure IaaS.

См. такжеSee also

Облачные сети Майкрософт для корпоративных архитекторовMicrosoft Cloud Networking for Enterprise Architects

Ресурсы для администраторов, посвященные архитектуре Microsoft CloudMicrosoft Cloud IT architecture resources

Стратегия Enterprise Cloud корпорации Майкрософт: ресурсы для лиц, принимающих решения в области ИТMicrosoft's Enterprise Cloud Roadmap: Resources for IT Decision Makers