Migrowanie bramy aplikacyjnej Azure i zapory aplikacyjnej z wersji 1 do wersji 2

Ogłosiliśmy wycofanie jednostki SKU usługi Application Gateway w wersji 1 (Standardowa i WAF) 28 kwietnia 2023 r. SKU V1 zostanie wycofane 28 kwietnia 2026 r. Aby uzyskać więcej informacji, zobacz Migruj swoje bramy aplikacji z wersji SKU V1 do SKU V2 do 28 kwietnia 2026 r..

Migracja do Azure Application Gateway i Zapory Aplikacji Internetowych (WAF) w wersji V2 oferuje kilka korzyści:

• Lepsza odporność systemu: Niezawodność AZ, automatyczne skalowanie
• Lepsze zabezpieczenia: integracja z usługą Azure Key Vault, ulepszone możliwości zapory aplikacji internetowych (WAF), ochrona przed botami
• Ulepszone możliwości monitorowania: w przeciwieństwie do wersji 1, która miała tylko monitorowanie procesora CPU, wersja 2 zapewnia kompleksowe monitorowanie użycia procesora CPU, pamięci i dysku.
• Ulepszone wykrywanie i automatyczne ograniczanie ryzyka: bramy w wersji 2 oferują zaawansowane mechanizmy wykrywania i zautomatyzowane procesy ograniczania ryzyka, które mogą szybko i dokładnie identyfikować i rozwiązywać problemy bez konieczności ręcznej interwencji.
• Wszystkie nowe funkcje są dostępne dla SKU V2.

Zdecydowanie zaleca się utworzenie planu migracji. Bramy V1 nie są automatycznie aktualizowane do V2. Skorzystaj z tego przewodnika migracji, aby ułatwić planowanie i przeprowadzanie migracji.

Migracja obejmuje dwa etapy:

1. Migrowanie konfiguracji
2. Migrowanie ruchu klienta

Ten artykuł pomaga przede wszystkim w migracji konfiguracji. Migracja ruchu klienta różni się w zależności od środowiska. Niektóre ogólne zalecenia zostały przedstawione w tym artykule.

Wymagania wstępne

• Konto platformy Azure z aktywną subskrypcją. Utwórz konto bezpłatnie.
• Istniejący Application Gateway V1 Standard.
• Upewnij się, że masz najnowsze moduły programu PowerShell lub możesz użyć usługi Azure Cloud Shell w portalu.
• Jeśli używasz programu PowerShell lokalnie, musisz też uruchomić polecenie Connect-AzAccount, aby utworzyć połączenie z platformą Azure.
• Upewnij się, że nie ma istniejącej bramy aplikacyjnej z podaną nazwą appGW V2 i nazwą grupy zasobów w subskrypcji w wersji V1. Spowoduje to ponowne zapisywanie istniejących zasobów.
• Jeśli podano publiczny adres IP, upewnij się, że jest w stanie pomyślnym. Jeśli nie podano nazwy AppGWResourceGroupName, upewnij się, że zasób publicznego adresu IP o nazwie AppGWV2Name-IP nie istnieje w grupie zasobów o nazwie AppGWResourceGroupName w subskrypcji V1.
• W przypadku jednostki SKU w wersji 1 certyfikaty uwierzytelniania są wymagane do skonfigurowania połączeń TLS z serwerami zaplecza. Jednostka SKU w wersji 2 wymaga przekazania głównych certyfikatów zaufania w tym samym celu. Wersja 1 zezwala na używanie certyfikatów z podpisem własnym jako certyfikatów uwierzytelniania, natomiast program V2 nakazuje generowanie i przekazywanie certyfikatu głównego z podpisem własnym, jeśli certyfikaty z podpisem własnym są używane w zapleczu.
• Upewnij się, że żadna inna operacja nie jest planowana na bramie V1 ani na żadnych związanych z nią zasobach podczas migracji.

Azure Cloud Shell

