چند پروژه Google Cloud، یک VPN ترکیبی؟ اول تصمیم بگیرید
VPC اشتراکی، پیرینگ و یک مرکز اتصال به پرسش‌های متفاوت مالکیت پاسخ می‌دهند. پیش از استقرار یک VPN برای هر پروژه، مرز شبکه را انتخاب کنید.
وقتی چند پروژه Google Cloud به دسترسی ترکیبی نیاز دارند، غریزه یک VPN برای هر پروژه است، و این تقریباً همیشه شکل اشتباه است. مالکیت پروژه و مسیریابی بسته‌ها موضوع‌هایی مرتبط اما متفاوت‌اند، و معماری مفید مرزهای اداری مورد نیاز شما را حفظ می‌کند و در همان حال به پیشوندهای مورد نظر یک مسیر سنجیده به دفتر یا مرکز داده می‌دهد. این بررسی‌ها تعیین می‌کنند واقعاً کدام مدل شبکه را می‌خواهید، به ترتیبی که از دوباره‌کاری جلوگیری می‌کند. هر کدام می‌تواند بحث را زود تمام کند، و نکته همین است.
مرز پروژه به‌طور خودکار به تونل خودش نیاز ندارد.
بررسی کنید که آیا شیء مشترک شبکه است
با پرسشی درباره مالکیت شروع کنید، نه اتصال: آیا مالکیت مرکزی شبکه می‌تواند این بارهای کاری را پشتیبانی کند؟ اگر پاسخ بله است و سازمان پیکربندی واجد شرایطی دارد، یک پروژه میزبان مالک VPC، زیرشبکه‌ها و اتصال است، در حالی که پروژه‌های سرویس مالک منابع برنامه خود هستند. سپس یک اتصال Cloud VPN در آن شبکه مشترک می‌تواند پیشوندهای بار کاری مورد نظر را سرویس دهد، با رعایت سیاست‌های مسیریابی و امنیتی .
درباره کاری که پیوستن انجام می‌دهد دقیق باشید. پیوستن یک پروژه سرویس، VPC مستقل موجود آن را در شبکه میزبان ادغام نمی‌کند و هر منبع را به‌طور خودکار جابه‌جا نمی‌کند. پیوست بار کاری، مجوزها، فضای نشانی و DNS همه بخشی از معماری‌اند، نه نتیجه تنظیم. پیوستن را نخست تغییر مجوز و سپس تغییر مسیریابی بخوانید، چون تیم‌ها معمولاً تفاوت را هنگام مهاجرت کشف می‌کنند.
اگر مالکیت مرکزی برای تیم‌های درگیر پذیرفتنی نیست، همین‌جا متوقف شوید و بقیه را طراحی پیرینگ یا مرکز بدانید. تحمیل Shared VPC به گروهی که به چرخه‌های حیات شبکه مستقل نیاز دارد، مشکلی سیاسی با نامی فنی می‌سازد.
بررسی کنید که آیا VPCهای مستقل می‌توانند مستقل بمانند
پیرینگ شبکه‌های VPC جداگانه را حفظ می‌کند و دقیقاً به همین دلیل تیم‌هایی را جذب می‌کند که طرح‌های نشانی خود و کنترل تغییر خود را می‌خواهند. نکته این است که پیرینگ متعدی نیست: پیرینگ از A به B و از B به C به‌خودی‌خود مسیریابی از A به C از طریق B ایجاد نمی‌کند. اگر سه پروژه باید به یک مقصد ترکیبی برسند، به یک طرح تبادل سنجیده نیاز دارید، نه زنجیره‌ای از پیرینگها.
اشتراک دسترس‌پذیری ترکیبی به تبادل مستند مسیرهای سفارشی و آگهی‌های مورد نظر Cloud Router نیز بستگی دارد. وضعیت فعال پیرینگ ثابت می‌کند که پیرینگ وجود دارد، نه اینکه پیشوندهایی که هر طرف به آن‌ها اهمیت می‌دهد هرگز صادر شده‌اند. بازه‌های صادرشده را در دو طرف همتا، در پیکربندی‌ای که صادرات را انجام می‌دهد بررسی کنید و آن‌ها را با نشانی‌هایی که بارهای کاری شما واقعاً استفاده می‌کنند مقایسه کنید. ناسازگاری در آنجا شایع‌ترین دلیل سالم به نظر رسیدن یک پیرینگ در حالی است که یک پیشوند دسترس‌ناپذیر می‌ماند.
طرح نشانی را پیش از هر چیز بنویسید. بازه‌های بدون همپوشانی، مسیرهای به‌سوی هر مقصد مورد نظر و آگهی‌های بازگشتی سه مصنوعی هستند که این مدل با آن‌ها زنده می‌ماند یا می‌میرد.
بررسی کنید که آیا مدل مرکز با توپولوژی سازگار است
برای طراحی بزرگ‌تر یا متفاوت تقسیم‌شده، نمای کلی Google Network Connectivity Center مدل‌های مرکز و شعاع را توصیف می‌کند. آن را برای آنچه نسخه فعلی پشتیبانی می‌کند بخوانید، نه برای آنچه نمودار القا می‌کند: کدام ترکیب‌های VPC و ترکیبی، کدام خانواده‌های مسیر و کدام سیاست‌ها را هر نوع شعاع مجاز می‌داند.
خانواده نشانی را صریح بررسی کنید. نمونه‌های برنامه‌ریزی در بیشتر راهنماها، از جمله این یکی، درباره IPv4 هستند، و ویژگی‌ای که برای یک نوع شعاع وجود دارد به‌طور خودکار و بدون تغییر به نوع دیگر اعمال نمی‌شود. اگر محیط شما دوپشته است، آن پرسش به انتخاب مدل تعلق دارد، نه به مهاجرت بعدی.
جدول زیر خلاصه سه مدل و پرسشی است که هر یک را تعیین می‌کند.
| Model | Network relationship | Planning question |
|---|---|---|
| Shared VPC | Service projects use subnets of a host project's VPC | Can central network ownership support these workloads? |
| VPC Network Peering | Independent VPCs exchange supported routes through explicit peers | Are direct peer and hybrid route exchanges sufficient? |
| Network Connectivity Center | Supported VPC and hybrid spokes join a managed hub | Does the required topology fit current routing and policy? |
بررسی کنید که مسیریابی چه چیزی نمی‌دهد
تبادل مسیر اعطای عمومی اعتماد نیست. حل DNS، مجوز دیوار آتش و مجوزدهی برنامه مسئولیت‌های خودشان را دارند و هر یک در بیشتر سازمان‌ها توسط مالک متفاوتی پیکربندی می‌شود. طراحی‌ای که فرض می‌کند دسترس‌پذیری یعنی مجوزدهی، آزمون اتصال خود را می‌گذراند و در بازبینی امنیتی رد می‌شود.
داستان DNS را نیز برای هر مدل تأیید کنید، چون ترتیبات ناحیه و ارسال به جلو میان شبکه اشتراکی و شبکه‌های همتا متفاوت است. نام‌های خصوصی که در یک پروژه حل می‌شوند مسیری به پروژه دیگر را دنبال نمی‌کنند.
تصمیم و مالک آن را ثبت کنید
جایی تمرکز دهید که سازمان مالک شبکه اشتراکی می‌خواهد؛ VPCهای جداگانه را جایی نگه دارید که چرخه حیات یا سیاست آن را می‌طلبد. سپس یک رابطه اتصال پشتیبانی‌شده انتخاب کنید و بنویسید کدام را انتخاب کردید، مالک شبکه اشتراکی کیست و هر پروژه مجاز است چه چیزی را آگهی کند.
شمردن پروژه‌ها و خرید یک VPN برای هر یک جایگزین آن تصمیم مالکیت نیست. این همان تصمیم است که بعداً توسط کسی گرفته می‌شود که صورت‌حساب و جدول مسیریابی را به ارث می‌برد.