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

Мы объявили об устаревании SKU шлюза приложений версии V1 (Standard и WAF) 28 апреля 2023 года. SKU версии V1 снимается с производства 28 апреля 2026 года. Дополнительные сведения см. в статье "Миграция шлюзов приложений из SKU V1 в SKU V2" до 28 апреля 2026 г.

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

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

Существует два этапа миграции:

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

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

Предпосылки

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

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

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

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

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

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

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

Существует два варианта в зависимости от вашей локальной настройки и предпочтений в среде PowerShell:

• Если у вас нет установленных модулей Azure Az или не удается удалить модули 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.
• Откройте файл в папке и проверьте .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. Используется Connect-AzAccount для подключения к Azure.

2. Используйте Import-Module Az, чтобы импортировать модули 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, разделенных запятыми, создаваемых для представления доверенных корневых сертификатов для аутентификации ваших внутренних экземпляров из шлюза v2.

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

5. Запустите скрипт с помощью соответствующих параметров. Для завершения может потребоваться пять–семь минут.

   Пример

   AzureAppGWMigration.ps1 `
      -resourceId /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/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/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/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. Шлюз версии 2 только для частных IP-адресов в настоящее время находится в публичном предварительном просмотре. После того как он станет доступным, клиенты могут использовать скрипт для переноса своего шлюза с частными IP-адресами версии 1 на шлюз с частными IP-адресами версии 2.
• WAFv2 создается в старом режиме конфигурации WAF; Требуется миграция в политику WAF.
• Новый WAFv2 настроен для использования CRS 3.0 по умолчанию. Тем не менее, так как CRS 3.0 находится на пути к отмене, рекомендуется обновить до последнего набора правил, DRS 2.1 после миграции. Дополнительные сведения см. в группах и правилах CRS и DRS.

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

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

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

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

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

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

Рекомендации по ценам

Модели ценообразования отличаются для номеров SKU шлюза приложений версии 1 и версии 2. Плата за V2 взимается в зависимости от объема потребления. Перед переносом см. цены на шлюз приложений, чтобы получить информацию о ценах.

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

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

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

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

Распространенные вопросы

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

Дальнейшие шаги

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