Na platformie Azure hostowane jest interaktywne środowisko wiersza poleceń Azure Cloud Shell, z którego można korzystać przez przeglądarkę. Do pracy z usługami platformy Azure można używać programu Bash lub PowerShell w środowisku Cloud Shell. Aby uruchomić kod w tym artykule, możesz użyć wstępnie zainstalowanych poleceń usługi Cloud Shell bez konieczności instalowania niczego w środowisku lokalnym.

Aby uruchomić środowisko Azure Cloud Shell:

Opcja	Przykład/link
Wybierz pozycję Wypróbuj w prawym górnym rogu bloku kodu lub polecenia. Wybranie pozycji Wypróbuj nie powoduje automatycznego skopiowania kodu lub polecenia do usługi Cloud Shell.
Przejdź do witryny https://shell.azure.com lub wybierz przycisk Uruchom Cloud Shell, aby otworzyć środowisko Cloud Shell w przeglądarce.
Wybierz przycisk Cloud Shell na pasku menu w prawym górnym rogu witryny Azure Portal.

Aby użyć usługi Azure Cloud Shell:

1. Uruchom usługę Cloud Shell.

2. Wybierz przycisk Kopiuj w bloku kodu (lub bloku poleceń), aby skopiować kod lub polecenie.

3. Wklej kod lub polecenie do sesji usługi Cloud Shell, wybierając Ctrl++V w systemie macOS.

4. Wybierz Enter, aby uruchomić kod lub polecenie.

Migracja konfiguracji

Migracja konfiguracji skupia się na uruchomieniu nowej bramy V2 z ustawieniami z aktualnego środowiska V1. Udostępniamy dwa skrypty programu Azure PowerShell zaprojektowane w celu ułatwienia migracji konfiguracji z wersji V1 (Standard lub WAF) do bram V2 (Standard_V2 lub WAF_V2). Te skrypty pomagają usprawnić proces przejścia, automatyzując kluczowe zadania wdrażania i konfiguracji.

1. Ulepszony skrypt klonowania

Jest to nowe środowisko, które oferuje ulepszone środowisko migracji przez:

• Wykluczenie konieczności ręcznego wprowadzania certyfikatów SSL interfejsu frontend i zaufanych certyfikatów głównych backendu.
• Obsługa wdrażania bram V2 przeznaczonych wyłącznie do użytku prywatnego.

Możesz pobrać skrypt rozszerzonego klonowania z galerii programu PowerShell.

Parametry skryptu: Ten skrypt przyjmuje poniższe parametry:

• AppGw V1 ResourceId — Wymagany: ten parametr jest identyfikatorem zasobu platformy Azure dla istniejącej bramy Standard V1 lub WAF V1. Aby znaleźć tę wartość ciągu, przejdź do witryny Azure Portal, wybierz bramę aplikacji lub zasób zapory aplikacji internetowej, a następnie kliknij link Właściwości dla bramy. Identyfikator zasobu znajduje się na tej stronie. Możesz również uruchomić następujące polecenia programu Azure PowerShell, aby uzyskać identyfikator zasobu:

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

• ZakresAdresówPodsieci - wymagane: adres podsieci w notacji CIDR, gdzie ma zostać wdrożona usługa Application Gateway V2
• AppGwName - opcjonalnie: nazwa bramy aplikacyjnej v2. Wartość domyślna : {AppGwV1 Name}_migrated
• AppGwResourceGroupName -Optional: Nazwa grupy zasobów, w której zostanie utworzona usługa Application Gateway w wersji 2. Jeśli nie zostanie podana, zostanie użyta grupa zasobów usługi Application Gateway w wersji 1.
• PrivateIPAddress -Optional: Prywatny adres IP, który ma zostać przypisany do usługi Application Gateway w wersji 2. Jeśli nie zostanie podany, zostanie przypisany losowy prywatny adres IP.
• ValidateBackendHealth — opcjonalnie: weryfikacja po migracji przez porównanie odpowiedzi ApplicationGatewayBackendHealth. Jeśli nie zostanie ustawiona, ta walidacja zostanie pominięta.
• PublicIpResourceId — opcjonalnie: identyfikator zasobu publicznego adresu IP (jeśli już istnieje) można dołączyć do bramy aplikacji. Jeśli nie zostanie podana, nazwa publicznego adresu IP będzie następująca: {AppGwName}-IP.
• DisableAutoscale -Optional: Wyłącz konfigurację automatycznego skalowania dla instancji Application Gateway V2, domyślnie false
• WafPolicyName (opcjonalnie): Nazwa polityki WAF, która zostanie utworzona z Konfiguracji WAF wersji 1 i dołączona do bramy WAF wersji 2.

