سيناريو منطقة واحدة - Private Link وDNS في Azure Virtual WAN

توضح هذه المقالة كيفية عرض مورد PaaS عبر نقطة نهاية خاصة لحمل عمل معين في منطقة واحدة. في السيناريو، طوبولوجيا الشبكة هي hub-spoke، والمركز هو مركز Azure Virtual WAN.

السيناريو

الشكل 1: سيناريو منطقة واحدة ل Virtual WAN مع Private Link وAzure DNS - التحدي

نزّل ملف Visio لهذه البنية. يحدد هذا القسم السيناريو ويعيد تعريف التحدي لهذا السيناريو (التحدي هو نفس المثال غير المتعلق بالعمل في صفحة النظرة العامة). تعتمد بنية السيناريو الأولي على مخطط شبكة البدء المحدد في دليل النظرة العامة. فيما يلي الإضافات والتغييرات:

• هناك منطقة واحدة فقط مع مركز ظاهري واحد.
• يوجد حساب Azure Storage في المنطقة التي تم تعطيل الوصول إلى الشبكة العامة فيها. الافتراض في هذا السيناريو هو أن حمل عمل واحد فقط يصل إلى حساب التخزين.
• هناك في البداية شبكة ظاهرية واحدة متصلة بالمركز الظاهري.
• تحتوي الشبكة الظاهرية على شبكة فرعية لحمل العمل تحتوي على عميل جهاز ظاهري (VM).
• تحتوي الشبكة الظاهرية على شبكة فرعية خاصة بنقطة النهاية تحتوي على نقطة نهاية خاصة لحساب التخزين.

نتيجة ناجحة

يمكن لعميل Azure Virtual Machine الاتصال بحساب Azure Storage عبر نقطة النهاية الخاصة لحساب التخزين الموجودة في نفس الشبكة الظاهرية، ويتم حظر جميع الوصول الآخر إلى حساب التخزين.

عائقا

تحتاج إلى سجل DNS في تدفق DNS قادر على حل اسم المجال المؤهل بالكامل (FQDN) لحساب التخزين مرة أخرى إلى عنوان IP الخاص لنقطة النهاية الخاصة. كما هو محدد في النظرة العامة، فإن التحدي مع السيناريو ذو شقين:

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

نظرا لأنه لا يمكنك ربط منطقة DNS خاصة بمركز ظاهري، وتم تكوين الشبكة الظاهرية لاستخدام وكيل Azure Firewall DNS، لا تحتوي خوادم Azure DNS على أي آلية لحل (FQDN) لحساب التخزين إلى عنوان IP الخاص لنقطة النهاية الخاصة. والنتيجة هي أن العميل يتلقى استجابة DNS خاطئة.

تدفقات DNS وHTTP

دعونا نراجع DNS وتدفقات طلب HTTP الناتجة لحمل العمل هذا. يساعدنا الاستعراض على تصور العائق الذي تم وصفه سابقا.

الشكل 2: سيناريو منطقة واحدة ل Virtual WAN مع Private Link وAzure DNS - التحدي

قم بتنزيل ملف Visio لهذه البنية.

تدفق DNS

1. يتم إرسال استعلام DNS من stgworkload00.blob.core.windows.net العميل إلى خادم DNS المكون، وهو Azure Firewall في المركز الإقليمي المتناظر.
2. يقوم Azure Firewall بوكلاء الطلب إلى Azure DNS. نظرا لعدم إمكانية ربط منطقة DNS خاصة بمركز ظاهري، لا يعرف Azure DNS كيفية حل FQDN بعنوان IP الخاص بنقطة النهاية الخاصة. وهو يعرف كيفية حل FQDN إلى عنوان IP العام لحساب التخزين، لذلك يقوم بإرجاع عنوان IP العام لحساب التخزين.

تدفق HTTP

1. مع وجود نتيجة DNS في متناول اليد، عنوان IP العام لحساب التخزين، يصدر العميل طلب HTTP إلى stgworkload00.blob.core.windows.net.
2. يتم إرسال الطلب إلى عنوان IP العام لحساب التخزين. فشل هذا الطلب لأسباب عديدة:
   • قد لا تسمح NSG على الشبكة الفرعية لحمل العمل بنسبة استخدام الشبكة المرتبطة بالإنترنت.
   • من المحتمل ألا يحتوي جدار حماية Azure الذي يقوم بتصفية حركة الخروج المرتبطة بالإنترنت على قاعدة تطبيق لدعم هذا التدفق.
   • حتى إذا كان لدى كل من NSG وAzure Firewall بدلات لتدفق الطلب هذا، يتم تكوين حساب التخزين لمنع جميع الوصول إلى الشبكة العامة. في نهاية المطاف، تنتهك المحاولة هدفنا المتمثل في السماح فقط بالوصول إلى حساب التخزين عبر نقطة النهاية الخاصة.

