routeros-qemu-chr
Exécuter MikroTik RouterOS CHR dans QEMU
MikroTik RouterOS CHR offre un routeur virtuel complet pour les tests et le développement, mais sa configuration nécessite de naviguer parmi les options QEMU, les pilotes VirtIO et les configurations de firmware. Ce skill fournit des instructions complètes pour exécuter CHR avec l'accélération matérielle, la configuration appropriée de VirtIO et l'intégration de l'API REST.
Télécharger le ZIP du skill
Importer dans Claude
Allez dans Paramètres → Capacités → Skills → Importer un skill
Activez et commencez à utiliser
Tester
Utilisation de "routeros-qemu-chr". Démarrer CHR avec l'accélération KVM et l'API REST sur le port 9180
Résultat attendu:
QEMU se lance avec l'accélération matérielle. RouterOS démarre en ~5 secondes. Une réponse HTTP 200 de http://127.0.0.1:9180/ confirme la disponibilité. L'API REST est accessible à http://127.0.0.1:9180/rest/ avec les identifiants admin.
Utilisation de "routeros-qemu-chr". Activer KVM sur le runner Ubuntu GitHub Actions
Résultat attendu:
Règle udev créée dans /etc/udev/rules.d/99-kvm4all.rules. Permissions du périphérique KVM mises à jour à 0666. QEMU ouvre avec succès /dev/kvm pour l'accélération matérielle. Le temps de démarrage est réduit de ~30s à ~5s.
Utilisation de "routeros-qemu-chr". Configurer la redirection de ports pour les services RouterOS
Résultat attendu:
Ports hôte mappés : 9180→80 (API REST), 9122→22 (SSH), 9728→8728 (API), 9729→8729 (API-SSL), 9291→8291 (WinBox). Services accessibles depuis l'hôte via les ports localhost.
Audit de sécurité
Risque faibleDocumentation 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.
Problèmes à risque élevé (4)
Problèmes à risque moyen (3)
Problèmes à risque faible (2)
Facteurs de risque
⚙️ Commandes externes (3)
🌐 Accès réseau (2)
📁 Accès au système de fichiers (2)
Score de qualité
Ce que vous pouvez construire
Tests automatisés de l'API REST RouterOS en CI
Exécutez RouterOS CHR comme environnement de test CI pour valider les appels à l'API REST, générer des schémas RAML et tester les configurations /app YAML sans configuration manuelle du routeur.
Environnement de développement et d'apprentissage
Démarrez une instance CHR avec une licence gratuite pour explorer les fonctionnalités de RouterOS, tester les règles de pare-feu, expérimenter le bridging et apprendre les concepts réseau sans matériel de production.
Tests multi-architecture
Testez les configurations RouterOS sur les architectures x86_64 et aarch64 en utilisant QEMU avec les firmwares appropriés (SeaBIOS pour x86, UEFI pour ARM) et les options d'accélération.
Essayez ces prompts
Aidez-moi à configurer RouterOS CHR dans QEMU. Je dois télécharger la dernière image stable et la démarrer avec l'accélération KVM et le port 9180 pour l'API REST.
Écrivez un workflow GitHub Actions qui télécharge RouterOS CHR, le démarre avec KVM si disponible (repli sur TCG), attend le démarrage, puis exécute les tests de l'API REST.
Configurez QEMU pour démarrer RouterOS CHR aarch64 sur macOS Apple Silicon. Incluez la configuration UEFI pflash et la configuration explicite du périphérique virtio-blk-pci.
RouterOS CHR ne parvient pas à démarrer avec un écran noir. L'image disque utilise if=virtio sur aarch64. Quel pourrait être le problème et comment le résoudre ?
Bonnes pratiques
- Utilisez -device virtio-blk-pci explicite au lieu de la forme abrégée if=virtio sur aarch64 pour éviter le piège MMIO qui provoque des échecs de démarrage silencieux
- Vérifiez les permissions en écriture de /dev/kvm (et pas seulement son existence) avant d'activer KVM, et effectuez toujours un repli gracieux vers TCG si KVM n'est pas disponible
- Utilisez des modèles de redirection de ports comme tcp::9180-:80 au lieu de coder en dur les adresses IP localhost pour rendre la configuration portable et réutilisable
Éviter
- N'utilisez pas if=virtio sur l'architecture aarch64 - cela se résout en MMIO que RouterOS ne prend pas en charge, provoquant des échecs de démarrage silencieux
- Ne skippez pas la vérification des permissions KVM - /dev/kvm peut exister mais être illisible, et QEMU ne revient pas silencieusement à TCG en cas d'erreur de permission
- N'utilisez pas git pull && git push dans les builds CI concurrents - utilisez le modèle retry-with-rebase pour éviter les rejets de push dus aux conditions de concurrence