نحوه بررسی Session ها و Flow ها در فایروال سیسکو برای عیب‌یابی ترافیک

در بسیاری از سناریوهای عیب‌یابی شبکه، مشکل در ظاهر ساده است؛ کاربر می‌گوید «سرویس وصل نمی‌شود» یا «ارتباط کند است». اما در پشت صحنه، آنچه تعیین می‌کند ترافیک واقعاً از فایروال عبور کرده یا نه، Session Table و Flow Processing است. اگر ندانید فایروال چگونه یک Connection را ثبت، مدیریت و خاتمه می‌دهد، عملاً در حال حدس زدن خواهید بود.

در معماری‌های مبتنی بر Cisco ASA و همچنین پلتفرم‌های جدیدتر مانند Cisco Secure Firewall، مفهوم Session و Flow هسته اصلی پردازش Packet است. هر Packet ورودی یا به یک Session موجود تعلق دارد یا باعث ایجاد Session جدید می‌شود. درک این فرآیند، پایه عیب‌یابی حرفه‌ای ترافیک است.

در این مقاله به‌صورت فنی و پروژه‌محور بررسی می‌کنیم چگونه Sessionها و Flowها را در فایروال‌های سیسکو تحلیل کنیم، چه دستوراتی حیاتی هستند، در چه شرایطی Sessionها رفتار غیرعادی دارند و چگونه از این اطلاعات برای یافتن Root Cause استفاده کنیم.

درک معماری پردازش Flow در فایروال

برای اینکه بتوانید Session و Flow را درست عیب‌یابی کنید، باید دقیقاً بدانید وقتی یک Packet وارد فایروال سیسکو می‌شود چه مراحلی را طی می‌کند. در Cisco ASA و همچنین در Cisco Secure Firewall، پردازش ترافیک مبتنی بر مدل Stateful Inspection انجام می‌شود. یعنی فایروال نه‌تنها هر Packet را جداگانه بررسی می‌کند، بلکه وضعیت کل ارتباط را نیز در نظر می‌گیرد.

وقتی اولین Packet از یک ارتباط وارد فایروال می‌شود، هنوز هیچ Sessionای برای آن وجود ندارد. این Packet به‌عنوان New Flow شناخته می‌شود. در این مرحله فایروال چند بررسی کلیدی انجام می‌دهد: ابتدا Route Lookup برای تعیین Interface خروجی، سپس بررسی NAT برای اعمال ترجمه آدرس، بعد ارزیابی Access Control یا ACL، و در صورت استفاده از قابلیت‌های پیشرفته، بررسی Application و Intrusion Policy. اگر تمام این مراحل Allow باشند، فایروال یک Entry در جدول Session ایجاد می‌کند که شامل اطلاعاتی مانند Source IP، Destination IP، Portها، Interface ورودی و خروجی، Timeout و وضعیت TCP است.

از این لحظه به بعد، Packetهای بعدی همان ارتباط دیگر تمام Policy را از ابتدا طی نمی‌کنند. آن‌ها فقط با جدول Session مقایسه می‌شوند. اگر با یک Entry معتبر Match شوند، بدون بررسی کامل ACL عبور داده می‌شوند. این موضوع دلیل اصلی کارایی بالای فایروال‌های Stateful است. اما همین ویژگی در عیب‌یابی اهمیت حیاتی دارد، چون تغییر در Policy لزوماً روی Sessionهای موجود اثر فوری نمی‌گذارد.

در یکی از پروژه‌های سازمانی، تیم امنیت Ruleای را از Allow به Deny تغییر داد، اما کاربران همچنان به سرویس دسترسی داشتند. بررسی نشان داد Sessionهای TCP قبلی همچنان فعال بودند و چون فایروال آن‌ها را معتبر می‌شناخت، Packetهای بعدی بدون بررسی مجدد ACL عبور می‌کردند. تنها پس از clear کردن Sessionها، Policy جدید اثر گذاشت.

در معماری‌های جدیدتر مبتنی بر Firepower، پردازش Flow چندلایه‌تر است. علاوه بر Session لایه ۳ و ۴، موتور تحلیل عمیق ترافیک نیز درگیر می‌شود. به این معنا که حتی اگر از نظر TCP ارتباط برقرار باشد، ممکن است در لایه Application توسط Snort یا IPS Drop شود. بنابراین باید بین Session TCP و Flow Application-Level تفاوت قائل شد. در برخی سناریوها Session برقرار است اما Application Response وجود ندارد، زیرا در لایه بالاتر Drop اتفاق افتاده است.

