إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
Azure Private Link هي تقنية تسمح لك بالاتصال بعروض Azure Platform-as-a-Service باستخدام اتصال عنوان IP الخاص عن طريق عرض نقاط النهاية الخاصة. باستخدام Azure Virtual WAN، يمكنك توزيع نقطة نهاية خاصة في إحدى الشبكات الظاهرية المتصلة بأي مركز ظاهري. يوفر هذا الارتباط الخاص الاتصال بأي شبكة ظاهرية أخرى أو فرع متصل بنفس شبكة WAN الظاهرية.
قبل البدء
تفترض الخطوات في هذا المقال أنك نشرت شبكة افتراضية مع مركز أو أكثر وشبكتين افتراضيتين على الأقل متصلتين بشبكة الشبكة الافتراضية.
لإنشاء شبكة WAN ظاهرية جديدة ومركز جديد، استخدم الخطوات الواردة في المقالات الآتية:
اعتبارات التوجيه مع الارتباط الخاص في Virtual WAN
اتصال نقطة النهاية الخاصة في Azure أمر في حالة. عند إنشاء اتصال بنقطة نهاية خاصة من خلال Virtual WAN، يتم توجيه حركة المرور من خلال نقل حركة مرور واحدة أو أكثر من خلال مكونات Virtual WAN مختلفة (على سبيل المثال موجه Virtual Hub أو بوابة ExpressRoute أو بوابة VPN أو جدار حماية Azure أو NVA). تستند حركة نقل الوثبات الدقيقة إلى تكوينات توجيه Virtual WAN. خلف الكواليس، ترسل طبقة الشبكات المعرفة بالبرامج في Azure جميع الحزم المتعلقة بتدفق واحد من 5 مجموعات إلى أحد مثيلات الواجهة الخلفية التي تخدم مكونات Virtual WAN المختلفة. نسبة استخدام الشبكة التي يتم توجيهها بشكل غير متماثل (على سبيل المثال، نسبة استخدام الشبكة المقابلة لتدفق واحد من 5 مجموعات يتم توجيهها إلى مثيلات خلفية مختلفة) غير مدعومة ويتم إسقاطها بواسطة النظام الأساسي Azure.
خلال أحداث الصيانة على بنية WAN الافتراضية، يتم إعادة تشغيل نسخ الخلفية واحدة تلو الأخرى. قد يؤدي ذلك إلى مشاكل اتصال متقطعة مع نقطة النهاية الخاصة لأن النسخة التي تخدم التدفق تكون غير متاحة مؤقتا. يمكن أن تحدث مشكلة مماثلة عندما يتغير نطاق جدار الحماية في Azure أو راوتر Virtual Hub. يمكن موازنة نفس تدفق الحركة إلى مثيل خلفية جديد يختلف عن النسخة التي تخدم التدفق حاليا.
للتخفيف من تأثير أحداث الصيانة وتوسيع النطاق على الارتباط الخاص أو حركة مرور نقطة النهاية الخاصة، ضع في اعتبارك أفضل الممارسات التالية:
- قم بضبط قيمة مهلة نهاية TCP لأي تطبيق (سواء كان مستضفا في الموقع أو في شبكة Azure افتراضية أخرى) يصل إلى الرابط الخاص/نقطة النهاية الخاصة ليكون بين 15-30 ثانية. تسمح قيمة مهلة TCP الأصغر لحركة مرور التطبيقات بالتعافي بسرعة أكبر من أحداث الصيانة والتوسع. بدلا من ذلك، اختبر قيم مهلة التقديم المختلفة لتحديد مهلة مناسبة بناء على متطلباتك.
- مكونات Virtual WAN واسعة النطاق مسبقا للتعامل مع اندفاعات نسبة استخدام الشبكة لمنع أحداث التحجيم التلقائي من الحدوث. بالنسبة إلى جهاز التوجيه Virtual Hub، يمكنك تعيين الحد الأدنى من وحدات البنية الأساسية للتوجيه على موجه المركز لمنع التحجيم أثناء اندفاعات نسبة استخدام الشبكة.
أخيرا، إذا كنت تستخدم الاتصال المحلي بين Azure والمحلي باستخدام VPN أو ExpressRoute، تأكد من أن جهازك المحلي مهيأ ليستخدم نفس نفق VPN أو نفس راوتر Microsoft Enterprise Edge كخطوة التالية لكل 5-تجمع يتوافق مع حركة المرور الخاصة بنقطة الطرف.
قم بإنشاء نقطة نهاية ارتباط خاص
يمكنك إنشاء نقطة نهاية ارتباط خاصة للعديد من الخدمات المختلفة. في هذا المثال، نستخدم قاعدة بيانات Azure SQL. يمكنك العثور على مزيد من المعلومات بشأن كيفية إنشاء نقطة نهاية خاصة لـ Azure SQL Database في تشغيل سريع: إنشاء نقطة نهاية خاصة باستخدام مدخل Microsoft Azure. تُظهر الصورة التالية تكوين الشبكة لـ Azure SQL Database:
بعد إنشاء Azure SQL Database، يمكنك التحقق من عنوان IP لنقطة النهاية الخاصة الذي يستعرض نقاط النهاية الخاصة بك:
عند النقر على نقطة النهاية الخاصة التي أنشأناها، يجب أن ترى عنوان IP الخاص بها واسم النطاق المؤهل بالكامل (FQDN). يجب أن يكون لنقطة النهاية الخاصة عنوان IP في نطاق الشبكة الظاهرية (10.1.3.0/24):
تحقق من الاتصال من نفس VNet
في هذا المثال، نتحقق من الاتصال بقاعدة بيانات Azure SQL من جهاز ظاهري Linux مع تثبيت أدوات MS SQL. الخطوة الأولى هي التحقق من أن حل DNS يعمل وأن اسم النطاق المؤهل بالكامل لقاعدة بيانات Azure SQL يتم حلها إلى عنوان IP خاص، في نفس VNet حيث يتم نشر نقطة النهاية الخاصة (10.1.3.0/24):
nslookup wantest.database.windows.net
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
wantest.database.windows.net canonical name = wantest.privatelink.database.windows.net.
Name: wantest.privatelink.database.windows.net
Address: 10.1.3.228
كما ترى في المخرج السابق، يتم تعيين FQDN wantest.database.windows.net إلى wantest.privatelink.database.windows.net، حيث يتم حل منطقة DNS الخاصة التي تم إنشاؤها على طول نقطة النهاية الخاصة إلى عنوان 10.1.3.228IP الخاص . البحث في منطقة DNS الخاصة يؤكد وجود سجل A لنقطة النهاية الخاصة مرتبطا بعنوان IP الخاص:
بعد التحقق من دقة DNS الصحيحة، يمكننا محاولة الاتصال بقاعدة البيانات:
query="SELECT CONVERT(char(15), CONNECTIONPROPERTY('client_net_address'));"
sqlcmd -S wantest.database.windows.net -U $username -P $password -Q "$query"
10.1.3.75
كما ترى، نحن نستخدم استعلام SQL خاص يمنحنا عنوان IP المصدر الذي يراه خادم SQL من العميل. في هذه الحالة، يرى الخادم العميل مع IP الخاص به (10.1.3.75)، ما يعني أن نسبة استخدام الشبكة تنتقل من VNet مباشرة إلى نقطة النهاية الخاصة.
قم بتعيين المتغيرات username و password لمطابقة بيانات الاعتماد المحددة في قاعدة بيانات Azure SQL لجعل الأمثلة في هذا الدليل تعمل.
قم بالاتصال من شبكة VNet مختلفة
الآن بعد أن أصبح لدى VNet واحد في Azure Virtual WAN اتصال بنقطة النهاية الخاصة، يمكن لجميع شبكات VNets والفروع الأخرى المتصلة بـ Virtual WAN الوصول إليها أيضاً. تحتاج إلى توفير اتصال عبر أي من النماذج التي تدعمها Azure Virtual WAN، مثل سيناريو أي إلى أي أو سيناريو VNet للخدمات المشتركة، على سبيل المثال لا الحصر.
بمجرد أن يكون لديك اتصال بين VNet أو الفرع بشبكة VNet حيث تم توزيع نقطة النهاية الخاصة، فأنت بحاجة إلى تكوين دقة DNS:
- في حالة الاتصال بنقطة النهاية الخاصة من شبكة VNet، يمكنك استخدام نفس المنطقة الخاصة التي تم إنشاؤها باستخدام Azure SQL Database.
- في حالة الاتصال بنقطة النهاية الخاصة من فرع (VPN من موقع إلى موقع أو VPN من نقطة إلى موقع أو ExpressRoute)، فأنت بحاجة إلى استخدام حل DNS المحلي.
في هذا المثال، نحن نتصل من شبكة ظاهرية مختلفة. أولا قم بإرفاق منطقة DNS الخاصة بشبكة VNet الجديدة بحيث يمكن لأحمال العمل الخاصة بها حل اسم المجال المؤهل بالكامل لقاعدة بيانات Azure SQL إلى عنوان IP الخاص. يتم ذلك من خلال ربط منطقة DNS الخاصة بشبكة VNet الجديدة:
الآن يجب على أي جهاز ظاهري في VNet المرفق حل Azure SQL Database FQDN بشكل صحيح إلى عنوان IP الخاص للرابط الخاص:
nslookup wantest.database.windows.net
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
wantest.database.windows.net canonical name = wantest.privatelink.database.windows.net.
Name: wantest.privatelink.database.windows.net
Address: 10.1.3.228
من أجل التحقق مرة أخرى من أن شبكة VNet هذه (10.1.1.0/24) لديها اتصال بشبكة VNet الأصلية حيث تم تكوين نقطة النهاية الخاصة (10.1.3.0/24)، يمكنك التحقق من جدول التوجيه الفعال في أي جهاز ظاهري في VNet:
كما ترى، هناك مسار يشير إلى VNet 10.1.3.0/24 الذي تم حقنه بواسطة بوابات الشبكة الظاهرية في Azure Virtual WAN. الآن يمكننا أخيراً اختبار الاتصال بقاعدة البيانات:
query="SELECT CONVERT(char(15), CONNECTIONPROPERTY('client_net_address'));"
sqlcmd -S wantest.database.windows.net -U $username -P $password -Q "$query"
10.1.1.75
مع هذا المثال، رأينا كيف أن إنشاء نقطة نهاية خاصة في إحدى الشبكات الظاهرية المرفقة بشبكة WAN الظاهرية يوفر الاتصال ببقية VNets والفروع في Virtual WAN.
الخطوات التالية
لمزيدٍ من المعلومات حول Virtual WAN، راجع الأسئلة المتداولة.