در شبکههای سازمانی، فایروال نقطه گلوگاه ترافیک است. اگر این نقطه از دسترس خارج شود، عملاً کل سازمان دچار قطعی ارتباط میشود. به همین دلیل پیادهسازی High Availability یا HA در فایروال نه یک قابلیت لوکس، بلکه یک الزام معماری است. در اکوسیستم Cisco، هم در Cisco Adaptive Security Appliance و هم در Cisco Firepower Threat Defense امکان پیادهسازی HA وجود دارد، اما مدل اجرا و جزئیات آن تفاوتهایی دارد.
در این مقاله، پیادهسازی HA را از منظر معماری، سناریوی عملی، مراحل کانفیگ و نکات عیبیابی در هر دو پلتفرم بررسی میکنیم.
وقتی از High Availability در فایروال صحبت میکنیم، منظور فقط داشتن یک دستگاه دوم به عنوان بکاپ نیست. HA در سطح فایروال یعنی طراحی سیستمی که در صورت بروز خرابی سختافزاری، نرمافزاری یا حتی اختلال در یک اینترفیس حیاتی، سرویسهای شبکه بدون وقفه یا با کمترین وقفه ادامه پیدا کنند. چون فایروال معمولاً در مرز شبکه قرار دارد، خرابی آن برابر با قطع اینترنت، VPN، دسترسی به سرورها و حتی ارتباط بین شعب خواهد بود. بنابراین HA در این نقطه اهمیت استراتژیک دارد.
در سادهترین مدل، ساختار HA شامل دو دستگاه است: Active و Standby. دستگاه Active تمام ترافیک را پردازش میکند و دستگاه Standby وضعیت Active را مانیتور میکند. اگر Active از دسترس خارج شود، Standby جای آن را میگیرد. اما آنچه HA را حرفهای میکند، مفهوم Stateful Failover است. در این حالت، جدول Sessionها، NAT Translationها، ارتباطهای TCP فعال و حتی تونلهای VPN بین دو دستگاه همگامسازی میشوند. این یعنی وقتی Failover رخ میدهد، کاربری که در حال دانلود فایل یا اتصال VPN است، ارتباطش قطع نمیشود یا فقط یک وقفه بسیار کوتاه تجربه میکند.
در مقابل، اگر HA فقط در سطح Device-Level و بدون Sync وضعیت اجرا شود، در زمان سوییچ تمام Sessionهای فعال از بین میروند و کاربران باید اتصال مجدد برقرار کنند. در محیطهای حساس مانند دیتاسنتر یا سازمانهای مالی، این موضوع قابل قبول نیست. به همین دلیل لینک Stateful Sync یکی از ارکان اصلی طراحی HA محسوب میشود.
مفهوم مهم دیگر، Health Monitoring است. در ساختار HA فقط خاموش شدن دستگاه معیار Failover نیست. پارامترهایی مانند Down شدن یک اینترفیس حیاتی، از دست رفتن Default Route یا حتی Fail شدن یک سرویس داخلی میتواند باعث Trigger شدن Failover شود. بنابراین باید مشخص کنید چه شرایطی به عنوان Failure شناخته شود. اگر این تنظیمات بیش از حد حساس باشند، ممکن است Failoverهای غیرضروری رخ دهد. اگر بیش از حد ساده باشند، ممکن است خرابی واقعی دیر تشخیص داده شود.
از نظر توپولوژی، HA معمولاً نیازمند لینک اختصاصی بین دو فایروال است. این لینک برای تبادل Heartbeat و همگامسازی وضعیت استفاده میشود. استفاده از لینک مشترک با ترافیک کاربران توصیه نمیشود، چون افزایش Latency یا Packet Loss در این مسیر میتواند باعث تشخیص اشتباه خرابی شود.
همچنین باید به مفهوم Failback توجه کرد. زمانی که دستگاه اصلی پس از خرابی دوباره آنلاین میشود، آیا باید به صورت خودکار دوباره Active شود یا خیر؟ در برخی سناریوها Auto-Failback فعال است و در برخی دیگر ترجیح داده میشود دستگاه جایگزین همچنان Active باقی بماند تا زمان Maintenance برنامهریزیشده.
در محیطهای پیچیدهتر، مدل Active/Active نیز وجود دارد که در آن هر دو دستگاه همزمان ترافیک را پردازش میکنند، اما معمولاً این مدل در سناریوهای Multi-Context یا طراحیهای خاص استفاده میشود و پیچیدگی بیشتری دارد.
در Cisco Adaptive Security Appliance، HA معمولاً به صورت Active/Standby پیادهسازی میشود. دو دستگاه باید از نظر مدل سختافزاری، نسخه نرمافزار، میزان RAM و لایسنس یکسان باشند.
هر دو دستگاه باید به یکدیگر از طریق یک لینک Failover متصل شوند. این لینک برای همگامسازی وضعیت دستگاه و مانیتورینگ سلامت استفاده میشود. همچنین یک لینک Stateful Failover برای Sync کردن جدول Sessionها پیشنهاد میشود تا در زمان سوییچ، ارتباطهای فعال قطع نشوند.
IPهای Failover و Standby باید روی اینترفیسها تعریف شوند. هر اینترفیس عملیاتی در ASA در حالت HA دارای دو IP است؛ یکی برای Active و یکی برای Standby.
روی دستگاه Primary:
روی دستگاه Secondary:
پس از اجرای دستورات، کانفیگ از Primary به Secondary Sync میشود.
با دستور زیر میتوان وضعیت HA را بررسی کرد:
در صورت مشاهده Active و Standby Ready، ساختار HA آماده است.
در Cisco Firepower Threat Defense، پیادهسازی HA معمولاً از طریق Cisco Firepower Management Center انجام میشود.
دو دستگاه FTD باید هممدل و دارای نسخه نرمافزاری یکسان باشند. اینترفیسهای Data و Management باید به درستی کابلکشی شده باشند. لینک Failover برای Sync کردن وضعیت و لینک Stateful برای Sync جدول اتصالها باید تعریف شود.
در FTD معمولاً HA به صورت Active/Standby پیادهسازی میشود.
در FMC وارد بخش Devices شوید و گزینه Add High Availability را انتخاب کنید. دستگاه Primary و Secondary را مشخص کرده و اینترفیس Failover را تعیین کنید.
پس از تأیید، FMC فرآیند Join کردن دو دستگاه را انجام میدهد و کانفیگ به صورت متمرکز روی هر دو اعمال میشود.
پس از Deploy، میتوان وضعیت HA را در FMC مشاهده کرد.
هرچند هر دو پلتفرم Cisco Adaptive Security Appliance و Cisco Firepower Threat Defense از High Availability پشتیبانی میکنند، اما نحوه پیادهسازی، مدیریت و حتی رفتار آنها در سناریوهای Failover تفاوتهای مهمی دارد. درک این تفاوتها برای طراحی درست معماری بسیار ضروری است، چون تجربه عملیاتی در این دو پلتفرم یکسان نیست.
اولین تفاوت، مدل مدیریتی است. در ASA، HA عمدتاً از طریق CLI روی خود دستگاهها پیکربندی میشود و پس از فعالسازی Failover، کل کانفیگ از دستگاه Primary به Secondary Sync میشود. این Sync به صورت مستقیم بین دو دستگاه انجام میشود و نیازی به سیستم مدیریتی جداگانه ندارد. اما در Firepower، ساختار HA معمولاً از طریق Cisco Firepower Management Center تعریف و کنترل میشود. یعنی شما HA Pair را در FMC ایجاد میکنید و Deploy انجام میدهید. بنابراین FMC در چرخه عملیاتی نقش پررنگتری دارد.
دومین تفاوت مربوط به نوع کانفیگ و زمان Deploy است. در ASA، تغییرات کانفیگ تقریباً بلافاصله روی دستگاه Active اعمال میشود و به Standby Sync میگردد. اما در Firepower، هر تغییری باید در FMC انجام شود و سپس Deploy گردد. این Deploy ممکن است بسته به حجم Policy چند دقیقه طول بکشد. در محیطهایی که تغییرات مکرر دارند، این تفاوت در Workflow کاملاً محسوس است.
سومین تفاوت به پیچیدگی Featureها برمیگردد. در ASA، HA بیشتر بر پایه Sync تنظیمات فایروال، NAT و VPN است. اما در Firepower علاوه بر این موارد، Intrusion Policy، URL Filtering، SSL Decryption و سایر ماژولهای NGFW نیز باید هماهنگ باشند. این موضوع باعث میشود فرآیند Join کردن HA Pair در Firepower حساستر و زمانبرتر باشد، بهویژه اگر نسخه نرمافزار یا Signatureها دقیقاً یکسان نباشند.
چهارمین تفاوت مربوط به Multi-Context است. در ASA امکان پیادهسازی Active/Active در سناریوهای Multi-Context وجود دارد که هر دستگاه بخشی از Contextها را Active نگه میدارد. در Firepower چنین مدلی به شکل کلاسیک ASA وجود ندارد و اغلب پیادهسازیها به صورت Active/Standby هستند. بنابراین اگر طراحی شما نیازمند Active/Active واقعی در سطح Context باشد، ASA انعطاف بیشتری ارائه میدهد.
پنجمین تفاوت در فرآیند عیبیابی است. در ASA ابزارهای CLI مانند show failover و show interface بسیار سریع و مستقیم وضعیت HA را نمایش میدهند. در Firepower، علاوه بر CLI، باید وضعیت HA را در FMC نیز بررسی کنید. اگر FMC از دسترس خارج شود، مدیریت HA پیچیدهتر میشود، هرچند خود FTD همچنان به کار ادامه میدهد.
ششمین تفاوت در Upgrade فرآیند است. در ASA میتوان با روشهای مشخصی Upgrade مرحلهای انجام داد. در Firepower، ارتقا معمولاً از طریق FMC مدیریت میشود و ترتیب Upgrade بین FMC و FTDها باید دقیق رعایت شود. در محیط HA، این فرآیند نیازمند برنامهریزی دقیقتری است تا Downtime به حداقل برسد.
فرض کنید یک سازمان متوسط با حدود ۳۰۰ کاربر دارید که اینترنت، VPN کاربران راهدور و ارتباط با یک شعبه دیگر همگی از طریق فایروال مرزی عبور میکند. این سازمان یک لینک اینترنت اصلی و یک لینک پشتیبان دارد و چند سرور حیاتی مانند ERP و فایلسرور در دیتاسنتر داخلی مستقر هستند. در چنین معماریای، فایروال یک Single Point of Failure محسوب میشود. اگر دستگاه از کار بیفتد، عملاً کل سازمان از اینترنت و سرویسهای بیرونی جدا میشود و کاربران راهدور نیز قطع خواهند شد.
در این سناریو تصمیم گرفته میشود دو دستگاه Cisco Adaptive Security Appliance یا Cisco Firepower Threat Defense به صورت Active/Standby پیادهسازی شوند. هر دو دستگاه در رک یکسان اما روی دو منبع برق مجزا نصب میشوند. لینک Failover و لینک Stateful Sync از طریق یک سوئیچ داخلی مجزا برقرار میشود تا ترافیک همگامسازی با ترافیک کاربران تداخل نداشته باشد.
در طراحی IP، برای هر اینترفیس عملیاتی دو IP در نظر گرفته میشود. یک IP به عنوان Active و یک IP به عنوان Standby. Gateway داخلی و روتر مرزی فقط IP Active را به عنوان Next-Hop میشناسند. در صورت Failover، IP مجازی یا Active به صورت خودکار روی دستگاه دوم بالا میآید و شبکه متوجه تغییر نمیشود.
از نظر عملیاتی، NAT و VPN نیز در ساختار HA باید Stateful باشند. فرض کنید ۵۰ کاربر از طریق VPN متصل هستند. اگر Failover بدون Sync وضعیت انجام شود، تمام این تونلها قطع خواهند شد و کاربران باید دوباره Login کنند. اما با فعال بودن Stateful Failover، جدول Session و وضعیت VPN بین دو دستگاه همگام میشود و هنگام سوییچ، ارتباطها پایدار میمانند یا فقط یک وقفه کوتاه چندثانیهای ایجاد میشود.
پس از پیادهسازی، تست عملی انجام میشود. ابتدا وضعیت HA بررسی میشود تا یکی Active و دیگری Standby Ready باشد. سپس در زمان Maintenance برنامهریزیشده، برق دستگاه Active قطع میشود یا اینترفیس حیاتی آن Shutdown میشود. در این لحظه باید مشاهده شود که دستگاه Standby در مدت کوتاه Active شده و کاربران اینترنت و VPN همچنان دسترسی دارند. همزمان مصرف CPU و وضعیت Interfaceها بررسی میشود تا از عملکرد صحیح اطمینان حاصل گردد.
در این سازمان، یک نکته مهم دیگر نیز در نظر گرفته میشود. لینک اینترنت پشتیبان به روتر جداگانهای متصل است. بنابراین Health Monitoring روی Default Route یا Interface WAN فعال میشود تا اگر لینک اینترنت اصلی Down شود، Failover فقط در سطح لینک انجام نشود، بلکه دستگاه سالم همچنان Active باقی بماند و فقط مسیر تغییر کند. این موضوع از Failover غیرضروری کل دستگاه جلوگیری میکند.
همچنین برنامه دورهای تست Failover تعریف میشود. هر شش ماه یکبار، در بازه Maintenance، سناریوی قطع دستگاه شبیهسازی میشود تا اطمینان حاصل شود HA همچنان بهدرستی کار میکند. بسیاری از سازمانها HA را پیادهسازی میکنند اما هرگز آن را تست نمیکنند، در نتیجه هنگام خرابی واقعی، رفتار پیشبینینشده مشاهده میشود.
لینک Failover باید پایدار و کمLatency باشد. استفاده از VLAN مشترک با ترافیک کاربران توصیه نمیشود.
مانیتورینگ وضعیت HA باید به صورت دورهای انجام شود. دستور show failover در ASA و بررسی Health Monitor در FMC برای FTD اهمیت دارد.
نسخه نرمافزار دو دستگاه باید دقیقاً یکسان باشد. حتی Patch Level متفاوت میتواند باعث Fail شدن Join شود.
همچنین بهتر است تست Failover به صورت دورهای در زمان Maintenance انجام شود تا از آمادگی ساختار اطمینان حاصل گردد.
پیادهسازی High Availability در فایروالهای سیسکو، چه در ASA و چه در Firepower، بخش حیاتی طراحی زیرساخت امنیتی است. HA فقط اضافه کردن یک دستگاه دوم نیست، بلکه طراحی دقیق لینک Failover، Sync وضعیت، بررسی لایسنس و تست عملیاتی را شامل میشود.
اگر HA به درستی پیادهسازی شود، حتی در صورت خرابی کامل یک دستگاه، سرویسهای حیاتی سازمان بدون وقفه ادامه خواهند داشت.
پیادهسازی HA در محیطهای سازمانی نیازمند تجربه عملی در طراحی لینک Failover، تحلیل سناریوهای خرابی، مدیریت نسخهها و تست عملیاتی است. بسیاری از مشکلات HA نه در مرحله کانفیگ، بلکه در زمان Fail واقعی آشکار میشوند.
وینو سرور به عنوان مرجع تخصصی در حوزه فایروالهای Cisco ASA و Firepower، با تجربه اجرای پروژههای High Availability در سازمانهای متوسط و بزرگ، به شما کمک میکند ساختار HA پایدار، قابل تست و متناسب با نیاز عملیاتی خود طراحی و اجرا کنید. اگر هدف شما حذف Single Point of Failure و افزایش پایداری زیرساخت امنیتی است، وینو سرور میتواند نقطه اتکای تخصصی شما در این مسیر باشد.
وینو سرور، اولین استارتاپ ارائه تجهیزات و سیستم های سخت افزاری، به صورت مستقیم از تولید کننده به مصرف کننده است. همواره تلاش مجموعه بر این اصل استوار بوده است تا مشتریان بتوانند بهترین سیستم را برای پروژه خود انتخاب کرده و با مناسبترین قیمت، آن را تهیه کنند. تیم وینو سرور، همواره سعی میکند تا جامعترین خدمات را به مشتریان ارائه دهد تا خرید را برای شما به کاری لذتبخش و آسان تبدیل کند.
مطلع شدن از پست های جدید
میخواهم اولین نفری باشم که از مقالههایی که در وینو سرور منتشر میشود، آگاه شوم.
