Habilidades routeros-qemu-chr
📦

routeros-qemu-chr

Baixo Risco ⚙️ Comandos externos🌐 Acesso à rede📁 Acesso ao sistema de arquivos

Executar o MikroTik RouterOS CHR no QEMU

O MikroTik RouterOS CHR oferece um roteador virtual completo para testes e desenvolvimento, mas a configuração exige navegar por opções do QEMU, drivers VirtIO e configurações de firmware. Esta habilidade fornece orientação completa para executar o CHR com aceleração, configuração adequada do VirtIO e integração com a API REST.

Suporta: Claude Codex Code(CC)
⚠️ 63 Ruim
1

Baixar o ZIP da skill

2

Upload no Claude

Vá em Configurações → Capacidades → Skills → Upload skill

3

Ative e comece a usar

Testar

A utilizar "routeros-qemu-chr". Inicializar o CHR com aceleração KVM e API REST na porta 9180

Resultado esperado:

O QEMU inicia com aceleração de hardware. O RouterOS inicializa em ~5 segundos. Resposta HTTP 200 de http://127.0.0.1:9180/ confirma que está pronto. API REST acessível em http://127.0.0.1:9180/rest/ com credenciais de administrador.

A utilizar "routeros-qemu-chr". Habilitar KVM no runner Ubuntu do GitHub Actions

Resultado esperado:

Regra udev criada em /etc/udev/rules.d/99-kvm4all.rules. Permissões do dispositivo KVM atualizadas para 0666. QEMU abre com sucesso /dev/kvm para aceleração de hardware. Tempo de inicialização reduzido de ~30s para ~5s.

A utilizar "routeros-qemu-chr". Configurar encaminhamento de portas para serviços RouterOS

Resultado esperado:

Portas do hospedeiro mapeadas: 9180→80 (API REST), 9122→22 (SSH), 9728→8728 (API), 9729→8729 (API-SSL), 9291→8291 (WinBox). Serviços acessíveis do hospedeiro via portas localhost.

Auditoria de Segurança

Baixo Risco
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
Arquivos analisados
794
Linhas analisadas
12
achados
2
Total de auditorias

Problemas de Alto Risco (4)

SKILL.md:16-316references/chr-licensing.md:25-71references/github-actions-ci.md:7-254references/known-issues.md:5-81references/virtio-drivers.md:9-53
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.
references/github-actions-ci.md:34-48
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.
references/github-actions-ci.md:103references/known-issues.md:55-62
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.
SKILL.md:271
Base64 HTTP Basic Auth (Standard Practice)
Static scanner flagged btoa('admin:') as weak crypto. This is standard HTTP Basic Auth encoding, not cryptographic weakness.
Problemas de Risco Médio (3)
SKILL.md:32-38references/github-actions-ci.md:71-72references/chr-licensing.md:36
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.
references/github-actions-ci.md:11SKILL.md:69
Device File Access for Virtualization
/dev/kvm access for KVM acceleration detection. This is standard practice for virtualization tooling.
references/github-actions-ci.md:110-238SKILL.md:104-148
Temp Directory Access
/tmp used for QEMU vars files, serial sockets, and log files. Standard temp file usage for VM management.
Problemas de Baixo Risco (2)
SKILL.md:110-270references/github-actions-ci.md:130-232
Hardcoded IP Addresses (Localhost)
127.0.0.1 used for RouterOS REST API and port forwarding. Standard localhost addressing.
SKILL.md:24-45references/known-issues.md:35
System Information Commands (Acceleration Detection)
uname, sysctl, and stat commands used for platform detection. Standard virtualization tooling practice.

Fatores de risco

⚙️ Comandos externos (3)
SKILL.md:66-83 references/github-actions-ci.md:34-48 references/github-actions-ci.md:103
🌐 Acesso à rede (2)
SKILL.md:32-38 references/github-actions-ci.md:71-72
📁 Acesso ao sistema de arquivos (2)
SKILL.md:69 references/github-actions-ci.md:11
Auditado por: claude Ver Histórico de Auditoria →

Pontuação de qualidade

45
Arquitetura
100
Manutenibilidade
87
Conteúdo
32
Comunidade
40
Segurança
100
Conformidade com especificações

O Que Você Pode Construir

Teste Automatizado da API REST RouterOS em CI

Execute o RouterOS CHR como um fixture de teste de CI para validar chamadas da API REST, gerar esquemas RAML e testar configurações /app YAML sem configuração manual do roteador.

Ambiente de Desenvolvimento e Aprendizado

Inicialize uma instância CHR com licença gratuita para explorar recursos do RouterOS, testar regras de firewall, experimentar com bridging e aprender conceitos de rede sem hardware de produção.

Teste Multi-Arquitetura

Teste configurações do RouterOS nas arquiteturas x86_64 e aarch64 usando QEMU com firmware apropriado (SeaBIOS para x86, UEFI para ARM) e opções de aceleração.

Tente Estes Prompts

Configuração Básica do CHR 
Ajude-me a configurar o RouterOS CHR no QEMU. Preciso baixar a imagem estável mais recente e inicializá-la com aceleração KVM e porta 9180 para a API REST.
Integração com GitHub Actions CI 
Escreva um fluxo de trabalho do GitHub Actions que baixa o RouterOS CHR, inicializa com KVM se disponível (com fallback para TCG), aguarda a inicialização e executa testes da API REST.
Configuração de Inicialização UEFI ARM64 
Configure o QEMU para inicializar o RouterOS CHR aarch64 no macOS Apple Silicon. Inclua a configuração UEFI pflash e a configuração explícita do dispositivo virtio-blk-pci.
Depuração de Falhas de Inicialização 
O RouterOS CHR falha ao inicializar com uma tela em branco. A imagem de disco usa if=virtio no aarch64. O que pode estar errado e como corrigir?

Melhores Práticas

  • Use -device virtio-blk-pci explícito em vez da forma abreviada if=virtio no aarch64 para evitar a armadilha MMIO que causa falhas silenciosas de inicialização
  • Verifique se /dev/kvm permite escrita (não apenas existência) antes de habilitar o KVM, e sempre faça fallback para TCG elegantemente caso o KVM não esteja disponível
  • Use padrões de encaminhamento de portas como tcp::9180-:80 em vez de codificar IPs localhost para tornar a configuração portátil e reutilizável

Evitar

  • Não use if=virtio na arquitetura aarch64 - isso resolve para MMIO, que o RouterOS não suporta, causando falhas silenciosas de inicialização
  • Não ignore a verificação de permissão do KVM - /dev/kvm pode existir, mas estar ilegível, e o QEMU não faz fallback silencioso para TCG em erros de permissão
  • Não use git pull && git push em builds CI concorrentes - use o padrão retry-with-rebase para evitar rejeições de push por condições de corrida

Perguntas Frequentes

Qual é o limite de velocidade na licença CHR gratuita?
A licença CHR gratuita limita a taxa de transferência da interface a 1 Mbps. Chamadas da API REST, SSH, WinBox e acesso WebFig não são afetados. Este limite aplica-se apenas ao encaminhamento real de dados entre interfaces.
Por que o QEMU Guest Agent não funciona com aceleração HVF?
O daemon QGA do RouterOS só inicia quando detecta um hipervisor KVM via CPUID. Sob HVF (macOS) ou TCG (emulação por software), CPUID 0x40000000 não retorna a string do fornecedor KVM, então o daemon nunca inicia. Use Linux com KVM para testes QGA.
Como escolho entre SeaBIOS e UEFI para inicialização do CHR?
Use SeaBIOS para x86_64 (padrão, inicialização mais rápida). Use UEFI para a arquitetura aarch64 ARM. No x86_64, apenas o SeaBIOS pode inicializar a partição de inicialização proprietária; o OVMF não consegue lê-la.
Por que meu CHR aarch64 fica travado na inicialização com if=virtio?
Na máquina virt aarch64, if=virtio resolve para transporte MMIO. O RouterOS possui o driver virtio_pci, mas não virtio_mmio, então o kernel trava silenciosamente. Sempre use -device virtio-blk-pci explícito no aarch64.
Posso executar várias instâncias CHR simultaneamente?
Sim. Use portas únicas do hospedeiro para cada instância (9180, 9181, 9182 para API REST, etc.). Cada instância precisa de sua própria imagem de disco e rastreamento de PID para limpeza.
Qual método de aceleração devo usar?
Use KVM no Linux quando as arquiteturas do hospedeiro/convidado correspondem. Use HVF no macOS Apple Silicon para convidados aarch64. Use TCG como fallback em todas as plataformas quando a aceleração de hardware não estiver disponível.

Detalhes do Desenvolvedor

Autor

tikoci

Licença

MIT

Repositório

https://github.com/tikoci/routeros-skills/tree/main/routeros-qemu-chr

Referência

main

Estrutura de arquivos

📁 references/

📄 chr-licensing.md

📄 github-actions-ci.md

📄 known-issues.md

📄 virtio-drivers.md

📄 SKILL.md