Migrieren von Azure Application Gateway und Web Application Firewall von V1 zu V2

Microsoft hat am 28. April 2023 die Einstellung des Anwendungsgateways V1 (Standard- und Webanwendungsfirewall) angekündigt. Das Anwendungsgateway V1 wird am 28. April 2026 eingestellt.

In diesem Artikel erfahren Sie, wie Sie Azure Application Gateway und Azure Web Application Firewall mithilfe von Azure PowerShell-Skripts von V1 zu V2 migrieren. Die Migration hat zwei Phasen: Konfigurationsmigration und Datenverkehrsmigration. Sie können das erweiterte Klonenskript (empfohlen) oder das Legacy-Klonskript verwenden, um Ihre V1-Gatewaykonfiguration an ein neues V2-Gateway zu klonen und dann den Clientdatenverkehr mit minimaler Ausfallzeit umzuleiten.

Weitere Informationen zur Einstellung von Application Gateway V1 finden Sie unter Migrieren von Application Gateway V1 zu V2 bis zum 28. April 2026.

Warum zu V2 migrieren?

Anwendungsgateway V2 und Webanwendungsfirewall V2 bieten die folgenden Vorteile gegenüber V1:

• Resilienz: Redundanz von Verfügbarkeitszonen und automatische Skalierung.
• Sicherheit: Azure Key Vault-Integration, verbesserte Funktionen der Webanwendungsfirewall und Bot-Schutz.
• Überwachung. Umfassende Überwachung für CPU, Arbeitsspeicher und Datenträgernutzung. (V1 unterstützt nur CPU.)
• Erkennung und Entschärfung. Erweiterte Erkennung und automatisierte Entschärfung, die Probleme ohne manuelle Eingriffe identifizieren und beheben.
• Neue Features. Veröffentlichung neuer Funktionen nur für V2.

V1-Gateways werden nicht automatisch auf V2 aktualisiert. Verwenden Sie dieses Handbuch, um Ihre Migration zu planen und durchzuführen.

Dieser Artikel konzentriert sich auf die Konfigurationsphase der Migration. Die Migration des Clientdatenverkehrs variiert je nach Umgebung. Dieser Artikel enthält nur allgemeine Empfehlungen für die Datenverkehrsmigration.

Voraussetzungen

• Sie benötigen ein Azure-Konto mit einem aktiven Abonnement. Kostenlos ein Konto erstellen.

• Sie benötigen eine vorhandene Application-Gateway V1-Standard-Bereitstellung.

• Verwenden Sie die neuesten PowerShell-Module, oder Sie können Azure Cloud Shell im Azure-Portal verwenden.

• Wenn Sie PowerShell lokal ausführen, führen Sie Connect-AzAccount aus, um eine Verbindung mit Azure zu erstellen.

• Sie können kein vorhandenes Gateway mit den bereitgestellten AppGWV2Name und AppGWResourceGroupName Parametern in einem V1-Abonnement haben. Diese Bedingung verhindert das Umschreiben vorhandener Ressourcen.

• Sie dürfen während der Migration keine anderen geplanten Vorgänge auf dem V1-Gateway oder irgendwelchen zugehörigen Ressourcen durchführen.

• Wenn Sie eine öffentliche IP-Adresse angeben, stellen Sie sicher, dass sie sich in einem erfolgreichen Zustand befindet. Wenn Sie keine öffentliche IP-Adresse angeben, aber angeben AppGWResourceGroupName, stellen Sie sicher, dass eine öffentliche IP-Ressource mit dem Namen AppGWV2Name-IP in einer Ressourcengruppe mit dem Namen AppGWResourceGroupName im V1-Abonnement nicht vorhanden ist.

• Für V1 sind Authentifizierungszertifikate erforderlich, um TLS-Verbindungen mit Back-End-Servern einzurichten. V2 erfordert das Hochladen vertrauenswürdiger Stammzertifikate für denselben Zweck. Während V1 die Verwendung von selbstsignierten Zertifikaten als Authentifizierungszertifikate zulässt, muss V2 ein selbstsigniertes Stammzertifikat generieren und hochladen , wenn selbstsignierte Zertifikate im Back-End verwendet werden.

• Wenn Sie die Netzwerkisolation für das Abonnement aktivieren, müssen sich alle Application Gateway V2 Bereitstellungen, die entweder nur öffentlich oder nur privat sind, in einem Subnetz befinden, das an Microsoft.Network/applicationGateways delegiert ist. Führen Sie die Schritte zum Einrichten der Subnetzdelegierung aus.

