Azure Virtual Network часто задаваемые вопросы (FAQ)

Основные сведения

Что такое виртуальная сеть?

Виртуальная сеть представляет собственную сеть в облаке, как предоставляется службой Azure Virtual Network. Виртуальная сеть — это логическая изоляция облака Azure, выделенного для вашей подписки.

Виртуальные сети можно использовать для подготовки виртуальных частных сетей (VPN) и управления ими в Azure. При необходимости можно связать виртуальные сети с другими виртуальными сетями в Azure или локальной ИТ-инфраструктурой, чтобы создать гибридные или кросс-локальные решения.

Каждая виртуальная сеть, которую вы создаёте, имеет свой собственный блок Classless Inter-Domain Routing (CIDR). Вы можете связать виртуальную сеть с другими виртуальными сетями и локальными сетями, если блоки CIDR не пересекаются. Вы также можете контролировать параметры DNS-сервера для виртуальных сетей, а также сегментацию виртуальной сети в подсети.

Использование виртуальных сетей для:

• Создайте выделенную, частную, облачную виртуальную сеть. Иногда для вашего решения не нужна распределенная конфигурация. При создании виртуальной сети службы и виртуальные машины в виртуальной сети могут взаимодействовать напрямую и безопасно друг с другом в облаке. Вы по-прежнему можете настроить подключения к конечным точкам для виртуальных машин и служб, которым требуется подключение к Интернету, как часть вашего решения.

• Безопасно расширяйте центр обработки данных. С помощью виртуальных сетей можно создавать традиционные VPN от сайта к сайту (S2S) для безопасного расширения возможностей центра обработки данных. Виртуальные сети S2S используют IPsec для обеспечения безопасного подключения между корпоративным VPN-шлюзом и Azure.

• Включите сценарии гибридного облака. Вы можете безопасно подключить облачные приложения к любому типу локальной системы, включая мейнфреймы и системы Unix.

Как начать работу?

Ознакомьтесь с документацией Azure Virtual Network, чтобы приступить к работе. Это содержимое содержит общие сведения и сведения о развертывании для всех функций виртуальной сети.

Можно ли использовать виртуальные сети без подключения между локальными сетями?

Да. Виртуальную сеть можно использовать без подключения к локальной среде. Например, можно запускать Microsoft Windows Server Active Directory контроллеры домена и фермы SharePoint исключительно в виртуальной сети Azure.

Можно ли выполнять оптимизацию глобальной сети между виртуальными сетями или между виртуальной сетью и локальным центром обработки данных?

Да. Вы можете развернуть виртуальное устройство network для оптимизации глобальной сети от нескольких поставщиков через Azure Marketplace.

Настройка

Какие средства используются для создания виртуальной сети?

Для создания или настройки виртуальной сети можно использовать указанные ниже средства.

• Портал Azure.
• PowerShell.
• Azure CLI.
• Сетевой конфигурационный файл (netcfg, только для классических виртуальных сетей).

Какие диапазоны адресов можно использовать в виртуальных сетях?

Рекомендуется использовать следующие диапазоны адресов, которые перечисляются в RFC 1918. Рабочая группа по интернет-инженерии (IETF) выделила эти диапазоны для частных, немаршрутизируемых адресных пространств.

• 10.0.0.0 до 10.255.255.255 (префикс 10/8).
• 172.16.0.0 до 172.31.255.255 (префикс 172.16/12).
• 192.168.0.0 до 192.168.255.255 (префикс 192.168/16).

Вы также можете развернуть общее адресное пространство, зарезервированное в RFC 6598, которое рассматривается как частное пространство IP-адресов в Azure:

• 100.64.0.0 до 100.127.255.255 (префикс 100.64/10).

Другие адресные пространства, включая все другие утвержденные IETF частные, не маршрутизируемые адресные пространства, могут работать, но имеют нежелательные побочные эффекты.

Кроме того, нельзя добавить следующие диапазоны адресов:

• 224.0.0.0/4 (мультикаст).
• 255.255.255.255/32 (вещание).
• 127.0.0.0/8 (обратная петля).
• 169.254.0.0/16 (местная ссылка).
• 168.63.129.16/32 (внутренний DNS).

Можно ли использовать общедоступные IP-адреса в виртуальных сетях?

Да. Дополнительные сведения о диапазонах общедоступных IP-адресов см. в статье "Создание виртуальной сети". Общедоступные IP-адреса не доступны непосредственно из Интернета.

Существует ли ограничение на количество подсетей в виртуальной сети?

Да. Дополнительные сведения см. в разделе "Ограничения сети ". Адресные пространства подсети не могут перекрываться друг с другом.

Существуют ли ограничения на использование IP-адресов в пределах этих подсетей?

Да. Azure резервирует первые четыре адреса и последний адрес в общей сложности пять IP-адресов в каждой подсети.

Например, диапазон IP-адресов 192.168.1.0/24 имеет следующие зарезервированные адреса:

• 192.168.1.0: сетевой адрес.
• 192.168.1.1: зарезервировано Azure для шлюза по умолчанию.
• 192.168.1.2, 192.168.1.3: зарезервировано Azure для сопоставления Azure DNS IP-адресов с пространством виртуальной сети.
• 192.168.1.255: адрес сетевой трансляции.

Насколько маленькими и насколько большими могут быть виртуальные сети и подсети?

Минимальный размер подсети для протокола IPv4 равен /29, максимальный — /2 (согласно определениям подсети CIDR). Размер подсетей для протокола IPv6 должен составлять в точности /64.

Можно ли перенести виртуальные локальные сети в Azure с помощью виртуальных сетей?

№ Виртуальные сети — это наложения уровня 3. Azure не поддерживает семантику уровня 2.

Можно ли указать пользовательские политики маршрутизации в виртуальных сетях и подсетях?

Да. Вы можете создать таблицу маршрутов и связать ее с подсетью. Дополнительные сведения о маршрутизации в Azure см. в разделе Custom routes.

Каково поведение, когда я применяю как NSG, так и UDR к подсети?

