ترحيل بوابة تطبيق Azure وجدار حماية تطبيق الويب من V1 إلى V2

أعلنا عن إيقاف Application Gateway V1 SKU (Standard و WAF) في 28 أبريل 2023. يتوقف V1 SKU في 28 أبريل 2026. لمزيد من المعلومات، راجع ترحيل Application Gateways من V1 SKU إلى V2 SKU بحلول 28 أبريل 2026.

يوفر الترحيل إلى Azure Application Gateway وجدار حماية تطبيق الويب (WAF) V2 العديد من الفوائد:

مرونة أفضل: التكرار من الألف إلى الياء ، مقياس تلقائي
أمان أفضل: تكامل Azure Keyvault، وقدرات WAF المحسنة، وحماية الروبوت
قدرات مراقبة محسنة: على عكس V1 ، الذي كان يحتوي فقط على مراقبة وحدة المعالجة المركزية ، يوفر V2 مراقبة شاملة لاستخدام وحدة المعالجة المركزية والذاكرة والقرص.
تحسين الاكتشاف والتخفيف التلقائي: تتميز بوابات V2 بآليات كشف متقدمة وعمليات تخفيف مؤتمتة يمكنها تحديد المشكلات وحلها بسرعة ودقة دون الحاجة إلى تدخل يدوي.
تم إصدار جميع الميزات الجديدة ل V2 SKU.

يوصى بشدة بإنشاء خطة ترحيل الآن. لا تتم ترقية بوابات V1 تلقائيا إلى V2. استخدم دليل الترحيل هذا لمساعدتك في تخطيط عمليات الترحيل وتنفيذها.

هناك مرحلتان في الترحيل:

ترحيل التكوين
ترحيل نسبة استخدام شبكة العميل

تساعد هذه المقالة بشكل أساسي في ترحيل التكوين. يختلف ترحيل نسبة استخدام الشبكة للعميل اعتمادا على البيئة. يتم تقديم بعض التوصيات العامة في هذه المقالة.

المتطلبات الأساسية

حساب Azure مع اشتراك نشط. أنشئ حساباً مجاناً.
Application Gateway V1 Standard موجود.
تأكد من أن لديك أحدث وحدات Azure CLI النمطية، أو يمكنك استخدام Azure Cloud Shell في المدخل.
في حالة تشغيل PowerShell محليًا، فأنت بحاجة أيضًا إلى تشغيل Connect-AzAccount لإنشاء اتصال مع Azure.
تأكد من عدم وجود بوابة تطبيق مع اسم AppGW V2 المتوفر واسم مجموعة الموارد في اشتراك V1. يؤدي هذا إلى إعادة كتابة الموارد الموجودة.
إذا تم توفير عنوان IP عام، فتأكد من أنه في حالة ناجحة. إذا لم يتم توفيره وتم توفير AppGWResourceGroupName، فتأكد من عدم وجود مورد IP العام الذي يحمل الاسم AppGWV2Name-IP في مجموعة موارد تحمل الاسم AppGWResourceGroupName في اشتراك V1.
بالنسبة إلى V1 SKU، يلزم شهادات المصادقة لإعداد اتصالات TLS مع خوادم الواجهة الخلفية. يتطلب V2 SKU تحميل شهادات الجذر الموثوق بها لنفس الغرض. بينما يسمح الإصدار 1 باستخدام الشهادات الموقعة ذاتيا كشهادات مصادقة، فإن V2 يفرض إنشاء وتحميل شهادة جذر موقعة ذاتيا إذا تم استخدام الشهادات الموقعة ذاتيا في الخلفية.
تأكد من عدم التخطيط لأي عملية أخرى على بوابة V1 أو أي موارد مقترنة أثناء الترحيل.

Azure Cloud Shell

Azure يستضيف Azure Cloud Shell، بيئة تفاعلية يمكن استخدامها من خلال المستعرض. يمكنك استخدام Bash أو PowerShell مع Cloud Shell للعمل مع خدمات Azure. يمكنك استخدام أوامر Cloud Shell المثبتة مسبقًا لتشغيل التعليمات البرمجية في هذه المقالة دون الحاجة إلى تثبيت أي شيء على البيئة المحلية.

لبدء Azure Cloud Shell:

خيار	مثال/ رابط
انقر فوق ⁧⁩جربه⁧⁩ في الزاوية العلوية اليسرى من التعليمة البرمجية أو كتلة الأمر. تحديد ⁧⁩جربه⁧⁩ لا يقوم بنسخ التعليمة البرمجية أو الأمر تلقائيًا إلى Cloud Shell.
انتقل إلى ⁧⁩⁧ https://shell.azure.com⁩⁧⁩، أو حدد زر ⁩تشغيل Cloud Shell لفتح Cloud Shell في المتصفح لديك.
حدد زر Cloud Shell على شريط القوائم في أعلى اليمين في مدخل Microsoft Azure.

