Usando reglas de política de ruteo (policy routing rules) con mikrotik para interconexiones de WISP distintos

Este tema no es algo que muchos WISP vallan a necesitar, sin embargo para los que imparten asesorías para empresas y redes grandes sí esta herramienta es bastante útil (y potente)

Si eres un WISP que solo le interesa vender internet y ganar cuarto vete a otro artículo que este no lo necesitas leer. Cómo por ejemplo este

Resulta que bajo el escenario que está más abajo tenemos dos redes duplicadas. R3 pertenece a un cliente digamos que se llama LOCÓN y R4 pertenece a otro cliente llamado DELOMIO.

Ninguno de tus clientes quiere cambiar su segmento de red (ya sabes normal en los clientes) y ambos quieren acceder desde sus respectivas PC remotas conectadas a tu red.

Este escenario se puede complicar usando VPNs pero en nuestro caso si te muestro la teoría y te la aprendes puedes extenderlo a cualquier uso. Lo único que necesitas es tener ingenio para adaptarlo a tu situación.

Método 1: El rápido pero no escalable

Este método es complejo si aumentas la cantidad de clientes a los cuales les das el servicio de acceso remoto. Pero resuelves rápido si solo tienes 1 o 2 clientes con un par de redes.

Puedes usar el mangle en R2 una marca de ruta para obligar el paquete que viene de la PC1 10.87.87.1 a que tome la ruta 10.81.2.0. Este sería para tu LOCÓN.

En caso de que el cliente DELOMIO quiera acceder a su red conectada a R4 que vendría a ser la misma red del cliente LOCÓN (loco al fin) 192.168.20.0 entonces tendrías que marcar el trafico con la ruta 10.81.3.0

Esto se puede complicar aun más, imagina que cada cliente tiene 20 redes duplicadas y que también en el punto origen hay más redes duplicadas. Puede que tu cantidad de clientes crezca y pues te salga más cara la sal que el chivo.

Metodo 2: Igual de rápido y escalable

Este método es una belleza. Es fácil de implementar, de mantener, de actualizar y de introducir más y más redes sin que tengas que preocuparte porque todas las marcas de rutas funcionen correctamente.

Toda esta información la saqué de aquí. Está entendible solo que hay que tener mucha paciencia para leerla y comprender lo que ellos quieren decir. Yo la voy a resumir en 2 pasos.

Paso 1: Dividir el router en trozos. Este paso consiste en tomar la tabla de enrutamiento del router que tiene la decisión de interconectar las redes. En el caso de arriba el R2

Un router es un dispositivo que se encarga de encaminar paquetes usando una tabla. Si esta tabla la puedes dividir en difernetes pedazos y ponerles nombres a cada una de la forma

• • • Tabla_Cliente_1
    • Tabla_Cliente_2
    • Tabla_Cliente_3
    • Tabla_Cliente_N

De esta manera un mismo router puede comportarse diferente dependiendo de quien envíe el tráfico. Tu dirás «pero eso es lo que se hace con mangle» la diferencia está en un detalle importante

Puedes instruirle al protocolo de enrutamiento que inserte las rutas de cada tabla individual de forma que cada cliente pueda correr OSPF o RIP y que cada ruta ingrese al cliente correspondiente.

Para mandar las rutas a tablas de enrrutamiento específicas se usan los routing filtering. Este tema podría tocarlo más adelante porque amerita un artículo completo.

Esto es una belleza porque así no tienes que agregar cientos y cientos de marcas en el mangle para decidir por donde encaminar el paquete. Si el cliente agrega una ruta nueva no tienes que actualizar nada todo funciona sin tu intervención.

Paso 2. Configuración de las reglas de rutas

Esto no es nada del otro mundo si dominas bien lo que es routing. En este apartado vas a filtrar los paquetes entrantes dependiendo de:

• • • • src address
      • dst address
      • routing mark 
      • interfaz de entrada.

Los paquetes son evaluados y si cumplen con alguno de los criterios de la lista de rules entonces se usa una tabla en específico. Incluso puedes obligar al router a solo buscar en una tabla particular (para que no te valla a mandar paquetes de una red de un cliente a otra).

Action

En este apartado tenemos 4 opciones.

• • • • drop. Si te interesa responer el paquete que cumpla esa regla con un simple drop.
      • lookup: Si quieres que el router busque en la tabla Tabla_Cliente_1 y si no encuentra un camino para ese paquete entonces use la tabla main.
      • lookup only in table: La misma que lookup pero solo usa la Tabla_Cliente_1. SI no encuentra una ruta que coincida responde con un network unreachable.
      • unreachable: Respone los paquete que cumplan la regla con un network unreachable.

Esto señores es un recurso potentísimo. Se me ocurren una infinidad de cosas que se pueden hacer con esto. En este caso particular lo uso para dirigir trafico a redes de clientes que cuentan con interfaces dentro del mismo segmento de red.

Lo mejor de todo esto es que como le explicaba puedes correr enrrutamiendo dinámico en todos los clientes a la vez y repartir las rutas en tablas independientes.

De esta forma el router se comporta completamente distinto dependiendo de donde vengan los paquetes. Es como dividir un router en decenas de pedazos cada uno con un forwarding information base distinto.

Table:

En esta opción vas a especificar en cual de las tablas de ruta el router va a aplicar el table lookup process o proceso de búsqueda de tabla en español. Lo ideal es que asignes a cada usuario una tabla exclusiva.

Esto es realmente una ventaja sorprendente de mikrotik ya que pueden coexistir múltiples redes todas convergiendo en el mismo router con la posibilidad de que varias de esas redes estén duplicadas.