Продажи: 1-800-867-1389

Вопросы по виртуальным сетям

Обновлено: Июль 2014 г.

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

Конфигурация виртуальной сети

Подключение между виртуальными сетями организаций (виртуальные частные сети)

Подключение нескольких сайтов и подключения типа «VNet to VNet»

Виртуальная сеть и разрешение имен (DNS)

Виртуальная сеть и виртуальные машины

Виртуальная сеть и службы

Виртуальная сеть и безопасность

API-интерфейсы, схемы и средства

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

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

  • Создание выделенной, частной, только облачной виртуальной сети.

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

  • Безопасное расширение центра обработки данных.

    Благодаря виртуальной сети можно построить традиционную VPN типа «сеть-сеть», безопасно масштабирующую емкости центра обработки данных. Виртуальная сеть использует стандартный протокол IPSEC для установки безопасного соединения между корпоративным шлюзом VPN и Azure. За шлюзом VPN можно добавить столько машин, сколько требуется.

  • Поддержка гибридных облачных сценариев

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

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

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

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

Да. Виртуальную сеть можно использовать без подключения «сеть-сеть». Это особенно полезно, если вы хотите запустить в Azure контроллеры доменов и фермы SharePoint .

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

Можно использовать любой диапазон IP-адресов, определенный в RFC1918. Сюда входят IP-адреса в следующих диапазонах:

  • 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)

IP-адреса за пределами диапазона RFC1918 не поддерживаются.

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

Некоторые IP-адреса в каждой подсети резервируются. Первый и последний IP-адреса подсетей зарезервированы для соответствия протоколу. Также дополнительно резервируются несколько IP-адресов для наших служб.

Самая малая поддерживаемая подсеть - /29, а самая большая - /8 (по определениям подсети CIDR). Мы резервируем некоторые IP-адреса из каждой подсети.

Виртуальные сети представляют собой перекрывающиеся сети уровня 3. Они не поддерживают семантику уровня - 2.

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

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

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

  • TCP

  • UDP

  • ICMP

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

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

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

Адреса подсетей можно изменять, если в них не развернуты виртуальные машины или службы, с помощью командлетов PowerShell или файла NETCFG. Нельзя изменить или удалить подсеть после развертывания в ней виртуальных машин и служб.

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

Нет. Адреса IPv6 не поддерживаются для виртуальных сетей.

Нет. Виртуальная сеть ограничена одним регионом.

Да. Вы можете создать связь типа «VNet to VNet», используя API REST или Windows PowerShell. См. раздел Настройка соединения типа "VNet-VNet".

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

  • Site-to-site — VPN-подключение по IPsec (IKE v1 и IKE v2)

  • Point-to-site — VPN-подключение по протоколу SSTP (Secure Sockets Tunneling Protocol)

  • ExpressRoute — прямое безопасное подключение от глобальной сети, а не по общедоступном Интернету

Подключения типа «сеть-сеть» позволяют подключать любые локальные компьютеры к любой виртуальной машине или экземпляру роли в виртуальной сети в зависимости от конфигурации маршрутизации. Это отличный вариант для всегда доступного подключения между организациями, и оно оптимально подходит для гибридных конфигураций. Оно полагается на устройство VPN IPsec (аппаратное или программное), которое должно быть развернуто на периферии сети для подключения. Для создания этого типа подключения потребуется оборудование VPN и внешний IPv4-адрес.

Подключения типа «точка-сеть» позволят вам подключаться с одного компьютера к любому устройству, находящемуся в вашей виртуальной сети. Они используют клиент VPN Windows. В рамках конфигурации «точка-сеть» необходимо установить сертификат и пакет конфигурации клиента VPN, который содержит параметры, позволяющие компьютеру подключаться к любой виртуальной машине или экземпляру роли в виртуальной сети. Это отлично подходит, если вам необходимо подключиться с системы, отличной от локальной, к виртуальной сети. Также данный вариант оптимален, если у вас нет доступа к оборудованию VPN или внешнему IPv4-адресу, которые нужны для подключения типа «сеть-сеть».