لاستخدام Azure Cloud Shell:

ابدأ تشغيل Cloud Shell.
حدد الزر نسخ على كتلة التعليمات البرمجية (أو كتلة الأوامر) لنسخ التعليمات البرمجية أو الأمر.
ألصق التعليمة البرمجية أو الأمر في جلسة Cloud Shell بتحديد Ctrl+Shift+Vعلى Windows وLunix، أو بتحديد Cmd+Shift+Vعلى macOS.
حدد Enter لتشغيل التعليمات البرمجية أو الأمر.

إشعار

نوصي باستخدام الوحدة النمطية Azure Az PowerShell للتفاعل مع Azure. للبدء، راجع تثبيت Azure PowerShell. لمعرفة كيفية الترحيل إلى الوحدة النمطية Az PowerShell، راجع ترحيل Azure PowerShell من AzureRM إلى Az.

ترحيل التكوين

يركز ترحيل التكوين على إعداد بوابة V2 الجديدة مع الإعدادات من بيئة V1 الحالية. نحن نقدم برنامجين نصيين ل Azure PowerShell مصممين لتسهيل ترحيل التكوينات من بوابات V1 (قياسي أو WAF) إلى بوابات V2 (Standard_V2 أو WAF_V2). تساعد هذه البرامج النصية في تبسيط عملية الانتقال من خلال أتمتة مهام النشر والتكوين للمفاتيح.

1. برنامج نصي استنساخ محسن

هذه هي التجربة الجديدة التي توفر تجربة ترحيل محسنة من خلال:

التخلص من الحاجة إلى الإدخال اليدوي لشهادات SSL للواجهة الأمامية وشهادات الجذر الموثوق بها للواجهة الخلفية.
دعم نشر بوابات V2 الخاصة فقط.

إشعار

إذا كانت بوابة التطبيقات V1 الحالية مهيأة بواجهة أمامية خاصة فقط، يجب عليك تسجيل ميزة EnableApplicationGatewayNetworkIsolation في الاشتراك الخاص بالنشر الخاص قبل تشغيل سكريبت الترحيل. هذه الخطوة مطلوبة لتجنب فشل النشر.

إشعار

يجب أن يكون تفويض الشبكة الفرعية في عمليات نشر بوابات التطبيقات الخاصة مهيأة إلى Microsoft.Network/applicationGateways. استخدم الخطوات التالية لإعداد تفويض الشبكة الفرعية.

يمكنك تنزيل البرنامج النصي للاستنساخ المحسن من معرض PowerShell.

معلمات البرنامج النصي: يأخذ هذا البرنامج النصي المعلمات التالية:

معرف المورد AppGw V1 -مطلوب: هذه المعلمة هي معرف مورد Azure لبوابة Standard V1 أو WAF V1 الحالية. للبحث عن قيمة السلسلة هذه، انتقل إلى مدخل Azure، وحدد بوابة التطبيق أو مورد WAF، وانقر فوق الارتباط خصائص للبوابة. معرف المورد موجود على تلك الصفحة. يمكنك أيضا تشغيل أوامر Azure PowerShell التالية للحصول على معرف المورد:
```
$appgw = Get-AzApplicationGateway -Name <V1 gateway name> -ResourceGroupName <resource group Name>
$appgw.Id
```
SubnetAddressRange -Required: عنوان الشبكة الفرعية في تدوين CIDR، حيث سيتم نشر Application Gateway V2
AppGwName -اختياري: اسم بوابة تطبيق v2. القيمة الافتراضية = {اسم AppGwV1}_migrated
AppGwResourceGroupName -اختياري: اسم مجموعة الموارد حيث سيتم إنشاء بوابة تطبيق V2. إذا لم يتم توفيرها، استخدام مجموعة موارد Application Gateway V1.
PrivateIPAddress -اختياري: عنوان IP الخاص المراد تعيينه إلى Application Gateway V2. إذا لم يتم توفيره، تعيين عنوان IP خاص عشوائي.
ValidateBackendHealth -اختياري: التحقق من صحة ما بعد الترحيل من خلال مقارنة استجابة ApplicationGatewayBackendHealth. إذا لم يتم تعيينه، تخطي هذا التحقق من الصحة.
PublicIpResourceId -اختياري: يمكن إرفاق عنوان IP العام resourceId (إذا كان موجودا بالفعل) ببوابة التطبيق. إذا لم يتم توفيره، فسيكون اسم IP العام {AppGwName}-IP.
DisableAutoscale -اختياري: تعطيل تكوين التحجيم التلقائي لمثيلات Application Gateway V2، false بشكل افتراضي
WafPolicyName -اختياري: اسم نهج WAF الذي سيتم إنشاؤه من تكوين WAF V1 وسيتم إرفاقه ببوابة WAF v2.

