طراحی سناریوی Multi-ISP و Failover اینترنت با فایروال Cisco ASA

در بسیاری از سازمان‌های امروزی، اینترنت دیگر یک مسیر خروجی ساده برای وب‌گردی کاربران نیست. بستر اصلی سرویس‌دهی، ارتباط با سامانه‌های ابری، VPN کاربران راه‌دور، ارتباط با شعب، سرویس‌های مالی و حتی سیستم‌های مانیتورینگ بر پایه اینترنت کار می‌کنند. در چنین شرایطی، قطع شدن اینترنت حتی برای چند دقیقه می‌تواند منجر به توقف عملیات یا ایجاد خسارت مستقیم شود. به همین دلیل طراحی سناریوی Multi-ISP و Failover با استفاده از Cisco ASA یک تصمیم زیرساختی جدی است، نه یک قابلیت جانبی.

در تجربه پروژه‌های مختلف، بسیاری از سازمان‌ها تنها زمانی به فکر Multi-ISP افتاده‌اند که با قطعی طولانی ISP مواجه شده‌اند. اما طراحی اصولی این سناریو باید پیش از وقوع بحران انجام شود، با در نظر گرفتن رفتار ترافیک، نوع سرویس‌های منتشرشده و الزامات VPN.

تحلیل نیازمندی‌ها پیش از طراحی فنی

مرحله تحلیل نیازمندی‌ها مهم‌ترین بخش طراحی Multi-ISP است، چون تقریباً تمام مشکلاتی که بعدها در زمان Failover یا Incident دیده می‌شود، ریشه در همین مرحله دارد. اگر این فاز سطحی انجام شود، حتی بهترین کانفیگ هم در عمل پایدار نخواهد بود. طراحی فنی باید خروجی یک تحلیل دقیق عملیاتی باشد، نه صرفاً یک تصمیم تکنیکی.

اولین موضوع، شناخت دقیق نوع سرویس اینترنت است. باید مشخص شود هر ISP چه نوع آدرس‌دهی ارائه می‌دهد. آیا IP عمومی استاتیک اختصاص می‌دهد یا اتصال از طریق CGNAT انجام می‌شود. آیا امکان دریافت رنج IP وجود دارد یا تنها یک IP در اختیار شما قرار می‌گیرد. این موضوع مستقیماً روی طراحی NAT، Publish سرویس‌ها و VPN اثر می‌گذارد. در یکی از پروژه‌های سازمانی، لینک دوم دارای IP داینامیک بود و این موضوع در طراحی VPN لحاظ نشده بود. در زمان قطعی لینک اصلی، تونل‌ها بالا نیامدند چون Peer سمت مقابل روی IP ثابت تنظیم شده بود. همین مسئله باعث قطع ارتباط بین شعب شد.

موضوع دوم بررسی سرویس‌های وابسته به اینترنت است. باید بدانید چه سیستم‌هایی به اینترنت وابسته‌اند و حساسیت هر کدام چقدر است. برای مثال، اگر سازمان از سرویس‌های مالی برخط یا APIهای بانکی استفاده می‌کند، حتی چند دقیقه قطعی می‌تواند فرآیندهای حیاتی را متوقف کند. در مقابل، اگر تنها دسترسی کاربران به وب عمومی مدنظر باشد، سطح حساسیت پایین‌تر است. این تحلیل تعیین می‌کند که آیا مدل Active-Standby کافی است یا باید به سمت معماری Active-Active با توزیع بار رفت.

نکته مهم دیگر، بررسی سرویس‌های Publish شده است. اگر وب‌سرور، میل‌سرور، یا هر سرویس دیگری روی اینترنت منتشر شده باشد، باید مشخص شود آیا دسترسی از هر دو ISP باید امکان‌پذیر باشد یا خیر. همچنین باید بررسی شود کاربران خارجی چگونه به سرویس دسترسی پیدا می‌کنند. آیا DNS داخلی است یا عمومی. TTL رکوردها چقدر است. در یکی از پروژه‌های فروش آنلاین، TTL رکورد DNS روی 24 ساعت تنظیم شده بود. هنگام Failover، کاربران تا ساعت‌ها به IP قدیمی متصل می‌شدند و تصور می‌کردند سایت از دسترس خارج شده است. این مشکل نه به ASA مربوط بود و نه به Routing، بلکه به تحلیل ناقص نیازمندی‌ها بازمی‌گشت.

