اشتباهی که شبکه را نابود می‌کند؛ تنظیمات خطرناک MikroTik که نباید انجام دهید

برای از کار انداختن یک شبکه همیشه به خرابی Core Switch، قطع فیبر یا یک حمله سایبری پیچیده نیاز نیست. گاهی تنها یک تغییر چندثانیه‌ای در RouterOS کافی است تا کاربران اینترنت نداشته باشند، VPN از کار بیفتد، VLANها به یکدیگر دسترسی پیدا کنند یا حتی پنل مدیریتی روتر مستقیماً در برابر اینترنت قرار گیرد.

مشکل اینجاست که بسیاری از اشتباهات تنظیمات MikroTik در لحظه اول خود را نشان نمی‌دهند. ممکن است اینترنت همچنان کار کند، Ping پاسخ دهد و کاربران نیز متوجه مشکلی نشوند؛ اما در پشت صحنه Firewall دور زده شده باشد، یک Management Service روی WAN باز مانده باشد یا FastTrack باعث شده باشد Queue و Policy Routing آن‌طور که انتظار داریم عمل نکنند.

در بعضی خطاها نتیجه برعکس است: امنیت مشکلی ندارد، اما CPU روتر ناگهان به 100 درصد نزدیک می‌شود، Throughput شبکه سقوط می‌کند یا با فعال‌شدن VLAN Filtering دسترسی مدیر شبکه به روتر قطع می‌شود.

بنابراین Configuration صحیح MikroTik فقط به این معنا نیست که «اینترنت کار می‌کند». یک تنظیم حرفه‌ای باید از نظر امنیت، Routing، Performance، Segmentation، قابلیت بازیابی و توسعه آینده نیز بررسی شده باشد.

منظور از «نابودکردن شبکه» در عنوان این مقاله چیست؟ منظور خرابی فیزیکی تجهیزات نیست؛ بلکه Configuration اشتباهی است که می‌تواند باعث Outage، افت شدید Performance، از دست رفتن Segmentation، دسترسی غیرمجاز یا از دست رفتن امکان مدیریت روتر شود.

هشدار: دستورات این مقاله برای بررسی و آموزش نوشته شده‌اند. هیچ Rule، VLAN، NAT یا Interface Configuration را بدون Backup، شناخت توپولوژی و مسیر جایگزین مدیریت روی روتر Production تغییر ندهید.

اشتباه اول: حذف Default Configuration بدون ساخت Firewall جایگزین

یکی از خطرناک‌ترین جملاتی که در بعضی آموزش‌های MikroTik دیده می‌شود این است:

«اول تنظیمات کارخانه را کامل پاک کنید تا روتر تمیز شود.»

این روش برای یک مدیر شبکه باتجربه که دقیقاً می‌داند Firewall، NAT، DHCP، Interface List و Management Access را چگونه از صفر بسازد قابل قبول است؛ اما برای بسیاری از شبکه‌ها می‌تواند اولین قدم به سمت یک روتر بدون حفاظت باشد.

Default Configuration بسیاری از مدل‌های MikroTik فقط برای راحتی کاربر نیست. بسته به مدل، مجموعه‌ای از تنظیمات اولیه شامل Firewall، LAN Bridge، DHCP، NAT و محدودیت دسترسی از WAN را ایجاد می‌کند.

چه اتفاقی ممکن است بیفتد؟

  • WinBox یا SSH از اینترنت قابل دسترسی شود.
  • هیچ Drop Rule مؤثری روی Input وجود نداشته باشد.
  • Forward Traffic بدون Policy صحیح عبور کند.
  • NAT یا DHCP به‌درستی کار نکند.
  • مدیر تصور کند چون اینترنت برقرار است، Router امن است.

چگونه بررسی کنیم؟

/ip firewall filter print detail
/ip firewall nat print detail
/interface list print
/interface list member print
/ip service print

اگر روتر مستقیماً به اینترنت متصل است و در Input Chain هیچ Policy واضحی برای محدودکردن WAN نمی‌بینید، Configuration باید جدی بررسی شود.

راهکار صحیح

اگر نیاز واقعی به Configuration خالی ندارید، Default Configuration را بی‌دلیل حذف نکنید. اگر قرار است روتر از صفر ساخته شود، ابتدا Plan مربوط به Firewall، LAN، WAN، Management و Recovery را آماده کنید و سپس تغییر را انجام دهید.