كيفية تشغيل البرنامج النصي

لتشغيل البرنامج النصي:

استخدم Connect-AzAccount للاتصال بـ Azure.
استخدم Import-Module Az لاستيراد الوحدات النمطية لـ Az.
Set-AzContext قم بتشغيل cmdlet، لتعيين سياق Azure النشط إلى الاشتراك الصحيح. هذه خطوة مهمة لأن البرنامج النصي للترحيل قد يقوم بتنظيف مجموعة الموارد الموجودة إذا لم تكن موجودة في سياق الاشتراك الحالي.
```
Set-AzContext -Subscription '<V1 application gateway SubscriptionId>'
```
قم بتثبيت البرنامج النصي باتباع الخطوات-تثبيت البرنامج النصي

قم بتشغيل البرنامج النصي باستخدام المعلمات المناسبة. قد يستغرق الأمر من خمس إلى سبع دقائق للانتهاء.

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

التوصيات

بعد اكتمال البرنامج النصي، راجع تكوين بوابة V2 في مدخل Microsoft Azure واختبر الاتصال عن طريق إرسال نسبة استخدام الشبكة مباشرة إلى عنوان IP لبوابة V2.
يعمل البرنامج النصي على تخفيف التحقق من صحة TLS للواجهة الخلفية افتراضيا (لا توجد سلسلة شهادات أو انتهاء صلاحية أو تحقق من صحة SNI) أثناء الاستنساخ. إذا كانت شهادات التحقق من صحة TLS أو المصادقة أكثر صرامة، فيمكن للعميل تحديث إنشاء لاحق Application Gateway V2 لإضافة شهادات جذر موثوق بها وتمكين هذه الميزة وفقا لمتطلباتهم.
لتمرير NTLM/Kerberos، قم بتعيين اتصال الواجهة الخلفية المخصص إلى "true" في إعدادات HTTP بعد الاستنساخ.

تحذيرات

يجب توفير مساحة عنوان IP لشبكة فرعية أخرى داخل شبكتك الظاهرية حيث توجد بوابة V1. لا يمكن للبرنامج النصي إنشاء بوابة V2 في شبكة فرعية تحتوي بالفعل على بوابة V1. إذا كانت الشبكة الفرعية تحتوي بالفعل على بوابة V2، فقد لا يزال البرنامج النصي يعمل، شريطة توفر مساحة عنوان IP كافية.
إذا كانت لديك مجموعة أمان شبكة أو مسارات معرفة من قبل المستخدم مرتبطة بالشبكة الفرعية لبوابة V2، فتأكد من التزامها بمتطلبات NSG ومتطلباتUDR للترحيل الناجح
إذا كان لديك وضع FIPS ممكنا لبوابة V1، فلن يتم ترحيله إلى بوابة V2 الجديدة.
تم تكوين WAFV2 الجديد لاستخدام CRS 3.0 بشكل افتراضي. ومع ذلك، نظرا لأن CRS 3.0 على المسار إلى الإهمال، نوصي بالترقية إلى أحدث مجموعة قواعد، DRS 2.1 بعد الترحيل. لمزيد من التفاصيل، ارجع إلى مجموعات قواعد CRS وDRS والقواعد التي تحتوي على مجموعة أمان شبكة أو مسارات محددة من قبل المستخدم مقترنة بالشبكة الفرعية لبوابة V2، تأكد من التزامها بمتطلبات NSG ومتطلبات UDR للترحيل الناجح.

إشعار

أثناء الترحيل، لا تحاول أي عملية أخرى على بوابة V1 أو أي موارد مقترنة.

2. نص الاستنساخ القديم

هذا هو نص الاستنساخ الأقدم ، والذي يسهل الانتقال من خلال:

إنشاء Standard_V2 جديد أو بوابة تطبيق WAF_V2 في شبكة فرعية للشبكة الظاهرية المحددة من قبل المستخدم.
نسخ التكوين تلقائيا من بوابة قياسية أو WAF V1 موجودة إلى بوابة V2 التي تم إنشاؤها حديثا.
يتطلب من العميل توفير شهادات SSL والمصادقة كإدخال ولا يدعم بوابات V2 الخاصة فقط يمكنك تنزيل البرنامج النصي للاستنساخ هذا من معرض PowerShell