Jak uruchomić skrypt

Aby uruchomić skrypt:

1. Użyj polecenia Connect-AzAccount , aby nawiązać połączenie z platformą Azure.
2. Użyj polecenia Import-Module Az , aby zaimportować moduły Az.
3. Uruchom cmdlet Set-AzContext aby ustawić aktywny kontekst platformy Azure na poprawną subskrypcję. Jest to ważny krok, ponieważ skrypt migracji może wyczyścić istniejącą grupę zasobów, jeśli nie istnieje w bieżącym kontekście subskrypcji.

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

4. Zainstaluj skrypt, wykonując kroki instalacji skryptu
5. Uruchom skrypt przy użyciu odpowiednich parametrów. Ukończenie może potrwać od pięciu do siedmiu minut.

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

   Przykład

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

Rekomendacje

• Po zakończeniu skryptu przejrzyj konfigurację bramy w wersji 2 w witrynie Azure Portal i przetestuj łączność, wysyłając ruch bezpośrednio do adresu IP bramy w wersji 2.
• Skrypt domyślnie rozluźnia walidację TLS na zapleczu (bez łańcucha certyfikatów, wygaśnięcia ani walidacji SNI) podczas klonowania. Jeśli bardziej rygorystyczne certyfikaty weryfikacji protokołu TLS lub uwierzytelniania są wymagane, klient może zaktualizować swoją usługę Application Gateway w wersji 2 po utworzeniu, aby dodać zaufane certyfikaty główne i włączyć tę funkcję zgodnie z wymaganiami.
• W przypadku przekazywania NTLM/Kerberos, ustaw dedykowane połączenie backendowe na wartość "true" w ustawieniach HTTP po sklonowaniu.

Zastrzeżenia

• Musisz podać przestrzeń adresową IP dla innej podsieci w sieci wirtualnej, w której znajduje się brama V1. Skrypt nie może utworzyć bramy w wersji 2 w podsieci, która ma już bramę w wersji 1. Jeśli podsieć ma już bramę w wersji 2, skrypt może nadal działać, o ile dostępna jest wystarczająca ilość przestrzeni adresowej IP.
• Jeśli masz grupę zabezpieczeń sieciowych lub trasy zdefiniowane przez użytkownika skojarzone z podsiecią bramy w wersji V2, upewnij się, że spełniają wymagania NSG i UDR dotyczące pomyślnej migracji.
• Jeśli dla bramy w wersji 1 jest włączony tryb FIPS, nie jest on migrowany do nowej bramy w wersji 2.
• Nowy WAFV2 jest domyślnie skonfigurowany do używania CRS 3.0. Jednak ponieważ CRS 3.0 jest przeznaczony do wycofania, zalecamy uaktualnienie do najnowszego zestawu reguł, DRS 2.1, po dokonaniu migracji. Aby uzyskać więcej informacji, zobacz Grupy reguł CRS i DRS oraz reguły mające sieciową grupę zabezpieczeń lub trasy zdefiniowane przez użytkownika skojarzone z podsiecią bramy w wersji 2. Upewnij się, że są one zgodne z wymaganiami sieciowej grupy zabezpieczeń i wymaganiami trasy zdefiniowanej przez użytkownika w celu pomyślnej migracji.

