MikroTik وRouterOS للمبتدئين: أول إعداد آمن

لنفرض أنك اشتريت جهاز MikroTik صغيراً مثل hEX أو hAP، لأنك قرأت أنه رخيص ويفعل ما تفعله أجهزة الشركات، ووصلته بالإنترنت فعمل من أول مرة، ثم فتحت أداة WinBox فوجدت أمامك عشرات القوائم: Bridge وFirewall وMangle وQueues وRouting وContainers، ولا تعرف ما الذي يحميك منها وما الذي يفتح جهازك للعالم. وهذه هي المشكلة الحقيقية مع RouterOS: النظام يعطيك كل شيء، ولا يمنعك من شيء، ولذلك فإن آلاف الأجهزة التي اخترقت في السنوات الماضية لم تخترق لأن النظام ضعيف فقط، وإنما لأن أصحابها تركوا منافذ الإدارة مفتوحة على الإنترنت بكلمات مرور قديمة.

وفي المودم وONT والراوتر والسويتش وAccess Point: ما الفرق بينها؟ عرفنا وظيفة كل جهاز في الشبكة، وفي وضع الجسر Bridge Mode رأينا كيف يصبح ال Router الخاص بك هو الجدار الوحيد أمام الإنترنت، وهذه السلسلة تأخذ أشهر هذه الأجهزة عند مديري الشبكات الصغيرة، وهي جزء من مرحلة معدات الشبكة في خارطة الطريق.

المواضيع في السلسلة:

1. MikroTik وRouterOS للمبتدئين: الأجهزة والتراخيص وWinBox، وأول إعداد آمن (الموضوع الحالي).
2. جدار الحماية في MikroTik RouterOS بالتفصيل: السلاسل وتتبع الاتصالات والقوائم وNAT.
3. MikroTik في الواقع: شبكة الضيوف وVLAN وWireGuard وتوجيه المنافذ وأكثر من مزود إنترنت.

وفي هذا المقال سوف نتناول:

• لماذا نشرح نظاماً مغلق المصدر في موقع يهتم بالمصادر المفتوحة، وما هي البدائل المفتوحة.
• عائلات أجهزة MikroTik، والفرق بين RouterOS وSwOS، والراوتر الافتراضي CHR.
• مستويات الترخيص License Levels، وترخيص CHR المجاني وحدوده، مع قياس حقيقي.
• أدوات الإدارة: WinBox وWebFig وSSH وAPI، والإدارة عبر عنوان MAC ومخاطرها.
• الإعداد الافتراضي Default Configuration، وما الذي يحميه، وكيف يبدو جهاز بلا إعداد افتراضي.
• أول إعداد آمن خطوة خطوة على RouterOS حقيقي يعمل في مختبرنا، مع المخرجات الحقيقية.
• الفرق بين النسخة الاحتياطية Backup والتصدير Export، ووضع الأمان Safe Mode.
• ثغرة WinBox عام 2018 وشبكة Mēris عام 2021، وما الذي نتعلمه منهما.

RouterOS نظام مغلق المصدر، فلماذا نشرحه؟

قبل أن نبدأ يجب أن نكون صريحين: RouterOS نظام مملوك لشركة MikroTik اللاتفية ومغلق المصدر، والترخيص يأتي مع الجهاز أو يشترى للنسخ الافتراضية كما سيأتي، وهذا يخالف ما نفضله في هذا الموقع من برامج مفتوحة المصدر يمكنك أن تقرأ كودها وتنقلها من جهاز إلى آخر. ولكننا نشرحه لسبب عملي، وهو أنه منتشر جداً في الشبكات الصغيرة والمتوسطة وعند مزودي الإنترنت اللاسلكي، وأجهزته رخيصة مقارنة بما تقدمه، فمن المرجح أنك سوف تجده أمامك في مكتب أو عند عميل حتى لو لم تختره بنفسك، ومن الأفضل أن تعرف كيف تؤمنه.

وإذا كنت تبدأ من الصفر وتريد نظاماً مفتوحاً، فهناك بديلان سوف نشرحهما في المرحلة نفسها: OpenWrt الذي يعمل على كثير من أجهزة الراوتر المنزلية بدلاً من برنامجها الأصلي، وOPNsense الذي يحول حاسوباً صغيراً إلى جدار ناري كامل، وتجد مقالاتهما المخططة في مرحلة معدات الشبكة. وأغلب ما سوف تتعلمه هنا عن السلاسل Chains وتتبع الاتصالات Connection Tracking وال NAT ينطبق عليهما أيضاً، لأنها مفاهيم من نواة Linux ومن الشبكات عموماً، وليست خاصة ب MikroTik.

عائلات الأجهزة: من hAP في البيت إلى CCR في مركز البيانات

MikroTik تبيع عشرات الأجهزة، ولكنها تنقسم إلى عائلات قليلة، وكلها تقريباً تعمل بالنظام نفسه RouterOS، وهذه هي النقطة الأهم: ما تتعلمه على جهاز منزلي صغير هو نفسه ما تكتبه على راوتر في مركز بيانات، والفرق في المعالج وعدد المنافذ وسرعتها. والصورة التالية تبين العائلات الرئيسية:

والجدول التالي يلخص العائلات مع أمثلة من صفحة الراوترات وصفحة السويتشات في موقع الشركة:

وأسماء الأجهزة الطويلة ليست عشوائية، فالشركة تشرح طريقة قراءتها في صفحة Product Naming، فمثلاً في RB5009UG+S+IN الحرف U يعني منفذ USB، وG يعني Gigabit Ethernet، وIN يعني علبة للاستخدام الداخلي Indoor، وفي CRS326-24G-2S+RM الرقم 24G يعني 24 منفذاً بسرعة Gigabit، و2S+ يعني منفذي SFP+، وRM يعني علبة تركب في الرف Rack-mount.

RouterOS أم SwOS؟

