این ادعا که App Engine Standard نمی‌تواند از طریق Cloud VPN به یک پایگاه داده خصوصی برسد، بازمانده‌ای از نسل قبلی پلتفرم است. نمونه‌های Standard مانند برخی محیط‌های اجرای دیگر آدرس بومی VPC نمی‌گیرند، اما می‌توانند خروجی را از طریق یک کانکتور Serverless VPC Access که در شبکه شما قرار دارد بفرستند. وقتی این مسیر وجود داشته باشد، Cloud VPN و فایروال راه دور ترافیک کانکتور را مانند هر منبع دیگری می‌بینند. چیزی که شکست می‌خورد به‌ندرت خودِ توانایی است. این یکی از سه تنظیمی است که هرگز هم‌تراز نشد.

پاسخ قدیمی از کجا آمد

پیش از وجود کانکتورها، پاسخ عملی واقعاً این بود که Standard فقط می‌تواند با نقاط پایانی عمومی صحبت کند و تیم‌ها برای دور زدن آن به یک VM پروکسی یا محیط اجرای دیگری می‌رفتند. پلتفرم تغییر کرد و افسانه نه. بسیاری از توصیه‌های آنلاین هنوز بازتاب دوره‌ای است که هیچ گزینه خروجی وجود نداشت.

اصلاح باریک‌تر از آن است که به نظر می‌رسد. Standard می‌تواند به شبکه خصوصی برسد، اما فقط از طریق یک یکپارچه‌سازی خروجی پشتیبانی‌شده و فقط برای مقصدهایی که آن یکپارچه‌سازی واقعاً می‌گیرد.

اول مسیر خروجی را انتخاب کنید

کانکتوری که به سرویس متصل است همان چیزی است که ترافیک آن را وارد VPC می‌کند. مستندات کانکتور پیش‌نیاز منطقه‌ای و تنظیمات خروجی را فهرست می‌کند؛ کانکتور باید در منطقه سرویس وجود داشته باشد و برای هویتی که استقرار می‌دهد قابل استفاده باشد.

vpc_access_connector:
  name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME
  egress_setting: private-ranges-only

private-ranges-only مقصدهای خصوصی را به VPC می‌فرستد و بقیه را روی مسیر عادی اینترنت می‌گذارد، که معمولاً همان چیزی است که اتصال پایگاه داده لازم دارد. all-traffic ترافیک خروجی را به‌طور گسترده از VPC عبور می‌دهد، بنابراین فراخوانی‌های عادی اینترنت نیز وضعیت NAT و فایروال VPC را به ارث می‌برند.

ویرایش محلی فایل تا زمانی که استقرار ندهید چیزی را تغییر نمی‌دهد. نسخه در حال اجرا پیکربندی‌ای را که با آن ساخته شده نگه می‌دارد.

آدرس مبدأ کانکتور است، نه لپ‌تاپ شما

بیشتر زمان اشکال‌زدایی اینجا می‌رود. دروازه VPN راه دور و فایروال پایگاه داده باید محدوده تخصیص‌یافته کانکتور را بپذیرند در داخل VPC، نه آدرس دفتر شما و نه آدرس خروجی عمومی سرویس. پیش از نوشتن حتی یک قاعده، آن محدوده را در کنسول جستجو کنید.

دو جای دیگر هم باید توافق کنند. جدول مسیر VPC به مسیری به شبکه پایگاه داده راه دور نیاز دارد و طرف مقابل به مسیر بازگشتی برای محدوده کانکتور نیاز دارد. اگر تونل از انتخابگرهای ترافیک استفاده می‌کند، تأیید کنید که محدوده کانکتور داخل دامنه مذاکره‌شده است. مسیری که فقط در جهت دور به محلی وجود دارد یک اشتباه رایج است و پینگ‌ها را عبور می‌دهد اما هرگز دست‌دهی TCP را کامل نمی‌کند.

تونلی که فقط یک زیرشبکه VM را می‌پذیرد بسته‌های کانکتور را بدون پیام خطای مفید دور می‌ریزد، و به همین دلیل مهلت پایگاه داده شبیه مشکل اعتبارنامه به نظر می‌رسد.

DNS مسیر دیگری را طی می‌کند

نام میزبان یک پایگاه داده خصوصی باید درون شبکه‌ای که کانکتور به آن می‌رسد حل شود، از طریق هم‌تایی Cloud DNS یا ناحیه ارجاعی که VPC می‌تواند استفاده کند. حل کردن آن روی ایستگاه کاری شما چیزی درباره سرویس مستقرشده اثبات نمی‌کند، چون لپ‌تاپ شما از آن حل‌کننده استفاده نمی‌کند.

اگر نام از داخل VPC به آدرس عمومی حل شود، در آستانه اشکال‌زدایی فایروال اشتباه هستید.

URL Fetch از کانکتور استفاده نمی‌کند

تنظیم خروجی سوکت‌های خروجی عادی محیط اجرا را پوشش می‌دهد و سرویس قدیمی URL Fetch بخشی از آن مسیر نیست. درخواستی که از طریق urlfetch صادر شود صرف‌نظر از اینکه پیکربندی چه می‌گوید کانکتور را نادیده می‌گیرد. وقتی فراخوانی ناموفق در کتابخانه‌ای قدیمی است که هنوز از URL Fetch استفاده می‌کند، راه‌حل انتقال آن فراخوانی به کلاینت استاندارد HTTP است.

برای درایور پایگاه داده این به‌ندرت مشکل است، اما دلیل کلاسیک کار کردن یک نقطه پایانی و کار نکردن دیگری از همان سرویس است.

با یک پرس‌وجوی باریک بررسی کنید

استقرار دهید، سپس یک عملیات مجاز پایگاه داده را از نسخه مستقرشده اجرا کنید در حالی که طرف دور را تماشا می‌کنید. آدرس مبدأیی که پایگاه داده یا دروازه VPN ثبت می‌کند باید آدرس کانکتور باشد. اگر نیست، درخواست هرگز وارد VPC نشده و هیچ مقدار پیکربندی تونل آن را درست نمی‌کند. آن را با محدوده‌ای که در کنسول جستجو کردید مقایسه کنید؛ عدم تطابق معمولاً یعنی کانکتور دومی به نسخه سرویس می‌دهد.

پرس‌وجوی موفق از یک VM داخل VPC ثابت می‌کند که مسیر وجود دارد. ثابت نمی‌کند که سرویس آن را انتخاب کرده است.

مقالات مرتبط