VPN-шлюз: вопросы и ответы

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

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

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

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

Да.

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

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

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

Вы можете подключиться к нескольким сайтам с помощью Windows PowerShell и интерфейсов REST API Azure. См. раздел этой статьи Возможности подключения нескольких сайтов и подключения между виртуальными сетями.

Взимается ли дополнительная плата за настройку VPN-шлюза в режиме "активный — активный"?

Нет.

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

Поддерживаются следующие подключения к виртуальному сетевому шлюзу:

Дополнительные сведения о подключениях через VPN-шлюз см. в статье Сведения о VPN-шлюзе.

Чем отличаются подключения "сеть — сеть" и "точка — сеть"?

Конфигурация сеть — сеть — это подключение между локальным расположением и Azure (через VPN-туннель IPsec/IKE). Такая конфигурация позволяет подключать любые компьютеры, находящиеся в локальной среде, к любой виртуальной машине или экземпляру роли в виртуальной сети в зависимости от настроек маршрутизации и разрешений. Это отличный вариант для всегда доступного распределенного подключения, а также для гибридных конфигураций. Для этого типа подключения требуется устройство VPN с поддержкой IPsec (аппаратное устройство или программное обеспечение), которое необходимо развернуть на границе сети. Для создания этого типа подключения необходим внешний адрес IPv4.

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

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

Конфиденциальность

Хранит и обрабатывает ли служба VPN данные клиентов?

Нет.

Шлюзы виртуальной сети

Является ли VPN-шлюз виртуальным сетевым шлюзом?

VPN-шлюз — это тип шлюза виртуальной сети. Он передает зашифрованный трафик между виртуальной сетью и локальным расположением через общедоступное подключение. VPN-шлюз можно также использовать для передачи трафика между виртуальными сетями. При создании VPN-шлюза для параметра GatewayType используется значение Vpn. Дополнительные сведения см. в статье Сведения о параметрах VPN-шлюза.

Что такое шлюз на основе политик (со статической маршрутизацией)?

Шлюзы на основе политик реализуют подключения VPN на основе политик. VPN на основе политики шифруют и направляют пакеты через туннели IPsec на основе комбинаций префиксов адресов между местной сетью и виртуальной сетью Azure. Политика (или селектор трафика) обычно определяется как список доступа в конфигурации VPN.

Что такое шлюз на основе маршрутов (с динамической маршрутизацией)?

Шлюзы на основе маршрутов реализуют VPN на основе маршрутов. VPN на основе маршрутов используют «маршруты» в таблице маршрутизации и переадресации для направления пакетов в интерфейсы соответствующих туннелей. Затем интерфейсы туннелей шифруют пакеты в туннели или расшифровывают их из туннелей. Политика или селекторы трафика для VPN на основе маршрутов настроены как "любой — к — любому" (или подстановочные знаки).

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

Да, селекторы трафика можно определить с помощью атрибута trafficSelectorPolicies в подключении, используя команду PowerShell New-AzIpsecTrafficSelectorPolicy. Чтобы указанный селектор трафика вступил в силу, нужно включить параметр Use Policy Based Traffic Selectors (Использовать селекторы трафика на основе политики).

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

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

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

  1. Удалите все подключения, связанные со шлюзом.

  2. Удалите шлюз, выполнив инструкции приведенные в одной из следующих статей:

  3. Создайте новый шлюз, используя необходимый тип, а затем завершите настройку VPN. Пошаговые инструкции см. в статье Руководство по настройке подключения "сеть — сеть".

Требуется ли параметр GatewaySubnet?

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

При создании подсети шлюза указывается количество IP-адресов, которое содержит подсеть. IP-адреса в подсети шлюза выделяются службе шлюза. В некоторых конфигурациях службам шлюза требуется выделить больше IP-адресов. Необходимо убедиться, что подсеть шлюза содержит достаточно IP-адресов с учетом будущего роста и возможных дополнительных конфигураций подключения. Хотя можно создать подсеть шлюза всего лишь с размером /29, мы советуем создавать подсети с размером /27 или больше (/27, /26, /25 и т. д.). Просмотрите требования для конфигурации, которую требуется создать, и убедитесь, что подсеть шлюза соответствует этим требованиям.

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

Нет.

Можно ли получить IP-адрес своего VPN-шлюза до его создания?

Зональные и избыточные между зонами шлюзы (номера SKU шлюза, в названии которых есть AZ) зависят от ресурса общедоступного IP-адреса Azure номера SKU категории "Стандартный" . Ресурсы общедоступных IP-адресов Azure номера SKU категории "Стандартный" должны использовать статический метод распределения. Следовательно, у вас будет общедоступный IP-адрес для VPN-шлюза, как только вы создадите предназначенный для него ресурс общедоступного IP-адреса номера SKU "Стандартный".

Для незональных шлюзов и шлюзов, неизбыточных между зонами (номера SKU шлюзов, которые не содержат AZ в имени), невозможно получить IP-адрес VPN-шлюза перед созданием. IP-адрес изменится только в том случае, если вы удалите и заново создадите свой VPN-шлюз.

Могу ли я запросить статический общедоступный IP-адрес для своего VPN-шлюза?

Зональные и избыточные между зонами шлюзы (номера SKU шлюза, в названии которых есть AZ) зависят от ресурса общедоступного IP-адреса Azure номера SKU категории "Стандартный" . Ресурсы общедоступных IP-адресов Azure номера SKU категории "Стандартный" должны использовать статический метод распределения.

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

Как проверить подлинность моего VPN-туннеля?

VPN Azure использует проверку подлинности с помощью общего ключа (PSK). Во время создания VPN-туннеля генерируется общий ключ (PSK). Вы можете заменить автоматически созданный PSK собственным. Для этого используйте PowerShell или API REST для задания общего ключа.

Можно ли использовать API для задания общего ключа для настройки VPN-шлюза со статической маршрутизацией (на основе политик)?

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

Можно ли использовать другие способы проверки подлинности

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

Как установить, какой именно трафик проходит через VPN-шлюз?

Модель развертывания диспетчера ресурсов

  • PowerShell: используйте параметр AddressPrefix, чтобы указать трафик для шлюза локальной сети.
  • Портал Azure: перейдите к шлюзу локальной сети > "Конфигурация" > "Адресное пространство".

Классическая модель развертывания

  • Портал Azure: перейдите к классической виртуальной сети и последовательно выберите > "VPN-подключения" > "VPN-подключения типа "сеть — сеть" > Local site name (Имя локального сайта) > "Локальный сайт" > Client address space (Адресное пространство клиента).

Можно ли использовать NAT-T для моих VPN-подключений?