الحل - إنشاء ملحق مركز ظاهري ل DNS

يتمثل حل التحدي في أن يقوم فريق شبكة المؤسسة بتنفيذ ملحق مركز ظاهري ل DNS. تتمثل المسؤولية الفردية لملحق مركز DNS الظاهري في تمكين فرق حمل العمل التي تحتاج إلى استخدام مناطق DNS الخاصة في بنيتها ضمن مخطط مركز شبكة WAN الظاهرية هذا.

يتم تنفيذ ملحق DNS كشبكة ظاهرية يتم تناظرها مع مركزها الظاهري الإقليمي. من الممكن ربط مناطق DNS الخاصة بهذه الشبكة الظاهرية. تحتوي الشبكة الظاهرية أيضا على Azure DNS Private Resolver الذي يمكن الخدمات خارج هذه الشبكة الظاهرية، مثل Azure Firewall، من الاستعلام عن القيم وتلقيها من جميع مناطق DNS الخاصة المرتبطة. فيما يلي مكونات ملحق المركز الظاهري النموذجي ل DNS، جنبا إلى جنب مع بعض تغييرات التكوين المطلوبة:

• شبكة ظاهرية محورية جديدة تتناظر مع المركز الظاهري للمنطقة. تم تكوين هذا المحور مثل أي محور آخر، ما يعني أن خادم DNS الافتراضي وقواعد التوجيه تفرض استخدام جدار حماية Azure في المركز الإقليمي.
• يتم نشر مورد محلل DNS خاص بنقطة نهاية واردة في الشبكة الظاهرية المحورية.
• يتم إنشاء مورد منطقة DNS خاص يسمى privatelink.blob.core.windows.net .
  • تحتوي هذه المنطقة على A سجل يعين من اسم FQDN لحساب التخزين إلى عنوان IP الخاص لنقطة النهاية الخاصة لحساب التخزين.
  • ترتبط منطقة DNS الخاصة بالشبكة الظاهرية المحورية.
  • إذا كان التحكم في الوصول استنادا إلى الدور (RBAC) يسمح بذلك، يمكنك استخدام التسجيل التلقائي أو الإدخالات المدارة بواسطة الخدمة للاحتفاظ بسجلات DNS هذه. إذا لم يكن الأمر كما هو، يمكنك الاحتفاظ بها يدويا.
• في المركز الإقليمي، يتم تغيير خادم DNS الخاص بجدار حماية Azure للإشارة إلى نقطة النهاية الواردة لمحلل DNS الخاص.

يوضح الرسم التخطيطي التالي البنية، جنبا إلى جنب مع كل من تدفقات DNS وHTTP.

الشكل 3: حل العمل لسيناريو منطقة واحدة ل Virtual WAN مع Private Link وDNS

قم بتنزيل ملف Visio لهذه البنية.

تدفق DNS لإنشاء ملحق مركز ظاهري ل DNS

1. يتم إرسال استعلام DNS من stgworkload00.blob.core.windows.net العميل إلى خادم DNS المكون، وهو Azure Firewall في المركز الإقليمي المتناظر - 10.100.0.132 في هذه الحالة.

   الشكل 4: تكوين خوادم DNS للشبكة الظاهرية لحمل العمل

2. يعمل Azure Firewall على دعم الطلب إلى محلل Azure DNS الخاص الإقليمي في ملحق المركز - 10.200.1.4 في هذه الحالة، وهو عنوان IP الخاص لنقطة النهاية الواردة ل DNS Private Resolver.

   

   لقطة شاشة لنهج Azure Firewall حيث يتم تمكين وكيل DNS وتعيين خوادم DNS إلى مخصص. يشير الإدخال إلى عنوان IP الخاص لنقطة نهاية إدخال DNS Private Resolver.

   الشكل 5: تكوين DNS في نهج جدار حماية Azure

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

   الشكل 6: ارتباطات الشبكة الظاهرية لمنطقة DNS الخاصة

4. يستشير Azure DNS منطقة DNS الخاصة المرتبطة ويحل FQDN من stgworkload00.blob.core.windows.net إلى 10.1.2.4، وهو عنوان IP لنقطة النهاية الخاصة لحساب التخزين. يتم توفير هذه الاستجابة إلى Azure Firewall DNS، الذي يقوم بعد ذلك بإرجاع عنوان IP الخاص بحساب التخزين إلى العميل.

   الشكل 7: منطقة DNS الخاصة مع سجل A لنقطة النهاية الخاصة لحساب التخزين

تدفق HTTP

