مشاركة عبر

إنشاء بادئة عنوان IPv4 مخصصة باستخدام Azure CLI

  • مقالة

تمكنك بادئة عنوان IPv4 المخصصة من إحضار نطاقات IPv4 الخاصة بك إلى Microsoft وربطها باشتراك Azure الخاص بك. سيظل النطاق مملوكًا لك، على الرغم من أنه سيسمح لشركة Microsoft بالإعلان عنه على الإنترنت. تعمل بادئة عنوان IP المخصصة كمورد إقليمي يمثل كتلة متجاورة من عناوين IP المملوكة للعملاء.

توضح الخطوات الواردة في هذه المقالة تفاصيل العملية المطلوبة لـ:

  • إعداد النطاق المطلوب توفيره

  • توفير النطاق لتخصيص عنوان IP

  • تمكين النطاق المطلوب إعلان عنه بواسطة Microsoft

إذا لم يكن لديك اشتراك في Azure، فأنشئ حساب Azure مجاني قبل أن تبدأ.

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

  • حساب Azure مع اشتراك نشط. أنشئ حساباً مجاناً.
  • يتطلب هذا البرنامج التعليمي الإصدار 2.28 أو إصدار أحدث من Azure CLI (يمكنك تشغيل إصدار az لتحديد الإصدار الذي لديك). إذا كنت تستخدم Azure Cloud Shell، يتم تثبيت أحدث إصدار بالفعل.
  • سجل الدخول إلى Azure CLI، وتأكد من تحديد الاشتراك الذي تريد استخدام هذه الميزة من خلاله باستخدام az account.
  • نطاق IPv4 المملوك للعميل لتوفيره في Azure.
    • يتم استخدام عينة من نطاق العميل (1.2.3.0/24) في هذا المثال. لن يتم التحقق من صحة هذا النطاق بواسطة Azure. استبدل النطاق الوارد في المثال بنطاقك.

إشعار

للاطلاع على المشكلات التي ظهرت أثناء عملية التوفير، يرجى مراجعة استكشاف الأخطاء وإصلاحها في بادئة عنوان IP المخصصة.

خطوات التوفير المسبق

لاستخدام ميزة AZURE BYOIP، يجب عليك تنفيذ الخطوات التالية قبل توفير نطاق عناوين IPv4.

المتطلبات وجاهزية البادئة

  • يجب أن يكون نطاق العنوان مملوكا لك ومسجلا باسمك بأحد سجلات الإنترنت الإقليمية الخمسة الرئيسية:

  • يجب ألا يقل نطاق العناوين عن /24، بحيث يتم قبوله من قبل موفري خدمات الإنترنت.

  • يجب أن يتم ملء مستند تخويل أصل المسار (ROA) الذي يخول Microsoft للإعلان عن نطاق العناوين بواسطة العميل على موقع ويب سجل إنترنت المسار (RIR) المناسب أو عبر واجهة برمجة التطبيقات. سيتطلب RIR توقيع ROA رقميًا مع البنية التحتية للمفتاح العام للموارد (RPKI) لـ RIR لديك.

    بالنسبة إلى تخويل أصل المسار:

    • يجب إدراج Origin AS ك 8075 للسحابة العامة. (إذا كان النطاق سيتم إلحاقه ب US Gov Cloud، فيجب إدراج Origin AS ك 8070.)

    • يجب أن يحسب تاريخ انتهاء الصلاحية الوقت الذي تنوي فيه الإعلان عن البادئة بواسطة Microsoft. لا تقدم بعض سجلات RIR تاريخ انتهاء الصلاحية كخيار أو تختار التاريخ لك.

    • يجب أن يتطابق طول البادئة تمامًا مع البادئات التي يمكن أن تعلن عنها Microsoft. على سبيل المثال، إذا كنت تخطط لتوفير 1.2.3.0/24 و2.3.4.0/23 في Microsoft، يجب تسميتهما.

    • بعد اكتمال ROA وإرساله، انتظر 24 ساعة على الأقل حتى يصبح متاحًا لشركة Microsoft، حيث سيتم التحقق منه لتحديد صلاحيته وصحته كجزء من عملية التوفير.

إشعار

يُوصى أيضًا بإنشاء ROA لأي ASN موجود يقوم بالإعلان عن النطاق وذلك لتجنب أي مشاكل أثناء الترحيل.

هام

على الرغم من أن Microsoft لن تتوقف عن الإعلان عن النطاق بعد التاريخ المحدد، فمن المستحسن بشدة إنشاء ROA للمتابعة بشكل مستقل إذا مر تاريخ انتهاء الصلاحية الأصلي لتجنب شركات الاتصالات الخارجية من عدم قبول الإعلان.

جاهزية الشهادة

لتخويل Microsoft لإقران بادئة باشتراك عميل، يجب مقارنة الشهادة العامة بالرسالة الموقعة.

توضح الخطوات التالية الخطوات المطلوبة لإعداد نموذج نطاق العملاء (1.2.3.0/24) للتزويد إلى السحابة العامة.

إشعار