Да, обход NAT (NAT-T) поддерживается. VPN-шлюз Azure НЕ будет выполнять никаких функций, подобных NAT, для внутренних пакетов, поступающих в туннели IPsec и из них. В этой конфигурации убедитесь, что локальное устройство инициирует использование туннеля IPsec.

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

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

Почему на моем шлюзе виртуальной сети открыты определенные порты?

Они необходимы для обмена данными в рамках инфраструктуры Azure. Они защищены (заблокированы) с использованием сертификатов Azure. Без подходящих сертификатов внешние сущности, включая клиентов этих шлюзов, не смогут как-либо повлиять на эти конечные точки.

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

Дополнительные сведения о типах шлюзов, требованиях и пропускной способности

Дополнительные сведения см. в статье Сведения о параметрах VPN-шлюза.

Подключения "сеть — сеть" и VPN-устройства

Что следует учесть при выборе VPN-устройства?

Для подключения "сеть — сеть" мы утвердили набор стандартных VPN-устройств в сотрудничестве с поставщиками устройств. Дополнительные сведения о списке известных совместимых устройств VPN, соответствующих инструкциях по настройке или образцах конфигураций, а также о спецификации устройств см. в статье VPN-устройства и параметры IPsec/IKE для подключений типа "сеть — сеть" через VPN-шлюз. Все устройства, перечисленные в семействах устройств как совместимые, должны работать с виртуальной сетью. Чтобы настроить VPN-устройство, см. образец конфигурации устройства или перейдите по ссылке, которая соответствует семейству устройств.

Где можно найти параметры конфигурации VPN-устройств?

Скачивание скриптов конфигурации VPN-устройства:

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

Дополнительные сведения о конфигурации см. по следующим ссылкам:

Как изменить примеры конфигурации VPN-устройства?

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

Где найти параметры IPsec и IKE?

См. сведения о параметрах IPsec/IKE.

Почему мой туннель VPN на основе политики выключается при отсутствии трафика?

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

Можно ли использовать сети VPN для подключения к Azure?

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

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

Можно ли подключиться к VPN-шлюзу с помощью подключения "точка — сеть" при активном подключении "сеть — сеть"?

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

Подключения "точка — сеть" и проверка подлинности на основе сертификата

Этот раздел посвящен модели развертывания с помощью Resource Manager.

Сколько конечных точек VPN-клиента можно иметь в конфигурации «точка-сеть»?

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

Какие клиентские операционные системы можно использовать для подключения "точка — сеть"?

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

  • Windows Server 2008 R2 (только 64-разрядная версия)
  • Windows 8.1 (32-разрядная и 64-разрядная версии)
  • Windows Server 2012 (только 64-разрядная версия)
  • Windows Server 2012 R2 (только 64-разрядная версия)
  • Windows Server 2016 (только 64-разрядная версия)
  • Windows Server 2019 (только 64-разрядная версия)
  • Windows Server 2022 (только 64-разрядная версия)
  • Windows 10
  • Windows 11
  • macOS версии 10.11 или более поздней
  • Linux (StrongSwan)
  • iOS

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

Azure поддерживает три варианта VPN-подключения типа "точка — сеть":

  • По протоколу SSTP (Secure Sockets Tunneling Protocol). SSTP — это разработанное корпорацией Майкрософт решение на основе SSL, которое позволяет проходить через брандмауэры, так как большинство брандмауэров открывают для SSL исходящий TCP-порт 443.

  • OpenVPN. OpenVPN — это решение на основе SSL, которое позволяет проходить через брандмауэры, так как большинство брандмауэров открывают для SSL исходящий TCP-порт 443.

  • По протоколу IKEv2 для VPN. IKEv2 для VPN — это стандартное решение для VPN-подключения IPsec, которое использует исходящие порты UDP 500 и 4500, а также протокол IP 50. Эти порты не всегда открываются в брандмауэре, поэтому есть вероятность, что IKEv2 для VPN не сможет пройти через прокси-серверы и брандмауэры.

Переподключится ли виртуальная частная сеть автоматически при перезагрузке клиентского компьютера, настроенного для подключения «точка-сеть»?

Автоматическое переподключение — это функция используемого клиента. В Windows автоматическое переподключение поддерживается с помощью функции клиента Always On VPN.

Поддерживает ли подключение "точка — сеть" DDNS для VPN-клиентов?

Сейчас DDNS не поддерживается в VPN-подключениях "точка — сеть".

Могут ли сосуществовать в одной виртуальной сети конфигурации "сеть — сеть" и "точка — сеть"?

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

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

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

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

Да, клиентские подключения "точка — сеть" к шлюзу виртуальной сети, развернутому в сети с пиринговым подключением к другим виртуальным сетям, могут иметь доступ к другим одноранговым виртуальным сетям. Если одноранговые виртуальные сети используют функции UseRemoteGateway или AllowGatewayTransit, клиенты с подключением "точка — сеть" смогут подключаться к этим сетям. Дополнительные сведения см. в статье Сведения о маршрутизации "точка — сеть".

На какую пропускную способность можно рассчитывать в конфигурациях подключения "сеть — сеть" и "точка — сеть"?

Сложно поддерживать конкретную пропускную способность для туннелей VPN. IPsec и SSTP — это надежно зашифрованные протоколы VPN. Пропускная способность также зависит от задержки и пропускной способности между локальной сетью и Интернетом. Для VPN-шлюза, который используется только для VPN-подключений типа "точка — сеть" по протоколу IKEv2, общая пропускная способность зависит от ценовой категории шлюза. Дополнительные сведения о пропускной способности см. в статье о номерах SKU шлюзов.

Можно ли использовать для подключения "точка — сеть" любой программный VPN-клиент, поддерживающий SSTP и (или) IKEv2?

Нет. Вы можете использовать только собственный VPN-клиент для SSTP в Windows и собственный VPN-клиент для IKEv2 в Mac. Но для подключения по протоколу OpenVPN можно использовать клиент OpenVPN на любой платформе. См. список поддерживаемых клиентских операционных систем.

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

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

Azure поддерживает протокол IKEv2 для VPN в Windows?

IKEv2 поддерживается в Windows 10 и Server 2016. Однако для использования IKEv2 в некоторых версиях операционных систем необходимо установить обновления и задать значение раздела реестра локально. Версии операционной системы до Windows 10 не поддерживаются и могут использовать только протокол SSTP или OpenVPN®.

Примечание

Эти действия не нужно выполнять в сборках ОС Windows новее, чем Windows 10 версии 1709 и Windows Server 2016 версии 1607.

Чтобы подготовить Windows 10 или Server 2016 IKEv2:

  1. Установите обновление в зависимости от используемой версии ОС.

    Версия ОС Дата Номер или ссылка
    Windows Server 2016
    Windows 10 версии 1607
    17 января 2018 г. KB4057142
    Windows 10 версии 1703 17 января 2018 г. KB4057144
    Windows 10 версии 1709 22 марта 2018 г. KB4089848
  2. Установите значение раздела реестра. Создайте или задайте для ключа REG_DWORD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\ IKEv2\DisableCertReqPayload" в реестре значение 1.