1. مع وجود نتيجة DNS في متناول اليد، عنوان IP الخاص لحساب التخزين، يصدر العميل طلب HTTP إلى stgworkload00.blob.core.windows.net.
2. يتم إرسال الطلب إلى عنوان IP الخاص (10.1.2.4) لحساب التخزين. يوجه هذا الطلب بنجاح، مع افتراض عدم وجود قيود متعارضة على مجموعات أمان الشبكة المحلية على الشبكة الفرعية للعميل أو الشبكة الفرعية لنقطة النهاية الخاصة. من المهم أن نفهم أنه على الرغم من أن Azure Firewall يقوم بتأمين نسبة استخدام الشبكة الخاصة، لا يتم توجيه الطلب من خلال Azure Firewall لأن نقطة النهاية الخاصة في نفس الشبكة الظاهرية مثل العميل. مما يعني أنه لا يلزم إجراء بدلات جدار حماية Azure لهذا السيناريو.
3. يتم إنشاء اتصال خاص بحساب التخزين من خلال خدمة Private Link. يسمح حساب التخزين بالوصول إلى الشبكة الخاصة فقط، ويقبل طلب HTTP.

ملحق المركز الظاهري لاعتبارات DNS

عند تنفيذ الملحق لمؤسستك، ضع في اعتبارك الإرشادات التالية.

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

الشبكة الظاهرية المركزية

• باتباع مبدأ المسؤولية الفردية، يجب أن تحتوي الشبكة الظاهرية لملحق DNS فقط على الموارد المطلوبة لحل DNS ولا يجب مشاركتها مع الموارد الأخرى.
• يجب أن تتبع الشبكة الظاهرية لملحق DNS نفس إرشادات التكوين ضمن إضافة شبكات محورية.

Azure DNS Private Resolver

• يجب أن يكون لكل منطقة ملحق DNS مركز ظاهري واحد مع محلل DNS خاص واحد.

• يتطلب محلل DNS الخاص نقطة نهاية واردة فقط ولا يتطلب نقاط نهاية صادرة لهذا السيناريو. عنوان IP الخاص لنقطة النهاية الواردة هو ما تم تعيينه لخدمة DNS المخصصة في نهج جدار حماية Azure (راجع الشكل 5).

• للحصول على مرونة أعلى ومعالجة تحميل متزايدة، يمكنك نشر مثيلات DNS Private Resolver متعددة لكل منطقة، مع تكوين وكيل Azure DNS مع عناوين IP متعددة للتحليل الوكيل.

  الشكل 8: نقاط النهاية الواردة لمحلل DNS الخاص

• اتبع قيود الشبكة الظاهرية لمحلل DNS الخاص.

• يجب أن تسمح مجموعة أمان الشبكة في الشبكة الفرعية لنقطة نهاية DNS Private Resolver الواردة فقط بحركة مرور UDP من مركزها الإقليمي إلى المنفذ 53. يجب حظر جميع حركة المرور الواردة والصادرة الأخرى.

منطقة DNS خاصة

نظرا لأن محلل Azure DNS الخاص يحل DNS عبر Azure DNS، فإن Azure DNS قادر على التقاط أي مناطق DNS خاصة مرتبطة بالشبكة الظاهرية للشبكة الفرعية الواردة.

• ربط منطقة DNS الخاصة بملحق المركز الظاهري لشبكة DNS الظاهرية.
• اتبع الإرشادات المتعلقة بإدارة مناطق DNS الخاصة لنقاط النهاية الخاصة.
• إذا كنت تتوقع من مالكي موارد PaaS إدارة إدخالاتهم الخاصة، فقم بتكوين RBAC وفقا لذلك أو تنفيذ حل مثل الحل من Private Link وتكامل DNS على نطاق واسع.

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

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

حساب التخزين

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

أمان نقطة النهاية الخاصة

أحد متطلبات هذا الحل هو الحد من تعرض حساب التخزين هذا. بمجرد إزالة الوصول العام إلى الإنترنت إلى مورد PaaS الخاص بك، يجب عليك معالجة أمان الشبكات الخاصة.

عندما يقوم جدار حماية Azure بتأمين نسبة استخدام الشبكة الخاصة في مخطط محور شبكة WAN الظاهرية، يقوم Azure Firewall افتراضيا برفض الاتصال بين المتحدثين. يمنع هذا الإعداد الافتراضي أحمال العمل في الشبكات المحورية الأخرى من الوصول إلى نقاط النهاية الخاصة (والموارد الأخرى) في الشبكة الظاهرية لحمل العمل. لا يتم توجيه نسبة استخدام الشبكة بالكامل داخل شبكة ظاهرية من خلال Azure Firewall. للتحكم في الوصول داخل الشبكة الظاهرية، وإضافة حماية أكثر دقة، ضع في اعتبارك توصيات مجموعة أمان الشبكة (NSG) التالية.

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

قواعد NSG للشبكة الفرعية التي تحتوي على جهاز ظاهري لحمل العمل

