نقطة نهاية خاصة، اسم الخادم نفسه: سلاسل اتصال Azure SQL

يغيّر Private Link المكان الذي يصل إليه الاتصال، لا الاسم الذي يُنادى به الاتصال. وبالنسبة إلى Azure SQL Database فإن هذا التمييز هو التصميم كله: يحتفظ الخادم المنطقي باسمه، وتوفّر نقطة النهاية الخاصة مدخل شبكة يُحلّ إليه الاسم. واستبدال الاسم بعنوان IP هو التغيير الوحيد الذي يكسر TLS وبيانات الاعتماد والأدوات في الوقت نفسه. وقد تبدو سلسلتا اتصال متكافئتين وتتصرفان بشكل مختلف تمامًا.

احتفظ بـ orders-db.database.windows.net وامنح العميل إجابة خاصة له.

للاسم والعنوان وظيفتان مختلفتان

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

تتطلب إرشادات Microsoft لـ Azure SQL اسم الخادم العادي من العملاء. وعنوان IP المباشر، وكذلك الاسم المسبوق بـ privatelink، ليس هدف تسجيل دخول قابلًا للتبادل. والأدوات التي تقبل عنوان IP ستقبله ثم تفشل عند TLS أو عند المصادقة، وهو ما يخفي الخطأ الحقيقي. وتُقرأ تلك الإخفاقات كأنها مشكلات في بيانات الاعتماد حتى تنظر إلى اسم المضيف في رسالة الخطأ.

ما الذي تغيّره المنطقة الخاصة فعليًا

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

Application name:        orders-db.database.windows.net
Private DNS zone:        privatelink.database.windows.net
Resolved private entry:  the approved private endpoint address

حافظ على ذلك السجل وربط منطقته كبنية تحتية، مع مالك وتاريخ مراجعة.

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

يحتاج العملاء خارج Azure إلى مسار إلى تلك المنطقة

يجلس عميل VPN خارج محلّل Azure، لذا يجب أن تكون المنطقة الخاصة قابلة للوصول من المسار المختلط. يمكن لأداة إعادة توجيه DNS في Azure أو Azure DNS Private Resolver أن تخدم الاستعلامات الواردة عبر تلك الشبكة. وتوصي إرشادات Microsoft بإعادة توجيه منطقة الخدمة العامة المعنية عبر ذلك الترتيب بدلًا من افتراض أن العملاء يستعلمون عن اسم privatelink مباشرة. والعملاء الذين لا يستطيعون حل الإجابة الخاصة يعودون إلى الإجابة العامة دون شكوى.

أبقِ نطاق إعادة التوجيه مقصودًا، لأن استبدال منطقة عامة قيد الاستخدام يكسر أسماء لا تحتوي عليها البديل.

التزويد بترتيب يحافظ على ثبات الهوية

للخطوات مالكوها المنفصلون: إنشاء نقطة النهاية والموافقة عليها، وتوفير مسار VPN، ودمج DNS الخاصة، ثم تكوين العميل باسم الخادم العادي. وإن إجراء DNS قبل المسار ينتج مهلات تبدو كإخفاقات DNS. وإن إجراء العميل أخيرًا يُبقي متغيرًا واحدًا يتحرك في كل مرة. ولكل خطوة نتيجة قابلة للملاحظة، فلا حاجة إلى اختبار أي منها بالتخمين.

أيقونة VPN متصلة لا تختار وجهة خاصة بحد ذاتها.

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

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

تحقّق أيضًا من سياسة الاتصال التي يستخدمها الخادم.

يوجّه Redirect العميل إلى منفذ على العقدة بعد اتصال أولي بالبوابة، وهو ما يغيّر ما يجب أن تسمح به شبكة العميل. ويُبقي Proxy حركة المرور على البوابة. ومصافحة TCP ناجحة على منفذ واحد ليست سير عمل تسجيل الدخول كله.

هذه Azure SQL Database، وليست SQL Managed Instance التي لها نموذج اتصال خاص بها ولا قصة نقطة نهاية خاصة مكافئة. وفي الحالتين، أبقِ ثلاثة أشياء مسمّاة بشكل منفصل: الاسم، ومدخل الشبكة، وبيانات الاعتماد. وتغيير مكان انتقال الاتصال يجب ألا يغيّر أبدًا الخدمة التي يعتقد العميل أنه يتحدث إليها.