Gestionar tus dispositivos con VRF
00:17:21
LinkAbout this episode
Hola a todos, hoy iba a titular el capítulo siguiendo las instrucciones de un buen amigo que sabe mucho de posicionamiento como «la gestión definitiva de tus dispositivos con VRF», o algo del estilo «No te podrás creer lo que puedes hacer con RouterOS7» o alguna cosa así, pero al final no he tenido estómago para hacerlo y el capítulo se va a llamar «Gestionar tus dispositivos con VRF» y vamos a aprovechar para comentar la funcionalidad nueva de VRF en Mikrotik.
Hoy vamos a hablar de VRF (Virtual Routing and Forwarding) que en RouterOS7 ya viene por defecto gracias a que ya viene incluido en el kernel de Linux.
Lo primero es tener claro qué es eso de VRF, ya os he dicho que VRF significa Virtual Routing and Forwarding, pero aún no os he contado qué hace.
No se si además de seguir el podcast os leéis los artículos que de vez en cuando voy colgando en la web. En 2016 colgué un artículo hablando de PBR en linux, en el artículo lo que os comentaba era cómo hacer que se tomara una decisión de routing en función del origen, es decir, podíamos seleccionar el next hop dependiendo del origen en vez del destino. Para explicar esto encabecé el artículo con la frase de Anton Chejov, que escribió unos fantásticos cuentos por si no los habéis leído, «Si quieres ser universal, habla de tu pueblo, de tu aldea», es decir, nunca olvides de donde vienes.
Pues bien, si vamos un poco más allá en ese concepto podemos por ejemplo seleccionar un nexthop en función del interfaz por el que ha entrado ese tráfico y ya si vamos otro poquito más allá podemos hacer que en función del interfaz de entrada tengamos una tabla de rutas independiente.
Al tener tablas de rutas diferentes en función del interfaz podemos tener por ejemplo rutas por defecto diferentes en función del interfaz y por supuesto esas tablas de rutas, por defecto, no se verán entre si.
De esta manera podemos decir que el gateway de la tabla principal es la 192.168.1.1 y de la tabla de gestión la 10.1.1.1 y podemos tener destinos a los que se llegue por una tabla pero no por otra.
Esto puede ser muy útil porque el router no va a tener forma de unir las dos tablas.
Esto nos permite tener tablas de rutas separadas, una para la gestión y otra para el tráfico general. Esto es algo que ser podía hacer de forma más o menos sencilla en otros dispositivos desde hace ya bastante tiempo.
Bueno, después del rollo, vamos a buscarle una utilidad práctica a todo esto.
Si sois usuarios de otros equipos de red como Cisco o Juniper esto os va a sonar bastante viejuno, pero en Mikrotik es algo relativamente nuevo gracias al kernel de Linux.
En la versión de RouterOS7 ya tenéis soporte de VRFs, así que
[edu@Casa Edu] > /ip/vrf/add name=gestion interfaces=ether1
[edu@Casa Edu] > /ip/route/add gateway=10.1.1.1 vrf-interface=ether1
[edu@Casa Edu] /ip/service> print
Flags: X, I - INVALID
Columns: NAME, PORT, CERTIFICATE, VRF
# NAME PORT CERTIFICATE VRF
0 telnet 23 main
1 ftp 21
2 www 80 main
3 ssh 22 main
4 X www-ssl 443 none main
5 api 8728 main
6 winbox 8291 main
7 X api-ssl 8729 none main
[edu@Casa Edu] /ip/service> set numbers=2 vrf=gestion
Con esto que os paso tan sencillo la gestión de vuestro mikrotik ya no será accesible desde los clientes.
Hasta ahora la protección de los Mikrotik ha sido un tema bastante arduo porque dependía en buena medida de la configuración del firewall y de cómo se redistribuían las rutas, por ejemplo, redistribuir las redes de gestión en la tabla de rutas general es algo que deberíamos de evitar siempre que podamos.
Ahora, todo esto tiene una pega, yo no me había dado cuenta, pero mi compañero Adrián sí, y es que el SNMP no puede ser expuesto en una VRF, supongo que para futuras versiones eso se solucionará.
A partir de la versión de hoy, la 7.3 ya se puede exponer el SNMP a la VRF.
Hoy vamos a hablar de VRF (Virtual Routing and Forwarding) que en RouterOS7 ya viene por defecto gracias a que ya viene incluido en el kernel de Linux.
Lo primero es tener claro qué es eso de VRF, ya os he dicho que VRF significa Virtual Routing and Forwarding, pero aún no os he contado qué hace.
No se si además de seguir el podcast os leéis los artículos que de vez en cuando voy colgando en la web. En 2016 colgué un artículo hablando de PBR en linux, en el artículo lo que os comentaba era cómo hacer que se tomara una decisión de routing en función del origen, es decir, podíamos seleccionar el next hop dependiendo del origen en vez del destino. Para explicar esto encabecé el artículo con la frase de Anton Chejov, que escribió unos fantásticos cuentos por si no los habéis leído, «Si quieres ser universal, habla de tu pueblo, de tu aldea», es decir, nunca olvides de donde vienes.
Pues bien, si vamos un poco más allá en ese concepto podemos por ejemplo seleccionar un nexthop en función del interfaz por el que ha entrado ese tráfico y ya si vamos otro poquito más allá podemos hacer que en función del interfaz de entrada tengamos una tabla de rutas independiente.
Al tener tablas de rutas diferentes en función del interfaz podemos tener por ejemplo rutas por defecto diferentes en función del interfaz y por supuesto esas tablas de rutas, por defecto, no se verán entre si.
De esta manera podemos decir que el gateway de la tabla principal es la 192.168.1.1 y de la tabla de gestión la 10.1.1.1 y podemos tener destinos a los que se llegue por una tabla pero no por otra.
Esto puede ser muy útil porque el router no va a tener forma de unir las dos tablas.
Esto nos permite tener tablas de rutas separadas, una para la gestión y otra para el tráfico general. Esto es algo que ser podía hacer de forma más o menos sencilla en otros dispositivos desde hace ya bastante tiempo.
Bueno, después del rollo, vamos a buscarle una utilidad práctica a todo esto.
Si sois usuarios de otros equipos de red como Cisco o Juniper esto os va a sonar bastante viejuno, pero en Mikrotik es algo relativamente nuevo gracias al kernel de Linux.
En la versión de RouterOS7 ya tenéis soporte de VRFs, así que
[edu@Casa Edu] > /ip/vrf/add name=gestion interfaces=ether1
[edu@Casa Edu] > /ip/route/add gateway=10.1.1.1 vrf-interface=ether1
[edu@Casa Edu] /ip/service> print
Flags: X, I - INVALID
Columns: NAME, PORT, CERTIFICATE, VRF
# NAME PORT CERTIFICATE VRF
0 telnet 23 main
1 ftp 21
2 www 80 main
3 ssh 22 main
4 X www-ssl 443 none main
5 api 8728 main
6 winbox 8291 main
7 X api-ssl 8729 none main
[edu@Casa Edu] /ip/service> set numbers=2 vrf=gestion
Con esto que os paso tan sencillo la gestión de vuestro mikrotik ya no será accesible desde los clientes.
Hasta ahora la protección de los Mikrotik ha sido un tema bastante arduo porque dependía en buena medida de la configuración del firewall y de cómo se redistribuían las rutas, por ejemplo, redistribuir las redes de gestión en la tabla de rutas general es algo que deberíamos de evitar siempre que podamos.
Ahora, todo esto tiene una pega, yo no me había dado cuenta, pero mi compañero Adrián sí, y es que el SNMP no puede ser expuesto en una VRF, supongo que para futuras versiones eso se solucionará.
A partir de la versión de hoy, la 7.3 ya se puede exponer el SNMP a la VRF.