چگونه ترافیک SaaS را به VPN درست مشتری هدایت کنیم
زیرشبکه‌های هم‌پوشان مشتری مسیریابی مشترک را می‌شکنند. یک مدل جداسازی انتخاب کنید، هر کار را به مستأجر تأییدشده گره بزنید و مسیرهای بین مستأجرها را پیش از راه‌اندازی آزمایش کنید.
یک پلتفرم SaaS به دوازده شبکه مشتری متصل می‌شود و دو نفر از این مشتریان هر دو از 10.20.0.10 برای پایگاه داده اصلی خود استفاده می‌کنند. کارگری که این نشانی را در یک کار دریافت می‌کند هیچ راهی ندارد که بداند کار کدام پایگاه داده را منظور دارد، و یک جدول مسیریابی مشترک آن را با خوشحالی به همان تونلی می‌فرستد که پیشوند به آن اشاره می‌کند. راه‌حل تونل‌های بیشتر نیست؛ راه‌حل این است که تصمیم بگیریم هویت مستأجر از کجا وارد مسیر می‌شود و برنامه نشانی‌ها کدام مدل جداسازی را می‌طلبد. سه شرط این انتخاب را تعیین می‌کنند: آیا پیشوندهای مشتری هم‌پوشانی دارند، یک اشتباه تا کجا می‌تواند گسترش یابد، و چه کسی اتصال‌دهنده را اداره می‌کند.
دو پایگاه داده مشتری، یک نشانی مقصد
یک نشانی IP یک مکان است، نه یک هویت. درخواست باید مستأجری را حمل کند که سرور تأیید کرده است، و آن مستأجر باید پیش از حل شدن مقصد، زمینه شبکه را انتخاب کند.
وقتی این کار را نمی‌کند، شکست بی‌صدا است. اتصال برقرار می‌شود، پرس‌وجو اجرا می‌شود و پاسخ از پایگاه داده مشتری اشتباه می‌آید، چون جدول مسیریابی یک ورودی برای 10.20.0.10 داشت. DNS آن را بدتر می‌کند: نامی که در حافظه نهان و در زمینه مستأجر A حل شده است می‌تواند توسط کاری که برای مستأجر B اجرا می‌شود دوباره استفاده شود. هیچ چیز در بسته این دو را از هم جدا نمی‌کند، بنابراین هیچ منطق تلاش مجددی آن را درست نمی‌کند.
اول درباره مدل جداسازی تصمیم بگیرید
سه شرط را پیش از مقایسه محصولات بنویسید. هم‌پوشانی تعیین می‌کند که آیا یک فضای نشانی اصلاً می‌تواند مشترک باشد؛ شعاع اثر تعیین می‌کند که یک اشتباه مسیریابی یک بلیت پشتیبانی است یا یک نفوذ؛ مالکیت عملیاتی تعیین می‌کند که آیا می‌توانید ناوگانی از اتصال‌دهنده‌ها برای هر مستأجر اجرا کنید.
| Condition | Hub with per-tenant route tables | Per-tenant connector context |
|---|---|---|
| Customer CIDRs overlap | No, unless you add 1:1 NAT | Yes, each context keeps its own view |
| A mistake must stay inside one VPC | Weak, routing is shared infrastructure | Strong, each connector has its own egress |
| You can run one fleet per tenant | Not required | Required |
اگر پیشوندها متمایز باشند و سیاست یک هاب کنترل‌شده را مجاز کند، یک Transit Gateway با جدول‌های مسیریابی برای هر مستأجر عملی است. انجمن پیوست تعیین می‌کند که کدام جدول مسیریابی برای ترافیکی که از آن پیوست وارد می‌شود استفاده شود، و انتشار تعیین می‌کند که کدام مسیرها در یک جدول ظاهر شوند. پیوست مستأجری که فقط به جدول خودش مرتبط است و فقط پیشوندهای خودش را منتشر می‌کند، به هاب می‌رسد و به هیچ جای دیگر. این یک تصمیم مسیریابی است، و تنها تا زمانی درست می‌ماند که هیچ‌کس مسیر پیش‌فرضی به جدول مشترک اضافه نکند.
اگر پیشوندها هم‌پوشانی داشته باشند، مسیریابی به‌تنهایی نمی‌تواند آن‌ها را جدا کند. شما یا به زمینه شبکه متمایز برای هر مستأجر نیاز دارید یا به یک برنامه ترجمه که به فضای هر مشتری معنایی بی‌ابهام می‌دهد.
جداسازی Transit Gateway در واقع چه معنایی دارد
انجمن و انتشار دو تنظیم مهم هستند و اشتباه گرفتن آن‌ها آسان است. انجمن پاسخ می‌دهد که بسته از این پیوست در کدام جدول جست‌وجو می‌شود؛ انتشار پاسخ می‌دهد که کدام جدول‌ها مسیرهای این پیوست را یاد می‌گیرند. جداسازی از مستأجر‌محور کردن هر دو می‌آید، نه از ساختن پیوست‌های بیشتر.
پیکربندی پیش‌فرض همه‌به‌همه راحت است و جداسازی نیست. جدول‌های مسیریابی جداگانه اتصال را محدود می‌کنند، اما به یک نشانی مقصد بدون تغییر دو معنا در همان زمینه مسیریابی نمی‌دهند. اگر برنامه پیش از شناختن مستأجر، 10.20.0.10 را حل کند، لایه مسیریابی اطلاعات مورد نیازش را از دست داده است.
AWS در 23 اکتبر 2026 NAT 1:1 در سطح پیوست را برای Transit Gateway و Cloud WAN افزود، که پاسخ هم‌پوشانی را برای پیوست‌های پشتیبانی‌شده تغییر می‌دهد. مستندات NAT در Transit Gateway نگاشته‌های IPv4 ثابت، بدون حالت و با پیشوند برابر را توصیف می‌کند که بیت‌های میزبان در آن حفظ می‌شوند. پیش از طراحی بر اساس آن، انواع پیوست پشتیبانی‌شده و محدودیت‌های منطقه‌ای را بررسی کنید.
کار را به مستأجر تأییدشده گره بزنید
هر کار باید هویت مستأجری را حمل کند که سرور تأیید کرده است، و آن هویت باید یک رکورد اتصال تحت مالکیت مدیر را انتخاب کند. رکورد زمینه شبکه تأییدشده، نشانی سرویس، ارجاع اعتبارنامه و عملیات مجاز در آنجا را نام می‌برد. یک درخواست غیرقابل اعتماد هرگز نباید شناسه VPN، دروازه یا هدف خصوصی خودش را ارائه دهد، زیرا ورود معتبر اجازه کاوش فضای نشانی هر مشتری متصل نیست.
در طراحی با اتصال‌دهنده‌های جدا، کار مستأجر A به اتصال‌دهنده مخصوص A می‌رود که در VPC مستأجر A اجرا می‌شود و فقط به منابع تأییدشده A می‌رسد. کانتینرهای جدا روی یک میزبان به‌خودی‌خود آن جدایی را ایجاد نمی‌کنند؛ فضای نام شبکه، مسیرها و سیاست خروج باید آن را پیاده کنند. اتصال‌دهنده همچنین به اعتبارنامه‌ها و صف‌های محدود به مستأجر نیاز دارد، چون مسیر خصوصی یک راز مشترک یا یک آیتم کار مشترک را محدود نمی‌کند. کارگرهای برنامه‌ای مشترک تا زمانی خوب‌اند که زمینه شبکه و اعتبارنامه‌ها برای هر مستأجر انتخاب شوند، نه برای هر میزبان.
بررسی‌های سلامت باید مستأجر و مرحله را نام ببرند: تونل برقرار، مسیر موجود و موفقیت یک درخواست واقعی سرویس سه سیگنال متفاوت‌اند. یک شمارش تجمیعی از تونل‌های فعال، تنها مشتری‌ای را پنهان می‌کند که اتصال‌دهنده‌اش خراب است.
مسیرهایی را که باید شکست بخورند آزمایش کنید
پیش از راه‌اندازی سه آزمایش انجام دهید. یک عملیات مجاز A باید موفق شود، یک عملیات مجاز B باید موفق شود، و یک کار A که به‌عمد به سوی اتصال‌دهنده B یا نام مستعار ترجمه‌شده آن نشانه رفته است باید به‌صورت بسته شکست بخورد. سپس یک تونل را بشکنید و تأیید کنید که کار فقط برای همان مستأجر شکست می‌خورد، بدون بازگشت به زیرشبکه هم‌شماره مشتری دیگر. بازگردانی نیز باید آزمایش شود، چون یک مسیر کهنه یا اعتبارنامه ذخیره‌شده می‌تواند از قطعی جان سالم به در ببرد.
معماری می‌تواند کارگرهای مشترک با اتصال‌دهنده‌های جدا باشد، یا منابع مستأجر کاملاً جدا. ناوردا یکسان است: زمینه مستأجر تأییدشده مسیر و اعتبارنامه‌ها را انتخاب می‌کند، و هیچ تغییر مسیری هرگز به برنامه اجازه بین مستأجرها نمی‌دهد.