Перенос Azure Application Gateway и Web Application Firewall с версии 1 на версию 2

Microsoft объявила об устаревании шлюза приложений V1 (Стандарт и веб-защита приложений) 28 апреля 2023 года. Шлюз приложений версии 1 завершится 28 апреля 2026 г.

Из этой статьи вы узнаете, как перенести шлюз приложений Azure и брандмауэр веб-приложений Azure с версии 1 до версии 2 с помощью скриптов Azure PowerShell. Миграция состоит из двух этапов: миграция конфигурации и миграция трафика. Можно использовать расширенный скрипт клонирования (рекомендуется) или устаревший скрипт клонирования, чтобы клонировать конфигурацию шлюза V1 в новый шлюз версии 2, а затем перенаправить клиентский трафик с минимальным временем простоя.

Дополнительные сведения о прекращении поддержки шлюза приложений версии 1 см. в статье «Миграция с шлюза приложений версии 1 на версию 2 до 28 апреля 2026 года».

Почему переход на версию 2?

Шлюз приложений версии 2 и брандмауэр веб-приложения версии 2 предлагают следующие преимущества по сравнению с версией 1.

• Устойчивость. Избыточность зоны доступности и автомасштабирование.
• Безопасность. Интеграция Azure Key Vault, улучшенные возможности брандмауэра веб-приложений и защита ботов.
• Мониторинг. Комплексный мониторинг использования ЦП, памяти и диска. (версия 1 поддерживает только ЦП.)
• Обнаружение и устранение рисков. Расширенное обнаружение и автоматическое устранение проблем без вмешательства вручную.
• Новые возможности. Выпуск новых функций только для версии 2.

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

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

Предпосылки

• Вам потребуется учетная запись Azure с активной подпиской. Создайте учетную запись бесплатно .

• Вам потребуется существующее развертывание шлюза приложений версии 1 уровня "Стандартный".

• Используйте последние модули PowerShell или вы можете использовать Azure Cloud Shell на портале Azure.

• Если вы используете PowerShell локально, запустите Connect-AzAccount, чтобы создать подключение с Azure.

• В подписке V1 не может существовать шлюз с предоставленными параметрами AppGWV2Name и AppGWResourceGroupName. Это условие предотвращает перезапись существующих ресурсов.

• Во время миграции невозможно выполнить другую плановую операцию на шлюзе версии 1 или любых связанных ресурсах.

• Если вы предоставляете общедоступный IP-адрес, убедитесь, что он находится в успешном состоянии. Если вы не предоставляете общедоступный IP-адрес, но предоставляете AppGWResourceGroupName, убедитесь, что ресурс общедоступного IP-адреса с именем AppGWV2Name-IP не существует в группе ресурсов с именем AppGWResourceGroupName в подписке версии V1.

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

• Если включить сетевую изоляцию в подписке, все общедоступные или частные развертывания шлюза приложений версии 2 должны находиться в подсети, делегированной Microsoft.Network/applicationGateways. Выполните действия по настройке делегирования подсети.

Azure Cloud Shell

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

Чтобы начать Azure Cloud Shell, выполните приведенные действия.

Вариант	Пример/ссылка
Нажмите кнопку Попробовать в правом верхнем углу блока кода или команд. Выбор Try It не копирует код или команду в Cloud Shell.
Перейдите к https://shell.azure.com или нажмите кнопку Launch Cloud Shell, чтобы открыть 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, чтобы запустить код или команду.

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

Миграция конфигурации посвящена настройке нового шлюза версии 2 с параметрами из существующей среды V1. Два скрипта Azure PowerShell упрощают миграцию конфигураций (брандмауэр стандартных или веб-приложений) с шлюзов версии 1 до версии 2. Эти сценарии помогают упростить процесс перехода, автоматив ключевые задачи развертывания и настройки.

Расширенный скрипт клонирования (рекомендуется)

Рекомендуемый вариант — расширенный сценарий клонирования. Он предлагает улучшенный опыт миграции благодаря следующим аспектам.

• Устранение необходимости ручного ввода внешних SSL-сертификатов и доверенных корневых сертификатов серверной части.
• Поддержка развертывания шлюзов V2 только для частных сетей.

Вы можете скачать расширенный скрипт клонирования из коллекции PowerShell.

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

Если существующее развертывание Шлюза приложений версии 1 настроено с помощью внешнего интерфейса только для частного доступа, перед запуском скрипта миграции необходимо зарегистрировать EnableApplicationGatewayNetworkIsolation функцию в подписке для частного развертывания. Этот шаг необходим, чтобы избежать сбоев развертывания.

