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

Статья
03/26/2024

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

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

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

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

Да.

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

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

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

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

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

№ Однако плата за любые дополнительные общедоступные IP-адреса будет взиматься соответствующим образом. См . цены на IP-адреса.

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

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

Сеть — сеть. VPN-подключение по протоколу IPsec (протоколы IKEv1 и IKEv2). Для этого типа подключения требуется VPN-устройство или RRAS. Дополнительные сведения см. в статье Настройка подключения "сеть — сеть".
Точка — сеть. VPN-подключение по протоколу SSTP (Secure Socket Tunneling Protocol) или IKEv2. Для этого подключения не требуется VPN-устройство. Дополнительные сведения см. в статье Настройка подключения "точка — сеть".
Виртуальная сеть — виртуальная сеть. Этот тип подключения аналогичен конфигурации "сеть — сеть". Конфигурация «Виртуальная сеть — виртуальная сеть» — это VPN-подключение по протоколу IPsec (протоколы IK v1 и IKE v2). Для этого подключения не требуется VPN-устройство. Дополнительные сведения см. в статье Настройка подключения между виртуальными сетями на портале Azure.
ExpressRoute. ExpressRoute — это прямое подключение к Azure из глобальной сети, а не VPN-подключение через общедоступный Интернет. Дополнительные сведения см. в статьях Технический обзор ExpressRoute и Вопросы и ответы по ExpressRoute.

Дополнительные сведения о подключениях через 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 на основе политик и маршрутов?

По состоянию на 1 октября 2023 г. vpn-шлюз на основе политик нельзя создать через портал Azure. Все новые VPN-шлюзы будут автоматически созданы в качестве маршрутов. Если у вас уже есть шлюз на основе политик, вам не нужно обновлять шлюз до маршрутизации. Powershell/CLI можно использовать для создания шлюзов на основе политик.

Ранее старые номера SKU шлюза не поддерживали IKEv1 для шлюзов на основе маршрутов. Теперь большинство текущих номеров SKU шлюза поддерживают IKEv1 и IKEv2.

Тип VPN шлюза.	Gateway SKU	Поддерживаемые версии IKE
Шлюз на основе политик	Базовая	IKEv1
Шлюз на основе маршрутов	Базовая	IKEv2
Шлюз на основе маршрутов	VpnGw1, VpnGw2, VpnGw3, VpnGw4, VpnGw5	IKEv1 и IKEv2
Шлюз на основе маршрутов	VpnGw1AZ, VpnGw2AZ, VpnGw3AZ, VpnGw4AZ, VpnGw5AZ	IKEv1 и IKEv2

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

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

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

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

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

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

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

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

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

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

№

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

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

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

Ресурсы общедоступного IP-адреса SKU уровня "Стандартный" используют статический метод выделения. При создании нового VPN-шлюза необходимо использовать общедоступный IP-адрес SKU уровня "Стандартный". Это относится ко всем номерам SKU шлюза, кроме номера SKU "Базовый". Номер SKU шлюза "Базовый" в настоящее время поддерживает только общедоступные IP-адреса SKU уровня "Базовый". В ближайшее время мы добавим поддержку общедоступных IP-адресов SKU уровня "Стандартный" для SKU шлюза "Базовый".

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

Как использование общедоступного IP-адреса уровня SKU уровня "Базовый" влияет на vpn-шлюзы?

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

Однако важно отметить, что общедоступные IP-адреса SKU уровня "Базовый" прекращены. При создании VPN-шлюза необходимо использовать общедоступный IP-адрес SKU уровня "Стандартный". Дополнительные сведения об выходе общедоступных IP-адресов SKU уровня "Базовый" см . здесь.

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

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

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

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

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

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

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

Модель развертывания Resource Manager

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-шлюз с номером SKU шлюза "Базовый" на портале?

№ Номер SKU "Базовый" недоступен на портале. Vpn-шлюз SKU уровня "Базовый" можно создать с помощью Azure CLI или PowerShell.

Где можно найти сведения о типах шлюза, требованиях и пропускной способности?

