مسیرهای استاتیک یا پروتکل مسیریابی روی VPN سایت به سایت؟
تغییرپذیری پیشوندها، رفتار جابه‌جایی و اشتیاق عملیاتی آن را تعیین می‌کند. بسنجید که درست نگه داشتن هر گزینه چه هزینه‌ای دارد، سپس مسیر خرابی را بیازمایید.
هر دو گزینه بسته‌ها را بین سایت‌ها حمل می‌کنند، پس تصمیم درباره این نیست که کدام پروتکل جدیدتر است، و اندازه تونل هم آن را تعیین نمی‌کند. سه شرط آن را تعیین می‌کنند: چند پیشوند تغییر می‌کند و چند وقت یک‌بار، آیا طراحی به جابه‌جایی خودکار بین مسیرها نیاز دارد، و تیم در ساعت سه بامداد چه مقدار سازوکار لایه کنترل را می‌تواند اداره کند. صادقانه به این‌ها پاسخ دهید و انتخاب معمولاً خودش انجام می‌شود. باقی این نوشته هزینه هر پاسخ است.
سه شرط آن را تعیین می‌کند
شرط اول تغییرپذیری است. چند زیرشبکه پایدار با مالکیت روشن را می‌توان سال‌ها دستی نگهداری کرد و هر مسیر خطی می‌ماند که کسی می‌تواند بخواند و بررسی کند. ده‌ها پیشوند که با آمدن و رفتن پروژه‌ها جابه‌جا می‌شوند مسئله دیگری است، چون هر جابه‌جایی باید به هر دستگاهی برسد که هنوز مسیر قدیمی را به یاد دارد.
شرط دوم رفتار در برابر خرابی است. وقتی یک مسیر پشتیبان باید بدون آنکه انسانی متوجه شود فعال شود، چیزی باید خرابی را تشخیص دهد و مسیر را پس بگیرد. مسیریابی استاتیک این کار را فقط از طریق ردیابی یا نصب شرطی می‌تواند انجام دهد، و فقط برای خرابی‌هایی که از پیش در نظر گرفته‌اید.
شرط سوم اشتیاق به یک لایه کنترل دوم است. پروتکل مسیریابی نشست‌ها، احراز هویت، فیلترها و سیاست انتخاب را اضافه می‌کند و هر یک از این‌ها به پایش و فرایند تغییر نیاز دارد. این هزینه عملیاتی دائمی است، نه یک کار پیکربندی یک‌باره.
| Condition | Points to static | Points to dynamic |
|---|---|---|
| Prefix churn | Rare, few, stable | Frequent, many, moving |
| Failover | Manual or tracked | Automatic withdrawal |
| Operations | No routing staff | Protocol monitoring exists |
جدول زیر بند سوم نسخه کوتاه است و سه بخش بعد از آن توضیح می‌دهد که چرا هر ردیف جای خودش قرار دارد. پیش از انتخاب، ردیف‌ها را با شمار سایت خودتان بسنجید، چون تصمیمی که هزینه عملیاتی را نادیده بگیرد فقط نیمی از تصمیم است.
مسیریابی استاتیک واقعاً چه هزینه‌ای دارد
مسیر استاتیک باید در دو طرف تونل درست باشد. افزودن یک زیرشبکه یعنی ویرایش دروازه دور، دروازه محلی و معمولاً مسیر بازگشت، و فراموش کردن هر یک از آن‌ها خرابی یک‌طرفه‌ای می‌سازد که مانند یک اشکال برنامه به نظر می‌رسد. تیم برنامه زمان‌های انتظار می‌بیند در حالی که تیم شبکه مسیری را می‌بیند که وجود دارد و ظاهراً سالم است. هیچ‌کدام اشتباه نمی‌کنند و به همین دلیل جای این خرابی این‌قدر دیر پیدا می‌شود.
یک ورودی استاتیک پس از ناپدید شدن مسیر زیرش هم نصب‌شده می‌ماند. مگر اینکه بستر ردیابی فراهم کند، مسیر همچنان به گام بعدی اشاره می‌کند که دیگر ارسال نمی‌کند و ترافیک به جای جابه‌جایی ناپدید می‌شود. آن سکوت همان هزینه‌ای است که با انتخاب گزینه ساده می‌پذیرید.
روش ردیابی را کنار هر مسیر بنویسید، یادداشت کنید کدام خرابی‌ها را پوشش می‌دهد و فهرست را همراه پیکربندی تونل نگه دارید. وگرنه قطعی بعدی را کاربر کشف می‌کند نه شبکه، و این همیشه کشف گران‌تر است.
مسیریابی دینامیک واقعاً چه هزینه‌ای دارد
پروتکل پیشوندهای جدید را اعلام می‌کند، پیشوندهای غیرقابل دسترس را پس می‌گیرد و ترجیح میان مسیرها را بیان می‌کند. این واقعاً مفید است وقتی چند سایت یا تونل‌های افزونه در غیر این صورت در هر تغییر به ویرایش هماهنگ نیاز داشتند. این همچنین دلیل آن است که پروتکل می‌تواند در بدترین لحظه شما را غافلگیر کند. هر یک از این کارها تغییر وضعیتی است که خودتان انجام نداده‌اید.
دو وضعیت می‌سازد که می‌توانند با هم اختلاف داشته باشند. تونل می‌تواند بالا باشد در حالی که نشست مسیریابی پایین است، و نشست می‌تواند بالا باشد در حالی که اعلام‌هایش زیرشبکه مورد نیاز برنامه را جا می‌اندازند. هر دو مانند شبکه‌ای به نظر می‌رسند که نیمه‌کاره کار می‌کند و هیچ‌کدام از صفحه وضعیت تونل دیده نمی‌شود.
بنابراین فیلترها و سیاست بخشی از طراحی می‌شوند نه یک فکر بعدی. پروتکلی که همه‌چیز را اعلام می‌کند سرانجام چیزی نادرست اعلام خواهد کرد و پیشوند نادرست سریع‌تر از کسی که می‌تواند اصلاحش کند سفر می‌کند. فیلترها را پیش از فعال شدن نخستین نشست بنویسید تا نخستین اعلام از همان آغاز آگاهانه باشد.
کنترل کنید نشست مسیریابی چه می‌تواند بگوید
فهرست پیشوندهای مجاز را برای هر همتا تعیین کنید و آن را در ورودی اعمال کنید، چون یک فیلتر خروجی نمی‌تواند مانع شود که همتا مسیر پیش‌فرض برای شما بفرستد. مسیرهای پیش‌فرض و تجمیع‌ها اشتباه‌های گران اینجا هستند: می‌توانند بی‌صدا مسیرهای بی‌ربط را با یک ورودی آموخته‌شده که مشروع به نظر می‌رسد جایگزین کنند. آن‌ها را صریحاً رد کنید مگر اینکه طراحی واقعاً آن‌ها را بخواهد.
پیش از بالا آمدن نخستین نشست، سایت مالک را کنار هر شبکه بنویسید، چون این نگاشت منبع فهرست فیلترها است نه آرایه‌ای برای مستندات. بدون آن، کسی که فیلتری را ویرایش می‌کند باید حدس بزند کدام سایت باید پیشوند را اعلام کند.
بازتوزیع بین دو پروتکل جایی است که حلقه‌ها آغاز می‌شوند و همان پیشوند دو بار با ویژگی‌هایی می‌رسد که پاک مقایسه نمی‌شوند. بازتوزیع را تا زمانی که نیاز مشخصی آن را تحمیل نکند از طراحی بیرون نگه دارید، و اگر باید وجود داشته باشد، مسیرها را در مرز علامت بزنید و فیلتر کنید.
رابط‌های تونل مبتنی بر مسیر نمایش مسیریابی دینامیک را آسان‌تر می‌کنند، چون تونل به رابطی با مسیرها تبدیل می‌شود نه سیاستی که انتخابگرها را تطبیق می‌دهد. این پرسش دامنه همتا را برنمی‌دارد: انتخابگرهای IPsec هنوز باید ترافیکی را که می‌خواهید مسیریابی کنید مجاز کنند.
مسیر خرابی را بیازمایید، نه مسیر خوش‌بینانه را
هر چه انتخاب کنید، یک پیوند بالاسری را پایین بیاورید و تأیید کنید که ترافیک جابه‌جا می‌شود یا همان‌گونه که مستند کرده‌اید شکست می‌خورد. طراحی‌ای که فقط با دو مسیر سالم آزموده شده باشد طراحی‌ای است که اصلاً آزموده نشده است. زمان تشخیص را همان‌جا اندازه بگیرید، چون عددی که اندازه گرفتید همان عددی است که کاربران تجربه خواهند کرد.
سپس مسیر بازگشت را مستقل تأیید کنید، چون مسیریابی نامتقارن روی VPN رایج است و تا زمانی که دستگاه حالت‌دار پاسخ‌ها را دور نریزد نامرئی می‌ماند. جریانی که در یک جهت کار می‌کند فقط نیمی از مسیر را اثبات می‌کند.
ترتیب کار: پیشوندها را بشمارید، تصمیم بگیرید خرابی‌ها چگونه تشخیص داده شوند، بررسی کنید چه کسی می‌تواند پروتکل را اداره کند، کنترل کنید چه چیزی اعلام می‌شود، سپس یک قطعی را سرتاسر بیازمایید. هر گام واقعیتی می‌سازد که گام بعدی به آن نیاز دارد.