مشاركة عبر

تصميم إعداد Azure Private Link

  • مقالة

قبل إعداد مثيل Azure Private Link، ضع في اعتبارك مخطط الشبكة وطوبولوجيا توجيه DNS.

كما تمت مناقشته في استخدام Azure Private Link لتوصيل الشبكات ب Azure Monitor، يؤثر إعداد ارتباط خاص على نسبة استخدام الشبكة إلى جميع موارد Azure Monitor. هذا صحيح بشكل خاص لموارد Application Insights. كما أنه يؤثر ليس فقط على الشبكة المتصلة بنقطة النهاية الخاصة ولكن أيضا على جميع الشبكات الأخرى التي تشترك في نفس DNS.

النهج الأبسط والأكثر أمانا:

  1. إنشاء اتصال ارتباط خاص واحد، مع نقطة نهاية خاصة واحدة ونطاق ارتباط خاص واحد Azure Monitor (AMPLS). إذا كانت شبكاتك نظيرة، فبادر بإنشاء اتصال الارتباط الخاص على الشبكة الظاهرية المشتركة (أو المركز).
  2. أضف جميع موارد Azure Monitor مثل مكونات Application Insights ومساحات عمل Log Analytics ونقاط نهاية تجميع البيانات إلى AMPLS.
  3. حظر حركة مرور خروج الشبكة قدر الإمكان.

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

التخطيط حسب طوبولوجيا الشبكة

ضع في اعتبارك تخطيط الشبكة في عملية التخطيط الخاصة بك.

المبدأ التوجيهي: تجنب تجاوز DNS باستخدام AMPLS واحد

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

في الرسم التخطيطي التالي، تتصل الشبكة الظاهرية 10.0.1.x ب AMPLS1، والتي تنشئ إدخالات DNS التي تعين نقاط نهاية Azure Monitor إلى عناوين IP من النطاق 10.0.1.x. لاحقا، تتصل الشبكة الظاهرية 10.0.2.x ب AMPLS2، والتي تتجاوز نفس إدخالات DNS عن طريق تعيين نفس نقاط النهاية العمومية /الإقليمية إلى عناوين IP من النطاق 10.0.2.x. نظرا لعدم تناظر هذه الشبكات الظاهرية، تفشل الشبكة الظاهرية الأولى الآن في الوصول إلى نقاط النهاية هذه.

لتجنب هذا التعارض، إنشاء كائن AMPLS واحد فقط لكل DNS.

رسم تخطيطي يوضح تجاوزات DNS في شبكات ظاهرية متعددة.

شبكات Hub-and-Speak

يجب أن تستخدم شبكات النظام المحوري اتصال ارتباط خاص واحد تم تعيينه على شبكة المركز (الرئيسية)، وليس على كل شبكة ظاهرية محورية.

رسم تخطيطي يوضح ارتباط خاص واحد محوري.

إشعار

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

شبكات نظيرة

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

شبكات معزولة

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

الاختبار محليًا: تحرير ملف مضيفي الجهاز بدلاً من DNS

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

  • قم بإعداد ارتباط خاص، ولكن عند الاتصال بنقطة نهاية خاصة، اختر عدم التكامل التلقائي مع DNS (الخطوة 5 ب).
  • تكوين نقاط النهاية ذات الصلة على ملفات مضيفي الأجهزة. لمراجعة نقاط نهاية Azure Monitor التي تحتاج إلى تعيين، راجع مراجعة إعدادات DNS لنقطة النهاية.

لا نوصي بهذا النهج لبيئات الإنتاج.

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

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

  • خاص فقط: يسمح للشبكة الظاهرية بالوصول إلى موارد الارتباط الخاص فقط (الموارد في AMPLS). هذا هو الوضع الأكثر أمانا للعمل. يمنع النقل غير المصرح للبيانات عن طريق حظر حركة المرور خارج AMPLS إلى موارد Azure Monitor. رسم تخطيطي يوضح وضع الوصول الخاص ب AMPLS فقط.
  • فتح: يسمح للشبكة الظاهرية بالوصول إلى كل من موارد الارتباط الخاص والموارد غير الموجودة في AMPLS (إذا كانت تقبل نسبة استخدام الشبكة من الشبكات العامة). لا يمنع وضع الوصول المفتوح النقل غير المصرح للبيانات، ولكنه لا يزال يوفر الفوائد الأخرى للارتباطات الخاصة. يتم إرسال نسبة استخدام الشبكة إلى موارد الارتباط الخاص من خلال نقاط النهاية الخاصة، والتحقق من صحتها، وإرسالها عبر العمود الفقري ل Microsoft. يعد وضع الفتح مفيدا لوضع عمل مختلط (الوصول إلى بعض الموارد بشكل عام والبعض الآخر عبر ارتباط خاص) أو أثناء عملية الإعداد التدريجية. رسم تخطيطي يوضح وضع الوصول المفتوح ل AMPLS. يتم تعيين أوضاع الوصول بشكل منفصل للاستيعاب والاستعلامات. على سبيل المثال، يمكنك تعيين وضع خاص فقط للعرض ووضع فتح للاستعلامات.

