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

В этой статье даны ответы на часто задаваемые вопросы о межсетевых подключенияах с использованием шлюза Azure VPN, гибридных конфигурациях подключений и шлюзах виртуальной сети (VNet). Он содержит подробные сведения о параметрах конфигурации "точка — сеть" (P2S), "сеть — сеть" (S2S) и "виртуальная сеть — виртуальная сеть" (VNet-to-VNet), включая протоколы безопасности интернет-протокола (IPsec) и обмена ключами Интернета (IKE).

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

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

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

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

Да.

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

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

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

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

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

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

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

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

• Межсетевое: VPN-подключение через IPsec (IKEv1 и IKEv2). Для этого типа подключения требуется VPN-устройство или маршрутизация Windows Server и удаленный доступ. Для получения дополнительной информации см. статью Создание VPN-подключения типа "сеть — сеть" в портале Azure.
• Точка — сеть: VPN-подключение по протоколу безопасного туннелирования сокетов (SSTP) или IKEv2. Для этого подключения не требуется VPN-устройство. Дополнительные сведения см. в разделе Настройка параметров сервера для сертификатной аутентификации VPN-шлюза от "точка к сайту".
• VNet-к-VNet подключение: Этот тип подключения аналогичен межсайтовой конфигурации. Соединение VNet-to-VNet — это VPN-подключение через IPsec (IKEv1 и IKEv2). Для этого подключения не требуется VPN-устройство. Дополнительные сведения см. в разделе "Настройка vpn-шлюза для соединения между виртуальными сетями".
• Azure ExpressRoute: ExpressRoute — это частное подключение к Azure из широкой сети (WAN), а не VPN-подключение через общедоступный Интернет. Дополнительные сведения см. в техническом обзоре ExpressRoute и часто задаваемых вопросов о ExpressRoute.

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

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

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

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

• Конфигурация точка — сеть (VPN-подключение по протоколу SSTP) позволяет подключаться с одного компьютера, который может находиться где угодно, к любому расположению в виртуальной сети. Он использует встроенный VPN-клиент Windows.

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

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

Вы можете настроить виртуальную сеть для одновременного использования как межсайтового (site-to-site), так и точка-сайт (point-to-site) подключений, если создаете межсайтовое подключение, используя VPN-шлюз маршрутизируемого типа. Типы VPN на основе маршрутов называются динамическими шлюзами в классической модели развертывания.

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

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

При реализации пользовательского DNS в виртуальной сети важно настроить dns-пересылку, которая указывает на Azure DNS (168.63.129.16). Эта конфигурация помогает обеспечить непрерывное взаимодействие между VPN-шлюзом и плоскостем управления. Неправильная настройка перенаправления DNS в Azure DNS может помешать выполнению Microsoft операций и обслуживания на VPN-шлюзе, что создаёт угрозу безопасности.

Чтобы обеспечить правильную функциональность и работоспособность VPN-шлюза, рассмотрите одну из следующих конфигураций DNS в виртуальной сети:

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

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

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

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

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

Корпорация Майкрософт осведомлена об отчетах о методе обхода сети, который обходит инкапсуляцию VPN. Это проблема на уровне отрасли. Она влияет на любую операционную систему, которая реализует клиент протокола динамической конфигурации хоста (DHCP) в соответствии со спецификацией RFC и поддерживает маршруты, связанные с DHCP опцией 121, включая Windows.

Как отмечается в исследовании, меры по снижению рисков включают запуск VPN внутри виртуальной машины, которая получает аренду IP-адреса от виртуального DHCP-сервера, чтобы предотвратить установку маршрутов DHCP-сервером локальной сети. Дополнительные сведения об этой уязвимости можно найти в национальной базе данных уязвимостей NIST.

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

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

нет

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

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

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

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

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

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

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

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

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

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

2. Удалите шлюз с помощью одной из следующих статей:

   • Портал Azure
   • Azure PowerShell
   • Azure PowerShell (классическая модель)

3. Создайте новый шлюз с помощью нужного типа шлюза, а затем завершите настройку VPN. Инструкции см. в руководстве по сайту.

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

