Drop شدن ترافیک در FortiGate

چرا ترافیک در FortiGate عبور نمی‌کند؟ ۱۰ علت و روش عیب‌یابی

وقتی ارتباطی با FortiGate برقرار نمی‌شود، اغلب اولین فرض این است که یک Firewall Policy اشتباه تنظیم شده یا FortiGate ترافیک را Block کرده است. اما در عمل، Drop شدن ترافیک همیشه به معنی وجود یک Rule با Action برابر deny نیست.

عدم تطابق Firewall Policy، اشتباه در Routing، Sessionهای قدیمی، تنظیمات VIP و DNAT، Security Profileها، Policy-Based Routing، SD-WAN و حتی تنظیمات NAT می‌توانند باعث شوند یک Connection به مقصد نرسد یا پاسخ آن از مسیر صحیح نباشد. به همین دلیل، عیب‌یابی FortiGate بهتر است با این سؤال شروع شود:

ترافیک دقیقاً در کدام مرحله از مسیر Packet متوقف می‌شود؟

در این مقاله ویکی رسیس، ۱۰ علت رایج Drop شدن ترافیک در FortiGate را بررسی می‌کنیم و برای هر مورد عدم عبور ترافیک در فورتی گیت ، مهم‌ترین روش‌های تشخیص و رفع مشکل را توضیح می‌دهیم.

دیاگرام ساده از مسیر Packet در FortiGate
مراحل عبور ترافیک از FortiGate و نقاط احتمالی Drop شدن Packet

قبل از شروع؛ مشخص کنید FortiGate واقعاً ترافیک را Drop کرده است

پیش از تغییر Policy یا غیر فعال کردن Security Profileها، باید مشخص شود Packet واقعاً وارد FortiGate شده و در کدام مرحله متوقف شده‌است. سه ابزار اصلی بررسی عبارت‌اند از:

  • Traffic Log، برای مشاهده Session، Policy ID، Action و اطلاعات مرتبط با ترافیک
  • Debug Flow، برای دنبال کردن نحوه پردازش Packet در FortiOS و بررسی Policy Matching
  • Packet Sniffer، برای بررسی اینکه Packet واقعاً روی Interface ورودی و خروجی دیده می‌شود یا خیر.

Fortinet استفاده از Debug Flow را برای بررسی Traffic Flow مستند کرده و امکان فیلتر کردن Trace براساس مواردی مانند Source و Destination IP، Port و Protocol را فراهم می‌کند.

نکته مهم: Debug Flow می‌تواند خروجی زیادی تولید کند؛ بنابراین آن را فقط برای مدت موردنیاز و ترجیحاً با Filter مناسب اجرا کنید. Fortinet درباره حجم بالای خروجی این ابزار هشدار داده است.

۱۰ علت رایج Drop شدن ترافیک در FortiGate

۱. هیچ Firewall Policyای با ترافیک Match نمی‌شود

یکی از رایج‌ترین دلایل عدم عبور Traffic این است که Packet با هیچ Policyای که اجازه عبور آن را می‌دهد Match نمی‌شود.

FortiGate برای انتخاب Policy، مشخصاتی مانند Incoming Interface، Source، Destination، Service و Schedule را در نظر می‌گیرد. اگر Traffic با Policy مناسب Match نشود، ممکن است در نهایت به Implicit Deny برسد.

در Log یا Debug Flow ممکن است این وضعیت با Policy ID 0 مشاهده شود. با این حال، Policy 0 همیشه به معنی «هیچ Policyای وجود ندارد» نیست و باید نتیجه آن را در کنار Routing و Session بررسی کرد.

چه چیزهایی را بررسی کنیم؟

  • Incoming Interface
  • Outgoing Interface
  • Source Address
  • Destination Address
  • Service و Port
  • Schedule
  • وضعیت Policy
  • Policy ID

برای بررسی Match شدن Policy می‌توانیم از Policy Lookup یا Debug Flow استفاده کنیم. Fortinet برای بررسی Policy Matching نیز diagnose firewall iprope lookup را مستند کرده است.