يجب توخي الحذر عند تحديد وضع الوصول. سيؤدي استخدام وضع الوصول الخاص فقط إلى حظر نسبة استخدام الشبكة إلى الموارد غير الموجودة في AMPLS عبر جميع الشبكات التي تشترك في نفس DNS، بغض النظر عن الاشتراك أو المستأجر. الاستثناء هو طلبات استيعاب Log Analytics، والتي يتم شرحها. إذا لم تتمكن من إضافة جميع موارد Azure Monitor إلى AMPLS، فابدأ بإضافة موارد محددة وتطبيق وضع الوصول المفتوح. قم بالتبديل إلى وضع Private Only للحصول على أقصى قدر من الأمان فقط بعد إضافة جميع موارد Azure Monitor إلى AMPLS.

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

إشعار

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

تعيين أوضاع الوصول لشبكات معينة

تؤثر أوضاع الوصول المعينة على مورد AMPLS على كافة الشبكات، ولكن يمكنك تجاوز هذه الإعدادات لشبكات معينة.

في الرسم التخطيطي التالي، يستخدم VNet1 الوضع فتح ويستخدم VNet2 وضع خاص فقط. يمكن أن تصل الطلبات من VNet1 إلى مساحة العمل 1 والمكون 2 عبر ارتباط خاص. يمكن أن تصل الطلبات إلى المكون 3 فقط إذا قبلت نسبة استخدام الشبكة من الشبكات العامة. لا يمكن لطلبات VNet2 الوصول إلى المكون 3. رسم تخطيطي يوضح أوضاع الوصول المختلط.

ضع في اعتبارك حدود AMPLS

كائن AMPLS له الحدود التالية:

  • يمكن للشبكة الظاهرية الاتصال بعنصر AMPLS واحد فقط. وهذا يعني أن كائن AMPLS يجب أن يوفر الوصول إلى جميع موارد Azure Monitor التي يجب أن يكون للشبكة الظاهرية حق الوصول إليها.
  • يمكن لعنصر AMPLS الاتصال ب 300 مساحة عمل Log Analytics و1000 مكون Application Insights على الأكثر.
  • يمكن لمورد Azure Monitor (مساحة العمل أو مكون Application Insights أو نقطة نهاية تجميع البيانات) الاتصال بخمسة AMPLSs على الأكثر.
  • يمكن لعنصر AMPLS الاتصال ب 10 نقاط نهاية خاصة على الأكثر.

إشعار

تدعم موارد AMPLS التي تم إنشاؤها قبل 1 ديسمبر 2021 50 موردًا فقط.

في الرسم التخطيطي التالي:

  • تتصل كل شبكة ظاهرية بعنصر AMPLS واحد فقط.
  • تتصل AMPLS A بمساحة عمل ومكون Application Insight واحد باستخدام اثنين من مساحات عمل Log Analytics الممكنة وواحدة من 1000 مكون Application Insights الممكنة التي يمكنها الاتصال بها.
  • تتصل مساحة العمل 2 ب AMPLS A و AMPLS B باستخدام اثنين من اتصالات AMPLS الخمسة الممكنة.
  • يتم توصيل AMPLS B بنقاط النهاية الخاصة لشبكتين ظاهريتين (VNet2 وVNet3) باستخدام اتصالين من 10 اتصالات نقطة نهاية خاصة محتملة.

رسم تخطيطي يوضح حدود AMPLS.

تحكم في وصول الشبكة إلى مواردك

يمكن تعيين مساحات عمل Log Analytics أو مكونات Application Insights على:

  • قبول أو حظر العرض من الشبكات العامة (الشبكات غير المتصلة بمورد AMPLS).
  • قبول أو حظر الاستعلامات من الشبكات العامة (الشبكات غير المتصلة بمصدر AMPLS).

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

