المهارات routeros-qemu-chr
📦

routeros-qemu-chr

مخاطر منخفضة ⚙️ الأوامر الخارجية🌐 الوصول إلى الشبكة📁 الوصول إلى نظام الملفات

تشغيل MikroTik RouterOS CHR في QEMU

يوفر MikroTik RouterOS CHR جهاز توجيه افتراضي كامل الميزات للاختبار والتطوير، لكن الإعداد يتطلب التعامل مع خيارات QEMU ومشغلات VirtIO وإعدادات البرامج الثابتة. توفر هذه المهارة إرشادات كاملة لتشغيل CHR مع التسريع وإعداد VirtIO المناسب والتكامل مع REST API.

يدعم: Claude Codex Code(CC)
⚠️ 63 ضعيف
1

تنزيل ZIP المهارة

2

رفع في Claude

اذهب إلى Settings → Capabilities → Skills → Upload skill

3

فعّل وابدأ الاستخدام

اختبرها

استخدام "routeros-qemu-chr". تشغيل CHR مع تسريع KVM و REST API على المنفذ 9180

النتيجة المتوقعة:

يقلع QEMU مع تسريع الأجهزة. يقلع RouterOS في ~5 ثوانٍ. استجابة HTTP 200 من http://127.0.0.1:9180/ تؤكد الجاهزية. REST API متاح على http://127.0.0.1:9180/rest/ ببيانات المسؤول.

استخدام "routeros-qemu-chr". تمكين KVM على مشغل Ubuntu في GitHub Actions

النتيجة المتوقعة:

تم إنشاء قاعدة udev في /etc/udev/rules.d/99-kvm4all.rules. تم تحديث أذونات جهاز KVM إلى 0666. QEMU يفتح /dev/kvm بنجاح لتسريع الأجهزة. تم تقليل وقت الإقلاع من ~30 ثانية إلى ~5 ثوانٍ.

استخدام "routeros-qemu-chr". تكوين إعادة توجيه المنافذ لخدمات RouterOS

النتيجة المتوقعة:

المنافذ المعينة على المضيف: 9180→80 (REST API) و 9122→22 (SSH) و 9728→8728 (API) و 9729→8729 (API-SSL) و 9291→8291 (WinBox). الخدمات متاحة من المضيف عبر منافذ localhost.

التدقيق الأمني

مخاطر منخفضة
v2 • 4/16/2026

Documentation and reference skill for running RouterOS CHR in QEMU. Static analysis flagged 343 patterns, but evaluation reveals these are false positives: shell backtick notation in markdown code examples (not execution), sudo in GitHub Actions CI (expected), MD5 references in kernel history docs (not actual usage), and legitimate acceleration detection commands. All network access targets MikroTik infrastructure for downloading CHR images. Risk level set to LOW due to external command patterns in documentation examples, but no actual malicious code present.

5
الملفات التي تم فحصها
794
الأسطر التي تم تحليلها
12
النتائج
2
إجمالي عمليات التدقيق

مشكلات عالية المخاطر (4)

Documentation Shell Examples Misidentified as Execution
Static scanner flagged 264 instances of Ruby/shell backtick notation. These are markdown code blocks showing shell command syntax, not actual command execution. Files are documentation with command examples.
sudo Commands in GitHub Actions CI (Expected Behavior)
GitHub Actions workflow uses sudo for package installation (apt-get install). This is standard CI/CD practice, not privilege escalation risk.
nohup for Background QEMU Process (Legitimate Use)
nohup is used to run QEMU in background during CI testing. This is standard practice for running VMs in CI environments.
Base64 HTTP Basic Auth (Standard Practice)
Static scanner flagged btoa('admin:') as weak crypto. This is standard HTTP Basic Auth encoding, not cryptographic weakness.
مشكلات متوسطة المخاطر (3)
Network Access to External URLs
Skill downloads CHR images from MikroTik infrastructure. URLs point to download.mikrotik.com and cdn.mikrotik.com for official RouterOS images.
Device File Access for Virtualization
/dev/kvm access for KVM acceleration detection. This is standard practice for virtualization tooling.
Temp Directory Access
/tmp used for QEMU vars files, serial sockets, and log files. Standard temp file usage for VM management.
مشكلات منخفضة المخاطر (2)
Hardcoded IP Addresses (Localhost)
127.0.0.1 used for RouterOS REST API and port forwarding. Standard localhost addressing.
System Information Commands (Acceleration Detection)
uname, sysctl, and stat commands used for platform detection. Standard virtualization tooling practice.

عوامل الخطر

⚙️ الأوامر الخارجية (3)
🌐 الوصول إلى الشبكة (2)
📁 الوصول إلى نظام الملفات (2)
تم تدقيقه بواسطة: claude عرض سجل التدقيق →

درجة الجودة

45
الهندسة المعمارية
100
قابلية الصيانة
87
المحتوى
32
المجتمع
40
الأمان
100
الامتثال للمواصفات

ماذا يمكنك بناءه

اختبار REST API لـ RouterOS تلقائياً في CI

تشغيل RouterOS CHR كبيئة اختبار في CI للتحقق من استدعاءات REST API وإنشاء مخططات RAML واختبار تكوينات /app YAML دون إعداد يدوي للجهاز.

