اگر Policy Routing در MikroTik ترافیک را از جدول یا Gateway مورد انتظار عبور نمی‌دهد، معمولاً مشکل در یکی از این نقاط است: جدول Routing با fib ساخته نشده، Route داخل جدول فعال نیست، /routing/rule با Source/Destination واقعی Match نمی‌شود، Mangle قبل از Rule تصمیم را عوض می‌کند، ترافیک Local اشتباه Mark شده یا FastTrack باعث می‌شود بخشی از ترافیک فقط در جدول main پردازش شود. در RouterOS v7 ابتدا جدول و Route را مستقل Verify کنید و بعد سراغ Rule یا Mangle بروید.
سناریوی عیب‌یابی
فرض کنید دو اینترنت دارید. Gateway اصلی 192.0.2.1 روی WAN1 است و می‌خواهید کلاینت 192.168.88.50 فقط از WAN2 با Gateway فرضی 198.51.100.1 خارج شود. نام جدول دوم را to_wan2 می‌گذاریم. آدرس‌ها نمونه‌اند؛ قبل از Copy/Paste آن‌ها را با شبکه خودتان جایگزین کنید.
۱. قبل از تغییر، تنظیمات فعلی را ذخیره کنید
/export file=before-policy-routing
/system backup save name=before-policy-routingExport متنی برای مقایسه تغییرات مناسب است و Backup باینری برای Recovery همان روتر کاربرد دارد. فایل‌ها را از بخش Files خارج از روتر هم نگه دارید.
۲. اول مشخص کنید مشکل واقعاً Routing است
/ip address print detail
/ip route print detail
/routing/table print
/routing/rule print detail
/ip firewall mangle print detail statsاگر WAN2 خودش Gateway قابل دسترس ندارد، Policy Routing نمی‌تواند مشکل Layer 2/3 را حل کند. ابتدا Gateway را از Interface مربوط به WAN2 تست کنید:
/ping 198.51.100.1 interface=ether2 count=5اگر این تست Fail است، قبل از Rule و Mangle مشکل Interface، VLAN، IP، ARP یا Gateway را حل کنید.
۳. جدول Routing در RouterOS v7 باید درست ساخته شده باشد
جدول‌های سفارشی را ببینید:
/routing/table print detailبرای جدولی که قرار است Routeهای آن در Forwarding استفاده شوند، جدول را با FIB ایجاد کنید:
/routing/table add fib name=to_wan2اگر جدول از قبل وجود دارد، دوباره آن را نسازید. نام جدول در Rule، Route و Mangle باید دقیقاً یکسان باشد.
۴. Route داخل جدول سفارشی را مستقل Verify کنید
یک Default Route نمونه:
/ip/route add dst-address=0.0.0.0/0 gateway=198.51.100.1@main routing-table=to_wan2 comment="PBR via WAN2"در RouterOS v7، Gateway جدول سفارشی باید بتواند Resolve شود. به همین دلیل در سناریوهای رایج، Gateway با @main Resolve می‌شود. بعد وضعیت Route را بررسی کنید:
/ip/route print detail where routing-table=to_wan2Route باید Active باشد. اگر Inactive است، اضافه‌کردن Rule بیشتر مشکل را حل نمی‌کند؛ ابتدا Recursive/Nexthop resolution، Gateway و Routeهای جدول main را بررسی کنید.
۵. برای سناریوی ساده، ابتدا Routing Rule را تست کنید
برای هدایت یک Source مشخص:
/routing/rule add src-address=192.168.88.50/32 action=lookup table=to_wan2 comment="client via WAN2"lookup اجازه می‌دهد اگر Lookup در جدول مشخص‌شده نتیجه نداد، پردازش Routing طبق زنجیره تصمیم ادامه پیدا کند. اگر می‌خواهید این کلاینت فقط و فقط از همان جدول استفاده کند، رفتار سخت‌گیرانه‌تر را با احتیاط تست کنید:
/routing/rule add src-address=192.168.88.50/32 action=lookup-only-in-table table=to_wan2قبل از جایگزینی Rule قبلی، تفاوت این دو رفتار را در Maintenance Window تست کنید؛ lookup-only-in-table در صورت نبود Route مناسب می‌تواند اتصال را عمداً قطع کند.
۶. ترتیب Ruleها و Match واقعی را بررسی کنید
/routing/rule print detailSource Address را با IP واقعی Packet مقایسه کنید. اگر قبل از Routing، Source توسط ساختار شبکه شما تغییر کرده یا ترافیک از مسیر دیگری وارد روتر می‌شود، Rule مورد انتظار Match نمی‌شود. برای مشاهده ترافیک واقعی می‌توانید موقتاً از Torch استفاده کنید:
/tool/torch interface=bridge src-address=192.168.88.50روی روتر پرترافیک، Torch را کوتاه‌مدت و با Filter محدود اجرا کنید.
۷. اگر Mangle دارید، اولویت آن را نادیده نگیرید
طبق مستندات MikroTik، Policy Routing می‌تواند با Routing Rules یا Firewall Mangle پیاده شود. اگر هر دو را با هم استفاده می‌کنید، Mark ایجادشده توسط Mangle می‌تواند باعث شود Rule مورد انتظار دیگر تصمیم نهایی را نگیرد.
/ip/firewall/mangle print detail stats where action=mark-routingCounterها را قبل و بعد از یک تست کنترل‌شده مقایسه کنید. برای یک Rule نمونه:
/ip/firewall/mangle add chain=prerouting src-address=192.168.88.50 dst-address-type=!local action=mark-routing new-routing-mark=to_wan2 passthrough=no comment="PBR client via WAN2"نکته مهم: در RouterOS v7 مقدار new-routing-mark باید به جدول Routing موجود اشاره کند. همچنین ترافیک مقصد خود روتر را بی‌دلیل Mark نکنید؛ شرط dst-address-type=!local در این نمونه برای جلوگیری از شکستن دسترسی به IPهای خود روتر است.
۸. FastTrack را در سناریوی Policy Routing بررسی کنید
MikroTik صراحتاً هشدار می‌دهد FastTrack فقط با جدول Routing اصلی سازگار است. اگر Connectionهایی که باید با Routing Mark به جدول دیگری بروند FastTrack شوند، نتیجه می‌تواند با انتظار شما متفاوت باشد.
/ip/firewall/filter print detail stats where action=fasttrack-connectionبرای تست، Rule FastTrack را کورکورانه حذف نکنید. ابتدا Counter را بررسی و در یک Maintenance Window کوتاه، اثر Disable موقت همان Rule را روی Connection آزمایشی بسنجید. اگر مشکل تأیید شد، Exclusion دقیق برای ترافیک Policy-Routed طراحی کنید. برای جزئیات رفتار FastTrack، راهنمای عیب‌یابی FastTrack در MikroTik را ببینید.
۹. Connection Tracking و NAT را همزمان با Routing بررسی کنید
گاهی Route درست است اما Session قدیمی هنوز State/NAT قبلی را نگه داشته است. قبل از پاک‌کردن Connectionها، وضعیت را ببینید:
/ip/firewall/connection print detail where src-address~"192.168.88.50"
/ip/firewall/nat print detail statsاگر بعد از تغییر NAT یا مسیر، فقط Connectionهای قدیمی مشکل دارند، تست را با یک Connection جدید انجام دهید. حذف سراسری Connection Tracking روی روتر Production می‌تواند Sessionهای فعال کاربران را قطع کند. برای تشخیص دقیق‌تر NAT و Stateها، مقاله عیب‌یابی NAT و Firewall با Connection Tracking را بخوانید.
۱۰. NAT خروجی WAN2 را فراموش نکنید
Policy Routing فقط مسیر را انتخاب می‌کند؛ اگر ISP/WAN2 به Source NAT نیاز دارد باید NAT مناسب هم وجود داشته باشد. نمونه عمومی:
/ip/firewall/nat add chain=srcnat out-interface=ether2 action=masquerade comment="WAN2 NAT"اگر WAN2 IP ثابت دارد، بسته به طراحی شبکه ممکن است src-nat صریح مناسب‌تر باشد. قبل از اضافه‌کردن Rule جدید، NATهای موجود و Counterهایشان را بررسی کنید تا Rule تکراری نسازید.
۱۱. تست مرحله‌به‌مرحله بعد از اصلاح
تست را از همان کلاینتی انجام دهید که Rule برای آن ساخته شده است. همزمان Counter و Routeها را روی MikroTik ببینید:
/routing/rule print detail
/ip/firewall/mangle print stats
/ip/firewall/nat print stats
/ip/route print detail where routing-table=to_wan2
/ip/firewall/connection print detail where src-address~"192.168.88.50"سپس از کلاینت مقصد عمومی را Ping/Trace کنید و IP خروجی را با یک سرویس مورد اعتماد بررسی کنید. اگر Failover یا دو WAN دارید، تست را یک بار با WAN1 و یک بار با WAN2 انجام دهید تا مشخص شود Rule فقط در حالت خاصی Fail نمی‌شود.
نشانه‌ها و علت‌های رایج
- Route جدول سفارشی Inactive است: Gateway در main Resolve نمی‌شود یا مسیر رسیدن به Nexthop مشکل دارد.
- Rule ظاهراً درست است ولی اثر ندارد: Mangle قبلاً Routing Mark دیگری اعمال کرده یا Match واقعی Source/Destination متفاوت است.
- خود Router از LAN قابل دسترس نیست: احتمالاً ترافیک Local را هم Mark کرده‌اید.
- بعضی Connectionها مسیر درست و بعضی مسیر غلط دارند: FastTrack یا Connection Tracking قدیمی را بررسی کنید.
- Packet از WAN2 خارج می‌شود ولی پاسخ برنمی‌گردد: NAT، مسیر برگشت، Firewall و وضعیت Gateway را بررسی کنید.
- با lookup کار می‌کند ولی با lookup-only-in-table قطع می‌شود: جدول سفارشی Route کافی برای مقصد ندارد.
Rollback امن
Ruleهای جدید را با Comment مشخص بسازید تا برگشت ساده باشد:
/routing/rule print where comment="client via WAN2"
/ip/firewall/mangle print where comment="PBR client via WAN2"
/ip/route print where comment="PBR via WAN2"در صورت مشکل، ابتدا Rule/Mangle جدید را Disable کنید، نه اینکه کل Routing یا Firewall را Reset کنید. سپس Route اضافه‌شده را Disable و وضعیت قبلی را Verify کنید. اگر تغییرات گسترده بوده است، Export قبل از تغییر را با تنظیمات فعلی مقایسه کنید.
مانیتورینگ بعد از رفع مشکل
بعد از پایدار شدن مسیر، قطع WAN یا Gateway را جداگانه مانیتور کنید. برای Probeهای ICMP/TCP/HTTP/DNS می‌توانید از مانیتورینگ سرویس با MikroTik Netwatch استفاده کنید. برای ساخت Lab یا RouterOS CHR نیز در صورت نیاز به ماشین مجازی مستقل، پلن‌های سرور مجازی وان‌سرور قابل استفاده‌اند.