Для входящего трафика обрабатываются правила группы безопасности сети (NSG). Для исходящего трафика обрабатываются правила исходящего трафика NSG, за которыми следует правила определяемого пользователем маршрута (UDR).

Что такое поведение при применении группы безопасности сети в сетевой сети и подсети для виртуальной машины?

При применении сетевых групп безопасности на сетевом адаптере (NIC) и подсети виртуальной машины (VM):

• Сначала обрабатывается сетевой экран NSG на уровне подсети, затем на уровне сетевого адаптера для входящего трафика.
• Сначала обрабатывается NSG на уровне сетевого адаптера, затем NSG на уровне подсети для исходящего трафика.

Поддерживают ли виртуальные сети многоадресную или широковещательную рассылку?

№ Многоадресная и широковещательная рассылка не поддерживаются.

Какие протоколы можно использовать в виртуальных сетях?

В виртуальных сетях можно использовать протоколы TCP, UDP, ESP, AH и ICMP TCP/IP.

Юникаст поддерживается на виртуальных сетях. Многоадресная рассылка, широковещательная передача, инкапсулированные пакеты IP-внутри-IP и пакеты инкапсуляции с общей маршрутизацией (GRE) блокируются в виртуальных сетях. Нельзя использовать протокол динамической конфигурации хоста (DHCP), используя unicast (исходный порт UDP/68, порт назначения UDP/67). Порты UDP 4791 и 65330 зарезервированы для хоста.

Можно ли развернуть DHCP-сервер в виртуальной сети?

Azure виртуальные сети предоставляют DHCP-сервис и DNS для виртуальных машин Azure. Однако вы также можете развернуть DHCP-сервер в Azure VM для обслуживания локальных клиентов через агент DHCP реле.

DHCP-серверы в Azure ранее были невозможны, поскольку трафик на порт UDP/67 был ограничен по скорости в Azure. Однако недавние обновления платформы убрали ограничение скорости и включили эту возможность.

Можно ли пинговать дефолтный шлюз в виртуальной сети?

№ Шлюз по умолчанию, предоставляемый Azure, не отвечает на запрос ping. Но вы можете использовать проверки связи в виртуальных сетях для проверки подключения и устранения неполадок между виртуальными машинами.

Можно ли использовать команду tracert для диагностики подключения?

Да.

Можно ли добавить подсети после создания виртуальной сети?

Да. Вы можете добавлять подсети в виртуальные сети в любое время, если оба из этих условий существуют:

• Диапазон адресов подсети не является частью другой подсети.
• В диапазоне адресов виртуальной сети доступно место.

Можно ли изменить размер подсети после ее создания?

Да. Вы можете добавить, удалить, развернуть или уменьшить подсеть, если в ней нет виртуальных машин или служб.

Можно ли изменить виртуальную сеть после ее создания?

Да. Вы можете добавлять, удалять и изменять блоки CIDR, которые использует виртуальная сеть.

Если я выполняю свои службы в виртуальной сети, можно ли подключиться к Интернету?

Да. Все службы, развернутые в виртуальной сети, могут подключаться к Интернету. Дополнительные сведения об исходящих подключениях к Интернету в Azure см. в разделе Использование преобразования адресов источника (SNAT) для исходящих подключений.

Если вы хотите подключиться к ресурсу, развернутму через Azure Resource Manager, ресурсу должен быть назначен общедоступный IP-адрес. Дополнительные сведения см. в разделе Создание, изменение или удаление общедоступного IP-адреса Azure.

Каждая облачная служба, развернутая в Azure, имеет общедоступный виртуальный IP-адрес (VIP), назначенный ей. Вы определяете входные конечные точки для ролей и конечных точек платформы как службы (PaaS) для виртуальных машин, чтобы эти службы могли принимать подключения из Интернета.

Поддерживают ли виртуальные сети IPv6?

Да. Виртуальные сети могут быть только IPv4 или двойной стек (IPv4 + IPv6). Дополнительные сведения см. в разделе Что такое IPv6 для Azure Virtual Network?

Может ли диапазон виртуальных сетей охватывать регионы?

№ Виртуальная сеть ограничена одним регионом. Но виртуальная сеть охватывает зоны доступности. Дополнительные сведения о зонах доступности см. в статье Что такое регионы и зоны доступности Azure?

Виртуальные сети можно подключить в разных регионах с помощью пиринга виртуальных сетей. Дополнительные сведения см. в разделе Пиринг виртуальных сетей.

Можно ли подключить виртуальную сеть к другой виртуальной сети в Azure?

Да. Вы можете подключить одну виртуальную сеть к другой виртуальной сети с помощью следующего:

• Пиринг между виртуальными сетями. Дополнительные сведения см. в разделе Пиринг виртуальных сетей.
• VPN-шлюз Azure. Дополнительные сведения см. в разделе "Настройка сетевого VPN-шлюза".

Разрешение имен (DNS)

Каковы параметры DNS для виртуальных сетей?

Используйте таблицу решений в разрешении имен для ресурсов в виртуальных сетях Azure, чтобы изучить доступные параметры DNS.

Можно ли указать DNS-серверы для виртуальной сети?

Да. Ip-адреса для DNS-серверов можно указать в параметрах виртуальной сети. Этот параметр применяется как DNS-сервер по умолчанию или серверы для всех виртуальных машин в виртуальной сети.

Сколько DNS-серверов можно указать?

См. ограничения сети.

Можно ли изменить DNS-серверы после создания сети?

Да. Список DNS-серверов для виртуальной сети можно изменить в любое время.

При изменении списка DNS-серверов необходимо выполнить продление аренды DHCP на всех затронутых виртуальных машинах в виртуальной сети. Новые параметры DNS вступают в силу после продления аренды. Для виртуальных машин, работающих Windows, вы можете продлить аренду, введя ipconfig /renew непосредственно на виртуальной машине. Сведения о других типах ОС см. в документации по продлению аренды DHCP.

Что такое dns с Azure и работает ли он с виртуальными сетями?

Azure dns — это мультитенантная служба DNS из Microsoft. Azure регистрирует все виртуальные машины и роли облачных служб в этой службе. Эта служба предоставляет разрешение имен:

• По имени хоста для виртуальных машин и экземпляров ролей в одной облачной службе.
• Полное доменное имя (FQDN) для виртуальных машин и экземпляров ролей в пределах одной виртуальной сети.

Дополнительную информацию о DNS можно найти в статье Name resolution for resources in Azure virtual networks.

Существует ограничение на первые 100 облачных служб в виртуальной сети для разрешения имен между арендаторами через DNS, предоставляемые Azure. Если вы используете собственный DNS-сервер, это ограничение не применяется.

Можно ли переопределить параметры DNS для каждой виртуальной машины или облачной службы?

Да. Dns-серверы для каждой виртуальной машины или облачной службы можно задать для переопределения параметров сети по умолчанию. Тем не менее, мы рекомендуем максимально широко использовать DNS уровня сети.

Можно ли использовать собственный суффикс DNS?

№ Вы не можете указать настраиваемый DNS-суффикс для виртуальных сетей.

Подключение виртуальных машин

Можно ли развернуть виртуальные машины в виртуальной сети?

Да. Все сетевые адаптеры ,подключенные к виртуальной машине, развернутой с помощью модели развертывания Resource Manager, должны быть подключены к виртуальной сети. При необходимости можно подключить виртуальные машины, развернутые с помощью классической модели развертывания, к виртуальной сети.

Какие типы IP-адресов можно назначить виртуальным машинам?

• Частный: назначается каждому сетевому адаптеру в каждой виртуальной машине через статический или динамический метод. Частные IP-адреса назначаются из диапазона, указанного в параметрах подсети виртуальной сети.

  Ресурсы, развернутые с помощью классической модели развертывания, назначаются частные IP-адреса, даже если они не подключены к виртуальной сети. Поведение метода выделения отличается в зависимости от того, развернут ли ресурс с помощью Resource Manager или классической модели развертывания:

  • Resource Manager: частный IP-адрес, назначенный динамическим или статическим методом, остается назначенным виртуальной машине (Resource Manager), пока ресурс не будет удален. Разница в том, что при использовании статического метода вы выбираете адрес для назначения, а при использовании динамического метода выбор делает Azure.
  • Классическая модель. Частный IP-адрес, назначенный динамическим методом, может измениться при перезапуске виртуальной машины (классической) после того, как он находится в остановленном (освобожденном) состоянии. Если необходимо убедиться, что частный IP-адрес для ресурса, развернутого с помощью классической модели развертывания, никогда не изменяется, назначьте частный IP-адрес с помощью статического метода.

• Public: при необходимости назначается сетевым адаптерам, подключенным к виртуальным машинам, развернутыми с помощью модели развертывания Resource Manager. Адрес можно назначить с помощью статического или динамического метода распределения.

  Все виртуальные машины и экземпляры ролей в Azure Cloud Services, развернутые в классической модели развертывания, существуют в облачной службе. Облачной службе назначается динамический общедоступный VIP-адрес. При необходимости можно назначить общедоступный статический IP-адрес, называемый зарезервированным IP-адресом, в качестве VIP.

  Общедоступные IP-адреса можно назначать отдельным виртуальным машинам или экземплярам ролей облачных служб, развернутым по классической модели. Эти адреса называются общедоступными IP-адресами уровня экземпляра и могут быть динамически назначены.

Можно ли зарезервировать частный IP-адрес для виртуальной машины, которую я создаю позже?

№ Вы не можете зарезервировать частный IP-адрес. Если доступен частный IP-адрес, DHCP-сервер назначает его экземпляру виртуальной машины или роли. Виртуальная машина может быть или не может быть той, которой вы хотите назначить частный IP-адрес. Однако можно изменить частный IP-адрес существующей виртуальной машины на любой доступный частный IP-адрес.

Изменяются ли частные IP-адреса для виртуальных машин в виртуальной сети?

Это зависит от ряда обстоятельств. Если вы развернули виртуальную машину с помощью Resource Manager, IP-адреса не могут изменяться независимо от того, назначены ли адреса с помощью статического или динамического метода выделения. Если вы развернули виртуальную машину с помощью классической модели развертывания, динамические IP-адреса могут измениться при запуске виртуальной машины, которая находилась в остановленном (освобожденном) состоянии.

Адрес освобождается после удаления виртуальной машины, развернутой через любую модель развертывания.

Можно ли вручную назначать IP-адреса для сетевых адаптеров в операционной системе виртуальной машины?

Да, но мы не рекомендуем его, если это не необходимо, например при назначении нескольких IP-адресов виртуальной машине. Дополнительные сведения см. в разделе "Назначение нескольких IP-адресов виртуальным машинам".

Если IP-адрес, назначенный сетевому адаптеру Azure, подключенному к виртуальной машине, изменяется, а IP-адрес в операционной системе виртуальной машины отличается, вы теряете подключение к виртуальной машине.

Если я остановлю слот развертывания облачной службы или выключим виртуальную машину из операционной системы, что происходит с IP-адресами?

Ничего. IP-адреса (общедоступные IP-адреса, общедоступные и частные) остаются назначенными слоту развертывания облачной службы или виртуальной машине.

Можно ли переместить виртуальные машины из одной подсети в другую подсеть в виртуальной сети без повторного развертывания?

Да. Дополнительные сведения см. в разделе "Перемещение виртуальной машины или экземпляра роли" в другую подсеть.

Можно ли настроить статический MAC-адрес для виртуальной машины?

№ Вы не можете статически настроить MAC-адрес.

Остается ли MAC-адрес прежним для моей виртуальной машины после его создания?

Да. MAC-адрес остается неизменным для виртуальной машины, развернутой с помощью Resource Manager и классических моделей развертывания, пока не удалите его.

Ранее MAC-адрес был выпущен при остановке (освобождении) виртуальной машины. Но теперь виртуальная машина сохраняет MAC-адрес, когда он находится в освобожденном состоянии. MAC-адрес остается назначенным сетевому адаптеру, пока не выполните одну из следующих задач:

• Удалите сетевой адаптер.
• Измените частный IP-адрес, назначенный основной IP-конфигурации основного сетевого адаптера.

службы Azure, которые подключаются к виртуальным сетям

Можно ли использовать веб-приложения с виртуальной сетью?

Да. Вы можете развернуть компонент веб-приложения в составе Служба приложений Azure в виртуальной сети, используя Среда службы приложений. Затем можно:

• Подключите внутренние части приложений к виртуальным сетям с помощью интеграции виртуальной сети.
• Блокировка входящего трафика в приложение с помощью конечных точек службы.

Дополнительные сведения см. в следующих статьях:

• Сетевые функции App Service.
• Используйте Среда службы приложений.
• Интеграция приложения с виртуальной сетью Azure.
• Настройте ограничения доступа в Служба приложений Azure.

Можно ли развернуть Облачные службы с веб-ролями и рабочими ролями (PaaS) в виртуальной сети?

Да. Вы можете при желании развертывать экземпляры ролей облачных служб в виртуальных сетях. Для этого необходимо указать имя виртуальной сети и сопоставления ролей и подсетей в разделе конфигурации сети службы. Вам не нужно обновлять двоичные файлы.

Могу ли я подключить масштабируемый набор виртуальных машин к виртуальной сети?

Да. Необходимо подключить масштабируемый набор виртуальных машин к виртуальной сети.

Существует ли полный список служб Azure, из которых я могу развернуть ресурсы в виртуальную сеть?

Да. Дополнительные сведения см. в разделе Развертывание выделенных служб Azure в виртуальных сетях.

Как ограничить доступ к ресурсам PaaS Azure из виртуальной сети?

Ресурсы, развернутые через некоторые службы PaaS (например Azure, служба хранилища Azure и База данных SQL Azure), могут ограничить доступ к виртуальным сетям через использование конечных точек службы виртуальной сети или Приватный канал Azure. Дополнительные сведения см. в разделах Конечные точки службы виртуальной сети и Что такое Приватный канал Azure?

Можно ли переместить службы в виртуальные сети и выйти из нее?

№ Вы не можете перемещать службы в виртуальные сети и из них. Чтобы переместить ресурс в другую виртуальную сеть, необходимо удалить и повторно развернуть ресурс.

Безопасность

Что такое модель безопасности для виртуальных сетей?

Виртуальные сети изолированы друг от друга и от других служб, размещенных в инфраструктуре Azure. Виртуальная сеть — это граница доверия.

Можно ли ограничить входящий или исходящий поток трафика ресурсами, подключенными к виртуальной сети?

Да. Группы безопасности сети можно применить к отдельным подсетям в виртуальной сети, сетевым адаптерам, подключенным к виртуальной сети или к обеим.

Можно ли реализовать брандмауэр между ресурсами, подключенными к виртуальной сети?

Да. Вы можете развернуть виртуальное устройство firewall от нескольких поставщиков через Azure Marketplace.

Доступны ли сведения о защите виртуальных сетей?

Да. Ознакомьтесь с обзором безопасности сети Azure.

Хранят ли данные клиентов виртуальные сети?

№ Виртуальные сети не хранят данные клиента.

Можно ли задать свойство FlowTimeoutInMinutes для всей подписки?

№ Необходимо задать свойство FlowTimeoutInMinutes в виртуальной сети. Следующий код поможет настроить это свойство автоматически для больших подписок:

$Allvnet = Get-AzVirtualNetwork
$time = 4 #The value should be from 4 to 30 minutes (inclusive) to enable tracking, or null to disable tracking. 
ForEach ($vnet in $Allvnet)
{
    $vnet.FlowTimeoutInMinutes = $time
    $vnet | Set-AzVirtualNetwork
}

API-интерфейсы, схемы и инструменты

Можно ли управлять виртуальными сетями из кода?

Да. REST API можно использовать для виртуальных сетей в моделях развертывания Azure Resource Manager и classic.

Существует ли поддержка инструментов для виртуальных сетей?

Да. Узнайте больше об использовании.

• Портал Azure для развертывания виртуальных сетей с помощью моделей развертывания Azure Resource Manager и classic.
• PowerShell для управления виртуальными сетями, развернутыми с помощью модели развертывания Resource Manager.
• Классический интерфейс командной строки Azure или Azure CLI для развертывания и управления виртуальными сетями, развернутыми с помощью моделей развертывания Resource Manager и classic.

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

Что такое пиринг между виртуальными сетями?

Пиринг между виртуальными сетями позволяет подключать виртуальные сети. Пиринговое подключение между виртуальными сетями позволяет маршрутизировать трафик между ними в частном порядке через IPv4-адреса.

Виртуальные машины в одноранговых виртуальных сетях могут взаимодействовать друг с другом, как если бы они были в одной сети. Эти виртуальные сети могут находиться в одном регионе или в разных регионах (также известных как пиринг глобальной виртуальной сети).

Вы также можете создавать пиринговые подключения виртуальной сети между Azure подписками.

Можно ли создать пиринговое подключение к виртуальной сети в другом регионе?

Да. Пиринг глобальной виртуальной сети позволяет выполнять пиринг между виртуальными сетями в разных регионах. Пиринг глобальной виртуальной сети доступен во всех общедоступных регионах Azure, облачных регионах Китая и регионах правительственного облака. Глобальное одноранговое подключение из общедоступных регионов Azure в национальные облачные регионы невозможно.

Какие ограничения связаны с пирингом глобальной виртуальной сети и подсистемами балансировки нагрузки?

Если две виртуальные сети в двух регионах связаны через глобальное одноранговое подключение виртуальных сетей, вы не можете подключиться к ресурсам, которые находятся за базовым балансировщиком нагрузки, через его IP-адрес внешнего интерфейса. Это ограничение не существует для стандартной подсистемы балансировки нагрузки.

Следующие ресурсы могут использовать базовые подсистемы балансировки нагрузки, что означает, что вы не можете связаться с ними через внешний IP-адрес подсистемы балансировки нагрузки через пиринг глобальной виртуальной сети. Но вы можете использовать пиринг глобальной виртуальной сети для доступа к ресурсам непосредственно через IP-адреса частной виртуальной сети, если разрешено.

