این مطلب برای زمانی است که FortiGate فقط یک اسم روی فاکتور یا یک گزینه داخل دیتاسنتر نیست؛ قرار است در یک شبکه واقعی کار کند، تغییر بگیرد، لاگ بدهد، و وقتی مشکلی پیش آمد مسیر عیبیابی آن روشن باشد. موضوع اصلی این نوشته طراحی SLA و failover در SD-WAN فورتیگیت است؛ یعنی همان بخشی که اگر از اول درست طراحی نشود، بعداً خودش را به شکل قطعی، خطای مبهم، یا تغییرات پرریسک نشان میدهد.
در کار عملی منطق مهمتر از حفظ کردن چند دستور است. باید بدانیم در شبکهای با دو اینترنت، چند subnet داخلی و سرویسهایی که تحمل قطعی چنددقیقهای ندارند چه چیزی ورودی تصمیم است، چه چیزی خروجی تصمیم است، و کدام نشانهها میگویند مشکل از policy، route، certificate، session، health check یا وابستگی بیرونی آمده است. برای همین این متن را مثل یک چکلیست اجرایی نوشتهام، نه توضیح تبلیغاتی محصول.
برای دیدن مطالب مرتبطتر، صفحه FortiGate هم میتواند مسیر خوبی برای ادامه مطالعه باشد.
سناریوی واقعی مسئله
سناریوی معمول این است که تیم شبکه یک تغییر ظاهراً ساده میدهد: یک policy اضافه میشود، یک interface جابهجا میشود، یک سرویس پشت load balancer قرار میگیرد، یا یک مسیر مانیتورینگ/احراز هویت فعال میشود. در همان لحظه شاید همه چیز سالم به نظر برسد، اما چند ساعت بعد کاربر میگوید بخشی از سرویس کند شده یا بعضی connectionها fail میشوند. اینجا اگر فقط به آخرین تغییر نگاه کنیم، احتمالاً علت اصلی را از دست میدهیم.
در طراحی SLA و failover در SD-WAN فورتیگیت باید مسیر داده را مرحله به مرحله دید. اول باید معلوم شود packet یا request از کجا وارد میشود، با چه identity یا contextی شناخته میشود، کدام rule روی آن match میشود، بعد از تصمیم امنیتی به کجا میرود، و در نهایت سمت مقصد چه پاسخی میدهد. این نگاه ساده است، اما جلوی بیشتر عیبیابیهای پراکنده و حدسی را میگیرد.
نشانه مهم در این سناریو معمولاً بالا بودن interface اما افت کیفیت latency، packet loss یا route selection اشتباه است. این نشانه بهتنهایی حکم قطعی نمیدهد، ولی جهت بررسی را مشخص میکند. اگر نشانه را درست بخوانیم، لازم نیست دهها گزینه را همزمان تغییر بدهیم. تغییر همزمان چند چیز، بدترین دشمن عیبیابی در شبکه production است.
قبل از تغییر چه چیزهایی باید ثبت شود؟
قبل از هر اصلاح، snapshot عملیاتی لازم است. منظور فقط backup گرفتن از config نیست. باید بدانیم وضعیت sessionها، hit countها، logها، route table، objectها، certificateها و وضعیت health check در همان لحظه چه بوده است. اگر بعداً تغییر جواب نداد، بدون این snapshot نمیشود دقیق برگشت یا فهمید مشکل از کجا شروع شده.
- ثبت وضعیت performance SLA برای هر لینک قبل از تغییر
- بررسی اینکه health check فقط gateway نزدیک را نمیسنجد و مقصد معنادار دارد
- کنترل route priority و policy routeهای قدیمی
- تفکیک ترافیک حساس مثل VPN، VoIP و سرویسهای مدیریتی
این موارد شاید بدیهی به نظر برسند، اما در عمل خیلی از downtimeها از همین جا شروع میشود: تغییر انجام شده، اما وضعیت قبل از تغییر ثبت نشده است. وقتی وضعیت قبلی نداریم، rollback هم فقط یک حدس خوشبینانه است.
روش عیبیابی مرحلهای
برای FortiGate بهتر است عیبیابی را از سادهترین لایه شروع کنیم. اول دسترسی پایه و مسیر را ببینیم، بعد سراغ policy و inspection برویم، بعد وابستگیهای پیشرفتهتر مثل profile، identity، certificate یا automation را بررسی کنیم. اگر از همان ابتدا سراغ گزینههای پیچیده برویم، احتمالاً یک مشکل ساده routing یا object اشتباه را نمیبینیم.
من در این نوع کار معمولاً سه سؤال ثابت میپرسم: آیا ترافیک به نقطه تصمیم میرسد؟ آیا rule درست match میشود؟ آیا بعد از تصمیم، مسیر برگشت و state درست است؟ همین سه سؤال برای بیشتر تجهیزات امنیتی و شبکهای جواب میدهد، حتی اگر اسم featureها فرق کند.
diagnose sys sdwan health-check
get router info routing-table all
diagnose firewall proute list
diagnose sys session filter clearدستورها و خروجیها باید در همان change record نگهداری شوند. اگر بعداً یک نفر دیگر بخواهد ادامه کار را بگیرد، نباید مجبور شود از صفر بفهمد چه چیزهایی بررسی شده است.
خطاهای رایج
- استفاده از فقط ping به gateway ISP بهعنوان معیار سلامت
- یکی گرفتن failover اینترنت کاربران با failover تونلهای VPN
- برگرداندن سریع لینک flapping بدون hold-down منطقی
- ندیدن اثر NAT و sessionهای قبلی بعد از تغییر مسیر
نقطه مشترک این خطاها عجله است. وقتی یک سرویس قطع است، فشار برای حل سریع طبیعی است، اما حل سریع با تغییر بیحساب فرق دارد. تغییر کوچک، قابل اندازهگیری و قابل برگشت معمولاً از تغییر بزرگ و مبهم بهتر جواب میدهد.
طراحی درست برای محیط production
در محیط production، اینکه چه زمانی لینک از مدار خارج شود، چه زمانی برگردد و کدام ترافیک اجازه failover داشته باشد باید از قبل مشخص باشد. یعنی تیم بداند اگر تست اول fail شد چه کاری میکند، اگر فقط بخشی از کاربران مشکل داشتند چه چیزی را جدا میکند، و اگر rollback لازم شد دقیقاً کدام object یا policy برمیگردد. طراحی خوب فقط دیاگرام نیست؛ طراحی خوب یعنی تصمیمهای روز حادثه از قبل آماده باشند.
برای طراحی SLA و failover در SD-WAN فورتیگیت بهتر است naming هم جدی گرفته شود. اسم object، rule، profile و monitor باید طوری باشد که شش ماه بعد هم قابل فهم باشد. اسمهای کوتاه و مبهم شاید زمان ایجاد سریعتر باشند، اما هزینه عیبیابی را بالا میبرند. وقتی policy زیاد میشود، naming ضعیف خودش به یک ریسک امنیتی تبدیل میشود.
موضوع دیگر logging است. لاگ زیاد بدون معنا کمک نمیکند؛ لاگ کم هم تیم را کور میکند. باید مشخص باشد برای چه decisionهایی log لازم داریم، کدام logها فقط noise تولید میکنند، و کدام رویدادها باید به مانیتورینگ یا SIEM بروند. در FortiGate این تنظیم اگر درست انجام شود، هم troubleshooting را سریعتر میکند و هم ردپای تغییرات را نگه میدارد.
چکلیست اجرا
- نقشه لینکها و مقصد تست SLA را ثبت کن
- آستانه latency/loss/jitter را با واقعیت سرویس تنظیم کن
- برای ترافیک حساس policy جدا بساز
- قبل از change یک تست failover کنترلشده انجام بده
- بعد از change، session و route و log را با هم بررسی کن
این چکلیست جای تجربه را نمیگیرد، ولی جلوی بینظمی را میگیرد. تجربه زمانی ارزش دارد که به روش تبدیل شود؛ وگرنه هر بار باید همان اشتباهها را دوباره کشف کنیم.
تحویل کار به تیم بعدی
تحویل درست SD-WAN یعنی فقط نگوییم دو اینترنت داریم. باید مشخص باشد لینک اصلی چیست، لینک پشتیبان چه ترافیکی را میگیرد، معیار سلامت چیست، و اگر کیفیت لینک بد شد چه اتفاقی برای sessionهای موجود میافتد.
در نهایت، معیار موفقیت فقط این نیست که سرویس الان بالا آمده باشد. معیار بهتر این است که اگر همین مشکل دوباره رخ داد، تیم بتواند با داده، لاگ و مسیر تصمیم روشن جلو برود. این همان تفاوت بین خاموش کردن آتش و ساختن یک عملیات قابل اتکا است.
اگر این موضوع در شبکه شما درگیر چند محصول یا چند تیم است، بهتر است قبل از تغییر نهایی یک جدول مسئولیت هم داشته باشید: مالک policy، مالک route، مالک application، مالک certificate، و کسی که decision نهایی rollback را میگیرد. نبودن همین مالکیتها معمولاً زمان حل مشکل را چند برابر میکند.