RouterOS نظام توجيه كامل، فيه جدار ناري وNAT وVPN وتوجيه ديناميكي وحتى Containers، ويمكنك إدارته من الواجهة الرسومية ومن سطر الأوامر ومن API. أما SwOS فهو نظام خفيف مخصص لأجهزة السويتش فقط، يقدم VLAN وعزل المنافذ وقوائم تحكم ACL وMirroring، ويدار من المتصفح فقط عبر HTTP على IPv4، ولا يوجد فيه سطر أوامر ولا SSH ولا API ولا WinBox كما تنص صفحته الرسمية. وكثير من سويتشات CRS3xx تدعم الإقلاع المزدوج Dual Boot، فتختار بين النظامين بالأمر /system routerboard settings set boot-os=swos كما في دليل CRS3xx. وقاعدة الاختيار بسيطة: إذا كان السويتش سوف يبقى سويتشاً فقط فإن SwOS أبسط وأقل سطحاً للهجوم، وإذا احتجت أن يوجه أو يدار بسكربتات فاستخدم RouterOS، وهذه السلسلة كلها عن RouterOS.

الراوتر الافتراضي CHR

CHR هو RouterOS نفسه مجهزاً ليعمل آلة افتراضية على معالج x86_64، وتنزله ملف قرص بإحدى الصيغ .img و.vdi و.vmdk و.vhdx و.ova، ويعمل على Proxmox وVMware وHyper-V وVirtualBox وفي سحابات مثل AWS وHetzner. ويستخدمه الناس كراوتر VPN في السحابة، أو كبوابة بين شبكات افتراضية، أو للتعلم والتجربة دون جهاز، وهذا ما سوف نفعله في هذه السلسلة، فكل المخرجات التي تراها هنا من CHR حقيقي يعمل في مختبرنا.

التراخيص: ما الذي تدفع ثمنه؟

الترخيص في RouterOS لا يفتح الميزات بالطريقة التي تتوقعها، فأغلب الميزات موجودة في كل المستويات، وما يتغير هو أشياء محددة مثل عدد أنفاق VPN القديمة ووضع نقطة الوصول اللاسلكية لعدة عملاء، والجدول التالي مختصر من صفحة ترخيص أجهزة MikroTik:

في الجدول أعلاه لاحظ التالي:

• أجهزة MikroTik تأتي بترخيص مثبت مسبقاً، فلا تحتاج أن تشتري شيئاً عندما تشتري الجهاز، والترخيص مربوط بالجهاز ولا ينتقل إلى جهاز آخر.
• المستوى 2 كان ترخيصاً انتقالياً من الصيغة القديمة ولم يعد يباع، ولذلك لا يظهر في الجدول.
• الميزات التي لا تظهر في الجدول لا يقيدها الترخيص، فالجدار الناري وWireGuard وVLAN وال Queues تعمل كلها في كل مستوى.
• تثبيت RouterOS على حاسوب x86 عادي يعطيك 24 ساعة من التجربة، ثم تحتاج إلى مستوى مجاني محدود أو مفتاح مدفوع كما في صفحة ترخيص x86.

ترخيص CHR: مجاني بحد سرعة

CHR له نظام ترخيص مختلف تشرحه صفحة ترخيص CHR، فهو يبدأ بالمستوى Free الذي يعمل بلا حد زمني وبكل الميزات، ولكنه يحد سرعة الإرسال Upload في كل واجهة بميغابت واحد في الثانية، ثم المستويات الدائمة P1 بحد 1 Gbps وسعر 45 دولاراً، وP10 بحد 10 Gbps وسعر 95 دولاراً، وP-Unlimited بلا حد وسعر 250 دولاراً، ويمكنك أن تجرب أي مستوى مدفوع مجاناً لمدة 60 يوماً بعد ربط النسخة بحسابك في موقع MikroTik. ولاحظ أن النسخة المرخصة يجب أن تتصل بسيرفر التراخيص بشكل دوري، وإذا لم تتصل قبل الموعد المحدد فإنها تستمر في العمل بالمستوى نفسه ولكنها لا تقبل التحديث إلى إصدار أحدث، وهي نقطة مهمة إذا كنت تشغله في شبكة معزولة.

والنسخة التي في مختبرنا تعمل بالمستوى المجاني، والمخرج التالي منها:

[admin@CHR] > /system license print
  system-id: VAEw6wxVLvC
      level: free       

وقد يتساءل البعض: هل الحد بميغابت واحد حقيقي أم مكتوب فقط؟ والإجابة أننا قسنا ذلك، فقد نزلنا الجزء الأول من ملف بحجم 2 ميغابايت من خادم MikroTik مرتين، مرة من الحاسوب مباشرة، ومرة من جهاز في الشبكة الداخلية يمر عبر CHR، على الجهاز نفسه وفي الوقت نفسه، والمخرج سوف يكون كما يلي:

# from the LAN client, through CHR (free licence)
206 2000000B total=17.760772s speed=112607B/s
# from the host, directly
2000000B total=3.260757s speed=613354B/s

والرقم 112607 بايت في الثانية يساوي تقريباً 0.9 ميغابت، وهو الحد المكتوب في التوثيق، لأن CHR يرسل البيانات إلى الجهاز الداخلي عبر واجهة LAN وهذه الواجهة محدودة الإرسال، وهذا القياس توضيحي من مختبر واحد وليس اختبار أداء. لذلك فإن النسخة المجانية ممتازة للتعلم ولراوتر إدارة صغير، ولا تصلح لتمرير حركة حقيقية.

أدوات الإدارة: من أين تدخل إلى الجهاز؟

RouterOS يقدم طرقاً كثيرة للإدارة، وكل طريقة منفذ مفتوح يجب أن تعرف من يستطيع الوصول إليه، والصورة التالية تبين هذه الطرق:

• WinBox: البرنامج الرسمي للإدارة الرسومية، والإصدار الحالي WinBox 4 يعمل على Windows وLinux وmacOS، ويتصل على المنفذ 8291/tcp، ويستخدم بروتوكول ECSRP لتبادل المفاتيح والتحقق من كلمة المرور، فلا تمر كلمة المرور على الشبكة. وهو أسرع طريقة للتعلم لأن كل قائمة فيه تقابل قائمة في سطر الأوامر.
• WebFig: الواجهة نفسها تقريباً من المتصفح، يقدمها سيرفر الويب في الجهاز على الخدمة www بالمنفذ 80، أو www-ssl بالمنفذ 443 بعد أن تضع شهادة، كما في صفحة WebFig. ولاحظ أن الخدمة نفسها تقدم REST API، فإغلاقها يغلق الاثنين.
• سطر الأوامر CLI عبر SSH: على المنفذ 22، وهي الطريقة التي نستخدمها في هذه السلسلة، لأن الأوامر تنسخ وتحفظ وتراجع، ويمكن أن تدخل بمفتاح SSH بدلاً من كلمة المرور.
• Telnet وFTP: بروتوكولان قديمان ينقلان كلمة المرور نصاً واضحاً، ولا يوجد سبب لتركهما يعملان.
• API: على المنفذ 8728، ونسخة مشفرة api-ssl على 8729، وتستخدمها أدوات المراقبة والسكربتات، كما في صفحة API.
• MAC-Telnet وMAC-WinBox: يتصلان بالجهاز عن طريق عنوان MAC في الطبقة الثانية، دون أي عنوان IP على الطرفين، وهذا مفيد جداً عندما تخطئ في إعداد العناوين وتفقد الوصول، ولكنه يعني أيضاً أن أي جهاز في نفس الشبكة المحلية يستطيع أن يحاول الدخول حتى لو كان الجدار الناري يمنع كل منافذ IP، لأن هذه الحركة لا تمر عبر جدار IP أصلاً، ولذلك فإن صفحة MAC Server تنص على أن الإعداد الافتراضي يسمح بها على واجهات قائمة LAN فقط.
• اكتشاف الجيران Neighbor Discovery: الجهاز يعلن عن نفسه واسمه وإصداره بالبروتوكولات MNDP وCDP وLLDP، وهذا ما يجعل WinBox يجده في قائمة Neighbors، وهي معلومات لا تريد أن يراها من هو خارج شبكتك.

والقاعدة التي توصي بها MikroTik نفسها في صفحة Securing your router أن الوصول عن بعد يكون عبر VPN مثل WireGuard وليس بفتح منافذ الإدارة، وسوف نطبق ذلك في المقال الثالث.

المختبر: RouterOS حقيقي داخل Docker

لكي تكون كل المخرجات في هذه السلسلة حقيقية، شغلنا CHR في محاكي QEMU داخل Container على حاسوب Windows 11 مع Docker Desktop، وأعطيناه واجهتين: ether1 تمثل الإنترنت (WAN) وتأخذ عنوانها من شبكة QEMU الداخلية، وether2 تمثل الشبكة الداخلية (LAN) ويقف خلفها جهاز تجريبي بالعنوان 192.168.88.10. وتوجد Docker Images جاهزة من المجتمع لهذا الغرض مثل docker-routeros، وهو مشروع برخصة MIT ما زال يحدث، ولكننا فضلنا أن نبني ال Image بأنفسنا حتى ترى كل خطوة، فملف ال Dockerfile كان كما يلي:

FROM alpine:3.22
RUN apk add --no-cache qemu-system-x86_64 qemu-img socat iproute2 openssh-client curl iputils nmap-ncat tcpdump busybox-extras
COPY chr-7.24.5.img /chr/chr.img
COPY start.sh /start.sh
RUN chmod +x /start.sh
ENTRYPOINT ["/start.sh"]

وملف التشغيل start.sh ينشئ واجهة tap للشبكة الداخلية ثم يشغل CHR:

#!/bin/sh
# Lab: RouterOS CHR in QEMU. ether1 = WAN (QEMU user network, the "Internet" side),
# ether2 = LAN (tap0 in this container, which plays a LAN client at 192.168.88.10).
set -e
ip tuntap add dev tap0 mode tap
ip addr add 192.168.88.10/24 dev tap0
ip link set tap0 up
cp /chr/chr.img /tmp/disk.img
# management through the LAN side, as an admin PC on the LAN would do
socat TCP-LISTEN:2222,fork,reuseaddr TCP:192.168.88.1:22 &
socat TCP-LISTEN:8080,fork,reuseaddr TCP:192.168.88.1:80 &
exec qemu-system-x86_64 -enable-kvm -m 256 -smp 1 -nographic -serial mon:stdio \
  -drive file=/tmp/disk.img,format=raw,if=virtio \
  -netdev user,id=wan,net=10.0.2.0/24,hostfwd=tcp::2223-10.0.2.15:22,hostfwd=tcp::8081-10.0.2.15:80,hostfwd=tcp::8443-10.0.2.15:8443 \
  -device virtio-net-pci,netdev=wan,mac=52:54:00:00:01:01 \
  -netdev tap,id=lan,ifname=tap0,script=no,downscript=no \
  -device virtio-net-pci,netdev=lan,mac=52:54:00:00:02:02

ثم نزلنا ملف القرص من موقع MikroTik وبنينا ال Image وشغلنا ال Container، مع ربط المنافذ بالعنوان 127.0.0.1 فقط حتى لا يصل إليها أحد من خارج الحاسوب:

curl -o chr.img.zip https://download.mikrotik.com/routeros/7.24.5/chr-7.24.5.img.zip
unzip chr.img.zip
docker build -t lab-mikrotik-chr:7.24.5 .
docker run -d --name lab-mikrotik-chr --device /dev/kvm --device /dev/net/tun --cap-add NET_ADMIN \
  -p 127.0.0.1:21180:2222 -p 127.0.0.1:21181:8080 \
  -p 127.0.0.1:21182:2223 -p 127.0.0.1:21183:8081 \
  lab-mikrotik-chr:7.24.5

في الإعداد أعلاه لاحظ التالي:

• المنفذ 21180 يصل إلى SSH في الراوتر من جهة الشبكة الداخلية، كما يفعل حاسوب المدير في المكتب، والمنفذ 21182 يصل إلى SSH نفسه من جهة WAN، كما يفعل أي شخص على الإنترنت، وبهذا نستطيع أن نختبر الجهتين.
• الخيار --device /dev/kvm يعطي QEMU تسريع العتاد الافتراضي، فيقلع CHR في ثوان.
• أعطينا CHR ذاكرة 256 ميغابايت وهو الحد الأدنى المذكور في التوثيق، والتوثيق يوصي ب 1024 ميغابايت لأي استخدام حقيقي.