قم بتنفيذ الأوامر التالية في PowerShell مع تثبيت OpenSSL.

  1. يجب إنشاء شهادة X509 موقعة ذاتيًا لإضافتها إلى سجل Whois/RDAP للبادئة. للحصول على معلومات حول RDAP، راجع مواقع ARIN و RIPE و APNIC و AFRINIC .

    يظهر أدناه مثال على استخدام مجموعة أدوات OpenSSL. تقوم الأوامر التالية بإنشاء مفتاح RSA مزدوج وإنشاء شهادة X509 باستخدام المفتاح المزدوج الذي تنتهي صلاحيته في غضون ستة أشهر:

    ./openssl genrsa -out byoipprivate.key 2048
Set-Content -Path byoippublickey.cer (./openssl req -new -x509 -key byoipprivate.key -days 180) -NoNewline

  2. بعد إنشاء الشهادة، قم بتحديث قسم التعليقات العامة من سجل Whois/RDAP للبادئة. للعرض بغرض النسخ، بما في ذلك عنوان/تذييل BEGIN/END مع شرطات، استخدم الأمر cat byoippublickey.cer، ويجب أن تكون قادرًا على تنفيذ هذا الإجراء عبر سجل توجيه الإنترنت.

    وفيما يلي تعليمات لكل سجل:

    • ARIN - تحرير "التعليقات" لسجل البادئة.

    • RIPE - تحرير "ملاحظات" سجل inetnum.

    • APNIC - تحرير "ملاحظات" سجل inetnum باستخدام MyAPNIC.

    • AFRINIC - تحرير "ملاحظات" سجل inetnum باستخدام MyAFRINIC.

    • بالنسبة إلى النطاقات من سجل LACNIC، قم بإنشاء تذكرة دعم باستخدام Microsoft.

    بعد ملء التعليقات العامة، يجب أن يبدو سجل Whois/RDAP مثل المثال أدناه. تأكد من عدم وجود مسافات أو أحرف إرجاع. تضمين جميع الشرطات:

    Screenshot of example certificate comment

  3. لإنشاء الرسالة التي سيتم تمريرها إلى Microsoft، أنشئ سلسلة تحتوي على معلومات ذات صلة حول البادئة والاشتراك. قم بتوقيع هذه الرسالة باستخدام المفتاح المزدوج الذي تم إنشاؤه في الخطوات أعلاه. استخدم التنسيق الموضح أدناه، مع استبدال معرف الاشتراك والبادئة المراد توفيرها، وتاريخ انتهاء الصلاحية المطابق لتاريخ الصلاحية في تخويل أصل المسار. تأكد من أن يكون التنسيق بهذا الترتيب.

    استخدم الأمر التالي لإنشاء رسالة موقعة يتم تمريرها إلى Microsoft للتحقق منها.

    إشعار

    إذا لم يتم تضمين تاريخ انتهاء الصلاحية في تخويل أصل المسار، فاختر تاريخًا يتوافق مع الوقت الذي تريد فيه أن يتم الإعلان عن البادئة بواسطة Azure. لاحظ أيضا أن Microsoft لن تتوقف عن الإعلان عن النطاق بعد التاريخ المحدد، ولكن يوصى بإنشاء ROA للمتابعة بشكل مستقل إذا مر تاريخ انتهاء الصلاحية الأصلي.

    $byoipauth="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx|1.2.3.0/24|yyyymmdd"
Set-Content -Path byoipauth.txt -Value $byoipauth -NoNewline
./openssl dgst -sha256 -sign byoipprivate.key -keyform PEM -out byoipauthsigned.txt byoipauth.txt
$byoipauthsigned=(./openssl enc -base64 -in byoipauthsigned.txt) -join ''

  4. لعرض محتوى الرسالة الموقعة، أدخل المتغير الذي تم إنشاؤه من الرسالة الموقعة التي تم إنشاؤها مسبقًا، وحدّد Enter في مطالبة PowerShell:

    $byoipauthsigned
dIlwFQmbo9ar2GaiWRlSEtDSZoH00I9BAPb2ZzdAV2A/XwzrUdz/85rNkXybXw457//gHNNB977CQvqtFxqqtDaiZd9bngZKYfjd203pLYRZ4GFJnQFsMPFSeePa8jIFwGJk6JV4reFqq0bglJ3955dVz0v09aDVqjj5UJx2l3gmyJEeU7PXv4wF2Fnk64T13NESMeQk0V+IaEOt1zXgA+0dTdTLr+ab56pR0RZIvDD+UKJ7rVE7nMlergLQdpCx1FoCTm/quY3aiSxndEw7aQDW15+rSpy+yxV1iCFIrUa/4WHQqP4LtNs3FATvLKbT4dBcBLpDhiMR+j9MgiJymA==

خطوات التوفير

تعرض الخطوات التالية الإجراء الخاص بتوفير عينة من نطاق العميل (1.2.3.0/24) في منطقة غرب الولايات المتحدة الأمريكية 2.

إشعار