2. Starszy skrypt klonowania

Jest to starszy skrypt klonowania, który ułatwia przejście przez:

• Tworzenie nowej bramy aplikacji Standard_V2 lub WAF_V2 w podsieci wirtualnej sieci, którą określił użytkownik.
• Automatyczne kopiowanie konfiguracji z istniejącej bramy Standard lub Web Application Firewall (WAF) w wersji 1 do nowo utworzonej bramy w wersji 2.
• Wymaga od klienta dostarczenia certyfikatów SSL oraz uwierzytelniających jako dane wejściowe i nie obsługuje bram V2 tylko prywatnych. Ten skrypt klonowania można pobrać z PowerShell Gallery.

Parametry skryptu: Starszy skrypt przyjmuje poniższe parametry:

• resourceId: [Ciąg]: Wymagany: Ten parametr jest identyfikatorem zasobu platformy Azure dla istniejącej bramy Standard V1 lub zapory aplikacji internetowej V1. Aby znaleźć tę wartość ciągu, przejdź do witryny Azure Portal, wybierz bramę aplikacji lub zasób zapory aplikacji internetowej, a następnie kliknij link Właściwości dla bramy. Identyfikator zasobu znajduje się na tej stronie. Możesz również uruchomić następujące polecenia programu Azure PowerShell, aby uzyskać identyfikator zasobu:

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

• subnetAddressRange: [Ciąg]: Wymagany: Ten parametr określa przestrzeń adresową IP, którą przydzieliłeś (lub chcesz przydzielić) dla nowej podsieci zawierającej nową bramę V2. Przestrzeń adresowa musi być określona w notacji CIDR. Na przykład: 10.0.0.0/24. Nie musisz z wyprzedzeniem tworzyć tej podsieci, ale ciDR musi być częścią przestrzeni adresowej sieci wirtualnej. Skrypt tworzy go dla Ciebie, jeśli nie istnieje, a jeśli już jest, korzysta z istniejącego. Upewnij się, że podsieć jest albo pusta, zawiera tylko bramę w wersji V2, jeśli jest, i ma wystarczającą liczbę dostępnych adresów IP.
• appgwName: [String]: opcjonalne. Jest to ciąg znaków, którego należy użyć jako nazwy dla nowej bramy Standard_V2 lub WAF_V2. Jeśli ten parametr nie zostanie podany, nazwa istniejącej bramy w wersji 1 będzie używana z dodanym sufiksem _V2.
• AppGWResourceGroupName: [String]: Opcjonalne. Nazwa grupy zasobów, w której mają zostać utworzone zasoby usługi Application Gateway w wersji 2 (wartość domyślna to <V1-app-gw-rgname>)

• sslCertificates: [PSApplicationGatewaySslCertificate]: Opcjonalne. Rozdzielana przecinkami lista obiektów PSApplicationGatewaySslCertificate tworzonych do reprezentowania certyfikatów TLS/SSL z bramy w wersji 1 musi zostać przekazana do nowej bramy w wersji 2. Dla każdego certyfikatu TLS/SSL skonfigurowanego dla bramy Standardowa V1 lub WAF V1 można utworzyć nowy obiekt PSApplicationGatewaySslCertificate za pomocą New-AzApplicationGatewaySslCertificate pokazanego tutaj polecenia. Potrzebna jest ścieżka do pliku certyfikatu TLS/SSL i hasła.

  Ten parametr jest opcjonalny tylko wtedy, gdy nie masz skonfigurowanych odbiorników HTTPS dla bramy w wersji V1 lub zapory aplikacyjnej WAF. Jeśli masz co najmniej jedną konfigurację odbiornika HTTPS, musisz określić ten parametr.

       $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
  

  W poprzednim przykładzie można przekazać $mySslCert1, $mySslCert2 w formie wartości rozdzielonych przecinkami jako wartości dla tego parametru w skrypcie.