• Виртуальные машины за базовыми балансировщиками нагрузки.
• Наборы масштабирования виртуальных машин с базовыми балансировщиками нагрузки.
• Azure Managed Redis.
• Шлюз приложений Azure v1.
• Azure Service Fabric.
• Azure API Management stv1.
• Доменные службы Microsoft Entra.
• Azure Logic Apps.
• Azure HDInsight.
• пакетная служба Azure.
• Среда службы приложений v1 и v2.

Вы можете подключаться к этим ресурсам через Azure ExpressRoute или через сетевые соединения через виртуальные сетевые шлюзы.

Можно ли включить пиринг между виртуальными сетями, если мои виртуальные сети принадлежат подпискам в разных клиентах Microsoft Entra?

Да. Вы можете установить виртуальное сетевое пирингование (локальное или глобальное), если ваши подписки принадлежат разным арендаторам Microsoft Entra. Это можно сделать через портал Azure, PowerShell или Azure CLI.

Подключение к пирингу виртуальной сети находится в состоянии, инициированном. Почему я не могу подключиться?

Если пиринговое подключение находится в состоянии инициированного , вы создали только одну ссылку. Чтобы установить успешное подключение, необходимо создать двунаправленную ссылку.

Например, для пиринга VNetA с VNetB необходимо создать ссылку от VNetA к VNetB и от VNetB к VNetA. Создание обоих ссылок изменяет состояние на Подключено.

Подключение к пирингу виртуальной сети находится в отключенном состоянии. Почему я не могу создать пиринговое подключение?

Если подключение к пирингу виртуальной сети находится в отключенном состоянии, то была удалена одна из созданных ссылок. Чтобы повторно установить пиринговое подключение, необходимо удалить оставшуюся ссылку и повторно создать оба.

Можно ли выполнить пиринг виртуальной сети с виртуальной сетью, которая находится в другой подписке?

Да. Вы можете настроить одноранговое соединение виртуальных сетей в разных подписках и регионах.

Можно ли соединить две виртуальные сети с совпадающими или перекрывающимися диапазонами адресов?

№ Невозможно включить пиринг между виртуальными сетями, если адресные пространства перекрываются.

Можно ли однорангово соединить одну виртуальную сеть с двумя другими виртуальными сетями с включенной опцией "Использовать удаленный шлюз" для обоих соединений?

№ Вы можете включить параметр "Использовать удаленный шлюз" только на одном пиринге в одной из виртуальных сетей.

Можно ли переместить виртуальную сеть с пиринговым подключением к другой виртуальной сети?

№ Вы не можете переместить виртуальную сеть с пиринговым подключением к другой виртуальной сети. Перед перемещением виртуальной сети необходимо удалить пиринговое подключение.

Сколько стоит пиринг между виртуальными сетями?

Плата за создание пирингового подключения виртуальной сети не взимается. Передача данных через пиринговые подключения оплачивается. Дополнительные сведения см. на странице цен Azure Virtual Network.

Шифруется ли пиринговый трафик виртуальной сети?

Когда трафик Azure перемещается между дата-центрами (за пределами физических границ, которые Microsoft не контролирует или от имени Microsoft), базовое сетевое оборудование использует шифрование уровня канала передачи данных MACsec. Это шифрование применяется к виртуальному сетевому пиринговому трафику.

Почему мое пиринговое соединение находится в состоянии Отключено?

Пиринговые подключения виртуальной сети переходят в состояние "Отключено" при удалении одной связи пиринга виртуальной сети. Чтобы восстановить пиринговое соединение, необходимо удалить оба соединения.

Если настроить пиринговое подключение между сетями VNetA и VNetB, а затем между сетями VNetB и VNetC, будет ли это означать, что между сетями VNetA и VNetC также установлено пиринговое подключение?

№ Транзитивный пиринг не поддерживается. Необходимо вручную создать взаимосвязь между VNetA и VNetC.

Есть ли ограничения пропускной способности для пиринговых подключений?

№ Пиринг между виртуальными сетями, будь то локальный или глобальный, не накладывает никаких ограничений пропускной способности. Пропускная способность ограничена только виртуальной машиной или вычислительным ресурсом.

Как устранить проблемы с пирингом виртуальной сети?

Воспользуйтесь руководством по устранению неполадок.

Виртуальный сетевой TAP

Какие Azure регионы доступны для TAP виртуальной сети?

Предварительный доступ к точке подключения терминала виртуальной сети (TAP) доступен во всех регионах Azure. Необходимо развернуть отслеживаемые сетевые адаптеры, ресурс TAP виртуальной сети и решение сборщика или аналитики в одном регионе.

Поддерживает ли виртуальная сеть TAP какие-либо возможности фильтрации на зеркальных пакетах?

Возможности фильтрации не поддерживаются предварительной версией TAP виртуальной сети. При добавлении конфигурации TAP к сетевому адаптеру полная копия всего входящего и исходящего трафика на сетевом адаптере передается к назначению TAP.

Можно ли добавить несколько конфигураций TAP в отслеживаемый сетевой адаптер?

Отслеживаемый сетевой адаптер может иметь только одну конфигурацию TAP. Обратитесь к отдельному партнерскому решению , чтобы обеспечить возможность потоковой передачи нескольких копий трафика TAP в выбранные средства аналитики.

Может ли один и тот же ресурс TAP агрегировать трафик из отслеживаемых сетевых адаптеров в нескольких виртуальных сетях?

Да. Один и тот же ресурс TAP виртуальной сети можно использовать для агрегирования зеркального трафика от отслеживаемых сетевых адаптеров в одноранговых виртуальных сетях в одной подписке или другой подписке.

Ресурс TAP виртуальной сети и целевой балансировщик нагрузки или целевой сетевой адаптер должны находиться в одной подписке. Все подписки должны находиться в одном клиенте Microsoft Entra.

Существуют ли рекомендации по производительности рабочего трафика, если включить конфигурацию TAP виртуальной сети на сетевом адаптере?