معلمات البرنامج النصي: يأخذ البرنامج النصي القديم المعلمات التالية:

resourceId: [String]: مطلوب: هذه المعلمة هي معرف مورد Azure لبوابة الإصدار 1 القياسي أو WAF V1 الموجودة. للبحث عن قيمة السلسلة هذه، انتقل إلى مدخل Azure، وحدد بوابة التطبيق أو مورد WAF، وانقر فوق الارتباط خصائص للبوابة. معرف المورد موجود على تلك الصفحة. يمكنك أيضا تشغيل أوامر Azure PowerShell التالية للحصول على معرف المورد:
```
$appgw = Get-AzApplicationGateway -Name <V1 gateway name> -ResourceGroupName <resource group Name>
$appgw.Id
```
subnetAddressRange: [String]: مطلوبة: هذه المعلمة هي مساحة عنوان IP التي قمت بتخصيصها (أو تريد تخصيصها) لشبكة فرعية جديدة تحتوي على بوابة V2 الجديدة. يجب تحديد مساحة العنوان في رمز CIDR. على سبيل المثال: 10.0.0.0/24. لا تحتاج إلى إنشاء هذه الشبكة الفرعية مقدماً ولكن يجب أن تكون CIDR جزءاً من مساحة عنوان VNET. يقوم البرنامج النصي بإنشائه لك إذا لم يكن موجودا وإذا كان موجودا، فإنه يستخدم الشبكة الموجودة (تأكد من أن الشبكة الفرعية إما فارغة، وتحتوي على بوابة V2 فقط إن وجدت، وتحتوي على ما يكفي من عناوين IP المتوفرة).
appgwName: [سلسلة]: اختياري. هذه سلسلة تحددها لاستخدامها كاسم لبوابة Standard_V2 أو WAF_V2 الجديدة. إذا لم يتم توفير هذه المعلمة، يتم استخدام اسم بوابة V1 الموجودة مع اللاحقة _V2 إلحاقها.
AppGWResourceGroupName: [String]: اختياري. اسم مجموعة الموارد حيث تريد إنشاء موارد بوابة تطبيق V2 (القيمة الافتراضية هي <V1-app-gw-rgname>)

إشعار

تأكد من عدم وجود بوابة تطبيق مع اسم AppGW V2 المتوفر واسم مجموعة الموارد في اشتراك V1. يؤدي هذا إلى إعادة كتابة الموارد الموجودة.

sslCertificates: [PSApplicationGatewaySslCertificate]: اختياري. يجب تحميل قائمة مفصولة بفواصل من كائنات PSApplicationGatewaySslCertificate التي تقوم بإنشائها لتمثيل شهادات TLS/SSL من بوابة V1 إلى بوابة V2 الجديدة. لكل من شهادات TLS/SSL المكونة لبوابة الإصدار 1 القياسي أو WAF V1، يمكنك إنشاء كائن PSApplicationGatewaySslCertificate جديد عبر الأمر الموضح New-AzApplicationGatewaySslCertificate هنا. تحتاج المسار إلى ملف شهادات TLS/SSL وكلمة المرور.

هذه المعلمة اختيارية فقط إذا لم يكن لديك مستمعات HTTPS مكونة لبوابة V1 أو WAF. إذا كان لديك إعداد وحدة إصغاء HTTPS واحد على الأقل، يجب تحديد هذه المعلمة.
```
     $password = ConvertTo-SecureString <cert-password> -AsPlainText -Force
     $mySslCert1 = New-AzApplicationGatewaySslCertificate -Name "Cert01" `
    -CertificateFile <Cert-File-Path-1> `
     Password $password
     $mySslCert2 = New-AzApplicationGatewaySslCertificate -Name "Cert02" `
    -CertificateFile <Cert-File-Path-2> `
    -Password $password
```
يمكنك التمرير في $mySslCert1, $mySslCert2 (مفصولة بفاصلة) في المثال السابق كقيم لهذه المعلمة في البرنامج النصي.

sslCertificates من Keyvault: اختياري. يمكنك تنزيل الشهادات المخزنة في Azure Key Vault وتمريرها إلى برنامج الترحيل النصي. لتحميل الشهادة كملف PFX، قم بتشغيل الأمر التالي. تصل هذه الأوامر إلى SecretId، ثم قم بحفظ المحتوى كملف PFX.

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

لكل شهادة تم تنزيلها من Keyvault، يمكنك إنشاء كائن PSApplicationGatewaySslCertificate جديد عبر الأمر New-AzApplicationGatewaySslCertificate الموضح هنا. تحتاج المسار إلى ملف شهادات TLS/SSL وكلمة المرور.

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