وأول ما فعلناه بعد الإقلاع أن طلبنا معلومات النظام عبر SSH من جهة WAN، والمخرج سوف يكون كما يلي:

[admin@CHR] > /system resource print
                   uptime: 1m33s
                  version: 7.24.5 (stable)
               build-time: 2026-09-29 14:21:27
          minimum-version: 7.1
              free-memory: 50.9MiB
             total-memory: 256.0MiB
                      cpu: QEMU
                cpu-count: 1
            cpu-frequency: 4199MHz
                 cpu-load: 6%
           free-hdd-space: 69.1MiB
          total-hdd-space: 89.2MiB
  write-sect-since-reboot: 1296
         write-sect-total: 1296
        architecture-name: x86_64
               board-name: CHR QEMU Standard PC (i440FX + PIIX, 1996)
                 platform: MikroTik

ولاحظ أننا دخلنا من جهة الإنترنت باسم المستخدم admin دون كلمة مرور ونفذ الأمر مباشرة، وهذا هو موضوع القسم التالي.

الإعداد الافتراضي: ما الذي يحميك قبل أن تلمس شيئاً؟

كل أجهزة MikroTik تأتي بإعداد افتراضي Default Configuration يختلف حسب نوع الجهاز، وتشرحه صفحة Default Configurations، فأجهزة البيت مثل hAP وhEX تأخذ إعداد AP Router الذي يفعل التالي:

• المنفذ الأول ether1 هو WAN، وعليه عميل DHCP يأخذ العنوان من المزود، والجدار الناري لـ IPv4 وIPv6 يحميه، ومعه NAT للشبكة الداخلية، والإدارة عبر MAC واكتشاف الجيران معطلان عليه.
• بقية المنافذ والواجهات اللاسلكية في Bridge واحد للشبكة الداخلية بالعنوان 192.168.88.1/24، مع سيرفر DHCP وDNS.
• المستخدم admin محمي بكلمة مرور، وفي الأجهزة الحديثة تكون كلمة مرور فريدة لكل جهاز مطبوعة على الملصق وعلى العلبة كما في صفحة كلمات المرور الافتراضية، أما الأجهزة الأقدم فكانت تأتي ب admin بلا كلمة مرور.

ولكن هناك أجهزة لا تأخذ هذا الإعداد، فأجهزة CCR مثلاً تأخذ إعداد IP Only، وهو عنوان واحد 192.168.88.1/24 على المنفذ الأول، والمستخدم admin بلا كلمة مرور، ولا يوجد جدار ناري إطلاقاً. ونسخة CHR تشبه هذه الحالة، فهي لا تأخذ إعداد Router المنزلي، وهذا ما وجدناه في مختبرنا بعد الإقلاع مباشرة:

[admin@CHR] > /ip service print
Flags: D - DYNAMIC; X - DISABLED, I - INVALID; c - CONNECTION
Columns: NAME, PORT, PROTO, CERTIFICATE, VRF, MAX-SESSIONS, LOCAL
 #     NAME           PORT  PROTO  CERTIFICATE  VRF   MA  LOCAL
 0     ftp              21  tcp                 main  20
 1     ssh              22  tcp                 main  20
 2 D c ssh              22  tcp                           10.0.2.15
 3     telnet           23  tcp                 main  20
 4 D   dhcpclient       68  udp
 5     www              80  tcp                 main  20
 6  X  www-ssl         443  tcp    none         main  20
 7     reverse-proxy   443  tcp    none         main  20
 8 D   btest          2000  tcp
 9 D   discover       5678  udp
10     winbox         8291  tcp                 main  20
11     api            8728  tcp                 main  20
12     api-ssl        8729  tcp    none         main  20

[admin@CHR] > /user print
Flags: E - EXPIRED
Columns: NAME, GROUP, LAST-LOGGED-IN, INACTIVITY-POLICY
#   NAME   GROUP  LAST-LOGGED-IN       INACTIVITY-POLICY
;;; system default user
0 E admin  full   2026-10-07 06:08:14  none

[admin@CHR] > /ip firewall filter print

[admin@CHR] > /tool mac-server print
  allowed-interface-list: all

[admin@CHR] > /tool bandwidth-server print
                  enabled: yes
             authenticate: yes
  allocate-udp-ports-from: 2000
             max-sessions: 100
       allowed-addresses4:
       allowed-addresses6:     

في المخرج أعلاه لاحظ التالي:

• كل خدمات الإدارة تعمل على كل العناوين، بما فيها Telnet وFTP وAPI، والسطر 2 D c ssh هو اتصالنا نحن على عنوان WAN 10.0.2.15.
• المستخدم admin بلا كلمة مرور، والعلم E يعني EXPIRED أي أن كلمة المرور منتهية، ومع ذلك نفذت الأوامر التي أرسلناها عبر SSH دون أن يطلب منا تغييرها.
• جدول الجدار الناري فارغ، والإدارة عبر MAC مسموحة على كل الواجهات all، وسيرفر قياس السرعة Bandwidth Test يعمل على المنفذ 2000.

أي أن هذا الجهاز لو كان على عنوان عام لكان مفتوحاً لأول من يجده، وهذا بالضبط حال كثير من الأجهزة التي تركب بإعداد فارغ ثم تنسى، لذلك فإن القاعدة الأولى: إذا كان جهازك جاء بإعداد افتراضي فيه جدار ناري فلا تحذفه، والتوثيق الرسمي في First Time Configuration يحذر صراحة أن حذف الإعداد الافتراضي يحذف كل قواعد الحماية، وإذا كان بلا إعداد مثل CHR وCCR فإن الخطوات التالية إلزامية قبل أن تصله بالإنترنت.

أول إعداد آمن خطوة خطوة

الخطوات التالية مأخوذة من Securing your router وFirst Time Configuration، وطبقناها بالترتيب على CHR في المختبر، والصورة التالية تلخص الترتيب:

الخطوة صفر: شبكة داخلية وقوائم واجهات

قبل الحماية نحتاج أن نعرف للراوتر أي واجهة هي الإنترنت وأيها الداخل، والطريقة التي يستخدمها الإعداد الافتراضي هي قوائم الواجهات Interface Lists، وهي أسماء مثل WAN وLAN تضع فيها الواجهات، ثم تكتب القواعد على القائمة بدلاً من اسم الواجهة، فإذا أضفت لاحقاً اتصال PPPoE أو VLAN جديداً يكفي أن تضيفه إلى القائمة الصحيحة:

/interface list add name=WAN
/interface list add name=LAN
/interface list member add list=WAN interface=ether1
/interface list member add list=LAN interface=ether2
/ip address add address=192.168.88.1/24 interface=ether2 comment=LAN

والمخرج سوف يكون كما يلي:

[admin@CHR] > /interface list member print
Columns: LIST, INTERFACE
# LIST  INTERFACE
0 WAN   ether1
1 LAN   ether2

[admin@CHR] > /ip address print
Flags: D - DYNAMIC
Columns: ADDRESS, NETWORK, INTERFACE, VRF
#   ADDRESS          NETWORK       INTERFACE  VRF
0 D 10.0.2.15/24     10.0.2.0      ether1     main
;;; LAN
1   192.168.88.1/24  192.168.88.0  ether2     main

في أجهزة البيت تكون الشبكة الداخلية Bridge اسمه bridge فيه عدة منافذ وليس منفذاً واحداً، والقوائم نفسها موجودة باسم WAN وLAN في الإعداد الافتراضي، فلا تحتاج إلى إنشائها.

الخطوة الأولى: حدث RouterOS وRouterBOOT

RouterOS يصدر في قنوات Release Channels: Long-term للتحديثات النادرة التي تحمل الإصلاحات الحرجة فقط، وStable كل بضعة أشهر، وTesting وDevelopment للتجربة ولا تصلح للإنتاج، كما في صفحة Upgrade. والتحقق من التحديث يكون بالأمر التالي:

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

والمخرج سوف يكون كما يلي:

            channel: stable
               mode: https
  check-certificate: yes
         ip-version: auto
  installed-version: 7.24.5
     latest-version: 7.24.5
             status: getting changelog...

وإذا ظهر إصدار أحدث فإن /system package update install ينزله ويعيد تشغيل الجهاز. ثم تأتي خطوة ينساها كثيرون، وهي تحديث برنامج الإقلاع RouterBOOT الموجود في عتاد أجهزة MikroTik، والتوثيق يوصي بشدة بتحديثه بعد كل تحديث للنظام بالأمر /system routerboard upgrade ثم إعادة التشغيل. ولاحظ أن هذا الأمر لا يوجد في CHR لأنه لا يوجد عتاد RouterBOARD، والمخرج في مختبرنا كان كما يلي:

[admin@CHR] > /system routerboard print
bad command name routerboard (line 1 column 9)

وتابع سجل التغييرات قبل كل تحديث، لأن بعض الإصدارات تغير أسماء الخصائص، كما سوف ترى في الخطوة الثالثة.

الخطوة الثانية: مستخدم جديد بمفتاح SSH، ثم عطل admin

اسم admin معروف لكل برنامج يخمن كلمات المرور، لذلك فإن التوثيق يوصي بمستخدم باسم آخر وكلمة مرور لا تقل عن 12 حرفاً، والأفضل أن تدخل بمفتاح SSH. والترتيب هنا مهم: أنشئ المستخدم الجديد وجربه في جلسة ثانية قبل أن تعطل admin، وإلا فقد تغلق الباب على نفسك. فنقلنا المفتاح العام إلى الراوتر عبر scp ثم:

/user add name=netadmin group=full password="(كلمة مرور من 20 حرفاً)" comment="main admin"
/user ssh-keys import public-key-file=netadmin.pub user=netadmin
/user ssh-keys print

والمخرج سوف يكون كما يلي:

Columns: USER, KEY-TYPE, BITS, INFO
#  USER      KEY-TYPE  BITS  INFO
0  netadmin  ed25519    256  lab-mikrotik

ثم دخلنا بالمستخدم الجديد في جلسة جديدة، وعطلنا admin منها:

[netadmin@CHR] > /user disable admin
[netadmin@CHR] > /user print
Flags: E - EXPIRED; X - DISABLED
Columns: NAME, GROUP, LAST-LOGGED-IN, INACTIVITY-POLICY
#    NAME      GROUP  LAST-LOGGED-IN       INACTIVITY-POLICY
;;; system default user
0 EX admin     full   2026-10-07 07:28:04  none
;;; main admin
1    netadmin  full   2026-10-07 07:28:16  none             

وفضلنا التعطيل على الحذف، لأن التعطيل يمكن التراجع عنه، والنتيجة واحدة لمن يحاول الدخول باسم admin.

الخطوة الثالثة: أغلق الخدمات التي لا تستخدمها، واحصر الباقي

عطلنا Telnet وFTP وسيرفر الويب وال API، وتركنا SSH وWinBox فقط، وحصرناهما في الشبكة الداخلية:

/ip service disable telnet,ftp,www,api,api-ssl
/ip service set ssh,winbox available-from=192.168.88.0/24
/ip service print where !dynamic

والمخرج سوف يكون كما يلي:

Flags: X - DISABLED, I - INVALID
Columns: NAME, PORT, PROTO, AVAILABLE-FROM, CERTIFICATE, VRF, MAX-SESSIONS
#   NAME           PORT  PROTO  AVAILABLE-FROM   CERTIFICATE  VRF   MA
0 X ftp              21  tcp                                  main  20
1   ssh              22  tcp    192.168.88.0/24               main  20
2 X telnet           23  tcp                                  main  20
3 X www              80  tcp                                  main  20
4 X www-ssl         443  tcp                     none         main  20
5   reverse-proxy   443  tcp                     none         main  20
6   winbox         8291  tcp    192.168.88.0/24               main  20
7 X api            8728  tcp                                  main  20
8 X api-ssl        8729  tcp                     none         main  20