برای آشنایی با مراحل اصولی شروع کار، راهنمای راه‌اندازی سریع روتر MikroTik از صفر را مطالعه کنید.

اشتباه دوم: بازکردن WinBox، SSH یا WebFig روی اینترنت

بازکردن Port مربوط به WinBox روی Public IP به این دلیل که «گاهی از بیرون باید روتر را مدیریت کنم» یکی از بدترین Shortcutهای امنیتی است.

همین موضوع درباره SSH، WebFig، API و سایر Management Serviceها نیز صدق می‌کند.

تغییر Port پیش‌فرض نیز به‌تنهایی این مشکل را حل نمی‌کند. اگر سرویس همچنان از اینترنت عمومی قابل دسترسی باشد، فقط شماره Port تغییر کرده است و اصل Attack Surface باقی مانده است.

راهکار مناسب‌تر چیست؟

ابتدا یک VPN مانند WireGuard یا OpenVPN ایجاد کنید و مدیریت RouterOS را فقط از داخل شبکه مدیریتی یا VPN انجام دهید.

برای نمونه، یک Interface List جداگانه برای مدیریت بسازید:

/interface list
add name=MGMT

/interface list member
add list=MGMT interface=vlan99-mgmt

همچنین می‌توان سرویس‌ها را به Subnet مدیریتی محدود کرد:

/ip service
set [find name=winbox] address=192.168.99.0/24
set [find name=ssh] address=192.168.99.0/24

مهم: محدودیت Address در IP Services جایگزین Firewall مناسب روی شبکه‌های غیرقابل اعتماد نیست. Management Plane باید در Firewall نیز محافظت شود.

برای دسترسی امن از بیرون، راهنمای اتصال امن با WireGuard یا راه‌اندازی OpenVPN در MikroTik را مطالعه کنید.

اشتباه سوم: اشتباه در Input، Forward و ترتیب Firewall Ruleها

RouterOS Firewall فقط مجموعه‌ای از Allow و Drop نیست. اینکه Rule در کدام Chain و در چه موقعیتی قرار گرفته باشد، نتیجه را کاملاً تغییر می‌دهد.

دو Chain بسیار مهم عبارت‌اند از:

  • Input: ترافیکی که مقصد آن خود روتر است.
  • Forward: ترافیکی که از داخل روتر عبور می‌کند.

اگر قصد دارید دسترسی به WinBox را ببندید ولی Rule را در Forward قرار دهید، ترافیک Management خود روتر همچنان از آن Rule عبور نخواهد کرد.

برعکس، Rule مربوط به دسترسی کاربران LAN به یک Server دیگر باید در Forward بررسی شود، نه Input.

اشتباه خطرناک دیگر: Accept عمومی

Ruleهایی مانند نمونه زیر بدون Source، Interface یا Policy مشخص می‌توانند تمام منطق Firewall را بی‌اثر کنند:

# نمونه خطرناک - اجرا نکنید
/ip firewall filter
add chain=input action=accept

اگر چنین Ruleای پیش از Drop Ruleها قرار گیرد، Packetهای بعدی دیگر به بخش محدودکننده Firewall نمی‌رسند.

Baseline منطقی چگونه فکر می‌کند؟

یک Firewall Stateful معمولاً ابتدا Connectionهای معتبر قبلی را مدیریت می‌کند، Invalidها را کنار می‌گذارد و سپس فقط ترافیک جدید مجاز را براساس Policy عبور می‌دهد.

قبل از دستکاری Firewall فعلی، Counterها را ببینید:

/ip firewall filter print stats

نکته مهم: Ruleای که Counter آن صفر است الزاماً اضافی نیست؛ ممکن است برای شرایط Failover یا حمله خاص طراحی شده باشد. قبل از حذف، منطق کامل Firewall را بررسی کنید.

اشتباه چهارم: قراردادن WAN در Bridge یا Interface List اشتباه

گاهی هنگام اضافه‌کردن یک Port جدید، مدیر شبکه به اشتباه Ether مربوط به اینترنت را وارد Bridge داخلی می‌کند یا Interface WAN را عضو List مربوط به LAN قرار می‌دهد.

این اشتباه می‌تواند مرز منطقی بین شبکه داخلی و اینترنت را تغییر دهد.