Каков ограничение селектора трафика IKEv2 для подключений "точка — сеть"?

Для Windows 10 версии 2004 (выпущено в сентябре 2021 г.) ограничение селектора трафика увеличено до 255. В предыдущих версиях Windows ограничение селектора трафика составляет 25.

Ограничение селекторов трафика в Windows определяет максимальное количество адресных пространств в виртуальной сети и максимальную сумму локальных сетей, подключений между виртуальными сетями и одноранговых виртуальных сетей, подключенных к шлюзу. Клиенты с подключением типа "точка — сеть" на базе Windows не смогут подключиться через IKEv2, если они превысят это ограничение.

Что произойдет, если настроить и SSTP, и IKEv2 для подключений VPN типа "точка — сеть"?

При настройке SSTP и IKEv2 в смешанной среде (состоящей из устройств Windows и Mac) VPN-клиент Windows будет сначала пытаться подключиться к туннелю IKEv2, но если не удастся установить подключение IKEv2, подключится к SSTP. MacOSX подключится только через IKEv2.

Какие еще платформы, кроме Windows и Mac, Azure поддерживает для VPN-подключений типа "точка — сеть"?

Azure поддерживает VPN-подключения "точка — сеть" в Windows, Mac и Linux.

У меня уже развернут VPN-шлюз Azure. Можно ли включить на нем RADIUS и/или IKEv2 для VPN?

Да, если используемая ценовая категория шлюза поддерживает RADIUS и (или) IKEv2, эти новые функции можно включить для уже развернутых шлюзов с помощью PowerShell или портала Azure. Ценовая категория "Базовый" не поддерживает ни RADIUS, ни IKEv2.

Как удалить конфигурацию подключения "точка — сеть"?

Эту конфигурацию можно удалить с помощью Azure CLI и PowerShell, используя следующие команды:

Azure PowerShell

$gw=Get-AzVirtualNetworkGateway -name <gateway-name>`  
$gw.VPNClientConfiguration = $null`  
Set-AzVirtualNetworkGateway -VirtualNetworkGateway $gw`

Azure CLI

az network vnet-gateway update --name <gateway-name> --resource-group <resource-group name> --remove "vpnClientConfiguration"

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

Снимите флажок Подтверждать удостоверение сервера с помощью проверки сертификата или добавьте FQDN сервера вместе с сертификата при создании профиля вручную. Это можно сделать, выполнив команду rasphone в командной строке. Затем нужно выбрать профиль в раскрывающемся списке.

Обход проверки удостоверения сервера в целом не рекомендуется, но при проверке подлинности на основе сертификата Azure для проверки сервера в протоколе туннелирования VPN (IKEv2/SSTP) и протоколе EAP используется один и тот же сертификат. Так как сертификат сервера и FQDN уже проверены протоколом туннелирования VPN, повторная проверка в EAP не требуется.

проверка подлинности типа

Можно ли с помощью корневого ЦС собственной внутренней системы PKI создать сертификаты для подключения "точка — сеть"?

Да. Раньше поддерживались только самозаверяющие корневые сертификаты. Вы по-прежнему можете загружать до 20 корневых сертификатов.

Можно ли использовать сертификаты из Azure Key Vault?

Нет.

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

Можно использовать решение Enterprise PKI (внутренняя инфраструктура открытых ключей), Azure PowerShell, MakeCert и OpenSSL.

Есть инструкции по выбору параметров сертификата?

  • Внутренняя инфраструктура открытых ключей и решение Enterprise PKI: см. инструкции по созданию сертификатов.

  • Azure PowerShell: см. инструкции по работе с Azure PowerShell.

  • MakeCert: см. инструкции по работе с MakeCert.

  • OpenSSL:

    • При экспорте сертификатов преобразуйте корневой сертификат в кодировку Base64.

    • Для сертификата клиента:

      • При создании закрытого ключа укажите длину 4096.
      • При создании сертификата для параметра -extensions укажите значение usr_cert.

Подключения "точка — сеть" и проверка подлинности RADIUS

Этот раздел посвящен модели развертывания с помощью Resource Manager.

Сколько конечных точек VPN-клиента можно иметь в конфигурации «точка-сеть»?

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

Какие клиентские операционные системы можно использовать для подключения "точка — сеть"?

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

  • Windows Server 2008 R2 (только 64-разрядная версия)
  • Windows 8.1 (32-разрядная и 64-разрядная версии)
  • Windows Server 2012 (только 64-разрядная версия)
  • Windows Server 2012 R2 (только 64-разрядная версия)
  • Windows Server 2016 (только 64-разрядная версия)
  • Windows Server 2019 (только 64-разрядная версия)
  • Windows Server 2022 (только 64-разрядная версия)
  • Windows 10
  • Windows 11
  • macOS версии 10.11 или более поздней
  • Linux (StrongSwan)
  • iOS

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

Azure поддерживает три варианта VPN-подключения типа "точка — сеть":

  • По протоколу SSTP (Secure Sockets Tunneling Protocol). SSTP — это разработанное корпорацией Майкрософт решение на основе SSL, которое позволяет проходить через брандмауэры, так как большинство брандмауэров открывают для SSL исходящий TCP-порт 443.

  • OpenVPN. OpenVPN — это решение на основе SSL, которое позволяет проходить через брандмауэры, так как большинство брандмауэров открывают для SSL исходящий TCP-порт 443.

  • По протоколу IKEv2 для VPN. IKEv2 для VPN — это стандартное решение для VPN-подключения IPsec, которое использует исходящие порты UDP 500 и 4500, а также протокол IP 50. Эти порты не всегда открываются в брандмауэре, поэтому есть вероятность, что IKEv2 для VPN не сможет пройти через прокси-серверы и брандмауэры.

Переподключится ли виртуальная частная сеть автоматически при перезагрузке клиентского компьютера, настроенного для подключения «точка-сеть»?

Автоматическое переподключение — это функция используемого клиента. В Windows автоматическое переподключение поддерживается с помощью функции клиента Always On VPN.

Поддерживает ли подключение "точка — сеть" DDNS для VPN-клиентов?

Сейчас DDNS не поддерживается в VPN-подключениях "точка — сеть".

Могут ли сосуществовать в одной виртуальной сети конфигурации "сеть — сеть" и "точка — сеть"?

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

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

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

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

Да, клиентские подключения "точка — сеть" к шлюзу виртуальной сети, развернутому в сети с пиринговым подключением к другим виртуальным сетям, могут иметь доступ к другим одноранговым виртуальным сетям. Если одноранговые виртуальные сети используют функции UseRemoteGateway или AllowGatewayTransit, клиенты с подключением "точка — сеть" смогут подключаться к этим сетям. Дополнительные сведения см. в статье Сведения о маршрутизации "точка — сеть".

На какую пропускную способность можно рассчитывать в конфигурациях подключения "сеть — сеть" и "точка — сеть"?

Сложно поддерживать конкретную пропускную способность для туннелей VPN. IPsec и SSTP — это надежно зашифрованные протоколы VPN. Пропускная способность также зависит от задержки и пропускной способности между локальной сетью и Интернетом. Для VPN-шлюза, который используется только для VPN-подключений типа "точка — сеть" по протоколу IKEv2, общая пропускная способность зависит от ценовой категории шлюза. Дополнительные сведения о пропускной способности см. в статье о номерах SKU шлюзов.

Можно ли использовать для подключения "точка — сеть" любой программный VPN-клиент, поддерживающий SSTP и (или) IKEv2?

Нет. Вы можете использовать только собственный VPN-клиент для SSTP в Windows и собственный VPN-клиент для IKEv2 в Mac. Но для подключения по протоколу OpenVPN можно использовать клиент OpenVPN на любой платформе. См. список поддерживаемых клиентских операционных систем.

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

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

Azure поддерживает протокол IKEv2 для VPN в Windows?

IKEv2 поддерживается в Windows 10 и Server 2016. Однако для использования IKEv2 в некоторых версиях операционных систем необходимо установить обновления и задать значение раздела реестра локально. Версии операционной системы до Windows 10 не поддерживаются и могут использовать только протокол SSTP или OpenVPN®.

Примечание

Эти действия не нужно выполнять в сборках ОС Windows новее, чем Windows 10 версии 1709 и Windows Server 2016 версии 1607.

Чтобы подготовить Windows 10 или Server 2016 IKEv2:

  1. Установите обновление в зависимости от используемой версии ОС.

    Версия ОС Дата Номер или ссылка
    Windows Server 2016
    Windows 10 версии 1607
    17 января 2018 г. KB4057142
    Windows 10 версии 1703 17 января 2018 г. KB4057144
    Windows 10 версии 1709 22 марта 2018 г. KB4089848
  2. Установите значение раздела реестра. Создайте или задайте для ключа REG_DWORD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\ IKEv2\DisableCertReqPayload" в реестре значение 1.

Каков ограничение селектора трафика IKEv2 для подключений "точка — сеть"?

Для Windows 10 версии 2004 (выпущено в сентябре 2021 г.) ограничение селектора трафика увеличено до 255. В предыдущих версиях Windows ограничение селектора трафика составляет 25.

Ограничение селекторов трафика в Windows определяет максимальное количество адресных пространств в виртуальной сети и максимальную сумму локальных сетей, подключений между виртуальными сетями и одноранговых виртуальных сетей, подключенных к шлюзу. Клиенты с подключением типа "точка — сеть" на базе Windows не смогут подключиться через IKEv2, если они превысят это ограничение.

Что произойдет, если настроить и SSTP, и IKEv2 для подключений VPN типа "точка — сеть"?

При настройке SSTP и IKEv2 в смешанной среде (состоящей из устройств Windows и Mac) VPN-клиент Windows будет сначала пытаться подключиться к туннелю IKEv2, но если не удастся установить подключение IKEv2, подключится к SSTP. MacOSX подключится только через IKEv2.

Какие еще платформы, кроме Windows и Mac, Azure поддерживает для VPN-подключений типа "точка — сеть"?

Azure поддерживает VPN-подключения "точка — сеть" в Windows, Mac и Linux.

У меня уже развернут VPN-шлюз Azure. Можно ли включить на нем RADIUS и/или IKEv2 для VPN?

Да, если используемая ценовая категория шлюза поддерживает RADIUS и (или) IKEv2, эти новые функции можно включить для уже развернутых шлюзов с помощью PowerShell или портала Azure. Ценовая категория "Базовый" не поддерживает ни RADIUS, ни IKEv2.

Как удалить конфигурацию подключения "точка — сеть"?

Эту конфигурацию можно удалить с помощью Azure CLI и PowerShell, используя следующие команды:

Azure PowerShell

$gw=Get-AzVirtualNetworkGateway -name <gateway-name>`  
$gw.VPNClientConfiguration = $null`  
Set-AzVirtualNetworkGateway -VirtualNetworkGateway $gw`

