وقتی یک FortiGate وسط مسیر ترافیک سازمان است، عیبیابی نباید با تغییرات سریع و حدسی شروع شود. مشکل ممکن است از Policy باشد، اما همانقدر ممکن است از Route، NAT، VIP، Zone، VPN، Security Profile، نسخه FortiOS، زمان دستگاه یا حتی نبودن لاگ درست باشد. تجربه عملی این است که اگر مسیر بررسی از اول مرتب نباشد، تیم فنی چند تغییر جداگانه انجام میدهد و آخر کار معلوم نیست کدام تغییر واقعاً مسئله را حل کرده یا مشکل تازهای ساخته است.
این مطلب برای شبکهای نوشته شده که FortiGate همین حالا در حال کار است و قطع سرویس هزینه دارد. هدفش آموزش یک ترتیب عیبیابی قابل اتکا است؛ نه جایگزین مستندات رسمی Fortinet و نه نسخه آماده برای هر محیط. برای پروژه کاملتر، صفحه مشاوره و پیادهسازی FortiGate و Security Fabric مسیر مستقیمتری است، اما همین چکلیست کمک میکند قبل از تغییرات سنگین، مسئله را درست دستهبندی کنید.
اول صورت مسئله را کوچک کنید
قبل از ورود به تنظیمات، باید بدانیم دقیقاً چه ترافیکی مشکل دارد. جملههایی مثل «اینترنت قطع است» یا «VPN کار نمیکند» برای عیبیابی FortiGate کافی نیستند. باید حداقل مبدأ، مقصد، سرویس، زمان رخداد، مسیر مورد انتظار، تغییرات اخیر و اثر مشکل روی کاربران روشن شود. اگر فقط یک سرویس خاص قطع است، نباید کل Policyها یا Routeها را دستکاری کرد.
- IP مبدأ، IP مقصد و پورت یا پروتکل را جداگانه یادداشت کنید.
- مشخص کنید مشکل دائم است یا فقط در ساعت/لینک/شعبه خاص دیده میشود.
- آخرین تغییرات Policy، NAT، SD-WAN، VPN، Firmware یا Security Profile را بررسی کنید.
- اگر HA دارید، وضعیت کلاستر و دستگاه فعال را هم در همان ابتدا ببینید.
Policy را فقط با نام Rule قضاوت نکنید
در FortiGate، ترتیب Policyها، interface یا zone مبدأ و مقصد، آدرسها، سرویسها، NAT و Security Profile همه با هم تصمیم میگیرند. نام Rule ممکن است ظاهراً درست باشد، اما ترافیک اصلاً به آن Rule نرسد. برای همین بهتر است اول Hit Count، زمان آخرین استفاده، مسیر واقعی interfaceها و Ruleهای بالادست بررسی شود.
اشتباه رایج این است که برای حل سریع مشکل، یک Rule جدید در بالا اضافه میشود. این کار گاهی سرویس را برمیگرداند، اما بعداً تبدیل به Rule دائمی و پرریسک میشود. اگر Rule جدید موقت است، باید Owner، دلیل، زمان بازبینی و لاگ داشته باشد. در غیر این صورت، بعد از چند ماه خود FortiGate تبدیل به دفترچه یادداشت تغییرات عجولانه میشود.
NAT و VIP را جدا از Policy نبینید
در خیلی از خطاهای دسترسی، Policy درست دیده میشود اما NAT یا VIP مسیر را عوض کرده است. اگر ترافیک خروجی است، Source NAT، IP Pool و مسیر برگشت را بررسی کنید. اگر ترافیک ورودی است، VIP، Port Forwarding، ARP، Route و Policy مرتبط را کنار هم ببینید. یک VIP اشتباه یا IP Pool مصرفشده میتواند شبیه مشکل Policy دیده شود.
- برای ترافیک خروجی، IP ترجمهشده و مسیر برگشت را با لاگ تطبیق دهید.
- برای سرویسهای Published، VIP و Policy ورودی را با هم بررسی کنید.
- اگر چند لینک اینترنت دارید، SD-WAN Rule و Route را در کنار NAT ببینید.
- در تغییرات بزرگ، قبل و بعد از تغییر از Ruleها و Objectها خروجی مستند داشته باشید.
VPN را فقط از روی Up بودن Tunnel تأیید نکنید
در IPsec یا SSL VPN، سبز بودن Tunnel به معنی عبور درست همه ترافیک نیست. ممکن است Phase 1 و Phase 2 بالا باشند اما Selector، Route، Policy، NAT Exemption یا مسیر برگشت مشکل داشته باشد. در SSL VPN هم گروه کاربر، Portal، Split Tunnel، DNS و Policy مقصد باید جداگانه بررسی شوند.
برای VPN شعب، همیشه یک جدول ساده از subnetهای دو طرف، Interfaceهای مرتبط، Policyهای رفت و برگشت و روش مانیتورینگ Tunnel داشته باشید. اگر این جدول وجود نداشته باشد، هر بار که یک شعبه قطع میشود، تیم فنی دوباره از صفر شروع میکند. مقاله Security Fabric برای شعب سازمانی همین بخش شعب، SD-WAN، VPN و لاگ را از زاویه طراحی کلیتر توضیح میدهد.
لاگ باید قبل از بحران آماده باشد
FortiGate بدون لاگ قابل جستوجو، در زمان Incident یا قطعی عملاً نیمهکور است. بهتر است برای Ruleهای حساس، Log Allowed Traffic، Log Denied Traffic، زمان دستگاه، NTP، ارسال به FortiAnalyzer و Retention از قبل مشخص باشد. اگر تازه بعد از مشکل بخواهید لاگ را فعال کنید، فقط رخدادهای بعدی را میبینید و شواهد اصلی از دست رفته است.
برای شبکههای چند FortiGate یا چند شعبه، FortiAnalyzer و FortiManager فقط ابزار تزئینی نیستند؛ اگر درست طراحی شوند، مسیر عیبیابی و کنترل تغییرات را کوتاهتر میکنند. مطلب نقش FortiAnalyzer و FortiManager در Security Fabric برای همین تصمیم مفید است.
Debug Flow را محدود و کنترلشده اجرا کنید
Debug Flow در FortiGate ابزار قدرتمندی است، اما نباید بیمهابا روی دستگاه پرترافیک اجرا شود. فیلتر باید تا حد ممکن محدود باشد و قبل از شروع، زمان اجرا، تعداد Packet و روش توقف مشخص باشد. برای نمونه، الگوی زیر فقط یک مسیر محدود را بررسی میکند و بعد باید فوراً متوقف شود:
diagnose debug reset
diagnose debug flow filter addr 192.0.2.10
diagnose debug flow filter daddr 198.51.100.20
diagnose debug flow show function-name enable
diagnose debug flow trace start 50
diagnose debug enable
# stop after capturing enough packets
diagnose debug disable
diagnose debug resetدر خروجی debug، دنبال این باشید که ترافیک به کدام Policy خورده، آیا Drop شده، آیا NAT اعمال شده، آیا Route پیدا شده و کدام Security Profile وارد تصمیم شده است. اگر خروجی برای شما مبهم است، همان بهتر که تغییر ندهید و اول مسیر را مستند کنید. تغییرات عجولانه روی فایروال مرکزی، از خود مشکل خطرناکتر است.
Security Profileها را متهم همیشگی نکنید
IPS، Antivirus، Web Filter، Application Control و SSL Inspection گاهی باعث Block یا False Positive میشوند، اما خاموش کردن کامل آنها برای حل سریع مشکل معمولاً تصمیم بدی است. بهتر است اول لاگ مربوط به Profile بررسی شود، سپس Exception محدود، زماندار و مستند تعریف شود. اگر استثنا عمومی باشد، بعداً کسی یادش نمیماند چرا ساخته شده و چه زمانی باید حذف شود.
عیبیابی خوب، خروجی مستند دارد
در پایان عیبیابی FortiGate باید چند چیز روشن باشد: علت محتمل، شواهدی که آن علت را تأیید میکند، تغییری که انجام شده، اثر تغییر، ریسک باقیمانده و کارهای بعدی. اگر فقط سرویس برگشته ولی هیچچیز ثبت نشده، دفعه بعد همان مشکل دوباره زمان میگیرد. برای همین در پروژههای سازمانی، عیبیابی از طراحی و نگهداری جدا نیست.
اگر هنوز در مرحله طراحی یا اصلاح ساختار FortiGate هستید، راهنمای پیادهسازی FortiGate در سازمان و صفحه پیادهسازی فایروال سازمانی مسیر کاملتری برای Policy، NAT، VPN، HA و Hardening میدهند. برای دسترسی مدیریتی هم مطلب امنسازی دسترسی مدیریتی FortiGate را جداگانه ببینید، چون پنل مدیریت فایروال نباید بخشی از سطح حمله روزمره شبکه باشد.
منابع رسمی برای بررسی عمیقتر
- Debugging the packet flow در FortiGate Administration Guide
- Firewall policy در مستند رسمی Fortinet
- VPN security policies در FortiGate Administration Guide
- Troubleshooting and diagnosis در FortiOS
برای بررسی FortiGate در شبکه فعال، بهتر است قبل از هر تغییر، توپولوژی خلاصه، مدل دستگاه، نسخه FortiOS، سناریوی مشکل و چند نمونه لاگ آماده باشد. از صفحه تماس میتوانید همین اطلاعات اولیه را بفرستید تا مسیر بررسی دقیقتر مشخص شود.
