توجيه نسبة استخدام الشبكة الظاهرية

  • مقالة
  • قراءة خلال 24 دقائق

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

مسارات النظام

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

افتراضي

يحتوي كل مسار على بادئة عنوان ونوع القفزة التالية. عند إرسال عملية نقل بيانات مغادرة لشبكة فرعية إلى عنوان IP داخل بادئة العنوان لمسار ما، يكون المسار الذي يحتوي على البادئة هو المسار الذي يستخدمه Azure. تعرف على المزيد حول كيفية تحديد Azure لتوجيه عندما تحتوي توجيهات متعددة على نفس البادئات أو بادئات متداخلة. كلما أنشئت شبكة ظاهرية، يُنشئ Azure مسارات النظام الافتراضية التالية تلقائياً لكل شبكة فرعية داخل الشبكة الظاهرية:

المصدر بادئات العناوين نوع الوثب التالي
افتراضي فريدة إلى الشبكة الظاهرية شبكة ظاهرية
افتراضي 0.0.0.0/0 الإنترنت
افتراضي 10.0.0.0/8 بلا
افتراضي 192.168.0.0/16 بلا
افتراضي 100.64.0.0/10 بلا

تمثل أنواع القفز التالية المدرجة في الجدول السابق كيفية توجيه Azure لعملية نقل البيانات الموجهة لبادئة العنوان المدرجة. فيما يلي شرح لأنواع الوثب التالية:

  • Virtual network: يوجِّه نقل البيانات بين نطاقات العناوين داخل مساحة عنوان الشبكة الظاهرية. يُنشئ Azure مساراً ببادئة عنوان تتوافق مع كل نطاق عنوان معرّف ضمن مساحة العنوان الخاصة بالشبكة الظاهرية. إذا كان لمساحة عنوان الشبكة الظاهرية نطاقات عناوين متعددة مُعرّفة، ينشئ Azure توجيهاً مفرداَ لكل نطاق عناوين. يوجه Azure نسبة استخدام الشبكة بين الشبكات الفرعية تلقائياً باستخدام المسارات التي تم إنشاؤها لكل نطاق عناوين. أنت لست بحاجة إلى تحديد بوابات لـ Azure لتوجيه نسبة استخدام الشبكة بين الشبكات الفرعية. على الرغم من أن الشبكة الظاهرية تحتوي على شبكات فرعية، وكل شبكة فرعية لها نطاق عناوين محدد، فإن Azure لا ينشئ مسارات افتراضية لنطاقات عناوين الشبكة الفرعية؛ وذلك لأن كل نطاق عناوين للشبكة الفرعية يقع ضمن نطاق عناوين مساحة عنوان الشبكة الظاهرية.

  • Internet: يوجِّه نقل البيانات المُحدد من قبل بادئة العنوان إلى الإنترنت. يحدد التوجيه الافتراضي للنظام بادئة العنوان 0.0.0.0/0. إذا لم تتجاوز التوجيهات الافتراضية لـ Azure، فسيوجِّه Azure نقل البيانات لأي عنوان غير محدد من خلال نطاق عناوين داخل شبكة ظاهرية، إلى الإنترنت، باستثناء واحد. إذا كان عنوان الوجهة إحدى خدمات Azure، فإن Azure يوجِّه نقل البيانات مباشرةً إلى الخدمة عبر شبكة تجميع Azure، بدلاً من توجيه نقل البيانات إلى Internet. لا تُوزّع حركة المرور الإنترنت بين خدمات Azure بغض النظر عن منطقة Azure الموجودة في الشبكة الظاهرية أو منطقة Azure التي يتم نشر مثيل Azure service فيها. يمكنك تجاوز توجيه النظام الافتراضي الخاص بـ Azure لبادئة العنوان 0.0.0.0/0 باستخدام توجيه مُخصص.

  • None: يتم إفلات نقل البيانات الموجَّه إلى نوع الوثب التالي None، بدلاً من الموجَّهة إلى خارج الشبكة الفرعية. يُنشئ Azure المسارات الافتراضية لبادئات العناوين التالية تلقائياً:

    • 10.0.0.0/8 و192.168.0.0/16: محجوز للاستخدام الخاص في RFC 1918.
    • 100.64.0.0/10: محجوز في RFC 6598.

    إذا عيّنت أياً من نطاقات العناوين السابقة ضمن مساحة العنوان لشبكة ظاهرية، فسيغير Azure نوع الوثب التالي للمسار تلقائياً من None إلى Virtual network. إذا عيّنت نطاق عناوين لمساحة عنوان الشبكة الظاهرية التي تتضمن، ولكن ليست مثل، واحدة من بادئات العنوان الأربعة المحجوزة، فسيزيل Azure توجيه البادئة ويضيف توجيهاً لبادئة العنوان التي أضفتها، مع تعيين Virtual network كنوع الوثب التالي.

المسارات الافتراضية الاختيارية

يضيف Azure توجيهات أخرى من توجيهات النظام لإمكانات Azure المختلفة ولكن فقط إذا قمت بتمكين الإمكانات. بناء على الإمكانيات، يضيف Azure المسارات الافتراضية الاختيارية إما لشبكات فرعية معينة داخل الشبكة الظاهرية، وإما لكافة الشبكات الفرعية داخل شبكة ظاهرية. تعتبر مسارات النظام الإضافية وأنواع القفز التالية التي قد تضيفها Azure عندما تفعّل الإمكانيات المختلفة هي:

المصدر بادئات العناوين نوع الوثب التالي الشبكة الفرعية داخل الشبكة الظاهرية التي أُضيف المسار إليها
افتراضي تقتصر على الشبكة الظاهرية، على سبيل المثال: 10.1.0.0/16 الإقران بين الشبكات الظاهرية الكل
بوابة الشبكة الظاهرية البادئات التي أُعلن عنها محلياً باستخدام BGP أو كُوِّنت في بوابة الشبكة المحلية بوابة الشبكة الظاهرية الكل
افتراضية متعددة VirtualNetworkServiceEndpoint فقط الشبكة الفرعية التي تم تمكين نقطة تقديم الخدمة لها.

  • إنشاء نظير شبكة ظاهرية (VNet): عند إنشاء نظير شبكة ظاهرية بين شبكتين ظاهريتين، يُضاف مسار لكل نطاق عناوين ضمن مساحة العنوان لكل شبكة ظاهرية يتم إنشاء نظير لها. تعرّف على المزيد حول إنشاء نظير شبكة ظاهرية.

  • Virtual network gateway: تتم إضافة مسار واحد أو أكثر مع Virtual network gateway المُعينة كنوع الوثب التالي عند إضافة بوابة شبكة ظاهرية إلى شبكة ظاهرية. المصدر أيضاً بوابة شبكة ظاهرية، لأن البوابة تضيف التوجيهات إلى الشبكة الفرعية. إذا كانت بوابة شبكتك المحلية تتبادل مسارات بروتوكول بوابة الحدود (BGP) مع بوابة شبكة ظاهرية تابعة لـ Azure، تتم إضافة مسار لكل مسار تم نشره من بوابة الشبكة المحلية. من المستحسن تلخيص التوجيهات المحلية إلى أكبر نطاقات عناوين ممكنة، بحيث يتم توزيع أقل عدد من التوجيهات على بوابة شبكة Azure الظاهرية. هناك حدود لعدد التوجيهات التي يمكنك نشرها إلى بوابة الشبكة الظاهرية لـ Azure. للحصول على التفاصيل، راجع حدود Azure.

  • VirtualNetworkServiceEndpoint: تُضاف عناوين IP العامة لخدمات معينة إلى جدول التوجيه بواسطة Azure عند تمكين نقطة تقديم خدمة للخدمة. تُفعّل نقاط نهاية الخدمة للشبكات الفرعية الفردية داخل شبكة ظاهرية، لذا يُضاف المسار فقط إلى جدول مسارات الشبكة الفرعية التي تُمكن نقطة تقديم الخدمة لها. عناوين IP العامة لخدمات Azure تتغير بشكل دوري. يقوم Azure بإدارة العناوين في جدول التوجيه تلقائياً عند تغيير العناوين. تعرّف على المزيد حول نقاط تقديم الخدمة للشبكة الظاهرية، والخدمات التي يمكنك إنشاء نقاط تقديم خدمة لها.

    ملاحظة

    يُضاف الاقتران بين الشبكات الافتراضية و أنواع الوثبات التالية لـ VirtualNetworkServiceEndpoint لجدول مسارات الشبكة الفرعية داخل الشبكات الظاهرية التي أُنشئت من خلال نموذج نشرAzure Resource Manager. لا تُضاف أنواع القفز التالية إلى جداول المسارات المقترنة بالشبكات الفرعية التابعة للشبكة الظاهرية التي أنشئت من خلال نموذج النشر الكلاسيكي. تعرّف على المزيد حول نماذج التوزيع لـ Azure.

مسارات مخصصة

يمكنك إنشاء مسارات مخصصة إما عن طريق إنشاء مسارات معرّفة من قبل المستخدم، أو عن طريق تبديل مسارات بروتوكول بوابة الحدود (BGP) بين بوابة الشبكة المحلية وبوابة شبكة Azure الظاهرية.

معرّف بواسطة المستخدم

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