• sslCertificates z usługi Keyvault: opcjonalnie. Możesz pobrać certyfikaty przechowywane w usłudze Azure Key Vault i przekazać je do skryptu migracji. Aby pobrać certyfikat jako plik PFX, uruchom następujące polecenie. Te polecenia uzyskują dostęp do identyfikatora SecretId, a następnie zapisują zawartość jako plik 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)
  

  Dla każdego certyfikatu pobranego z usługi Keyvault można utworzyć nowy obiekt PSApplicationGatewaySslCertificate za pomocą polecenia New-AzApplicationGatewaySslCertificate pokazanego tutaj. Potrzebna jest ścieżka do pliku certyfikatu TLS/SSL i hasła.

  //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]: Opcjonalnie. Lista obiektów PSApplicationGatewayTrustedRootCertificate oddzielonych przecinkami, które tworzysz, aby reprezentować zaufane certyfikaty główne do uwierzytelniania wystąpień zaplecza z twojej bramy w wersji 2.

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

  Aby utworzyć listę obiektów PSApplicationGatewayTrustedRootCertificate, zobacz New-AzApplicationGatewayTrustedRootCertificate.

• privateIpAddress: [Ciąg znaków]: Opcjonalne. Określony prywatny adres IP, który chcesz skojarzyć z nową bramą wersji 2. To musi pochodzić z tego samego VNet, który przydzielasz dla swojej nowej bramy w wersji 2. Jeśli nie zostanie określony, skrypt przydziela prywatny adres IP twojej bramy w wersji 2.

• publicIpResourceId: [Ciąg]: Opcjonalne. ResourceId istniejącego zasobu publicznego adresu IP (standardowy SKU) w twojej subskrypcji, który chcesz przydzielić do nowej bramy w wersji V2. Jeśli podano nazwę zasobu publicznego adresu IP, upewnij się, że istnieje on w stanie zakończonym sukcesem. Jeśli nie zostanie określony, skrypt przydzieli nowy publiczny adres IP w tej samej grupie zasobów. Nazwa to nazwa bramy V2 z dołączonym -IP. Jeśli podano nazwę AppGWResourceGroupName i nie podano publicznego adresu IP, upewnij się, że zasób publicznego adresu IP o nazwie AppGWV2Name-IP nie istnieje w grupie zasobów o nazwie AppGWResourceGroupName w subskrypcji V1.

• validateMigration: [switch]: Opcjonalne. Aby skrypt mógł wykonywać podstawowe weryfikacje porównawcze konfiguracji po utworzeniu bramy V2 i skopiowaniu konfiguracji, użyj tego parametru. Domyślnie nie jest wykonywana walidacja.

• enableAutoScale: [przełącznik]: Opcjonalne. Użyj tego parametru, aby skrypt włączył autoskalowanie w nowej bramie V2 po jej utworzeniu. Domyślnie skalowanie automatyczne jest wyłączone. Zawsze możesz włączyć ją ręcznie później w nowo utworzonej bramie V2.

Jak uruchomić skrypt

Aby uruchomić skrypt:

1. Użyj polecenia Connect-AzAccount , aby nawiązać połączenie z platformą Azure.
2. Użyj polecenia Import-Module Az , aby zaimportować moduły Az.
3. Uruchom cmdlet Set-AzContext aby ustawić aktywny kontekst platformy Azure na poprawną subskrypcję. Jest to ważny krok, ponieważ skrypt migracji może wyczyścić istniejącą grupę zasobów, jeśli nie istnieje w bieżącym kontekście subskrypcji.

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

4. Zainstaluj skrypt, wykonując kroki instalacji skryptu
5. Uruchom polecenie Get-Help AzureAppGWMigration.ps1 , aby sprawdzić wymagane parametry:
6. Uruchom skrypt przy użyciu odpowiednich parametrów. Ukończenie może potrwać od pięciu do siedmiu minut.

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

   Przykład

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