عامل مهم دیگر در معماری Flow، مفهوم Asymmetric Routing است. فایروال Stateful انتظار دارد Packet رفت و برگشت از همان مسیر عبور کنند. اگر Packet رفت از فایروال عبور کند اما پاسخ از مسیر دیگری بازگردد، فایروال Session معتبر برای آن Packet برگشتی پیدا نمی‌کند و آن را Drop می‌کند. این موضوع در معماری‌های دارای Load Balancer یا Multi-ISP بسیار رایج است. در یکی از پروژه‌های دیتاسنتری، تغییر مسیر برگشت توسط Load Balancer باعث شد فایروال Session را Invalid تشخیص دهد و ترافیک قطع شود، در حالی که از دید سرور همه چیز طبیعی بود.

بررسی Sessionها در Cisco ASA

وقتی صحبت از عیب‌یابی ترافیک در Cisco ASA می‌شود، اولین جایی که باید نگاه کنید جدول Session یا همان Connection Table است. چون ASA یک فایروال Stateful است، هر ارتباط مجاز که از آن عبور می‌کند در این جدول ثبت می‌شود. بنابراین اگر یک ارتباط واقعاً برقرار شده باشد، باید اثری از آن در جدول Connection وجود داشته باشد. اگر وجود نداشته باشد، یا Packet هرگز از Policy عبور نکرده، یا قبل از ایجاد Session Drop شده است.

دستور پایه برای مشاهده Sessionها، show conn است. خروجی این دستور شامل اطلاعاتی مانند IP مبدأ، IP مقصد، پورت‌ها، Interface ورودی و خروجی، مدت زمان ارتباط و وضعیت TCP است. همین چند فیلد ساده در بسیاری از سناریوهای عملیاتی پاسخ سؤال اصلی را می‌دهد: آیا ارتباط واقعاً برقرار شده یا نه.

در شرایط واقعی معمولاً به دنبال یک Session خاص هستید، نه کل جدول. بنابراین فیلتر کردن خروجی اهمیت دارد. برای مثال با show conn address می‌توان فقط Sessionهای مربوط به یک IP مشخص را دید. این روش زمانی کاربرد دارد که یک کاربر خاص یا یک سرور خاص مشکل دارد. در یکی از پروژه‌های سازمانی، کاربری اعلام کرده بود به یک سرور داخلی دسترسی ندارد. بررسی جدول Session نشان داد هیچ Connectionای از IP او به آن سرور ثبت نشده است. این یعنی مشکل پیش از ایجاد Session رخ داده، احتمالاً در ACL یا NAT.

اما اگر Session در جدول وجود داشته باشد، مرحله بعد تحلیل وضعیت آن است. ASA وضعیت‌های مختلف TCP را نشان می‌دهد، مانند ESTABLISHED، SYN-SENT یا FIN-WAIT. اگر Session در حالت SYN-SENT باقی بماند، یعنی Packet اولیه ارسال شده اما پاسخ SYN-ACK دریافت نشده است. این وضعیت معمولاً نشان‌دهنده مشکل در سمت مقصد یا مسیر برگشت است، نه در فایروال. در یک پروژه دیتاسنتری، صدها Session در حالت SYN-SENT دیده می‌شد. بررسی بیشتر نشان داد سرور مقصد به دلیل محدودیت منابع قادر به پاسخ‌گویی نبود.

مدت زمان Session نیز اطلاعات ارزشمندی ارائه می‌دهد. اگر Session برای مدت طولانی فعال باشد اما حجم ترافیک ناچیز باشد، ممکن است یک Connection Idle باشد که منابع جدول را اشغال کرده است. در محیط‌های پرترافیک، تعداد زیاد Sessionهای نیمه‌فعال می‌تواند باعث مصرف بالای منابع شود. بررسی دوره‌ای جدول Connection به شناسایی چنین الگوهایی کمک می‌کند.

گاهی لازم است یک Session خاص را به‌صورت دستی حذف کنید. با دستور clear conn address می‌توان Connectionهای مربوط به یک IP را پاک کرد. این کار در شرایطی مفید است که Policy تغییر کرده اما Session قدیمی هنوز فعال است. در یکی از پروژه‌های مالی، پس از تغییر Rule دسترسی، کاربران همچنان به سرویس متصل بودند. پاک کردن Sessionها باعث شد ارتباط جدید با Policy به‌روزشده ایجاد شود.