يمكنك تحديد أنواع القفز التالية عند إنشاء مسار معرف من قبل المستخدم:

  • Virtual appliance: الجهاز الظاهري أداة ظاهرية عادة ما تُشغل تطبيق شبكة مثل جدار الحماية. للتعرّف على مجموعة متنوعة من الأجهزة الظاهرية للشبكة المكوّنَة مسبقاً، والتي يمكنك توزيعها في شبكة ظاهرية، راجع Azure Marketplace. عند إنشاء توجيه باستخدام نوع الوثب virtual appliance، يمكنك أيضاً تحديد عنوان IP لنوع الوثب التالي. يمكن أن يكون عنوان IP:

    • عنوان IP خاص لواجهة شبكة متصلة بجهاز ظاهري. لأي واجهة شبكة متصلة بجهاز ظاهري يعيد توجيه نقل البيانات إلى عنوان آخر غير عنوانه، يجب أن يكون خيار Azure Enable IP forwarding ممكناً. يعطل الإعداد فحص Azure للمصدر والوجهة لواجهة الشبكة. تعرّف على المزيد حول تمكين إعادة توجيه IP لواجهة الشبكة. على الرغم من أن Enable IP forwarding أحد إعدادات Azure، فقد تحتاج أيضاً إلى تمكين إعادة توجيه IP داخل نظام تشغيل الجهاز الظاهري حتى يتمكن الجهاز من إعادة توجيه نقل البيانات بين عناوين IP الخاصة المعينة لواجهات شبكة Azure. إذا كان يجب توجيه لنقل البيانات إلى عنوان IP عام بواسطة الجهاز، فيجب إما أن يستخدم الجهاز وكيل لتوجيه نقل البيانات أو أن يحوّل عنوان الشبكة عنوان IP الخاص المرتبط بعنوان IP الخاص للمصدر إلى عنوان IP خاص له، والذي يحوّله بعد ذلك عنوان شبكة Azure إلى عنوان IP عام، قبل إرسال نقل البيانات إلى Internet. لتحديد الإعدادات المطلوبة داخل الجهاز الظاهري، راجع الوثائق المتعلقة بنظام التشغيل أو تطبيق الشبكة. لفهم الاتصالات الصادرة في Azure، راجع فهم الاتصالات الصادرة.

      ملاحظة

      يمكنك توزيع جهاز ظاهري في شبكة فرعية مختلفة عن الموارد حيث تم توزيع التوجيه عبر الجهاز الظاهري. يمكن أن يؤدي توزيع الجهاز الظاهري إلى نفس الشبكة الفرعية، ثم تطبيق جدول توجيه على الشبكة الفرعية التي توجِّه نقل البيانات عبر الجهاز الظاهري، إلى التكرار الحلقي للتوجيه، بحيث لا يغادر نقل البيانات الشبكة الفرعية.

      يجب أن يكون لعنوان IP الخاص للوثب التالي اتصال مباشر دون الحاجة إلى التوجيه عبر ExpressRoute Gateway أو Virtual WAN. يؤدي تعيين القفزة التالية إلى عنوان IP بدون اتصال مباشر إلى تكوين توجيه غير صالح معرف من قبل المستخدم.

    • عنوان IP الخاص لـ موازن التحميل الداخلي لـ Azure. يُستخدم موازن التحميل عادة كجزء من استراتيجية قابلية الوصول العالية للأجهزة الظاهرية للشبكة.

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

  • بوابة الشبكة الظاهرية: حدد الوقت الذي تريد فيه نقل البيانات الموجهة إلى بادئات عناوين مُحددة مُوجهة إلى بوابة الشبكة الظاهرية. يجب إنشاء بوابة الشبكة الظاهرية من نوع VPN. لا يمكنك تحديد بوابة شبكة ظاهرية تم إنشاؤها كنوع ExpressRoute في توجيه مُعرّف من قبل المستخدم لأنه مع ExpressRoute، يجب عليك استخدام BGP للتوجيهات المخصصة. لا يمكنك تحديد Virtual Network Gateways إذا كان كل من اتصالات VPN وExpressRoute موجوداً لديك. يمكنك تحديد مسار يوجه نقل البيانات الموجَّه لبادئة العنوان 0.0.0.0/0 إلى بوابة شبكة ظاهرية تستند إلى المسار. قد يكون لديك جهاز في مكان عملك يفحص نقل البيانات ويحدد ما إذا كنت تريد إعادة توجيهه أو إفلاته. إذا كنت تنوي إنشاء توجيه مُعرّف من قبل المستخدم لبادئة العنوان 0.0.0.0/0، فاطلع على بادئة العنوان 0.0.0.0/0 أولاً. بدلاً من تكوين مسار مُعرّف من قبل المستخدم لبادئة العنوان 0.0.0.0/0، يمكنك الإعلان عن مسار بالبادئة 0.0.0.0/0 عبر BGP، إذا قمت بـ تمكين BGP لبوابة شبكة ظاهرية VPN.

  • بلا: حدد الوقت الذي تريد فيه إسقاط عملية نقل البيانات لبادئة عنوان، بدلاً من إعادة توجيه نقل البيانات لوجهة. إذا كنت لم تكوّن إحدى الإمكانات بالكامل، فقد يدرج Azure None لبعض توجيهات النظام الاختيارية. على سبيل المثال، إذا رأيت None مدرجاً كـ عنوان IP للوثب التالي مع نوع الوثب التالي لـ بوابة الشبكة الظاهرية أو الجهاز الظاهري، فربما يرجع ذلك إلى أن الجهاز لا يعمل أو لم يتم تكوينه بالكامل. ينشئ Azure توجيهات افتراضية للنظام لبادئات العناوين المحجوزة بتعيين نوع الوثب التالي على None.

  • الشبكة الظاهرية: حدد الوقت الذي تريد فيه تجاوز المسارات الافتراضية داخل الشبكة الظاهرية. راجع Routing example، للاطلاع على مثال لأحد الأسباب الممكنة للحاجة إلى إنشاء توجيه باستخدام نوع الوثب Virtual network.

  • Internet: حدد الوقت الذي تريد أن توجِّه فيه نقل البيانات الموجَّه لبادئة عنوان إلى Internet، أو إذا كنت تريد إبقاء نقل البيانات الموجهة لخدمات Azure بعناوين IP عامة داخل شبكة تجميع Azure.

لا يمكنك تحديد VNet peering أو VirtualNetworkServiceEndpoint كنوع الوثب التالي في التوجيهات المُعرّفة من قبل المستخدم. يتم إنشاء التوجيهات حيث نوع الوثب التالي يُعين على VNet peering أو VirtualNetworkServiceEndpoint بواسطة Azure فقط، عند تكوين نظير شبكة ظاهرية أو نقطة تقديم خدمة.

Service Tags للتوجيهات المُعرّفة من قبل المستخدم

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

مطابقة تامة

عندما يكون هناك تطابق بادئة تام بين توجيه له بادئة IP صريحة وتوجيه له Service Tag، تُعطى الأفضلية للتوجيه الذي له بادئة صريحة. عندما يكون للتوجيهات المتعددة التي لها Service Tags بادئات IP مطابقة، يتم تقييم التوجيهات بالترتيب التالي:

  1. علامات المناطق(على سبيل المثال، Storage.EastUS, AppService.AustraliaCentral)
  2. علامات المستوى الأعلى (على سبيل المثال، Storage، AppService)
  3. علامات مناطق AzureCloud (على سبيل المثال، AzureCloud.canadacentral، AzureCloud.eastasia)
  4. علامة AzureCloud

