دسترسی راه دور توسعه‌دهنده به یک VPC در Google Cloud: مسیر را انتخاب کنید

توسعه‌دهنده به یک نشست SSH، یک درگاه پایگاه داده یا دسترسی گسترده به دوازده سرویس خصوصی نیاز دارد، و هر یک از این درخواست‌ها شبیه همان یک پرسش به نظر می‌رسد. اما این‌طور نیست. مقصدها، پروتکل‌ها و هویت‌های درگیر تعیین می‌کنند کدام مسیر دسترسی در Google Cloud مناسب است، و انتخاب گسترده‌ترین گزینه به‌صورت پیش‌فرض کاری می‌سازد که لازم نبود مالک آن باشید.

مقصدها و پروتکل‌ها را بنویسید

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

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

IAP برای چند سرویس TCP

ارسال TCP در Identity-Aware Proxy یک تونل احراز هویت‌شده به منابع واجد شرایط VM می‌دهد بدون آنکه سرویس را در اینترنت آشکار کند. شکل روزمره آن 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 دسترسی راه دور است که به‌صراحت روی یک VM یا دستگاه پشتیبانی‌شده مدیریت می‌شود. این استقرار از Cloud VPN مدیریت‌شده توسط Google جدا است: ثبت هویت کلاینت، به‌روزرسانی‌های نرم‌افزار، مسیرهای کلاینت و مسیرهای بازگشت VPC بر عهده شماست.

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

Cloud VPN یک دروازه سایت است، نه پروفایل لپ‌تاپ

Google Cloud VPN دروازه‌های همتا را از طریق IPsec متصل می‌کند، و پرسش‌های متداول آن این نقش سایت-به-سایت را از دسترسی کلاینت-به-دروازه جدا می‌کند. ساخت تونل، پروفایلی تولید نمی‌کند که کارمندی آن را روی لپ‌تاپ وارد کند. این تمایز وقتی مهم می‌شود که کسی پروفایل Cloud VPN بخواهد. پاسخ، محصول دیگری است.

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

بررسی و ثبت کنید

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

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