См. следующие статьи:

Отмена номера SKU для устаревших номеров SKU

Номера SKU уровня "Стандартный" и "Высокий уровень производительности" будут устарели 30 сентября 2025 г. Вы можете просмотреть объявление здесь. Группа разработчиков предложит способ миграции для этих категорий к 30 ноября 2024 года. Дополнительные сведения см. в статье VPN-шлюз устаревших номеров SKU. В настоящее время нет никаких действий, которые вам нужно предпринять.

Можно ли создать номер SKU уровня "Стандартный" или "Высокий уровень производительности" после объявления об отмене 30 ноября 2023 г.?

№ Начиная с 1 декабря 2023 г. нельзя создавать новые шлюзы с номерами SKU уровня "Стандартный" или "Высокий уровень производительности". Вы можете создать новые шлюзы с помощью VpnGw1 и VpnGw2 для той же цены, что и номера SKU уровня "Стандартный" и "Высокая производительность", указанные соответственно на нашей странице цен.

Сколько времени будут поддерживаться существующие шлюзы на номерах SKU уровня "Стандартный" или "Высокий уровень производительности"?

Все существующие шлюзы, использующие номера SKU уровня "Стандартный" или "Высокий уровень производительности", будут поддерживаться до 30 сентября 2025 г.

Нужно ли перенести номера SKU шлюза уровня "Стандартный" или "Высокий уровень производительности" прямо сейчас?

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

Какой номер SKU можно перенести в шлюз?

Когда миграция SKU шлюза становится доступной, номера SKU можно перенести следующим образом:

Standard —> VpnGw1
Высокая производительность —> VpnGw2

Что делать, если я хочу перейти на SKU AZ?

Вы не можете перенести устаревший номер SKU в AZ SKU. Однако обратите внимание, что все шлюзы, которые по-прежнему используют номера SKU уровня "Стандартный" или "Высокий уровень производительности" после 30 сентября 2025 г. будут перенесены и обновлены автоматически до следующих номеров SKU:

Standard —> VpnGw1AZ
Высокая производительность —> VpnGw2AZ

Эту стратегию можно использовать для автоматической миграции и обновления номеров SKU AZ. При необходимости вы можете изменить размер номера SKU в пределах этого семейства SKU. См. нашу страницу цен на AZ SKU. Сведения о пропускной способности по номеру SKU см. в разделе "Сведения о номерах SKU шлюза".

Будет ли разница в ценах на шлюзы после миграции?

Если вы переносите номера SKU к 30 сентября 2025 г., разница в ценах не будет. Номера SKU VpnGw1 и VpnGw2 предоставляются по той же цене, что и номера SKU уровня "Стандартный" и "Высокая производительность" соответственно. Если вы не переносите по этой дате, номера SKU автоматически будут перенесены и обновлены до номеров SKU AZ. В этом случае разница в ценах.

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

Да, вы получаете лучшую производительность с помощью VpnGw1 и VpnGw2. В настоящее время VpnGw1 на 650 Мбит/с предоставляет 6,5x и VpnGw2 на 1 Гбит/с обеспечивает повышение производительности 5x по той же цене, что и устаревшие шлюзы уровня "Стандартный" и "Высокая производительность" соответственно. Дополнительные сведения о пропускной способности SKU см. в разделе "Сведения о номерах SKU шлюза".

Что произойдет, если я не переносю номера SKU к 30 сентября 2025 г.?

Все шлюзы, которые по-прежнему используют номера SKU уровня "Стандартный" или "Высокая производительность", будут перенесены автоматически и обновлены до следующих номеров SKU AZ:

Standard —> VpnGw1AZ
Высокая производительность —> VpnGw2AZ

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

Кроме того, VPN-шлюз номер SKU уровня "Базовый"?