Azure Cloud Shell

Azure hosten Azure Cloud Shell eine interaktive Shellumgebung, die Sie über Ihren Browser verwenden können. Sie können entweder Bash oder PowerShell mit Cloud Shell verwenden, um mit Azure Diensten zu arbeiten. Sie können die Cloud Shell vorinstallierten Befehle verwenden, um den Code in diesem Artikel auszuführen, ohne etwas in Ihrer lokalen Umgebung installieren zu müssen.

So starten Sie Azure Cloud Shell:

Option	Beispiel/Link
Wählen Sie rechts oben in einem Code- oder Befehlsblock die Option Ausprobieren aus. Wenn Sie Try It auswählen, wird der Code oder befehl nicht automatisch in Cloud Shell kopiert.
Wechseln Sie zu https://shell.azure.com, oder wählen Sie die Schaltfläche Launch Cloud Shell aus, um Cloud Shell in Ihrem Browser zu öffnen.
Wählen Sie die Schaltfläche Cloud Shell auf der Menüleiste oben rechts im Portal Azure Portal aus.

So verwenden Sie Azure Cloud Shell:

1. Starten Sie Cloud Shell.

2. Wählen Sie die Schaltfläche Kopieren für einen Codeblock (oder Befehlsblock) aus, um den Code oder Befehl zu kopieren.

3. Fügen Sie den Code oder Befehl in die Cloud Shell Sitzung ein, indem Sie Ctrl+Shift+V auf Windows und Linux auswählen, oder indem Sie Cmd+Shift+V unter macOS auswählen.

4. Wählen Sie Geben Sie ein, um den Code oder Befehl auszuführen.

Konfiguration der Migration

Die Konfigurationsmigration konzentriert sich auf das Einrichten des neuen V2-Gateways mit den Einstellungen aus Ihrer vorhandenen V1-Umgebung. Zwei Azure PowerShell-Skripts erleichtern die Migration von Konfigurationen (Standard- oder Webanwendungsfirewall) von V1 zu V2-Gateways. Diese Skripts helfen, den Übergangsprozess zu optimieren, indem wichtige Bereitstellungs- und Konfigurationsaufgaben automatisiert werden.

Private Bereitstellungen des Application Gateways müssen Subnetzdelegierung konfiguriert haben Microsoft.Network/applicationGateways. Führen Sie die Schritte zum Einrichten der Subnetzdelegierung aus.

Erweitertes Klonenskript (empfohlen)

Das erweiterte Klonskript ist die empfohlene Option. Es bietet eine verbesserte Migrationserfahrung durch:

• Die Notwendigkeit einer manuellen Eingabe von Frontend-SSL-Zertifikaten und vertrauenswürdigen Back-End-Stammzertifikaten wird beseitigt.
• Unterstützung der Bereitstellung von nur privaten V2-Gateways.

Sie können das erweiterte Klonenskript aus dem PowerShell-Katalog herunterladen.

Überlegungen

Wenn die vorhandene Anwendungsgateway-V1-Bereitstellung mit einem nur privaten Frontend konfiguriert ist, müssen Sie das EnableApplicationGatewayNetworkIsolation Feature im Abonnement für die private Bereitstellung registrieren, bevor Sie das Migrationsskript ausführen. Dieser Schritt ist erforderlich, um Bereitstellungsfehler zu vermeiden.

Private Bereitstellungen des Application Gateways müssen Subnetzdelegierung konfiguriert haben Microsoft.Network/applicationGateways. Führen Sie die Schritte zum Einrichten der Subnetzdelegierung aus.

Parameter für das Skript

• AppGw V1 ResourceId -Required. Azure-Ressourcen-ID für Ihr vorhandenes Standard-V1- oder WAF-V1-Gateway. Um diesen Zeichenfolgenwert zu finden, wechseln Sie zum Azure-Portal, wählen Sie Ihre Anwendungsgateway- oder Webanwendungsfirewall-Ressource aus, und wählen Sie dann den Link "Eigenschaften" für das Gateway aus. Die Ressourcen-ID befindet sich in diesem Fensterbereich.

  Sie können auch die folgenden Azure PowerShell-Befehle ausführen, um die Ressourcen-ID abzurufen:

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

• SubnetAddressRange -Required. Subnetzadresse in CIDR-Notation, wo das Anwendungs-Gateway V2 bereitgestellt wird.

• AppGwName -Optional. Name des V2-Anwendungsgateways. Der Standardwert ist {AppGwV1 Name}_migrated.