نکته مهم دیگر، بررسی ارتباط بین Session و NAT است. اگر NAT به‌درستی Match نشده باشد، Session هرگز ساخته نمی‌شود. بنابراین در کنار show conn معمولاً باید show xlate نیز بررسی شود. نبود Translation مرتبط با یک IP نشان می‌دهد مشکل در مرحله قبل از ایجاد Session رخ داده است.

در معماری‌های پیچیده‌تر مانند Multi-ISP یا سناریوهای دارای Asymmetric Routing، جدول Session اولین جایی است که می‌تواند رفتار غیرعادی را نشان دهد. اگر Packet رفت از ASA عبور کند اما Packet برگشت از مسیر دیگری وارد شود، ASA Session معتبر برای آن پیدا نمی‌کند و Drop اتفاق می‌افتد. در این حالت، Session ممکن است در وضعیت ناقص باقی بماند یا اصلاً کامل نشود.

تحلیل NAT و Translation Table

در بسیاری از سناریوهای عیب‌یابی، مشکل نه در ACL است و نه در Routing، بلکه در NAT اتفاق می‌افتد. در Cisco ASA، NAT یکی از مراحل کلیدی در پردازش Packet است و اگر به‌درستی Match نشود، Session هرگز ساخته نخواهد شد. به همین دلیل بررسی Translation Table یکی از اولین گام‌های مهندسی در تحلیل ترافیک است.

زمانی که یک کلاینت داخلی قصد برقراری ارتباط با اینترنت را دارد، ASA باید آدرس خصوصی او را به یک آدرس عمومی ترجمه کند. این ترجمه در جدول xlate ثبت می‌شود. دستور show xlate وضعیت تمام Translationهای فعال را نمایش می‌دهد. اگر کاربری اعلام کند که به اینترنت دسترسی ندارد و در خروجی show xlate هیچ Entry مربوط به IP او دیده نشود، این یک نشانه مهم است. یعنی NAT Match نشده و Packet پیش از ایجاد Session Drop شده است.

در پروژه‌ای با معماری Multi-ISP، کاربران هنگام قطع شدن لینک اصلی دیگر به اینترنت دسترسی نداشتند. بررسی Routing نشان داد مسیر پشتیبان فعال است. اما show xlate نشان داد هیچ Translationای برای Interface دوم ساخته نمی‌شود. علت این بود که NAT فقط برای Interface اول تعریف شده بود. این مثال نشان می‌دهد بدون بررسی Translation Table ممکن است ساعت‌ها روی Routing تمرکز کنید، در حالی که مشکل در NAT است.

در تحلیل NAT باید به نوع Translation نیز توجه کرد. در ASA، NAT می‌تواند Dynamic، Static یا Policy-Based باشد. اگر Static NAT برای Publish سرویس داخلی تعریف شده باشد اما ترتیب Ruleها اشتباه باشد، ممکن است ترجمه صحیح اعمال نشود. ترتیب پردازش NAT اهمیت دارد و show nat detail می‌تواند نشان دهد کدام Rule در چه ترتیبی اعمال می‌شود.

یکی دیگر از موارد رایج، عدم تطابق بین Real IP و Mapped IP در ارتباطات ورودی است. برای مثال، اگر یک سرویس داخلی Publish شده اما کاربران خارجی نمی‌توانند به آن متصل شوند، بررسی show xlate می‌تواند نشان دهد آیا Translation ورودی ایجاد شده یا خیر. اگر هیچ Entryای ساخته نشده باشد، احتمالاً NAT Rule به‌درستی Match نمی‌شود یا Packet پیش از آن توسط ACL Drop شده است.

همچنین باید به Translationهای قدیمی و ماندگار توجه داشت. گاهی Translation Table شامل Entryهایی است که مدت زیادی فعال بوده‌اند. این وضعیت می‌تواند نشان‌دهنده Sessionهای نیمه‌باز یا Timeout نامناسب باشد. در محیط‌های پرترافیک، پر شدن جدول Translation می‌تواند منجر به Drop شدن ارتباط‌های جدید شود. بررسی تعداد Translationهای فعال و مقایسه آن با ظرفیت دستگاه بخشی از مانیتورینگ پیشگیرانه است.

در سناریوهای پیچیده‌تر مانند VPN، NAT Exemption اهمیت پیدا می‌کند. اگر ترافیک بین دو سایت نباید NAT شود اما Rule مربوطه به‌درستی تعریف نشده باشد، Packet ترجمه شده و تونل برقرار نمی‌شود. در یکی از پروژه‌های چندسایته، یک NAT عمومی بالاتر از Rule Exemption قرار گرفته بود و باعث می‌شد ترافیک VPN اشتباهاً ترجمه شود. نتیجه آن Failure در برقراری تونل بود که تنها با بررسی دقیق Translation Table مشخص شد.