موضوع VPN نیز باید به‌صورت دقیق بررسی شود. اگر VPN Site-to-Site دارید، باید مشخص شود آیا دو سمت ارتباط آمادگی پشتیبانی از IP دوم را دارند یا خیر. اگر Remote Access VPN دارید، آیا کاربران می‌توانند در صورت تغییر IP به‌راحتی مجدداً متصل شوند. در یکی از پروژه‌های چندملیتی، لینک دوم فعال شد اما کاربران Remote VPN نمی‌توانستند به IP جدید متصل شوند چون Client Profile به‌روزرسانی نشده بود. این موضوع باعث سردرگمی کاربران و افزایش فشار روی تیم پشتیبانی شد.

تحلیل ظرفیت نیز بخش مهمی از نیازمندی‌هاست. باید مصرف پهنای باند در ساعات اوج اندازه‌گیری شود. اگر لینک پشتیبان ظرفیت کمتری دارد، باید مشخص شود در زمان Failover چه ترافیکی اولویت دارد و آیا نیاز به QoS وجود دارد یا خیر. در یک سازمان صنعتی، لینک پشتیبان تنها 50 درصد ظرفیت لینک اصلی را داشت. هنگام قطعی، ترافیک Backup شبانه همچنان فعال بود و باعث اشباع لینک شد، در حالی که سرویس‌های حیاتی دچار اختلال شدند. اگر در مرحله تحلیل این موضوع دیده می‌شد، سیاست کنترلی برای محدود کردن ترافیک غیرحیاتی تعریف می‌شد.

انتخاب مدل معماری Active-Standby یا Active-Active

انتخاب بین معماری Active-Standby و Active-Active یکی از تصمیم‌های کلیدی در طراحی Multi-ISP با استفاده از Cisco ASA است. این تصمیم صرفاً به این برنمی‌گردد که دو لینک اینترنت دارید یا نه، بلکه به ماهیت ترافیک، حساسیت سرویس‌ها، ظرفیت لینک‌ها، سطح مهارت تیم عملیاتی و حتی مدل کسب‌وکار سازمان وابسته است. اگر این انتخاب بدون تحلیل انجام شود، یا هزینه اضافی ایجاد می‌کند یا در زمان بحران به پیچیدگی غیرضروری منجر می‌شود.

در مدل Active-Standby، یک لینک به‌عنوان مسیر اصلی تعریف می‌شود و تمام ترافیک در شرایط عادی از آن عبور می‌کند. لینک دوم در حالت آماده‌به‌کار قرار دارد و فقط در صورت تشخیص خرابی لینک اصلی فعال می‌شود. مزیت اصلی این مدل سادگی، قابلیت پیش‌بینی رفتار شبکه و سهولت عیب‌یابی است. مسیر خروجی مشخص است، NAT ساده‌تر مدیریت می‌شود و رفتار VPNها پایدارتر خواهد بود. در بسیاری از پروژه‌های سازمانی، این مدل به دلیل همین پایداری عملیاتی انتخاب شده است.

اما همین سادگی می‌تواند در برخی سناریوها محدودیت ایجاد کند. اگر هر دو لینک ظرفیت بالایی داشته باشند و هزینه قابل توجهی برای آن‌ها پرداخت شود، استفاده از تنها یکی از آن‌ها در حالت عادی ممکن است از نظر اقتصادی منطقی نباشد. همچنین در سازمان‌هایی که مصرف پهنای باند بالاست، نگه داشتن یک لینک بیکار ممکن است به معنای استفاده ناکارآمد از منابع باشد.

در مقابل، مدل Active-Active تلاش می‌کند از هر دو لینک به‌صورت هم‌زمان استفاده کند. این استفاده می‌تواند به شکل تقسیم ترافیک بر اساس نوع سرویس، رنج IP یا حتی Policy Based Routing باشد. برای مثال ممکن است ترافیک کاربران عمومی از ISP اول و ترافیک Backup یا آپدیت نرم‌افزار از ISP دوم عبور کند. در ظاهر این مدل بهره‌وری بالاتری دارد، اما در عمل پیچیدگی آن بسیار بیشتر است.