• AppGwResourceGroupName -Optional. Name der Ressourcengruppe, in der das V2-Anwendungsgateway erstellt wird. Wenn Sie sie nicht bereitstellen, wird die Ressourcengruppe "Application Gateway V1" verwendet.

• PrivateIPAddress -Optional. Private IP-Adresse, die dem Anwendungsgateway V2 zugewiesen werden soll. Wenn Sie sie nicht angeben, wird eine zufällige private IP zugewiesen.

• ValidateBackendHealth -Optional. Validierung nach der Migration durch Vergleich der ApplicationGatewayBackendHealth Antworten. Wenn Sie sie nicht festlegen, wird diese Überprüfung übersprungen.

• PublicIpResourceId -Optional. Ressourcen-ID der öffentlichen IP-Adresse (sofern sie bereits vorhanden ist), die an das Anwendungsgateway angefügt werden soll. Wenn Sie sie nicht angeben, lautet {AppGwName}-IPder öffentliche IP-Name .

• DisableAutoscale -Optional. Option zum Deaktivieren der Autoskalenkonfiguration für Anwendungsgateway-V2-Instanzen. Standardmäßig ist dies false der Standardwert.

• WafPolicyName -Optional. Name der Webanwendungsfirewallrichtlinie, die aus der Konfiguration der Webanwendungsfirewall V1 erstellt und an das Webanwendungsfirewall V2-Gateway angefügt wird.

Schritte zum Ausführen des Skripts

1. Verwenden Sie Connect-AzAccount, um eine Verbindung mit Azure herzustellen.

2. Verwenden Sie Import-Module Az, um die Az-Module zu importieren.

3. Führen Sie das Set-AzContext Cmdlet aus, um den aktiven Azure-Kontext auf das richtige Abonnement festzulegen. Dieser Schritt ist wichtig, da das Migrationsskript möglicherweise die vorhandene Ressourcengruppe bereinigen kann, wenn die Gruppe nicht im aktuellen Abonnementkontext vorhanden ist.

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

4. Installieren Sie das Skript, indem Sie die Schritte zum Installieren des Skripts weiter unten in diesem Artikel ausführen.

5. Führen Sie das Skript mithilfe der entsprechenden Parameter aus. Das Skript kann fünf bis sieben Minuten dauern.

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

   Ein Beispiel:

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

• Überprüfen Sie nach Abschluss des Skripts die V2-Gatewaykonfiguration im Azure-Portal, und testen Sie die Konnektivität, indem Sie den Datenverkehr direkt an die IP des V2-Gateways senden.

• Das Skript entspannt die TLS-Back-End-Überprüfung standardmäßig (keine Zertifikatkette, Ablauf- oder SNI-Überprüfung) während des Klonens. Wenn Sie strengere TLS-Überprüfungs- oder Authentifizierungszertifikate benötigen, können Sie die Anwendungsgateway-V2-Bereitstellung nach der Erstellung aktualisieren, um vertrauenswürdige Stammzertifikate hinzuzufügen und dieses Feature zu aktivieren.

• Für NTLM- und Kerberos-Passthrough legen Sie die dedizierte Backend-Verbindung auf true innerhalb der HTTP-Einstellungen nach dem Klonen fest.

Vorbehalte

• Sie müssen einen IP-Adressraum für ein anderes Subnetz innerhalb des virtuellen Netzwerks bereitstellen, das Ihr V1-Gateway enthält. Mit dem Skript kann das V2-Gateway nicht in einem vorhandenen Subnetz erstellt werden, in dem es bereits ein V1-Gateway gibt. Wenn das Subnetz bereits über ein V2-Gateway verfügt, funktioniert das Skript möglicherweise noch, wenn genügend IP-Adressraum verfügbar ist.

• Wenn Sie über eine Netzwerksicherheitsgruppe (Network Security Group, NSG) oder benutzerdefinierte Routen (UDRs) verfügen, die dem V2-Gateway-Subnetz zugeordnet sind, stellen Sie sicher, dass sie den NSG-Anforderungen und UDR-Anforderungen für eine erfolgreiche Migration entsprechen.

• Haben Sie für Ihr V1-Gateway den FIPS-Modus aktiviert, wird dieser nicht in Ihr neues V2-Gateway migriert.

• Die Webanwendungsfirewall V2 ist standardmäßig für die Verwendung des Kernregelsatzes (Core Rule Set, CRS) 3.0 konfiguriert. Da CRS 3.0 auf dem Weg zur Ausmusterung ist, sollten Sie nach der Migration ein Upgrade auf den neuesten Standardregelsatz (Default Rule Set, DRS) 2.2 durchführen. Weitere Informationen finden Sie unter Webanwendungsfirewall-DRS- und CRS-Regelgruppen und -regeln.

