تماس با ما
MikroTik · RouterOS · Firewall

FastTrack در MikroTik چیست؟ آموزش تنظیم صحیح، ترتیب Ruleها و محدودیت‌ها

FastTrack می‌تواند سربار پردازش ترافیک را کاهش دهد و در بعضی سناریوها توان عبوری روتر را افزایش دهد؛ اما فعال‌سازی آن بدون توجه به Queue، Mangle، IPsec، VRF و سیاست Firewall می‌تواند نتیجه‌ای متفاوت از انتظار ایجاد کند.

نویسنده: مهرگان نت · تاریخ انتشار: ۴ مهر ۱۴۰۵ · زمان مطالعه: حدود ۸ دقیقه

FastTrack در MikroTik چه کاری انجام می‌دهد؟

در RouterOS، بسته‌هایی که از روتر عبور می‌کنند معمولاً از بخش‌هایی مانند Connection Tracking، Mangle، Firewall Filter، NAT و Queue عبور می‌کنند. این پردازش کنترل و قابلیت مشاهده زیادی فراهم می‌کند، اما برای هر بسته می‌تواند سربار پردازشی ایجاد کند.

FastTrack برای برخی اتصال‌های TCP و UDP مسیر پردازش سریع‌تری فراهم می‌کند. اتصال با Rule دارای action=fasttrack-connection علامت‌گذاری می‌شود و بسته‌های آن می‌توانند از FastPath عبور کنند؛ در نتیجه بخشی از امکانات لایه ۳ مانند Firewall، Simple Queue، Queue Tree با parent=global، IP Accounting، IPsec، Hotspot Universal Client و VRF Assignment برای آن ترافیک دیگر در مسیر عادی اعمال نمی‌شوند.

FastTrack یک «دکمه افزایش سرعت برای همه ترافیک» نیست؛ باید مشخص باشد کدام اتصال‌ها اجازه عبور از مسیر سریع را دارند و کدام ترافیک باید مسیر کامل پردازش را طی کند.

ارتباط FastTrack با Connection Tracking

FastTrack بر مبنای Connection Tracking کار می‌کند. در Firewall معمولاً وضعیت‌هایی مانند new، established، related، invalid و untracked را می‌بینیم. الگوی رایج FastTrack برای اتصال‌های established,related است.

نکته مهم این است که FastTrack به معنی حذف کامل Connection Tracking برای همیشه نیست. برای نگه‌داری اطلاعات اتصال، بعضی بسته‌ها همچنان از مسیر کند عبور می‌کنند. به همین دلیل Rule مربوط به accept بعد از FastTrack نیز لازم است.

ترتیب صحیح Ruleهای FastTrack در Forward

ترتیب Ruleها بسیار مهم است. اگر یک ترافیک باید از FastTrack خارج شود، Rule استثنا باید قبل از Rule FastTrack قرار بگیرد؛ در غیر این صورت ممکن است اتصال زودتر FastTrack شود و به Rule استثنا نرسد.

الگوی پایه و استاندارد

/ip firewall filter add chain=forward action=fasttrack-connection connection-state=established,related comment="FastTrack established/related" add chain=forward action=accept connection-state=established,related comment="Accept established/related"

Rule اول اتصال‌های مناسب را وارد FastTrack می‌کند. Rule دوم برای بسته‌هایی است که به هر دلیل در مسیر کند باقی می‌مانند و همچنین برای پروتکل‌هایی که FastTrack نمی‌شوند اهمیت دارد.

اگر استثنا دارید، اول استثنا را بنویسید

برای مثال، MikroTik در مستندات خود برای خارج‌کردن یک Host از FastTrack، Ruleهای accept مربوط به آن Host را قبل از FastTrack قرار می‌دهد. منطق کار ساده است: ترافیک استثنا نباید به Rule FastTrack برسد.

/ip firewall filter add chain=forward action=accept connection-state=established,related src-address=192.168.88.111 add chain=forward action=accept connection-state=established,related dst-address=192.168.88.111 add chain=forward action=fasttrack-connection connection-state=established,related add chain=forward action=accept connection-state=established,related

FastTrack با چه قابلیت‌هایی تداخل دارد؟