Нет, VPN-шлюз базовый номер SKU здесь, чтобы остаться. Vpn-шлюз можно создать с помощью номера SKU шлюза "Базовый" с помощью PowerShell или CLI. В настоящее время VPN-шлюз номера SKU "Базовый" поддерживают только ресурс общедоступного IP-адреса SKU уровня "Базовый" (который находится на пути к выходу на пенсию). Мы работаем над добавлением поддержки в номер SKU шлюза VPN-шлюз "Базовый" для ресурса общедоступного IP-адреса SKU уровня "Стандартный".

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

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

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

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

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

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

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

См. дополнительные сведения о совместимых VPN-устройствах.
Прежде чем настраивать VPN-устройство, которое вы хотите использовать, проверьте его на наличие известных проблем совместимости устройств.
См. дополнительные сведения о проверенных VPN-устройствах. Ссылки на инструкции по настройке устройств будут предоставляться по мере возможности. Актуальные сведения о конфигурации всегда лучше проверять у производителей устройств. В списке перечислены протестированные нами версии. Если вашей ОС нет в этом списке, эта версия все равно может быть совместимой. Обратитесь к изготовителю устройства, чтобы проверить совместимость версии ОС с вашим VPN-устройством.
Общие сведения о конфигурации устройства VPN см. в статье Обзор конфигураций партнерских VPN-устройств.
См. дополнительные сведения о примерах изменения конфигурации устройств.
См. дополнительные сведения о требованиях к шифрованию и VPN-шлюзах Azure.
См. дополнительные сведения о VPN-устройствах и параметрах IPsec/IKE для подключений типа "сеть — сеть" через VPN-шлюз. По этой ссылке отображаются сведения о версии IKE, группе Диффи-Хелмана, способе аутентификации, алгоритмах шифрования и хэширования, времени существования SA, PFS, DPD, а также другие сведения о параметрах, необходимых для завершения настройки.
См. инструкции по настройке политики IPsec/IKE для VPN-подключений типа "сеть — сеть" или "виртуальная сеть — виртуальная сеть".
Сведения о подключении нескольких VPN-устройств на основе политик см. в статье Подключение VPN-шлюзов Azure к нескольким локальным VPN-устройствам на основе политики с помощью PowerShell.

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

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

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

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

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

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

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

Мы поддерживаем серверы маршрутизации и удаленного доступа Windows Server 2012 (RRAS) для межсайтовой конфигурации.

Другие программные решения 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 не сможет пройти через прокси-серверы и брандмауэры.

Если перезапустить клиентский компьютер, настроенный для типа "точка — сеть", 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 шлюза. Дополнительные сведения о пропускной способности см. в статье о номерах 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:

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

Версия ОС	Дата	Номер или ссылка
Windows Server 2016 Windows 10 версии 1607	17 января 2018 г.	KB4057142
Windows 10 версии 1703	17 января 2018 г.	KB4057144
Windows 10 версии 1709	22 марта 2018 г.	KB4089848

Установите значение раздела реестра. Создайте или задайте для ключа 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.

Если в шлюзе включен единый протокол SSTP и IKEv2, пул адресов типа "точка — сеть" будет статически разделен между этими двумя, поэтому клиенты, использующие разные протоколы, будут назначены IP-адреса из любого под диапазона. Обратите внимание, что максимальное количество клиентов SSTP всегда равно 128, даже если диапазон адресов больше /24, что приводит к большему количеству адресов, доступных для клиентов IKEv2. Для небольших диапазонов пул будет равным наполовину. Селекторы трафика, используемые шлюзом, могут не включать ciDR диапазона адресов "Точка — сеть", но два под-диапазона CIDR.

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

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

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

Да, если используемый номер SKU шлюза поддерживает 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"

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

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

Обход проверки удостоверения сервера в целом не рекомендуется, но при проверке подлинности на основе сертификата Azure для проверки сервера в протоколе туннелирования VPN (IKEv2/SSTP) и протоколе EAP используется один и тот же сертификат. Так как сертификат сервера и полное доменное имя уже проверяются протоколом туннелирования 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-клиента можно использовать в конфигурации типа "точка — сеть"?

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

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

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 не сможет пройти через прокси-серверы и брандмауэры.

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