trustedRootCertificates: [PSApplicationGatewayTrustedRootCertificate]: اختياري. قائمة مفصولة بفاصلة لكائنات PSApplicationGatewayTrustedRootCertificate التي تقوم بإنشائها لتمثيل شهادات الجذر الموثوق به للمصادقة على مثيلات الخلفية لبوابة الإصدار 2.
```
$certFilePath = ".\rootCA.cer"
$trustedCert = New-AzApplicationGatewayTrustedRootCertificate -Name "trustedCert1" -CertificateFile $certFilePath
```
لإنشاء قائمة من الكائنات PSApplicationGatewayTrustedRootCertificate، راجع New-AzApplicationGatewayTrustedRootCertificate.
privateIpAddress: [سلسلة]: اختياري. عنوان IP خاص معين تريد إقرانه ببوابة V2 الجديدة. يجب أن يكون هذا من نفس الشبكة الظاهرية التي تخصصها لبوابة V2 الجديدة. إذا لم يتم تحديد هذا، يخصص البرنامج النصي عنوان IP خاصا لبوابة V2 الخاصة بك.
publicIpResourceId: [سلسلة]: اختياري. معرف المورد لمورد عنوان IP العام (SKU القياسي) الموجود في اشتراكك الذي تريد تخصيصه إلى بوابة V2 الجديدة. إذا تم توفير اسم مورد IP العام، فتأكد من وجوده في حالة ناجحة. إذا لم يتم تحديد هذا، يخصص البرنامج النصي عنوان IP عاما جديدا في نفس مجموعة الموارد. الاسم هو اسم بوابة V2 مع إلحاق -IP . إذا تم توفير AppGWResourceGroupName ولم يتم توفير عنوان IP عام، فتأكد من عدم وجود مورد IP العام مع الاسم AppGWV2Name-IP في مجموعة موارد باسم AppGWResourceGroupName في اشتراك V1.
validateMigration: [التبديل]: اختياري. استخدم هذه المعلمة لتمكين البرنامج النصي من إجراء بعض عمليات التحقق من صحة مقارنة التكوين الأساسية بعد إنشاء بوابة V2 ونسخة التكوين. بشكل افتراضي، لم يتم التحقق من الصحة.
enableAutoScale: [التبديل]: اختياري. استخدم هذه المعلمة لتمكين البرنامج النصي لتمكين التحجيم التلقائي على بوابة V2 الجديدة بعد إنشائها. بشكل افتراضي، يتم تعطيل التحجيم التلقائي. يمكنك دائما تمكينه يدويا لاحقا على بوابة V2 التي تم إنشاؤها حديثا.

كيفية تشغيل البرنامج النصي

لتشغيل البرنامج النصي:

استخدم Connect-AzAccount للاتصال بـ Azure.
استخدم Import-Module Az لاستيراد الوحدات النمطية لـ Az.
Set-AzContext قم بتشغيل cmdlet، لتعيين سياق Azure النشط إلى الاشتراك الصحيح. هذه خطوة مهمة لأن البرنامج النصي للترحيل قد يقوم بتنظيف مجموعة الموارد الموجودة إذا لم تكن موجودة في سياق الاشتراك الحالي.
```
Set-AzContext -Subscription '<V1 application gateway SubscriptionId>'
```
قم بتثبيت البرنامج النصي باتباع الخطوات-تثبيت البرنامج النصي
تشغيل Get-Help AzureAppGWMigration.ps1 لفحص المعلمات المطلوبة:

قم بتشغيل البرنامج النصي باستخدام المعلمات المناسبة. قد يستغرق الأمر من خمس إلى سبع دقائق للانتهاء.

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

مثال

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

المحاذير\القيود