لاستخدام هذه الميزة، حدد اسم Service Tag لمعلمة بادئة العنوان في أوامر جدول التوجيه. على سبيل المثال، يمكنك في PowerShell إنشاء توجيه جديد لتوجيه نقل البيانات المُرسل إلى بادئة عنوان IP لـ Azure Storage إلى جهاز ظاهري باستخدام: 

New-AzRouteConfig -Name "StorageRoute" -AddressPrefix "Storage" -NextHopType "VirtualAppliance" -NextHopIpAddress "10.0.100.4"

سيكون نفس الأمر لـ CLI هو: 

az network route-table route create -g MyResourceGroup --route-table-name MyRouteTable -n StorageRoute --address-prefix Storage --next-hop-type VirtualAppliance --next-hop-ip-address 10.0.100.4

المشكلات المعروفة (أبريل 2021)

عند وجود توجيهات BGP أو عند تكوين Service Endpoint على الشبكة الفرعية، قد لا تُقيَّم التوجيهات بالأولوية الصحيحة. هذه الميزة لا تعمل حالياً للشبكات الظاهرية ذات المكدس المزدوج (IPv4+IPv6). يتم العمل حالياً على تصحيح لهذه السيناريوهات

ملاحظة

أثناء المعاينة العامة، توجد العديد من القيود. الميزة غير مدعمة حالياً في مدخل Azure ولا تتوفر إلا من خلال PowerShell وCLI. لا يتوفر الدعم للاستخدام مع الحاويات.

أنواع الوثب التالي عبر أدوات Azure

يختلف الاسم المعروض والمشار إليه لأنواع الوثب التالي بين مدخل Azure وأدوات سطر الأوامر، وAzure Resource Manager ونماذج التوزيع الكلاسيكية. يوضح الجدول التالي الأسماء المستخدمة للإشارة إلى كل نوع وثب تالٍ باستخدام الأدوات ونماذج التوزيع المختلفة:

نوع الوثب التالي Azure CLI وPowerShell (Resource Manager) Azure CLI الكلاسيكي وPowerShell (كلاسيكي)
بوابة الشبكة الظاهرية VirtualNetworkGateway VPNGateway
شبكة ظاهرية VNetLocal VNETLocal (غير متوفر في CLI الكلاسيكي في وضع asm)
الإنترنت الإنترنت Internet (غير متوفر في CLI الكلاسيكي في وضع asm)
جهاز ظاهري VirtualAppliance VirtualAppliance
بلا بلا Null (غير متوفر في CLI الكلاسيكي في وضع asm)
نظير الشبكة الظاهرية الإقران بين الشبكات الظاهرية غير قابل للتطبيق
نقطة نهاية خدمة الشبكة الظاهرية VirtualNetworkServiceEndpoint غير قابل للتطبيق

بروتوكول بوابة الحدود (BGP)

يمكن لبوابة الشبكة المحلية تبديل التوجيهات مع بوابة شبكة Azure الظاهرية باستخدام بروتوكول بوابة الحدود (BGP). يعتمد استخدام BGP مع بوابة شبكة Azure الظاهرية على النوع الذي حددته عند إنشاء البوابة. إذا كان النوع الذي حددته:

  • ExpressRoute: يجب عليك استخدام BGP للإعلان عن التوجيهات المحلية إلى جهاز التوجيه Microsoft Edge. لا يمكنك إنشاء توجيهات مُعرّفة من قبل المستخدم لفرض نقل البيانات إلى بوابة الشبكة الظاهرية ExpressRoute إذا قمت بتوزيع بوابة شبكة ظاهرية تم توزيعها كنوع: ExpressRoute. يمكنك استخدام توجيهات مُعرّفة من قبل المستخدم لفرض نقل البيانات من Express Route إلى، على سبيل المثال، Network Virtual Appliance.
  • VPN: يمكنك اختيارياً استخدام BGP. للحصول على التفاصيل، راجع BGP مع اتصالات VPN بين موقعين.

عند تبديل التوجيهات مع Azure باستخدام BGP، يُضاف توجيه منفصل إلى جدول التوجيه لكل الشبكات الفرعية في الشبكة الظاهرية لكل بادئة مُعلن عنها. يُضاف التوجيه مع بوابة الشبكة الظاهرية المدرجة كمصدر ونوع الوثب التالي.

يمكن تعطيل نشر توجيه ER وVPN Gateway على شبكة فرعية باستخدام خاصية على جدول توجيه. عند فعل ذلك، لن تُضاف التوجيهات إلى جدول التوجيه لكل الشبكات الفرعية عندما يكون نشر التوجيه لبوابة الشبكة الظاهرية معطلاً (كل من التوجيهات الثابتة وتوجيهات BGP). ينجح الاتصال لاتصالات VPN باستخدام توجيهات مخصصة مع نوع الوثب التالي Virtual network gateway. يجب ألا يتم تعطيل نشر التوجيه على GatewaySubnet. لن تعمل البوابة عندما يكون هذا الإعداد معطلاً. للحصول على التفاصيل، راجع كيفية تعطيل نشر التوجيه لبوابة الشبكة الظاهرية.

كيفية تحديد Azure لمسار

