Виртуальная сеть Azure: часто задаваемые вопросы

  • Статья

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Настройка

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

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

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

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

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

  • 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 частные, не routable адресные пространства, могут работать, но имеют нежелательные побочные эффекты.

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

  • 224.0.0.0/4 (многоадресная рассылка)
  • 255.255.255.255/32 (трансляция)
  • 127.0.0.0/8 (адрес обратной связи)
  • 169.254.0.0/16 (ссылка local)
  • 168.63.129.16/32 (внутренний DNS)

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

Да. Дополнительные сведения о диапазонах общедоступных IP-адресов см. в разделе Create a virtual network (Создание виртуальной сети). Общедоступные 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 для сопоставления IP-адресов Azure DNS с пространством виртуальной сети.
  • 192.168.1.255: адрес сетевой трансляции.

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

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

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

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

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

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

Что такое поведение при применении группы безопасности сети и UDR в подсети?

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.

Локальный клиент dhcp-сервера (исходный порт UDP/68, конечный порт UDP/67) по-прежнему не поддерживается в Azure, так как этот трафик перехватывается и обрабатывается иначе. Таким образом, это приведет к некоторому времени ожидания сообщений во время DHCP RENEW в T1, когда клиент напрямую пытается достичь DHCP-сервера в Azure, но это должно завершиться успешно, когда попытка ОБНОВЛЕНИЯ DHCP выполняется в T2 через агент ретранслятора DHCP. Дополнительные сведения о таймерах обновления DHCP T1 и T2 см. в статье RFC 2131.

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

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

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

Да.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Служба DNS, предоставляемая Azure, — это мультитенантная служба DNS от Корпорации Майкрософт. Azure регистрирует в этой службе все ваши виртуальные машины и экземпляры ролей облачной службы. Эта служба предоставляет разрешение имен:

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

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

Существует ограничение на первые 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-адрес с помощью статического метода.

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

    Все виртуальные машины и экземпляры ролей Azure Облачные службы, развернутые с помощью классической модели развертывания, существуют в облачной службе. Облачная служба назначает динамический общедоступный IP-адрес. При необходимости можно назначить общедоступный статический IP-адрес, называемый зарезервированным IP-адресом в качестве ВИРТУАЛЬНОго IP-адреса.

    Общедоступные 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 можно развернуть в виртуальной сети с помощью Среда службы приложений. Затем можно:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да. Вы можете развернуть виртуальную (модуль) сети брандмауэра из нескольких поставщиков через Azure Marketplace.

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

Да. Ознакомьтесь с общими сведениями о безопасности сети Azure.

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

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

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

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

$Allvnet = Get-AzVirtualNetwork
$time = 4 #The value should be 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 и классических моделях развертывания.

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

Да. Дополнительные сведения об использовании средств:

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

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

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

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

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

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

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

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

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

  • Виртуальные машины за базовыми подсистемами балансировки нагрузки
  • Масштабируемые наборы виртуальных машин с базовыми подсистемами балансировки нагрузки
  • Кэш Azure для Redis
  • Шлюз приложений Azure версии 1
  • Azure Service Fabric
  • Azure Управление API stv1
  • Доменные службы Microsoft Entra
  • Приложения логики Azure
  • Azure HDInsight
  • Пакетная служба Azure
  • Среда службы приложений версии 1 и 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В каких регионах Azure доступна функция TAP виртуальной сети?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

Примечание.

Если включить конечную точку службы в некоторых службах, например Microsoft.AzureActiveDirectory, можно просмотреть подключения ipV6-адресов в журналах входа. Корпорация Майкрософт использует внутренний частный диапазон IPV6 для этого типа подключений.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

По умолчанию ресурсы служб 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 должны находиться в одном регионе.

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

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

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

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

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

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

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

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

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

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

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

Дополнительные сведения о том, как Azure выбирает маршрут, см. в статье "Маршрутизация трафика виртуальной сети".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Служба Azure Ограничения правил виртуальной сети
Хранилище Azure 200
Azure SQL 128
Azure Synapse Analytics 128
Azure Key Vault 200
Azure Cosmos DB 64
Центры событий Azure 128
Служебная шина Azure 128
Хранилище Azure Data Lake Storage 1-го поколения 100

Примечание.

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

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

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

Azure Service Manager — это старая модель развертывания Azure, которая отвечает за создание, управление и удаление ресурсов. Слово классический применительно к сетевым службам относится к ресурсам, управляемым моделью 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-шлюз переносятся в рамках процесса миграции виртуальной сети. Миграция выполняется по одной виртуальной сети за раз без других требований. Шаги миграции аналогичны миграции для миграции виртуальной сети без VPN-шлюза.

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

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

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

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

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

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

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

  • Подключение типа "сеть — сеть" с VPN-шлюзом, подключенным к локальному расположению.

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

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

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

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

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

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

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

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

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

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

Ознакомьтесь с часто задаваемыми вопросами о миграции классической модели в Azure Resource Manager.

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

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