Legacy-Klonenskript

Das Alt-Klonskript unterstützt den Übergang durch:

• Erstellen eines neuen Standard V2- oder Web Application Firewall V2 Application Gateways in einem vom Benutzer angegebenen virtuellen Netzwerk-Subnetz.
• Automatisches Kopieren der Konfiguration von einem vorhandenen Standard- oder Webanwendungsfirewall V1-Gateway in das neu erstellte V2-Gateway.
• Sie müssen TLS/SSL- und Authentifizierungszertifikate als Eingabe bereitstellen. Dieses Skript unterstützt keine privaten V2-Gateways. Sie können dieses Klonskript aus dem PowerShell-Katalog herunterladen.

Parameter für das Skript

Das Legacyskript verwendet die folgenden Parameter:

• resourceId. Dieser erforderliche Parameter ist die Azure-Ressourcen-ID für Ihr vorhandenes Standard-V1- oder Webanwendungsfirewall V1-Gateway. Um diesen Zeichenfolgenwert zu finden, wechseln Sie zum Azure-Portal, wählen Sie Ihre Anwendungsgateway- oder Webanwendungsfirewall-Ressource aus, und wählen Sie den Link "Eigenschaften" für das Gateway aus. Die Ressourcen-ID befindet sich in diesem Fensterbereich.

  Sie können auch die folgenden Azure PowerShell-Befehle ausführen, um die Ressourcen-ID abzurufen:

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

• subnetAddressRange. Dieser erforderliche Zeichenfolgenparameter ist der IP-Adressraum, den Sie für ein neues Subnetz zugewiesen haben (oder zuordnen möchten), das Ihr neues V2-Gateway enthält. Der Adressraum muss in der CIDR-Notation angegeben werden. Ein Beispiel ist 10.0.0.0/24.

  Sie müssen dieses Subnetz nicht im Voraus erstellen, aber der CIDR muss Teil des Adressraums für das virtuelle Netzwerk sein. Das Skript erstellt es für Sie, wenn es nicht vorhanden ist. Wenn es vorhanden ist, verwendet das Skript das vorhandene. Stellen Sie sicher, dass das Subnetz leer ist oder nur das V2-Gateway enthält und über genügend verfügbare IPs verfügt.

• appgwName. Sie geben diese optionale Zeichenkette als Namen für das neue Gateway des Typs Standard V2 oder Web Application Firewall V2 an. Wenn Sie diesen Parameter nicht angeben, wird der Name Ihres vorhandenen V1-Gateways mit dem angefügten Suffix _V2 verwendet.

• AppGWResourceGroupName. Diese optionale Zeichenfolge ist der Name der Ressourcengruppe, in der Anwendungsgateway V2-Ressourcen erstellt werden sollen. Der Standardwert ist <V1-app-gw-rgname>.

  Stellen Sie sicher, dass sich kein vorhandenes Anwendungsgateway mit den bereitgestellten Werten für AppGWV2Name und AppGWResourceGroupName im V1-Abonnement befindet. Dieser Parameter schreibt die vorhandenen Ressourcen neu.

• sslCertificates. Dieser Parameter stellt eine durch Trennzeichen getrennte Liste von PSApplicationGatewaySslCertificate Objekten bereit, die Sie erstellen, um die TLS/SSL-Zertifikate von Ihrem V1-Gateway darzustellen, die in das neue V2-Gateway hochgeladen werden müssen.

  Für jedes Ihrer TLS/SSL-Zertifikate, das für Ihr Standard-V1- oder Webanwendungs-Firewall-V1-Gateway konfiguriert ist, können Sie über den PSApplicationGatewaySslCertificate Befehl im folgenden Code ein neues New-AzApplicationGatewaySslCertificate Objekt erstellen. Sie benötigen den Pfad zu Ihrer TLS/SSL-Zertifikatdatei und das Kennwort.

  Dieser Parameter ist nur optional, wenn Sie keine HTTPS-Listener für Ihr V1-Gateway oder für die Webanwendungsfirewall konfiguriert haben. Wenn Sie mindestens einen HTTPS-Listener eingerichtet haben, müssen Sie diesen Parameter angeben.

       $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
  

  Sie können $mySslCert1, $mySslCert2 (durch Komma getrennt) aus dem vorherigen Beispiel als Werte für diesen Parameter im Skript übergeben.