Да, можно определить селекторы трафика, используя атрибут trafficSelectorPolicies для подключения с помощью команды New-AzIpsecTrafficSelectorPolicy Azure PowerShell. Чтобы указанный селектор трафика действовал, обязательно включите селекторы трафика на основе политик.

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

Нужна ли подсеть шлюза?

Да. Подсеть шлюза содержит 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-адреса уровня "Базовый". Мы работаем над добавлением поддержки общедоступных IP-адресов SKU уровня "Стандартный" для номера SKU "Базовый".

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

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

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

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

Как осуществляется аутентификация моего VPN-туннеля?

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

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

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

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

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

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

Для модели развертывания с помощью Azure Resource Manager выполните следующую команду:

• Azure PowerShell. Используйте AddressPrefix для указания трафика для шлюза локальной сети.
• В портале Azure перейдите в шлюз локальной сети. >Конфигурация>Адресное пространство.

Выполните следующую команду для классической модели развертывания:

• портал Azure: перейдите в классическую виртуальную сеть, затем в VPN-подключения>, перейдите к VPN-подключениям типа "сеть-сеть">, далее название локального сайта>, локальный сайт> и адресное пространство клиента.

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

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

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

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

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

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

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

Можно ли создать VPN-шлюз с помощью номера SKU "Базовый" на портале?

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

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

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

• Сведения о параметрах конфигурации VPN-шлюз
• Сведения о SKU шлюзов

Устаревание старых артикулов SKU

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

В настоящее время нет никаких действий, которые вам нужно предпринять.

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

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

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

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

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

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

В какой SKU я могу перенести свой шлюз?

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

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

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

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

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

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

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

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

Если вы не перенесете к этой дате, ваши артикулы SKU будут автоматически перенесены и обновлены до артикулов SKU AZ. В этом случае разница в ценах.

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

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

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

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

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

Мы отправим уведомление перед началом миграции на любые шлюзы.

Ретируется ли VPN-шлюз с базовым SKU?

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

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

Перенос общедоступного IP-адреса SKU уровня "Базовый" в SKU уровня "Стандартный"

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

Какое ожидаемое влияние на клиента?

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

Какова ожидаемая временная шкала миграции?

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

Дата	Мероприятие
Апрель/май 2025 г.	Доступность средств миграции для активно-пассивных шлюзов.
Джул/август 2025 г.	Доступность средств миграции для шлюзов Active-Active.
Май 2025 по сентябрь 2025 г.	После доступности инструмента, управляемого клиентом, можно инициировать миграцию.
Сентябрь 2025 г.	Базовые IP-адреса SKU устарели.

Каковы необходимые действия клиента?

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

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

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

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

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

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

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

Ниже приведены дополнительные сведения о конфигурации:

• Сведения о совместимых VPN-устройствах см. в разделе "Сведения о VPN-устройствах".

• Перед настройкой VPN-устройства проверьте наличие известных проблем совместимости устройств.

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

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

• Основные сведения о конфигурации VPN-устройства см. в разделе "Общие сведения о конфигурациях VPN-устройств партнера".

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

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

• Сведения о параметрах, необходимых для завершения настройки, см. в разделе "Параметры IPsec/IKE по умолчанию". Сведения включают версию IKE, группу Diffie-Hellman (DH), метод проверки подлинности, алгоритмы шифрования и хэширования, время существования ассоциации безопасности (SA), протокол прямого переноса секретности (PFS) и обнаружение мертвых одноранговых узлов (DPD).

• Инструкции по настройке политики IPsec/IKE см. в разделе Настройка настраиваемых политик IPsec/IKE для подключения S2S VPN и VNet-to-VNet.

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

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

См. примеры настройки устройства.

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

См. раздел Параметры IPsec/IKE по умолчанию.

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

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

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

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

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

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

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

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

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

Это зависит от 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): частное решение на основе SSL Майкрософт, которое может проникать в брандмауэры, так как большинство брандмауэров открывают исходящий TCP-порт, который использует 443 SSL.

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

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

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

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

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

Динамический DNS (DDNS) в настоящее время не поддерживается в VPN "точка-сайт".

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

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

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

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

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

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

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

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

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

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

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

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

Да. На портале перейдите к VPN-шлюз>конфигурация «точка-сайт». Для типа проверки подлинности выберите тип проверки подлинности, который требуется использовать.

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

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

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

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

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

Примечание.

Сборки Windows, новее чем Windows 10 версии 1709 и Windows Server 2016 версии 1607, не требуют этих шагов.

Чтобы подготовить Windows 10 или Windows 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. Установите значение ключа реестра. Создайте или установите ключ HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\ IKEv2\DisableCertReqPayloadREG_DWORD в реестре в 1.

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

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

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

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

Ограничение селектора трафика для OpenVPN составляет 1000 маршрутов.

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

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

Когда на шлюзе включены протоколы SSTP и IKEv2, пул адресов "точка-сеть" статически разделяется между ними, поэтому клиенты, использующие разные протоколы, получают IP-адреса из одного из поддиапазонов. Максимальное число клиентов SSTP всегда равно 128, даже если диапазон адресов больше /24. Результатом является большее количество адресов, доступных для клиентов IKEv2. Для небольших диапазонов пул делится пополам. Селекторы трафика, которые использует шлюз, могут не включать блок маршрутизации без классов между доменами (CIDR) для диапазона адресов типа "точка — сеть", но включать блок CIDR для двух подрангов.

Какие платформы поддерживает Azure для VPN-соединений P2S?

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

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

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

Почему я отключаюсь от vpn-клиента Azure? Что можно сделать, чтобы уменьшить частоту отключения?

Вы можете увидеть одно из следующих сообщений:

• В VPN-клиенте Azure для Windows ver. 3.4.0.0: "Срок действия проверки подлинности с помощью Microsoft Entra истек. Чтобы получить новый маркер, необходимо повторно пройти проверку подлинности в Entra. Время ожидания проверки подлинности можно настроить администратором.
• В клиенте VPN Azure для macOS вер. 2.7.101: "Срок действия вашей аутентификации через Microsoft Entra истек, поэтому вам необходимо повторно пройти аутентификацию, чтобы получить новый токен. Повторите попытку подключения. Политики проверки подлинности и время ожидания настраиваются администратором в клиенте Entra".

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

Дополнительные сведения см. в статье об ошибке VPN-клиента: срок действия проверки подлинности с использованием Microsoft Entra истек.

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

Конфигурацию P2S можно удалить с помощью следующих команд Azure PowerShell или Azure CLI:

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

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

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

Что делать, если у вас возникло несоответствие сертификата для подключения аутентификации с использованием сертификата типа "точка-к-сайту"?

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

В общем, мы не рекомендуем обходить проверку идентификатора сервера. Но при проверке подлинности сертификата Azure для проверки сервера используется один и тот же сертификат в протоколе туннелирования VPN (IKEv2 или SSTP) и расширяемом протоколе проверки подлинности (EAP). Так как протокол туннелирования VPN уже проверяет сертификат сервера и полное доменное имя, повторная проверка в EAP является избыточной.

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

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

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

№

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

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

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

Сведения о форматах файлов .cer и PFX см. в статье:

• PowerShell
• MakeCert

Формат PEM-файла см. в следующем разделе:

• Linux: OpenSSL
• Linux: strongSwan

Подключения типа "точка-к-сайту" с аутентификацией RADIUS

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

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

Для более ранних версий SKU проверка подлинности RADIUS поддерживается в SKU Standard и High Performance.

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

№

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

Запросы RADIUS настроены на истечение времени ожидания через 30 секунд. Определяемые пользователем значения времени ожидания в настоящее время не поддерживаются.

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

Да.

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

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

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

№ Его можно перенаправить только через подключение типа "сеть — сеть".

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

Нет изменений в максимальном количестве поддерживаемых подключений SSTP на шлюзе с проверкой подлинности RADIUS. Он остается 128 для SSTP, но он зависит от номера SKU шлюза для IKEv2. Дополнительные сведения о количестве поддерживаемых подключений см. в разделе "Сведения о номерах SKU шлюза".

Какова разница между проверкой подлинности сертификата с помощью сервера RADIUS и проверки подлинности собственного сертификата Azure с помощью отправки доверенного сертификата?

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

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

Поддерживает ли проверка подлинности RADIUS интеграцию сервера политики сети для многофакторной проверки подлинности?

Если многофакторная проверка подлинности основана на тексте (например, SMS или код проверки мобильного приложения) и требует, чтобы пользователь ввел код или текст в пользовательском интерфейсе VPN-клиента, проверка подлинности не будет выполнена и не поддерживается. См. интеграцию аутентификации RADIUS VPN-шлюза Azure с сервером NPS для многофакторной аутентификации.

Работает ли проверка подлинности RADIUS как с VPN IKEv2, так и с SSTP?

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

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

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

Соединения VNet-to-VNet и подключения к нескольким сайтам

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

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

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

Трафик VNet-to-VNet проходит через Интернет?

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

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

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

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

Шифрование IPsec и IKE помогает защитить трафик между виртуальными сетями.

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

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

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

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

Если виртуальные сети (VNet) не находятся в одной подписке, необходимо ли, чтобы подписки были связаны с тем же арендатором Microsoft Entra?

№

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

№ VNet-to-VNet поддерживает подключение виртуальных сетей в пределах одного экземпляра Azure. Например, невозможно создать подключение между глобальным Azure и китайскими, немецкими или американскими правительственными экземплярами Azure. Рекомендуется использовать VPN-подключение типа "сеть — сеть" для этих сценариев.

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

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

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

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

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

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

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

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

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

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

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

нет Обе виртуальные сети должны использовать vpn-адреса на основе маршрутов (ранее называемые динамической маршрутизацией).

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

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

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

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

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

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

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

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

Как настроить сценарий между арендаторами?

• Если вы используете REST API или шаблоны ARM для ресурсов подключения, ссылающихся на шлюз в другом клиенте, выполните следующую процедуру проверки подлинности: значения заголовков для проверки подлинности.
• Для сайт-сайт.
• Для VNet-to-VNet.

Если вы используете команды PowerShell, убедитесь, что вы используете Az.Network 7.15.1

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

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

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

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

  Да. Дополнительные сведения см. в разделе BGP и маршрутизации .

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

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

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

№ По умолчанию Azure создает различные предварительные ключи для различных VPN-подключений. Однако вы можете использовать REST API или командлет PowerShell для установки предпочитаемого значения ключа VPN-шлюза. Ключ должен содержать только печатные символы ASCII, за исключением пробела, дефиса (-), или тильды (~).

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

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

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

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

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

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

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

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

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

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

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

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

Политика IPsec/протокол IKE

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

Настраиваемая политика IPsec/IKE поддерживается во всех SKU VPN-шлюзов 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, нет
Время существования SA в режиме быстрого режима	(Необязательно; значения по умолчанию, если они не указаны) Секунды (целое число; минимум 300, по умолчанию 27 000) Килобайты (целое число; минимум 1024, по умолчанию 10 2400 000)
Селектор трафика	UsePolicyBasedTrafficSelectors ($True или $False, но необязательно; значение по умолчанию $False , если не указано)
Тайм-аут DPD	Секунды (целое число; минимум 9, максимум 3600, по умолчанию 45)

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

  • Алгоритм шифрования IKE (основной режим, этап 1)
  • Алгоритм целостности IKE (основной режим, этап 1)
  • Группа DH (основной режим, этап 1)
  • Алгоритм шифрования IPsec (быстрый режим, этап 2)
  • Алгоритм целостности IPsec (быстрый режим, этап 2)
  • Группа PFS (быстрый режим, этап 2)
  • Селектор трафика (если используется UsePolicyBasedTrafficSelectors)
  • Срок службы SA (локальные спецификации, которые не должны соответствовать)

• При использовании GCMAES для алгоритма шифрования 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-шлюз для соединения с локальным VPN-брандмауэром на основе политик.

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

  Например, если префиксы локальной сети — 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-шлюза к нескольким локальным VPN-устройствам на основе политик".

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

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

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

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

Группа 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-шлюз использует только эту политику в подключении, как инициатор IKE, так и ответитель IKE.

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

При создании подключения можно указать тип протокола IKEv1 или IKEv2. Если тип протокола не указан, по умолчанию используется тип IKEv2 (там, где это применимо). Дополнительные сведения см. в документации по командлетам Azure PowerShell.