لا يتم عرض خطوات التنظيف أو الحذف في هذه الصفحة نظرًا لطبيعة المورد. للحصول على معلومات حول إزالة بادئة IP مخصصة موفرة، راجع إدارة بادئة IP المخصصة.

إنشاء مجموعة موارد وتحديد البادئة ورسائل التخويل

إنشاء مجموعة موارد في الموقع المطلوب لتوفير نطاق BYOIP.

  az group create \
    --name myResourceGroup \
    --location westus2

توفير بادئة عنوان IP مخصصة

ينشئ الأمر التالي بادئة IP مخصصة في المنطقة المحددة ومجموعة الموارد. حدد البادئة الدقيقة في رمز CIDR كسلسلة لضمان عدم وجود خطأ في بناء الجملة. بالنسبة إلى المعلمة --authorization-message، استخدم المتغير $byoipauth الذي يحتوي على معرف الاشتراك والبادئة المراد توفيرها وتاريخ انتهاء الصلاحية المطابق لتاريخ الصلاحية على تخويل أصل المسار. تأكد من أن يكون التنسيق بهذا الترتيب. استخدم المتغير $byoipauthsigned للمعلمة --signed-message التي تم إنشاؤها في قسم جاهزية الشهادة.

  byoipauth="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx|1.2.3.0/24|yyyymmdd"
  
  az network custom-ip prefix create \
    --name myCustomIpPrefix \
    --resource-group myResourceGroup \
    --location westus2 \
    --cidr ‘1.2.3.0/24’ \
    --zone 1 2 3
    --authorization-message $byoipauth \
    --signed-message $byoipauthsigned

سيتم توفير النطاق في مسار عمليات توزيع Azure IP. عملية التوزيع غير متزامنة. لتحديد الحالة، قم بتنفيذ الأمر التالي:

 az network custom-ip prefix show \
   --name myCustomIpPrefix \
   --resource-group myResourceGroup

يتم عرض إخراج العينة أدناه، مع إزالة بعض الحقول للوضوح:

{
  "cidr": "1.2.3.0/24",
  "commissionedState": "Provisioning",
  "id": "/subscriptions/xxxx/resourceGroups/myResourceGroup/providers/Microsoft.Network/customIPPrefixes/myCustomIpPrefix",
  "location": "westus2",
  "name": myCustomIpPrefix,
  "resourceGroup": "myResourceGroup",
}

يجب أن يعرض حقل CommissionedState النطاق على أنه بالحالة قيد التوفير في البداية، متبوعًا في المستقبل بالحالة متوفر.

إشعار

الوقت المقدر لإكمال عملية التوفير هو 30 دقيقة.

هام

بعد أن تكون بادئة IP المخصصة بالحالة متوفر، يمكن إنشاء بادئة IP عام فرعي. يمكن إرفاق بادئات IP العامة هذه وأي عناوين IP عامة بموارد الشبكات. على سبيل المثال، واجهات شبكة الجهاز الظاهري أو الواجهات الأمامية لموازن التحميل. لن يتم الإعلان عن عناوين IP، وبالتالي سيتعذر الوصول إليها. لمزيد من المعلومات حول ترحيل بادئة نشطة، راجع إدارة بادئة IP مخصصة.

تكليف بادئة عنوان IP المخصصة

عندما تكون بادئة IP المخصصة بالحالة متوفرة، يقوم الأمر التالي بتحديث البادئة لبدء عملية الإعلان عن النطاق من Azure.

az network custom-ip prefix update \
    --name myCustomIpPrefix \
    --resource-group myResourceGroup \
    --state commission

كما كان من قبل، العملية غير متزامنة. استخدم عرض بادئة az network-ip المخصصة لاسترداد الحالة. سيعرض حقل CommissionedState مبدئيًا البادئة على أنها قيد التكليف، متبوعة في المستقبل بالحالة مُكلفة. إطلاق الإعلان ليس ثنائيًا، وسيتم الإعلان عن النطاق جزئيًا بينما لا يزال في الحالة قيد التكليف.

إشعار

الوقت المقدر لإكمال عملية التكليف بالكامل هو 3-4 ساعات.

هام

مع انتقال بادئة IP المخصصة إلى حالة مُكلفة، يتم الإعلان عن النطاق من خلال Microsoft من منطقة Azure المحلية وعالميًا إلى الإنترنت بواسطة شبكة Microsoft واسعة النطاق بموجب رقم النظام المستقل (ASN) 8075. قد يؤدي الإعلان عن هذا النطاق نفسه على الإنترنت من موقع بخلاف Microsoft في نفس الوقت إلى عدم استقرار توجيه BGP أو فقدان نسبة استخدام الشبكة. على سبيل المثال، إنشاء داخلي للعميل. خطط لأي ترحيل لنطاق نشط خلال فترة الصيانة لتجنب التأثير. بالإضافة إلى ذلك، يمكنك الاستفادة من ميزة التكليف الإقليمية لوضع بادئة IP مخصصة في حالة يتم الإعلان عنها فقط داخل منطقة Azure التي يتم نشرها فيها- راجع إدارة بادئة عنوان IP مخصص (BYOIP) لمزيد من المعلومات.

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