MikroTik CHR: cuando el router dejó de ser una caja, ahora es software

Cada vez que una red crece, suele ocurrir lo mismo.

Necesitas concentrar varias VPN: compras un router.

Necesitas proteger unas máquinas virtuales: compras otro router.

Necesitas más memoria para CGNAT o BGP: reemplazas el router.

Necesitas montar una infraestructura en la nube: buscas cómo enviar una caja física hasta un lugar donde, evidentemente, no puedes instalarla.

Seguimos resolviendo problemas nuevos con una idea vieja:

El router siempre será una caja con puertos.

Pero esa idea dejó de ser cierta hace tiempo.

El router puede vivir dentro de un servidor, compartir la infraestructura con tus máquinas virtuales, ejecutarse en un VPS a miles de kilómetros y seguir ofreciéndote el mismo RouterOS de MikroTik que ya conoces.

Aquí viene el cambio de perspectiva:

El router dejó de ser un lugar. Ahora es una función.

Y una función puede ejecutarse donde tenga más sentido para tu arquitectura.

Vamos a eso.

La creencia que te cuesta caro

Deja que adivine cómo llegaste hasta aquí.

Tienes un servidor con Proxmox o VMware. Dentro viven varias máquinas virtuales: un sistema administrativo, un servidor web, un DNS, una plataforma de monitoreo y quizás algún servicio para clientes.

Cada máquina necesita conectividad.

Entonces conectaste el bridge principal del hipervisor directamente a Internet y comenzaste a entregar direcciones públicas a las VMs.

En teoría funciona.

En la práctica, acabas de colocar cada servidor frente a Internet con una instrucción silenciosa:

“Defiéndete como puedas”... y a veces no podrá!

Una VM tiene su firewall bien configurado. Otra dejó SSH abierto. Otra conserva una contraseña débil. Otra ejecuta una aplicación desactualizada. Y otra tiene puertos publicados que nadie recuerda por qué se abrieron.

El resultado es predecible:

• Cada IP pública se convierte en una nueva superficie de ataque.
• La política de seguridad queda distribuida entre múltiples sistemas.
• Los cambios deben repetirse máquina por máquina.
• El acceso remoto depende de publicar cada vez más servicios.
• Nadie tiene una visión completa de lo que entra y sale.

El problema no es Proxmox.

Tampoco es VMware.

Y probablemente tampoco son tus servidores.

El problema es que construiste una plataforma virtualizada sin un borde de red bajo tu control. Y el proveedor de servicios en la nube, poco le importa.

Qué es realmente MikroTik CHR

CHR significa Cloud Hosted Router.

En términos sencillos, es RouterOS empaquetado para funcionar como una máquina virtual sobre arquitectura x86.

No es un simulador.

No es una versión educativa.

No es un RouterOS recortado.

Es el mismo sistema operativo que utilizas en un RouterBOARD o un CCR, pero ejecutándose dentro de un hipervisor o un servidor virtual.

Puedes utilizarlo para:

• Firewall y NAT.
• WireGuard, IPsec y otras VPN.
• BGP, OSPF y enrutamiento estático.
• QoS y administración de ancho de banda.
• Concentración de conexiones.
• Segmentación mediante VLAN.
• CGNAT.
• Monitoreo, scripts y automatización.

Puede vivir en Proxmox, VMware ESXi, KVM, Hyper-V, VirtualBox, Xen o directamente dentro de un VPS.

Mismo cerebro. Distinto cuerpo.

CHR no elimina la necesidad del hardware, esto por ahora es imposible.

Cambia quién lo suministra.

En lugar de depender exclusivamente del procesador, la memoria y los puertos incluidos y predefinidos en una caja diseñada por MikroTik, utilizas los recursos del servidor donde se ejecuta.

La licencia no habilita funciones: habilita velocidad

Otro error frecuente es pensar que una licencia más económica trae menos características.

No funciona así.

Las funciones de RouterOS están disponibles. Lo que cambia entre las licencias de CHR es el límite de velocidad por interfaz.

La edición gratuita sirve para laboratorios y pruebas, pero su límite de tráfico la hace inadecuada para producción. A partir de allí puedes escalar a licencias de 1 Gbit/s, 10 Gbit/s o sin límite establecido por la licencia.

La decisión correcta no es:

“¿Qué funciones necesito habilitar?”

La pregunta correcta es:

“¿Cuánto tráfico deberá procesar esta instancia durante los próximos años?”

Y aquí aparece una de las ventajas de CHR: puedes comenzar con una licencia acorde al despliegue actual y ampliarla cuando el proyecto crezca, sin reconstruir toda la plataforma.

Pieza 1 — Un router que nunca duerme: CHR en un VPS

Un VPS (Maquina virtual alquilada en la nube) con CHR te da algo difícil de garantizar en muchas oficinas: un punto público, estable y disponible permanentemente.

Piensa en una empresa con varias sedes sin IP pública.

La oficina principal concentra las VPN porque allí está el router más potente. Todo funciona hasta que falla la energía, se cae el proveedor o alguien apaga accidentalmente el rack.

De repente, todas las sucursales quedan aisladas.

Un CHR alojado en un datacenter cambia el patrón.

En lugar de depender de una sede física, cada oficina establece un túnel hacia una instancia con IP pública fija y disponibilidad 24/7.

Ese CHR puede funcionar como:

Concentrador VPN

Las oficinas, técnicos y usuarios remotos terminan sus túneles WireGuard o IPsec en un único punto público.

Hub entre múltiples sitios

Las sedes se comunican a través de la nube sin que una oficina tenga que convertirse obligatoriamente en el centro de toda la red.

Servidor de pruebas

Puedes medir tráfico entre tus routers y el VPS sin depender exclusivamente de plataformas públicas de Speedtest.

Punto de monitoreo externo

Netwatch, scripts y alertas vía telegram pueden verificar tus sitios desde una infraestructura que permanece fuera de ellos.

La nube no hace que el router sea más inteligente.

Hace que esté ubicado en un lugar más conveniente.

Pieza 2 — El borde virtual que protege tus máquinas

Este es probablemente el caso de uso más importante para quienes administran Proxmox o VMware.

El esquema común, pero peligroso, se parece a esto:

Internet
   │
Bridge o vSwitch público
   ├── VM Linux 1 · IP pública
   ├── VM Linux 2 · IP pública
   └── VM Linux 3 · IP pública

Cada VM está expuesta directamente.

Cada una necesita su propio firewall.

Cada error de configuración abre una nueva puerta.

Ahora colocamos un CHR entre Internet y las máquinas:

Internet
   │
IP pública
   │
MikroTik CHR
Firewall · NAT · VPN · QoS
   │
Red privada virtual
   ├── VM Linux 1 · IP privada
   ├── VM Linux 2 · IP privada
   └── VM Linux 3 · IP privada

El cambio parece pequeño, pero transforma toda la arquitectura.

Las máquinas dejan de mirar directamente a Internet. El tráfico entra y sale por un único punto de control.

El CHR asume cuatro trabajos fundamentales:

1. Direccionamiento

Administra la red pública y las redes privadas utilizadas por las máquinas virtuales.

2. NAT y publicación de servicios

Puedes asignar una IP pública completa a una VM mediante NAT 1:1 o publicar únicamente los puertos que una aplicación necesita.

No expones un servidor entero solo porque requiere acceso HTTPS.

3. Firewall centralizado

Las reglas principales viven en un solo lugar.

Puedes controlar qué servicios se publican, desde qué países o redes se aceptan conexiones, qué máquinas pueden comunicarse entre sí y qué tráfico debe bloquearse.

4. Acceso mediante VPN

Los administradores entran por WireGuard o IPsec y acceden a las direcciones privadas.

WinBox, SSH, RDP, las consolas web y las bases de datos dejan de estar publicadas para todo Internet.

El CHR se convierte en una VM más dentro del hipervisor.

Pero no es una VM cualquiera.

Es la VM que decide quién habla con todas las demás.

Dos formas de entrar: publicación y VPN

No todo servicio debe tratarse de la misma manera.

Una página web pública necesita recibir conexiones desde Internet. La consola de administración de esa página, probablemente no.

Por eso el diseño debe separar dos caminos.

Servicios públicos

Utilizas reglas de dst-nat para publicar exclusivamente los puertos necesarios:

• HTTP y HTTPS.
• Un servicio específico.
• Una aplicación que debe ser consumida externamente.

Administración privada

Utilizas una VPN para llegar a:

• SSH.
• RDP.
• WinBox.
• Proxmox.
• VMware.
• Bases de datos.
• Paneles administrativos.
• Sistemas de monitoreo.

La regla es sencilla:

Lo que necesita el público se publica. Lo que necesita tu equipo se enruta por una VPN.

Cuando todo termina convertido en un port forwarding, no tienes una política de acceso. Tienes una colección de excepciones.

Pieza 3 — Cuando el CCR ya no alcanza

CHR no solo sirve para pequeñas máquinas virtuales o concentradores VPN.

También puede ejecutarse sobre un servidor x86 dedicado y asumir funciones de core en redes de ISP.

Aquí conviene evitar los discursos absolutos.

Un CCR sigue siendo una excelente elección cuando necesitas:

• Puertos de alta velocidad integrados.
• Bajo consumo eléctrico.
• Formato compacto.
• Un equipo probado y listo para instalar.
• Menos componentes y menor complejidad operativa.
• Soporte sobre una plataforma cerrada y conocida.

Pero un servidor con CHR comienza a tener sentido cuando el problema principal ya no son los puertos, sino los recursos de procesamiento y memoria.

Por ejemplo:

CGNAT con muchas conexiones

Connection tracking consume memoria. A medida que aumentan los clientes y las sesiones simultáneas, la RAM deja de ser un detalle y se convierte en parte central del diseño.

En un servidor puedes instalar decenas o cientos de gigabytes de memoria, dependiendo de la plataforma.

Varias tablas completas de BGP

Cada peer, filtro y tabla de rutas requiere memoria y procesamiento. Una CPU x86 moderna, con buen rendimiento por núcleo, puede ofrecer una plataforma apropiada para estas cargas.

Crecimiento progresivo

Puedes ampliar RAM, reemplazar una NIC, cambiar el procesador o migrar la instancia hacia otro servidor sin reconstruir toda la configuración desde cero.

Disponibilidad de repuestos

Una fuente de poder, un disco o una tarjeta de red de servidor puede conseguirse y sustituirse sin esperar necesariamente el RMA de un equipo especializado.

Pero aquí está la advertencia:

Un servidor no se convierte automáticamente en un router de alto rendimiento solo porque tenga muchos núcleos.

El rendimiento dependerá de:

• La frecuencia y arquitectura de la CPU.
• Los paquetes por segundo.
• El tamaño promedio de los paquetes.
• El número de reglas de firewall.
• Connection tracking.
• Las colas y túneles.
• El driver de las interfaces.
• La ruta que recorren los paquetes dentro del hipervisor.
• El uso de PCI passthrough o SR-IOV cuando la carga lo exige.

En un CHR no tienes un switch-chip descargando trabajo.

Cada paquete que procesas pasa por la CPU.

Pieza 4 — Proxmox o VMware: cambia el camino, no el router

Para CHR, ambos hipervisores cumplen el mismo objetivo.

En Proxmox utilizarás normalmente:

• Imagen RAW.
• Interfaces VirtIO.
• Bridges como vmbr0 y vmbr1.
• KVM/QEMU como backend.
• Snapshots, backups y almacenamiento como ZFS, Ceph o LVM-thin.

En VMware utilizarás normalmente:

• Imagen VMDK.
• Interfaces VMXNET3.
• Port groups y vSwitches.
• BIOS compatible con la imagen.
• Políticas del vSwitch cuando la topología requiera aceptar cambios de MAC o tráfico promiscuo.

La regla de rendimiento es clara:

Utiliza los drivers paravirtualizados diseñados para cada plataforma.

VirtIO en Proxmox y KVM.

VMXNET3 en VMware.

La topología final será prácticamente la misma:

NIC física / bridge WAN
          │
       ether1
     MikroTik CHR
       ether2
          │
Bridge interno sin salida física
          │
   Máquinas virtuales

ether1 recibe la conectividad pública.

ether2 se conecta a una red virtual privada.

Las demás VMs solo utilizan esa red privada y tienen al CHR como gateway.

El patrón completo, de punta a punta

Una arquitectura básica con CHR como borde queda así:

Internet → bridge WAN → CHR → bridge LAN privado → máquinas virtuales

Sobre ese patrón agregas las funciones necesarias:

1. Dirección pública y ruta por defecto en la interfaz WAN.
2. Direccionamiento privado en la interfaz LAN.
3. NAT para la salida de las VMs.
4. Firewall de entrada para proteger el propio CHR.
5. Firewall de forwarding para proteger las máquinas.
6. Publicaciones puntuales mediante dst-nat.
7. WireGuard o IPsec para administración.
8. VLAN para separar clientes, servidores y gestión.
9. Backups y exports de RouterOS.
10. Snapshots controlados desde el hipervisor.

No necesitas comenzar con una arquitectura enorme.

Puedes levantar un CHR pequeño, conectar dos interfaces y mover una sola VM detrás de él.

Una vez probado el patrón, migras las demás.

Los errores que convierten un CHR en un problema

Virtualizar el router no corrige automáticamente un mal diseño.

Solo virtualiza sus consecuencias.

Estos son los errores que más caro se pagan.

Dejar el usuario administrador sin contraseña

Un CHR recién desplegado puede quedar directamente conectado a una IP pública. Los escaneos comienzan prácticamente de inmediato.

La contraseña no es una tarea para después.

Publicar WinBox, SSH o la API para todo Internet

Cambiar el puerto no convierte un servicio en seguro.

Restringe el acceso por direcciones de confianza o, mejor aún, administra mediante VPN.

No configurar el firewall de input

El firewall que protege a las VMs no sustituye el que debe proteger al propio router.

input protege el CHR.

forward protege el tráfico que atraviesa el CHR.

Confundir ambas cadenas deja una parte de la infraestructura expuesta.

Utilizar la licencia gratuita en producción

