routeros-qemu-chr
تشغيل MikroTik RouterOS CHR في QEMU
يوفر MikroTik RouterOS CHR جهاز توجيه افتراضي كامل الميزات للاختبار والتطوير، لكن الإعداد يتطلب التعامل مع خيارات QEMU ومشغلات VirtIO وإعدادات البرامج الثابتة. توفر هذه المهارة إرشادات كاملة لتشغيل CHR مع التسريع وإعداد VirtIO المناسب والتكامل مع REST API.
تنزيل ZIP المهارة
رفع في Claude
اذهب إلى Settings → Capabilities → Skills → Upload skill
فعّل وابدأ الاستخدام
اختبرها
استخدام "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.
التدقيق الأمني
مخاطر منخفضة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.
مشكلات عالية المخاطر (4)
مشكلات متوسطة المخاطر (3)
مشكلات منخفضة المخاطر (2)
عوامل الخطر
⚙️ الأوامر الخارجية (3)
🌐 الوصول إلى الشبكة (2)
📁 الوصول إلى نظام الملفات (2)
درجة الجودة
ماذا يمكنك بناءه
اختبار REST API لـ RouterOS تلقائياً في CI
تشغيل RouterOS CHR كبيئة اختبار في CI للتحقق من استدعاءات REST API وإنشاء مخططات RAML واختبار تكوينات /app YAML دون إعداد يدوي للجهاز.
بيئة التطوير والتعلم
تشغيل نسخة CHR بترخيص مجاني لاستكشاف ميزات RouterOS واختبار قواعد الجدار الناري وتجربة الربط بين الشبكات وتعلم مفاهيم الشبكات دون أجهزة إنتاج.
الاختبار متعدد المعماريات
اختبار تكوينات RouterOS عبر معماريتي x86_64 و aarch64 باستخدام QEMU مع البرامج الثابتة المناسبة (SeaBIOS لـ x86 و UEFI لـ ARM) وخيارات التسريع.
جرّب هذه الموجهات
ساعدني في إعداد RouterOS CHR في QEMU. أحتاج إلى تنزيل أحدث صورة مستقرة وتشغيلها مع تسريع KVM والمنفذ 9180 لـ REST API.
اكتب سير عمل GitHub Actions يقوم بتنزيل RouterOS CHR وتشغيله مع KVM إذا كان متاحاً (مع الرجوع إلى TCG) والانتظار حتى يكتمل الإقلاع ثم تشغيل اختبارات REST API.
قم بتكوين 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 لتجنب رفض الدفع بسبب ظروف السباق