VPN به VPC کار می‌کند، اما سرویس مدیریت‌شده به پایان مهلت می‌رسد
تونل در لبه شبکه شما پایان می‌یابد، نه در درگاه ورودی ارائه‌دهنده. پیش از تغییر هر مسیری، مقصد را به‌عنوان میزبانی‌شده روی VM، متصل به VPC یا فقط عمومی طبقه‌بندی کنید.
دسترسی به یک پایگاه داده مدیریت‌شده از طریق VPN معمولاً به دلیلی شکست می‌خورد که هیچ‌کس آن را در دفترچه راهنما ننوشته است: تونل در لبه شبکه شما پایان می‌یابد، در حالی که سرویس هرگز در سمت شما از آن قرار نداشته است. جدول مسیرها درست به نظر می‌رسد، تونل وضعیت فعال را گزارش می‌کند و اتصال با این حال به پایان مهلت می‌رسد. چهار بررسی زیر را به ترتیب انجام دهید و در نخستین بررسی‌ای که شرط موفقیت آن برقرار نیست توقف کنید، زیرا هر بررسی بعدی فرض می‌کند بررسی‌های پیشین موفق بوده‌اند.
بررسی یکم: نقطه پایانی واقعاً کجا قرار دارد؟
یک دروازه VPN دو شبکه را به هم متصل می‌کند که آدرس‌دهی آن‌ها در کنترل شماست. سرویس مدیریت‌شده پشت درگاه ورودی خود ارائه‌دهنده اجرا می‌شود و آن درگاه بسته به محصول یکی از سه شکل را دارد. اگر ندانید با کدام شکل روبه‌رو هستید، هیچ حجمی از کار روی مسیرها کمک نمی‌کند، زیرا خرابی ممکن است اصلاً خرابی مسیریابی نباشد.
| Shape | What it means | Pass condition |
|---|---|---|
| Software on your VM | Ordinary subnet addressing | Route and security group permit the client |
| Attached to your VPC | Private, but only inside that VPC | Endpoint associated, source allowed, route present |
| Provider-hosted, public endpoint | Optional private link, not private by default | A private endpoint exists and DNS points at it |
بیشتر بعدازظهرهای تلف‌شده از نادیده گرفتن این طبقه‌بندی و رفتن مستقیم به جدول مسیرها ناشی می‌شود. سرویسی که نزد ارائه‌دهنده میزبانی می‌شود و نقطه پایانی عمومی دارد، هرچه نمودار بگوید، پشت تونل شما نیست، و سرویس متصل به VPC هرگز در پاسخ DNS عمومی ظاهر نخواهد شد.
بررسی دوم: سرویس متصل به VPC مانند ElastiCache
حافظه‌های نهان از این نوع درون VPC خودتان آدرس‌دهی می‌شوند و هیچ شنونده‌ای رو به اینترنت ندارند. یک VPN کارخواه که در همان VPC پایان می‌یابد می‌تواند به آن‌ها برسد، اما تنها زمانی که سه شرط هم‌زمان برقرار شوند. نقطه پایانی حافظه نهان باید به زیرشبکه‌هایی متصل باشد که تونل شما می‌بیند، گروه امنیتی آن باید آدرسی را که کارخواهان شما از آن می‌آیند مجاز کند، و سمت کارخواه به مسیری نیاز دارد که زیرشبکه‌های حافظه نهان را پوشش دهد.
اشتباه رایج این است که گمان کنیم اتصالی در جایی نزدیک به حساب می‌آید. متصل کردن VPN به VPC دیگر، یا تکیه صرف بر peering، گروه امنیتی حافظه نهان یا جدول مسیر زیرشبکه آن را به کارخواهان شما گسترش نمی‌دهد. وقتی تونل موجود جای دیگری پایان می‌یابد، میزبان پرش یا سرور VPN که درون همان VPC قرار داده شده باشد راه‌حل جایگزین معمول است. چنین جایگزینی یک راه‌حل موقت است و نه یک طراحی، و باید در دفترچه راهنما همین‌گونه برچسب بخورد.
بررسی سوم: نقطه پایانی PaaS با نام عمومی
Azure Database for PostgreSQL یک نام سرور عمومی ارائه می‌دهد. این سرویس آدرس خصوصی‌ای به شما نمی‌دهد که بتوانید آن را در فایل hosts ثابت کنید و از طریق دروازه مسیریابی کنید. نقاط پایانی سرویس شبکه مجازی محدود می‌کنند کدام زیرشبکه‌ها می‌توانند به یک منبع برسند؛ آن‌ها به یک کارخواه درون‌سازمانی که از طریق VPN می‌آید مجوز نمی‌دهند.
دسترسی خصوصی به دست آوردن یعنی یک نقطه پایانی خصوصی یا طراحی پیوند خصوصی معرفی شود و سپس یک ناحیه DNS خصوصی افزوده شود تا نام عمومی به‌جای اینترنت با همان نقطه پایانی پاسخ دهد. ترکیب VPN با قاعده نقطه پایانی سرویس معماری دیگری است که فقط در نمودار شبیه به نظر می‌رسد. سرویس App از همان منطق در جهت مخالف پیروی می‌کند: یکپارچه‌سازی VNet به برنامه اجازه می‌دهد تماس‌های خروجی به یک VNet انجام دهد و مسیر خصوصی ورودی از تونل شما ایجاد نمی‌کند. بنابراین دسترسی خصوصی ورودی به یک نقطه پایانی خصوصی، یک محیط App Service یا یک دروازه پیش از برنامه نیاز دارد، و اینکه کدام‌یک را می‌توانید به کار ببرید به طرح بستگی دارد.
بررسی چهارم: محصولاتی با درگاه ورودی خودشان
Firebase Hosting را نمی‌توان به Cloud VPN متصل کرد، زیرا لایه میزبانی یک پیشانه جهانی است و نه چیزی درون VPC یک پروژه. جایگزین مستند این است که نقطه ورود کنترل‌شده را خودتان بسازید، با یک نمونه پروکسی یا یک متعادل‌کننده بار که به یک سطل متکی است. در هر حال سایت دیگر یک محصول میزبانی خالص نیست و به زیرساختی تبدیل می‌شود که اکنون شما آن را اداره می‌کنید. این معاوضه ارزش نام بردن دارد پیش از آنکه کسی وعده دهد تونل آن را پوشش می‌دهد.
Private API Gateway به سمت سرویس‌های VPC نزدیک‌تر است: یک نقطه پایانی VPC از نوع interface نام میزبانی را منتشر می‌کند که پاسخ‌هایش آدرس‌های خصوصی هستند، و ترافیک از محل شما از طریق تونل یا یک اتصال اختصاصی می‌رسد. نقطه پایانی باید به API متصل باشد و گواهی به‌همراه نام میزبان باید با دامنه سفارشی‌ای که فراخوانان استفاده می‌کنند مطابقت داشته باشد.
تونل‌های Google Cloud VPN به آدرس‌های IP همتا متصل می‌شوند، نه به نام‌ها. ارسال DNS جداگانه پیکربندی می‌شود، و همین دلیل آن است که یک تونل می‌تواند کاملاً سالم باشد در حالی که جستجوها در ناحیه خصوصی دوردست هنوز شکست می‌خورند.
سپس مرز را پیدا کنید
همان اتصال را از یک VM درون VPC اجرا کنید. وقتی آنجا موفق می‌شود و از کارخواه VPN شکست می‌خورد، شکاف میان مسیر کارخواه و نقطه پایانی سرویس است: یک مسیر، یک گروه امنیتی، یک سیاست نقطه پایانی یا یک نام. وقتی هر دو تلاش شکست می‌خورند، هیچ چیز در آن شبکه نمی‌تواند به سرویس برسد و VPN هرگز مانع نبوده است.
getent hosts db.internal.example
nc -vz db.internal.example 5432جستجوی نام و بررسی درگاه را جداگانه انجام دهید، زیرا به دلایل متفاوتی شکست می‌خورند و این جفت به شما می‌گوید کدام نیمه مسیر خراب است. نامی که به یک آدرس عمومی حل می‌شود به شما می‌گوید که ناحیه DNS خصوصی در کار نیست.