TAP виртуальной сети доступен в предварительной версии. Во время предварительной версии соглашение об уровне обслуживания отсутствует. Не следует использовать функциональность в производственной среде.

При включении сетевого адаптера виртуальной машины с конфигурацией TAP те же ресурсы на узле Azure, выделенном виртуальной машине для отправки рабочего трафика, используются для выполнения функции зеркального отображения и отправки зеркальных пакетов. Выберите правильный размер Linux или Windows размер виртуальной машины, чтобы убедиться, что для виртуальной машины достаточно ресурсов для отправки рабочего трафика и зеркального трафика.

Поддерживается ли ускорение сети для Linux или Windows с помощью TAP виртуальной сети?

Конфигурацию TAP можно добавить на сетевой адаптер, подключенный к виртуальной машине с включенным ускорением сети для Linux или Windows. Но добавление конфигурации TAP повлияет на производительность и задержку на виртуальной машине, так как ускоренная сеть Azure в настоящее время не поддерживает разгрузку зеркального трафика.

Конечные точки службы для виртуальной сети

Какова правильная последовательность операций для настройки конечных точек службы в службе Azure?

Существует два шага для защиты ресурса службы Azure с помощью конечных точек службы:

1. Включите конечные точки службы для службы Azure.
2. Настройте списки управления доступом виртуальной сети (ACL) в службе Azure.

Первым шагом является операция на стороне сети, а вторым шагом является операция на стороне службы. Один и тот же администратор или разные администраторы могут выполнять действия в зависимости от разрешений, предоставленных на роли администратора в системе управления доступом на основе ролей Azure (RBAC).

Рекомендуется произвести включение конечных точек службы для вашей виртуальной сети перед настройкой списков управления доступом (ACL) виртуальной сети на стороне службы Azure. Чтобы настроить конечные точки службы виртуальной сети, необходимо выполнить действия, описанные в предыдущей последовательности.

Некоторые службы (например, Azure SQL и Azure Cosmos DB) позволяют делать исключения из предыдущей последовательности с использованием флага IgnoreMissingVnetServiceEndpoint. После установки флага на True вы можете настроить сетевые списки управления доступом (ACL) на стороне сервиса Azure до включения конечных точек службы на стороне сети. службы Azure предоставляют этот флаг, чтобы помочь клиентам в случаях, когда определенные брандмауэры IP-адресов настроены в службах Azure.

Включение конечных точек службы на стороне сети может привести к снижению качества подключения, из-за изменения исходного IP-адреса с публичного IPv4-адреса на частный адрес. Настройка ACL виртуальной сети на стороне службы Azure до включения сетевых конечных точек может помочь избежать перебоев в подключении.

Находятся ли все службы Azure в Azure виртуальной сети, которую предоставляет клиент? Как конечная точка службы виртуальной сети работает со службами Azure?

Не все службы Azure находятся в виртуальной сети клиента. Большинство служб данных Azure (например, служба хранилища Azure, Azure SQL и Azure Cosmos DB) — это мультитенантные службы, к которым можно обращаться через общедоступные IP-адреса. Дополнительные сведения см. статью Развертывание выделенных служб Azure в виртуальных сетях.

При включении конечных точек службы виртуальной сети на стороне сети и настройке соответствующих списков ACL виртуальной сети на стороне службы Azure доступ к службе Azure ограничен разрешенной виртуальной сетью и подсетью.

Как конечные точки службы виртуальной сети обеспечивают безопасность?

Конечные точки службы виртуальной сети ограничивают доступ службы Azure к разрешенной виртуальной сети и подсети. Таким образом, они обеспечивают безопасность на уровне сети и изоляцию трафика службы Azure.

Весь трафик, использующий конечные точки службы виртуальной сети, передается через магистраль Microsoft для обеспечения другого уровня изоляции от общедоступного Интернета. Клиенты также могут полностью удалить общедоступный интернет-доступ к ресурсам службы Azure и разрешить трафик только из виртуальной сети с помощью сочетания ip-брандмауэра и списков ACL виртуальной сети. Удаление доступа к Интернету помогает защитить ресурсы службы Azure от несанкционированного доступа.

Что защищает конечная точка службы виртуальной сети — ресурсы виртуальной сети или ресурсы служб Azure?

Конечные точки службы виртуальной сети помогают защитить ресурсы службы Azure. Ресурсы виртуальной сети защищены с помощью групп безопасности сети.

Есть ли затраты на использование конечных точек службы виртуальной сети?

№ Дополнительные затраты на использование конечных точек службы виртуальной сети отсутствуют.

Можно ли включить конечные точки службы виртуальной сети и настроить списки управления доступом к виртуальной сети, если виртуальная сеть и ресурсы службы Azure принадлежат разным подпискам?

Да, это возможно. Виртуальные сети и ресурсы службы Azure могут находиться в одной подписке или в разных подписках. Единственное требование заключается в том, что как виртуальная сеть, так и ресурсы службы Azure должны находиться в одном и том же клиенте Microsoft Entra.

Можно ли включить конечные точки службы виртуальной сети и настроить списки ACL виртуальной сети, если виртуальная сеть и ресурсы службы Azure принадлежат разным клиентам Microsoft Entra?

Да, это возможно, если вы используете конечные точки службы для служба хранилища Azure и Azure Key Vault. Для других служб конечные точки службы виртуальной сети и списки ACL виртуальной сети не поддерживаются в разных клиентах Microsoft Entra.

Может ли IP-адрес локального устройства, подключенного через шлюз виртуальной сети Azure (VPN) или шлюз ExpressRoute, получать доступ к службам PaaS Azure через конечные точки службы виртуальной сети?

По умолчанию Azure ресурсы службы, защищенные для виртуальных сетей, недоступны из локальных сетей. Если вы хотите разрешить трафик из локальной среды, необходимо также разрешить общедоступные IP-адреса (как правило, NAT) из локальной среды или ExpressRoute. Эти IP-адреса можно добавить с помощью конфигурации брандмауэра IP-адресов для ресурсов службы Azure.