نتیجه احتمالی

  • DHCP خارجی وارد Broadcast Domain داخلی شود.
  • DHCP Server داخلی به سمتی که نباید پاسخ دهد.
  • Management Access روی Interface اشتباه مجاز شود.
  • Firewall Ruleهایی که به Interface List وابسته‌اند رفتار متفاوتی پیدا کنند.
  • شبکه LAN و WAN در سطح دوم ناخواسته به یکدیگر متصل شوند.

ممیزی سریع

/interface bridge port print
/interface list member print
/ip dhcp-server print
/ip dhcp-client print

هر Interface باید نقش مشخصی داشته باشد: WAN، LAN، Trunk، Management، VPN یا Transit.

نام‌گذاری واضح مانند ether1-WAN، bridge-LAN و vlan99-MGMT نیز احتمال خطای انسانی را کاهش می‌دهد.

اشتباه پنجم: VLAN Filtering، PVID و Trunk اشتباه

VLAN یکی از نقاطی است که یک Configuration ظاهراً کوچک می‌تواند هم امنیت و هم دسترس‌پذیری شبکه را تحت تأثیر قرار دهد.

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

  • VLANهای Tagged روی Trunk
  • VLAN یا PVID مربوط به Access Port
  • عضویت Bridge یا CPU در VLANهای مدیریتی موردنیاز

اگر VLAN Filtering بدون آماده‌کردن Management Path فعال شود، ممکن است همان لحظه ارتباط WinBox قطع شود.

از طرف دیگر، اگر Trunk بیش از VLANهای موردنیاز را حمل کند یا Access Port فریم‌های Tagged غیرمنتظره را بپذیرد، Segmentation شبکه ضعیف می‌شود.

برای بررسی:

/interface bridge print detail
/interface bridge port print detail
/interface bridge vlan print detail
/interface vlan print detail

روی Access Port چه چیزی را کنترل کنیم؟

در طراحی استاندارد باید PVID صحیح، Ingress Filtering و Frame Type متناسب با نقش Port بررسی شوند.

روی Trunk چه چیزی را کنترل کنیم؟

فقط VLANهای واقعاً موردنیاز باید از Trunk عبور کنند. مفهوم «تمام VLANها را Tagged می‌کنم تا بعداً راحت باشم» می‌تواند سطح دسترسی غیرضروری ایجاد کند.

قبل از فعال‌کردن vlan-filtering: مطمئن شوید VLAN مدیریت، Bridge/CPU و Port مدیریتی به‌درستی در VLAN Table قرار گرفته‌اند و ترجیحاً تغییر را در Safe Mode انجام دهید.

اشتباه ششم: Multi-WAN بدون طراحی Routing و Session Symmetry

اضافه‌کردن اینترنت دوم فقط به معنای ساخت یک DHCP Client یا PPPoE Client دیگر نیست.

اگر دو WAN هر دو Default Route ایجاد کنند و Distance، Routing Table، Policy Routing و NAT به‌درستی طراحی نشده باشند، ممکن است Packet از یک WAN وارد و پاسخ از WAN دیگری خارج شود.

نتیجه می‌تواند شامل موارد زیر باشد:

  • قطع Sessionهای اینترنتی
  • کارنکردن Port Forward
  • ناپایداری VPN
  • رفتار تصادفی بعضی سایت‌ها
  • مشکل VoIP
  • پاسخ‌ندادن سرویس‌هایی که به Public IP خاص وابسته‌اند

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

/ip route print detail
/routing table print
/routing rule print
/ip firewall mangle print detail
/ip firewall nat print detail
/ip dhcp-client print detail

در یک Failover ساده می‌توان از Route Distance و Gateway Check استفاده کرد. در Load Balancing یا Policy Routing، طراحی Connection Mark و Routing Table اهمیت بیشتری پیدا می‌کند.

قاعده مهم: Multi-WAN را بر اساس «Connection» طراحی کنید، نه صرفاً Packet. Session باید تا حد امکان مسیر برگشت قابل پیش‌بینی داشته باشد.

اشتباه هفتم: استفاده کورکورانه از FastTrack

FastTrack یکی از قابلیت‌های بسیار مفید RouterOS برای کاهش پردازش CPU و افزایش Throughput است؛ اما همین ویژگی می‌تواند در شبکه پیچیده باعث رفتارهایی شود که در نگاه اول شبیه Bug به نظر می‌رسند.