قابلیتنکته مهم
Simple Queueترافیک FastTracked از Simple Queue عبور نمی‌کند؛ بنابراین محدودیت سرعت کاربران باید با دقت تست شود.
Queue Tree با parent=globalاین ترافیک از HTB Global عبور نمی‌کند و ممکن است سیاست QoS مورد انتظار اعمال نشود.
Mangleاگر Mangle برای Marking یا Policy Routing استفاده می‌شود، FastTrack می‌تواند نتیجه مورد انتظار را تغییر دهد.
IPsecترافیک IPsec را نباید بدون استثنا وارد FastTrack کرد؛ در صورت نیاز Ruleهای استثنا باید قبل از FastTrack باشند.
IP Accountingبخشی از ترافیک FastTracked ممکن است در Accounting به شکل مورد انتظار دیده نشود.
Hotspot Universal ClientFastTrack می‌تواند با پردازش Hotspot تداخل داشته باشد.
VRF / Policy RoutingFastTrack فقط با Main Routing Table کار می‌کند؛ اتصال‌هایی که با Routing Mark به جدول دیگری می‌روند نباید بی‌دلیل FastTrack شوند.

آیا FastTrack را برای همه ترافیک فعال کنیم؟

در یک روتر ساده SOHO ممکن است FastTrack برای اتصال‌های established,related انتخاب مناسبی باشد. اما در شبکه سازمانی، قبل از فعال‌سازی باید مشخص شود که Queue، QoS، Mangle، Policy Routing، VPN، IPsec، Hotspot یا Accounting چه نقشی دارند.

قاعده عملی این است: هر ترافیکی که برای پردازش صحیح به یکی از قابلیت‌های دورزده‌شده توسط FastTrack وابسته است، باید از FastTrack خارج شود.

الگوی پیشنهادی برای Forward

ترتیب دقیق به معماری و سیاست امنیتی شبکه بستگی دارد، اما یک ساختار قابل استفاده می‌تواند چنین باشد:

  1. در صورت نیاز، Drop کردن ترافیک invalid.
  2. قرار دادن Ruleهای استثنا برای IPsec، Queue، Policy Routing، مدیریت یا سایر ترافیک‌هایی که نباید FastTrack شوند.
  3. FastTrack کردن اتصال‌های مجاز established,related.
  4. Accept مکمل برای established,related و در صورت استفاده، untracked.
  5. Allow کردن ترافیک‌های جدید و مشخص، مانند سرویس‌های داخلی موردنیاز.
  6. Drop کردن ترافیک ناخواسته WAN.
  7. در انتها، Drop پیش‌فرض برای سایر ترافیک‌ها طبق سیاست امنیتی.
نکته درباره ترتیب: «Rule عمومی» را قبل از Ruleهای خاص قرار ندهید. مهم‌تر از حفظ یک شماره یا ترتیب ثابت، این است که استثناها قبل از FastTrack قرار بگیرند و Ruleهای Allow/Drop با سیاست امنیتی واقعی شبکه هماهنگ باشند.

چطور مطمئن شویم FastTrack واقعاً فعال است؟

بعد از تغییر Ruleها فقط به افزایش سرعت یا کاهش CPU اکتفا نکنید. Counterهای Firewall و جدول Connection Tracking را بررسی کنید.

بررسی Counterهای Firewall

/ip firewall filter print stats

با این خروجی می‌توانید Packet و Byte مربوط به Ruleهای FastTrack و Accept را بررسی کنید.

بررسی Connection Tracking

/ip firewall connection print

در جدول Connection به فیلدهایی مانند fasttrack=yes، hw-offload=yes، orig-fasttrack-packets و repl-fasttrack-packets توجه کنید. افزایش Counterهای FastTrack برای اتصال موردنظر نشانه مهمی است که آن اتصال واقعاً از مسیر FastTrack استفاده می‌کند.

FastTrack و Hardware Offload

در برخی تجهیزات و شرایط، FastTrack می‌تواند با Hardware Offload همراه شود و بخشی از پردازش به سخت‌افزار منتقل شود. با این حال، فعال بودن FastTrack به‌تنهایی تضمین نمی‌کند که همه ترافیک در سخت‌افزار پردازش شود.

پشتیبانی Hardware Offload به مدل دستگاه، معماری سخت‌افزار، RouterOS و شرایط مسیر بستگی دارد. بنابراین مقدار hw-offload و Counterهای مرتبط را بررسی و نتیجه را با تست واقعی مقایسه کنید.

چه تست‌هایی قبل و بعد از فعال‌سازی انجام دهیم؟

CPU روتر قبل و بعد از تغییر
Throughput در ساعات عادی و پرترافیک
عملکرد Simple Queue و Queue Tree
ارتباط‌های VPN و IPsec
اعمال صحیح Ruleهای Mangle
ثبت آمار Accounting
رفتار Hotspot
ارتباط بین VLANها و VRFها

