وقتی روی FortiGate یک Rule ظاهراً درست است اما ترافیک عبور نمیکند، نگاه کردن به جدول Policy بهتنهایی کافی نیست. تصمیم نهایی دستگاه از ترکیب چند لایه ساخته میشود: مسیر رفت، مسیر برگشت، NAT، ترتیب Policy، session قبلی، Security Profile و حتی interface role. Debug Flow برای همین لحظه است؛ برای اینکه قبل از دست زدن به Rule Base بفهمیم بسته دقیقاً کجا رد یا پذیرفته شده است.
قبل از اجرای Debug Flow چه چیزی را مشخص کنیم؟
Debug بدون فیلتر در محیط عملیاتی خطرناک است، چون خروجی زیاد میشود و ممکن است هم تحلیل را سخت کند هم روی دستگاه فشار بگذارد. من معمولاً قبل از شروع سه چیز را روشن میکنم: IP مبدأ یا مقصد مشخص، پورت یا سرویس مورد نظر، و سناریوی تست کوتاه. اگر مشکل مربوط به VPN یا SD-WAN باشد، interface و route هم باید جداگانه بررسی شود؛ چون گاهی بسته اصلاً به Policy مورد انتظار نمیرسد.
diagnose debug reset
diagnose debug flow filter addr 10.10.10.25
diagnose debug flow filter port 443
diagnose debug flow show function-name enable
diagnose debug flow trace start 50
diagnose debug enableبعد از تست کوتاه، Debug باید سریع خاموش شود. خروجی را نباید فقط دنبال کلمه deny خواند. گاهی پیام مهمتر این است که lookup به route اشتباه خورده، NAT اعمال نشده، session قدیمی رفتار قبلی را نگه داشته، یا packet به یک Policy عمومیتر قبل از Rule مورد نظر match شده است.
ترتیب تحلیل خروجی
- اول ببینید بسته از کدام interface وارد شده و آیا همان مسیر مورد انتظار است.
- بعد route lookup و مسیر خروج را بررسی کنید؛ بهخصوص در سناریوهای چند لینک، VPN و SD-WAN.
- Policy ID را با Rule Base مقایسه کنید. اگر Policy اشتباه match شده، مشکل معمولاً ترتیب Rule یا object group است.
- NAT را جدا بخوانید. بسیاری از قطعیها از Policy نیستند؛ از source NAT یا VIP اشتباه میآیند.
- اگر Security Profile باعث block شده، exception را به همان endpoint محدود کنید، نه اینکه کل profile را خاموش کنید.
اشتباه رایج در شبکههای فعال
اشتباه رایج این است که بعد از دیدن اولین deny، Rule جدید ساخته میشود. این کار ممکن است همان لحظه مشکل را پنهان کند، اما Rule Base را شلوغتر و آینده عیبیابی را سختتر میکند. اگر deny بهخاطر route برگشت، session قبلی یا NAT اشتباه باشد، Rule جدید فقط یک لایه ابهام اضافه میکند.
برای یک پروژه تمیز، خروجی Debug Flow باید کنار بازبینی Policy و Rule Base در FortiGate و عیبیابی Policy، NAT، VPN و لاگ دیده شود. اگر موضوع شما پیادهسازی یا اصلاح جدی FortiGate است، صفحه مشاوره و پیادهسازی FortiGate مسیر خدماتی دقیقتری میدهد.
سناریوی واقعی: کاربر به سرویس میرسد اما پاسخ برنمیگردد
یکی از سناریوهای رایج این است که کلاینت از سمت داخل به سرویس DMZ یا اینترنت درخواست میفرستد، اما پاسخ برنمیگردد. در ظاهر ممکن است Rule اجازه داده باشد، ولی Debug Flow نشان میدهد مشکل در return route، session یا NAT برگشتی است. اگر فقط Rule جدید بسازیم، ممکن است مسیر رفت بازتر شود اما مسیر برگشت همچنان اشتباه بماند. در چنین حالتی باید همزمان route table، session table و NAT decision خوانده شود.
get router info routing-table details 10.10.10.25
diagnose sys session filter dst 10.10.10.25
diagnose sys session listاگر session از قبل با تصمیم قبلی ساخته شده باشد، تغییر policy همیشه فوراً اثر قابل مشاهده نمیدهد. در عیبیابی production، پاک کردن session باید محدود و با احتیاط انجام شود؛ پاک کردن گسترده sessionها میتواند روی کاربران فعال اثر بگذارد. بهتر است اول session مربوط به همان IP و سرویس پیدا شود و فقط همان مسیر تحلیل شود.
چه خروجیای از عیبیابی باید تحویل شود؟
خروجی خوب از Debug Flow فقط چند خط command نیست. باید مشخص کند بسته از کجا وارد شد، به کدام route خورد، کدام policy ID انتخاب شد، NAT چه تغییری داد، profile امنیتی چه تصمیمی گرفت و برای اصلاح چه تغییری با چه ریسکی لازم است. این مدل گزارش باعث میشود تغییر بعدی قابل دفاع باشد و تیم فنی بداند اگر مشکل برگشت، از کدام نقطه دوباره شروع کند.
منبع فنی
برای جزئیات دستورها و رفتار Debug Flow، مستند رسمی Fortinet درباره debugging the packet flow مرجع اصلی است. در محیط production بهتر است همین دستورها با فیلتر محدود، زمان کوتاه و برنامه rollback استفاده شوند.
قبل از اینکه خروجی debug را اشتباه تفسیر کنید
در عیبیابی FortiGate، خروجی debug flow فقط یک تکه از تصویر است. قبل از اینکه بر اساس یک خط log، policy یا NAT را تغییر دهید، باید سه چیز را کنار هم ببینید: جدول route، ترتیب policyها و وضعیت session. اگر route درست نباشد، تغییر در policy فقط مسئله را پنهان میکند. اگر session قدیمی هنوز فعال باشد، ممکن است بعد از اصلاح policy هم همان رفتار قبلی را ببینید. اگر NAT روی مسیر برگشت با طراحی شبکه هماهنگ نباشد، ترافیک در ظاهر match میشود ولی جواب به مقصد درست برنمیگردد.
روال کمریسک برای محیط production
برای شبکه عملیاتی بهتر است debug را محدود و کوتاه اجرا کنید. اول فیلتر را تا حد ممکن دقیق کنید: IP مبدأ، IP مقصد و در صورت نیاز پورت یا پروتکل. بعد یک تست کنترلشده بسازید و همزمان route lookup، policy lookup و session table را بررسی کنید. اگر قرار است تغییری انجام شود، آن را به یک تغییر کوچک و قابل rollback محدود کنید؛ مثلاً اصلاح یک object یا ترتیب یک policy مشخص، نه بازنویسی کل rule base. بعد از تغییر، همان تست را دوباره تکرار کنید و نتیجه را با خروجی قبل مقایسه کنید.
برای مسیرهای VPN، SD-WAN یا چند اینترنت، debug flow باید کنار بررسی interface خروجی و route انتخابشده خوانده شود. در چنین سناریوهایی، مشکل همیشه از firewall rule نیست؛ گاهی preferred route، policy route یا asymmetry باعث میشود packet از مسیر متفاوتی برگردد. مستندسازی همین چند خط تصمیم، بعداً از تکرار خطا در تغییرهای بعدی جلوگیری میکند.