Кроме того, можно реализовать частные конечные точки для поддерживаемых служб.

Можно ли использовать конечные точки службы виртуальной сети для защиты служб Azure в нескольких подсетях в виртуальной сети или в нескольких виртуальных сетях?

Чтобы защитить службы Azure в нескольких подсетях в виртуальной сети или в нескольких виртуальных сетях, включите конечные точки службы на стороне сети на каждой из подсетей независимо. Затем защитите ресурсы службы Azure для всех подсетей, настроив соответствующие списки управления доступом (ACL) на стороне службы Azure.

Как отфильтровать исходящий трафик из виртуальной сети к службам Azure и при этом по-прежнему использовать конечные точки службы?

Если вы хотите проверить или отфильтровать трафик, предназначенный для службы Azure из виртуальной сети, можно развернуть сетевое виртуальное устройство в виртуальной сети. Затем можно применить конечные точки службы к подсети, в которой развернуто сетевое виртуальное устройство, и ограничить доступ к ресурсам службы Azure только для этой подсети с помощью списков ACL виртуальной сети.

Этот сценарий также может оказаться полезным, если вы хотите ограничить доступ служб Azure из виртуальной сети только к определенным ресурсам Azure с помощью фильтрации виртуальных сетевых устройств. Дополнительные сведения см. в разделе "Развертывание высокодоступных NVAs".

Что происходит, когда кто-то обращается к учетной записи службы Azure с включенным ACL виртуальной сети извне виртуальной сети?

Служба возвращает ошибку HTTP 403 или HTTP 404.

Разрешён ли доступ подсетям виртуальной сети, созданным в разных регионах, к учетной записи службы Azure в другом регионе?

Да. Для большинства служб Azure виртуальные сети, созданные в разных регионах, могут получать доступ к службам Azure в другом регионе через конечные точки службы виртуальной сети. Например, если учетная запись Azure Cosmos DB находится в регионе "Западная часть США" или "Восточная часть США", а виртуальные сети находятся в нескольких регионах, виртуальные сети могут получить доступ к Azure Cosmos DB.

Azure SQL является исключением и является региональным в природе. Виртуальная сеть и служба Azure должны находиться в одном регионе.

Может ли служба Azure иметь как ACL виртуальной сети, так и брандмауэр IP-адресов?

Да. ACL виртуальной сети и брандмауэр IP-адресов могут сосуществовать. Функции дополняют друг друга, чтобы обеспечить изоляцию и безопасность.

Что произойдет, если удалить виртуальную сеть или подсеть, где включены конечные точки службы для служб Azure?

Удаление виртуальных сетей и удаление подсетей являются независимыми операциями. Они поддерживаются даже при включении конечных точек службы для служб Azure.

Если вы настроили списки управления доступом (ACL) виртуальной сети для служб Azure, то связанные с этими службами Azure сведения ACL становятся неактивными при удалении виртуальной сети или подсети с активированными конечными точками службы виртуальной сети.

Что произойдет, если удалить учетную запись службы Azure с включенной конечной точкой службы виртуальной сети?

Удаление учетной записи службы Azure является независимой операцией. Эта поддержка сохраняется, даже если вы включили конечную точку службы на стороне сети и настроили списки контроля доступа (ACL) виртуальной сети на стороне службы Azure.

Что происходит с исходным IP-адресом ресурса (например, виртуальной машины в подсети), для которого включены конечные точки службы виртуальной сети?

При включении конечных точек службы виртуальной сети исходные IP-адреса ресурсов в подсети виртуальной сети переключаются с использования общедоступных IPv4-адресов к использованию частных IP-адресов виртуальной сети Azure для трафика в службы Azure. Этот переключатель может привести к сбою определенных IP-брандмауэров, настроенных ранее на общедоступный IPv4-адрес в службах Azure.

Всегда ли маршрут конечной точки службы имеет приоритет?

Конечные точки службы добавляют системный маршрут, который имеет приоритет над маршрутами протокола BGP и обеспечивает оптимальную маршрутизацию для трафика конечной точки службы. Конечные точки службы всегда напрямую перенаправляют трафик вашей виртуальной сети к службе в магистральной сети Microsoft Azure.

Дополнительные сведения о том, как Azure выбирает маршрут, см. в статье Virtual network traffic route.

Работают ли конечные точки службы с ICMP?

№ Трафик ICMP, полученный из подсети с включенными конечными точками службы, не будет принимать путь туннеля службы к нужной конечной точке. Конечные точки службы обрабатывают только TCP-трафик. Если вы хотите проверить задержку или связность с конечной точкой через сервисные конечные точки, такие инструменты, как ping и tracert, не покажут истинный путь, по которому пройдут ресурсы внутри подсети.

Как NSG (группы безопасности сети) в пределах подсети взаимодействуют с конечными точками службы?

Чтобы получить доступ к службе Azure, группы безопасности сети должны разрешить исходящее подключение. Если группы безопасности сети открыты для всего исходящего интернет-трафика, трафик конечной точки службы должен работать. Кроме того, можно ограничить исходящий трафик только IP-адресами службы с помощью тегов службы.

Какие разрешения необходимы для настройки конечных точек службы?

Конечные точки службы можно настраивать в виртуальной сети независимо, если у вас есть доступ на запись к этой сети.

Чтобы защитить ресурсы службы Azure в виртуальной сети, необходимо иметь Microsoft. Network/virtualNetworks/subnets/joinViaServiceEndpoint/action разрешение на добавляемые подсети. Это разрешение включается в встроенную роль администратора службы по умолчанию и может быть изменено путем создания пользовательских ролей.

Дополнительные сведения о встроенных ролях и назначении определенных разрешений пользовательским ролям см. в разделе Azure настраиваемые роли.

Можно ли фильтровать трафик виртуальной сети к службам Azure через конечные точки службы?

Политики конечной точки службы виртуальной сети можно использовать для фильтрации трафика виртуальной сети в службы Azure, что позволяет использовать только определенные ресурсы службы Azure через конечные точки службы. Политики конечных точек обеспечивают детализированный контроль доступа из трафика виртуальной сети к службам Azure.