في المخرج أعلاه لاحظ التالي:

• الخاصية اسمها في الإصدارات الحديثة available-from كما في صفحة Services، وفي الإصدارات الأقدم وفي كثير من الشروحات على الإنترنت ستجدها باسم address، ولذلك راجع سجل التغييرات عند التحديث.
• الخدمة reverse-proxy على المنفذ 443 تستمع فقط عندما توجد قاعدة Reverse Proxy مفعلة حسب التوثيق، فلا تقلق منها إذا لم تستخدمها.

والآن نكسر الإعداد لنفهمه: حاولنا الدخول عبر SSH من جهة WAN، أي من خارج النطاق المسموح، والمخرج سوف يكون كما يلي:

debug1: Connecting to 127.0.0.1 [127.0.0.1] port 21182.
debug1: Connection established.
kex_exchange_identification: Connection closed by remote host
Connection closed by 127.0.0.1 port 21182

لاحظ السطر Connection established: الراوتر قبل الاتصال ثم أغلقه دون أن يخدمه، أي أن المنفذ ما زال يظهر مفتوحاً لأي برنامج يفحص المنافذ Port Scanner، والتوثيق نفسه يقول إن available-from مناسب للتقييد داخل الشبكات الموثوقة، أما منع الإنترنت فمكانه الجدار الناري الذي يسقط الحزمة قبل أن تصل إلى الخدمة، وهو موضوع المقال الثاني.

الخطوة الرابعة: الإدارة عبر MAC واكتشاف الجيران وقياس السرعة

التوثيق يقترح تعطيل MAC-Telnet وMAC-WinBox كلياً في بيئة الإنتاج، ونحن حصرناهما في قائمة LAN كما يفعل الإعداد الافتراضي، لأنهما طريق النجاة عندما تخطئ في العناوين، وعطلنا MAC Ping، ثم حصرنا اكتشاف الجيران في LAN، وأوقفنا سيرفر قياس السرعة:

/tool mac-server set allowed-interface-list=LAN
/tool mac-server mac-winbox set allowed-interface-list=LAN
/tool mac-server ping set enabled=no
/ip neighbor discovery-settings set discover-interface-list=LAN
/tool bandwidth-server set enabled=no

والمخرج سوف يكون كما يلي:

[netadmin@CHR] > /tool mac-server print
  allowed-interface-list: LAN
[netadmin@CHR] > /tool mac-server mac-winbox print
  allowed-interface-list: LAN
[netadmin@CHR] > /tool mac-server ping print
  enabled: no
[netadmin@CHR] > /tool bandwidth-server print
                  enabled: no
             authenticate: yes
  allocate-udp-ports-from: 2000
             max-sessions: 100
       allowed-addresses4:
       allowed-addresses6:     

وإذا كانت شبكتك الداخلية نفسها غير موثوقة، مثل شبكة يتصل بها الضيوف أو أجهزة لا تعرفها، فاجعل القائمة none كما يقترح التوثيق، أو اجعلها قائمة إدارة خاصة فيها منفذ واحد.

الخطوة الخامسة: DNS وSSH والخدمات الإضافية

الراوتر يستطيع أن يكون سيرفر DNS لأجهزة الشبكة، والخاصية allow-remote-requests هي التي تسمح بذلك، وكانت في CHR معطلة no كما رأينا في المخرج الأول. ولا تقم بتفعيلها إلا إذا كانت أجهزتك تستخدم الراوتر للأسماء فعلاً، والسبب أن الراوتر عندها يجيب على المنفذ 53 على كل عناوينه، فإذا لم يمنع الجدار الناري ذلك من جهة الإنترنت أصبح سيرفر DNS مفتوحاً Open Resolver يستخدمه المهاجمون لتضخيم هجمات حجب الخدمة، كما تحذر صفحة DNS. ثم شددنا SSH، فجعلنا الدخول بالمفاتيح فقط وفعلنا الخوارزميات الأقوى:

/ip ssh set strong-crypto=yes password-authentication=no
/ip ssh print

والمخرج سوف يكون كما يلي:

                           ciphers: auto
                forwarding-enabled: no
           password-authentication: no
  publickey-authentication-options: none
                     strong-crypto: yes
                     host-key-size: 2048
                     host-key-type: rsa 

وقبل أن تجعل password-authentication=no تأكد أن مفتاحك يعمل وأن عندك طريقاً آخر مثل WinBox أو MAC-WinBox، لأن هذا الخيار يخص SSH فقط. وتأكدنا أيضاً أن الخدمات التي يذكرها التوثيق كخدمات تفتح أبواباً إضافية معطلة، وهي ال Proxy وSOCKS وUPnP، وفي CHR كانت كلها enabled: no، وفي جهاز منزلي تحقق منها بالأوامر /ip proxy print و/ip socks print و/ip upnp print، وانتبه بالذات إلى SOCKS لأنه ظهر في حادثة Mēris التي سوف نذكرها أدناه.

الخطوة السادسة: الوقت الصحيح عبر NTP

السجلات Logs وجدولة السكربتات وصلاحية الشهادات كلها تعتمد على الوقت، والأجهزة الصغيرة لا تحتفظ بالوقت بعد انقطاع الكهرباء، لذلك فعلنا عميل NTP كما في صفحة NTP:

/system clock set time-zone-name=Asia/Riyadh
/system ntp client set enabled=yes servers=pool.ntp.org
/system ntp client print

والمخرج بعد عشرين ثانية سوف يكون كما يلي:

         enabled: yes
            mode: unicast
         servers: pool.ntp.org
             vrf: main
      freq-drift: 0 PPM
          status: synchronized
   synced-server: pool.ntp.org
  synced-stratum: 1
   system-offset: -0.43 ms    

وضع الأمان Safe Mode قبل أي تغيير خطير