یکی از چالش‌های جدی Active-Active، مدیریت NAT است. چون هر لینک دارای Public IP متفاوت است، باید ترجمه آدرس‌ها دقیقاً مطابق مسیر خروجی انجام شود. اگر ترافیک رفت از ISP اول خارج شود اما پاسخ برگشتی از ISP دوم دریافت شود، Session ناپایدار خواهد شد. در یکی از پروژه‌های دیتاسنتری، تقسیم ترافیک بدون در نظر گرفتن Symmetric Routing باعث ایجاد Session Dropهای تصادفی شد که تشخیص آن ساعت‌ها زمان برد.

موضوع دیگر، تحلیل Incident در معماری Active-Active است. در مدل Active-Standby، وقتی اختلالی رخ می‌دهد مسیر مشخص است و عیب‌یابی ساده‌تر انجام می‌شود. اما در Active-Active ابتدا باید مشخص شود ترافیک از کدام لینک عبور کرده است. در یک پروژه SaaS، هنگام افزایش Latency، تیم شبکه تصور می‌کرد مشکل از ISP اول است، در حالی که بخش عمده ترافیک حساس از ISP دوم عبور می‌کرد. نبود مستندسازی دقیق تقسیم ترافیک باعث طولانی شدن فرآیند تشخیص شد.

همچنین باید به رفتار Failover در مدل Active-Active توجه کرد. در این معماری، اگر یکی از لینک‌ها قطع شود، باید مشخص شود آیا کل ترافیک به لینک دیگر منتقل می‌شود یا فقط بخشی از آن. اگر ظرفیت لینک باقی‌مانده برای تحمل کل بار کافی نباشد، در زمان Failover با اشباع پهنای باند مواجه خواهید شد. بنابراین تحلیل ظرفیت در این مدل حیاتی‌تر از Active-Standby است.

پیاده‌سازی Failover مبتنی بر SLA Monitor

در Cisco ASA رایج‌ترین روش برای پیاده‌سازی Failover اینترنت استفاده از IP SLA و Track Object است. ASA به‌صورت دوره‌ای یک مقصد مشخص را Ping می‌کند. در صورت عدم دریافت پاسخ، Route پیش‌فرض حذف شده و مسیر پشتیبان فعال می‌شود.

نکته مهم انتخاب مقصد مانیتورینگ است. بسیاری از مهندسان تنها Gateway ISP را بررسی می‌کنند. اما ممکن است Gateway در دسترس باشد در حالی که ارتباط اینترنت دچار اختلال شده است. در یک پروژه بانکی، همین اشتباه باعث شد Failover فعال نشود زیرا SLA همچنان پاسخ دریافت می‌کرد. بهترین رویکرد مانیتور کردن یک IP معتبر خارج از شبکه ISP یا حتی چند مقصد مختلف است تا اطمینان از قطع واقعی ارتباط حاصل شود.

مدیریت NAT در سناریوی Multi-ISP

چالش اصلی در طراحی Multi-ISP معمولاً در NAT ظاهر می‌شود. هر ISP دارای Public IP متفاوت است و باید NAT به‌صورت Interface-Specific تعریف شود. ASA بر اساس Route فعال، ترجمه مناسب را اعمال می‌کند. اگر NAT برای هر دو Interface تعریف نشده باشد، در زمان Failover کاربران اینترنت خواهند داشت اما Sessionهای جدید برقرار نمی‌شوند.

در یکی از پروژه‌های دیتاسنتری، NAT تنها برای Interface اصلی تعریف شده بود. هنگام قطع لینک اول، کاربران داخلی نمی‌توانستند به اینترنت متصل شوند زیرا ترجمه آدرس برای Interface دوم وجود نداشت. اصلاح NAT مشکل را برطرف کرد.

موضوع پیچیده‌تر زمانی است که سرویس داخلی Publish شده باشد. اگر وب‌سرور روی IP عمومی ISP اول منتشر شده باشد، در زمان Failover کاربران همچنان به IP قبلی متصل می‌شوند مگر اینکه DNS به‌درستی طراحی شده باشد. در یک فروشگاه آنلاین، TTL رکورد DNS بالا بود و پس از قطعی لینک اصلی، کاربران برای مدت طولانی به IP از دسترس خارج متصل می‌شدند. کاهش TTL یا استفاده از DNS هوشمند این مشکل را حل کرد.