Версия ОС	Дата	Номер или ссылка
Windows Server 2016 Windows 10 версии 1607	17 января 2018 г.	KB4057142
Windows 10 версии 1703	17 января 2018 г.	KB4057144
Windows 10 версии 1709	22 марта 2018 г.	KB4089848

Установите значение раздела реестра. Создайте или задайте для ключа REG_DWORD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\ IKEv2\DisableCertReqPayload" в реестре значение 1.

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

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

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

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

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

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

Эту конфигурацию можно удалить с помощью 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, а не через Интернет.

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

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

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

Да. Он защищен шифрованием 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-шлюза Azure и одно соглашение об уровне обслуживания VPN-шлюзов в Azure.

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

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

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

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

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

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

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

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

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

Модель развертывания Resource Manager
Да. Дополнительные сведения см. в разделе, посвященном 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. Более короткий путь AS предпочтителен в выборе пути BGP.

Можно ли использовать свойство 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
Проверка целостности IKEv2	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, если не задано другое значение.)
Время ожидания обнаружения неиспользуемых одноранговых узлов (DPD)	Секунды (целое число, минимум — 9; максимум — 3600, по умолчанию — 45 секунд)

Ваша конфигурация локальных VPN-устройств должна совпадать со следующими алгоритмами и параметрами, указанными в политике Azure IPsec/IKE, или содержать их.
- алгоритм шифрования IKE (основной режим или фаза 1);
- алгоритм обеспечения целостности IKE (основной режим или фаза 1);
- группа DH (основной режим или фаза 1);
- алгоритм шифрования IKE (основной режим или фаза 2);
- алгоритм обеспечения целостности IPsec (быстрый режим или фаза 2);
- группа PFS (быстрый режим или фаза 2);
- селектор трафика (если используется UsePolicyBasedTrafficSelectors).
- Время существования SA — это только локальные спецификации, и не нужно соответствовать.
Если для шифрования IPsec используется алгоритм GCMAES, необходимо указать одинаковую длину алгоритма и ключа для проверки целостности IPsec, например GCMAES128 в обоих случаях.
В таблице "Алгоритмы и ключи":
- IKE соответствует главному режиму или этапу 1.
- IPsec соответствует быстрому режиму или фазе 2;
- Группа DH указывает группу Diffie-Hellman, используемую в главном режиме или на этапе 1.
- Группа PFS указала группу Diffie-Hellman, используемую в быстром режиме или на этапе 2.
Время существования SA основного режима IKE составляет 28 800 секунд на VPN-шлюзах Azure.
UsePolicyBasedTrafficSelectors — это необязательный параметр подключения. Если задать для параметра UsePolicyBasedTrafficSelectors значение $True для подключения, это позволит настроить VPN-шлюз Azure, чтобы локально подключаться к брандмауэру VPN на основе политик. Если вы включили параметр PolicyBasedTrafficSelectors, необходимо обеспечить соответствующие селекторы трафика для VPN-устройства, которые определены с помощью всех комбинаций префиксов локальной сети (шлюза локальной сети) с префиксами виртуальной сети Azure, а не разрешать совпадение любого префикса с любым. VPN-шлюз Azure принимает любой селектор трафика, предлагаемый удаленным VPN-шлюзом независимо от того, что настроено в 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.
Время ожидания обнаружения неиспользуемых одноранговых узлов (DPD). Значение по умолчанию — 45 секунд на VPN-шлюзах Azure. Установка более короткого времени ожидания приведет к более агрессивному переназначению ключей IKE, в результате чего в некоторых экземплярах может наблюдаться разрыв подключения. Это может оказаться нежелательным, если ваши локальные расположения находятся далеко от региона Azure, где размещен VPN-шлюз, или если ненадлежащее состояние физической связи может приводить к потере пакетов. Общая рекомендация заключается в установке времени ожидания в диапазоне от 30 до 45 секунд.

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

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

В следующей таблице перечислены соответствующие группы Diffie-Hellman, поддерживаемые пользовательской политикой:

Группа Диффи-Хелмана	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 бит)

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

Заменяет ли настраиваемая политика стандартные наборы политик 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 секунд.

Примечание.

Значение по умолчанию — 45 секунд в VPN-шлюзах Azure. Установка более короткого времени ожидания приведет к более агрессивному переназначению ключей IKE, в результате чего в некоторых экземплярах может наблюдаться разрыв подключения. Это может быть не желательно, если локальные расположения находятся далеко от региона Azure, где находится VPN-шлюз, или когда физическое условие связи может привести к потере пакетов. Общая рекомендация — задать время ожидания от 30 до 45 секунд.

Работает ли настраиваемая политика 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, который поддерживает переназначение ключей без отключения.

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

Где можно найти сведения о конфигурации и шаги?

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

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 секунд. Это приводит к ускоренной конвергенции. Тем не менее таймеры ниже интервала хранения по умолчанию 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 можно использовать на 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 применяется к одному экземпляру VPN-шлюза. В шлюзах active-active создайте отдельное правило NAT для каждого экземпляра шлюза с помощью поля "Идентификатор конфигурации IP".

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

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

Выберите Включить преобразование маршрутов BGP на странице «Конфигурация правил NAT», чтобы полученные маршруты и объявляемые маршруты преобразовывались в префиксы адресов после NAT (внешние сопоставления) на основе правил NAT, связанных с соединениями. Необходимо убедиться, что локальные маршрутизаторы BGP объявляют точные префиксы, как определено в правилах IngressSNAT.
Если локальный VPN-маршрутизатор использует обычный, не APIPA-адрес и сталкивается с адресным пространством виртуальной сети или другими локальными сетевыми пространствами, убедитесь, что правило IngressSNAT преобразует ОДНОранговый IP-адрес BGP в уникальный, не перекрывающийся адрес и помещает адрес после NAT в поле IP-адреса однорангового ip-адреса BGP шлюза локальной сети.
NAT не поддерживается с адресами APIPA BGP.

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

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

Правило IngressSNAT определяет преобразование исходных IP-адресов, поступающих в VPN-шлюз Azure из локальной сети. Он также обрабатывает перевод конечных IP-адресов, покидающих виртуальную сеть в ту же локальную сеть.
Правило EgresSNAT определяет преобразование 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

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

Внимание

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

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

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

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

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

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

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

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

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

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

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

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

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

Есть несколько вариантов. Если вы включили протокол удаленного рабочего стола для виртуальной машины, вы можете подключиться к виртуальной машине с помощью частного 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 через удаленный рабочий стол.

Обслуживание шлюза, управляемого клиентом

Какие службы включены в конфигурацию обслуживания область сетевых шлюзов?

Сетевые шлюзы область включают ресурсы шлюза в сетевых службах. В сетевых шлюзах область четыре типа ресурсов:

Шлюз виртуальной сети в службе ExpressRoute.
Шлюз виртуальной сети в службе VPN-шлюз.
VPN-шлюз (сеть — сеть) в службе Виртуальная глобальная сеть.
Шлюз ExpressRoute в службе Виртуальная глобальная сеть.

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

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

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

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

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

В настоящее время необходимо настроить как минимум пять часового периода в предпочтительном часовом поясе.

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

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

Существуют ли случаи, когда не удается контролировать определенные обновления?

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

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

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

Да

Какие номера SKU шлюза можно настроить для использования обслуживания, управляемого клиентом?

Все номера SKU шлюза (кроме номера SKU basic для VPN-шлюз) можно настроить для использования обслуживания, управляемого клиентом.

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

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

Существуют ли ограничения на использование управляемого клиентом обслуживания на основе общедоступного IP-адреса SKU уровня "Базовый"?

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

Как запланировать периоды обслуживания при использовании VPN и ExpressRoute в сценарии сосуществования?

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

Я запланировал период обслуживания для следующей даты для одного из моих ресурсов. Будут ли действия по обслуживанию приостановлены на этом ресурсе до тех пор?

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

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

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

Следующие шаги

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

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