مشکل زمانی ایجاد می‌شود که مدیر شبکه Rule عمومی FastTrack را کپی می‌کند، بدون اینکه بررسی کند شبکه از چه Featureهایی استفاده می‌کند.

ترافیک FastTracked می‌تواند از بخش‌هایی مانند موارد زیر عبور نکند یا آن‌ها را دور بزند:

  • Simple Queue
  • Queue Tree با Parent سراسری
  • بخشی از پردازش Firewall
  • Mangle موردنیاز بعضی سناریوها
  • IPsec
  • VRF Assignment
  • Policy Routing مبتنی بر Routing Mark

نشانه‌های FastTrack اشتباه

  • Queue برای بعضی کاربران کار نمی‌کند.
  • Policy Routing گاهی درست و گاهی اشتباه است.
  • ترافیک IPsec رفتار غیرمنتظره دارد.
  • Counter بعضی Ruleها افزایش پیدا نمی‌کند.
  • با غیرفعال‌شدن FastTrack مشکل برطرف می‌شود.

Ruleهای FastTrack را پیدا کنید

/ip firewall filter print detail where action=fasttrack-connection

راهکار این نیست که FastTrack همیشه غیرفعال باشد؛ بلکه باید Scope آن براساس معماری شبکه تعیین شود و Trafficهای حساس پیش از FastTrack استثنا شوند.

اشتباه هشتم: NAT و Port Forward بیش از حد باز

یک Rule کوچک DST-NAT می‌تواند یک Server داخلی را از اینترنت قابل دسترسی کند.

مثلاً اگر RDP، SSH، Database یا Management Interface بدون Source Restriction روی اینترنت Publish شود، Attack Surface شبکه به‌شدت افزایش پیدا می‌کند.

قبل از Port Forward این سؤال‌ها را بپرسید

  • آیا واقعاً باید این سرویس Public باشد؟
  • آیا VPN جایگزین مناسب‌تری است؟
  • آیا Source IP مشخص است؟
  • آیا Server مقصد Firewall مستقل دارد؟
  • آیا Log و Monitoring وجود دارد؟

تمام DST-NATها را ممیزی کنید

/ip firewall nat print detail where chain=dstnat

همچنین Masquerade نباید بدون فکر برای تمام Interfaceها و تمام Trafficها اعمال شود. در Site-to-Site VPN معمولاً می‌خواهیم IP واقعی دو شبکه حفظ شود و NAT ناخواسته می‌تواند Routing و Logging را پیچیده کند.

نکته دیگر اینکه NAT روی اولین Packet یک Connection تصمیم می‌گیرد. بعد از تغییر Ruleهای NAT، Sessionهای موجود ممکن است تا زمان انقضای Connection Tracking رفتار قبلی را حفظ کنند.

اشتباه نهم: DNS و ابزارهای مدیریت Layer 2 را بدون محدودیت رها کردن

DNS Open Resolver

گزینه زیر باعث می‌شود RouterOS درخواست DNS دریافت‌شده از Clientها را پاسخ دهد:

/ip dns
set allow-remote-requests=yes

این تنظیم به‌خودی‌خود اشتباه نیست. مشکل زمانی است که Firewall اجازه دهد درخواست DNS از WAN نیز به Router برسد.

اگر Router به‌عنوان DNS Resolver شبکه استفاده نمی‌شود:

/ip dns
set allow-remote-requests=no

اگر DNS داخلی لازم است، دسترسی آن را به VLANها و Subnetهای مورد اعتماد محدود کنید.

MAC WinBox و Neighbor Discovery

RouterOS علاوه بر IP، ابزارهای مدیریت لایه دوم نیز دارد. MAC WinBox و Neighbor Discovery برای نصب و عیب‌یابی بسیار مفید هستند، اما نباید بی‌دلیل در تمام Broadcast Domainها در دسترس باشند.

برای شبکه‌ای که Management VLAN دارد می‌توان دسترسی را محدود کرد:

/tool mac-server
set allowed-interface-list=MGMT

/tool mac-server mac-winbox
set allowed-interface-list=MGMT

/ip neighbor discovery-settings
set discover-interface-list=MGMT

در محیط‌های بسیار حساس می‌توان MAC Management را پس از نصب به‌طور کامل غیرفعال کرد.

