技能 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 加速及連接埠 9180 REST API 啟動 CHR

預期結果:

QEMU 以硬體加速啟動。RouterOS 約 5 秒內完成啟動。來自 http://127.0.0.1:9180/ 的 HTTP 200 回應確認就緒狀態。REST API 可透過 http://127.0.0.1:9180/rest/ 以管理員憑證存取。

正在使用「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
規範符合性

你能建構什麼

CI 中的自動化 RouterOS REST API 測試

將 RouterOS CHR 作為 CI 測試環境執行,以驗證 REST API 呼叫、產生 RAML 結構描述,以及測試 /app YAML 配置,無需手動設定路由器。

開發與學習環境

啟動免費授權的 CHR 執行個體,以探索 RouterOS 功能、測試防火牆規則、實驗橋接技術,並在無需實體設備的情況下學習網路概念。

多架構測試

使用 QEMU 搭配適當的韌體(x86 使用 SeaBIOS、ARM 使用 UEFI)及加速選項,在 x86_64 與 aarch64 兩種架構上測試 RouterOS 配置。

試試這些提示

基本 CHR 設定
協助我在 QEMU 中設定 RouterOS CHR。我需要下載最新穩定版映像檔,並以 KVM 加速及連接埠 9180 啟動 REST API。
GitHub Actions CI 整合
撰寫一個 GitHub Actions 工作流程,下載 RouterOS CHR 並啟動(若有 KVM 則使用 KVM,否則回退至 TCG),等待啟動完成後執行 REST API 測試。
ARM64 UEFI 啟動配置
在 macOS Apple Silicon 上配置 QEMU 以啟動 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 廠商字串,因此服務程序永遠不會啟動。請使用 Linux 搭配 KVM 進行 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 上針對 aarch64 客戶端使用 HVF。在所有平台上,當硬體加速不可用時,請使用 TCG 作為回退方案。

開發者詳情