طراحی VPN در معماری Multi-ISP

در سناریوهایی که VPN Site-to-Site یا Remote Access وجود دارد، طراحی Multi-ISP پیچیده‌تر می‌شود. هر تونل باید امکان برقراری روی هر دو لینک را داشته باشد یا حداقل مکانیزم Failover در هر دو سمت هماهنگ باشد. عدم هماهنگی در دو سمت ارتباط یکی از رایج‌ترین دلایل Failure تونل‌ها است.

در یک پروژه چندسایته، لینک اصلی در یک سمت قطع شد اما سمت مقابل همچنان تلاش می‌کرد به IP قبلی متصل شود. چون Peer دوم تعریف نشده بود، تونل هرگز برقرار نشد. طراحی صحیح باید شامل تعریف Peer ثانویه و تست عملی در هر دو سمت باشد.

استفاده از Policy Based Routing در سناریوهای پیشرفته

در برخی سازمان‌ها نیاز است بخشی از ترافیک حتی در حالت عادی از ISP دوم عبور کند. برای مثال ترافیک Backup یا به‌روزرسانی سیستم‌ها می‌تواند از لینک دوم ارسال شود. در نسخه‌های جدید ASA امکان استفاده از Policy Based Routing فراهم است. این قابلیت اجازه می‌دهد بر اساس ACL مشخص شود کدام ترافیک از چه Gatewayای عبور کند.

با این حال باید توجه داشت که اضافه شدن PBR پیچیدگی تحلیل مسیر را افزایش می‌دهد. در یک پروژه Enterprise، وجود PBR باعث شد تیم عملیات در زمان قطعی لینک اصلی به‌اشتباه تصور کند مشکل از ISP دوم است، در حالی که بخشی از ترافیک طبق طراحی از آن مسیر عبور می‌کرد.

تست عملی و اعتبارسنجی سناریو

پیاده‌سازی بدون تست واقعی تقریباً بی‌فایده است. باید سناریوهای مختلف شامل قطع فیزیکی لینک، قطع Gateway، اختلال DNS و بازگشت لینک اصلی آزمایش شوند. همچنین باید بررسی شود که در زمان بازگشت لینک اصلی، آیا Sessionهای فعال Drop می‌شوند یا خیر.

در یک پروژه مالی، هنگام بازگشت لینک اصلی، به‌دلیل فعال بودن Preemption سریع، کاربران VPN قطع می‌شدند. با تنظیم Delay مناسب در Track Object و کنترل زمان بازگشت مسیر، این مشکل برطرف شد.

ظرفیت لینک پشتیبان و مدیریت پهنای باند

بسیاری از سازمان‌ها لینک دوم را با ظرفیت کمتر تهیه می‌کنند. اگر در زمان Failover تمام ترافیک سازمان روی لینکی با ظرفیت پایین‌تر منتقل شود، احتمال Saturation بسیار بالاست. در یک پروژه صنعتی، لینک پشتیبان تنها ۴۰ درصد ظرفیت لینک اصلی را داشت و هنگام Failover سرویس‌های VoIP دچار قطعی و Packet Loss شدند. تحلیل مصرف پهنای باند و طراحی QoS مناسب باید بخشی از سناریوی Multi-ISP باشد.

جمع‌بندی

طراحی Multi-ISP و Failover اینترنت با Cisco ASA فرآیندی چندلایه است که Routing، NAT، VPN، DNS و مانیتورینگ را در بر می‌گیرد. اضافه کردن یک Route دوم به‌تنهایی تضمین‌کننده پایداری نیست. یک طراحی حرفه‌ای باید رفتار شبکه را در شرایط بحرانی پیش‌بینی کند، تست شود و مستندسازی دقیق داشته باشد.

تفاوت میان یک پیاده‌سازی سطحی و یک معماری پایدار در جزئیات نهفته است. اگر این جزئیات به‌درستی دیده شوند، زیرساخت اینترنت سازمان می‌تواند در برابر قطعی‌های ISP مقاوم باشد و سرویس‌های حیاتی بدون اختلال ادامه یابند.