تحتوي بوابة V2 الجديدة على عناوين IP عامة وخاصة جديدة. لا يمكن نقل عناوين IP المقترنة ببوابة V1 الموجودة بسلاسة إلى V2. ومع ذلك، يمكنك تخصيص عنوان IP عام أو خاص موجود (غير مخصص) لبوابة V2 الجديدة.
يجب توفير مساحة عنوان IP لشبكة فرعية أخرى داخل شبكتك الظاهرية حيث توجد بوابة V1. لا يمكن للبرنامج النصي إنشاء بوابة V2 في شبكة فرعية تحتوي بالفعل على بوابة V1. إذا كانت الشبكة الفرعية تحتوي بالفعل على بوابة V2، فقد لا يزال البرنامج النصي يعمل، شريطة توفر مساحة عنوان IP كافية.
إذا كان لديك مجموعة أمان شبكة أو مسارات محددة من قبل المستخدم مقترنة بالشبكة الفرعية لبوابة V2، فتأكد من التزامها بمتطلبات NSG ومتطلبات UDR للترحيل الناجح.
نُهج نقطة نهاية خدمة الشبكة الظاهرية غير مدعومة حالياً في الشبكة الفرعية لـ Application Gateway.
لترحيل تكوين TLS/SSL، يجب تحديد جميع شهادات TLS/SSL المستخدمة في بوابة V1.
إذا كان لديك وضع FIPS ممكنا لبوابة V1، فلن يتم ترحيله إلى بوابة V2 الجديدة.
يتم إنشاء WAFv2 في وضع تكوين WAF القديم؛ الترحيل إلى نهج WAF مطلوب.
يتم تكوين WAFv2 الجديد لاستخدام CRS 3.0 بشكل افتراضي. ومع ذلك، نظرا لأن CRS 3.0 على المسار إلى الإهمال، نوصي بالترقية إلى أحدث مجموعة قواعد، DRS 2.1 بعد الترحيل. لمزيد من التفاصيل، راجع مجموعات قواعد وقواعد CRS وDRS

إشعار

يتم دعم مصادقة تمرير NTLM وKerberos بواسطة Application Gateway V2. لمزيد من التفاصيل، راجع اتصالات الواجهة الخلفية المخصصة.

تثبيت البرنامج النصي

إشعار

Set-AzContext -Subscription <V1 application gateway SubscriptionId> قم بتشغيل cmdlet في كل مرة قبل تشغيل البرنامج النصي للترحيل. هذا ضروري لتعيين سياق Azure النشط إلى الاشتراك الصحيح، لأن البرنامج النصي للترحيل قد يقوم بتنظيف مجموعة الموارد الموجودة إذا لم يكن موجودا في سياق الاشتراك الحالي.

هناك خياران لك وفقاً لإعدادات وتفضيلات بيئة PowerShell المحلية لديك:

إذا لم تكن لديك وحدات Azure Az مثبتة، أو لا تمانع في إزالة تثبيت وحدات Azure Az النمطية، فإن أفضل خيار هو استخدام الخيار Install-Script لتشغيل البرنامج النصي.
إذا كنت بحاجة إلى الاحتفاظ بوحدات Azure Az النمطية، فإن أفضل رهان لك هو تنزيل البرنامج النصي وتشغيله مباشرةً. لتحديد ما إذا كان لديك وحدات Azure Az النمطية مثبتة، قم بتشغيل 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

كيفية التحقق من إصدار البرنامج النصي الذي تم تنزيله

للتحقق من إصدار البرنامج النصي الذي تم تنزيله، تكون الخطوات كما يلي:

استخراج محتويات حزمة NuGet.
.PS1 افتح الملف في المجلد وتحقق من .VERSION الجزء العلوي لتأكيد إصدار البرنامج النصي الذي تم تنزيله

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

ترحيل نسبة استخدام الشبكة

المتطلبات الأساسية

أولا، تحقق من أن البرنامج النصي أنشأ بنجاح بوابة V2 جديدة مع التكوين الدقيق الذي تم ترحيله من بوابة V1 الخاصة بك. يمكنك التحقق من ذلك من مدخل Azure.
أرسل أيضا كمية صغيرة من حركة المرور من خلال بوابة V2 كاختبار يدوي.

البرنامج النصي العام للاحتفاظ بعنوان IP

بعد ترحيل التكوين بنجاح واختبار بوابة V2 الجديدة بدقة، تركز هذه الخطوة على إعادة توجيه حركة المرور المباشرة. نحن نقدم برنامج نصي Azure PowerShell مصمما للاحتفاظ بعنوان IP العام من V1.

مبادلة عنوان IP العام: يحتفظ هذا البرنامج النصي بعنوان IP العام الأساسي من V1 ، ويحوله إلى قياسي ، ويربطه ببوابة V2. يؤدي هذا إلى إعادة توجيه جميع نسبة استخدام الشبكة الواردة بشكل فعال إلى بوابة V2.
وقت التوقف عن العمل المتوقع: تؤدي عملية تبديل IP هذه عادة إلى وقت تعطل قصير يبلغ حوالي 1-5 دقائق. يرجى التخطيط وفقًا لذلك.
بعد تشغيل البرنامج النصي بنجاح، يتم نقل عنوان IP العام من Application Gateway V1 إلى Application Gateway V2، مع تلقي Application Gateway V1 عنوان IP عام جديد.

إشعار

