ESC را فشار دهید تا بسته شود

چرا NAT یا Firewall در MikroTik درست Match نمی‌شود؟ عیب‌یابی Connection Tracking

فهرست

عیب‌یابی Connection Tracking در MikroTik زمانی لازم می‌شود که Rule جدید NAT یا Firewall ظاهراً هیچ اثری ندارد. برای رفع مشکل NAT در MikroTik یا رفع مشکل Firewall در MikroTik، قبل از جابه‌جا کردن Ruleها یا ریبوت روتر، سه چیز را بررسی کنید: Counter همان Rule، وضعیت Connection Tracking و این‌که اتصال مورد آزمایش از قبل در جدول Connection ثبت شده یا نه. RouterOS تصمیم NAT را روی اولین Packet اتصال می‌گیرد و نتیجه را در Connection Tracking نگه می‌دارد؛ به همین دلیل تغییر NAT روی اتصال قدیمی ممکن است تا پایان همان Connection دیده نشود.

قبل از تغییر تنظیمات، از کانفیگ خروجی بگیرید

/export file=before-conntrack-troubleshoot

روی روتر Production، پاک‌کردن کل جدول Connection می‌تواند Sessionهای فعال را قطع کند. در مراحل بعد ابتدا Connection هدف را پیدا می‌کنیم و فقط در صورت نیاز همان مورد را حذف می‌کنیم.

مرحله ۱: ببینید Packet اصلاً به Rule می‌رسد یا نه

Counterهای Filter و NAT سریع‌ترین نقطه شروع هستند:

/ip firewall filter print stats
/ip firewall nat print stats
/ip firewall raw print stats

ترافیک تست را ایجاد کنید و دوباره Counterها را بخوانید. اگر Counter Rule هدف افزایش پیدا نمی‌کند، مشکل قبل از Connection Tracking یا NAT است: ترتیب Rule، Chain اشتباه، Interface/List، Address، Protocol/Port یا Rule بالاتری که زودتر Match می‌شود را بررسی کنید.

مرحله ۲: Connection Tracking را بررسی کنید

/ip firewall connection tracking print
/ip firewall connection print detail

RouterOS برای اتصال‌ها State نگه می‌دارد. در Firewall معمولاً با وضعیت‌های new، established، related، invalid و در سناریوهای RAW با untracked روبه‌رو می‌شوید. اگر اتصال هدف از قبل در جدول وجود دارد، NAT جدید الزاماً روی همان Session قدیمی دوباره محاسبه نمی‌شود.

مرحله ۳: چرا NAT جدید کار نمی‌کند ولی Rule درست است؟

طبق مستندات RouterOS، NAT فقط Packet اول Connection را Match می‌کند و Connection Tracking ترجمه را برای Packetهای بعدی به خاطر می‌سپارد. بنابراین بعد از تغییر srcnat، masquerade یا dstnat یک Connection قدیمی می‌تواند همچنان رفتار قبلی را نشان دهد.

ابتدا Connection مرتبط را با فیلتر مناسب پیدا کنید. برای مثال، اگر IP مقصد تست 203.0.113.10 است:

/ip firewall connection print detail where dst-address~"203.0.113.10"

بعد از اطمینان از این‌که همان Session آزمایشی است، می‌توانید فقط همان Entry را حذف کنید:

/ip firewall connection remove [find where dst-address~"203.0.113.10"]

احتیاط: IP مثال را با مقصد واقعی خود جایگزین کنید و قبل از Remove خروجی print detail را ببینید. روی Production از دستور حذف بدون فیلتر استفاده نکنید.

مرحله ۴: ترتیب NAT و Firewall را با Counterها پیدا کنید

Rule بالاتر می‌تواند قبل از Rule موردنظر Match شود. خروجی زیر را با شماره Ruleها بررسی کنید:

/ip firewall nat print detail stats
/ip firewall filter print detail stats

اگر Counter Rule دیگری هم‌زمان بالا می‌رود، Matcherهای آن را با Rule هدف مقایسه کنید. به‌جای جابه‌جایی کورکورانه Ruleها، مشخص کنید کدام شرط باعث Match زودتر شده است.

مرحله ۵: connection-state=invalid را کورکورانه Accept نکنید

