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

Перенос VPN-шлюза из классической модели развертывания в модель Resource Manager

  • Статья

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

Внимание

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

VPN-шлюзы переносятся в рамках миграции виртуальной сети с классической модели в Resource Manager. Виртуальные сети переносятся по одной за раз. Существуют не дополнительные требования с точки зрения средств или предварительных требований для миграции. Шаги миграции идентичны существующей миграции виртуальной сети и описаны на странице миграции ресурсов IaaS.

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

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

Поддерживаемые сценарии

Наиболее распространенные сценарии VPN-подключения входят в процесс перехода от классической модели к модели Resource Manager. Ниже перечислены поддерживаемые сценарии.

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

Ниже перечислены сценарии, которые не поддерживаются:

  • В настоящее время виртуальная сеть с шлюзом ExpressRoute и VPN-шлюзом не поддерживается.
  • Транзитные сценарии, когда расширения виртуальных машин подключены к локальным серверам. Ограничения vpn-подключения транзитного vpn подробно описаны в следующих разделах.

Примечание.

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

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

Подключение между виртуальными сетями в классической модели развертывания было достигнуто путем создания локального представления виртуальной сети подключенной виртуальной сети. Клиентам требуется создать два локальных сайта, представляющих две виртуальные сети, которые должны быть подключены друг к другу. Затем они подключались к соответствующим виртуальным сетям с помощью туннеля IPsec, чтобы установить подключение между двумя виртуальными сетями. Эта модель имеет проблемы с управляемостью, так как любые изменения диапазона адресов в одной виртуальной сети также должны поддерживаться в соответствующем представлении локального сайта. В модели Resource Manager этот обходной путь больше не нужен. Подключение между двумя виртуальными сетями можно достичь напрямую с помощью типа подключения "Vnet2Vnet" в ресурсе подключения.

Схема миграции между виртуальными сетями.

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

Транзитное VPN-подключение

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

Схема, показывающая сценарий маршрутизации транзита.

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

  • Включите BGP в VPN-шлюзах, подключенных вместе и к локальному расположению. Включение подключения BGP восстанавливает подключение без каких-либо других изменений конфигурации, так как маршруты изучаются и объявляются между шлюзами виртуальной сети. Обратите внимание, что параметр BGP доступен только на номерах SKU уровня "Стандартный" и более поздних версий.
  • Установите явное подключение из затронутой виртуальной сети к шлюзу локальной сети, представляющей локальное расположение. Для этого также потребуется изменить конфигурацию локального маршрутизатора, чтобы создать и настроить туннель IPsec.

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

Изучив сведения о поддержке при переносе VPN-шлюза, ознакомьтесь со статьей Перенос ресурсов IaaS из классической модели в модель Azure Resource Manager с помощью Azure PowerShell, чтобы приступить к работе.