VPN چند-مستاجری: دروازه مشترک، به ازای هر مستاجر یا هر میزبان
تانل به معنای جداسازی مستاجران نیست. دروازه مشترک، دروازه‌های هر مستاجر و اتصال‌های هر میزبان را از نظر نگاشت هویت، مسیریابی و خروج از سرویس مقایسه کنید.
تصمیم بگیرید چه کسی مشتری را می‌پذیرد و چه چیزی مانع می‌شود آن مشتری به منابع مستاجر دیگری برسد. این‌ها دو تصمیم‌اند و انتخاب IPsec یا WireGuard یا یک محصول mesh به هیچ‌کدام پاسخ نمی‌دهد. تانلی که بی‌نقص بالا می‌آید می‌تواند باز هم هر مستاجر را قادر به رسیدن به همهٔ دیگران بگذارد، و بازبینی‌ای که این دو را یکی می‌بیند طراحی نادرست را تصویب می‌کند. نخست نقشهٔ مشتری به منبع را بنویسید: مدیران، دسترسی پشتیبانی، سرویس‌های مشترک و مسیرهایی که باید ممنوع بمانند.
با نقشه شروع کنید، نه با محصول
آن نقشه نخستین سند است و هر انتخاب زیر تنها تصمیمی است دربارهٔ اینکه مرزی که آن را اعمال می‌کند کجا زندگی می‌کند. آن را قابل بازبینی نگه دارید: یک سطر برای هر مشتری، یک سطر برای هر سرویس مشترک و مسیرهای ممنوع نوشته‌شده.
نقشه‌ای که هیچ‌کس نمی‌تواند بخواند نقشه‌ای است که هیچ‌کس اعمال نخواهد کرد.
یک نقطهٔ پذیرش و مشکل نگاشت آن
هر جای‌گذاری با یک پرسش عملیاتی واحد تعیین می‌شود و جدول تمام مقایسه است.
| Placement | The question it lives or dies on |
|---|---|
| One shared gateway | How does an admitted identity end up limited to its own resources and its own routing context? |
| A gateway per tenant | Who owns each gateway, its credentials, its policy, its updates and its eventual retirement? |
| A connection per hosted machine | How do enrollment, per-machine policy and replacement work at fleet scale? |
دروازهٔ مشترک پذیرش را متمرکز می‌کند و ریسک را در یک جا جمع می‌کند: پیوند میان هویت مستاجر و سیاست آن. گروه‌ها یا نشانی‌های تانل باید به مجوزهای درست منابع تبدیل شوند، و برچسب متفاوت برای هر مشتری به‌خودی‌خود چیزی را مانع نمی‌شود. بافت‌های مسیریابی جداگانه می‌توانند پیشوندهای همپوشان را نگه دارند وقتی پلتفرم آن را پشتیبانی می‌کند و طراحی کامل است. جدول مسیریابی مشترک ساده نمی‌تواند دو پیشوند مقصد یکسان را تنها به این دلیل که مردمان پشت آن‌ها حساب‌های متفاوت دارند از هم تشخیص دهد.
این آزمون بیشتر طراحی‌هاست. دو مستاجر که هر دو در داخل با 10.0.0.0/8 شماره‌گذاری می‌کنند به وضعیت مسیریابی جداگانه نیاز دارند، نه به یک قرارداد نام‌گذاری.
دروازه به ازای هر مستاجر مرزها و سامانه‌ها می‌خرد
یک دروازه برای هر مشتری برخی مرزهای اداری را آسان توضیح می‌دهد، چون پذیرش و سیاست آن مشتری کنار هم قرار دارند. همچنین سامانه‌هایی را که به اعتبارنامه، وصله، پایش و مالک نیاز دارند چند برابر می‌کند. و هیچ چیدمان تجویزی واحدی برای نشانی‌های عمومی تحمیل نمی‌کند: اشتراک نقطهٔ پایانی، ترجمه و جداسازی پروتکل‌ها به آنچه پیاده‌سازی واقعاً پشتیبانی می‌کند بستگی دارد.
پیش از شمردن سود امنیتی، سامانه‌ها و آدم‌ها را بشمارید. طراحی‌ای که چهار دروازه بیش از توان وصله‌کردن تیم دارد در عمل جداافتاده‌تر نیست.
اگر شمار مستاجران هر ماه تغییر می‌کند، آن مدل به روایت خودکارسازی نیاز دارد نه به یک الگو.
اتصال‌های هر میزبان کار را جابه‌جا می‌کنند
اتصال روی هر ماشین میزبانی‌شده کار عملیاتی را حذف نمی‌کند، آن را به چرخهٔ عمر ماشین منتقل می‌کند. ثبت‌نام، سیاست هر ماشین، چرخش کلید و جایگزینی همه بخشی از تأمین می‌شوند و در همان پنجره‌ای که خود ماشین شکست می‌خورد شکست می‌خورند. برای چند میزبان دیرزی در شبکه‌های متمایز این اغلب درست است، و برای ناوگانی که پیش‌تر رد کدام تصویر کجا اجرا می‌شود را گم کرده به‌ندرت.
زیر هر گزینه برای صدور هویت، به‌روزرسانی‌ها، حذف دسترسی، پایش و بازیابی نقشی نام ببرید. سپس بپرسید روزی که یک مشتری می‌رود چه می‌شود.
خروج از سرویس به مقایسه تعلق دارد
بیشتر مقایسه‌ها خروج از سرویس را نادیده می‌گیرند. حذف یک مستاجر باید اعتبارنامه‌هایش را باطل کند، سیاستش را بیندازد، نشانی‌ها و وضعیت مسیریابی‌اش را آزاد کند و بقیه را دست‌نخورده بگذارد. راهنمای معماری اعتماد صفر NIST اینجا مرجع درست است، چون احراز هویت و مجوزدهی را روی منبع می‌گذارد نه اعتماد به موقعیت شبکه، و این درون بخش خود مشتری هم صدق می‌کند.
جریان‌های مجاز و ممنوع، برخورد با نشانی‌های همپوشان و رویهٔ خروج از سرویس را وزن کنید پیش از آنکه معیارهای پروتکل را وزن کنید. سپس روش انتقال و احراز هویتی برگزینید که با مرزی که انتخاب کرده‌اید بخواند. نام محصولی قدیمی‌تر، یا این ادعا که هر کسب‌وکاری باید بر یک پروتکل استاندارد شود، هیچ‌یک از این‌ها را حل نمی‌کند. نقشه‌ای که نخست نوشتید حل می‌کند.