تناظر VNet ونقاط نهاية الخدمات

لا يمكن للموارد الموجودة في VNets مختلفة في Azure التواصل مع بعضها افتراضيًا، حتى لو كانت في منطقة Azure نفسها. ومع ذلك، غالبًا ما تمتلك المؤسسات الكبيرة عدة VNets: شبكات منفصلة للتطوير والاختبار المرحلي والإنتاج، أو شبكات مختلفة للأقسام المختلفة. يربط VNet Peering بين شبكتي VNet مباشرةً عبر شبكة Microsoft الخاصة الأساسية، ما يتيح للموارد في كلتا الشبكتين التواصل كما لو كانت في الشبكة نفسها، من دون عبور أي حركة مرور عبر الإنترنت العام أو الحاجة إلى VPN gateway.

يُعد VNet Peering اتصالًا غير انتقالي: فإذا كانت VNet A مقترنة بـ VNet B، وكانت VNet B مقترنة بـ VNet C، فلن تتمكن VNet A من الاتصال بـ VNet C ما لم تنشئوا اقترانًا منفصلًا بين A وC. وتكون روابط الاقتران ثنائية الاتجاه، لكن يجب إعدادها على كلا الجانبين؛ إذ لا يؤدي إنشاء اقتران من A إلى B تلقائيًا إلى إنشاء اقتران من B إلى A. وبعد إعداد الجانبين، تستخدم حركة المرور بين VNets المقترنتين Azure backbone بزمن انتقال منخفض ونطاق ترددي عالٍ، بما يشبه الاتصال بين الشبكات الفرعية داخل VNet واحدة.

يحتوي تناظر VNet على خيارين لنطاق الاتصال: يربط تناظر VNet المحلي بين شبكتي VNet في منطقة Azure نفسها. وتبقى حركة المرور داخل المنطقة، مع فرض رسم صغير على كل جيجابايت من البيانات المنقولة. أما تناظر VNet العالمي فيربط بين شبكتي VNet في منطقتين مختلفتين من Azure، وتُوجَّه حركة المرور عبر العمود الفقري العالمي لـ Microsoft. ويتيح ذلك للموارد في East US الاتصال بشكل خاص بالموارد في West Europe من دون المرور عبر الإنترنت العام. وتكلفة نقل البيانات عبر التناظر العالمي أعلى قليلًا من التناظر المحلي، لكنها تظل أقل بكثير وأكثر موثوقية من التوجيه عبر VPN.

يستخدم نمط شائع في المؤسسات تناظر VNet لتنفيذ طوبولوجيا المحور والأطراف. وتستضيف شبكة VNet مركزية تُسمى المحور خدمات مشتركة، مثل Azure Firewall وVPN Gateway وخوادم DNS والمراقبة. وترتبط عدة شبكات VNet تُسمى الأطراف — واحدة لكل بيئة أو حمل عمل — بالمحور من خلال التناظر. ومن خلال توجيه كل حركة مرور الأطراف عبر جدار حماية المحور، تحصل المؤسسة على فحص أمني مركزي من دون إدارة معقدة لـ NSG في كل طرف. ونظرًا إلى أن التناظر غير انتقالي، يوجّه جدار حماية المحور حركة المرور بين الأطراف باستخدام User-Defined Routes (UDRs).

يتطلب تناظر VNet شرطًا مهمًا واحدًا: يجب ألا تتداخل مساحات عناوين شبكات VNet المتناظرة. فإذا كانت VNet A تستخدم 10.0.0.0/16 وكانت VNet B تستخدم 10.0.0.0/16 أيضًا، يفشل التناظر لأن Azure لا يستطيع توجيه حركة المرور بين نطاقات عناوين متطابقة. ولهذا من المهم جدًا التخطيط لنطاقات CIDR غير المتداخلة لجميع شبكات VNet — وكذلك للشبكات المحلية — قبل البدء. ويتطلب تغيير مساحة عناوين VNet بعد نشر الموارد إعادة إنشاء VNet أو استخدام ميزة إضافة/إزالة مساحة العناوين (المحدودة).

تعمل نقاط نهاية الخدمة على توسيع هوية VNet لتشمل خدمات Azure PaaS مثل Azure Storage وAzure SQL Database وAzure Key Vault وCosmos DB. عند تمكين نقطة نهاية خدمة على شبكة فرعية، تُوجَّه حركة المرور من الموارد الموجودة في تلك الشبكة الفرعية إلى خدمة Azure المحددة عبر العمود الفقري لـ Azure بدلًا من الإنترنت العام — حتى عند استخدام عنوان IP العام للخدمة. ويمكن للخدمة بعد ذلك تقييد الوصول ليقتصر على الموارد الموجودة داخل شبكات VNet التي تم تمكين نقطة نهاية الخدمة فيها، مما يوفر تحسينًا أمنيًا ملحوظًا مقارنة بنقاط النهاية التي يمكن الوصول إليها عبر الإنترنت.