سكريبت ترحيل IP لا يدعم موارد عناوين IP العامة التي يبدأ باسم DNS بحرف رقمي. هذا القيد موجود لأن موارد عناوين IP العامة لا تسمح بتسميات أسماء DNS التي تبدأ برقم. من المرجح أن تحدث هذه المشكلة في بوابات V1 التي تم إنشاؤها قبل مايو 2023، عندما تم تعيين عناوين IP العامة تلقائيا باسم DNS افتراضي من النموذج {GUID}.cloudapp.net. للمضي قدما في الترحيل، قم بتحديث مورد عنوان IP العام ليستخدم تسمية DNS تبدأ بحرف قبل تشغيل السكريبت. تعرف على كيفية تكوين DNS لبروتوكول IP العام

يمكنك تنزيل البرنامج النصي للاحتفاظ بعنوان IP العام هذا من معرض PowerShell

معلمات البرنامج النصي:

يتطلب هذا البرنامج النصي المعلمات الإلزامية التالية:

V1 ResourceId - معرف المورد لبوابة تطبيق V1 التي سيتم حجز عنوان IP العام الخاص بها وإقرانه ب V2.
V2 ResourceId - معرف المورد لبوابة تطبيق V2 التي سيتم تعيين عنوان IP العام V1 إليها. يمكن إنشاء بوابة V2 إما يدويا أو باستخدام أي برنامج نصي للاستنساخ.

بعد تنزيل البرنامج النصي وتثبيته

قم بتنفيذ 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.

إشعار

أثناء ترحيل IP، لا تحاول أي عملية أخرى على بوابة V1 و V2 أو أي موارد مقترنة.

إشعار

لا رجعة فيه مبادلة IP العامة التي يقوم بها هذا البرنامج النصي. بمجرد البدء، لا يمكن إرجاع عنوان IP مرة أخرى إلى بوابة V1 باستخدام البرنامج النصي.

توصيات ترحيل نسبة استخدام الشبكة

فيما يلي بعض السيناريوهات التي يمكن أن تتلقى فيها بوابة التطبيق الحالية (قياسية) نسبة استخدام الشبكة للعميل، وتوصياتنا لكل منها:

منطقة DNS مخصصة (على سبيل المثال، contoso.com) تشير إلى عنوان IP للواجهة الأمامية (باستخدام سجل A) المقترن ببوابة الإصدار 1 القياسي أو WAF V1. يمكنك تحديث سجل DNS للإشارة إلى عنوان IP الأمامي أو تسمية DNS المقترنة ببوابة تطبيق Standard_V2. اعتمادا على TTL الذي تم تكوينه على سجل DNS الخاص بك، قد يستغرق الأمر بعض الوقت حتى يتم ترحيل جميع نسبة استخدام الشبكة العميلة إلى بوابة V2 الجديدة.
منطقة DNS مخصصة (على سبيل المثال، contoso.com) تشير إلى تسمية DNS (على سبيل المثال: myappgw.eastus.cloudapp.azure.com باستخدام سجل CNAME) المقترنة ببوابة V1. لديك خياران:
- إذا كنت تستخدم عناوين IP العامة على بوابة التطبيق الخاصة بك، يمكنك القيام بترحيل دقيق ومتحكم به باستخدام ملف تعريف Traffic Manager لتوجيه نسبة استخدام الشبكة بشكل متزايد (أسلوب توجيه نسبة استخدام الشبكة المرجح) إلى بوابة V2 الجديدة. يمكنك القيام بذلك عن طريق إضافة تسميات DNS لكل من بوابات تطبيق V1 وV2 إلى ملف تعريف Traffic Manager، وCNAMEing سجل DNS المخصص (على سبيل المثال، www.contoso.com) إلى مجال Traffic Manager (على سبيل المثال، contoso.trafficmanager.net).
- أو يمكنك تحديث سجل DNS للمجال المخصص للإشارة إلى تسمية DNS لبوابة تطبيق V2 الجديدة. اعتمادا على TTL الذي تم تكوينه على سجل DNS الخاص بك، قد يستغرق الأمر بعض الوقت حتى يتم ترحيل جميع نسبة استخدام الشبكة العميلة إلى بوابة V2 الجديدة.
يتصل العملاء بعنوان IP الأمامي لبوابة التطبيق. قم بتحديث عملائك لاستخدام عنوان IP المقترن ببوابة تطبيق V2 التي تم إنشاؤها حديثا. نوصي بعدم استخدام عناوين IP مباشرة. خذ بعين الاعتبار استخدام تسمية اسم DNS (على سبيل المثال، yourgateway.eastus.cloudapp.azure.com) المقترنة ببوابة التطبيق التي يمكنك CNAME إلى منطقة DNS المخصصة الخاصة بك (على سبيل المثال، contoso.com).

ما بعد الهجرة