• sslCertificates. Sie verwenden diesen optionalen Parameter, um die in Azure Key Vault gespeicherten Zertifikate herunterzuladen und an das Migrationsskript zu übergeben. Führen Sie den folgenden Befehl aus, um das Zertifikat als PFX-Datei herunterzuladen. Diese Befehle greifen auf den Inhalt zu SecretId und speichern sie dann als PFX-Datei.

      $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)
  

  Für jedes von Key Vault heruntergeladene Zertifikat können Sie ein neues PSApplicationGatewaySslCertificate Objekt über den New-AzApplicationGatewaySslCertificate befehl im folgenden Code erstellen. Sie benötigen den Pfad zu Ihrer TLS/SSL-Zertifikatdatei und das Kennwort.

  //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. Verwenden Sie diesen optionalen Parameter, um eine durch Trennzeichen getrennte Liste von PSApplicationGatewayTrustedRootCertificate Objekten zu erstellen, um die vertrauenswürdigen Stammzertifikate für die Authentifizierung Ihrer Back-End-Instanzen von Ihrem V2-Gateway darzustellen.

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

  Informationen zum Erstellen einer Liste von PSApplicationGatewayTrustedRootCertificate Objekten finden Sie unter New-AzApplicationGatewayTrustedRootCertificate.

• privateIpAddress. Verwenden Sie diese optionale Zeichenfolge, um eine bestimmte private IP-Adresse anzugeben, die Sie Ihrem neuen V2-Gateway zuordnen möchten. Es muss aus dem gleichen virtuellen Netzwerk stammen, das Sie für Ihr neues V2-Gateway zuweisen. Wenn Sie diesen Parameter nicht angeben, weist das Skript eine private IP-Adresse für Ihr V2-Gateway zu.

• publicIpResourceId. Verwenden Sie diese optionale Zeichenfolge, um die Ressourcen-ID einer vorhandenen öffentlichen IP-Adresse (Standardebene) in Ihrem Abonnement bereitzustellen, die Sie dem neuen V2-Gateway zuordnen möchten. Wenn Sie den öffentlichen IP-Ressourcennamen angeben, stellen Sie sicher, dass er in einem erfolgreichen Status vorhanden ist.

  Wenn Sie diesen Parameter nicht angeben, weist das Skript eine neue öffentliche IP-Adresse in derselben Ressourcengruppe zu. Der Name ist der Name des V2-Gateways mit angefügtem -IP. Wenn Sie ohne Angabe einer öffentlichen IP-Adresse angeben AppGWResourceGroupName , stellen Sie sicher, dass eine öffentliche IP-Ressource mit dem Namen AppGWV2Name-IP in einer Ressourcengruppe mit dem Namen AppGWResourceGroupName im V1-Abonnement nicht vorhanden ist.

• validateMigration. Verwenden Sie diesen optionalen Schalterparameter, damit das Skript nach der Erstellung des V2-Gateways und dem Kopieren der Konfiguration einige grundlegende Überprüfungen zum Konfigurationsvergleich durchführen kann. Standardmäßig erfolgt keine Prüfung.

• enableAutoScale. Verwenden Sie diesen optionalen Switch-Parameter, um das Skript zu aktivieren, um die automatische Skalierung auf dem neuen V2-Gateway zu aktivieren, nachdem es erstellt wurde. Standardmäßig ist automatische Skalierung deaktiviert. Sie können automatische Skalierung später für das neu erstellte V2-Gateway jederzeit manuell aktivieren.

Schritte zum Ausführen des Skripts

1. Verwenden Sie Connect-AzAccount, um eine Verbindung mit Azure herzustellen.

2. Verwenden Sie Import-Module Az, um die Az-Module zu importieren.

3. Führen Sie das Set-AzContext Cmdlet aus, um den aktiven Azure-Kontext auf das richtige Abonnement festzulegen. Dieser Schritt ist wichtig, da das Migrationsskript möglicherweise die vorhandene Ressourcengruppe bereinigt, sofern sie im aktuellen Abonnementkontext nicht vorhanden ist.

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

4. Installieren Sie das Skript, indem Sie die Schritte zum Installieren des Skripts weiter unten in diesem Artikel ausführen.

5. Führen Sie die Ausführung Get-Help AzureAppGWMigration.ps1 aus, um die erforderlichen Parameter zu untersuchen.

6. Führen Sie das Skript mithilfe der entsprechenden Parameter aus. Das Skript kann fünf bis sieben Minuten dauern.

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

   Ein Beispiel:

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

Vorbehalte und Einschränkungen