Azure CLI

az network vnet-gateway update --name <gateway-name> --resource-group <resource-group name> --remove "vpnClientConfiguration"

Поддерживается ли аутентификация RADIUS во всех номерах SKU VPN-шлюзов Azure?

Проверка подлинности RADIUS поддерживается для всех номеров SKU, кроме номера SKU "Базовый".

Из устаревших ценовых категорий проверка подлинности RADIUS поддерживается только для категорий "Стандартный" и "Высокопроизводительный". Она не поддерживается для шлюзов с ценовой категорией "Базовый".

Поддерживается ли аутентификация RADIUS в классической модели развертывания?

Нет. Проверка подлинности RADIUS не поддерживается в классической модели развертывания.

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

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

Поддерживаются ли сторонние серверы RADIUS?

Да, сторонние серверы RADIUS поддерживаются.

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

Требуется VPN-подключение "сеть — сеть" к локальному сайту с правильно настроенными маршрутами.

Может ли трафик направляться на локальный сервер RADIUS (из VPN-шлюза Azure) через подключение ExpressRoute?

Нет. Он может направляться только через подключение "сеть — сеть".

Изменилось ли количество поддерживаемых SSTP-подключений с аутентификацией RADIUS? Каково максимальное количество поддерживаемых SSTP- и IKEv2-подключений?

Количество поддерживаемых шлюзом SSTP-подключений с аутентификацией RADIUS не менялось. По-прежнему доступно 128 подключений по протоколу SSTP, но их количество зависит от SKU шлюза для IKEv2. Дополнительные сведения о количестве поддерживаемых подключений см. в разделе SKU шлюзов.

В чем разница между проверкой подлинности на основе сертификата с использованием сервера RADIUS и собственной проверкой подлинности Azure на основе сертификата (путем передачи доверенного сертификата в Azure)?

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

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

Работает ли аутентификация RADIUS с IKEv2 и SSTP для VPN?

Да, аутентификация RADIUS поддерживается для IKEv2 и SSTP для VPN.

Работает ли аутентификация RADIUS с клиентом OpenVPN?

Протокол OpenVPN поддерживает аутентификацию RADIUS.

Подключения типа "виртуальная сеть — виртуальная сеть" и многосайтовые подключения

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

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

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

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

Нет. Трафик между виртуальными сетями проходит через магистральную сеть Microsoft Azure, а не через Интернет.