بمجرد نجاح ترحيل نسبة استخدام الشبكة وبعد التحقق الكامل من تشغيل التطبيق بشكل صحيح من خلال بوابة V2، يمكنك التخطيط بأمان لإيقاف تشغيل مورد V1 Application Gateway القديم وحذفه لتجنب التكاليف غير الضرورية.

اعتبارات التسعير

تختلف نماذج التسعير لوحدات SKU V1 وV2 لبوابة التطبيق. يتم احتساب V2 بناء على الاستهلاك. راجع تسعير بوابة التطبيق قبل الترحيل للحصول على معلومات التسعير.

إرشادات كفاءة التكلفة

يأتي V2 SKU مع مجموعة من المزايا مثل تعزيز الأداء بنسبة 5 أضعاف، وتحسين الأمان مع تكامل Key Vault، وتحديثات أسرع لقواعد الأمان في WAF_V2، وقواعد WAF المخصصة، وارتباطات النهج، وحماية الروبوت. كما أنه يوفر قابلية توسع عالية، وتوجيه محسن لنسبة استخدام الشبكة، والتكامل السلس مع خدمات Azure. يمكن لهذه الميزات تحسين تجربة المستخدم الإجمالية، ومنع التباطؤ أثناء أوقات حركة المرور الكثيفة، وتجنب خروقات البيانات باهظة الثمن.

هناك خمسة متغيرات متوفرة في V1 SKU استنادا إلى المستوى والحجم - Standard_Small Standard_Medium Standard_Large WAF_Medium WAF_Large.

وحدة حفظ المخزون SKU	V1 السعر الثابت/mo	V2 السعر الثابت/mo	التوصية
متوسط قياسي	102.2	179.8	يمكن ل V2 SKU معالجة عدد أكبر من الطلبات من بوابة V1، لذلك نوصي بدمج بوابات V1 متعددة في بوابة V2 واحدة، لتحسين التكلفة. تأكد من أن الدمج لا يتجاوز حدود بوابة التطبيق. نوصي بدمج 3:1.
WAF متوسط	183.96	262.8	كما هو الحال مع متوسط قياسي
قياسي كبير	467.2	179.58	بالنسبة لهذه المتغيرات، في معظم الحالات، يمكن أن يوفر لك الانتقال إلى بوابة V2 ميزة سعر أفضل مقارنة ب V1.
WAF كبير	654.08	262.8	كما هو الحال بالنسبة إلى Standard Large

إشعار

تستند العمليات الحسابية الموضحة هنا إلى شرق الولايات المتحدة ولبوابة بها مثيلتان في V1. تعتمد التكلفة المتغيرة في V2 على أحد الأبعاد الثلاثة ذات الاستخدام الأعلى: الاتصالات الجديدة (50 / ثانية) ، الاتصالات المستمرة (2500 اتصال مستمر / دقيقة) ، الإنتاجية (يمكن ل CU واحد التعامل مع 2.22 ميجابت في الثانية).

السيناريوهات الموضحة هنا هي أمثلة ولأغراض التوضيح فقط. للحصول على معلومات التسعير وفقًا لمنطقتك، راجعصفحة التسعير.

لمزيد من المخاوف المتعلقة بالتسعير، تعاون مع CSAM أو تواصل مع فريق الدعم لدينا للحصول على المساعدة.

الأسئلة الشائعة

يمكن العثور على الأسئلة الشائعة حول الترحيل هنا

الخطوات التالية

تعرف على الإصدار 2 من Application Gateway

الملاحظات

هل كانت هذه الصفحة مفيدة؟

Last updated on 2025-11-04

مشاركة عبر

ترحيل بوابة تطبيق Azure وجدار حماية تطبيق الويب من V1 إلى V2

المتطلبات الأساسية

Azure Cloud Shell

ترحيل التكوين

1. برنامج نصي استنساخ محسن

كيفية تشغيل البرنامج النصي

التوصيات

تحذيرات

2. نص الاستنساخ القديم

كيفية تشغيل البرنامج النصي

المحاذير\القيود

تثبيت البرنامج النصي

التثبيت باستخدام أسلوب Install-Script (مستحسن)

التثبيت باستخدام البرنامج النصي مباشرةً

كيفية التحقق من إصدار البرنامج النصي الذي تم تنزيله

ترحيل نسبة استخدام الشبكة

المتطلبات الأساسية

البرنامج النصي العام للاحتفاظ بعنوان IP

توصيات ترحيل نسبة استخدام الشبكة

ما بعد الهجرة

اعتبارات التسعير

إرشادات كفاءة التكلفة

الأسئلة الشائعة

الخطوات التالية

الملاحظات

الموارد الإضافية