Zastrzeżenia\Ograniczenia

• Nowy gateway w wersji 2 ma nowe publiczne i prywatne adresy IP. Nie można bezproblemowo przenieść adresów IP skojarzonych z istniejącą bramą V1 do wersji 2. Można jednak przydzielić istniejący (nieprzydzielony) publiczny lub prywatny adres IP do nowej bramy V2.
• Musisz podać przestrzeń adresową IP dla innej podsieci w sieci wirtualnej, w której znajduje się brama V1. Skrypt nie może utworzyć bramy w wersji 2 w podsieci, która ma już bramę w wersji 1. Jeśli podsieć ma już bramę w wersji 2, skrypt może nadal działać, o ile dostępna jest wystarczająca ilość przestrzeni adresowej IP.
• Jeśli masz grupę zabezpieczeń sieci lub trasy zdefiniowane przez użytkownika (UDR) skojarzone z subnetem bramy V2, upewnij się, że są zgodne z wymaganiami NSG i wymaganiami UDR w celu pomyślnej migracji.
• Polityki punktu końcowego usługi sieci wirtualnej nie są obecnie obsługiwane w podsieci Application Gateway.
• Aby przeprowadzić migrację konfiguracji protokołu TLS/SSL, należy określić wszystkie certyfikaty TLS/SSL używane w bramie w wersji 1.
• Jeśli dla bramy w wersji 1 jest włączony tryb FIPS, nie jest on migrowany do nowej bramy w wersji 2.
• WAFv2 jest tworzony w starym trybie konfiguracji zapory aplikacji internetowej; wymagana jest migracja do zasad zapory aplikacji internetowej.
• Nowy WAFv2 jest domyślnie skonfigurowany do używania CRS 3.0. Jednak ponieważ CRS 3.0 jest przeznaczony do wycofania, zalecamy uaktualnienie do najnowszego zestawu reguł, DRS 2.1, po dokonaniu migracji. Aby uzyskać więcej informacji, zapoznaj się z CRS and DRS rule groups and rules

Instalowanie skryptu

Dostępne są dwie opcje w zależności od konfiguracji i preferencji lokalnego środowiska programu PowerShell:

• Jeśli nie masz zainstalowanych modułów Azure Az lub nie masz nic przeciwko odinstalowaniu modułów Azure Az, najlepszym rozwiązaniem jest użycie Install-Script opcji uruchamiania skryptu.
• Jeśli chcesz zachować moduły Azure Az, najlepszym rozwiązaniem jest pobranie skryptu i uruchomienie go bezpośrednio. Aby ustalić, czy masz zainstalowane moduły Azure Az, uruchom polecenie Get-InstalledModule -Name az. Jeśli nie widzisz żadnych zainstalowanych modułów Az, możesz użyć Install-Script metody .

Instalowanie przy użyciu metody Install-Script (zalecane)

Aby użyć tej opcji, nie można zainstalować modułów Azure Az na komputerze. Jeśli są zainstalowane, następujące polecenie wyświetla błąd. Możesz odinstalować moduły Azure Az lub użyć drugiej opcji, aby pobrać skrypt ręcznie i uruchomić go.

Uruchom skrypt za pomocą następującego polecenia, aby uzyskać najnowszą wersję:

• W celu ulepszonego sklonowania skryptu zatrzymywania publicznych adresów IP — Install-Script -Name AzureAppGWIPMigrate -Force

• W przypadku rozszerzonego skryptu klonowania — Install-Script -Name AzureAppGWClone -Force

• W przypadku starszego skryptu klonowania — Install-Script -Name AzureAppGWMigration -Force

To polecenie instaluje również wymagane moduły Az.

Instalowanie bezpośrednio przy użyciu skryptu

Jeśli masz zainstalowane moduły Azure Az i nie możesz ich odinstalować (lub nie chcesz ich odinstalować), możesz ręcznie pobrać skrypt przy użyciu karty Pobieranie ręczne w linku pobierania skryptu.