حظر الاستعلامات من الشبكات العامة يعني أن العملاء مثل الأجهزة وSDKs خارج AMPLSs المتصلة لا يمكنهم الاستعلام عن البيانات في المورد. تتضمن هذه البيانات سجلات ومقاييس وتدفق المقاييس المباشرة. يؤثر حظر الاستعلامات من الشبكات العامة على جميع التجارب التي تقوم بتشغيل هذه الاستعلامات، مثل المصنفات ولوحات المعلومات والرؤى في مدخل Microsoft Azure والاستعلامات التي يتم تشغيلها من خارج مدخل Azure.

إشعار

هناك استثناءات معينة حيث لا تنطبق هذه الإعدادات. يمكنك العثور على التفاصيل في القسم التالي.

يمكن تعيين نقاط نهاية جمع البيانات لقبول أو حظر الوصول من الشبكات العامة (الشبكات غير المتصلة ب AMPLS المورد).

للحصول على معلومات التكوين، راجع تعيين علامات الوصول إلى الموارد.

استثناءات

لاحظ الاستثناءات التالية.

سجلات التشخيص

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

مقاييس مخصصة أو مقاييس ضيف Azure Monitor

لا يتم التحكم في المقاييس المخصصة (المعاينة) التي يتم جمعها وتحميلها عبر عامل Azure Monitor بواسطة نقاط نهاية جمع البيانات. لا يمكن تكوينها عبر ارتباطات خاصة.

Azure Resource Manager

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

إشعار

لا يمكن للاستعلامات المرسلة من خلال واجهة برمجة تطبيقات Resource Manager استخدام ارتباطات Azure Monitor الخاصة. يمكن أن تمر هذه الاستعلامات فقط إذا كان المورد الهدف يسمح بالاستعلامات من الشبكات العامة (تعيين من خلال جزء عزل الشبكة أو باستخدام CLI).

تعرف التجارب التالية بتشغيل الاستعلامات من خلال واجهة برمجة تطبيقات Resource Manager:

  • موصل LogicApp
  • تحديث حل الإدارة
  • تغيير تعقب الحل
  • تفاصيل الأجهزة الظاهرية (VM)
  • نتائج تحليلات الحاوية
  • جزء ملخص مساحة عمل Log Analytics (مهمل) (الذي يعرض لوحة معلومات الحلول)

اعتبارات رؤى التطبيق

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

إشعار

لتأمين Application Insights المستند إلى مساحة العمل بالكامل، تحتاج إلى تأمين الوصول إلى مورد Application Insights ومساحة عمل Log Analytics الأساسية.

اعتبارات تحليلات السجل

لاحظ اعتبارات Log Analytics التالية.

تحميل حزم حلول تحليلات السجل

يحتاج وكلاء Log Analytics إلى الوصول إلى حساب تخزين عمومي لتنزيل حزم الحلول. يمكن أن تصل إعدادات الارتباط الخاص التي تم إنشاؤها في 19 أبريل 2021 أو بعد ذلك (أو بدءا من يونيو 2021 على السحب السيادية ل Azure) إلى تخزين حزم حلول الوكلاء عبر الارتباط الخاص. يتم جعل هذه الإمكانية ممكنة من خلال منطقة DNS التي تم إنشاؤها ل blob.core.windows.net.

إذا تم إنشاء إعداد الارتباط الخاص قبل 19 أبريل 2021، فلن يصل إلى تخزين حزم الحلول عبر ارتباط خاص. للتعامل مع ذلك، يمكنك إما:

  • أعد إنشاء AMPLS ونقطة النهاية الخاصة المتصلة به.

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

    بيئة سحابية مورد العامل منافذ الاتجاه
    Azure العامة scadvisorcontent.blob.core.windows.net 443 صادر
    Azure Government usbn1oicore.blob.core.usgovcloudapi.net 443 صادر
    Microsoft Azure مُشغل بواسطة 21Vianet mceast2oicore.blob.core.chinacloudapi.cn 443 صادر

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

لمزيد من المعلومات حول كيفية توصيل حساب التخزين الخاص بك، راجع حسابات التخزين المملوكة للعميل لاستيعاب السجل وتحديدا استخدام الارتباطات الخاصة وربط حسابات التخزين بمساحة عمل Log Analytics.

Automation

إذا كنت تستخدم حلول Log Analytics التي تتطلب حساب Azure Automation (مثل Update Management أو Change Tracking أو Inventory)، فيجب عليك أيضا إنشاء ارتباط خاص لحساب التنفيذ التلقائي الخاص بك. لمزيد من المعلومات، راجع استخدام ارتباط Azure الخاص لتوصيل الشبكات بأمان بـ Azure Automation .