عند إرسال نقل البيانات الصادر من شبكة فرعية، يحدد Azure توجيهاً بناءً على عنوان IP الوجهة، باستخدام أطول خوارزمية مطابقة للبادئة. على سبيل المثال، يحتوي جدول التوجيه على توجيهين، أحدهما يحدد بادئة العنوان 10.0.0.0/24، في حين يحدد الآخر بادئة العنوان 10.0.0.0/16. يوجّه Azure نقل البيانات الموجَّه لـ 10.0.0.5، إلى نوع الوثب التالي المحدد في المسار ببادئة العنوان 10.0.0.0/24، لأن 10.0.0.0/24 بادئة أطول من 10.0.0.0/16، حتى وإن كانت 10.0.0.5 ضمن بادئات العناوين. يوجّه Azure نقل البيانات المُوجَّه إلى 10.0.1.5، إلى نوع الوثب التالي المحدد في التوجيه باستخدام بادئة العنوان 10.0.0.0/16؛ لأن 10.0.1.5 غير مضمن في بادئة العنوان 10.0.0.0/24، وبالتالي فإن التوجيه الذي له بادئة العنوان 10.0.0.0/16 هو أطول بادئة مطابقة.

إذا احتوت توجيهات متعددة على نفس بادئة العنوان، فسيحدد Azure نوع التوجيه، استناداً إلى الأولوية التالية:

  1. مسارات محددة من قِبل المستخدم
  2. توجيه BGP
  3. مسار النظام

ملاحظة

توجيهات النظام لنقل البيانات المرتبطة بالشبكة الظاهرية أو نظائر الشبكة الظاهرية أو نقاط تقديم خدمة الشبكة الظاهرية توجيهات مفضلة، حتى وإن كانت توجيهات BGP أكثر تحديداً.

على سبيل المثال، يحتوي جدول التوجيه على المسارات التالية:

المصدر بادئات العناوين نوع الوثب التالي
افتراضي 0.0.0.0/0 الإنترنت
المستخدم 0.0.0.0/0 بوابة الشبكة الظاهرية

عندما يتم توجيه نقل البيانات إلى عنوان IP خارج بادئات العناوين لأي توجيهات أخرى في جدول التوجيه، يحدد Azure التوجيه باستخدام المصدر User، لأن التوجيهات المُعرّفة من قبل المستخدم تكون ذات أولوية أعلى من التوجيهات الافتراضية للنظام.

راجع Routing example للاطلاع على جدول التوجيه الشامل مع تفسيرات للمسارات في الجدول.

0.0.0.0/0 بادئة العنوان

يوجِّه أي مسار ببادئة العنوان 0.0.0.0/0 Azure إلى كيفية توجيه نقل البيانات الموجَّه إلى عنوان IP غير موجود ضمن بادئة العنوان لأي توجيه آخر في جدول توجيه الشبكة الفرعية. عند إنشاء شبكة فرعية، ينشئ Azure توجيهاً افتراضياً إلى بادئة العنوان 0.0.0.0/0، بتعيين نوع الوثب التالي على Internet. إذا لم تتجاوز هذا التوجيه، فسيوجِّه Azure نقل البيانات الموجَّه بالكامل إلى عناوين IP غير المضمنة في بادئة العنوان لأي توجيه آخر، إلى Internet. الاستثناء هو أن نقل البيانات إلى عناوين IP العامة لخدمات Azure يبقى على شبكة تجميع Azure، ولا يتم توجيهه إلى Internet. إذا تجاوزت هذا التوجيه، باستخدام توجيه مخصص، فسيتم إرسال نقل البيانات الموجَّه إلى عناوين ليست ضمن بادئات العناوين لأي توجيه آخر في جدول التوجيه إلى جهاز شبكة ظاهرية أو بوابة شبكة ظاهرية، بناءً على ما تحدده في المسار المخصص الواحد.

عند تجاوز بادئة العنوان 0.0.0.0/0، بالإضافة إلى نقل البيانات الصادر من الشبكة الفرعية المتدفقة عبر بوابة الشبكة الظاهرية أو الجهاز الظاهري، تحدث التغييرات التالية مع التوجيه الافتراضي لـ Azure:

  • يرسل Azure نقل البيانات بالكامل إلى نوع الوثب التالي المحدد في التوجيه، بما في ذلك نقل البيانات الموجَّه لعناوين IP العامة لخدمات Azure. عندما يكون نوع الوثب التالي للتوجيه الذي له بادئة العنوان 0.0.0.0/0 هو Internet، فإن نقل البيانات من الشبكة الفرعية الموجَّهة إلى عناوين IP العامة لخدمات Azure لا تغادر أبدًا شبكة تجميع Azure، بغض النظر عن منطقة Azure التي توجد فيها الشبكة الظاهرية أو مورد خدمة Azure. عند إنشاء توجيه معرّف من قبل المستخدم أو توجيه BGP باستخدام بوابة الشبكة الظاهرية أو نوع الوثب التالي لـ الجهاز الظاهري، يتم إرسال نسبة استخدام الشبكة بالكامل، بما في ذلك نسبة استخدام الشبكة المرسلة إلى عناوين IP العامة لخدمات Azure، والتي لم تقم بتمكين نقاط تقديم الخدمة لها، إلى نوع الوثب التالي المحدد في التوجيه. إذا قمت بتمكين نقطة تقديم الخدمة لإحدى الخدمات، فلن يتم توجيه نسبة استخدام الشبكة إلى نوع الوثب التالي في توجيه ببادئة العنوان 0.0.0.0/0، لأن بادئات عناوين الخدمة محددة في التوجيه الذي ينشئه Azure عند تمكين نقطة تقديم الخدمة، وبادئات عناوين الخدمة أطول من 0.0.0.0/0.

  • لم تعد قادراً على الوصول مباشرة إلى الموارد في الشبكة الفرعية من Internet. يمكنك الوصول بشكل غير مباشر إلى الموارد الموجودة في الشبكة الفرعية من الإنترنت، إذا مر نقل البيانات الوارد عبر الجهاز المحدد بواسطة نوع الوثب التالي لمسار يتضمن بادئة العنوان 0.0.0.0/0 قبل الوصول إلى المورد في الشبكة الظاهرية. إذا كان التوجيه يحتوي على القيم التالية لنوع الوثب التالي:

    • Virtual appliance: يجب أن يكون الجهاز:

      • قابلاً للوصول إليه من Internet
      • مُعيّن له عنوان IP عام،
      • لا ترتبط به قاعدة مجموعة أمان شبكة تمنع الاتصال بالجهاز
      • لا يرفض الاتصال
      • أن تكون قادراً على تحويل عنوان الشبكة وإعادة توجيه أو استخدام وكيل لتوجيه نقل البيانات إلى المورد الوجهة في الشبكة الفرعية، وإعادة نقل البيانات مرة أخرى إلى Internet.

    • بوابة الشبكة الظاهرية: إذا كانت البوابة بوابة شبكة ExpressRoute ظاهرية، فيمكن لجهاز متصل بالإنترنت محلياً تحويل عنوان الشبكة وإعادة توجيه، أو استخدام وكيل لتوجيه نقل البيانات إلى مورد الوجهة في الشبكة الفرعية، عبر النظير الخاص لـ ExpressRoute.