Skrypt jest pobierany jako nieprzetworzony plik nupkg. Aby zainstalować skrypt z tego pliku nupkg, zobacz instrukcje Ręczne pobieranie pakietu.

W przypadku starszego skryptu klonowania wersja 1.0.11 to nowa wersja skryptu migracji, która zawiera główne poprawki błędów. Upewnij się, że używasz najnowszej stabilnej wersji z Galeria programu PowerShell

Jak sprawdzić wersję pobranego skryptu

Aby sprawdzić wersję pobranego skryptu, wykonaj następujące kroki:

1. Wyodrębnij zawartość pakietu NuGet.
2. .PS1 Otwórz plik w folderze i sprawdź .VERSION go u góry, aby potwierdzić wersję pobranego skryptu

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

Migracja ruchu

Wymagania wstępne

• Najpierw dokładnie sprawdź, czy skrypt pomyślnie utworzył nową bramę w wersji V2 z dokładną konfiguracją przeniesioną z bramy w wersji V1. Możesz to sprawdzić w witrynie Azure Portal.
• Wyślij również niewielką ilość ruchu przez bramę w wersji 2 jako test ręczny.

Skrypt przechowywania publicznego adresu IP

Po pomyślnym przeprowadzeniu migracji konfiguracji i dokładnym przetestowaniu nowej bramy V2, ten krok koncentruje się na przekierowywaniu ruchu na żywo. Udostępniamy skrypt programu Azure PowerShell zaprojektowany tak, aby zachować publiczny adres IP z wersji 1.

• Zamiana publicznego adresu IP: ten skrypt rezerwuje podstawowy publiczny adres IP z wersji 1, konwertuje go na standardowy i przypisuje do bramy w wersji 2. Skutecznie przekierowuje cały ruch przychodzący do bramy V2.
• Oczekiwany przestój: ta operacja zamiany adresów IP zwykle powoduje krótki przestój około 1–5 minut. Odpowiednio zaplanuj.
• Po pomyślnym uruchomieniu skryptu publiczny adres IP zostanie przeniesiony z usługi Application Gateway w wersji 1 do usługi Application Gateway w wersji 2, a usługa Application Gateway v1 otrzymuje nowy publiczny adres IP.

Ten skrypt przechowywania publicznego adresu IP można pobrać z galerii programu PowerShell

Parametry skryptu:

Ten skrypt wymaga następujących obowiązkowych parametrów:

• V1 ResourceId — identyfikator zasobu usługi Application Gateway w wersji 1, której publiczny adres IP zostanie zarezerwowany i skojarzony z wersją 2.
• V2 ResourceId — identyfikator zasobu usługi Application Gateway w wersji 2, do której zostanie przypisany publiczny adres IP w wersji 1. Bramę w wersji 2 można utworzyć ręcznie lub użyć dowolnego skryptu klonowania.

Po pobraniu i zainstalowaniu skryptu

Wykonaj AzureAppGWIPMigrate.ps1 z wymaganymi parametrami:

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

Przykład

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

Po zakończeniu zmiany adresów IP klienci powinni zweryfikować operacje kontrolne i danych na bramie w wersji V2. Wszystkie akcje warstwy sterowania, poza usuwaniem, zostaną wyłączone w bramce V1.

Zalecenia dotyczące migracji ruchu

Poniżej przedstawiono kilka scenariuszy, w których bieżąca brama aplikacji (Standardowa) może odbierać ruch klientów i nasze zalecenia dotyczące każdego z nich:

• Niestandardowa strefa DNS (na przykład contoso.com), która wskazuje adres IP frontonu (przy użyciu rekordu A) skojarzonego z bramą Standard V1 lub WAF V1. Rekord DNS można zaktualizować tak, aby wskazywał adres IP frontonu lub etykietę DNS skojarzoną z bramą aplikacji Standard_V2. W zależności od skonfigurowanego TTL dla rekordu DNS, może upłynąć trochę czasu, zanim cały ruch klienta przejdzie do nowej bramy V2.
• Niestandardowa strefa DNS (na przykład contoso.com), która wskazuje etykietę DNS (na przykład: myappgw.eastus.cloudapp.azure.com używając rekordu CNAME) skojarzoną z twoją bramą V1. Dostępne są dwie opcje:
  • Jeśli używasz publicznych adresów IP w bramie aplikacji, możesz przeprowadzić kontrolowaną, szczegółową migrację przy użyciu profilu usługi Traffic Manager w celu przyrostowego kierowania ruchu (metody routingu ważonego ruchu) do nowej bramy w wersji 2. Można to zrobić, dodając etykiety DNS bram aplikacji w wersji 1 i 2 do profilu usługi Traffic Manager oraz tworząc rekord CNAME dla swojego niestandardowego rekordu DNS (na przykład www.contoso.com) wskazujący na domenę usługi Traffic Manager (na przykład contoso.trafficmanager.net).
  • Możesz też zaktualizować rekord DNS domeny niestandardowej, aby wskazywał etykietę DNS nowej bramy aplikacji V2. W zależności od skonfigurowanego TTL dla rekordu DNS, może upłynąć trochę czasu, zanim cały ruch klienta przejdzie do nowej bramy V2.
• Klienci łączą się z adresem IP interfejsu frontowego bramy aplikacyjnej. Zaktualizuj klientów, aby używali adresu IP skojarzonego z nowo utworzoną bramą aplikacji w wersji 2. Zalecamy, aby nie używać bezpośrednio adresów IP. Rozważ użycie etykiety nazwy DNS (na przykład yourgateway.eastus.cloudapp.azure.com) skorelowanej z bramą aplikacyjną, którą można powiązać z własną niestandardową strefą DNS przy użyciu CNAME (na przykład contoso.com).

Po migracji

Po pomyślnym zakończeniu migracji ruchu i po pełnym sprawdzeniu, czy aplikacja działa prawidłowo za pośrednictwem bramy w wersji 2, można bezpiecznie zaplanować zlikwidowanie i usunięcie starego zasobu usługi Application Gateway w wersji 1, aby uniknąć niepotrzebnych kosztów.

Zagadnienia do rozważenia dotyczące cennika

Modele cenowe różnią się w przypadku jednostek SKU usługi Application Gateway w wersji 1 i 2. Opłata za V2 jest naliczana na podstawie użycia. Zobacz Cennik usługi Application Gateway przed migracją, aby uzyskać informacje o cenach.

Wskazówki dotyczące wydajności kosztów

Jednostka SKU w wersji 2 oferuje szereg zalet, takich jak pięciokrotne zwiększenie wydajności, lepsze zabezpieczenia dzięki integracji z usługą Key Vault, szybsze aktualizacje reguł zabezpieczeń w WAF_V2, niestandardowe reguły WAF, skojarzenia z zasadami oraz ochrona przed botami. Oferuje również wysoką skalowalność, zoptymalizowany routing ruchu i bezproblemową integrację z usługami platformy Azure. Te funkcje mogą poprawić ogólne środowisko użytkownika, zapobiec spowolnieniu w czasie dużego ruchu i uniknąć kosztownych naruszeń danych.

W jednostce SKU "V1" dostępnych jest pięć wariantów zależnych od warstwy i rozmiaru — Standard_Small, Standard_Medium, Standard_Large, WAF_Medium i WAF_Large.

W przypadku dodatkowych pytań dotyczących cen skonsultuj się ze swoim CSAM lub skontaktuj się z naszym zespołem pomocy technicznej.

Często zadawane pytania

Typowe pytania dotyczące migracji można znaleźć tutaj

Następne kroki

Dowiedz się więcej o usłudze Application Gateway w wersji 2