إشعار

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

  • موصل LogicApp
  • تحديث حل الإدارة
  • تغيير تعقب الحل
  • جزء ملخص مساحة العمل (مهمل) في المدخل (الذي يعرض لوحة معلومات الحلول)
  • تفاصيل الأجهزة الظاهرية (VM)
  • نتائج تحليلات الحاوية

اعتبارات Prometheus المدارة

  • يتم إجراء إعدادات استيعاب الارتباط الخاص باستخدام AMPLS والإعدادات على نقاط نهاية تجميع البيانات (DCEs) التي تشير إلى مساحة عمل Azure Monitor المستخدمة لتخزين مقاييس Prometheus.
  • يتم إجراء إعدادات استعلام Private Link مباشرة على مساحة عمل Azure Monitor المستخدمة لتخزين مقاييس Prometheus ولا تتم معالجتها عبر AMPLS.

المتطلبات

لاحظ المتطلبات التالية.

حجم الشبكة الفرعية للشبكة

أصغر شبكة فرعية IPv4 مدعومة هي / 27 (باستخدام تعريفات الشبكة الفرعية CIDR). على الرغم من أن شبكات Azure الظاهرية يمكن أن تكون صغيرة مثل /29، فإن Azure تحتفظ بخمسة عناوين IP. يتطلب إعداد الارتباط الخاص ل Azure Monitor 11 عنوان IP آخر على الأقل، حتى إذا كنت تتصل بمساحة عمل واحدة. راجع إعدادات DNS الخاصة بنقطة النهاية لقائمة نقاط نهاية الارتباط الخاص ب Azure Monitor.

الوكلاء

يجب استخدام أحدث إصدارات وكلاء Windows وLinux لدعم البث الآمن لمساحات عمل Log Analytics. لا يمكن للإصدارات القديمة تحميل بيانات المراقبة عبر شبكة خاصة.

عوامل Azure Monitor Windows

إصدار عامل Azure Monitor Windows 1.1.1.0 أو أعلى (باستخدام نقاط نهاية تجميع البيانات).

عوامل Azure Monitor Linux

إصدار عامل Azure Monitor Linux 1.10.5.0 أو أعلى (باستخدام نقاط نهاية جمع البيانات).

عامل Log Analytics Windows (في مسار الإهمال)

استخدم إصدار عامل سجل التحليلات 10.20.18038.0 أو أحدث.

عامل Log Analytics Linux (في مسار الإهمال)

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

$ sudo /opt/microsoft/omsagent/bin/omsadmin.sh -X
$ sudo /opt/microsoft/omsagent/bin/omsadmin.sh -w <workspace id> -s <workspace key>

مدخل Azure

لاستخدام تجارب مدخل Azure Monitor مثل Application Insights وLog Analytics ونقاط نهاية تجميع البيانات، تحتاج إلى السماح للوصول إلى مدخل Azure وملحقات Azure Monitor على الشبكات الخاصة. أضف علامات خدمة AzureActiveDirectory وAzureResourceManager وAzureFrontDoor.FirstParty وAzureFrontdoor.Frontend إلى مجموعة أمان الشبكة.

الوصول البرمجي

لاستخدام واجهة برمجة تطبيقات REST أو Azure CLI أو PowerShell مع Azure Monitor على الشبكات الخاصة، أضف علامات الخدمة AzureActiveDirectory وAzureResourceManager إلى جدار الحماية الخاص بك.

تنزيل التطبيق Insights SDK من شبكة توصيل محتوى

قم بتجميع رمز JavaScript في البرنامج النصي بحيث لا يحاول المستعرض تنزيل التعليمات البرمجية من CDN. يتم توفير مثال على GitHub.

إعدادات DNS للمتصفح

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

الاستعلام عن القيد: عامل تشغيل البيانات الخارجية

  • externaldata عامل التشغيل غير مدعوم عبر ارتباط خاص لأنه يقرأ البيانات من حسابات التخزين ولكنه لا يضمن الوصول إلى التخزين بشكل خاص.
  • يسمح وكيل Azure Data Explorer (وكيل ADX) لاستعلامات السجل بالاستعلام عن Azure Data Explorer. وكيل ADX غير مدعوم عبر ارتباط خاص لأنه لا يضمن الوصول إلى المورد المستهدف بشكل خاص.

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