Сведения о типах SKU и поддержке IKEv1 и IKEv2 см. в разделе Подключение VPN-шлюза к нескольким локальным VPN-устройствам на основе политик.

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

Да.

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

нет SKU "Базовый" не поддерживает эту конфигурацию.

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

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

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

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

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

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

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

• Настройка настраиваемых политик соединения IPsec/IKE для S2S VPN и VNet-to-VNet: портал Azure
• Настройка настраиваемых политик IPsec/IKE для VPN-подключений S2S и VNet-VNet: PowerShell

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

Поддерживается ли BGP во всех SKU Azure VPN Gateway?

BGP поддерживается на всех SKU шлюза VPN Azure, кроме SKU "Basic".

Можно ли использовать BGP с VPN-шлюзами, управляемыми через Azure Policy?

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

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

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

Вы не можете использовать следующие зарезервированные ASN:

• Azure зарезервировал:

  • Общедоступные ASN: 8074, 8075, 12076.
  • Частные ASN: 65515, 65517, 65518, 65519, 65520.

• Зарезервировано IANA:

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

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

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

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

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

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

• 64512–65514 и 65521–65534

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

Какой адрес использует шлюз Azure VPN для пирингового IP BGP?

По умолчанию Azure VPN-шлюз выделяет один IP-адрес из диапазона GatewaySubnet для VPN-шлюзов с активным резервным режимом или два IP-адреса для VPN-шлюзов с активно-активным режимом. Эти адреса выделяются автоматически при создании VPN-шлюза.

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

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

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

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

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

Что нужно указать в качестве префикса адреса локального сетевого шлюза, если используется 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?

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

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

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

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

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

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

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

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

• Если включен транзит шлюза: нельзя рекламировать точные префиксы вашей виртуальной сети, включая префиксы пиринговых виртуальных сетей. Azure блокирует или фильтрует объявление всех префиксов, соответствующих префиксам виртуальной сети. Однако можно объявить префикс, который является супермножеством адресного пространства виртуальной сети. Например, если виртуальная сеть использует адресное пространство 10.0.0.0/16, можно объявить 10.0.0.0/8, но не 10.0.0.0/16 или 10.0.0.0.0/24.
• Если транзит шлюза не включен: шлюз не принимает префиксы одноранговых виртуальных сетей, позволяя вам объявлять те же префиксы, что и ваша одноранговая виртуальная сеть.

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

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

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

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

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

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

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

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

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

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

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

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

Да.

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

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

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

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

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

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

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

NAT

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

NAT поддерживается с VpnGw2 по VpnGw25 и с VpnGw2AZ по VpnGw5AZ.

Можно ли использовать NAT для подключения VNet-на-VNet или подключений типа "точка-сеть" (P2S)?

№

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

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

Можно ли использовать косую черту (/) в имени правила NAT?

№ Вы получите сообщение об ошибке.

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

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

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

VPN-шлюзы поддерживают только статический 1:1 NAT и динамический NAT. Они не поддерживают NAT64.

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

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

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

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

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

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

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

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

№ Правило преобразования одного исходного сетевого адреса (SNAT) определяет преобразование обоих направлений конкретной сети:

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

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

В любом случае вам не нужны правила преобразования сетевых адресов назначения (DNAT).

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

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

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

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

Внимание

Если вы связываете только одно правило с предыдущим соединением, другое адресное пространство не будет преобразовано.

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

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

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

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

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

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

Требуются ли правила входящего трафика и исходящего трафика для подключения NAT?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Область сетевых шлюзов включает ресурсы шлюза в сетевых службах, включая следующие типы ресурсов:

• Шлюз виртуальной сети в службе ExpressRoute
• Шлюз виртуальной сети в службе VPN-шлюз
• ВПН-шлюз (межсайтовый) в службе Azure Виртуальная WAN.
• VPN-шлюз (VPN-подключение пользователя или точка — сеть) в службе Виртуальной глобальной сети Azure
• Шлюз ExpressRoute в службе Виртуальная глобальная сеть

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

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

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

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

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

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

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

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

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

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

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

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

Да.

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

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

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

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

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

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

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

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

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

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

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

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

Связанный контент

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

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