اشتباه دهم: IPv4 را امن کنیم و IPv6 را فراموش کنیم

یکی از خطاهای رایج در شبکه‌هایی که سال‌ها IPv4 محور بوده‌اند این است که مدیر Firewall IPv4 را دقیق تنظیم می‌کند، اما توجهی به IPv6 ندارد.

Firewallهای IPv4 و IPv6 در RouterOS Rule Setهای جداگانه دارند.

بنابراین وجود این Rule:

/ip firewall filter ...

به این معنا نیست که IPv6 نیز با همان Policy محافظت می‌شود.

بررسی کنید آیا IPv6 فعال و دارای آدرس است

/ipv6 address print detail
/ipv6 route print detail
/ipv6 firewall filter print stats

اگر ISP Prefix IPv6 در اختیار شبکه قرار داده باشد، Clientها ممکن است Global IPv6 Address دریافت کنند و ترافیک IPv6 دیگر به NAT IPv4 وابسته نیست.

بنابراین Firewall IPv6 باید به‌اندازه IPv4 جدی گرفته شود.

برای Hardening کامل‌تر می‌توانید مقاله امنیت در MikroTik از کجا شروع می‌شود؟ را مطالعه کنید.

اشتباه یازدهم: Configuration درست از نظر منطقی، اما فاجعه‌بار برای CPU

همه خطاهای MikroTik امنیتی نیستند. بعضی تنظیمات از نظر Functional کار می‌کنند، اما مسیر Hardware Offloading یا Fast Path را از بین می‌برند و Router یا Switch مجبور می‌شود حجم زیادی از Traffic را در CPU پردازش کند.

یکی از نمونه‌ها فعال‌کردن گزینه‌های Bridge Firewall بدون درک Packet Flow است.

بررسی Bridge Settings

/interface bridge settings print
/interface bridge port print
/interface print stats-detail
/system resource print
/tool profile

اگر بعد از تغییر Bridge یا VLAN موارد زیر رخ داد، Hardware Offloading و Packet Flow را بررسی کنید:

  • CPU ناگهان بسیار بالا رفت.
  • Throughput از Gigabit به مقدار بسیار کمتری سقوط کرد.
  • Latency داخل LAN افزایش یافت.
  • Packet Loss زیر Load دیده شد.
  • Flag مربوط به Hardware Offload روی Port مورد انتظار وجود ندارد.

روی بعضی خانواده‌های Switch MikroTik، روش صحیح VLAN Configuration به Switch Chip بستگی دارد. استفاده از یک دستورالعمل یکسان برای همه نسل‌ها می‌تواند Traffic را از Hardware به CPU منتقل کند.

اشتباه رایج: اینکه یک دستگاه دارای 24 پورت Gigabit است به این معنا نیست که هر نوع Bridge، Firewall و VLAN Configuration را می‌توان با Wire Speed در CPU پردازش کرد.

اشتباه دوازدهم: تغییر Firewall، Route یا VLAN روی Production بدون Safe Mode

این اشتباه شاید از همه ساده‌تر باشد:

از راه دور به Router وارد شده‌اید و قصد دارید فقط «یک Rule کوچک» تغییر دهید.

Rule را Apply می‌کنید.

WinBox قطع می‌شود.

و حالا روتر در شهری دیگر قرار دارد.

RouterOS برای همین وضعیت Safe Mode دارد.

Safe Mode چه کاری انجام می‌دهد؟

در WinBox می‌توانید Safe Mode را فعال کنید. در Terminal نیز با میانبر مربوط به Safe Mode می‌توان وارد این وضعیت شد.

اگر Session به‌صورت غیرعادی قطع شود، تغییراتی که در Safe Mode انجام شده‌اند قابل Rollback هستند.

قبل از هر تغییر حساس

  1. Backup تهیه کنید.
  2. Export متنی تهیه کنید.
  3. Safe Mode را فعال کنید.
  4. فقط یک بخش کوچک را تغییر دهید.
  5. Connectivity را تست کنید.
  6. سپس مرحله بعد را انجام دهید.

Export بدون نمایش Secrets:

/export show-sensitive=no file=before-change

Backup:

/system backup save name=before-change

Backup خود روتر را تنها نسخه پشتیبان ندانید. فایل را از Router دانلود و در محل امن نگهداری کنید؛ زیرا در خرابی Storage یا خود دستگاه ممکن است به فایل محلی دسترسی نداشته باشید.