Можно ли установить подключение "виртуальная сеть – виртуальная сеть" между клиентами Azure Active Directory (AAD)?

Да, подключения "виртуальная сеть – виртуальная сеть" с использованием VPN-шлюзов Azure работают между клиентами Azure AD.

Защищен ли трафик между двумя виртуальными сетями?

Да. Он защищен шифрованием IPsec/IKE.

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

Нет. Для подключения нескольких виртуальных сетей Azure друг к другу не нужно VPN-устройство, если только не требуется распределенное подключение.

Должны ли мои виртуальные сети находиться в одном регионе?

Нет. Виртуальные сети могут быть в одном или разных регионах (расположениях) Azure.

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

Нет.

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

Нет. Подключения между виртуальными сетями поддерживаются только в пределах одного экземпляра Azure. Например, невозможно создать подключение между общедоступным облаком Azure и экземплярами Azure для государственных организаций Китая, Германии или США. В этих сценариях рекомендуется использовать VPN-подключение типа "сеть – сеть".

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

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

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

См. таблицу Требования к шлюзу.

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

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

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

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

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

Нет. Для подключений типа "виртуальная сеть – виртуальная сеть" и многосайтовых подключений необходимы VPN-шлюзы Azure с VPN типа RouteBased (этот тип раньше назывался динамической маршрутизацией).

Могу ли я подключить виртуальную сеть с типом VPN RouteBased к другой виртуальной сети с типом VPN PolicyBased?

Нет, обе виртуальные сети ДОЛЖНЫ использовать VPN-шлюзы на основе маршрутов (этот тип раньше назывался динамической маршрутизацией).

Используют ли VPN-туннели пропускную способность совместно?

Да. Все туннели VPN виртуальной сети совместно используют доступную пропускную способность VPN-шлюза Azure и одно соглашение об уровне обслуживания VPN-шлюзов в Azure.

Поддерживаются ли избыточные туннели?

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

Могут ли перекрываться адресные пространства для конфигураций типа "виртуальная сеть — виртуальная сеть"?

Нет. Нельзя, чтобы диапазоны IP-адресов перекрывались.

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

Нет. Нельзя, чтобы диапазоны IP-адресов перекрывались.

Как включить маршрутизацию между VPN-подключением типа "сеть — сеть" и ExpressRoute?

Если вы хотите включить маршрутизацию между ветвью, подключенной к ExpressRoute, и ветвью, подключенной к VPN типа "сеть — сеть", вам необходимо настроить Azure Route Server.

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

Модель развертывания диспетчера ресурсов
Да. Дополнительные сведения см. в разделе, посвященном BGP.

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

Создает ли Azure один общий ключ IPsec/IKE для всех VPN-подключений для той же виртуальной сети?

Нет. По умолчанию Azure создает разные общие ключи для разных VPN-подключений. Но можно использовать командлет Set VPN Gateway Key API REST или PowerShell, чтобы задать ключ VPN-шлюза и установить собственное значение ключа. Ключ ДОЛЖЕН содержать только печатные символы ASCII, за исключением пробела, дефиса (-) и тильды (~).

Смогу ли я увеличить пропускную способность, если вместо одной виртуальной сети буду использовать VPN "точка — сеть"?

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

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

Да, но необходимо настроить BGP для обоих туннелей к тому же расположению.

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

Да, VPN-шлюз Azure будет учитывать путь AS, добавляемый в начало, чтобы облегчить принятие решений о маршрутизации при включенном BGP. При выборе пути BGP будет предпочтительнее более короткий путь AS.

Можно ли использовать свойство RoutingWeight при создании нового VPN-подключения VirtualNetworkGateway?

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

Можно ли использовать VPN "точка — сеть" с виртуальной сетью с несколькими VPN-туннелями?

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

Можно ли подключить виртуальную сеть с VPN IPsec к каналу ExpressRoute?

Да, это поддерживается. Дополнительные сведения см. в статье Настройка сосуществующих подключений ExpressRoute и VPN "сеть — сеть".

Политика IPsec/IKE

Поддерживается ли политика IPsec/IKE во всех номерах SKU VPN-шлюзов Azure?

Пользовательская политика IPsec/IKE поддерживается во всех SKU Azure, за исключением SKU "Базовый".

Сколько политик можно указать для подключения?

Можно указать только одну комбинацию политик для каждого подключения.

Можно ли указать частичную политику для подключения (например, только алгоритмы IKE без IPsec)?

Нет, следует указать все алгоритмы и параметры для IKE (основной режим) и IPsec (быстрый режим). Указать частичную спецификацию политики невозможно.

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

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

IPsec/IKEv2 Параметры
Шифрование IKEv2 GCMAES256, GCMAES128, AES256, AES192, AES128, DES3, DES
Проверка целостности IKEv2 GCMAES256, GCMAES128, SHA384, SHA256, SHA1, MD5
Группа DH DHGroup24, ECP384, ECP256, DHGroup14 (DHGroup2048), DHGroup2, DHGroup1, нет
Шифрование IPsec GCMAES256, GCMAES192, GCMAES128, AES256, AES192, AES128, DES3, DES, нет
Целостность IPsec GCMAES256, GCMAES192, GCMAES128, SHA256, SHA1, MD5
Группа PFS PFS24, ECP384, ECP256, PFS2048, PFS2, PFS1, нет
Время существования QM SA Секунды (целое число, минимум 300, по умолчанию — 27 000 с)
Килобайты (целое число, минимум 1024, по умолчанию — 102 400 000 КБ)
Селектор трафика UsePolicyBasedTrafficSelectors ($True/$False; по умолчанию — $False)

Важно!

  • DHGroup2048 и PFS2048 — это такие же группы, как и группа Диффи-Хелмана 14 в протоколе IKE и IPsec PFS. Полное сопоставление см. в разделе о группах Диффи — Хелмана.
  • В алгоритмах GCMAES необходимо указать одинаковую длину ключа и алгоритма для шифрования и целостности данных IPsec.
  • Время существования SA основного режима IKEv2 составляет 28 800 секунд на VPN-шлюзах Azure.
  • Время существования QM SA указывать необязательно. Если эти значения не указаны, по умолчанию используются значения 27 000 с (7,5 ч) и 102 400 000 КБ (102 ГБ).
  • UsePolicyBasedTrafficSelector — это необязательный параметр при подключении. Чтобы получить информацию о параметре UsePolicyBasedTrafficSelectors, см. следующий вопрос и ответ.

Должны ли политика VPN-шлюза Azure и мои конфигурации локальных VPN-устройств полностью совпадать?

Ваша конфигурация локальных VPN-устройств должна совпадать со следующими алгоритмами и параметрами, указанными в политике Azure IPsec/IKE, или содержать их.

  • Алгоритм шифрования IKE
  • Алгоритм проверки целостности IKE
  • Группа DH
  • Алгоритм шифрования IPsec
  • Алгоритм проверки целостности IPsec
  • Группа PFS
  • Селектор трафика ( * )

