Перенос Шлюз приложений Azure и Брандмауэр веб-приложений из версии 1 в версию 2

Мы объявили об отмене Шлюз приложений SKU версии 1 (standard и WAF) 28 апреля 2023 года. Номер SKU версии 1 выходит на пенсию 28 апреля 2026 года. Дополнительные сведения см. в статье "Миграция Шлюз приложений с номера SKU версии 1 на номер SKU версии 2 к 28 апреля 2026 г.

Шлюз приложений Azure и Брандмауэр веб-приложений (WAF) V2 теперь предлагают дополнительные функции, такие как автомасштабирование, доступность, избыточность зон, более высокая производительность, более быстрые операции и улучшенная пропускная способность по сравнению с V1. Кроме того, для SKU версии 2 выпускаются все новые функции. Настоятельно рекомендуется создать план миграции.

Шлюзы версии 1 не обновляются автоматически до версии 2. Используйте это руководство по миграции, чтобы спланировать и выполнить миграцию.

Миграция выполняется в два этапа:

1. перенос конфигурации;
2. перенос клиентского трафика.

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

Необходимые компоненты

• Учетная запись Azure с активной подпиской. Создайте учетную запись бесплатно .
• Существующий Шлюз приложений версии 1 уровня "Стандартный".
• Убедитесь, что у вас есть последняя версия модулей PowerShell, или перейдите к Azure Cloud Shell на портале.
• При использовании PowerShell на локальном компьютере также нужно запустить Connect-AzAccount, чтобы создать подключение к Azure.
• Убедитесь, что в подписке версии 1 нет существующего шлюза приложений с указанным именем имени и группы ресурсов AppGW версии 2. При этом перезаписываются существующие ресурсы.
• Если указан общедоступный IP-адрес, убедитесь, что он находится в успешном состоянии. Если не указано и AppGWResourceGroupName предоставляется, убедитесь, что общедоступный IP-ресурс с именем AppGWV2Name-IP не существует в группе ресурсов с именем AppGWResourceGroupName в подписке V1.
• Для SKU версии 1 сертификаты проверки подлинности необходимы для настройки подключений TLS с внутренними серверами. Номер SKU версии 2 требует отправки доверенных корневых сертификатов для той же цели. Хотя версия 1 позволяет использовать самозаверяющие сертификаты в качестве сертификатов проверки подлинности, версия 2 требует создания и отправки самозаверяющего корневого сертификата , если самозаверяющие сертификаты используются в серверной части.
• Убедитесь, что во время миграции не планируется никаких других операций на шлюзе версии 1 или любых связанных ресурсах.

Azure Cloud Shell

В Azure есть Azure Cloud Shell, интерактивная оболочка среды, с которой можно работать в браузере. Для работы со службами Azure можно использовать Bash или PowerShell с Cloud Shell. Для запуска кода из этой статьи можно использовать предварительно установленные команды Cloud Shell. Ничего дополнительного в локальной среде устанавливать не нужно.

Начало работы с Azure Cloud Shell

Вариант	Пример и ссылка
Нажмите кнопку Попробовать в правом верхнем углу блока кода или команд. При нажатии кнопки Попробовать код или команда не копируется в Cloud Shell автоматически.
Чтобы открыть Cloud Shell в браузере, перейдите по адресу https://shell.azure.com или нажмите кнопку Запуск Cloud Shell.
Нажмите кнопку Cloud Shell в строке меню в правом верхнем углу окна портала Azure.

Чтобы использовать Azure Cloud Shell, выполните следующие действия:

1. Запустите Cloud Shell.

2. Нажмите кнопку Копировать в блоке кода (или блоке команд), чтобы скопировать код или команду.

3. Вставьте код или команду в окно сеанса Cloud Shell, нажав клавиши CTRL+SHIFT+V в Windows и Linux или CMD+SHIFT+V в macOS.

4. Нажмите клавишу ВВОД, чтобы запустить код или команду.

Миграция конфигурации

Скрипт Azure PowerShell представлен в этом документе. Он выполняет следующие операции, которые помогут вам в настройке:

• Создает новый шлюз Standard_V2 или WAF_V2 в указанной подсети виртуальной сети.
• Легко копирует конфигурацию, связанную с шлюзом V1 Standard или WAF, в только что созданный шлюз Standard_V2 или WAF_V2.

Скачивание скрипта

Скрипт миграции можно скачать из коллекция PowerShell. Доступен новый стабильный выпуск (версия 1.0.11) скрипта миграции, который включает в себя основные обновления и исправления ошибок. Рекомендуется использовать эту стабильную версию.

Использование скрипта

В зависимости от настроек и параметров локального окружения PowerShell существует два варианта использования скрипта:

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

Чтобы определить, установлены ли модули Azure Az, выполните команду Get-InstalledModule -Name az. Если установленных модулей Az нет, можно использовать метод Install-Script.

Установка с помощью метода Install-Script (рекомендуется)

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

Запустите скрипт с помощью следующей команды, чтобы получить последнюю версию:

Install-Script -Name AzureAppGWMigration -Force

Эта команда также устанавливает необходимые модули Az.

Установка путем запуска скрипта напрямую

Если у вас установлены некоторые модули Azure Az и их не удается удалить (или не хотите их удалить), можно вручную скачать сценарий с помощью вкладки "Скачивание вручную" в ссылке скачивания скрипта. Скрипт скачивается как необработанный NUPKG-файл. Сведения об установке скрипта из этого NUPKG-файла см. в статье Скачивание пакета вручную.

Версия 1.0.11 — это новая версия скрипта миграции, которая включает основные исправления ошибок. Рекомендуется использовать эту стабильную версию.

Как проверить версию скачаемого скрипта

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

• Извлечь содержимое пакета NuGet в локальную папку.
• .PS1 Откройте файл в папке и проверьте .VERSION его сверху, чтобы подтвердить версию скачаемого скрипта.

<#PSScriptInfo
.VERSION 1.0.10
.GUID be3b84b4-e9c5-46fb-a050-699c68e16119
.AUTHOR Microsoft Corporation
.COMPANYNAME Microsoft Corporation
.COPYRIGHT Microsoft Corporation. All rights reserved.

• Обязательно используйте последнюю стабильную версию из коллекция PowerShell

Запуск скрипта

Выполните следующее, чтобы запустить этот сценарий.

1. Подключитесь к Azure с помощью команды Connect-AzAccount.

2. Импортируйте модули Az с помощью команды Import-Module Az.

3. Set-AzContext Запустите командлет, чтобы задать активный контекст Azure для правильной подписки. Это важный шаг, так как сценарий миграции может очистить существующую группу ресурсов, если она не существует в текущем контексте подписки.

   Set-AzContext -Subscription '<V1 application gateway SubscriptionId>'
   

4. Запустите Get-Help AzureAppGWMigration.ps1, чтобы проверить обязательные параметры:

   AzureAppGWMigration.ps1
    -resourceId <V1 application gateway Resource ID>
    -subnetAddressRange <subnet space you want to use>
    -appgwName <string to use to append>
    -AppGWResourceGroupName <resource group name you want to use>
    -sslCertificates <comma-separated SSLCert objects as above>
    -trustedRootCertificates <comma-separated Trusted Root Cert objects as above>
    -privateIpAddress <private IP string>
    -publicIpResourceId <public IP name string>
    -validateMigration -enableAutoScale
   

Параметры скрипта

• resourceId: [String]: обязательный: этот параметр является идентификатором ресурса Azure для существующего шлюза Standard V1 или WAF версии 1. Чтобы найти это строковое значение, перейдите на портал Azure, выберите свой шлюз приложений или ресурс WAF и щелкните ссылку Свойства для шлюза. На этой странице будет указан идентификатор ресурса.

  Чтобы получить идентификатор ресурса, также можно выполнить следующие команды Azure PowerShell:

  $appgw = Get-AzApplicationGateway -Name <V1 gateway name> -ResourceGroupName <resource group Name>
  $appgw.Id
  

• subnetAddressRange: [String]: обязательный: этот параметр — это пространство IP-адресов, которое вы выделили (или хотите выделить) для новой подсети, содержащей новый шлюз версии 2. Адресное пространство должно быть указано в нотации CIDR. Пример: 10.0.0.0/24. Вам не нужно заранее создать эту подсеть, но CIDR должна быть частью адресного пространства виртуальной сети. Скрипт создает его для вас, если он не существует и если он существует, он использует существующий (убедитесь, что подсеть пуста, содержит только шлюз версии 2, если он есть, и имеет достаточно доступных IP-адресов).

• appgwName: [String]: необязательный. Это строка, используемая в качестве имени нового Standard_V2 или шлюза WAF_V2. Если этот параметр не указан, имя существующего шлюза версии 1 используется с суффиксом _V2 добавлен.

• AppGWResourceGroupName: [String]: необязательно. Имя группы ресурсов, в которой требуется создать ресурсы версии 2 Шлюз приложений (значение <V1-app-gw-rgname>по умолчанию )

• sslCertificates: [PSApplicationGatewaySslCertificate]: необязательный. Разделенный запятыми список объектов PSApplicationGatewaySslCertificate, создаваемых для представления сертификатов TLS/SSL из шлюза V1, необходимо отправить в новый шлюз V2. Для каждого сертификата TLS/SSL, настроенного для шлюза Standard V1 или WAF V1, можно создать новый объект PSApplicationGatewaySslCertificate с помощью команды, показанной New-AzApplicationGatewaySslCertificate здесь. Вам потребуется путь к файлу сертификата TLS/SSL и пароль к нему.

  Этот параметр является необязательным, если у вас нет прослушивателей HTTPS, настроенных для шлюза версии 1 или WAF. При наличии хотя бы одного прослушивателя HTTPS указывать этот параметр необходимо.

  $password = ConvertTo-SecureString <cert-password> -AsPlainText -Force
  $mySslCert1 = New-AzApplicationGatewaySslCertificate -Name "Cert01" `
    -CertificateFile <Cert-File-Path-1> `
    -Password $password
  $mySslCert2 = New-AzApplicationGatewaySslCertificate -Name "Cert02" `
    -CertificateFile <Cert-File-Path-2> `
    -Password $password
  

  Значения для этого параметра в скрипте можно передать в виде $mySslCert1, $mySslCert2 (с разделителями-запятыми), как в предыдущем примере.

• sslCertificates из Keyvault: необязательно. Вы можете скачать сертификаты, хранящиеся в Azure Key Vault, и передать его в скрипт миграции. Чтобы скачать сертификат в виде PFX-файла, выполните следующую команду. Эти команды обращаются к параметру SecretId, а затем сохраняют его содержимое в виде PFX-файла.

   $vaultName = ConvertTo-SecureString <kv-name> -AsPlainText -Force
   $certificateName = ConvertTo-SecureString <cert-name> -AsPlainText -Force
   $password = ConvertTo-SecureString <password> -AsPlainText -Force
  
   $pfxSecret = Get-AzKeyVaultSecret -VaultName $vaultName -Name $certificateName -AsPlainText
   $secretByte = [Convert]::FromBase64String($pfxSecret)
   $x509Cert = New-Object Security.Cryptography.X509Certificates.X509Certificate2
   $x509Cert.Import($secretByte, $null, [Security.Cryptography.X509Certificates.X509KeyStorageFlags]::Exportable)
   $pfxFileByte = $x509Cert.Export([Security.Cryptography.X509Certificates.X509ContentType]::Pkcs12, $password)
  
   # Write to a file
   [IO.File]::WriteAllBytes("KeyVaultcertificate.pfx", $pfxFileByte)
  

  Для каждого сертификата, скачаенного из Keyvault, можно создать новый объект PSApplicationGatewaySslCertificate с помощью команды New-AzApplicationGatewaySslCertificate, показанной здесь. Вам потребуется путь к файлу сертификата TLS/SSL и пароль к нему.

  //Convert the downloaded certificate to SSL object
  $password = ConvertTo-SecureString  <password> -AsPlainText -Force 
  $cert = New-AzApplicationGatewaySSLCertificate -Name <certname> -CertificateFile <Cert-File-Path-1> -Password $password 
  

• trustedRootCertificates: [PSApplicationGatewayTrustedRootCertificate]: необязательный. Разделенный запятыми список объектов PSApplicationGatewayTrustedRootCertificate доверенных корневых сертификатов для проверки подлинности экземпляров серверной части шлюза версии 2.

  $certFilePath = ".\rootCA.cer"
  $trustedCert = New-AzApplicationGatewayTrustedRootCertificate -Name "trustedCert1" -CertificateFile $certFilePath
  

  Чтобы создать список объектов PSApplicationGatewayTrustedRootCertificate, воспользуйтесь командой New-AzApplicationGatewayTrustedRootCertificate.

• privateIpAddress: [String]: необязательный. Конкретный частный IP-адрес, который требуется связать с новым шлюзом версии 2. Это должно быть из той же виртуальной сети, которую вы выделяете для нового шлюза версии 2. Если это не указано, скрипт выделяет частный IP-адрес для шлюза версии 2.

• publicIpResourceId: [String]: необязательный. ResourceId существующего ресурса общедоступного IP-адреса (стандартный номер SKU) в подписке, которую вы хотите выделить для нового шлюза версии 2. Если указано имя ресурса общедоступного IP-адреса, убедитесь, что он существует в успешном состоянии. Если это не указано, скрипт выделяет новый общедоступный IP-адрес в той же группе ресурсов. Имя шлюза версии 2 с добавленным IP-адресом . Если appGWResourceGroupName предоставлен и общедоступный IP-адрес не указан, убедитесь, что общедоступный IP-ресурс с именем AppGWV2Name-IP не существует в группе ресурсов с именем AppGWResourceGroupName в подписке V1.

• validateMigration: [switch]: необязательный . Этот параметр позволяет скрипту выполнять некоторые базовые проверки сравнения конфигурации после создания шлюза версии 2 и копирования конфигурации. По умолчанию проверка не выполняется.

• enableAutoScale: [switch]: необязательный. Используйте этот параметр, чтобы включить автоматическое масштабирование на новом шлюзе версии 2 после его создания. По умолчанию автомасштабирование отключено. Вы всегда можете включить его вручную в новом шлюзе версии 2.