Примечание. Можно настроить виртуальную сеть для одновременного использования подключения типа «сеть-сеть» и «точка-сеть», при условии что вы создадите подключение типа «сеть-сеть» с помощью динамического шлюза. Дополнительные сведения см. в Сведения о безопасной сети для нескольких организаций.

Вы можете подключиться к нескольким сайтам, используя Windows PowerShell и API REST Azure. См. раздел часто задаваемых вопросов о Подключение нескольких сайтов и подключения типа «VNet to VNet».

Мы утвердили набор стандартных VPN-устройств типа «сеть-сеть» в условиях партнерства поставщиков устройств. Перечень известных совместимых устройств VPN, соответствующих им шаблонов конфигурации и спецификаций устройств можно найти здесь. Все устройства в семействах устройств, перечисленных как совместимые, должны работать с виртуальной сетью. Чтобы легче настроить устройство VPN, используйте шаблон конфигурации, который соответствует соответствующему семейству устройств.

Если ваше устройство не входит в список совместимых устройств VPN, но вам бы хотелось использовать его для соединения VPN, необходимо убедиться, что оно соответствует минимальным требованиям. Устройства, соответствующие минимальным требованиям, также должны хорошо работать с виртуальной сетью. Минимальные требования к устройствам перечислены ниже как для статических, так и для динамических конфигураций маршрутизации. Дополнительные сведения можно найти здесь. За дополнительной поддержкой и инструкциями по настройке обратитесь к изготовителю соответствующего устройства.

Поддерживаются серверы маршрутизации и удаленного доступа (RRAS) Windows Server 2012 для конфигурации типа «сеть-сеть» для нескольких организаций.

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

Поддерживаются следующие операционные системы:

  • Windows 7 (только 64-разрядная версия)

  • Windows Server 2008 R2

  • Windows 8 (только 64-разрядная версия)

  • Windows Server 2012

Нет. Поддержка ограничена только версиями операционной системы Windows, перечисленными выше.

К виртуальной сети может подключиться до 128 VPN-клиентов.

Да. Для туннелирования через брандмауэры используется протокол SSTP (Secure Sockets Tunneling Protocol). Этот туннель будет отображаться как соединение HTTPs.

Автоматическое повторное подключение и DDNS в настоящее время не поддерживаются в виртуальных частных сетях «точка-сеть».

Да. Оба этих решения будут работать при наличии в виртуальной сети шлюза VPN с динамической маршрутизацией. В шлюзах VPN со статической маршрутизацией конфигурация «точка-сеть» не поддерживается.

Да, можно. Но при этом виртуальные сети не могут иметь перекрывающиеся префиксы IP, а адресные пространства подключения «точка-сеть» между виртуальными сетями не должны перекрываться.

Точную пропускную способность для туннелей VPN определить сложно. IPsec и SSTP - протоколы VPN с шифрованием. Пропускная способность также ограничивается задержкой и полосой пропускания между вашей локальной сетью и Интернетом.

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

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

Нет. Чтобы получить IP-адрес шлюза, необходимо сначала создать этот шлюз. При удалении и повторном создании шлюза VPN IP-адрес изменится.

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

Да, можно использовать API заданного предварительного ключа и командлет PowerShell для настройки VPN со статической маршрутизацией и VPN с динамической маршрутизацией Azure.

Для проверки подлинности можно использовать только общие ключи (PSK).

Имеется служба шлюза, выполняемая для предоставления подключений между организациями. Для обеспечения маршрутизации между локальной сетью и облаком необходимы два IP-адреса вашего домена маршрутизации. Требуется указать по крайней мере подсеть /29, из которой мы сможем отобрать IP-адреса для настройки маршрутов.

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

Добавьте для виртуальной сети каждый диапазон, который нужно отправлять через шлюз, на странице «Сети» в разделе «Локальные сети».

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

Максимальное количество тех и других — 10. Например, одна виртуальная сеть Azure может подключаться к 6 локальным сайтам и 4 виртуальным сетям.

Да, VPN P2S можно использовать со шлюзами VPN, подключающимися к нескольким локальным сайтам и другим виртуальным сетям

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

Нет, пересекающие адресные пространства вызовут отправку NETCFG-файла или сбой создания виртуальной сети.

Нет, все туннели VPN, включая VPN P2S, используют один шлюз VPN Azure и доступную пропускную способность.

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

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

