شبكة VPN الخاصة بك لا تجعل Cosmos DB خاصة بمفردها

توصل الحاسوب المحمول إلى VNet عبر VPN، وتفتح عنوان URL لحساب Cosmos DB، ويظل الطلب يخرج عبر الإنترنت العام. أدى النفق مهمته. ما لم يفعله هو إنشاء نقطة نهاية خاصة، أو نشر سجل DNS الخاص، أو إيقاف الوصول العام، لأن تلك ثلاث تغييرات منفصلة على الحساب وليست خصائص لاتصال شبكتك. يستخدم هذا المثال Azure Cosmos DB لـ NoSQL، ونقطة نهاية خاصة في VNet، وحاسوباً محمولاً متصلاً بذلك الـ VNet عبر VPN، ويبقي عنوان التطبيق دون تغيير.

الأسطورة: الوجود على VPN يجعل قاعدة البيانات خاصة

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

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

ما الذي يجعل الاسم يُحلّ بشكل خاص فعلاً

أبقِ نقطة نهاية الحساب العادية الخاصة بـ SDK، شيء مثل https://ACCOUNT.documents.azure.com. ينبغي أن يحل DNS الخاص ذلك الاسم عبر سلسلة Private Link إلى العناوين الخاصة لنقطة النهاية. لا تستبدلها بعنوان URL رقمي وتعطّل فحوص الشهادات، لأن ذلك يقايض مشكلة DNS بمشكلة أمنية.

تلك القيم خاصة بواجهة NoSQL API. واجهات Cosmos API الأخرى ليست إدخالات قابلة للتبادل في المثال نفسه، ونسخ اسم المورد الفرعي من واجهة API مختلفة ينتج نقطة نهاية لا تُحلّ أبداً.

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

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

وضع Gateway ووضع Direct غير قابلين للتبادل

يرسل وضع Gateway طلبات الخدمة عبر HTTPS على TCP 443. ولهذا يعمل معه نهج جدار حماية يسمح بالمنفذ 443 فقط، ولهذا يختاره هذا المثال عن قصد.

لوضع Direct عبر Private Link متطلبات اتصال مختلفة، بما في ذلك نطاق منافذ TCP أوسع تذكره وثائق الحساب. ويجب ألا يُعاد استخدام نهج مكتوب لوضع Gateway بصمت مع عميل في وضع Direct، وإلا سيتصل SDK ثم يتوقف عند أول عملية بيانات.

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

إيقاف الوصول العام مفتاح منفصل

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

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

إمكانية الوصول ليست إذناً

عملية SDK مسموح بها من حاسوب VPN المحمول هي اختبار القبول، باستخدام عنوان URL العادي للحساب والهوية المقصودة. لا تمنح إمكانية الوصول عبر VPN أذونات بيانات Cosmos؛ فمستوى البيانات يفحص أدواره أو مفاتيحه الخاصة.

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

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