دو اشتباه دیگر که نباید نادیده گرفته شوند

استفاده از حساب مدیریتی ضعیف یا مشترک

برای مدیران مختلف از حساب جداگانه استفاده کنید و حساب‌های بلااستفاده را غیرفعال نمایید. Password باید طولانی، منحصربه‌فرد و خارج از فایل‌های عمومی Configuration نگهداری شود.

حساب‌ها را بررسی کنید:

/user print detail

رهاکردن RouterOS قدیمی

روتر Edge Device است و مستقیماً با شبکه‌های غیرقابل اعتماد در ارتباط است. نگهداری نسخه‌های قدیمی بدون برنامه Patch Management ریسک غیرضروری ایجاد می‌کند.

نسخه فعلی را بررسی کنید:

/system resource print
/system package update check-for-updates

در شبکه Production قبل از Upgrade، Release Notes، Backup، Compatibility و Window بازگشت را بررسی کنید.

ممیزی ۵ دقیقه‌ای MikroTik؛ قبل از اینکه مشکل جدی شود

اگر روتر موجودی را تحویل گرفته‌اید یا مدت زیادی از آخرین Audit گذشته است، دستورات Read-Only زیر می‌توانند تصویر اولیه خوبی از وضعیت Configuration بدهند:

/system resource print
/system package print
/user print detail

/interface print detail
/interface list member print
/interface bridge print detail
/interface bridge port print detail
/interface bridge vlan print detail

/ip address print detail
/ip route print detail
/ip dhcp-client print detail
/ip dhcp-server print detail

/ip firewall filter print stats
/ip firewall nat print stats
/ip firewall mangle print stats

/ip service print
/ip dns print
/ip neighbor discovery-settings print
/tool mac-server print
/tool mac-server mac-winbox print

/ipv6 address print detail
/ipv6 firewall filter print stats

در Audit فقط دنبال Error Flag نباشید. Configuration ممکن است کاملاً Valid باشد اما از نظر معماری اشتباه باشد.

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

  • Management Service با Address برابر 0.0.0.0/0
  • Rule عمومی Accept در ابتدای Input یا Forward
  • DST-NATهای بدون Source Restriction
  • FastTrack روی شبکه دارای Policy Routing یا Queue پیچیده
  • WAN داخل Bridge داخلی
  • VLANهای بدون Documentation
  • چند Default Route با منطق نامشخص
  • DNS Remote Requests بدون Firewall مشخص
  • نبود IPv6 Firewall در شبکه دارای IPv6
  • Management از VLAN کاربران
  • MAC WinBox روی تمام Interfaceها
  • CPU بالا بدون دلیل مشخص

فرایند درست تغییر Configuration در MikroTik

بهترین راه جلوگیری از این مشکلات، استفاده از Change Management حتی در شبکه‌های کوچک است.

  1. هدف تغییر را مشخص کنید: دقیقاً قرار است چه مشکلی حل شود؟
  2. Current State را ثبت کنید: Route، Firewall، VLAN و Interfaceهای مرتبط.
  3. Backup بگیرید: Binary Backup و Export.
  4. Rollback Plan بنویسید: اگر نتیجه اشتباه بود چگونه برمی‌گردید؟
  5. Safe Mode را فعال کنید: مخصوصاً برای Remote Change.
  6. یک تغییر در هر مرحله: پنج بخش را هم‌زمان تغییر ندهید.
  7. Test Plan داشته باشید: LAN، اینترنت، DNS، VPN، VoIP و سرویس‌های حساس.
  8. Counterها را کنترل کنید: Ruleای که ساخته‌اید واقعاً Match می‌شود؟
  9. CPU و Traffic را ببینید: تغییر صحیح نباید Performance را ناخواسته نابود کند.
  10. Documentation را به‌روز کنید: Configuration بدون مستندات، مشکل آینده است.

اگر بعد از تغییر Configuration شبکه از کار افتاد چه کنیم؟

۱. چند تغییر جدید انجام ندهید

یکی از بدترین واکنش‌ها این است که پس از اولین مشکل، چند Rule و Route دیگر نیز تغییر داده شوند. در این حالت علت اصلی گم می‌شود.