Дополнительные сведения см. в разделе Политики виртуальных конечных точек сетевой службы для служба хранилища Azure.

Поддерживает ли Microsoft Entra ID конечные точки службы виртуальной сети?

Microsoft Entra ID не поддерживает конечные точки службы по умолчанию. Полный список служб Azure, поддерживающих конечные точки службы виртуальной сети, см. в разделе Конечные точки сетевых службVirtual.

В этом списке тег Microsoft.AzureActiveDirectory, указанный среди служб, поддерживающих конечные точки службы, используется для поддержки конечных точек службы Azure Data Lake Storage 1-го поколения. Виртуальная сетевая интеграция для Data Lake Storage 1-го поколения использует служебную конечную точку виртуальной сети между вашей виртуальной сетью и Microsoft Entra ID для создания дополнительных заявок безопасности в токене доступа. Затем эти заявки используются для проверки подлинности вашей виртуальной сети в учетной записи Data Lake Storage 1-го поколения и предоставления доступа.

Существуют ли ограничения на количество конечных точек службы, которые можно настроить из виртуальной сети?

Общее количество конечных точек служб в виртуальной сети не ограничено. Для ресурса службы Azure (например, учетной записи служба хранилища Azure) службы могут применять ограничения на количество подсетей, используемых для защиты ресурса. В следующей таблице приведены примеры некоторых ограничений.

Перенос классических сетевых ресурсов в Resource Manager

Что такое Azure Service Manager и что означает термин "классический"?

Azure Service Manager является старой моделью развертывания Azure, ответственной за создание, управление и удаление ресурсов. Слово classic в сетевой службе ссылается на ресурсы, управляемые моделью Azure Service Manager. Дополнительные сведения см. в сравнении моделей развертывания.

Что такое Azure Resource Manager?

Azure Resource Manager — это последняя модель развертывания и управления в Azure, которая отвечает за создание, управление и удаление ресурсов в подписке Azure. Дополнительные сведения см. в разделе Что такое Azure Resource Manager?

Можно ли отменить миграцию после того, как ресурсы перенесены в Resource Manager?

Вы можете отменить миграцию, пока ресурсы находятся в состоянии готовности. Откат к предыдущей модели развертывания не поддерживается после успешной миграции ресурсов с помощью операции коммита.

Можно ли отменить миграцию, если коммит операции не удался?

Вы не можете отменить миграцию, если операция фиксации не удалась. Никакие операции миграции, включая подтверждение, нельзя изменить после их начала. Рекомендуется повторить операцию через короткий период. Если операция снова завершится сбоем, отправьте запрос в службу поддержки.

Можно ли проверить подписку или ресурсы, чтобы узнать, подходят ли они для миграции?

Да. Первым шагом в подготовке к миграции является проверка возможности переноса ресурсов. Если проверка завершается ошибкой, вы получите сообщения по всем причинам, по которым миграция не может быть завершена.

Перенос ресурсов шлюза приложений выполняется в рамках миграции виртуальной сети из классической в Resource Manager?

Ресурсы Шлюз приложений Azure не переносятся автоматически в ходе процесса миграции виртуальной сети. Если в виртуальной сети присутствует один элемент, миграция не будет успешной. Чтобы перенести ресурс шлюза приложений в Resource Manager, необходимо удалить и повторно создать экземпляр шлюза приложений после завершения миграции.

Переносятся ли ресурсы шлюза VPN при миграции виртуальной сети с классической на Resource Manager?

Ресурсы Azure VPN Gateway переносятся в рамках процесса миграции виртуальной сети. Миграция выполняется по одной виртуальной сети за раз без других требований. Шаги миграции аналогичны шагам миграции виртуальной сети без VPN-шлюза.

Связано ли прерывание службы с переносом классических VPN-шлюзов в Resource Manager?

При миграции на Resource Manager ваше VPN-подключение не будет прерываться, и вы не испытаете перебоев в работе службы. Существующие рабочие нагрузки будут продолжать функционировать с полным локальным подключением во время миграции.

Нужно ли перенастроить локальное устройство после переноса VPN-шлюза в Resource Manager?

Общедоступный IP-адрес, связанный с VPN-шлюзом, остается неизменным после миграции. Вам не нужно перенастраивать локальный маршрутизатор.

Каковы поддерживаемые сценарии миграции VPN-шлюза с классической на Resource Manager?

Миграция из классической в Resource Manager охватывает большинство распространенных сценариев VPN-подключения. Ниже перечислены поддерживаемые сценарии.

• Подключение типа "точка — сеть".

• Подключение "site-to-site" с VPN-шлюзом, подключенным к локальной сети.

• Сетевое подключение между двумя виртуальными сетями, используюющими VPN-шлюзы.

• Несколько виртуальных сетей, подключенных к одному локальному расположению.

• Подключение к нескольким сайтам.

• Виртуальные сети с поддержкой принудительного туннелирования.

Какие сценарии не поддерживаются для миграции VPN-шлюза с классической на Resource Manager?

Ниже перечислены сценарии, которые не поддерживаются:

• Виртуальная сеть с шлюзом ExpressRoute и VPN-шлюзом.

• Виртуальная сеть, подключенная через шлюз ExpressRoute к каналу, находящемуся в другой подписке.

• Транзитные сценарии, когда расширения виртуальных машин подключены к локальным серверам.

Где можно найти дополнительные сведения о миграции из классической в Resource Manager?

См. Часто задаваемые вопросы о переходе с классического на Azure Resource Manager.

Можно ли восстановить удаленный общедоступный IP-адрес?

№ После удаления общедоступного IP-адреса Azure его невозможно восстановить. Дополнительные сведения см. в разделе "Просмотр", изменение параметров или удаление общедоступного IP-адреса.

Как сообщить о проблеме?

Вы можете опубликовать вопросы о проблемах миграции на странице Microsoft Q&A. Мы рекомендуем опубликовать все вопросы на этом форуме. Если у вас есть договор на поддержку, можно также отправить запрос в службу поддержки.