routeros-qemu-chr
QEMUでMikroTik RouterOS CHRを実行する
MikroTik RouterOS CHRはテストおよび開発用のフル機能仮想ルーターを提供しますが、セットアップにはQEMUオプション、VirtIOドライバー、ファイムウェア構成のナビゲーションが必要です。このスキルは、アクセラレーション、適切なVirtIO設定、REST API統合を備えたCHRの実行に関する完全なガイダンスを提供します。
スキルZIPをダウンロード
Claudeでアップロード
設定 → 機能 → スキル → スキルをアップロードへ移動
オンにして利用開始
テストする
「routeros-qemu-chr」を使用しています。 KVMアクセラレーションとREST APIをポート9180で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有効化
期待される結果:
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)
品質スコア
作れるもの
CIでの自動化されたRouterOS REST APIテスト
RouterOS CHRをCIテストフィクスチャとして実行し、手動のルーター設定なしでREST API呼び出しを検証し、RAMLスキーマを生成し、/app YAML設定をテストします。
開発と学習環境
フリーライセンスのCHRインスタンスを起動してRouterOS機能を探索し、ファイアウォールルールをテストし、ブリッジングを試み、プロダクションハードウェアなしでネットワークコンセプトを学習します。
マルチアーキテクチャテスト
適切なファイムウェア（x86用SeaBIOS、ARM用UEFI）とアクセラレーションオプションを使用して、x86_64とaarch64の両方でRouterOS設定をテストします。
これらのプロンプトを試す
QEMUでRouterOS CHRのセットアップを手伝ってください。最新の安定版イメージをダウンロードし、KVMアクセラレーションとREST API用ポート9180で起動する必要があります。
RouterOS CHRをダウンロードし、KVMが利用可能な場合は使用（TCGにフォールバック）し、ブートを待ち、REST APIテストを実行するGitHub Actionsワークフローを作成してください。
macOS Apple SiliconでRouterOS CHR aarch64をブートするようにQEMUを構成してください。UEFI pflash設定と明示的なvirtio-blk-pciデバイス構成を含めてください。
RouterOS CHRがブートせず、画面が真っ白になります。ディスクイメージはaarch64でif=virtioを使用していますが、何が問題でどのように修正すればよいですか？
ベストプラクティス
- aarch64でサイレントブート失敗を引き起こすMMIOトラップを回避するために、if=virtio省略形ではなく明示的な -device virtio-blk-pci を使用する
- KVM有効化前に /dev/kvm の書き込み可能性を確認（存在確認だけでなく）し、KVMが利用できない場合は常にTCGに優雅にフォールバックする
- 設定をポータブルかつ再利用可能にするために、localhostのIPをハードコードする代わりに tcp::9180-:80 のようなポートフォワーディングパターンを使用する
回避
- aarch64アーキテクチャでif=virtioを使用しない - これはRouterOSがサポートしていないMMIOに解決し、サイレントブート失敗を引き起こす
- KVM権限チェックをスキップしない - /dev/kvmは存在するが読み取り不可の場合があり、QEMUは権限エラー時にTCGにサイレントにフォールバックしない
- 並行CIビルドでgit pull && git pushを使用しない - レース条件からのプッシュ拒否を避けるためにretry-with-rebaseパターンを使用する