Для развертываний частного шлюза приложений должно быть настроено делегирование подсети Microsoft.Network/applicationGateways. Выполните действия по настройке делегирования подсети.

Параметры для скрипта

• AppGw V1 ResourceId -Required. Идентификатор ресурса Azure для вашего существующего шлюза Standard V1 или Web Application Firewall V1. Чтобы найти это строковое значение, перейдите на портал Azure, выберите ресурс шлюза приложений или брандмауэра веб-приложений, а затем выберите ссылку "Свойства " для шлюза. Идентификатор ресурса находится на этой панели.

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

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

• SubnetAddressRange -Required. Адрес подсети в нотации CIDR, где будет развернут шлюз приложений версии 2.

• AppGwName -Optional. Имя шлюза приложений версии 2. Значение по умолчанию — {AppGwV1 Name}_migrated.

• AppGwResourceGroupName -Optional. Имя группы ресурсов, в которой будет создан шлюз приложений версии 2. Если вы его не предоставите, будет использоваться группа ресурсов Application Gateway V1.

• PrivateIPAddress -Optional. Частный IP-адрес, назначенный шлюзу приложений версии 2. Если он не указан, назначается случайный частный IP-адрес.

• ValidateBackendHealth -Optional. Проверка после миграции путем ApplicationGatewayBackendHealth сравнения ответов. Если этот параметр не задан, эта проверка пропускается.

• PublicIpResourceId -Optional. Идентификатор ресурса общедоступного IP-адреса (если он уже существует), который будет присоединён к шлюзу приложений. Если не указано, общедоступное имя IP-адреса будет {AppGwName}-IP.

• DisableAutoscale -Optional. Возможность отключения конфигурации автомасштабирования для экземпляров шлюза приложений V2. false Это по умолчанию.

• WafPolicyName -Optional. Имя политики брандмауэра веб-приложения, которая будет создана из конфигурации брандмауэра веб-приложения версии 1 и подключена к шлюзу брандмауэра веб-приложений версии 2.

Действия по запуску скрипта

1. Используйте Connect-AzAccount для подключения к Azure.

2. Используйте Import-Module Az, чтобы импортировать модули Az.

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

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

4. Установите скрипт, выполнив действия по установке скрипта далее в этой статье.

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

   ./AzureAppGWClone.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>
   -privateIpAddress <private IP string>
   -publicIpResourceId <public IP name string>
   - disableAutoscale
   -wafpolicyname <wafpolicyname>
   

   Приведем пример:

   ./AzureAppGWClone.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" `
   -privateIpAddress "10.0.0.1" `
   -publicIpResourceId "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Network/publicIPAddresses/MyPublicIP" `
   

Recommendations

• После завершения скрипта просмотрите конфигурацию шлюза версии 2 на портале Azure и проверьте подключение, отправив трафик непосредственно в IP-адрес шлюза версии 2.

• Скрипт ослабляет проверку внутреннего протокола TLS по умолчанию (без цепочки сертификатов, истечения срока действия или проверки SNI) во время клонирования. Если вам нужны более строгие сертификаты проверки TLS или проверки подлинности, вы можете обновить развертывание Шлюза приложений версии 2 после создания, чтобы добавить доверенные корневые сертификаты и включить эту функцию.

• Для сквозной передачи NTLM и Kerberos, задайте выделенное подключение к резервному серверу в настройках HTTP после клонирования.

Предупреждения

• Необходимо указать пространство IP-адресов для другой подсети в виртуальной сети, содержащей шлюз версии 1. Скрипт не может создать шлюз версии 2 в подсети, которая уже имеет шлюз версии 1. Если подсеть уже имеет шлюз версии 2, сценарий может по-прежнему работать, если доступно достаточное пространство IP-адресов.

• Если у вас есть группа безопасности сети (NSG) или определяемые пользователем маршруты (UDR), связанные с подсетью шлюза V2, убедитесь, что они соответствуют требованиям NSG и требованиям UDR для успешной миграции.

• Если для шлюза версии 1 включен режим FIPS, он не переносится в новый шлюз версии 2.

• Брандмауэр веб-приложений версии 2 по умолчанию настроен для использования основного набора правил (CRS) 3.0. Так как CRS 3.0 находится на пути к отмене, обновите до последнего набора правил после миграции: набор правил по умолчанию (DRS) 2.2. Дополнительные сведения см. в разделе группы правил и правила DRS и CRS для брандмауэра веб-приложений.

Устаревший сценарий клонирования

Устаревший скрипт клонирования упрощает переход следующими компонентами:

• Создание шлюза приложений "Стандартный" версии 2 или брандмауэра веб-приложений версии 2 в подсети виртуальной сети, указанной пользователем.
• Автоматическое копирование конфигурации из существующего шлюза брандмауэра стандартного или веб-приложения версии 1 в только что созданный шлюз версии 2.
• Требование предоставления сертификатов TLS/SSL и проверки подлинности в качестве входных данных. Этот скрипт не поддерживает только частные шлюзы версии V2. Этот скрипт клонирования можно скачать из коллекции PowerShell.

Параметры для скрипта

Устаревший скрипт принимает следующие параметры:

• resourceId. Этот обязательный параметр — это идентификатор ресурса Azure для существующего шлюза версии Standard V1 или шлюза Брандмауэра веб-приложений версии V1. Чтобы найти это строковое значение, перейдите на портал Azure, выберите ресурс шлюза приложений или брандмауэра веб-приложений и выберите ссылку "Свойства " для шлюза. Идентификатор ресурса находится на этой панели.

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

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

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

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

• appgwName. Укажите эту необязательную строку в качестве имени для нового шлюза версии 2 уровня Standard или шлюза Брандмауэра веб-приложений версии 2. Если этот параметр не указан, имя существующего шлюза версии 1 используется с добавленным суффиксом _V2 .

• AppGWResourceGroupName. Эта необязательная строка — это имя группы ресурсов, в которой требуется создать ресурсы Шлюза приложений версии 2. Значение по умолчанию — <V1-app-gw-rgname>.

  Убедитесь, что в подписке V1 нет существующего шлюза приложений с предоставленными значениями AppGWV2Name и AppGWResourceGroupName. Этот параметр перезаписывает существующие ресурсы.

• sslCertificates. Этот параметр предоставляет разделенный запятыми список объектов, создаваемых для представления TLS/SSL-сертификатов PSApplicationGatewaySslCertificate из шлюза V1, которые должны быть отправлены в новый шлюз версии 2.

  Для каждого из ваших сертификатов TLS/SSL, настроенных для шлюза Standard V1 или Брандмауэр веб-приложений V1, можно создать новый PSApplicationGatewaySslCertificate объект с помощью команды, показанной в следующем коде New-AzApplicationGatewaySslCertificate. Вам нужен путь к файлу СЕРТИФИКАТА TLS/SSL и паролю.

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

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

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

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

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

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

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

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

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

Действия по запуску скрипта

1. Используйте Connect-AzAccount для подключения к Azure.

2. Используйте Import-Module Az, чтобы импортировать модули Az.

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

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

4. Установите скрипт, выполнив действия по установке скрипта далее в этой статье.

5. Запустите Get-Help AzureAppGWMigration.ps1 для проверки необходимых параметров.

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

      ./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
   

   Приведем пример:

      ./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-адресов.

• Если у вас есть НСГ или маршруты, определяемые пользователем (UDR), ассоциированные с подсетью шлюза V2, убедитесь, что они соответствуют требованиям НСГ и требованиям UDR для успешной миграции.

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

• Чтобы перенести конфигурацию TLS/SSL, необходимо указать все СЕРТИФИКАТЫ TLS/SSL, используемые в шлюзе версии 1.

• Если для шлюза версии 1 включен режим FIPS, он не переносится в новый шлюз версии 2.

• Экземпляр брандмауэра веб-приложения версии 2 создается в старом режиме настройки брандмауэра веб-приложения. Необходимо осуществить миграцию на политику брандмауэра веб-приложения.

• Брандмауэр веб-приложений версии 2 настроен для использования CRS 3.0 по умолчанию. Так как CRS 3.0 находится на пути к отмене, обновите его до последнего набора правил (DRS 2.2) после миграции. Дополнительные сведения см. в группах правил и правилах CRS и DRS.

Установка скрипта

У вас есть два варианта в зависимости от конфигурации вашей локальной среды PowerShell и предпочтений.

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

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

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

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

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

• Для улучшенного скрипта клонирования с сохранением общедоступных IP-адресов используйте Install-Script -Name AzureAppGWIPMigrate -Force.
• Для усовершенствованного скрипта клонирования используйте Install-Script -Name AzureAppGWClone -Force.
• Для устаревшего скрипта клонирования используйте Install-Script -Name AzureAppGWMigration -Force.

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