Время существования SA определяется исключительно локальными спецификациями, и эти значения не обязаны совпадать.

Если вы включили параметр UsePolicyBasedTrafficSelectors, необходимо обеспечить соответствующие селекторы трафика для VPN-устройства, которые определены с помощью всех комбинаций префиксов локальной сети (шлюза локальной сети) с префиксами виртуальной сети Azure, а не разрешать совпадение любого префикса с любым. Например, если префиксы локальной сети — 10.1.0.0/16 и 10.2.0.0/16, а префиксы виртуальной сети — 192.168.0.0/16 и 172.16.0.0/16, необходимо указать следующие селекторы трафика:

  • 10.1.0.0/16 <====> 192.168.0.0/16
  • 10.1.0.0/16 <====> 172.16.0.0/16
  • 10.2.0.0/16 <====> 192.168.0.0/16
  • 10.2.0.0/16 <====> 172.16.0.0/16

Дополнительные сведения см. в статье Подключение VPN-шлюзов Azure к нескольким локальным VPN-устройствам на основе политики с помощью PowerShell.

Поддерживаемые группы Диффи-Хелмана

В таблице ниже перечислены поддерживаемые группы Диффи-Хелмана для протокола IKE (DHGroup) и IPsec (PFSGroup).

Группа Диффи-Хелмана DHGroup PFSGroup Длина ключа
1 DHGroup1 PFS1 MODP (768 бит)
2 DHGroup2 PFS2 MODP (1024 бит)
14 DHGroup14
DHGroup2048
PFS2048 MODP (2048 бит)
19 ECP256 ECP256 ECP (256 бит)
20 ECP384 ECP384 ECP (384 бит)
24 DHGroup24 PFS24 MODP (2048 бит)

Дополнительные сведения см. на страницах RFC 3526 и RFC 5114.

Заменяет ли настраиваемая политика стандартные наборы политик IPsec/IKE для VPN-шлюзов Azure?

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

Если удалить настраиваемую политику IPsec/IKE, подключение становится незащищенным?

Нет, подключение будет по-прежнему защищено с помощью IPsec/IKE. После удаления настраиваемой политики из подключения VPN-шлюз Azure вернется к списку предложений IPsec/IKE по умолчанию и возобновит подтверждение IKE для локального VPN-устройства.

Прерывается ли VPN-подключение при добавлении или обновлении политики IPsec/IKE?

Да, это может привести к небольшому прерыванию работы (на несколько секунд), так как VPN-шлюз Azure будет прерывать существующее подключение и повторно запускать подтверждение IKE, чтобы повторно настроить туннель IPsec с новыми алгоритмами и параметрами шифрования. Чтобы минимизировать длительность прерывания, настройте для локального VPN-устройства совпадающие алгоритмы и уровни стойкости ключей.

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

Да. Настраиваемая политика применяется на уровне подключения. Можно создавать и применять разные политики IPsec/IKE для разных подключений. Можно также применять настраиваемые политики к подмножеству подключений. Оставшиеся подключения используют стандартные наборы политик IPsec/IKE Azure.

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

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

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

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

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

Время ожидания DPD по умолчанию составляет 45 секунд. Можно указать другое значение времени ожидания DPD для каждого подключения IPsec или виртуальной сети в диапазоне от 9 до 3600 секунд.

Работает ли настраиваемая политика IPsec/IKE для подключения ExpressRoute?

Нет. Политика IPsec/IKE работает только для VPN-подключений типа "сеть — сеть" или "виртуальная сеть — виртуальная сеть" через VPN-шлюзы Azure.

Как создавать подключения с типом протокола IKEv1 или IKEv2?

Подключения IKEv1 можно создавать во всех SKU с VPN типа RouteBased, кроме SKU уровня "Базовый" и "Стандартный" и других устаревших SKU. При создании подключения можно указать тип протокола IKEv1 или IKEv2. Если тип протокола не указан, по умолчанию используется тип IKEv2 (там, где это применимо). Дополнительные сведения см. в документации по командлетам PowerShell. Сведения о типах SKU и поддержке протоколов IKEv1 и IKEv2 см. в статье о подключении шлюзов к VPN-устройствам на базе политик.

Можно ли перейти с подключения IKEv1 на IKEv2 и обратно?

Да. Переход между типами подключений IKEv1 и IKEv2 поддерживается.

Можно ли использовать межсайтовые подключения IKEv1 на SKU категории "Базовый" с VPN типа RouteBased?

Нет. Ценовая категория "Базовый" не поддерживает эту возможность.

Можно ли сменить тип протокола после создания подключения (с IKEv1 на IKEv2 или обратно)?

Нет. Изменить тип протокола IKEv1 или IKEv2 после создания подключения невозможно. Вам потребуется удалить и снова создать подключение с протоколом нужного типа.

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

Если подключение IKEv1 со статической маршрутизацией или на основе маршрутов отключается через регулярные интервалы, это может быть связано с тем, что VPN-шлюзы не поддерживают переназначение ключей без отключения. Когда выполняется переназначение ключей для основного режима, туннели IKEv1 будут отключены и подключены снова, что может потребовать до 5 секунд. Значение времени ожидания для согласования основного режима определяет частоту переназначения ключей. Чтобы предотвратить такие повторные подключения, переключитесь на использование протокола IKEv2, который поддерживает переназначение ключей без отключения.

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

Где можно найти дополнительные сведения о конфигурации для IPsec?

См. статью Настройка политики IPsec/IKE для подключений "сеть — сеть" или "виртуальная сеть — виртуальная сеть".

BGP и маршрутизация

VPN-шлюзы Azure поддерживают BGP для всех классов SKU?

Протокол BGP поддерживается для всех SKU VPN-шлюза Azure, за исключением SKU уровня "Базовый".

Можно ли использовать BGP с VPN-шлюзами на основе Политики Azure?

Нет, BGP поддерживает только VPN-шлюзы с управлением на основе маршрута.

Какие номера ASN можно использовать?

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

Следующие номера ASN зарезервированы для Azure и IANA.

  • Номера ASN, зарезервированные для Azure:

    • общедоступные ASN — 8074, 8075, 12076;
    • частные ASN — 65515, 65517, 65518, 65519, 65520.
  • Номера ASN, зарезервированные для IANA:

    • 23456, 64496-64511, 65535-65551 и 429496729.

При подключении к VPN-шлюзам Azure эти номера ASN нельзя указывать для локальных VPN-устройств.

Можно ли использовать 32-разрядный (4-байтовый) номер ASN?