۲. Scope مشکل را مشخص کنید

  • خود Router قابل دسترسی است؟
  • LAN کار می‌کند؟
  • Gateway Ping می‌شود؟
  • Router اینترنت دارد؟
  • Client اینترنت دارد؟
  • DNS مشکل دارد یا Routing؟
  • تمام VLANها مشکل دارند یا فقط یکی؟

۳. از پایین به بالا تست کنید

/interface print
/ip address print
/ip route print
/ping 1.1.1.1
/ip firewall filter print stats
/ip firewall nat print stats

۴. آخرین تغییر را بررسی کنید

/system history print

۵. اگر Safe Mode فعال بوده است

در صورت قطع غیرعادی Session، RouterOS می‌تواند تغییرات Safe Mode را Rollback کند. دوباره متصل شوید و قبل از تکرار تغییر، علت قطع را مشخص کنید.

۶. در صورت از دست رفتن IP Management

اگر Layer 2 Path همچنان موجود باشد، MAC WinBox ممکن است برای بازیابی دسترسی مفید باشد.

۷. Reset آخرین گزینه است

تا زمانی که Backup، Console، MAC WinBox یا امکان Rollback وجود دارد، Reset کامل نباید اولین واکنش باشد.

در صورت نیاز به بازیابی کامل، راهنمای ریست روتر MikroTik را بررسی کنید.

ممیزی و طراحی MikroTik با گروه بیستون

بسیاری از مشکلات شبکه زمانی ایجاد می‌شوند که Configuration طی چند سال توسط افراد مختلف تغییر کرده باشد. Ruleهای قدیمی باقی می‌مانند، VLAN جدید اضافه می‌شود، اینترنت دوم وارد شبکه می‌شود و در نهایت هیچ‌کس تصویر دقیقی از Packet Flow ندارد.

در چنین شرایطی تعویض Router لزوماً مشکل را حل نمی‌کند. ابتدا باید Configuration و توپولوژی بررسی شوند.

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

برای بررسی مؤثر، موارد زیر مفید هستند:

  • مدل Router و نسخه RouterOS
  • توپولوژی شبکه
  • تعداد WANها
  • VLANها و Subnetها
  • نوع VPNها
  • تعداد کاربران
  • Firewall و NAT Policy
  • مشکل فعلی شبکه
  • CPU و RAM هنگام Peak
  • برنامه توسعه آینده

برای بررسی تجهیزات مناسب به بخش تجهیزات MikroTik گروه بیستون مراجعه کنید. برای طراحی، ممیزی یا بررسی مشکلات Configuration نیز از طریق صفحه پشتیبانی و مشاوره فنی درخواست خود را ثبت کنید.

سؤالات متداول درباره اشتباهات تنظیمات MikroTik

خطرناک‌ترین اشتباه در تنظیم MikroTik چیست؟

یک اشتباه واحد برای همه شبکه‌ها وجود ندارد، اما حذف Firewall بدون جایگزین، بازکردن Management روی WAN و اشتباه در VLAN یا Interface List از خطاهای بسیار پرریسک هستند.

آیا حذف Default Configuration میکروتیک اشتباه است؟

برای مدیر حرفه‌ای که Configuration کامل را از صفر طراحی می‌کند خیر؛ اما حذف تنظیمات کارخانه بدون ساخت Firewall، NAT، LAN و Management Policy جایگزین می‌تواند خطرناک باشد.

آیا تغییر پورت WinBox برای امنیت کافی است؟

خیر. تغییر Port فقط Scanهای بسیار ساده را کاهش می‌دهد. Management بهتر است از WAN عمومی بسته باشد و از طریق VPN یا Management Network انجام شود.

چرا بعد از فعال‌کردن VLAN Filtering ارتباط WinBox قطع شد؟

احتمالاً VLAN مدیریت، Bridge/CPU Port یا Tagged/Untagged Membership به‌درستی تنظیم نشده است. قبل از فعال‌سازی VLAN Filtering باید Management Path کامل بررسی شود.

چرا Queue میکروتیک کار نمی‌کند ولی تنظیم آن درست است؟

یکی از مواردی که باید بررسی شود FastTrack است. بخشی از ترافیک FastTracked می‌تواند Simple Queue و برخی مسیرهای Queue Processing را دور بزند.

آیا FastTrack را غیرفعال کنیم؟