• Das neue V2-Gateway hat neue öffentliche und private IP-Adressen. Sie können die ip-Adressen, die dem vorhandenen V1-Gateway zugeordnet sind, nicht nahtlos auf V2 verschieben. Sie können dem neuen V2-Gateway jedoch eine vorhandene (nicht zugeordnete) öffentliche oder private IP-Adresse zuordnen.

• Sie müssen einen IP-Adressraum für ein anderes Subnetz in Ihrem virtuellen Netzwerk bereitstellen, das Ihr V1-Gateway enthält. Mit dem Skript kann das V2-Gateway nicht in einem vorhandenen Subnetz erstellt werden, in dem es bereits ein V1-Gateway gibt. Wenn das Subnetz bereits über ein V2-Gateway verfügt, funktioniert das Skript möglicherweise noch, wenn genügend IP-Adressraum verfügbar ist.

• Wenn Sie über eine NSG- oder UDRs verfügen, die dem V2-Gateway-Subnetz zugeordnet sind, stellen Sie sicher, dass sie den NSG-Anforderungen und UDR-Anforderungen für eine erfolgreiche Migration entsprechen.

• Richtlinien für VNET-Dienstendpunkte werden derzeit in einem Application Gateway-Subnetz nicht unterstützt.

• Um eine TLS/SSL-Konfiguration zu migrieren, müssen Sie alle TLS/SSL-Zertifikate angeben, die in Ihrem V1-Gateway verwendet werden.

• Haben Sie für Ihr V1-Gateway den FIPS-Modus aktiviert, wird dieser nicht in Ihr neues V2-Gateway migriert.

• Die Instanz der Webanwendungsfirewall V2 wird im alten Konfigurationsmodus der Webanwendungsfirewall erstellt. Die Migration zur Webanwendungsfirewall-Richtlinie ist erforderlich.

• Die Webanwendungsfirewall V2 ist standardmäßig für die Verwendung von CRS 3.0 konfiguriert. Da CRS 3.0 bald nicht mehr unterstützt wird, sollten Sie nach der Migration auf den neuesten Regelsatz (DRS 2.2) aktualisieren. Weitere Informationen finden Sie unter CRS- und DRS-Regelgruppen und -regeln.

Installieren des Skripts

Je nach Einrichtung und Einstellung ihrer lokalen PowerShell-Umgebung haben Sie zwei Optionen:

• Wenn Sie die Azure Az-Module nicht installiert haben, oder Sie nicht daran denken, die Azure Az-Module zu deinstallieren, besteht die beste Option darin, die Install-Script Option zum Ausführen des Skripts zu verwenden.
• Wenn Sie die Azure Az-Module beibehalten müssen, laden Sie das Skript herunter, und führen Sie es direkt aus.

Um festzustellen, ob die Azure Az-Module installiert sind, führen Sie Get-InstalledModule -Name az aus. Wenn keine installierten Az-Module angezeigt werden, können Sie die Install-Script Methode verwenden.

Installieren mithilfe der Install-Script-Methode (empfohlen)

Um diese Option zu verwenden, dürfen sie nicht die Azure Az-Module auf Ihrem Computer installiert haben. Wenn diese installiert sind, zeigt der folgende Befehl einen Fehler an. Sie können entweder die Azure Az-Module deinstallieren oder die andere Option verwenden, um das Skript manuell herunterzuladen und auszuführen.

Führen Sie das Skript mit einem der folgenden Befehle aus, um die neueste Version zu erhalten:

• Verwenden Sie Install-Script -Name AzureAppGWIPMigrate -Forcefür das erweiterte Klonenskript mit öffentlicher IP-Aufbewahrung .
• Verwenden Sie Install-Script -Name AzureAppGWClone -Forcefür das erweiterte Klonenskript .
• Verwenden Sie Install-Script -Name AzureAppGWMigration -Force für das Legacy-Klonenskript.

Der Befehl installiert auch die erforderlichen Az-Module.

Installieren mithilfe des Skripts direkt

Wenn Sie einige Azure Az-Module installiert haben und sie nicht deinstallieren können (oder sie nicht deinstallieren möchten), können Sie das Skript manuell herunterladen, indem Sie die Registerkarte "Manueller Download " im Link zum Herunterladen des Skripts verwenden.

Das Skript wird als unformatierte nupkg-Datei heruntergeladen. Informationen zum Installieren des Skripts aus dieser nupkg-Datei finden Sie unter "Manuelles Paketdownload".

Für das Legacy-Klonskript ist Version 1.0.11 die neue Version des Migrationsskripts. Es enthält wichtige Fehlerkorrekturen. Stellen Sie sicher, dass Sie die neueste stabile Version aus dem PowerShell-Katalog verwenden.

Überprüfen der Version des heruntergeladenen Skripts

1. Entpacken Sie den Inhalt des NuGet-Pakets.

2. Öffnen Sie die .PS1 Datei im Ordner, und überprüfen Sie den .VERSION Wert, um die Version des heruntergeladenen Skripts zu bestätigen.

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

Datenverkehrsmigration

Voraussetzungen

• Überprüfen Sie im Azure-Portal, ob das Skript erfolgreich ein neues V2-Gateway mit der genauen Konfiguration erstellt hat, die von Ihrem V1-Gateway migriert wurde.
• Senden Sie einen kleinen Datenverkehr über das V2-Gateway als manuellen Test.

Öffentliches IP-Aufbewahrungsskript

Nachdem Sie die Konfiguration erfolgreich migriert und Ihr neues V2-Gateway gründlich getestet haben, konzentriert sich dieser Schritt auf die Umleitung von Livedatenverkehr.

• Das Skript reserviert die öffentliche Standard-IP von V1, konvertiert sie in Standard und fügt sie an das V2-Gateway an. Diese Aktion leitet effektiv den gesamten eingehenden Datenverkehr an das V2-Gateway um.
• Dieser IP-Swap-Vorgang führt in der Regel zu einer kurzen Ausfallzeit von etwa 1 bis fünf Minuten. Planen Sie entsprechend.
• Nachdem ein erfolgreiches Skript ausgeführt wurde, wird die öffentliche IP von Application Gateway V1 zu Application Gateway V2 verschoben. Das Anwendungsgateway V1 empfängt eine neue öffentliche IP.
• Versuchen Sie während der IP-Migration keinen anderen Vorgang auf den V1- und V2-Gateways oder den zugehörigen Ressourcen.
• Der öffentliche IP-Swap, den dieses Skript ausführt, ist unumkehrbar. Nach dem Initiieren können Sie die IP nicht mithilfe des Skripts auf das V1-Gateway zurücksetzen.

Sie können dieses öffentliche IP-Aufbewahrungsskript aus dem PowerShell-Katalog herunterladen.

Parameter für das Skript

Für dieses Skript sind die folgenden obligatorischen Parameter erforderlich:

• v1resourceId. Die Ressourcen-ID des V1-Gateways, dessen öffentliche IP reserviert und V2 zugeordnet wird.
• v2resourceId. Die Ressourcen-ID des V2-Gateways, dem die öffentliche V1-IP zugewiesen wird. Sie können das V2-Gateway manuell oder mithilfe eines der Klonskripts erstellen.

Nachdem Sie das Skript heruntergeladen und installiert haben, führen Sie es mit den erforderlichen Parametern aus.

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

Ein Beispiel:

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

Überprüfen Sie nach Abschluss des IP-Swaps die Steuerungsebenen- und Datenebenenvorgänge auf dem V2-Gateway. Alle Aktionen auf der Steuerebene mit Ausnahme des Löschens sind auf dem V1-Gateway deaktiviert.

Empfehlungen für die Verkehrsmigration

Die folgenden Punkte sind einige Szenarien, in denen Ihr aktuelles Anwendungsgateway (Standard) Datenverkehr von Clients empfangen kann, und unsere Empfehlungen dazu:

• Eine benutzerdefinierte DNS-Zone (z. B. contoso.com) verweist auf die Front-End-IP-Adresse (mithilfe eines A-Eintrags), der Ihrem Standard-V1- oder Webanwendungsfirewall V1-Gateway zugeordnet ist.

  Sie können Ihren DNS-Eintrag so aktualisieren, dass er auf die Front-End-IP- oder DNS-Bezeichnung verweist, die Ihrem Standard V2-Anwendungsgateway zugeordnet ist. Je nach der Konfiguration der Time-to-Live (TTL) für Ihren DNS-Eintrag kann es eine Weile dauern, bis der gesamte Clientdatenverkehr zu Ihrem neuen V2-Gateway migriert wird.