El CHR arrancará y parecerá funcionar, pero el límite de velocidad terminará convirtiéndose en una falla difícil de interpretar para quien no conozca la licencia instalada.

Dimensionar únicamente por megabits

Un gigabit compuesto por paquetes grandes no exige lo mismo que un gigabit de paquetes pequeños y miles de conexiones.

El número que termina castigando la CPU es el de paquetes por segundo (pps).

Asignar muchos núcleos sin entender la carga

Más vCPU no siempre significa rendimiento lineal.

Primero identifica si el cuello de botella está en el procesamiento, el driver, el bridge virtual, el firewall, las colas o la interfaz física.

No reservar recursos

Si el CHR comparte servidor con VMs que consumen toda la CPU o la memoria, el router también sufrirá.

El hipervisor debe garantizar recursos suficientes para la función más crítica de la plataforma.

No hacer backups

Una exportación de RouterOS, un backup y una copia fuera del servidor cuestan minutos.

Reconstruir de memoria el borde completo de un datacenter puede costar una noche.

Centralizar no significa ignorar la alta disponibilidad

Colocar el firewall y el enrutamiento en un único CHR simplifica la administración, pero también concentra responsabilidad.

En un laboratorio o despliegue pequeño, una instancia puede ser suficiente.

En una plataforma crítica debes pensar también en:

• Backups externos.
• Snapshots antes de cambios importantes.
• Réplicas del almacenamiento.
• Clúster del hipervisor con VRRP
• Recuperación en otro nodo.
• Redundancia de interfaces y switches.
• Segundo CHR o estrategia de conmutación.
• Acceso fuera de banda al servidor.

La virtualización hace que recuperar el router sea más rápido.

No elimina la necesidad de diseñar cómo recuperarlo.

CHR no reemplaza todos los routers

Y decirlo claramente es importante.

CHR no es una excusa para virtualizar cada router de la red.

Una RouterBOARD sigue teniendo sentido como CPE, equipo de una sucursal, nodo inalámbrico o dispositivo instalado donde necesitas interfaces físicas y bajo consumo.

Un CCR sigue siendo una solución sólida para muchos bordes y cores.

CHR gana cuando el router necesita vivir:

• Dentro de un VPS.
• Dentro de Proxmox o VMware.
• Junto a las máquinas que debe proteger.
• Sobre un servidor con más CPU y RAM.
• En una plataforma que requiera snapshots, migración o recuperación rápida.
• En un laboratorio virtual con múltiples topologías.

No se trata de escoger entre hardware y software como si fueran rivales.

Se trata de ubicar cada función donde produzca mejores resultados.

Las tres decisiones que separan un CHR de laboratorio de uno de producción

Si te llevas solo tres ideas de este artículo, que sean estas:

01 · Deja de pensar en el router como hardware tradicional rotulado MikroTik

RouterOS puede vivir en una caja física, un VPS, un hipervisor o un servidor dedicado.

La arquitectura debe decidir dónde corre, no la costumbre.

02 · Coloca un borde frente a tus máquinas virtuales

No entregues direcciones públicas indiscriminadamente y esperes que cada VM se proteja sola.

Centraliza NAT, firewall, VPN y segmentación en un punto controlado.

03 · Dimensiona por trabajo real

No mires únicamente los megabits.

Evalúa paquetes por segundo, conexiones simultáneas, reglas, túneles, colas, tablas de rutas, drivers y recursos garantizados.

De entenderlo a dominarlo

CHR cambia una creencia muy arraigada:

Para tener otro router, ya no tienes que comprar necesariamente otra caja.

Puedes descargar una imagen, crear una máquina virtual y levantar una nueva función de red en minutos.

Pero la facilidad de desplegarlo no debe confundirse con facilidad para diseñarlo.

El verdadero valor aparece cuando entiendes cómo conectar las interfaces virtuales, separar la WAN de la LAN, proteger el propio router, publicar únicamente lo necesario y mantener las máquinas detrás de una política centralizada.

Esto fue el mapa.

El terreno se aprende creando el laboratorio: levanta un CHR gratuito en Proxmox, VMware o paga por VPS económico, conecta una máquina virtual detrás de él, configura la salida a Internet y accede nuevamente mediante una VPN.

Después rompe la ruta, bloquea un puerto, restaura un backup y migra la VM.

Cuando lo hayas hecho varias veces, dejarás de ver un router virtual.

Comenzarás a ver lo que realmente es:

Una función de red que puede vivir donde tú decidas.

Luis Aguilar · CTO Ekoinos · Instructor certificado MikroTik 📱 WhatsApp: +58 412-356-4673 · ✉️ luis.aguilar@ekoinos.com

¿Te sirvió? Compártela con el colega que anda peleándose con tres antenas en este momento. Los próximos cursos están en la bio de nuestro instagram @ekoinos.