راهکار: به‌جای ایجاد یک Policy بسیار باز مانند Source=all / Destination=all / Service=ALL، ابتدا مشخصات واقعی Traffic را پیدا و Policy دقیق و محدود تعریف کنید.

۲. Policy درست است، اما ترتیب Policyها باعث Match شدن Rule دیگری شده است

در فورتی گیت، ترتیب Firewall Policyها اهمیت دارد. وقتی Traffic با یک Policy مناسب Match شود، Policyهای بعدی برای همان Traffic بررسی نمی‌شوند. بنابراین ممکن است Policy مورد نظر شما کاملاً صحیح باشد، اما Packet ابتدا با Rule دیگری Match شود.

Fortinet نیز توصیه می‌کند Policyهای Specific در بخش بالاتری از Policy List قرار بگیرند. برای مثال فرض کنید دو Policy دارید:

Policy

Source

Destination

Service

Action

۱۰

LAN-Users

Server

HTTPS

Allow

۱۱

LAN-Users

all

ALL

Deny

اگر Policy شماره ۱۱ قبل از Policy 10 قرار بگیرد، Traffic مربوط به HTTPS نیز ممکن است با Rule عمومی‌تر Match شود.

روش بررسی

در Traffic Log، مقدار Policy ID را بررسی کنید. اگر Traffic با Policy مورد انتظار Match نشده است، ترتیب Policyها و شرایط Match شدن Ruleها را بررسی کنید.

Policy List با نمایش یک Rule عمومی قبل از Rule اختصاصی
قرار گرفتن Policy عمومی قبل از Policy اختصاصی می‌تواند باعث Match شدن Rule اشتباه شود.

۳. Routing یا Policy-Based Routing مسیر اشتباهی انتخاب می‌کند

ممکن است Firewall Policy کاملاً درست باشد، اما FortiGate مقصد را از Interface یا Gateway اشتباه Route کند.

در این شرایط، Packet ممکن است توسط Firewall اجازه عبور بگیرد، اما از مسیر صحیح ارسال نشود یا Return Traffic از مسیر مورد انتظار بازنگردد. برای بررسی جدول Routing می‌توانید از دستور زیر استفاده کنید:

get router info routing-table all

برای بررسی مسیر یک مقصد مشخص نیز می‌توانید از Route Lookup و ابزارهای مربوط به Policy Route استفاده کنید.

بیشتر بخوانید: نصب فورتی گیت در حالت Route/NAT

این موضوع در محیط‌هایی که Policy-Based Routing (PBR)، Static Route یا SD-WAN دارند اهمیت بیشتری پیدا می‌کند. Fortinet ترتیب اولویت Policy Routeها را نیز مستند کرده است.

نکته: وجود PBR به معنی عبور خودکار Traffic از Firewall نیست. حتی اگر مسیر درست انتخاب شود، همچنان باید یک Security Policy معتبر برای اجازه عبور Traffic وجود داشته باشد.

۴. VIP یا DNAT اشتباه تنظیم شده است.

در سناریوهای انتشار Server داخلی روی Internet، یکی از نقاط حساس Virtual IP (VIP) است. VIP در FortiGate می‌تواند برای Destination NAT استفاده می‌شود و Public IP را به IP داخلی Server Map کند. اگر External IP، Mapped IP، Interface یا Port Forwarding اشتباه باشد، Connection ممکن است Timeout شود یا به مقصد مورد نظر هدایت نشود.

مواردی که باید بررسی شوند:

  • External IP
  • Mapped IP
  • Incoming Interface
  • Port Forwarding
  • Destination Port
  • Firewall Policy مرتبط با VIP
  • وضعیت Server مقصد

برای مثال اگر سرویس روی Server داخلی TCP/443 در دسترس باشد اما VIP برای Port دیگری تنظیم شده باشد، Connection از سمت Client ممکن است به مقصد نرسد.