إذا كانت شبكتك الظاهرية متصلة ببوابة Azure VPN، فلا تربط جدول التوجيه بـ الشبكة الفرعية للبوابة التي تتضمن مساراً بالوجهة 0.0.0.0/0. يمكن لذلك منع البوابة من العمل بشكل صحيح. للحصول على التفاصيل، راجع السؤال لماذا يتم فتح منافذ معينة على بوابة VPN؟ في VPN Gateway FAQ.

راجع DMZ بين Azure ومركز البيانات المحلي للحصول على تفاصيل التنفيذ عند استخدام بوابات الشبكة الظاهرية بين Internet وAzure.

مثال التوجيه

لتوضيح المفاهيم في هذه المقالة، توضح المقاطع التالية التي:

  • سيناريو، مع المتطلبات
  • التوجيهات المخصصة اللازمة لتلبية المتطلبات
  • جدول التوجيه الموجود لشبكة فرعية واحدة تتضمن التوجيهات الافتراضية والمخصصة اللازمة لتلبية المتطلبات

ملاحظة

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

المتطلبات

  1. تنفيذ شبكتين ظاهريتين في نفس منطقة Azure وتمكين الموارد للاتصال بين الشبكات الظاهرية.

  2. تمكين شبكة محلية من الاتصال بأمان مع الشبكتين الظاهريتين عبر نفق VPN عبر Internet. أو بدلاً من ذلك، يمكن استخدام اتصال ExpressRoute، ولكن في هذا المثال، يستخدم اتصال VPN.

  3. لشبكة فرعية واحدة في شبكة ظاهرية واحدة:

    • فرض تدفق نقل البيانات الصادر بالكامل من الشبكة الفرعية، باستثناء تلك الموجَّهة إلى Azure Storage وداخل الشبكة الفرعية، عبر جهاز ظاهري لشبكة للفحص والتسجيل.
    • عدم فحص نقل البيانات بين عناوين IP الخاصة داخل الشبكة الفرعية، والسماح لنقل البيانات بالتدفق مباشرة بين جميع الموارد.
    • إفلات أي نسبة استخدام شبكة صادرة موجَّهة إلى شبكة ظاهرية أخرى.
    • تمكين نقل البيانات الصادر إلى Azure storage من التدفق مباشرة إلى التخزين دون فرض ذلك من خلال جهاز ظاهري لشبكة.

  4. السماح لنقل البيانات بالكامل بين جميع الشبكات الفرعية والشبكات الظاهرية الأخرى.

التنفيذ

توضح الصورة التالية تطبيقاً من خلال نموذج توزيع Azure Resource Manager الذي يفي بالمتطلبات السابقة:

Network diagram

أسهم تُظهر تدفق نقل البيانات.

⁧⁩جداول التوجيه⁧⁩

Subnet1

يحتوي جدول التوجيه Subnet1 في الصورة على المسارات التالية:

المعرف المصدر الحالة بادئات العناوين نوع الوثب التالي عنوان IP الوثب التالي اسم المسار المُعرّف من قبل المستخدم
1 افتراضي غير صالح 10.0.0.0/16 شبكة ظاهرية
2 المستخدم نشط 10.0.0.0/16 جهاز ظاهري 10.0.100.4 Within-VNet1
3 المستخدم نشط 10.0.0.0/24 شبكة ظاهرية Within-Subnet1
4 افتراضي غير صالح 10.1.0.0/16 الإقران بين الشبكات الظاهرية
5 افتراضي غير صالح 10.2.0.0/16 الإقران بين الشبكات الظاهرية
6 المستخدم نشط 10.1.0.0/16 بلا ToVNet2-1-Drop
7 المستخدم نشط 10.2.0.0/16 بلا ToVNet2-2-Drop
8 افتراضي غير صالح ⁧⁩10.10.0.0/16⁧⁩ بوابة الشبكة الظاهرية [X.X.X.X]
9 المستخدم نشط ⁧⁩10.10.0.0/16⁧⁩ جهاز ظاهري 10.0.100.4 To-On-Prem
10 افتراضي نشط [X.X.X.X] VirtualNetworkServiceEndpoint
11 افتراضي غير صالح 0.0.0.0/0 الإنترنت
12 المستخدم نشط 0.0.0.0/0 جهاز ظاهري 10.0.100.4 Default-NVA