الزاماً خیر. FastTrack می‌تواند Performance را بهبود دهد. باید مشخص شود چه Trafficهایی می‌توانند FastTrack شوند و چه Trafficهایی باید برای Queue، IPsec، VRF یا Policy Routing از آن مستثنا باشند.

چرا Port Forward بعد از تغییر NAT هنوز مثل قبل کار می‌کند؟

NAT Decision برای اولین Packet Connection انجام می‌شود و Connection Tracking نتیجه را نگهداری می‌کند. Session موجود ممکن است تا زمان Expire شدن همچنان رفتار قبلی داشته باشد.

آیا allow-remote-requests=yes خطرناک است؟

برای DNS Server داخلی می‌تواند کاملاً طبیعی باشد؛ مشکل زمانی است که Firewall اجازه دهد منابع غیرقابل اعتماد یا اینترنت عمومی نیز به DNS Router دسترسی داشته باشند.

آیا Firewall IPv4 از IPv6 هم محافظت می‌کند؟

خیر. RouterOS برای IPv4 و IPv6 Firewall Rule Set جداگانه دارد و IPv6 باید مستقل بررسی شود.

Safe Mode در MikroTik چه کاربردی دارد؟

برای تغییرات پرریسک مانند Firewall، Route و VLAN استفاده می‌شود تا در صورت قطع غیرعادی Session بتوان تغییرات انجام‌شده را Rollback کرد.

قبل از تغییر Firewall چه کاری انجام دهیم؟

Backup و Export تهیه کنید، Safe Mode را فعال نمایید، Counterهای Ruleها را بررسی کنید و یک Rollback Plan داشته باشید.

چرا CPU سوئیچ MikroTik بعد از VLAN Configuration بالا رفته است؟

ممکن است Traffic به‌جای Switch Chip در CPU پردازش شود. Hardware Offloading، مدل Switch Chip، Bridge Configuration و روش VLAN Filtering باید بررسی شوند.

آیا یک Configuration آماده اینترنتی را می‌توان روی همه MikroTikها استفاده کرد؟

خیر. مدل سخت‌افزار، Switch Chip، تعداد WAN، VLAN، RouterOS Version و معماری شبکه متفاوت هستند. Configuration باید با محیط واقعی تطبیق داده شود.

جمع‌بندی؛ خطرناک‌ترین Configuration همان تنظیمی است که دلیلش را نمی‌دانیم

بزرگ‌ترین مشکل RouterOS پیچیدگی آن نیست؛ بلکه این است که تقریباً برای هر سناریو چند روش مختلف وجود دارد و بسیاری از روش‌ها در ظاهر کار می‌کنند.

ممکن است Router اینترنت داشته باشد اما Firewall آن ناامن باشد. VLANها کار کنند اما Traffic از CPU عبور کند. VPN متصل شود اما FastTrack Policy آن را مختل کند. Port Forward کار کند اما Server داخلی بدون محدودیت در معرض اینترنت قرار گرفته باشد.

به همین دلیل اشتباهات تنظیمات MikroTik فقط زمانی مشخص نمی‌شوند که شبکه کاملاً Down شده باشد.

Configuration حرفه‌ای باید چهار سؤال را پاسخ دهد:

  1. این Rule یا Setting دقیقاً چه کاری انجام می‌دهد؟
  2. این Traffic در Packet Flow از چه مسیری عبور می‌کند؟
  3. اگر این تنظیم حذف یا اشتباه شود، چه چیزی در معرض خطر قرار می‌گیرد؟
  4. اگر تغییر باعث قطع ارتباط شود، چگونه Rollback خواهیم کرد؟

Firewall، VLAN، NAT، Routing، FastTrack و Management Access نباید مجموعه‌ای از دستورهای کپی‌شده از اینترنت باشند. هرکدام باید بخشی از یک طراحی مستند و قابل توضیح باشند.

در بسیاری از مواقع، خطرناک‌ترین Rule شبکه Ruleای نیست که کاملاً اشتباه نوشته شده باشد؛ بلکه Ruleای است که هیچ‌کس دیگر نمی‌داند چرا وجود دارد.

اگر Configuration روتر طی سال‌ها تغییر کرده، قبل از اضافه‌کردن Ruleهای جدید ابتدا آن را Audit و مستند کنید. یک ساعت بررسی ساختار شبکه می‌تواند از ساعت‌ها قطعی و عیب‌یابی در آینده جلوگیری کند.