۵. Security Profile ترافیک را Block می‌کند

گاهی Firewall Policy با Action برابر Accept است، اما Traffic همچنان عبور نمی‌کند. یکی از دلایل احتمالی می‌تواند Security Profile متصل به همان Policy باشد؛ از جمله:

  • Web Filter
  • DNS Filter
  • Application Control
  • IPS
  • Antivirus
  • File Filter

این قابلیت‌ها می‌توانند پس از Match شدن Firewall Policy، براساس ویژگی‌های Traffic یا محتوای آن تصمیم به Block کردن بگیرند. Fortinet برای هر یک از این Security Profileها کاربردهای مشخصی مانند Filtering، تشخیص Application و جلوگیری از Exploitها تعریف کرده است.

روش عیب‌یابی

اگر Traffic با Policy درست Match می‌شود، اما Session همچنان Fail است:

  1. Traffic Log را بررسی کنید.
  2. Security Eventهای مرتبط را بررسی کنید.
  3. مشخص کنید کدام Profile یا Signature در تصمیم‌گیری نقش داشته است.
  4. در محیط تست و با رعایت سیاست امنیتی سازمان، Profile مربوطه را به‌صورت کنترل‌ شده بررسی کنید.

نکته: غیر فعال کردن دائمی Security Profile برای حل مشکل، راهکار مناسبی نیست. هدف باید شناسایی علت Block و اصلاح Configuration یا Exception مورد نیاز باشد.

۶. NAT یا Central SNAT به شکل صحیح Match نمی‌شود

در سناریوهای خروجی، ممکن است Policy اجازه عبور Traffic را بدهد اما NAT مورد نیاز انجام نشود. اگر Central SNAT فعال باشد، تصمیم‌گیری Source NAT از Firewall Policy جدا شده و براساس Ruleهای Central SNAT انجام می‌شود. در این حالت باید Match شدن Rule مناسب را بررسی کرد.

چه چیزهایی را بررسی کنیم؟

  • فعال بودن Central NAT
  • Source Address
  • Destination Address
  • Incoming Interface
  • Outgoing Interface
  • IP Pool
  • ترتیب Central SNAT Ruleها

اگر Traffic باید با Public IP خاصی ترجمه شود، بررسی IP Pool و Rule مربوط به آن نیز ضروری است.

۷. Session قدیمی یا Dirty Session باعث ادامه مشکل می‌شود

گاهی Configuration اصلاح شده‌است، اما Traffic همچنان رفتار قبلی را نشان می‌دهد. یکی از دلایل می‌تواند Session موجود باشد که پیش از تغییر Policy، Route، Interface یا Path ایجاد شده‌است.

Fortinet توضیح می‌دهد که در برخی تغییرات، Session موجود می‌تواند به وضعیت Dirty Session وارد شود و هنگام Revalidation دیگر با شرایط فعلی مطابقت نداشته باشد. این وضعیت حتی می‌تواند همراه با policy 0 در Debug Flow دیده شود.

نشانه‌های رایج

  • Traffic قبلاً کار می‌کرده است.
  • مشکل بعد از تغییر Policy یا Route ایجاد شده‌است.
  • Connectionهای جدید رفتار متفاوتی دارند.
  • Debug Flow به Dirty Session یا Policy 0 اشاره می‌کند.

در چنین شرایطی،برای بررسی Session Table می‌توانید از دستور زیر استفاده کنید:

diagnose sys session list

پس از بررسی دقیق، در صورت نیاز Session مرتبط را پاک کرده و Connection را دوباره ایجاد کنید. 

نکته: پاک کردن Session می‌تواند باعث قطع Connectionهای فعال شود؛ بنابراین این کار را بدون بررسی Session مربوطه و تأثیر آن روی کاربران انجام ندهید.

۸. SD-WAN یا مسیر انتخاب‌ شده برای لینک مناسب نیست