Установка с помощью скрипта напрямую

Если у вас установлены некоторые модули Azure Az и их не удается удалить (или вы не хотите их удалить), вы можете вручную скачать скрипт с помощью вкладки "Скачивание вручную " в ссылке скачивания скрипта.

Скрипт скачан в виде необработанного NUPKG-файла. Чтобы установить скрипт из этого NUPKG-файла, см. раздел "Скачивание пакетов вручную".

Для устаревшего сценария клонирования версия 1.0.11 является новой версией скрипта миграции. Она включает основные исправления ошибок. Обязательно используйте последнюю стабильную версию из коллекции PowerShell.

Проверка версии скачаемого скрипта

1. Извлеките содержимое пакета NuGet.

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

   <#PSScriptInfo
   .VERSION 1.0.10
   .GUID aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb
   .AUTHOR Microsoft Corporation
   .COMPANYNAME Microsoft Corporation
   .COPYRIGHT Microsoft Corporation. All rights reserved.
   

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

Предпосылки

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

Скрипт хранения общедоступных IP-адресов

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

• Скрипт резервирует общедоступный IP-адрес Уровня "Базовый" из версии 1, преобразует его в "Стандартный" и подключает его к шлюзу версии 2. Это действие эффективно перенаправляет весь входящий трафик на шлюз версии 2.
• Эта операция по замене IP-адресов обычно приводит к короткому простою примерно от одной до пяти минут. Планируйте работу соответствующим образом.
• После успешного выполнения скрипта общедоступный IP-адрес перемещается из шлюза приложений версии 1 в шлюз приложений версии 2. Шлюз приложений версии 1 получает новый общедоступный IP-адрес.
• Во время миграции IP-адресов не пытайтесь выполнить любую другую операцию на шлюзах версии 1 и версии 2 или любых связанных ресурсах.
• Переключение общедоступного IP-адреса, выполняемого этим скриптом, является необратимым. После его запуска вы не сможете вернуть IP-адрес в шлюз версии 1 с помощью скрипта.

Этот сценарий хранения общедоступных IP-адресов можно скачать из коллекции PowerShell.

Параметры для скрипта

Для этого скрипта требуются следующие обязательные параметры:

• v1resourceId. Идентификатор ресурса шлюза версии 1, общедоступный IP-адрес которого будет зарезервирован и связан с версией 2.
• v2resourceId. Идентификатор ресурса шлюза версии 2, которому будет назначен общедоступный IP-адрес версии 1. Шлюз версии 2 можно создать вручную или с помощью любого из скриптов клонирования.

После скачивания и установки скрипта запустите AzureAppGWIPMigrate.ps1 с необходимыми параметрами:

   ./AzureAppGWIPMigrate.ps1
    -v1resourceId <V1 application gateway resource ID>
    -v2resourceId <V2 application gateway resource ID>

Приведем пример:

   ./AzureAppGWIPMigrate.ps1 `
   -v1resourceId /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Network/applicationGateways/myv1appgateway `
   -v2resourceId /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Network/applicationGateways/myv2appgateway `

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

Рекомендации по миграции трафика

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

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

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

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

  У вас есть два варианта:

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

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

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

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

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

Задачи после миграции

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

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

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

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

Шлюз приложений версии 2 предоставляет ряд преимуществ, таких как:

• Повышение производительности в 5 раз.
• Улучшена безопасность с интеграцией Key Vault.
• Более быстрые обновления правил безопасности в брандмауэре веб-приложений версии 2.
• Пользовательские правила брандмауэра веб-приложений.
• Ассоциации политик
• Защита бота.

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

Пять вариантов доступны в версии V1, основанной на уровне и размере: Стандартный Малый, Стандартный Средний, Стандартный Большой, Средний Брандмауэр веб-приложений и Большой Брандмауэр веб-приложений. Сведения о ценах в соответствии с регионом см. на странице цен.

Сценарии в следующей таблице являются примерами только для иллюстраций. Вычисления основаны на восточном регионе США и на шлюзе с двумя экземплярами в версии V1. Переменная стоимость в версии 2 основана на одном из трех измерений с наибольшим использованием: новых подключений (50 в секунду), постоянных подключений (2500 в минуту) и пропускной способности (2,22 Мбит/с на единицу емкости).

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

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

Ответы на распространенные вопросы о миграции см. в разделе часто задаваемые вопросы об выходе шлюза приложений версии 1.

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

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