توفر نقاط نهاية الخدمة ونقاط النهاية الخاصة وصولًا آمنًا إلى خدمات Azure PaaS، لكنهما تعملان بشكل مختلف: نقطة نهاية الخدمة — توجّه حركة المرور عبر العمود الفقري لـ Azure، لكنها تظل تستخدم عنوان IP العام للخدمة؛ وتوجد نقطة نهاية الخدمة على مستوى الشبكة الفرعية. نقطة النهاية الخاصة — تخصص للخدمة عنوان IP خاصًا من VNet الخاصة بك؛ ويمكن تعطيل نقطة النهاية العامة بالكامل، مما يجعل الخدمة خاصة فعلًا. كما يمكن الوصول إلى نقاط النهاية الخاصة من الشبكات المحلية عبر VPN/ExpressRoute. ولتحقيق أعلى مستوى من الأمان، يُفضّل استخدام نقاط النهاية الخاصة؛ أما نقاط نهاية الخدمة فهي بديل أبسط وأقل تكلفة.

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

يتيح تكامل VNet، وهو مختلف عن تناظر VNet، لتطبيقات Azure App Service إجراء اتصالات صادرة بالموارد الموجودة داخل VNet. ومن دون تكامل VNet، تخرج حركة المرور الصادرة من App Service دائمًا عبر الإنترنت العام، حتى عند الاتصال بموارد مثل Azure SQL أو Azure Cache for Redis الموجودة في VNet نفسها. وعند تمكين تكامل VNet، تُوجَّه حركة المرور الصادرة من التطبيق إلى داخل VNet، ويمكنها الوصول إلى الموارد الخاصة. ويتطلب ذلك وجود شبكة فرعية مفوَّضة مخصصة داخل VNet بمساحة عناوين لا تقل عن /28.

نظرًا إلى أن تناظر VNet غير انتقالي، فإن ربط أكثر من شبكتي VNet يتطلب إما إنشاء تناظر مباشر بين كل زوج (بتعقيد O(n²)) أو استخدام محور توجيه مركزي. وفي نموذج المحور والأطراف، تحتوي VNet الخاصة بالمحور على Network Virtual Appliance (NVA) أو Azure Firewall يعمل بوصفه موجّهًا انتقاليًا بين شبكات VNet الطرفية. وتضيف كل شبكة طرفية UDR يوجّه كل حركة المرور (0.0.0.0/0 أو إلى نطاقات CIDR محددة للأطراف) إلى عنوان IP الخاص بـ NVA في المحور. ثم يعيد NVA توجيه حركة المرور إلى الشبكة الطرفية الصحيحة، موفرًا بذلك اتصالًا انتقاليًا عبر المحور.

القيود الأساسية لتناظر VNet: يلزم استخدام مساحات عناوين غير متداخلة — خطط نطاقات CIDR بعناية قبل إنشاء شبكات VNet. غير انتقالي — لا يؤدي إنشاء تناظر بين A وB وبين B وC إلى ربط A وC. لا يمكن تغيير حجم مساحة عناوين VNet إذا كانت تحتوي على عمليات تناظر نشطة من دون حذفها مؤقتًا. انتقال البوابة — يمكن لشبكات VNet الطرفية استخدام بوابة VPN أو ExpressRoute الموجودة في VNet الخاصة بالمحور من خلال تمكين الخيار 'Use Remote Gateways' في إعدادات التناظر، لكن ذلك يتطلب إنشاء بوابة المحور أولًا. ومن المهم فهم هذه القيود لتصميم بنيات متعددة لشبكات VNet قابلة للتوسع وسهلة الصيانة.

اختبر مدى فهمك لمفاهيم Microsoft Azure Fundamentals (AZ-900) الواردة في هذا الدرس.

تعلمت في هذا الدرس أن: تناظر VNet يربط بين شبكتي VNet عبر العمود الفقري لـ Microsoft لتوفير اتصال خاص منخفض زمن الاستجابة من دون VPN، لكن التناظر غير انتقالي، وأن نقاط نهاية الخدمة توجّه حركة مرور الشبكة الفرعية إلى خدمات Azure PaaS عبر العمود الفقري من دون تعريضها للإنترنت العام، وأن نقاط النهاية الخاصة هي البديل الأقوى الذي يخصص عنوان IP خاصًا لخدمة PaaS، مما يتيح تعطيل نقطة النهاية العامة بالكامل. في القسم التالي سنتعرف على أساسيات Azure DNS وLoad Balancer.