إلى جانب أي قواعد شبكة أخرى يتطلبها حمل العمل، قم بتكوين القواعد التالية.

• القواعد الصادرة:
  • السماح لحساب ASG بالوصول إلى حساب التخزين ASG.
  • السماح بالحوسبة ASG إلى عنوان IP الخاص بمركز Azure Firewall الخاص ب UDP على المنفذ 53.

*الشكل 9: قواعد NSG للشبكة الفرعية لحمل العمل

قواعد NSG للشبكة الفرعية التي تحتوي على نقاط نهاية خاصة

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

يسمح هذا السيناريو بتطبيق مجموعة أمان شبكة تقييدية للغاية.

• القواعد الواردة:
  • السماح لحساب ASG بالوصول إلى حساب التخزين ASG
  • رفض جميع حركات المرور الأخرى
• القواعد الصادرة:
  • رفض كل نسبة استخدام الشبكة

*الشكل 10: قواعد NSG للشبكة الفرعية لنقطة النهاية الخاصة

أمان نقطة النهاية الخاصة قيد التنفيذ

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

الشكل 11: حل العمل لسيناريو منطقة واحدة ل Virtual WAN مع Private Link وDNS

قم بتنزيل ملف Visio لهذه البنية.

تدفق DNS

تدفق DNS هو نفسه تماما كما هو الحال في تدفق الحل.

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

تدفق HTTP

1. مع وجود نتيجة DNS في متناول اليد، عنوان IP الخاص لحساب التخزين، يصدر العميل طلب HTTP إلى stgworkload00.blob.core.windows.net.
2. يتم إرسال الطلب إلى عنوان IP الخاص لحساب التخزين. يفشل هذا الطلب بشكل مناسب لأسباب عديدة:
   • تم تكوين جدار حماية Azure لتأمين نسبة استخدام الشبكة الخاصة، بحيث يعالج الطلب. ما لم يكن لدى Azure Firewall قاعدة شبكة أو تطبيق للسماح بالتدفق، يقوم Azure Firewall بحظر الطلب.
   • لا يتعين عليك استخدام Azure Firewall في المركز لتأمين نسبة استخدام الشبكة الخاصة. على سبيل المثال، إذا كانت شبكتك تدعم نسبة استخدام الشبكة الخاصة عبر المناطق، فلا يزال NSG على الشبكة الفرعية لنقطة النهاية الخاصة مكونا لحظر كافة نسبة استخدام الشبكة بخلاف مصادر ASG للحساب داخل الشبكة الظاهرية التي تستضيف حمل العمل.

الملخص

تقدم هذه المقالة سيناريو يتصل فيه عميل الجهاز الظاهري بحساب Azure Storage عبر نقطة النهاية الخاصة لحساب التخزين. نقطة النهاية في نفس الشبكة الظاهرية مثل العميل. تم حظر جميع الوصولات الأخرى إلى حساب التخزين. يتطلب هذا السيناريو سجل DNS في تدفق DNS قادر على حل اسم المجال المؤهل بالكامل (FQDN) لحساب التخزين مرة أخرى إلى عنوان IP الخاص لنقطة النهاية الخاصة.

يقدم مخطط شبكة البداية لهذا السيناريو تحديين:

• لا يمكن ربط منطقة DNS خاصة بسجلات DNS المطلوبة لحساب التخزين بالمركز الظاهري.
• لا يعمل ربط منطقة DNS خاصة بالشبكة الفرعية لحمل العمل. يتطلب مخطط شبكة البداية أن يفرض خادم DNS الافتراضي وقواعد التوجيه استخدام Azure Firewall في المركز الإقليمي.

الحل المقترح هو لفريق شبكة المؤسسة لتنفيذ ملحق مركز ظاهري ل DNS. يسمح هذا الملحق لفريق شبكة المؤسسة بعرض خدمات DNS المشتركة لمتحدثي حمل العمل التي تتطلبها.

الموارد ذات الصلة

• ما هي نقطة النهاية الخاصة؟
• تهيئة نقطة النهاية الخاصة بـ Azure DNS
• تكامل Private Link وDNS على نطاق واسع
• Azure Private Link في شبكة مركز وتحدث
• DNS للموارد المحلية وموارد Azure
• اتصال المنطقة المنتقل إليها للبيانات أحادية المنطقة
• استخدام الارتباط الخاص لـ Azure لتوصيل الشبكات إلى Azure Monitor
• محلل Azure DNS الخاص
• وصول محسّن بأمان إلى تطبيقات الويب متعددة العملاء من شبكة محلية
• تطبيق ويب متكرر في المنطقة للأساس متوفر بشكل كبير
• البرنامج التعليمي: إنشاء بنية أساسية خاصة ل DNS لنقطة النهاية باستخدام Azure Private Resolver لحمل عمل محلي