در شبکه‌هایی که چند WAN یا SD-WAN دارند، مسئله فقط «داشتن یک Route» نیست؛ انتخاب Member مناسب نیز اهمیت دارد. Performance SLA می‌تواند معیارهایی مانند موارد زیر را برای بررسی وضعیت Link در نظر بگیرد:

  • Latency
  • Jitter
  • Packet Loss

اگر یک Link معیارهای SLA تعریف‌ شده را نداشته باشد، FortiGate می‌تواند آن را از مسیر انتخابی خارج کرده و Traffic را از Member دیگری ارسال کند.

اگر مشکل فقط برای بعضی مقصدها یا در زمان‌های خاص رخ می‌دهد، موارد زیر را بررسی کنید:

  • SD-WAN Rule
  • Performance SLA
  • وضعیت Memberها
  • مسیر انتخاب‌ شده برای Session
  • تغییرات اخیر در WAN

Fortinet برای SD-WAN نیز مجموعه جداگانه‌ای از ابزارهای Troubleshooting ارائه کرده است.

۹. مقصد بسته خود دستگاه است؛ ترافیک Local-In را بررسی کنید

یک اشتباه رایج این است که تصور کنیم تمام Trafficهایی که وارد FortiGate می‌شوند، توسط IPv4/IPv6 Firewall Policy کنترل می‌شوند. اما وقتی مقصد Packet خود FortiGate باشد، ترافیک در دسته Local-In Traffic قرار می‌گیرد و منطق پردازش متفاوتی دارد.

این حالت می‌تواند برای سرویس‌هایی مانند HTTPS Management، SSH، Ping و VPN اهمیت داشته باشد. بنابراین اگر مقصد Connection یکی از IPهای خود FortiGate است، ابتدا مشخص کنید Traffic از نوع Local-In است یا Forward و سپس تنظیمات Interface، Administrative Access و Local-In Policy را بررسی کنید.

فورتی گیت برای Local-In Policy سازوکار جداگانه‌ای دارد و تأکید دارد که تغییر نادرست آن می‌تواند روی سرویس‌هایی مانند SSL VPN و برخی پروتکل‌های مدیریتی اثر بگذارد.

۱۰. مشکل خارج از Firewall Policy است؛ Packet Capture انجام دهید

اگر با بررسی Policy، Routing، NAT و Security Profile هنوز دلیل مشخصی پیدا نکردید، باید مسیر واقعی Packet را بررسی کنید. FortiGate ابزار داخلی Packet Sniffer دارد که می‌تواند Packetها را روی یک Interface یا تمام Interfaceها مشاهده کند. فرمت کلی دستور:

diagnose sniffer packet <interface> ‘<filter>’ <verbose> <count>

برای مثال، می‌توانید Traffic مربوط به یک Host مشخص را بررسی کنید. هدف از Packet Capture پاسخ دادن به چند سؤال اساسی است:

  1. آیا Packet وارد FortiGate می‌شود؟  اگر نه، مشکل ممکن است قبل از FortiGate باشد.
  2. آیا Packet از Interface خروجی خارج می‌شود؟ اگر وارد می‌شود اما خارج نمی‌شود، Policy، Routing، NAT و پردازش داخلی FortiGate را بررسی کنید.
  3. آیا Response از سمت Server برمی‌گردد؟ اگر Request خارج می‌شود اما Response برنمی‌گردد، احتمال دارد مشکل در Server، Return Route، NAT یا تجهیز دیگری در مسیر باشد.

نکته: Packet Sniffer نشان می‌دهد Packet روی Interface دیده می‌شود یا خیر، اما به‌تنهایی دلیل تصمیم FortiGate برای Allow یا Drop کردن Traffic را مشخص نمی‌کند. برای بررسی منطق پردازش Packet باید از Debug Flow نیز استفاده کنید.

سریع‌ترین روش عیب‌یابی Drop شدن Traffic در FortiGate

اگر بخواهیم کل فرآیند را به یک Checklist تبدیل کنیم، پیشنهاد می‌شود این ترتیب را دنبال کنید:

۱. Traffic Log را بررسی کنید: Source، Destination، Service، Action و Policy ID را پیدا کنید.

۲. Policy Match را بررسی کنید: اگر Policy مورد انتظار Match نشده، Source، Destination، Interface، Service و Policy Order را بررسی کنید.

۳. Routing را بررسی کنید: مطمئن شوید مقصد از Interface و Gateway صحیح انتخاب می‌شود.

۴. NAT و VIP را بررسی کنید: در Trafficهای خروجی Central SNAT و در Trafficهای ورودی VIP/DNAT را بررسی کنید.

۵. Security Profileها را بررسی کنید:  اگر Policy روی Allow است اما Traffic عبور نمی‌کند، Security Eventها و Profileهای مرتبط را بررسی کنید.

۶. Session را بررسی کنید: به‌خصوص اگر مشکل بعد از تغییر Configuration ایجاد شده‌است.

۷. Debug Flow اجرا کنید: برای بررسی Packet Processing و Policy Matching می‌توان از Debug Flow استفاده کرد. نمونه ساختار:

diagnose debug reset

diagnose debug flow filter addr <IP>

diagnose debug flow show iprope enable

diagnose debug enable

diagnose debug flow trace start 100

پس از پایان بررسی:

diagnose debug disable

diagnose debug reset

۸. در صورت نیاز Packet Sniffer بگیرید: اگر هنوز مشخص نیست Packet در کدام نقطه متوقف شده‌است، Sniffer می‌تواند مشخص کند Traffic واقعاً روی Interfaceها دیده می‌شود یا خیر.

⚠️ نکته مهم در عیب‌یابی FortiGate

برخی از مراحل عیب‌یابی FortiGate، مانند تغییر Firewall Policy، Routing، NAT، VIP، Security Profile یا پاک‌کردن Sessionها، می‌تواند روی ترافیک واقعی و دسترسی کاربران تأثیر بگذارد. بنابراین این تغییرات را بدون بررسی وابستگی‌های موجود و در محیط عملیاتی انجام ندهید.

همچنین غیر فعال کردن موقت قابلیت‌های امنیتی باید با کنترل و در چارچوب سیاست‌های سازمان انجام شود.

اگر علت Drop شدن ترافیک مشخص نیست یا تغییر تنظیمات ممکن است باعث اختلال در سرویس‌های سازمان شود، بهتر است پیش از اعمال تغییرات، موضوع توسط یک متخصص شبکه و امنیت بررسی شود.

اگر برای عیب‌یابی یا بررسی تنظیمات FortiGate سازمان خود نیاز به راهنمایی تخصصی دارید، می‌توانید با کارشناسان فنی رسیس در ارتباط باشید.

جمع‌بندی؛ مشکل Drop شدن Traffic در FortiGate را از کجا پیدا کنیم؟

Drop شدن Traffic در FortiGate لزوماً به معنی اشتباه بودن یک Firewall Policy نیست. Policy Matching، Policy Order، Routing، PBR، SD-WAN، VIP، NAT، Security Profile، Session و حتی نوع Traffic می‌توانند در نتیجه نهایی یک Connection نقش داشته باشند.

به همین دلیل، عیب‌یابی حرفه‌ای بهتر است از تغییر تصادفی Configuration شروع نشود؛ ابتدا باید مسیر Packet مشخص شود:

  1. Packet وارد FortiGate شده‌است؟
  2. با کدام Policy Match شده‌است؟
  3. کجا Route می‌شود؟ 
  4. آیا NAT انجام می‌شود؟
  5. Security Profile چه تصمیمی گرفته‌است؟
  6. Packet از کدام Interface خارج می‌شود؟ 
  7.  آیا Return Traffic از مسیر صحیح برمی‌گردد؟

وقتی این مسیر مشخص شود، پیدا کردن علت Drop شدن Traffic اغلب بسیار سریع‌تر و دقیق‌تر خواهد بود.