بيئة التطوير والتعلم

تشغيل نسخة CHR بترخيص مجاني لاستكشاف ميزات RouterOS واختبار قواعد الجدار الناري وتجربة الربط بين الشبكات وتعلم مفاهيم الشبكات دون أجهزة إنتاج.

الاختبار متعدد المعماريات

اختبار تكوينات RouterOS عبر معماريتي x86_64 و aarch64 باستخدام QEMU مع البرامج الثابتة المناسبة (SeaBIOS لـ x86 و UEFI لـ ARM) وخيارات التسريع.

جرّب هذه الموجهات

إعداد CHR الأساسي
ساعدني في إعداد RouterOS CHR في QEMU. أحتاج إلى تنزيل أحدث صورة مستقرة وتشغيلها مع تسريع KVM والمنفذ 9180 لـ REST API.
التكامل مع GitHub Actions CI
اكتب سير عمل GitHub Actions يقوم بتنزيل RouterOS CHR وتشغيله مع KVM إذا كان متاحاً (مع الرجوع إلى TCG) والانتظار حتى يكتمل الإقلاع ثم تشغيل اختبارات REST API.
تكوين الإقلاع عبر UEFI على ARM64
قم بتكوين QEMU لإقلاع RouterOS CHR على aarch64 في macOS Apple Silicon. قم بتضمين إعداد UEFI pflash وتكوين جهاز virtio-blk-pci الصريح.
تصحيح أخطاء الإقلاع
يفشل RouterOS CHR في الإقلاع مع شاشة فارغة. صورة القرص تستخدم if=virtio على aarch64. ما المشكلة المحتملة وكيف أصلحها؟

أفضل الممارسات

  • استخدم -device virtio-blk-pci الصريح بدلاً من if=virtio المختصر على aarch64 لتجنب خطأ MMIO الذي يسبب فشل إقلاع صامت
  • تحقق من قابلية الكتابة لـ /dev/kvm (وليس وجوده فقط) قبل تمكين KVM، وتأكد دائماً من الرجوع إلى TCG بسلاسة في حال عدم توفر KVM
  • استخدم أنماط إعادة توجيه المنافذ مثل tcp::9180-:80 بدلاً من ترميز عناوين localhost مباشرة لجعل التكوين قابلاً للنقل وإعادة الاستخدام

تجنب

  • لا تستخدم if=virtio على معمارية aarch64 - فهذا يتحول إلى MMIO الذي لا يدعمه RouterOS، مما يسبب فشل إقلاع صامت
  • لا تتجاوز فحص أذونات KVM - قد يوجد /dev/kvm لكنه غير قابل للقراءة، و QEMU لا يعود تلقائياً إلى TCG عند أخطاء الأذونات
  • لا تستخدم git pull && git push في بناء CI المتزامن - استخدم نمط retry-with-rebase لتجنب رفض الدفع بسبب ظروف السباق

الأسئلة المتكررة

ما هو حد السرعة في ترخيص CHR المجاني؟
يحد ترخيص CHR المجاني من إنتاجية الواجهة إلى 1 Mbps. استدعاءات REST API و SSH و WinBox و WebFig لا تتأثر. هذا الحد ينطبق فقط على إعادة توجيه البيانات الفعلية بين الواجهات.
لماذا لا يعمل QEMU Guest Agent مع تسريع HVF؟
لا يبدأ برنامج RouterOS QGA الخلفي إلا عندما يكتشف جهاز KVM الافتراضي عبر CPUID. تحت HVF (macOS) أو TCG (المحاكاة البرمجية)، لا يُرجع CPUID 0x40000000 سلسلة بائع KVM، لذا لا يبدأ البرنامج الخلفي أبداً. استخدم Linux مع KVM لاختبار QGA.
كيف أختار بين SeaBIOS و UEFI لإقلاع CHR؟
استخدم SeaBIOS لـ x86_64 (الإعداد الافتراضي، أسرع إقلاع). استخدم UEFI لمعمارية aarch64 ARM. على x86_64، فقط SeaBIOS يمكنه إقلاع قسم الإقلاع الاحتكاري؛ OVMF لا يمكنه قراءته.
لماذا توقف CHR على aarch64 عند الإقلاع مع if=virtio؟
على الآلة الافتراضية aarch64، يتحول if=virtio إلى نقل MMIO. يحتوي RouterOS على مشغل virtio_pci لكن ليس virtio_mmio، لذا تتوقف النواة بصمت. استخدم دائماً -device virtio-blk-pci الصريح على aarch64.
هل يمكنني تشغيل عدة نسخ من CHR في نفس الوقت؟
نعم. استخدم منافذ مضيف فريدة لكل نسخة (9180 و 9181 و 9182 لـ REST API، إلخ). كل نسخة تحتاج إلى صورة قرص خاصة وتتبع PID الخاص بها للتنظيف.
ما طريقة التسريع التي يجب أن أستخدمها؟
استخدم KVM على Linux عندما تتطابق معماريات المضيف والضيف. استخدم HVF على macOS Apple Silicon لنسخ aarch64. استخدم TCG كبديل على جميع المنصات عندما يكون تسريع الأجهزة غير متاح.

تفاصيل المطور

المؤلف

tikoci

الترخيص

MIT

مرجع

main

بنية الملفات