5. Запустите скрипт с соответствующими параметрами. Его выполнение может занять от пяти до семи минут.

   Пример

   AzureAppGWMigration.ps1 `
      -resourceId /subscriptions/aaaa0000-bb11-2222-33cc-444444dddddd/resourceGroups/MyResourceGroup/providers/Microsoft.Network/applicationGateways/myv1appgateway `
      -subnetAddressRange 10.0.0.0/24 `
      -appgwname "MynewV2gw" `
      -AppGWResourceGroupName "MyResourceGroup" `
      -sslCertificates $mySslCert1,$mySslCert2 `
      -trustedRootCertificates $trustedCert `
      -privateIpAddress "10.0.0.1" `
      -publicIpResourceId "/subscriptions/aaaa0000-bb11-2222-33cc-444444dddddd/resourceGroups/MyResourceGroup/providers/Microsoft.Network/publicIPAddresses/MyPublicIP" `
      -validateMigration -enableAutoScale
   

Предостережения и ограничения

• Новый шлюз версии 2 имеет новые общедоступные и частные IP-адреса. Невозможно легко переместить IP-адреса, связанные с существующим шлюзом версии 1, в версию 2. Однако вы можете выделить существующий (нераспределенный) общедоступный или частный IP-адрес для нового шлюза версии 2.
• Необходимо указать пространство IP-адресов для другой подсети в виртуальной сети, где находится шлюз версии 1. Скрипт не может создать шлюз версии 2 в подсети, которая уже имеет шлюз версии 1. Если подсеть уже имеет шлюз версии 2, скрипт может по-прежнему работать, укажите достаточное пространство IP-адресов.
• Если у вас есть группа безопасности сети или определяемые пользователем маршруты, связанные с подсетью шлюза версии 2, убедитесь, что они соответствуют требованиям NSG и требованиям UDR для успешной миграции.
• Политики конечных точек служб для виртуальной сети в настоящее время не поддерживаются в подсети Шлюза приложений.
• Чтобы перенести конфигурацию TLS/SSL, необходимо указать все сертификаты TLS/SSL, используемые в шлюзе версии 1.
• Если для шлюза версии 1 включен режим FIPS, он не переносится в новый шлюз версии 2. Режим FIPS не поддерживается в версии 2.
• Если у вас есть только частный IP-адрес шлюза версии 1, скрипт создает частный и общедоступный IP-адрес для нового шлюза версии 2. Частный IP-адрес только шлюз версии 2 в настоящее время находится в общедоступной предварительной версии. После того как он станет общедоступным, клиенты могут использовать скрипт для передачи своего частного IP-адреса только шлюзу версии 1 на частный IP-адрес только шлюз версии 2.
• Проверка подлинности NTLM и Kerberos не поддерживается Шлюз приложений версии 2. Скрипт не может определить, обслуживает ли шлюз этот тип трафика и может представлять собой критическое изменение от шлюзов версии 1 до шлюзов версии 2 при запуске.
• WAFv2 создается в старом режиме конфигурации WAF; Требуется миграция в политику WAF.

Миграция трафика

Сначала дважды убедитесь, что скрипт успешно создал новый шлюз версии 2 с точной конфигурацией, перенесенной из шлюза версии 1. Это можно сделать на портале Azure.

Кроме того, отправьте небольшой объем трафика через шлюз версии 2 в виде ручного теста.

Ниже приведены некоторые сценарии, в которых текущий шлюз приложений (стандартный) может получать клиентский трафик, и наши рекомендации по каждому из них:

• Настраиваемая зона DNS (например, contoso.com), указывающая на внешний IP-адрес (используя запись A), связанную с шлюзом Standard V1 или WAF V1.

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

• Настраиваемая зона DNS (например, contoso.com), указывающая на метку DNS (например , myappgw.eastus.cloudapp.azure.com с записью CNAME), связанную с шлюзом V1.

  Есть два варианта:

  • Если вы используете общедоступные IP-адреса в шлюзе приложений, вы можете выполнить контролируемую, детализированную миграцию с помощью профиля Диспетчер трафика для добавочного маршрутизации трафика (взвешированного метода маршрутизации трафика) в новый шлюз версии 2.

    Это можно сделать, добавив метки DNS шлюзов приложений версии 1 и версии 2 в профиль Диспетчер трафика и CNAMEing настраиваемую запись DNS (например, ) в домен Диспетчер трафика (например, www.contoso.comcontoso.trafficmanager.net).

  • Кроме того, вы можете обновить запись DNS личного домена, чтобы указать на метку DNS нового шлюза приложений версии 2. В зависимости от срока жизни, настроенного в записи DNS, может потребоваться некоторое время для переноса всего трафика клиента на новый шлюз версии 2.

• Клиенты подключаются к внешнему IP-адресу шлюза приложений.

  Обновите клиенты, чтобы использовать IP-адреса, связанные с недавно созданным шлюзом приложений версии 2. Использовать IP-адреса напрямую не рекомендуется. Вместо этого следует использовать метку DNS-имени (например, yourgateway.eastus.cloudapp.azure.com), связанную с вашим шлюзом приложений, которые можно с помощью записи CNAME направить на вашу собственную зону DNS (например, contoso.com).

Сведения о ценах

Модели ценообразования отличаются для номеров SKU Шлюз приложений версии 1 и V2. Плата за версию 2 взимается на основе потребления. См. Шлюз приложений цены перед переносом сведений о ценах.

Руководство по повышению эффективности затрат

SKU версии 2 поставляется с рядом преимуществ, таких как повышение производительности 5x, улучшенная безопасность с интеграцией Key Vault, более быстрые обновления правил безопасности в WAF_V2, пользовательских правилах WAF, сопоставлениях политик и защите ботов. Она также обеспечивает высокую масштабируемость, оптимизированную маршрутизацию трафика и простую интеграцию со службами Azure. Эти функции могут улучшить общий пользовательский интерфейс, предотвратить замедление во время интенсивного трафика и избежать дорогостоящих нарушений данных.

Существует пять вариантов в номере SKU версии 1 на основе уровня и размера — Standard_Small, Standard_Medium, Standard_Large, WAF_Medium и WAF_Large.

Для дальнейших проблем с ценами обратитесь к CSAM или обратитесь к нашей группе поддержки за помощью.

Часто задаваемые вопросы

Распространенные вопросы о миграции можно найти здесь

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

Сведения о Шлюз приложений версии 2