Поделиться через

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

  • Статья

В этой статье приведены ответы на часто задаваемые вопросы о межсайтовых подключениях Azure VPN-шлюз, гибридных подключениях конфигурации и шлюзах виртуальной сети. Он содержит подробные сведения о параметрах конфигурации "точка — сеть" (P2S), "сеть — сеть" и "виртуальная сеть — виртуальная сеть", включая протоколы "Безопасность интернет-протокола" (IPsec) и протоколы Exchange ключей Интернета (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-шлюз сертификата "точка — сеть".
  • Виртуальная сеть — виртуальная сеть. Этот тип подключения аналогичен конфигурации "сеть — сеть". Виртуальная сеть — это VPN-подключение через IPsec (IKEv1 и IKEv2). Для этого подключения не требуется VPN-устройство. Дополнительные сведения см. в разделе "Настройка vpn-шлюза между виртуальными сетями".
  • Azure ExpressRoute: ExpressRoute — это частное подключение к Azure из широкой сети (WAN), а не VPN-подключение через общедоступный Интернет. Дополнительные сведения см. в техническом обзоре ExpressRoute и часто задаваемых вопросов о ExpressRoute.

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

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

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

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

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

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

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

Вы можете настроить виртуальную сеть для одновременного использования подключения типа "сеть — сеть" и "точка — сеть", если вы создаете подключение типа 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 может предотвратить выполнение операций и обслуживания майкрософт на 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 (DHCP) в соответствии со спецификацией RFC и поддерживает маршруты DHCP 121, включая Windows.

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

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

Хранит и обрабатывает ли служба 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 SKU Поддерживаемые версии IKE
Шлюз на основе политик Базовая IKEv1
Шлюз на основе маршрутов Базовая IKEv2
Шлюз на основе маршрутов VpnGw1, VpnGw2, VpnGw3, VpnGw4, VpnGw5 IKEv1 и IKEv2
Шлюз на основе маршрутов VpnGw1AZ, VpnGw2AZ, VpnGw3AZ, VpnGw4AZ, VpnGw5AZ IKEv1 и IKEv2

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

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

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

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

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

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

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

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

Однако общедоступные 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.

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

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

Нерекомендуция старых номеров SKU

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Standard to 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 по той же цене, что и номер SKU "Стандартный". 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-шлюз "Базовый".

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

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

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

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

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

В зависимости от используемого 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 шлюза. Дополнительные сведения о поддерживаемом количестве подключений см. в разделе 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, а также номер 50 IP-протоколов. Брандмауэры не всегда открывают эти порты, поэтому существует вероятность того, что VPN IKEv2 не может проходить через прокси-серверы и брандмауэры.

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

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

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

Динамический DNS (DDNS) в настоящее время не поддерживается в виртуальных сетях типа "точка — сеть".

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

Да. Для модели развертывания 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\DisableCertReqPayload REG_DWORD для раздела реестра 1значение .

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

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

Ограничение селектора трафика в Windows определяет максимальное количество адресных пространств в виртуальной сети и максимальную сумму локальных сетей, подключений между виртуальными сетями и пиринговых виртуальных сетей, подключенных к шлюзу. Клиенты типа "точка — сеть" 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.

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

Конфигурацию 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 см. в статье:

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

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

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

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

Для более ранних номеров SKU проверка подлинности RADIUS поддерживается в номерах SKU уровня "Стандартный" и "Высокая производительность".

Поддерживается ли аутентификация 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

№

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да. Помните, что реклама маршрута по умолчанию заставляет весь исходящий трафик виртуальной сети к локальному сайту. Кроме того, виртуальные машины виртуальной сети не могут принимать общедоступные подключения из Интернета напрямую, например протокол удаленного рабочего стола (RDP) или Secure Shell (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-шлюзы не объявляют маршруты по умолчанию другим одноранговым узлам 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 при подключении между виртуальными сетями или 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?

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

  • Чтобы убедиться, что обучаемые маршруты и объявленные маршруты переводятся в префиксы адресов после 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 с 100.0.1.0/24.
  • Правило IngressSNAT 2: сопоставление 10.0.2.0/25 с 100.0.2.0/25.

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

Внимание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да.

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

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

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

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

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

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

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

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

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

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

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

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

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

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