ستاره یا شبکه کامل: کدام توپولوژی VPN برای سایت‌های شما مناسب است
دو تونل فعال هنوز یک توپولوژی نیست. پیش از انتخاب هاب، شبکه کامل یا هابی با چند پیوند مستقیم، ترانزیت، رفتار در خرابی و هزینه تغییر را مقایسه کنید.
دو شعبه تمام روز با هم صحبت می‌کنند و تونل میان آن‌ها از میان یک مرکز داده در منطقه‌ای دیگر عبور می‌کند. هر درخواست دو بار هزینه این انحراف را می‌پردازد و هیچ‌کس متوجه نمی‌شود تا زمانی که همگام‌سازی فایل‌ها اشتباه به نظر برسد. اینجاست که پرسش توپولوژی واقعاً آغاز می‌شود: نه با اینکه کدام نمودار مقاوم‌تر به نظر می‌رسد، بلکه با اینکه بابت کدام الگوی ترافیک پول می‌دهید. هر دو طراحی کار می‌کنند و هر دو به شکل‌های مختلف و با هزینه‌های مختلف شکست می‌خورند.
پیش از هر چیز روابط همتا را بشمارید
با N سایت، یک شبکه کامل به N ضربدر N منهای یک، تقسیم بر دو، تونل نیاز دارد؛ هاب به N نیاز دارد. در پنج سایت این ده در برابر پنج است که هنوز قابل مدیریت به نظر می‌رسد. در پانزده سایت 105 در برابر پانزده است و تفاوت دیگر حسابی نیست، بلکه نیروی انسانی است.
هر یک از این روابط حالتی را حمل می‌کند که باید مالک آن باشید. در IPsec این یعنی یک انجمن امنیتی، یک هویت، یک کلید یا گواهی، تشخیص همتای مرده و دست‌کم یک مسیر برای هر پیشوند دور. در WireGuard یعنی یک کلید عمومی و AllowedIPs یک بلوک برای هر همتا، که برای هر همتا ارزان‌تر است اما کاملاً بدون کشف می‌آید: سایت جدید در هر حال تغییری در پیکربندی هر سایت موجود است.
بگذارید ترکیب ترافیک تصمیم بگیرد، نه نقشه
اگر ترافیک شعبه‌ها بیشتر درخواست به یک ERP مرکزی یا خوشه فایل باشد، هاب یک سازش نیست، شکل درست است: ترافیک از پیش می‌خواست به آنجا برود و یک نقطه سیاست آسان‌تر از شبکه‌ای از قواعد جفتی قابل حسابرسی است. شبکه کامل زمانی پیچیدگی خود را توجیه می‌کند که شعبه‌ها داده‌ها را با یکدیگر مبادله کنند — تکرار میان دو دفتر، صدا میان سایت‌ها، یک اشتراک CAD که ده‌ها مهندس تمام روز باز می‌کنند.
موارد دشوار در میانه قرار دارند و اکثریت را تشکیل می‌دهند. پیش از بحث اندازه‌گیری کنید، نه اینکه از یک چارت سازمانی حدس بزنید.
| نشانه | به هاب اشاره می‌کند | به شبکه کامل اشاره می‌کند |
|---|---|---|
| ترافیک میان شعبه‌ها | گاه‌به‌گاه، کوچک | غالب، تمام روز |
| تعداد سایت‌ها | رو به رشد، بیش از ده | کوچک و پایدار |
| نرخ تغییر | افزودن‌ها و جابه‌جایی‌های مکرر | کم |
| تحمل خرابی | هاب دوم مقرون‌به‌صرفه است | هر سایت باید تنها دوام بیاورد |
جدول را به‌عنوان عامل برش بخوانید، نه به‌عنوان یک قاعده. سه سطر از چهار سطر در یک جهت معمولاً طراحی را قطعی می‌کند؛ شکاف یعنی طرح ترکیبی، که بیشتر شبکه‌های بالغ در هر حال به آن می‌رسند.
به هاب باید گفت که هدایت کند
دو تونل فعال شعبه-به-هاب دسترسی شعبه-به-شعبه ایجاد نمی‌کند. هاب به هدایت IP فعال، مسیری به هر شبکه شعبه، قاعده‌ای در دیوار آتش که عبور را مجاز کند و مسیر بازگشت محاسبه‌شده نیاز دارد؛ هر شعبه به مسیری برای پیشوندهای سایت دیگر نیاز دارد. روی هاب Linux این net.ipv4.ip_forward=1 به‌همراه FORWARD زنجیره‌ای است که جفت را بی‌صدا رها نمی‌کند، و در IPsec مبتنی بر سیاست این انتخابگرهای ترافیک هستند که زیرشبکه شعبه دور را در دو طرف فهرست می‌کنند. در strongSwan یادداشت‌های هدایت سمت هسته و دیوار آتش را پوشش می‌دهند، وقتی همان لایه‌ای است که کم دارید. یک آزمون ارزان این است که ترافیک را از یک شعبه به سرویسی در شعبه دیگر بفرستید و شمارنده‌های هاب را تماشا کنید؛ قاعده‌ای که هرگز بالا نمی‌رود یعنی ترتیب اشتباه است، نه مسیر.
سیاست مرکزی هم بخش سودمند ماجراست. می‌توان به شعبه‌ها اجازه داد به سرویس‌های مشترک برسند بدون اینکه به هم برسند، و آن ماتریس دسترسی ارزش ثبت صریح را دارد. مسیرهای غایب جایگزین بدی برای قاعده‌ای هستند که کسی بتواند بخواند.
مراقب نسخه نیمه‌کاره باشید: شعبه A از طریق هاب به شعبه B مسیر می‌دهد، هاب در هر دو جهت مسیر می‌دهد و دیوار آتش هاب اتصال‌های جدید از A را مجاز می‌کند اما از B را نه. جهت اول خوب آزمایش می‌شود و دومی معلق می‌ماند، که شبیه خطای مسیریابی است و نیست.
نخست خرابی را طراحی کنید، سپس مسیر عادی
هاب تنها یک وابستگی مشترک و یک گلوگاه ترانزیت است و افزونگی همان جایی است که طراحی‌های هاب معمولاً اشتباه می‌شوند. دو هاب یعنی هر شعبه دو تونل نگه می‌دارد و مسیر بازگشت باید با مسیر خروجی هم‌خوان باشد؛ وقتی نیست، دیوار آتش حالت‌دار پاسخ‌ها را دور می‌ریزد و نشانه، اتصالی است که باز می‌شود و سپس می‌میرد. استقرارهای بزرگ‌تر این را با پروتکل مسیریابی روی تونل‌ها به‌جای پیشوندهای ثابت حل می‌کنند، که ماشین‌آلات بیشتری است اما حدس زدن را حذف می‌کند. هر چه انتخاب کنید، مسیر بازگشت را کنار مسیر خروجی بنویسید، چون نیمه بازگشت همان نیمه‌ای است که هیچ‌کس آزمایش نمی‌کند.
شبکه کامل آن ریسک را پخش می‌کند: قطع پیوند یک سایت، بقیه را جدا نمی‌کند. همچنین جاهایی را که انتخاب مسیر می‌تواند غافلگیرتان کند چند برابر می‌کند، و نشست‌های برنامه هنوز بدون کمک از تغییر مسیر جان سالم به در نمی‌برند.
هیچ یک از این دو طراحی به‌تنهایی یک نشست TCP را در طول جابه‌جایی زنده نگه نمی‌دارد. اگر برنامه نتواند دوباره وصل شود، توپولوژی مشکل شما نیست.
بر پایه هزینه تغییر انتخاب کنید، سپس مسیرها را بررسی کنید
با هاب شروع کنید، چون اشتباه درباره‌اش ارزان‌تر استو برای جفت‌هایی که ترافیکشان آن را توجیه می‌کند تونل‌های مستقیم اضافه کنید. این طرح ترکیبی نشانه ناتوانی در تصمیم نیست؛ طراحی‌ای است که بیشتر سازمان‌ها ظرف یک سال به آن می‌رسند. مهم این است که هر پیوند مستقیم دلیلی اعلام‌شده و یک مالک داشته باشد.
سپس دو نقشه را بررسی کنید، نه یکی. برای مسیر عادی، traceroute از هر سایت به هر پیشوند سرویس و تأیید کنید که گام‌ها با نمودار می‌خوانند. برای مسیر خرابی، یک تونل را خاموش کنید و تکرار کنید، چون مسیری که فقط تا وقتی همه‌چیز بالاست کار می‌کند طراحی نشده، فقط پیکربندی شده است.
هر دو نقشه را همراه ماتریس دسترسی نگه دارید و هنگام افزودن سایت دوباره به آن‌ها برگردید؛ هزینه‌ای که مدیریت می‌کنید هزینه تغییر بعدی است، نه ظرافت تصویر کنونی.