اشتباهات رایج در استفاده از FastTrack

  1. کپی کردن Rule آماده بدون بررسی شبکه: Ruleهای اینترنتی ممکن است برای شبکه‌ای نوشته شده باشند که Queue، IPsec یا Mangle ندارد.
  2. قرار دادن استثنا بعد از FastTrack: استثنا باید قبل از FastTrack قرار بگیرد.
  3. حذف Rule پذیرش مکمل: FastTrack به‌تنهایی جای Rule accept established,related را نمی‌گیرد.
  4. نادیده گرفتن Queue: بعد از فعال‌سازی، محدودیت پهنای باند را با تست واقعی بررسی کنید.
  5. بررسی نکردن Counterها: فعال بودن Rule به معنی FastTracked شدن همه ترافیک موردنظر نیست.
  6. تغییر بدون Backup: قبل از تغییر Firewall خروجی بگیرید و مسیر بازگشت داشته باشید.
/export file=before-fasttrack-change /system backup save name=before-fasttrack-change

چک‌لیست نهایی فعال‌سازی FastTrack

  • ساختار Input و Forward مشخص شده است.
  • Connection Stateهای established و related را می‌شناسید.
  • ترافیک invalid طبق سیاست شبکه مدیریت شده است.
  • استثناهای Mangle، Queue، IPsec، VRF و Policy Routing مشخص شده‌اند.
  • Ruleهای استثنا قبل از FastTrack قرار گرفته‌اند.
  • Rule مکمل Accept بعد از FastTrack وجود دارد.
  • Counterهای Firewall قبل و بعد از تغییر بررسی شده‌اند.
  • Connection Tracking بررسی شده است.
  • Queue و VPN/IPsec تست شده‌اند.
  • قبل از تغییر Export یا Backup تهیه شده است.

جمع‌بندی

FastTrack یکی از ابزارهای مهم RouterOS برای کاهش سربار پردازش و افزایش توان عبوری در سناریوهای مناسب است. اما مزیت آن زمانی به‌درستی به دست می‌آید که بدانیم چه ترافیکی باید مسیر سریع را طی کند و چه ترافیکی به پردازش کامل Firewall، Queue، Mangle، IPsec، VRF یا Accounting نیاز دارد.

بنابراین به‌جای فعال‌کردن FastTrack برای «همه چیز»، ابتدا معماری و سیاست پردازش ترافیک را مشخص کنید، استثناها را قبل از FastTrack قرار دهید، Counterها و Connection Tracking را بررسی کنید و در نهایت نتیجه را با تست واقعی بسنجید.

پرسش‌های متداول

آیا FastTrack همیشه سرعت اینترنت را بیشتر می‌کند؟

خیر. FastTrack معمولاً با کاهش پردازش CPU می‌تواند توان عبوری را افزایش دهد، اما نتیجه به مدل روتر، نوع ترافیک و تنظیمات شبکه وابسته است.

آیا FastTrack برای همه اتصال‌ها مناسب است؟

خیر. اتصال‌هایی که به Queue، Mangle، IPsec، Accounting، Hotspot یا VRF وابسته‌اند باید جداگانه بررسی شوند و ممکن است نیاز به استثنا داشته باشند.

چرا بعد از FastTrack به Rule مربوط به Accept نیاز داریم؟

زیرا همه بسته‌های یک اتصال الزاماً FastTracked نمی‌شوند. برخی بسته‌ها برای حفظ Connection Tracking یا به دلیل نوع پروتکل از مسیر معمول عبور می‌کنند؛ Rule پذیرش مکمل این بسته‌ها را پوشش می‌دهد.

آیا FastTrack با Port Forward کار می‌کند؟

FastTrack از Source و Destination NAT پشتیبانی می‌کند، اما Port Forward باید همراه با سیاست Firewall و سناریوی واقعی شبکه تست شود. FastTrack به‌تنهایی مجوز عبور ترافیک ورودی به سرویس منتشرشده نیست.

از کجا بفهمیم یک Connection واقعاً FastTracked شده است؟

با /ip firewall connection print جدول Connection را بررسی کنید و فیلدهایی مانند fasttrack، hw-offload و Counterهای orig-fasttrack-packets و repl-fasttrack-packets را ببینید.

منبع فنی: مستندات MikroTik درباره Packet Flow و FastTrack و مستندات Connection Tracking. پیش از اعمال تنظیمات روی شبکه عملیاتی، دستورات را با نسخه RouterOS و معماری شبکه خود تطبیق دهید.