فيما يلي شرح لكل مُعرّف توجيه:

  1. أضاف Azure هذا المسار تلقائياً لجميع الشبكات الفرعية داخل Virtual-network-1، لأن 10.0.0.0/16 نطاق العناوين الوحيد المحدد في مساحة العنوان للشبكة الظاهرية. إذا لم يتم إنشاء المسار المُعرّف من قبل المستخدم في المسار ID2، فسيتم توجيه نقل البيانات المرسل إلى أي عنوان بين 10.0.0.1 و10.0.255.254 داخل الشبكة الظاهرية، لأن البادئة أطول من 0.0.0.0/0، وليست ضمن بادئات العناوين لأي من المسارات الأخرى. قام Azure بتغيير الحالة تلقائياً من Active إلى Invalid، عندما أُضيف ID2، وهو مسار مُعرّف من قبل المستخدم، لأنه يحتوي على نفس بادئة المسار الافتراضي، والمسارات المُعرّفة من قبل المستخدم تتجاوز المسارات الافتراضية. لا تزال حالة هذا التوجيه Active لـ Subnet2، لأن جدول التوجيه الذي يعرّفه المستخدم، والذي يتضمن ID2، غير مقترن بـ Subnet2.
  2. أضاف Azure هذا المسار عندما تم إقران مسار مُعرّف من قبل المستخدم لبادئة العنوان 10.0.0.0/16 بالشبكة الفرعية Subnet1 في الشبكة الظاهرية Virtual-network-1. يحدد المسار المُعرّف من قبل المستخدم 10.0.100.4 كعنوان IP للجهاز الظاهري، لأن العنوان هو عنوان IP خاص معيّن للجهاز الظاهري. جدول التوجيه حيث يوجد هذا المسار غير مقترن بـ Subnet2، لذلك لا يظهر في جدول التوجيه لـ Subnet2. يعمل هذا المسار على تجاوز المسار الافتراضي للبادئة 10.0.0.0/16 (ID1)، التي تؤدي إلى التوجيه التلقائي لنقل البيانات الموجَّه إلى 10.0.0.1 و10.0.255.254 داخل الشبكة الظاهرية من خلال نوع الوثب التالي للشبكة الظاهرية. يوجد هذا المسار لتلبية المطلب 3، لفرض نقل البيانات الصادر بالكامل من خلال جهاز ظاهري.
  3. أضاف Azure هذا المسار عندما تم إقران مسار مُعرّف من قبل المستخدم لبادئة العنوان 10.0.0.0/24 بالشبكة الفرعية Subnet1. يظل نقل البيانات الموجهة للعناوين بين 10.0.0.1 و10.0.0.254 داخل الشبكة الفرعية، بدلاً من توجيهه إلى الجهاز الظاهري المحدد في القاعدة السابقة (ID2)، لأن له بادئة أطول من مسار ID2. لم يكن هذا المسار مقترناً بـ Subnet2، لذلك لا يظهر المسار في جدول التوجيه لـ Subnet2. يتجاوز هذا المسار بفعالية توجيه ID2 لنقل البيانات داخل Subnet1. يوجد هذا المسار لتلبية المطلب 3.
  4. أضاف Azure تلقائياً التوجيهات إلى المُعرّفين 4 و5 لجميع الشبكات الفرعية داخل Virtual-network-1، عندما تم إقران الشبكة الظاهرية بـ Virtual-network-2.Virtual-network-2 لها نطاقي عناوين في مساحة العناوين الخاصة بها: 10.1.0.0/16 و10.2.0.0/16، لذلك أضاف Azure توجيهاً لكل نطاق. إذا لم يتم إنشاء التوجيهات المعرّفة من قبل المستخدم في معرّفي التوجيه 6 و7، فسيتم توجيه نقل البيانات المرسَل إلى أي عنوان بين 10.1.0.1-10.1.255.254 و10.2.0.1-10.2.255.254 إلى الشبكة الظاهرية النظير، لأن البادئة أطول من 0.0.0.0/0، وليست ضمن بادئات عناوين أي من التوجيهات الأخرى. قام Azure بتغيير الحالة تلقائياً من Active إلى Invalid، عندما أُضيفت المسارات في المُعرّفين 6 و7؛ وذلك لأن لها نفس البادئات مثل المسارات في المُعرّفين 4 و5، ولأن المسارات المعرّفة من قبل المستخدم تتجاوز المسارات الافتراضية. لا تزال حالة المسارات في المُعرفين 4 و5 Active لـ Subnet2، لأن جدول التوجيه حيث توجد المسارات المُعرّفة من قبل المستخدم في المعرفين 6 و7 غير مقترن بـ Subnet2. تم إنشاء نظير شبكة ظاهرية لتلبية المطلب 1.
  5. نفس تفسير ID4.
  6. أضاف Azure هذا المسار والمسار في ID7، عندما تم إقران المسارات المُعرّفة من قبل المستخدم لبادئات العناوين 10.1.0.0/16 و10.2.0.0/16 بالشبكة الفرعية Subnet1. يفلت Azure نقل البيانات الموجَّه للعناوين بين 10.1.0.1-10.1.255.254 و10.2.0.1-10.2.255.254 بدلاً من توجيهها إلى الشبكة الظاهرية النظيرة، لأن المسارات المعرّفة من قبل المستخدم تتجاوز المسارات الافتراضية. لم يقترن هذا المسار بـ Subnet2، لذلك لا تظهر المسارات في جدول التوجيه لـ Subnet2. تتجاوز التوجيهات مسارات ID4 وID5 لنقل البيانات التي تغادر Subnet1. توجد مسارات ID6 وID7 لتلبية المطلب 3 لإفلات نقل البيانات الموجَّه إلى الشبكة الظاهرية الأخرى.
  7. نفس تفسير ID6.
  8. أضاف Azure هذا المسار تلقائياً لجميع الشبكات الفرعية داخل Virtual-network-1 عند إنشاء بوابة شبكة ظاهرية من نوع VPN داخل الشبكة الظاهرية. أضاف Azure عنوان IP العام لبوابة الشبكة الظاهرية إلى جدول التوجيه. يتم توجيه نقل البيانات المرسَل إلى أي عنوان بين 10.10.0.1 و10.10.255.254 إلى بوابة الشبكة الظاهرية. البادئة أطول من 0.0.0.0/0 وليست ضمن بادئات العناوين لأي من التوجيهات الأخرى. تم إنشاء بوابة شبكة ظاهرية لتلبية المطلب 2.
  9. أضاف Azure هذا المسار عندما أُضيف مسار مُعرّف من قبل المستخدم لبادئة العنوان 10.10.0.0/16 إلى جدول التوجيه المقترن بالشبكة الفرعية Subnet1. يتجاوز هذا المسار ID8. يرسل التوجيه نقل البيانات الموجَّه إلى الشبكة المحلية بالكامل إلى فحص NVA، بدلاً من توجيه نقل البيانات محلياً مباشرة. تم إنشاء هذا المسار لتلبية المطلب 3.
  10. أضاف Azure هذا التوجيه تلقائياً إلى الشبكة الفرعية عند تمكين نقطة تقديم خدمة لخدمة Azure للشبكة الفرعية. يوجِّه Azure نقل البيانات من الشبكة الفرعية إلى عنوان IP عام للخدمة، عبر شبكة البنية الأساسية لـ Azure. البادئة أطول من 0.0.0.0/0 وليست ضمن بادئات العناوين لأي من التوجيهات الأخرى. تم إنشاء نقطة تقديم خدمة لتلبية المتطلب 3، لتمكين نقل البيانات الموجَّه إلى Azure Storage من التدفق مباشرة إلى Azure Storage.
  11. أضاف Azure هذا المسار تلقائياً إلى جدول التوجيه لجميع الشبكات الفرعية داخل Virtual-network-1 وVirtual-network-2. بادئة العنوان 0.0.0.0/0 هي أقصر بادئة. يتم توجيه أي نسبة استخدام شبكة مرسلة إلى عناوين ضمن بادئة عنوان طويلة استناداً إلى التوجيهات الأخرى. بشكل افتراضي، يوجِّه Azure نقل البيانات الموجَّهة إلى عناوين أخرى غير العناوين المحددة في أحد التوجيهات الأخرى بالكامل إلى Internet. قام Azure بتغيير الحالة تلقائياً من Active إلى Invalid للشبكة الفرعية Subnet1 عندما تم إقران مسار مُعرّف من قبل المستخدم لبادئة العنوان 0.0.0.0/0 (ID12) بالشبكة الفرعية. لا تزال حالة هذا التوجيه Active لجميع الشبكات الفرعية الأخرى داخل كلتا الشبكتين الظاهريتين، لأن التوجيه غير مرتبط بأي شبكات فرعية أخرى داخل أي شبكات ظاهرية أخرى.
  12. أضاف Azure هذا المسار عندما تم إقران مسار مُعرّف من قبل المستخدم لبادئة العنوان 0.0.0.0/0 بالشبكة الفرعية Subnet1. يحدد المسار المُعرّف من قبل المستخدم 10.0.100.4 كعنوان IP للجهاز الظاهري. لم يكن هذا المسار مقترناً بـ Subnet2، لذلك لا يظهر المسار في جدول التوجيه لـ Subnet2. يُرسل نقل البيانات لأي عنوان غير مدرج في بادئات العناوين لأي من التوجيهات الأخرى بالكامل إلى الجهاز الظاهري. أدت إضافة هذا المسار إلى تغيير حالة المسار الافتراضي لبادئة العنوان 0.0.0.0/0 (ID11) من Active إلى Invalid لـ Subnet1، لأن المسار المُعرّف من قبل المستخدم يتجاوز مساراً افتراضياً. يوجد هذا المسار لتلبية المطلب الثالث.