كل من أدار راوتر عن بعد مر بلحظة غير فيها قاعدة فانقطع الاتصال ولم يعد يستطيع الوصول ليصلحها، وهذا ما يحله وضع الأمان Safe Mode في RouterOS: تضغط Ctrl+X في سطر الأوامر أو زر Safe Mode في WinBox، فيظهر <SAFE> بعد اسم الجهاز، وكل تغيير تفعله بعدها يحفظ في سجل، فإذا انقطعت الجلسة بشكل غير طبيعي فإن الراوتر يتراجع عن كل هذه التغييرات تلقائياً، وإذا خرجت ب Ctrl+X مرة أخرى تثبت التغييرات. وتذكر حدوده كما في صفحة Console: السجل يحتفظ بآخر 100 تغيير فقط، فإذا تجاوزتها يخرج الجهاز من الوضع دون تراجع، والتراجع لا يشمل الأوامر التي تحتاج إعادة تشغيل مثل استرجاع نسخة احتياطية، والتراجع بعد انقطاع جلسة TCP قد يأخذ عدة دقائق. وقد حاولنا أن نلتقط مخرجه في المختبر من جلسة SSH آلية فلم ينجح ذلك، لذلك لا نعرض مخرجاً هنا، ونكتفي بما في التوثيق، وجربه أنت في جلسة تفاعلية قبل أن تحتاجه.

الخطوة السابعة: نسخة احتياطية Backup وتصدير Export، وما الفرق؟

RouterOS يقدم طريقتين لحفظ الإعداد، وكل واحدة لها غرض مختلف، والصورة التالية تبين الفرق:

• النسخة الاحتياطية الثنائية Binary Backup: ملف .backup فيه الإعداد كاملاً مع المستخدمين وعناوين MAC، ويسترجع على الجهاز نفسه وبالإصدار نفسه من RouterOS كما في صفحة Backup، وهو حساس جداً، لذلك شفره دائماً بكلمة مرور.
• التصدير Export: ملف نصي .rsc فيه الأوامر التي تعيد بناء الإعداد، ولا يحتوي كلمات مرور المستخدمين ولا مفاتيح SSH ولا الشهادات كما في صفحة Configuration Management، والقيم الحساسة الأخرى مثل المفاتيح الخاصة لا تظهر إلا إذا أضفت show-sensitive. وهو الذي تقرؤه وتقارنه وتنقل أجزاء منه إلى جهاز آخر.

والمثال التالي يحفظ الاثنين:

/system backup save name=before-firewall password=Lab-Backup-Pass-2026
/export file=before-firewall
/file print

والمخرج سوف يكون كما يلي:

Configuration backup saved
Columns: NAME, TYPE, SIZE, LAST-MODIFIED
# NAME                    TYPE       SIZE     LAST-MODIFIED
0 skins                   directory           2026-10-07 09:06:44
1 before-firewall.rsc     script     1152     2026-10-07 10:29:54
2 before-firewall.backup  backup     23.5KiB  2026-10-07 10:29:53

وهذا هو التصدير الكامل لما فعلناه في هذا المقال، وهو ملخص جيد لكل الخطوات:

[netadmin@CHR] > /export
# 2026-10-07 10:29:58 by RouterOS 7.24.5
# system id = VAEw6wxVLvC
#
/interface ethernet
set [ find default-name=ether1 ] disable-running-check=no
set [ find default-name=ether2 ] disable-running-check=no
/interface list
add name=WAN
add name=LAN
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add interface=ether1 list=WAN
add interface=ether2 list=LAN
/ip address
add address=192.168.88.1/24 comment=LAN interface=ether2 network=192.168.88.0
/ip dhcp-client
add interface=ether1 name=client1
/ip service
set ftp disabled=yes
set ssh available-from=192.168.88.0/24
set telnet disabled=yes
set www disabled=yes
set winbox available-from=192.168.88.0/24
set api disabled=yes
set api-ssl disabled=yes
/ip ssh
set password-authentication=no strong-crypto=yes
/system clock
set time-zone-name=Asia/Riyadh
/system ntp client
set enabled=yes
/system ntp client servers
add address=pool.ntp.org
/tool bandwidth-server
set enabled=no
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN
/tool mac-server ping
set enabled=no

في المخرج أعلاه لاحظ التالي:

• المستخدم netadmin ومفتاحه وتعطيل admin لا يظهر منها شيء، وهذا يعني أن من يسترجع هذا الملف على جهاز جديد سوف يجد admin كما كان، لذلك احتفظ بخطوات المستخدمين في ملاحظة منفصلة.
• الملف لا يحتوي إلا ما غيرته عن الإعداد الافتراضي، ولهذا هو قصير ومقروء، وهذا ما يجعله مناسباً لحفظه في Git، وسوف نفعل ذلك في المقال الثالث.
• الملفات تبقى على الراوتر نفسه، فإذا تعطل الجهاز تعطلت معه، لذلك انقلها خارجه بعد كل تغيير مهم.

ثغرة WinBox وشبكة Mēris: لماذا لا يكفي التحديث وحده؟

قد يتساءل البعض: إذا كان التحديث يغلق الثغرات، فلماذا كل هذه الخطوات؟ والإجابة في حادثتين متصلتين تبينان أن التحديث يغلق الباب، ولكنه لا يخرج من دخل قبل إغلاقه:

والدرس من الحادثتين يطابق خطوات هذا المقال: لا تترك WinBox أو أي خدمة إدارة مفتوحة للإنترنت، وغير كلمة المرور بعد كل ثغرة في الدخول حتى لو حدثت، وراجع التصدير /export دورياً بحثاً عن أشياء لم تضعها أنت، مثل سكربتات في /system scheduler أو إعدادات في /ip socks، ولا تثق بالشبكة الداخلية ثقة كاملة، لأن MikroTik ذكرت أن برنامجاً ضاراً كان يحاول إعادة إعداد الراوتر من حاسوب Windows داخل الشبكة نفسها.

الأخطاء الشائعة