استفاده از Packet Tracer برای تحلیل Flow

دستور packet-tracer یکی از قدرتمندترین ابزارهای عیب‌یابی در ASA است:

این دستور مسیر پردازش یک Packet را مرحله به مرحله نمایش می‌دهد. از بررسی ACL و NAT گرفته تا تصمیم نهایی Allow یا Drop.

در بسیاری از پروژه‌ها، به جای جستجوی دستی در ده‌ها Rule، استفاده از packet-tracer سریع‌ترین روش برای یافتن علت Block شدن ترافیک بوده است.

بررسی Flowها در Cisco Secure Firewall

در معماری‌های مبتنی بر Cisco Firepower Management Center، Sessionها به شکل Event در بخش Analysis قابل مشاهده هستند. می‌توان بر اساس IP، Application یا Intrusion Impact فیلتر کرد.

همچنین در CLI FTD می‌توان از دستور زیر برای مشاهده Sessionها استفاده کرد:

و برای بررسی دقیق‌تر Flowها:

در یکی از پروژه‌های SaaS، یک Application خاص به‌صورت تصادفی Drop می‌شد. بررسی Flow در FMC نشان داد Intrusion Policy با Impact متوسط آن را Block می‌کند، در حالی که در لایه TCP Session برقرار بوده است.

مدیریت و حذف Sessionها

در برخی موارد، Session معیوب باید به‌صورت دستی حذف شود:

این کار باعث می‌شود Session جدید با Policy به‌روزشده ایجاد شود.

در پروژه‌ای با تغییر Policy دسترسی، Sessionهای قدیمی باعث می‌شدند رفتار جدید اعمال نشود تا زمانی که جدول Session پاک شد.

تحلیل Timeout و Session Aging

هر Session دارای Timeout است. اگر Timeout به‌درستی تنظیم نشده باشد، ممکن است Session زودتر از حد انتظار بسته شود یا بیش از حد باقی بماند.

بررسی Timeoutها:

در یک محیط با ارتباطات طولانی‌مدت دیتابیس، Timeout کوتاه باعث قطع Sessionهای فعال می‌شد. تنظیم مجدد Timeout مشکل را حل کرد.

سناریوهای رایج عیب‌یابی مبتنی بر Session

یکی از سناریوهای متداول، Half-Open Session است. زمانی که SYN ارسال می‌شود اما پاسخ دریافت نمی‌شود، Connection Table پر می‌شود و منابع مصرف می‌شوند.

سناریوی دیگر، Asymmetric Routing است. اگر Packet رفت از فایروال عبور کند اما Packet برگشت از مسیر دیگری بازگردد، Session کامل نمی‌شود و Drop اتفاق می‌افتد.

در یکی از پروژه‌های دیتاسنتری، Load Balancer باعث تغییر مسیر برگشت شده بود و فایروال Session را Invalid تشخیص می‌داد.

جمع‌بندی مهندسی

بررسی Session و Flow در فایروال‌های سیسکو یکی از مهم‌ترین مهارت‌های عیب‌یابی حرفه‌ای است. بدون تحلیل جدول Connection، NAT و Flow Processing، عیب‌یابی تبدیل به حدس و گمان می‌شود.

دستورات show conn، show xlate، packet-tracer و بررسی Eventهای FMC ابزارهای کلیدی شما هستند. درک رفتار Stateful فایروال باعث می‌شود بدانید تغییر Policy چه زمانی اعمال می‌شود، چرا یک Packet Drop شده و آیا مشکل واقعاً از فایروال است یا از سمت دیگر ارتباط.

وینو سرور؛ مرجع تخصصی عیب‌یابی پیشرفته فایروال‌های سیسکو

عیب‌یابی حرفه‌ای Session و Flow نیازمند تجربه عملی در سناریوهای واقعی است. بسیاری از مشکلات تنها در شرایط پرترافیک یا معماری‌های پیچیده خود را نشان می‌دهند.

وینو سرور با تجربه عملی در پیاده‌سازی و عیب‌یابی زیرساخت‌های مبتنی بر Cisco ASA و Cisco Secure Firewall، می‌تواند در تحلیل دقیق ترافیک، شناسایی گلوگاه‌ها و رفع اختلال‌های پیچیده در کنار تیم فنی شما باشد. اگر هدف شما رسیدن به تحلیل دقیق و مهندسی ترافیک است، وینو سرور می‌تواند مرجع تخصصی شما در این مسیر باشد.