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

دوّن الوجهات والبروتوكولات

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

افعل ذلك قبل فتح منفذ استماع. تصبح القائمة لاحقًا اختبار القبول، وهي الطريقة الوحيدة الموثوقة للتمييز بين نفق ضيق ونفق واسع يعمل بالمصادفة.

IAP لعدد قليل من خدمات TCP

يمنح تمرير TCP في Identity-Aware Proxy نفقًا موثّقًا إلى موارد الأجهزة الافتراضية المؤهلة دون تعريض الخدمة للإنترنت. الشكل المعتاد هو gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a، ويمكن تمرير منفذ واحد محليًا باستخدام gcloud compute start-iap-tunnel instance-1 5432 --local-host-port=localhost:15432 --zone=us-central1-a.

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

تمرير TCP في IAP ليس شبكة VPN من الطبقة الثالثة. فهو ينقل TCP إلى وجهة محددة، لا حركة IP عشوائية ولا UDP، وهو خيار سيئ عندما يحتاج التطبيق إلى DNS خاص عبر خدمات كثيرة.

VPN للوصول عن بُعد لمدى وصول أوسع

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

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

Cloud VPN هو بوابة موقع، وليس ملف تعريف حاسوب محمول

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

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

تحقّق وسجّل

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

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

مقالات ذات صلة