Subnet2

يحتوي جدول التوجيه لـ Subnet2 في الصورة على المسارات التالية:

المصدر الحالة بادئات العناوين نوع الوثب التالي عنوان IP الوثب التالي
افتراضي نشط 10.0.0.0/16 شبكة ظاهرية
افتراضي نشط 10.1.0.0/16 الإقران بين الشبكات الظاهرية
افتراضي نشط 10.2.0.0/16 الإقران بين الشبكات الظاهرية
افتراضي نشط ⁧⁩10.10.0.0/16⁧⁩ بوابة الشبكة الظاهرية [X.X.X.X]
افتراضي نشط 0.0.0.0/0 الإنترنت
افتراضي نشط 10.0.0.0/8 بلا
افتراضي نشط 100.64.0.0/10 بلا
افتراضي نشط 192.168.0.0/16 بلا

يحتوي جدول التوجيه لـ Subnet2 على جميع المسارات الافتراضية التي أنشأها Azure والمسارات الاختيارية لبوابة الشبكة الظاهرية ونظير VNet الاختياري. أضاف Azure المسارات الاختيارية إلى كل الشبكات الفرعية في الشبكة الظاهرية عند إضافة البوابة والنظير إلى الشبكة الظاهرية. أزال Azure مسارات بادئات العناوين 10.0.0.0/8 و192.168.0.0/16 و100.64.0.0/10 من جدول توجيه Subnet1 عند إضافة المسار المُعرّف من قبل المستخدم لبادئة العنوان 0.0.0.0/0 إلى Subnet1.

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