• حذف الإعداد الافتراضي ثم نسيان الجدار الناري: يحدث كثيراً مع من يتبع شرحاً يبدأ ب Remove Configuration، فيبقى الجهاز كما رأيته في مخرج CHR، مفتوحاً على كل المنافذ.
• تعطيل admin قبل تجربة المستخدم الجديد: فتغلق الباب على نفسك وتحتاج إلى إعادة ضبط المصنع أو Netinstall، لذلك جرب المستخدم الجديد في جلسة ثانية أولاً.
• الاعتماد على available-from وحده: كما رأيت في المختبر، المنفذ يبقى مفتوحاً ويقبل الاتصال ثم يغلقه، فالجدار الناري هو الحماية من الإنترنت، وavailable-from طبقة إضافية.
• تحديث RouterOS دون RouterBOOT: يعمل الجهاز غالباً، ولكن التوثيق يوصي بتحديث الاثنين معاً، فاجعلها خطوة ثابتة بعد كل تحديث.
• الاحتفاظ بالنسخ الاحتياطية على الراوتر فقط: فإذا تعطلت ذاكرته فقدت الإعداد والنسخة معاً.
• نشر ملف backup دون تشفير: هذا الملف يحتوي كل شيء، فمن يحصل عليه يعرف شبكتك بالكامل.
• نسخ أوامر من شرح قديم: بعض الخصائص تغير اسمها بين الإصدارات مثل address وavailable-from، وشروحات RouterOS 6 كثيرة على الإنترنت، فتأكد من الإصدار في التوثيق الرسمي.

قائمة التحقق قبل أن تصل الجهاز بالإنترنت

1. RouterOS على آخر إصدار في قناة Stable أو Long-term، وRouterBOOT محدث بعده.
2. مستخدم باسم غير admin بكلمة مرور قوية ومفتاح SSH، وadmin معطل.
3. Telnet وFTP وwww وAPI معطلة إن لم تستخدمها، وSSH وWinBox محصوران في عناوين الإدارة.
4. MAC-Telnet وMAC-WinBox واكتشاف الجيران في قائمة LAN أو none، وMAC Ping وBandwidth Test معطلان.
5. allow-remote-requests في DNS معطل إلا إذا احتجته، وإذا احتجته فالجدار الناري يمنع المنفذ 53 من الإنترنت.
6. Proxy وSOCKS وUPnP معطلة إن لم تحتجها.
7. NTP متزامن والمنطقة الزمنية صحيحة.
8. نسخة backup مشفرة وملف export خارج الجهاز.
9. جدار ناري يمنع كل ما يصل إلى الراوتر من WAN، وهو موضوع المقال التالي.

تدريب عملي

1. نزل CHR بصيغة تناسب برنامج المحاكاة عندك، وشغله بواجهتين، ثم اطبع /ip service print و/user print واكتب كل باب مفتوح تجده قبل أن تغير شيئاً.
2. طبق خطوات هذا المقال واحدة واحدة، وبعد كل خطوة نفذ /export، ولاحظ كيف يكبر الملف بالأسطر التي غيرتها فقط.

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

• RouterOS نظام مغلق المصدر ومنتشر جداً، وأجهزته من hAP المنزلي إلى CCR وCHR الافتراضي تعمل بالأوامر نفسها، والبدائل المفتوحة OpenWrt وOPNsense في المرحلة نفسها.
• أجهزة MikroTik تأتي بترخيص مثبت، وCHR المجاني يعمل بكل الميزات بحد إرسال 1 ميغابت لكل واجهة، وقسنا ذلك فعلاً.
• كل أداة إدارة منفذ مفتوح، وMAC-Telnet وMAC-WinBox يتجاوزان جدار IP، فاحصرها كلها في الشبكة الداخلية، واستخدم VPN للوصول من الخارج.
• الإعداد الافتراضي في أجهزة البيت فيه جدار ناري فلا تحذفه، وCHR وCCR يأتيان بلا جدار وبمستخدم admin بلا كلمة مرور.
• الترتيب: تحديث، ثم مستخدم جديد، ثم تعطيل الخدمات وحصرها، ثم MAC والاكتشاف، ثم DNS وSSH وNTP، ثم backup مشفر وexport خارج الجهاز.
• ثغرة WinBox في 2018 وشبكة Mēris في 2021 تعلمانك أن التحديث يغلق الثغرة ولا يلغي كلمة مرور سرقت قبله.

وفي المقال التالي بإذن الله سوف نكتب الجدار الناري الذي ينقص هذا الجهاز، ونفهم كل قاعدة فيه، ونرى عداداته تتحرك مع حركة حقيقية.

دليلجدار الحماية Firewall في MikroTik RouterOS بالتفصيلكيف تمر الحزمة داخل جدار الحماية في RouterOS، وكيف تكتب قواعد مرتبة تحمي الراوتر والشبكة خلفه دون أن تفقد الوصول إليه.دليلMikroTik في الواقع: سيناريوهات عملية للبيت والمكتبكيف تبني على RouterOS ما تحتاجه فعلاً في البيت والمكتب، من شبكة ضيوف معزولة إلى الوصول الآمن من الخارج عبر WireGuard.دليلأجهزة الشبكة في البيت والمكتب: ماذا يفعل كل جهاز؟نأخذ كل جهاز في شبكة البيت والمكتب على حدة، من المودم إلى ال Router وال Switch، ونعرف ماذا يفعل ولماذا تحتاجه.دليلBridge Mode: متى تجعل راوتر المزود مجرد مودملماذا يفشل توجيه المنافذ عندما تضع Router خاصاً بك خلف جهاز المزود، وكيف يحل وضع الجسر مشكلة ال Double NAT.دليلما هو NAT؟ شرح ترجمة العناوين وتوجيه المنافذلماذا تخرج كل أجهزة بيتك بعنوان عام واحد، وكيف يترجم ال Router العناوين، ولماذا يفشل توجيه المنافذ خلف CGNAT.دليلما هو VPN؟ الشبكة الخاصة الافتراضية من المشكلة إلى الأنواعلماذا تحتاج شبكة خاصة افتراضية VPN، وكيف تغلف حزمك وتشفرها داخل نفق، وأي نوع منها يناسب فريقك.

سجل التحديثات

• أكتوبر 2026: كتابة المقال على RouterOS 7.24.5 (stable)، مع مخرجات حقيقية من CHR يعمل في QEMU داخل Docker على Windows 11.