Да, VPN-шлюз теперь поддерживает 32-разрядный (4-байтовый) номер ASN. Чтобы выполнить настройку с помощью ASN в десятичном формате, используйте PowerShell, Azure CLI или пакет Azure SDK.

Какие частные ASN можно использовать?

Доступные диапазоны частных ASN:

  • 64512–65514 и 65521–65534

Эти ASN не зарезервированы для использования IANA или Azure, поэтому их можно назначить VPN-шлюзу Azure.

Какой адрес VPN-шлюз использует в качестве IP-адреса узла BGP?

По умолчанию VPN-шлюз выделяет из диапазона GatewaySubnet один IP-адрес для VPN-шлюзов в режиме "активный — резервный" или два IP-адреса для VPN-шлюзов в режиме "активный — активный". Эти адреса выделяются автоматически при создании VPN-шлюза. Вы можете получить фактический выделенный IP-адрес BGP с помощью PowerShell или на портале Azure. В PowerShell используйте Get-AzVirtualNetworkGateway и найдите свойство bgpPeeringAddress. На портале Azure на странице Конфигурация шлюза просмотрите свойство Настройка BGP ASN.

Если локальные маршрутизаторы VPN используют IP-адреса APIPA (169.254.x.x) в качестве IP-адресов BGP, необходимо указать один или более IP-адресов BGP APIPA Azure на VPN-шлюзе Azure. VPN-шлюз Azure выберет адреса APIPA для использования с локальным узлом BGP APIPA, указанным в шлюзе локальной сети, или частным IP-адресом для локального узла BGP, не связанного с APIPA. См. статью Настройка BGP на VPN-шлюзах Azure.

Каковы требования к IP-адресам узла BGP на VPN-устройстве?

Локальный узел BGP не должен иметь общедоступный IP-адрес VPN-устройства или входить в диапазон IP-адресов виртуальной сети VPN-шлюза. Используйте в качестве IP-адреса узла BGP другой IP-адрес VPN-устройства. Это может быть адрес, назначенный интерфейсу внутреннего замыкания на устройстве (обычный IP-адрес или адрес APIPA). Если устройство использует для BGP адрес APIPA, необходимо указать один или несколько IP-адресов BGP APIPA на VPN-шлюзе Azure, как описано в статье Настройка BGP. Укажите эти адреса на локальном сетевом шлюзе, который представляет это расположение.

Что нужно указать в качестве префикса адреса локального сетевого шлюза, если используется BGP?

Важно!

Это изменение из задокументированного ранее требования. При использовании BGP для подключения следует оставить поле Адресное пространство пустым для соответствующего ресурса шлюза локальной сети. VPN-шлюз Azure добавит маршрут узла в IP-адрес локального узла BGP через туннель IPsec. Не добавляйте маршрут /32 в поле Диапазон адресов. Он является избыточным. Если вы используете адрес APIPA в качестве IP-адреса BGP VPN-устройства, его нельзя добавлять в это поле. Другие префиксы будут добавлены в поле Диапазон адресов как статические маршруты на VPN-шлюзе Azure, наряду с маршрутами, полученными через BGP.

Можно ли использовать один номер ASN одновременно для локальных VPN-сетей и виртуальных сетей Azure?

Нет, следует назначить различные ASN для локальных сетей и виртуальных сетей Azure, если они обмениваются данными с использованием BGP. VPN-шлюзы Azure по умолчанию получают значение ASN 65515, независимо от использования BGP для подключений между локальными сетями. Вы можете переопределить это значение по умолчанию, назначив другой номер ASN при создании VPN-шлюза или изменив его после создания шлюза. Номер ASN, который используется для локальной сети, нужно будет назначить соответствующему локальному сетевому шлюзу Azure.

Какие префиксы адресов будут объявлять для меня VPN-шлюзы Azure?

VPN-шлюз объявляет следующие маршруты для локальных устройств BGP:

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

Сколько префиксов можно объявлять VPN-шлюзу Azure?

VPN-шлюз Azure поддерживает до 4000 префиксов. Если количество префиксов превысит лимит, сеанс BGP будет сброшен.

Можно ли объявить маршрут по умолчанию (0.0.0.0/0) к VPN-шлюзам Azure?

Да. Обратите внимание, что в результате весь исходящий трафик виртуальной сети будет направлен на локальный сайт. Кроме того, виртуальные машины в виртуальной сети не смогут принимать общедоступный трафик из Интернета напрямую, например RDP или SSH из Интернета на виртуальные машины.

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

Нет. Azure будет блокировать или фильтровать объявление таких же префиксов, как префиксы адреса виртуальной сети. Тем нее менее вы можете объявить префикс, который представляет собой супермножество адресов внутри виртуальной сети.

Например, если ваша виртуальная сеть использует адресное пространство 10.0.0.0/16, вы можете объявить 10.0.0.0/8. При этом нельзя объявлять 10.0.0.0/16 или 10.0.0.0/24.

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

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

Можно ли сочетать подключения с BGP и подключения без BGP на VPN-шлюзах Azure?

Да, вы можете использовать подключения с BGP и без BGP на одном VPN-шлюзе Azure.

Поддерживает ли VPN-шлюз Azure транзитную маршрутизацию BGP?

Да, транзитная маршрутизация BGP поддерживается, но с одним исключением: VPN-шлюзы Azure не будут объявлять маршруты по умолчанию для других узлов BGP. Чтобы включить транзитную маршрутизацию между несколькими VPN-шлюзами Azure, необходимо включить BGP на всех промежуточных подключениях между виртуальными сетями. Дополнительные сведения см. в статье Обзор использования BGP с VPN-шлюзами Azure.

Можно ли создать несколько туннелей между VPN-шлюзом Azure и локальной сетью?

Да, вы можете создать несколько VPN-туннелей типа "сеть – сеть" (S2S) между VPN-шлюзом Azure и локальной сетью. Обратите внимание, что все эти туннели будут учитываться в общем числе туннелей на ваших VPN-шлюзах Azure. Кроме того, вы должны включить BGP для обоих туннелей.

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

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

Да, но хотя бы один из шлюзов виртуальной сети должен быть в конфигурации "активный — активный".

Можно ли использовать BGP для S2S VPN в конфигурации сосуществования ExpressRoute и S2S VPN?

Да.

Что следует добавить в настройки локального VPN-устройства для сеансов пиринга BGP?

Добавьте маршрут узла для IP-адреса узла BGP Azure на VPN-устройство. Этот маршрут указывает на туннель S2S VPN IPsec. Например если IP-адрес VPN-узла Azure имеет значение 10.12.255.30, добавьте для адреса 10.12.255.30 узловой маршрут, в котором интерфейсом следующего прыжка будет соответствующий интерфейс туннелирования IPsec на VPN-устройстве.

Поддерживает ли шлюз виртуальной сети BFD для подключений S2S с BGP?

