技能 routeros-qemu-chr
📦

routeros-qemu-chr

低风险 ⚙️ 外部命令🌐 网络访问📁 文件系统访问

在 QEMU 中运行 MikroTik RouterOS CHR

MikroTik RouterOS CHR 提供功能完整的虚拟路由器用于测试和开发,但设置过程需要处理 QEMU 选项、VirtIO 驱动和固件配置。本技能提供完整的指导,帮助用户使用加速功能运行 CHR、正确配置 VirtIO 并集成 REST API。

支持: Claude Codex Code(CC)
⚠️ 63
1

下载技能 ZIP

2

在 Claude 中上传

前往 设置 → 功能 → 技能 → 上传技能

3

开启并开始使用

测试它

正在使用“routeros-qemu-chr”。 使用 KVM 加速启动 CHR 并在端口 9180 上启用 REST API

预期结果:

QEMU 以硬件加速启动。RouterOS 约 5 秒内完成启动。来自 http://127.0.0.1:9180/ 的 HTTP 200 响应确认就绪。REST API 可通过 http://127.0.0.1:9180/rest/ 使用 admin 凭据访问。

正在使用“routeros-qemu-chr”。 在 GitHub Actions Ubuntu 运行器上启用 KVM

预期结果:

已在 /etc/udev/rules.d/99-kvm4all.rules 创建 udev 规则。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.
审计者: claude 查看审计历史 →

质量评分

45
架构
100
可维护性
87
内容
32
社区
40
安全
100
规范符合性

你能构建什么

自动化 RouterOS REST API CI 测试

将 RouterOS CHR 作为 CI 测试夹具运行,用于验证 REST API 调用、生成 RAML 模式以及测试 /app YAML 配置,无需手动设置路由器。

开发与学习环境

启动免费许可的 CHR 实例来探索 RouterOS 功能、测试防火墙规则、实验桥接配置,并学习网络知识,无需生产环境硬件。

多架构测试

使用 QEMU 在 x86_64 和 aarch64 两种架构上测试 RouterOS 配置,支持合适的固件(x86 使用 SeaBIOS,ARM 使用 UEFI)和加速选项。

试试这些提示

基础 CHR 设置
帮我设置 QEMU 中的 RouterOS CHR。我需要下载最新稳定版镜像并使用 KVM 加速启动,同时为 REST API 配置端口 9180。
GitHub Actions CI 集成
编写一个 GitHub Actions 工作流,下载 RouterOS CHR,优先使用 KVM 启动(回退到 TCG),等待启动完成后运行 REST API 测试。
ARM64 UEFI 启动配置
配置 QEMU 在 macOS Apple Silicon 上启动 RouterOS CHR aarch64。包含 UEFI pflash 设置和显式的 virtio-blk-pci 设备配置。
调试启动失败
RouterOS CHR 启动失败,屏幕空白。磁盘镜像在 aarch64 上使用了 if=virtio。可能是什么问题,我该如何修复?

最佳实践

  • 在 aarch64 上使用显式的 -device virtio-blk-pci 而非 if=virtio 简写形式,以避免导致静默启动失败的 MMIO trap
  • 启用 KVM 前检查 /dev/kvm 的可写性(而非仅检查是否存在),在 KVM 不可用时始终优雅回退到 TCG
  • 使用 tcp::9180-:80 等端口转发模式而非硬编码 localhost IP,使配置更具可移植性和可复用性

避免

  • 不要在 aarch64 架构上使用 if=virtio —— 这会解析为 MMIO,而 RouterOS 不支持,导致静默启动失败
  • 不要跳过 KVM 权限检查 —— /dev/kvm 可能存在但不可读,且 QEMU 在权限错误时不会静默回退到 TCG
  • 不要在并发 CI 构建中使用 git pull && git push —— 使用 retry-with-rebase 模式以避免竞态条件导致的推送拒绝

常见问题

免费 CHR 许可的速度限制是多少?
免费 CHR 许可将接口吞吐量限制为 1 Mbps。REST API 调用、SSH、WinBox 和 WebFig 访问不受影响。此限制仅适用于接口之间的实际数据转发。
为什么 QEMU Guest Agent 在 HVF 加速下无法工作?
RouterOS QGA 守护进程仅在通过 CPUID 检测到 KVM 管理程序时才会启动。在 HVF(macOS)或 TCG(软件模拟)下,CPUID 0x40000000 不返回 KVM 厂商标识,因此守护进程永远不会启动。请使用带 KVM 的 Linux 进行 QGA 测试。
如何在 SeaBIOS 和 UEFI 之间选择用于 CHR 启动?
x86_64 使用 SeaBIOS(默认,启动最快)。aarch64 ARM 架构使用 UEFI。在 x86_64 上,只有 SeaBIOS 能启动专有的启动分区;OVMF 无法读取它。
为什么我的 aarch64 CHR 使用 if=virtio 时卡在启动阶段?
在 aarch64 virt 机器上,if=virtio 会解析为 MMIO 传输。RouterOS 有 virtio_pci 驱动但没有 virtio_mmio 驱动,因此内核会静默卡住。在 aarch64 上请始终使用显式的 -device virtio-blk-pci。
我可以同时运行多个 CHR 实例吗?
可以。为每个实例使用独立的主机端口(如 9180、9181、9182 用于 REST API 等)。每个实例需要自己的磁盘镜像和 PID 跟踪以便清理。
我应该使用哪种加速方式?
当主机/客户机架构匹配时,在 Linux 上使用 KVM。在 macOS Apple Silicon 上使用 HVF 运行 aarch64 客户机。在所有平台上,当硬件加速不可用时使用 TCG 作为回退方案。

开发者详情