APIهای Google از طریق VPN: مسیر را به VIP بدهید، نه فقط به زیرشبکه
مسیر به یک زیرشبکه VPC نشانی‌های VIP مربوط به API را انتخاب نمی‌کند. نام‌های درست را حل کنید، پیشوند VIP را اعلام کنید، مسیر بازگشت را در VPC نگه دارید و سپس HTTPS را آزمایش کنید.
با SSH به سرور محلی وارد شوید، تونل را بالا بیاورید و VM خصوصی پاسخ می‌دهد؛ سپس اولین فراخوانی به یک API گوگل بدون مسیر شکست می‌خورد. زیرشبکه VM و نشانی‌های VIP مربوط به API دو مقصد متفاوت هستند، بنابراین مسیر یکی، دیگری را انتخاب نمی‌کند. سه شرط باید برقرار باشد تا یک فراخوانی خصوصی API کار کند. نام API باید به یک VIP حل شود، پیشوند VIP باید از طریق تونل اعلام شود و VPC باید بداند پاسخ را چگونه بازگرداند. ping هیچ‌کدام از این‌ها را به شما نمی‌گوید، و یک نشست SSH سالم به ماشینی در زیرشبکه هم نمی‌گوید.
نشانی‌های VIP مربوط به API مقصدهای جداگانه هستند
گوگل نشانی‌های 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 |
نشانی‌هایی که عمومی به نظر می‌رسند به این معنا نیست که مسیر باید تونل را ترک کند برای اینترنت معمولی. این پیشوندها وجود دارند تا یک کلاینت محلی از مسیری پشتیبانی‌شده به نسخه‌های جلویی گوگل برسد، نه از یک نقطه خروج دلخواه. با آن‌ها مانند مقصدهایی که به تونل تعلق دارند رفتار کنید، نه مانند میزبان‌هایی برای کاوش. یک قاعده دیوار آتش که برای خروج اینترنت نوشته شده باشد معمولاً آن‌ها را دور می‌ریزد، و این یکی از دلایل رایج شکست یک فراخوانی پیش از شروع آن است.
DNS تعیین می‌کند به کدام نقطه پایانی می‌رسید
resolver محلی را به رکوردهایی که گوگل برای نقطه پایانی انتخابی مستند کرده است تنظیم کنید تا نام‌هایی که برنامه نیاز دارد با همان VIP پاسخ دهند. صرفاً نگاشت googleapis.com یک فهرست کامل نیست: رجیستری‌های بسته، رجیستری‌های کانتینر و اتصال‌دهنده‌های مهاجرت نام‌های مستند خود را دارند. VIP محدود هم هر سرویسی را حمل نمی‌کند، بنابراین نامی که حل می‌شود می‌تواند هنوز پشتیبانی نشود. پیش از دست زدن به resolver، دامنه‌هایی را که برنامه واقعاً با آن‌ها تماس می‌گیرد یادداشت کنید.
حدس زدن نشانی یک VM در VPC به جای نام سرویس، راه‌حل نیست و معمولاً شکاف DNS را تا زمانی که کلاینت دیگری شکست بخورد پنهان می‌کند.
پیشوند VIP را اعلام کنید، بقیه را نگه دارید
در یک اتصال مبتنی بر BGP، Cloud Router باید پیشوند VIP انتخاب‌شده را اعلام کند تا روتر محلی آن محدوده را از طریق نشست مورد نظر یاد بگیرد. اعلام تنها زیرشبکه‌های VPC آن محدوده را اضافه نمی‌کند و روتر محلی برای آن نشانی‌ها همچنان از مسیر پیش‌فرض خود استفاده می‌کند. پیشوند موجود در جدول مسیریابی تنها مدرک عبور اعلام‌یه از نشست است.
هنگام افزودن مورد جدید، اعلام‌های موجود را حفظ کنید، چون گزینه‌های سطح روتر و سطح همتا دامنه متفاوتی دارند و جابه‌جایی مجموعه می‌تواند شبکه‌هایی را که قبلاً کار می‌کردند پس بگیرد. سپس اعلام مؤثر را در هر نشست بررسی کنید، نه در کل روتر. پیشوند گم‌شده و پیشوند پس‌گرفته‌شده از سمت محلی یکسان به نظر می‌رسند، بنابراین نمای نشست همان چیزی است که حذف را از پس‌رفت جدا می‌کند.
سمت VPC به مسیر و مسیر بازگشت خودش نیاز دارد
در داخل VPC، مسیر VIP باید از دروازه پیش‌فرض اینترنت به عنوان گام بعدی استفاده کند و با وجود نامش، این ترافیک درون شبکه گوگل می‌ماند. VPC همچنین به مسیری بازگشتی به منبع محلی از طریق VPN نیاز دارد که شیئی جدا از پیشوند اعلام‌شده است. وقتی تونل و کلاینت در یک منطقه نیستند، الزامات مسیریابی منطقه‌ای مستند را در نظر بگیرید.
مسیر بازگشت را مستقل بررسی کنید، چون جهت درخواست سالم می‌تواند جهت پاسخ خراب را پنهان کند. دو جهت، دو مسیر، و هر کدام با نشانه خودش شکست می‌خورد.
درخواست را آزمایش کنید، سپس رد شدن را بخوانید
پژواک ICMP از این VIPها پاسخی نمی‌گیرد، بنابراین ping ناموفق چیزی را ثابت نمی‌کند و ping موفق بسیار کم. از کلاینت واقعی، پاسخ نام و مسیر انتخاب‌شده را بررسی کنید و سپس یک درخواست HTTPS مجاز به سرویسی که برایتان مهم است بفرستید. اگر درخواست به سرویس برسد و رد شود، اعتبارنامه‌ها، IAM و هر سیاست محیط سرویس را که اعمال می‌شود بررسی کنید.
مسیریابی خصوصی مجوز API نمی‌دهد و تغییر نمی‌دهد که هویت چه کاری مجاز است انجام دهد. موفقیت انتقال و پاسخ مجاز دو نتیجه جداگانه هستند و به هر دو نیاز دارید. مسیر IPv6 را هم صریح نگه دارید، چون پیکربندی پیشوندهای IPv4 درباره کلاینتی که IPv6 را ترجیح می‌دهد چیزی نمی‌گوید.
راهنمای گوگل درباره Private Google Access از شبکه محلی رکوردهای DNS و الزامات مسیریابی را با هم پوشش می‌دهد، بنابراین تنظیمات resolver و اعلام خود را با آن مقایسه کنید، نه با یک پست انجمن. سپس همان درخواست را دوباره اجرا کنید و پاسخ و مسیر را در همان تیکت یادداشت کنید.