• Eine benutzerdefinierte DNS-Zone (z. B. contoso.com) verweist auf die DNS-Bezeichnung (z. B. myappgw.eastus.cloudapp.azure.com mithilfe eines CNAME-Eintrags), der Ihrem V1-Gateway zugeordnet ist.

  Sie haben zwei Möglichkeiten:

  • Wenn Sie öffentliche IP-Adressen auf Ihrem Anwendungsgateway verwenden, können Sie eine kontrollierte, präzise Migration mithilfe eines Azure Traffic Manager-Profils durchführen, um den Datenverkehr inkrementell an das neue V2-Gateway weiterzuleiten.

    Sie können diese gewichtete Datenverkehrsroutingmethode verwenden, indem Sie die DNS-Bezeichnungen sowohl des V1- als auch des V2-Anwendungsgateways zum Traffic Manager-Profil hinzufügen. Wenden Sie dann CNAME auf Ihren benutzerdefinierten DNS-Eintrag (z. B www.contoso.com. ) auf die Traffic Manager-Domäne an (z. B contoso.trafficmanager.net. ).

  • Sie können Ihren benutzerdefinierten DNS-Eintrag aktualisieren, um auf die DNS-Bezeichnung des neuen V2-Anwendungsgateways zu verweisen. Je nachdem, welche TTL für Ihren DNS-Eintrag konfiguriert wurde, kann es eine Weile dauern, bis der gesamte Clientdatenverkehr zu Ihrem neuen V2-Gateway migriert wird.

• Ihre Client stellen Verbindungen mit der Front-End-IP-Adresse Ihres Anwendungsgateways her.

  Aktualisieren Sie Ihre Clients, um die IP-Adresse zu verwenden, die dem neu erstellten V2-Anwendungsgateway zugeordnet ist. Es empfiehlt sich, dass Sie IP-Adressen nicht direkt verwenden. Erwägen Sie die Verwendung des DNS-Namensetiketts (z.B. yourgateway.eastus.cloudapp.azure.com), das Ihrem Anwendungsgateway zugeordnet ist, und das Sie über ein CNAME (z.B. contoso.com) in Ihrer eigenen benutzerdefinierten DNS-Zone anwenden können.

Aufgaben nach der Migration

Nachdem die Datenverkehrsmigration erfolgreich war und Sie vollständig überprüfen, ob die Anwendung ordnungsgemäß über das V2-Gateway ausgeführt wird, können Sie die alte Anwendungsgateway-V1-Ressource sicher außer Betrieb setzen und löschen, um unnötige Kosten zu vermeiden.

Preisinformationen

Die Preismodelle unterscheiden sich für Application Gateway V1 und V2. V2 wird basierend auf dem Verbrauch berechnet. Preisinformationen finden Sie unter Application Gateway-Preise vor der Migration.

Leitfaden zur Kosteneffizienz

Anwendungsgateway V2 bietet eine Reihe von Vorteilen, z. B.:

• Eine Leistungsverstärkung von 5x.
• Verbesserte Sicherheit durch Key Vault-Integration.
• Schnellere Updates von Sicherheitsregeln in der Webanwendungsfirewall V2.
• Benutzerdefinierte Regeln für die Webanwendungsfirewall.
• Richtlinienzuordnungen.
• Bot-Schutz.

Das Anwendungsgateway V2 bietet auch eine hohe Skalierbarkeit, optimiertes Datenverkehrsrouting und nahtlose Integration in Azure-Dienste. Diese Features können die allgemeine Benutzererfahrung verbessern, Verlangsamungen während schwerer Datenverkehrszeiten verhindern und Ihnen dabei helfen, teure Datenschutzverletzungen zu vermeiden.

Fünf Varianten sind in V1 verfügbar, basierend auf Ebene und Größe: Standard Small, Standard Medium, Standard Large, Web-Application-Firewall Medium und Web-Application-Firewall Large. Preisinformationen gemäß Ihrer Region finden Sie auf der Preisseite.

Die Szenarien in der folgenden Tabelle sind nur Beispiele für Veranschaulichungszwecke. Die Berechnungen basieren auf Ost-USA und für ein Gateway mit zwei Instanzen in V1. Die variablen Kosten in V2 basieren auf einer der drei Dimensionen mit der höchsten Nutzung: neue Verbindungen (50 pro Sekunde), persistente Verbindungen (2.500 pro Minute) und Durchsatz (2,22 Mbps pro Kapazitätseinheit).

Bei weiteren Fragen oder Bedenken bezüglich der Preise arbeiten Sie bitte mit Ihrem Customer Success Manager (CSAM) zusammen oder wenden Sie sich an unser Supportteam.

Häufig gestellte Fragen

Antworten auf häufig gestellte Fragen zur Migration finden Sie unter Häufig gestellte Fragen zur Einstellung des Anwendungsgateways V1.

Verwandte Inhalte

• Informationen zu Application Gateway V2