Packet با State برابر invalid الزاماً به معنی خراب بودن RouterOS نیست. مسیر نامتقارن، Packet خارج از Window، Timeout یا تنظیمات Tracking می‌تواند در تشخیص State اثر بگذارد. قبل از تغییر Rule عمومی برای Accept کردن Invalid، مسیر رفت و برگشت و Connection هدف را بررسی کنید.

/ip firewall connection print detail where connection-state=invalid

اگر مشکل فقط در یک Flow دیده می‌شود، همان Flow و Routeهای مربوط را بررسی کنید؛ بازکردن عمومی Invalid می‌تواند منطق Stateful Firewall را ضعیف کند.

مرحله ۶: RAW و notrack را فراموش نکنید

اگر در جدول RAW از action=notrack استفاده شده باشد، Packetهای Match‌شده وارد Connection Tracking عادی نمی‌شوند و در Firewall با State untracked دیده می‌شوند.

/ip firewall raw print detail stats

اگر Counter یک Rule با notrack بالا می‌رود، انتظار رفتار معمول Stateful Firewall یا NAT وابسته به Tracking برای همان ترافیک را نداشته باشید. برای تست، Rule را فقط در Maintenance Window و با امکان Rollback تغییر دهید.

مرحله ۷: FastTrack را از Connection Tracking جدا بدانید

FastTrack و Connection Tracking به هم مرتبط‌اند اما یک چیز نیستند. اگر مشکل شما این است که Queue یا Mangle برای بخشی از ترافیک اجرا نمی‌شود، راهنمای عیب‌یابی FastTrack و Simple Queue در MikroTik را ببینید. برای عیب‌یابی NAT، ابتدا Counterهای NAT و Connection Entry همان Flow را بررسی کنید.

سناریوی عملی: Port Forward ساخته‌اید ولی مقصد قدیمی باز می‌شود

فرض کنید Rule dstnat را از Server A به Server B تغییر داده‌اید، اما Client آزمایشی هنوز Session قبلی را باز نگه داشته است. ترتیب درست عیب‌یابی این است:

  1. Counter Rule جدید dstnat را بخوانید.
  2. Connection مربوط به Client و Port هدف را در جدول Connection پیدا کنید.
  3. Session سمت Client را ببندید و دوباره تست کنید.
  4. اگر Entry قدیمی باقی مانده و دقیقاً شناسایی شده است، فقط همان Connection را حذف کنید.
  5. اتصال جدید بسازید و Counter و Translation را دوباره Verify کنید.

Verify: از کجا بفهمیم مشکل حل شده است؟

بعد از اصلاح، یک Connection کاملاً جدید ایجاد کنید و این موارد را کنترل کنید:

/ip firewall nat print stats
/ip firewall filter print stats
/ip firewall connection print detail

Counter Rule موردنظر باید افزایش پیدا کند، Connection جدید باید State منطقی داشته باشد و آدرس/پورت‌های Original و Reply با سناریوی NAT شما سازگار باشند. اگر هدف شما پایش پایداری اینترنت یا سرویس است، مانیتورینگ سرویس با MikroTik Netwatch می‌تواند بعد از اصلاح برای Verify مداوم استفاده شود. برای مشکلات DNS نیز آموزش DNS over HTTPS در MikroTik مسیر عیب‌یابی جداگانه‌ای دارد.

Rollback و Recovery

اگر برای تست Rule را Disable یا جابه‌جا کرده‌اید، آن را به موقعیت و وضعیت قبلی برگردانید. فایل Export ابتدای کار مرجع شما برای مقایسه است. اگر حذف Connection باعث قطع Session شده، معمولاً Client باید Connection جدید بسازد؛ حذف Connection Table جایگزین اصلاح Rule اشتباه نیست.

اگر MikroTik را روی زیرساخت مجازی اجرا می‌کنید، قبل از تغییرات Firewall/NAT دسترسی Out-of-band یا Console را در نظر بگیرید. برای زیرساخت مجازی می‌توانید مشخصات سرور مجازی وان‌سرور را متناسب با بار شبکه بررسی کنید.

منابع رسمی

Rate this post
Views: 89
اشتراک گذاری نوشته در:

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *