(Book) Networking with MikroTik RouterOS: A Practical Approach to Understanding and Implementing RouterOS
Study material for the MTCNA Certification Course, updated to RouterOS v7
$19,97
MikroTik RouterOS 7 y contenedores: despliegue seguro de Pi-hole para ISPs y WISPs
- Kevin Morán
- No hay comentarios
- Comparte este artículo
Facebook
Twitter
LinkedIn
WhatsApp
Telegram
MikroTik Containers permite ejecutar servicios empaquetados dentro de RouterOS 7 sin servidores extra. Con esta función, un router asume tareas de DNS filtrado, monitoreo y autenticación. La propuesta aporta menos latencia, menor costo y una operación más simple.
Además, utiliza formatos de imágenes compatibles con registries públicos como Docker Hub. Por lo tanto, un equipo bien dimensionado puede centralizar funciones críticas con aislamiento razonable.
Fundamentos teóricos
Arquitectura de contenedores en RouterOS
Containers en MikroTik implementa Linux containers sobre el kernel de RouterOS. Utiliza namespaces y cgroups para aislar procesos y limitar recursos. Las imágenes provienen de Docker Hub, GCR o repositorios privados. El plano de red se integra con veth y bridges de RouterOS, con opción de NAT o L2 expuesto.
El almacenamiento se mapea mediante mounts hacia rutas del router o discos externos. La configuración se realiza con /container, /container/config, /container/envs y /container/mounts.
El aislamiento es bueno para servicios ligeros. Sin embargo, la seguridad final depende del origen de la imagen y del hardening del router. Por eso, MikroTik enfatiza el riesgo de ampliar la superficie de ataque al ejecutar software de terceros dentro del equipo.
Red y direccionamiento para containers
El modo más seguro y flexible usa un bridge dedicado y NAT. La veth del contenedor recibe IP de una subred interna, mientras el bridge actúa como gateway y aplica masquerade. Este modelo equivale al “bridge mode” de otros motores y evita exponer puertos innecesarios.
De ser imprescindible, se pueden publicar puertos con reglas dst-nat en el firewall. Existe un segundo patrón que ancla el contenedor a L2, similar a “host mode”. Ese diseño mejora un poco el rendimiento, pero expone todos los servicios del contenedor hacia la LAN.
En la práctica, se recomienda el bridge con NAT para servicios como DNS, HTTP o agentes de monitoreo. La guía oficial documenta ambos enfoques y sugiere prudencia con el modo L2.
Soporte, requisitos y paquetes
El paquete container funciona en arquitecturas arm, arm64 y x86. Para imágenes remotas se requiere espacio libre, por lo que MikroTik sugiere un disco externo. Algunos SoC, como EN7562CT, limitan a arm32v5, reduciendo la cantidad de imágenes disponibles.
La función está deshabilitada por seguridad y exige habilitar device-mode con acceso físico. RouterOS publica la lista de propiedades aceptadas al crear un contenedor: remote-image, interface, envlist, mounts, root-dir, logging, entre otras.
Se recomienda mantener RouterOS actualizado y usar discos externos para persistencia. La documentación central y la página de RouterOS consolidan cambios, notas y alcance.
Ventajas
Ahorro y consolidación de servicios
MikroTik Containers reduce hardware al integrar servicios clave en el router. Un ISP pequeño puede correr DNS filtrado, un agente de monitoreo o un proxy ligero. Además, la latencia baja porque el tráfico no abandona el equipo. La portabilidad de imágenes simplifica migraciones entre CHR y hardware físico.
El registro remoto agiliza despliegues repetibles y consistentes. Para redes corporativas, centralizar funciones minimiza puntos de falla y acelera el troubleshooting. Con discos externos, la persistencia de datos evita desgastar la NAND.
Por otra parte, los bridges dedicados y el NAT facilitan políticas de seguridad predecibles. Esta combinación hace viable ejecutar cargas razonables cerca del plano de reenvío.
Flexibilidad y tiempo de provisión
La compatibilidad con registries públicos permite elegir entre múltiples aplicaciones. Se implementan DNS filtrado, MQTT, RADIUS e incluso plataformas de domótica. El tiempo de provisión es corto, ya que el flujo consiste en configurar envs, mounts y red, y luego pull de la imagen.
El mantenimiento se basa en actualizar la imagen y reiniciar el contenedor sin tocar el resto del router. Por último, el enfoque sirve para laboratorio y preproducción en CHR. Estos escenarios aceleran pruebas de funciones y despliegues piloto en la nube.
La documentación oficial muestra guías paso a paso para Home Assistant, Mosquitto y ThingsBoard. Dichos ejemplos son patrones replicables para otros servicios.
Desventajas / Limitaciones
Compatibilidad, consumo y seguridad
No todas las imágenes Docker funcionan en RouterOS. Se debe respetar la arquitectura y, a veces, reconstruir con Podman o Docker Buildx. Los contenedores compiten por CPU y RAM con el plano de enrutamiento. Un error de dimensionamiento puede degradar BGP, NAT o colas.
La seguridad depende del origen de la imagen y del hardening del router. MikroTik advierte que un contenedor malicioso puede facilitar escaladas y backdoors. Además, la función no cubre orquestación avanzada como Compose o Kubernetes.
Por tanto, hay que limitarse a servicios ligeros y específicos. Por último, el almacenamiento interno es limitado, de modo que los volúmenes deben residir en discos externos para no dañar la NAND ni quedarse sin espacio.
Cuadro comparativo (ventajas vs desventajas)
Eje | Ventajas | Desventajas |
Coste | Menos hardware y energía | Riesgo si el router queda sobrecargado |
Latencia | Procesamiento local inmediato | Falla del contenedor impacta al plano de red |
Flexibilidad | Imágenes estándar y rápidas | Sin orquestación nativa |
Seguridad | Aislamiento por namespaces | Imagen de terceros aumenta superficie de ataque |
Operación | Flujo simple de envs y mounts | Requiere discos externos y mantenimiento |
Casos de uso reales
ISP/WISP: DNS filtrado centralizado
Un WISP puede desplegar Pi-hole en un CCR para bloquear anuncios y dominios maliciosos. La red direcciona las consultas hacia la IP del router, que hace dst-nat al contenedor. Los clientes no necesitan cambios manuales. El volumen del contenedor guarda listas y estadísticas en un SSD externo.
Esta arquitectura mejora la experiencia del cliente y reduce ancho de banda. La puesta en marcha requiere solo una veth, un bridge, NAT y variables de entorno. Finalmente, el mantenimiento consiste en actualizar la imagen y reiniciar el contenedor.
El patrón está descrito con comandos en la guía oficial.
Corporativo: MQTT y telemetría
En redes industriales, un MikroTik puede albergar Eclipse Mosquitto para IoT. El broker funciona dentro del contenedor y publica métricas hacia aplicaciones internas.
La guía sugiere configurar registry-url, root-dir, mounts y límites de RAM. El patrón es idéntico al de Pi-hole en cuanto a red y publicación de puertos. Con VLANs y firewall, se logra segmentación segura. La configuración paso a paso figura en la documentación de Mosquitto para RouterOS.
Tablas comparativas con alternativas
Tecnología | Arranque | Gestión | Aislamiento | Caso ideal |
MikroTik Containers | Rápido | CLI RouterOS | Medio | Servicios ligeros en el router |
VM en CHR | Medio | Hipervisor | Alto | Aplicaciones completas con más CPU/RAM |
Servidor dedicado | Lento | Complejo | Máximo | Cargas pesadas, IDS, bases de datos |
Ejercicios prácticos / Laboratorio
Topología y objetivos
El objetivo es desplegar Pi-hole en RouterOS con bridge+NAT, exponer la GUI por dst-nat y usar volúmenes en disk1. Se habilita device-mode, se crea veth, bridge, envs, mounts, y se añade el contenedor desde Docker Hub. Todos los comandos son oficiales y probados.
Paso 1. Habilitar container mode
/system/device-mode/update container=yes
# Confirmación física con botón RESET o cold reboot en x86
Paso 2. Red del contenedor
/interface/veth/add name=veth1 address=172.17.0.2/24 gateway=172.17.0.1
/interface/bridge/add name=containers
/ip/address/add address=172.17.0.1/24 interface=containers
/interface/bridge/port/add bridge=containers interface=veth1
/ip/firewall/nat/add chain=srcnat action=masquerade src-address=172.17.0.0/24
Paso 3. Variables de entorno
/container/envs/add list=ENV_PIHOLE key=TZ value="America/Guayaquil"
/container/envs/add list=ENV_PIHOLE key=FTLCONF_webserver_api_password value="CambiaEstoYA"
/container/envs/add list=ENV_PIHOLE key=DNSMASQ_USER value="root"
Personaliza contraseña y zona horaria.
Paso 4. Volúmenes montados
/container/mounts/add list=MOUNT_PIHOLE_PIHOLE src=disk1/volumes/pihole/pihole dst=/ etc/pihole/container/mounts/add list=MOUNT_PIHOLE_DNSMASQD src=disk1/volumes/pihole/dnsmasq.d dst=/ etc/dnsmasq.d
Coloca los volúmenes en disco externo para preservar la NAND.
Paso 5. Registry y directorios temporales
/container/config/set registry-url=https://registry-1.docker.io tmpdir=disk1/tmp
Paso 6. Crear el contenedor Pi-hole
/container/add remote-image=pihole/pihole interface=veth1 root-dir=disk1/images/pihole mountlists=MOUNT_PIHOLE_PIHOLE,MOUNT_PIHOLE_DNSMASQD envlist=ENV_PIHOLE name=pihole logging=yes
El contenedor se descarga y queda en status=stopped hasta iniciar.
Paso 7. Verificar e iniciar
/container/print/container/start [find where name=pihole]
Paso 8. Publicar la GUI y usar el DNS
/ip/firewall/nat/add chain=dstnat action=dst-nat protocol=tcp dst-address=192.168.88.1 dst-port=80 to-addresses=172.17.0.2 to-ports=80
# Acceso GUI: http://192.168.88.1/admin
# Configure clientes para usar 192.168.88.1 como DNS
Buenas prácticas y recomendaciones
Seguridad, almacenamiento y operación
Usa imágenes confiables y actualizadas. Limita exposición con NAT y firewall. Si necesitas L2, aplica ACLs estrictas. Mantén RouterOS al día y supervisa CPU y RAM. Sitúa volúmenes en disk1 o SSD para alargar la vida del router.
Activa logging durante la puesta en marcha y desactívalo cuando no haga falta. Define límites de RAM con ram-high si compartes recursos con BGP u OSPF. Para producción, documenta variables, puertos publicados y rutas de backup. Si te preocupa compatibilidad, assemble la imagen con Podman indicando plataforma.
Finalmente, evita correr contenedores sin necesidad de privilegios elevados. Las advertencias oficiales de seguridad son claras y deben respetarse.
Errores comunes y cómo evitarlos
Fallos de red, imagen y storage
El error más frecuente es usar equipos con poca RAM y NAND. Solución: discos externos y routers con recursos. Otro problema común es publicar todos los puertos en modo L2. Solución: bridge con NAT y dst-nat selectivo.
Algunos fallos ocurren por imagen incorrecta para la arquitectura. Solución: usar –platform al construir y seguir la matriz de compatibilidad.
También se olvida el botón físico al habilitar device-mode. Solución: revisar el procedimiento y confirmar localmente. Finalmente, el uso de la NAND como volumen agota el almacenamiento. Coloca mounts en disco externo. La comunidad comparte experiencias útiles sobre Pi-hole y containers en RouterOS.
Conclusiones
Containers de MikroTik habilita una virtualización ligera para funciones de red cercanas al plano de reenvío. El patrón bridge+NAT ofrece seguridad y control. El laboratorio de Pi-hole demuestra una implementación realista para ISPs y empresas. Aun así, la función no sustituye un hipervisor ni un servidor dedicado.
Sirve para servicios puntuales, con límites claros de recursos y seguridad. Con procedimientos basados en la documentación oficial, el despliegue es repetible y predecible.
El futuro apunta a más ejemplos oficiales y mejores flujos de mantenimiento. Por ahora, la clave está en dimensionar, endurecer y monitorizar.
Recursos adicionales
Preguntas Frecuentes
¿Puedo usar Kubernetes o Compose?
No. RouterOS gestiona contenedores individuales vía CLI. Orquestación no está soportada
¿Qué arquitectura debo elegir para Pi-hole?
Debe coincidir con tu hardware: arm, arm64 o x86. Considera reconstruir la imagen si es necesario.
¿Es obligatorio un disco externo?
Es altamente recomendado para volúmenes. Evita escribir en la NAND interna.
¿Cómo publico puertos del contenedor?
Usa dst-nat desde la IP del router hacia la IP de la veth.
¿Qué modelo es adecuado para producción?
CCR2004, RB5009 o CHR con recursos y SSD. Dimensiona CPU y RAM según carga.
¿Qué riesgos de seguridad existen?
Imágenes de terceros amplían la superficie de ataque. Aplica hardening y controla el origen.
Breve cuestionario de conocimientos
¿Qué te pareció este artículo?
¿Te atreves a evaluar tus conocimientos aprendidos?
Libros recomendados para éste artículo
Libro BGP y MPLS RouterOS v7
Material de estudio para el Curso de Certificación MTCINE actualizado a RouterOS v7
$19,97
Autoestudio MikroTik
Estudia las certificaciones MikroTik a tu propio ritmo
Autoestudio
Aprende a tu propio ritmo
advertisement (anuncio)
Artículos Relacionados
MikroLABs
Otros temas que te pueden interesar
advertisement (anuncio)
Escríbenos por WhatsApp (+593 98 700 0604)
¿Quieres sugerir un tema?
Todas las semanas posteamos nuevo contenido. Quieres que tratemos sobre algo específico?
Próximos Cursos
Libros MikroTik (español)
advertisement (anuncio)
MONARC Latin America: Soluciones Tecnológicas - monarclatinamerica.com.gt - Guatemala
1
Haz clic para chatear