Нет. Двухнаправленное обнаружение перенаправления (BFD) — это протокол, который можно использовать с BGP для определения времени простоя в соседних странах быстрее, чем при использовании стандартной проверки активности BGP ("keepalives"). BFD использует таймеры с точностью измерения до доли секунды, предназначенные для работы в среде LAN, но не с подключениями через общедоступный Интернет или глобальную сеть.

Для подключений через общедоступный Интернет задержка отправки или даже удаление определенных пакетов не является необычным, поэтому внедрение этих агрессивных таймеров приведет к нестабильной работе. Такая нестабильность может привести к подавлению маршрутов протоколом BGP. В качестве альтернативы можно настроить локальное устройство с таймерами с частотой проверки активности менее 60 секунд и таймером удержания на 180 секунд. Это приводит к ускоренной конвергенции.

Инициируют ли VPN-шлюзы Azure сеансы пиринга или подключения BGP?

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

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

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

NAT

VPN-шлюзы Azure поддерживают NAT для всех классов SKU?

NAT поддерживается на VpnGw2~5 и VpnGw2AZ~5AZ.

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

Нет, NAT поддерживается только для распределенных подключений IPsec.

Сколько правил NAT можно использовать на VPN-шлюзе?

На VPN-шлюзе можно создать до 100 правил NAT (сочетание правил для входящего и исходящего трафика).

Можно ли использовать / в имени правила NAT?

Нет. Появится сообщение об ошибке.

Применяется ли NAT ко всем подключениям на VPN-шлюзе?

NAT применяется к подключениям с правилами NAT. Если у подключения нет правила NAT, NAT не будет действовать для этого подключения. На одном VPN-шлюзе можно одновременно использовать соединения с NAT и без NAT.

Какие типы NAT поддерживаются на VPN-шлюзах Azure?

Поддерживаются только статическое преобразование NAT 1:1 и динамическое преобразование NAT. NAT64 НЕ поддерживается.

Работает ли NAT на VPN-шлюзах «активный — активный»?

Да. NAT работает как в режиме «активный — активный", так и на VPN-шлюзах в режиме «в сети».

Работает ли NAT с подключениями BGP?

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

  • Выберите Включить преобразование маршрутов BGP на странице «Конфигурация правил NAT», чтобы полученные маршруты и объявляемые маршруты преобразовывались в префиксы адресов после NAT (внешние сопоставления) на основе правил NAT, связанных с соединениями. Необходимо убедиться, что локальные маршрутизаторы BGP объявляют точные префиксы, как определено в правилах IngressSNAT.

  • Если локальный VPN-маршрутизатор использует обычный адрес, отличный от APIPA, и конфликтует с адресным пространством виртуальной сети или другими локальными сетевыми пространствами, убедитесь, что правило IngressSNAT будет преобразовывать IP-адрес однорангового узла BGP в уникальный адрес без перекрытия и вставит адрес после NAT в поле IP-адрес однорангового узла BGP шлюза локальной сети.

  • NAT не поддерживается с адресами API BGP.

Нужно ли создавать правила DNAT, соответствующие правилу SNAT?

Нет. Одно правило SNAT определяет преобразование для обоих направлений определенной сети:

  • Правило IngressSNAT определяет преобразование исходных IP-адресов, поступающих в VPN-шлюз Azure из локальной сети. Оно также обрабатывает преобразование конечных IP-адресов, которые переходят из виртуальной сети в одну локальную сеть.

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

  • Ни в одном из этих случаев правила DNAT не требуются.

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

Необходимо создать по одному правилу NAT для каждого префикса, который требуется для преобразования сетевых адресов (NAT), так как каждое правило NAT может включать только один префикс адреса для NAT. Например, если адресное пространство шлюза локальной сети состоит из 10.0.1.0/24 и 10.0.2.0/25, можно создать два правила, как показано ниже.

  • Правило IngressSNAT 1: сопоставление 10.0.1.0/24 и 100.0.1.0/24
  • Правило IngressSNAT 2: сопоставление 10.0.2.0/25 и 100.0.2.0/25

Эти два правила должны соответствовать длинам префиксов соответствующих адресов. То же относится и к правилам EgressSNAT для адресного пространства виртуальной сети.

Важно!

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

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

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

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

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

Можно ли использовать одно правило IngressSNAT для разных подключений?

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

Нужно ли создавать для подключения NAT правила как для входящего, так и исходящего трафика?

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

Что выбрать в качестве идентификатора IP-конфигурации?

"Идентификатор IP-конфигурации" — это просто имя объекта IP-конфигурации, который будет использоваться правилом NAT. С помощью этого параметра вы просто выбираете, какой общедоступный IP-адрес шлюза применяется к правилу NAT. Если вы не указали пользовательское имя во время создания шлюза, основной IP-адрес шлюза назначается IP-конфигурации "по умолчанию", а дополнительный IP-адрес назначается IP-конфигурации "активный-активный".

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

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

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

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

Если виртуальная машина находится в виртуальной сети с распределенным подключением, проходит ли весь трафик с моей виртуальной машины через это подключение?

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

Устранение неполадок подключения к виртуальной машине через протокол удаленного рабочего стола

Если возникают проблемы при подключении к виртуальной машине через VPN-подключение, проверьте следующее.

  • Убедитесь, что вы используете активное VPN-подключение.
  • Убедитесь, что подключаетесь к частному IP-адресу виртуальной машины.
  • Если вы можете подключиться к виртуальной машине с помощью частного IP-адреса, но не имени компьютера, проверьте, правильно ли настроено имя DNS. Дополнительные сведения о том, как работает разрешение имен для виртуальных машин, см. в статье Разрешение имен для ВМ и экземпляров ролей.

При подключении типа "точка — сеть" проверьте следующие дополнительные элементы.

  • Используйте ipconfig, чтобы проверить IPv4-адрес, назначенный Ethernet-адаптеру на компьютере, с которого выполняется подключение. Если IP-адрес находится в диапазоне адресов виртуальной сети, к которой выполняется подключение, или в диапазоне адресов VPNClientAddressPool, адресное пространство перекрывается. В таком случае сетевой трафик не достигает Azure и остается в локальной сети.
  • Убедитесь, что пакет конфигурации VPN-клиента был создан после IP-адресов DNS-сервера, заданных для виртуальной сети. Если вы обновили IP-адреса DNS-сервера, создайте и установите новый пакет конфигурации VPN-клиента.

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

Часто задаваемые вопросы по виртуальной сети

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

Дальнейшие действия

  • Дополнительные сведения о VPN-шлюзах см. в этой статье.
  • Дополнительные сведения о параметрах конфигурации VPN-шлюза см. в этой статье.

OpenVPN является товарным знаком OpenVPN Inc.