واجهات Google API عبر VPN: وجّه المسار إلى VIP وليس إلى الشبكة الفرعية فقط
المسار إلى شبكة فرعية في VPC لا يختار عناوين VIP الخاصة بواجهات API. حلّل الأسماء الصحيحة، وأعلن بادئة VIP، واحتفظ بمسار العودة في VPC، ثم اختبر HTTPS.
ادخل إلى الخادم المحلي عبر SSH، وارفع النفق، فيستجيب الجهاز الافتراضي الخاص؛ ثم يفشل أول استدعاء إلى واجهة Google API بلا مسار. الشبكة الفرعية للجهاز الافتراضي وعناوين VIP الخاصة بـ API وجهتان مختلفتان، لذا فإن مسارًا لإحداهما لا يختار الأخرى. يجب أن تتحقق ثلاثة شروط قبل أن ينجح استدعاء خاص لواجهة API. يجب أن يُحلَّ اسم API إلى عنوان VIP، ويجب الإعلان عن بادئة VIP عبر النفق، ويجب أن تعرف VPC كيفية إرسال الرد مرة أخرى. لا يخبرك ping بأي من ذلك، ولا جلسة SSH عاملة إلى جهاز داخل الشبكة الفرعية.
عناوين VIP الخاصة بواجهات API وجهات منفصلة
تنشر Google عناوين VIP مخصصة للوصول إلى واجهات API من الشبكة المحلية، وهي العناوين التي يجب أن يعيدها DNS لأسماء API. كلتاهما بادئتان صغيرتان وليستا ضمن مساحة RFC 1918:
| Record | Resolves to | What it does not give you |
|---|---|---|
| private.googleapis.com | 199.36.153.8/30, the general front door for Google APIs | not a bypass around a service perimeter |
| restricted.googleapis.com | 199.36.153.4/30, reachable only for services a perimeter allows | not the whole API surface, so some names stay out of reach |
العناوين التي تبدو عامة لا تعني أن على المسار مغادرة النفق بالنسبة إلى الإنترنت العادي. البادئات موجودة ليتمكن عميل محلي من الوصول إلى واجهات Google الأمامية عبر مسار مدعوم بدلًا من نقطة خروج عشوائية. تعامل معها كوجهات تنتمي إلى النفق، لا كمضيفات تُفحص. قاعدة جدار الحماية المكتوبة لخروج الإنترنت ستحذفها عادةً، وهذا سبب شائع لفشل استدعاء قبل أن يبدأ.
DNS يحدد نقطة النهاية التي تصل إليها
وجّه مُحلِّل الأسماء المحلي إلى السجلات التي توثقها Google لنقطة النهاية المختارة، حتى تُجيب الأسماء التي يحتاجها التطبيق بذلك عنوان VIP. إن مجرد googleapis.com ليس جردًا: فسجلات الحزم وسجلات الحاويات وموصلات الترحيل لها أسماؤها الموثقة. كما أن عنوان VIP المقيّد لا يحمل كل خدمة، لذا قد يظل اسم يُحلَّ بنجاح غير مدعوم. اكتب النطاقات التي يتصل بها التطبيق فعليًا قبل أن تمسّ المُحلِّل.
تخمين عنوان جهاز افتراضي في VPC كبديل عن اسم خدمة ليس حلًا، وهو عادةً يخفي فجوة DNS حتى يفشل عميل آخر.
أعلن بادئة VIP واحتفظ بالباقي
مع اتصال قائم على BGP، يجب أن يعلن Cloud Router بادئة VIP المختارة ليتمكن الموجّه المحلي من تعلّم ذلك النطاق عبر الجلسة المقصودة. الإعلان عن شبكات VPC الفرعية وحدها لا يضيف ذلك النطاق، ويظل الموجّه المحلي يستخدم مساره الافتراضي لتلك العناوين. البادئة في جدول التوجيه هي الدليل الوحيد على أن الإعلان عبر الجلسة.
احتفظ بالإعلانات القائمة أثناء إضافة العنصر الجديد، لأن خيارات مستوى الموجّه ومستوى النظير لها مدى مختلف، واستبدال المجموعة قد يسحب شبكات كانت تعمل أصلًا. ثم افحص الإعلان الفعلي في كل جلسة بدلًا من الموجّه ككل. البادئة المفقودة والبادئة المسحوبة تبدوان متطابقتين من الجانب المحلي، لذا فإن عرض الجلسة هو ما يفصل الإغفال عن الانحدار.
جانب VPC يحتاج مساره ومسار عودته الخاصين
داخل VPC، يجب أن يستخدم مسار VIP القفزة التالية الافتراضية لبوابة الإنترنت، ورغم الاسم يبقى ذلك الترافيك داخل شبكة Google. تحتاج VPC أيضًا مسارًا للعودة إلى المصدر المحلي عبر VPN، وهو كائن منفصل عن البادئة المعلنة. احسب متطلبات التوجيه الإقليمية الموثقة عندما لا يكون النفق والعميل في المنطقة نفسها.
افحص مسار العودة بشكل مستقل، لأن اتجاه الطلب العامل قد يخفي اتجاه رد معطوب. اتجاهان ومساران، وكل واحد يفشل بعرَضه الخاص.
اختبر الطلب ثم اقرأ الرفض
لا يستجيب ICMP echo من عناوين VIP هذه، لذا فإن ping فاشلًا لا يثبت شيئًا وناجحًا يثبت القليل. من العميل الفعلي، افحص إجابة الاسم والمسار المختار، ثم قدّم طلب HTTPS مصرّحًا به إلى الخدمة التي تهمك. إذا وصل الطلب إلى الخدمة ورُفض، فافحص بيانات الاعتماد وIAM وأي سياسة محيط خدمة تنطبق.
التوجيه الخاص لا يمنح تفويض API، ولا يغيّر ما يُسمح للهوية بفعله. نجاح النقل والاستجابة المصرّح بها نتيجتان منفصلتان، وتحتاج إلى كلتيهما. أبقِ مسار IPv6 صريحًا أيضًا، لأن ضبط بادئات IPv4 لا يقول شيئًا عن عميل يفضّل IPv6.
يجمع دليل Google لـ Private Google Access من الشبكة المحلية سجلات DNS ومتطلبات التوجيه معًا، لذا قارن إعدادات المُحلِّل والإعلان به بدلًا من منشور في منتدى. ثم أعد تنفيذ الطلب نفسه ودوّن الإجابة والمسار في التذكرة نفسها.