دليل إلى Private Link وDNS في Azure Virtual WAN

Azure Private Link

Azure DNS

Azure Firewall

Azure Virtual WAN

يتيح Azure Private Link للعملاء الوصول إلى خدمات النظام الأساسي Azure كخدمة (PaaS) مباشرة من الشبكات الظاهرية الخاصة دون استخدام عنوان IP العام. لكل خدمة، يمكنك تكوين نقطة نهاية خاصة تستخدم عنوان IP خاصا من شبكتك. يمكن للعملاء بعد ذلك استخدام نقطة النهاية الخاصة للاتصال بشكل خاص بالخدمة.

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

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

بدء تخطيط الشبكة

مخطط شبكة البداية هو بنية شبكة تعمل كنقطة بداية لجميع السيناريوهات في هذه السلسلة من المقالات. البنية هي شبكة محورية نموذجية تستخدم Azure Virtual WAN.

الشكل 1: بدء تخطيط الشبكة لجميع سيناريوهات نقطة النهاية الخاصة وDNS

نزّل ملف Visio لهذه البنية. يحتوي هذا المخطط على الخصائص التالية:

إنها شبكة محورية يتم تنفيذها مع Azure Virtual WAN.
هناك منطقتين، كل منهما مع مركز ظاهري آمن ل Azure Firewall إقليمي.
يحتوي كل مركز ظاهري إقليمي آمن على إعدادات الأمان التالية لاتصالات شبكة Azure الظاهرية:
- حركة مرور الإنترنت: مؤمنة بواسطة Azure Firewall - تتدفق جميع نسبة استخدام الشبكة إلى الإنترنت عبر جدار حماية المركز الإقليمي.
- نسبة استخدام الشبكة الخاصة: مؤمنة بواسطة Azure Firewall - تتدفق جميع حركة المرور التي تنتقل من spoke إلى spoke عبر جدار حماية المركز الإقليمي.
يتم تأمين كل مركز ظاهري إقليمي باستخدام Azure Firewall. تحتوي جدران الحماية المركزية الإقليمية على الإعدادات التالية:
- خوادم DNS: الافتراضي (توفير Azure) - يستخدم جدار حماية المركز الإقليمي بشكل صريح Azure DNS لتحليل FQDN في مجموعات القواعد.
- وكيل DNS: ممكن - يستجيب جدار حماية المركز الإقليمي لاستعلامات DNS على المنفذ 53. يقوم بإعادة توجيه الاستعلامات إلى Azure DNS للقيم غير المخزنة مؤقتا.
- يسجل جدار الحماية تقييمات القواعد وطلبات وكيل DNS إلى مساحة عمل Log Analytics الموجودة في نفس المنطقة. يعد تسجيل هذه الأحداث مطلبا شائعا لتسجيل أمان الشبكة.
تم تكوين خادم DNS الافتراضي لكل شبكة ظاهرية متصلة ليكون عنوان IP الخاص بجدار حماية المركز الإقليمي. وإلا يمكن أن يكون تقييم قاعدة FQDN غير متزامن.

التوجيه متعدد المناطق

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

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

إضافة شبكات محورية

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

الشكل 2: تكوين الأمان لاتصالات الشبكة الظاهرية في المركز الظاهري

التحديات الرئيسية

ينشئ مخطط شبكة البداية تحديات لتكوين DNS لنقاط النهاية الخاصة.

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

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

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

إشعار

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

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

تدعم قواعد شبكة Azure Firewall الحدود المستندة إلى FQDN من أجل التحكم بدقة أكبر في حركة الخروج التي لا تتعامل معها قواعد التطبيق. تتطلب هذه الميزة تمكين وكيل DNS. الاستخدام الشائع هو تقييد حركة مرور بروتوكول وقت الشبكة (NTP) بنقاط النهاية المعروفة، مثل time.windows.com.
يمكن لفرق الأمان الاستفادة من تسجيل طلب DNS. يحتوي جدار حماية Azure Firewall على دعم مضمن لتسجيل طلب DNS، لذا فإن طلب استخدام جميع الموارد المحورية لجدار حماية Azure كموفر DNS يضمن تغطية تسجيل واسعة.

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

سيناريو العمل

المثال التالي هو تكوين نقطة نهاية خاصة أساسية. تحتوي الشبكة الظاهرية على عميل يتطلب استخدام خدمة PAAS عن طريق نقطة نهاية خاصة. تحتوي منطقة DNS الخاصة المرتبطة بالشبكة الظاهرية على سجل A يحل FQDN للخدمة إلى عنوان IP الخاص لنقطة النهاية الخاصة. يوضح الرسم التخطيطي التالي التدفق.

الشكل 3: تكوين DNS أساسي لنقاط النهاية الخاصة

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

يصدر العميل طلبا stgworkload00.blob.core.windows.net.
يتم الاستعلام عن Azure DNS، خادم DNS المكون للشبكة الظاهرية، عن عنوان IP stgworkload00.blob.core.windows.net.