Нет, по умолчанию Azure создает разные предварительные ключи для разных VPN-подключений. Однако можно использовать новый API REST заданного ключа шлюза VPN или командлет PowerShell, чтобы задать предпочитаемое значение. Ключ ДОЛЖЕН быть строкой из букв и цифр с длиной от 1 до 128 символов.

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

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

Можно указать до 12 DNS-серверов.

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

Используйте таблицу решений на странице Разрешение имен для просмотра имеющихся параметров DNS.

DNS Azure - это многопользовательская служба DNS. Все ваши виртуальные машины регистрируются в этой службе. Эта служба предоставляет разрешение имен по имени узла для VM, содержащихся в той же облачной службе, и по FQDN для VM в одной виртуальной сети. Примечание. В данный момент есть ограничение на межклиентское разрешение имен с помощью DNS Azure до 100 первых облачных служб в виртуальной сети. При использовании собственного DNS-сервера это ограничение не применяется.

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

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

Поддерживаются все дистрибутивы Linux, поддерживаемые в Windows Azure.

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

  • Общедоступный VIP — это общедоступный IP-адрес, назначенный вашей облачной службе. Он не назначается напрямую сетевому адаптеру виртуальной машины. VIP продолжает принадлежать облачной службе, которой он назначен, пока все виртуальные машины в этой службе не будут остановлены (освобождены) или удалены. В таком случае он освобождается.

  • DIP. При развертывании VM в виртуальной сети VM всегда получает внутренний IP-адрес (DIP) из указанного пула внутренних IP-адресов. VM взаимодействуют в виртуальной сети, используя DIP. Хотя Azure назначает DIP, можно запросить статический DIP для виртуальной машины, если вы развертываете VM с помощью PowerShell. См. раздел Настройка статического внутреннего IP-адреса (DIP) для виртуальной машины.

  • Виртуальный IP-адрес. VM также связана с виртуальным IP-адресом, хотя он никогда не назначается VM напрямую. Виртуальный IP-адрес — это общедоступный IP-адрес, который может быть назначен облачной службе. Кроме того, можно зарезервировать виртуальный IP-адрес для облачной службы. См. раздел Reserved IP Addresses.

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

Windows Azure будет использовать DHCP для назначения внутреннего IP-адреса для каждой виртуальной машины и экземпляра PaaS из подсети, которую вы укажете.

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

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

Внутренние IP-адреса остаются с виртуальной машиной в течение всего срока ее работы, если только ее не остановить (освободить). При остановке (освобождении) виртуальной машины внутренние IP-адреса освобождаются, если не с помощью PowerShell не определен статический DIP. Если виртуальная машина просто остановлена (и не переведена в состояние «Остановлена (освобождена)»), IP-адрес останется назначенным виртуальной машине.

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

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

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

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

Нет. MAC-адрес нельзя статически настроить.

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

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

Можно сделать и так, и так. Если включен протокол удаленного рабочего стола (RDP) и создана конечная точка, можно также подключиться к виртуальной машине с помощью VIP-адреса. В это случае необходимо указать виртуальный адрес и порт, к которому следует подключиться. На виртуальной машине необходимо настроить порт для получения трафика. Обычно можно открыть портал управления и сохранить параметры подключения к удаленному рабочему столу на компьютере. Параметры будут содержать необходимые сведения о подключении.

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

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

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

Нет. Веб-сайты в виртуальных сетях не поддерживаются.

Нет. Базы данных SQL в виртуальных сетях не поддерживаются.

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

Это можно сделать, указав имя виртуальной сети и сопоставления «роль-подсеть» в разделе конфигурации сети файла конфигурации службы. При этом не требуется обновлять двоичные файлы.

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

Windows Azure использует механизм DHCP для назначения внутреннего IP-адреса каждой виртуальной машине и экземпляру PaaS в указанной подсети виртуальной сети.

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

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

Да. Для управления виртуальными сетями и подключения между организациями предназначен API-интерфейс REST. Дополнительные сведения можно найти здесь.

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

См. также

Была ли вам полезна эта информация?
(1500 символов осталось)
Спасибо за ваш отзыв
Показ:
© 2014 Microsoft