يوضح تشغيل الأمر التالي من الجهاز الظاهري (VM) أنه تم تكوين الجهاز الظاهري لاستخدام Azure DNS (168.63.129.16) كموفر DNS.
```
resolvectl status eth0

Link 2 (eth0)
      Current Scopes: DNS
  Current DNS Server: 168.63.129.16
         DNS Servers: 168.63.129.16    
```
ترتبط منطقة DNS الخاصة privatelink.blob.core.windows.net ب Workload VNet، لذلك يدمج Azure DNS سجلات من Workload VNet في استجابتها.
نظرا لوجود سجل A في منطقة DNS الخاصة التي تعين FQDN، stgworkload00.privatelink.blob.core.windows.net، إلى IP الخاص لنقطة النهاية الخاصة، يتم إرجاع عنوان IP الخاص 10.1.2.4.

يؤدي تشغيل الأمر التالي من الجهاز الظاهري إلى حل FQDN لحساب التخزين إلى عنوان IP الخاص لنقطة النهاية الخاصة.
```
resolvectl query stgworkload00.blob.core.windows.net

stgworkload00.blob.core.windows.net: 10.1.2.4   -- link: eth0
                                    (stgworkload00.privatelink.blob.core.windows.net)
```
يتم إصدار الطلب إلى عنوان IP الخاص لنقطة النهاية الخاصة، والذي، في هذه الحالة، هو 10.1.2.4.
يتم توجيه الطلب من خلال Private Link إلى حساب التخزين.

يعمل التصميم لأن Azure DNS:

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

سيناريو غير العمل

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

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

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

يصدر العميل طلبا stgworkload00.blob.core.windows.net.

يوضح تشغيل الأمر التالي من الجهاز الظاهري أن الجهاز الظاهري قد تم تكوينه لاستخدام جدار حماية المركز الظاهري كموفر DNS.
```
resolvectl status eth0

Link 2 (eth0)
      Current Scopes: DNS
  Current DNS Server: 10.100.0.132
         DNS Servers: 10.100.0.132    
```
يحتوي جدار الحماية على وكيل DNS ممكن مع الإعداد الافتراضي لإعادة توجيه الطلبات إلى Azure DNS. تتم إعادة توجيه الطلب إلى Azure DNS.
لا يمكن ل Azure DNS حل stgworkload00.blob.core.windows.net إلى عنوان IP الخاص لنقطة النهاية الخاصة بسبب:
1. لا يمكن ربط منطقة DNS خاصة بمركز Virtual WAN.
2. لا يعرف Azure DNS منطقة DNS خاصة مرتبطة بالشبكة الظاهرية لحمل العمل، لأن خادم DNS المكون للشبكة الظاهرية لحمل العمل هو Azure Firewall. يستجيب Azure DNS بعنوان IP العام لحساب التخزين.
يؤدي تشغيل الأمر التالي من الجهاز الظاهري إلى حل FQDN لحساب التخزين إلى IP العام لحساب التخزين.
```
resolvectl query stgworkload00.blob.core.windows.net

stgworkload00.blob.core.windows.net: 52.239.174.228 -- link: eth0
                                    (blob.bn9prdstr08a.store.core.windows.net)
```
نظرا لأن Azure Firewall يقوم بوكيل استعلامات DNS، يمكننا تسجيلها. فيما يلي نموذج سجلات وكيل DNS لجدار حماية Azure.
```
DNS Request: 10.1.0.4:60137 - 46023 A IN stgworkload00.blob.core.windows.net. udp 63 false 512 NOERROR qr,rd,ra 313 0.009424664s
DNS Request: 10.1.0.4:53145 - 34586 AAAA IN blob.bn9prdstr08a.store.core.windows.net. udp 69 false 512 NOERROR qr,aa,rd,ra 169 0.000113s    
```
لا يتلقى العميل عنوان IP الخاص لنقطة نهاية Private Link ولا يمكنه إنشاء اتصال خاص بحساب التخزين.

السلوك أعلاه متوقع. إنها المشكلة التي تعالجها السيناريوهات.

السيناريوهات

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

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

هام

قد يختلف تنفيذ Private Link لحساب Azure Storage عن خدمات PaaS الأخرى بطرق دقيقة، ولكنه يتماشى بشكل جيد مع العديد من الخدمات. على سبيل المثال، تقوم بعض الخدمات بإزالة سجلات FQDN أثناء عرضها من خلال Private Link، مما قد يؤدي إلى سلوكيات مختلفة، ولكن عادة ما لا تكون هذه الاختلافات عاملا في الحلول لهذه السيناريوهات.

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

الدليل:	‏‏الوصف
منطقة واحدة، PaaS مخصصة	يصل حمل العمل في منطقة واحدة إلى مورد PaaS مخصص واحد.

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

قراءة المنطقة الواحدة، سيناريو مورد PaaS المخصص

دليل إلى Private Link وDNS في Azure Virtual WAN