Manual: Mikrotik, VPN One to Many (L2TP + Netmap)

Introducción​

En este manual no vamos a hablar de ningún tipo de VPN nueva, sino de un caso práctico, planteado por un usuario. El caso es muy simple, pero a la vez muy frecuente: tengo un servicio X que quiero suministrar a unos clientes, y quiero tener la posibilidad de administrar la configuración de dicho servicio de forma remota. Sin embargo, la inmensa mayoría de ellos utiliza el router de operadora, con el mismo segmento de red (famoso 192.168.1.0/24), y es un fastidio montarles un equipo que reemplace a este: además de no ser un experto en redes, les causaría un impacto importante modificar su red actual, la cual ya está funcionando perfectamente.
Además de esto, se me suma la siguiente condición: cada uno, como se suele decir, es de su padre y de su madre, así que unos se conectan usando un proveedor que entrega IP pública, otros tienen CGNAT, otros una conexión LTE... vamos, un cristo.

Presentación del problema​

Bienvenidos a TvEO.tv: montamos cámaras de seguridad para que puedas ver a tu gato haciendo monerías mientras estás fuera de casa, o a tu vecino cotilla asomándose por la ventana. Las cámaras funcionan 24x7, pero de vez en cuando alguna deja de grabar y hay que darles un reinicio, o se llena la memoria y hay que vaciarlas, o simplemente hay que actualizarles el firmware, que ya sabemos cuán delicado son estos temas. Tenemos el siguiente esquema:



¿Cómo me las apaño para que, sin tocar lo que el cliente tiene ya en casa montado, esto funcione y yo tenga administración remota a las cámaras de seguridad, conectadas a dicho segmento de red que se repite?

Planteamientos​

De entrada podríamos pensar que podemos montar una VPN entre los headquarters y los clientes, y levantar cada túnel de manera independiente. Aquí nos topamos con dos problemas: el primero, si queremos levantar la VPN a demanda, lo normal es que la parte cliente sea quien monta el servidor, mientras que nosotros como headquarter levantamos el túnel a demanda. Así podemos ir levantando túneles independientemente y, una vez conectados, acceder a dicho rango de red remoto. La solución sin embargo la pintan calva, al darnos cuenta de que cada cliente tiene un tipo de conexión distinta, la cual no podemos dar por hecha que tenga una IP pública. Además, es un poco engorro, porque la actualización de las cámaras es un proceso que tenemos automatizado, y no queremos tener que andar conectando túneles manualmente para ir lanzando la actualización una a una, la cual se podría hacer toda de golpe.
La segunda opción, y más lógica, es que el servidor esté en los headquarters de TvEO.tv y nuestros clientes simplemente se conecten a nosotros. ¿Problema? tenemos muchos túneles levantados y la misma dirección remota a la que acceder, así que hay que encontrar una manera de enrutar ese tráfico por cada cliente, de manera independiente.

Solución: Netmap​

Cómo no, MikroTik al rescate. Para solucionar este embrollo vamos a desplegar routers MikroTik en toda esta infraestructura, montando un router servidor en los headquarters y routers cliente en cada uno de nuestros abonados. Por comodidad, vamos a configurar los routers cliente como switches, puesto que ni si quiera vamos a andar conectando las cámaras al router MikroTik, el cual se conectará al router del operador como un cliente más. Sería mucho más correcto montar esos equipos como router y conectar las cámaras a ellos, pero el cliente nos pide tener visibilidad no sólo de las cámaras, sino de toda su red, por si algo más falla. Además, ya que vamos a molestarle, le regalamos un switch que puede reusar en su red actual.

El tipo de VPN que vamos a elegir no es trivial, necesitamos algo que funcione en la inmensa mayoría de los equipos cliente (algo ampliamente soportado, transversal), que funcione en modo cliente/servidor, y que, si la conexión se cae, el cliente se quede indefinidamente tratando de restaurarla. Además, como no necesitamos más que un acceso esporádico, el rendimiento y velocidad de la VPN no es determinante en este setup. Por todo ello, elegimos L2TP/IPSec para dicho setup.

El servidor​

Para montar la parte servidora, no nos vamos a complicar la vida. Vamos a coger un router MikroTik recién reseteado, con la configuración por defecto, y lo vamos a montar como equipo principal del los headquarters. Dicho equipo ha de manejar la IP pública de esta conexión, y esto es muy importante: necesitamos que el DDNS de MikroTik funcione a la perfección, y mantenga mapeado el nombre de dominio y la IP pública que podamos tener constantemente (si tenemos IP estática, mejor que mejor, pero no es imprescindible). Dicho setup no tiene misterio: un servidor, las reglas de firewall para abrir los puertos 4500 y 500 IPSec + 1701 de L2TP y la configuración de los clientes. En dicha configuración (/ppp secrets) comienza la magia. Para cada cliente, además de los datos de usuario y contraseña, vamos a definir dos segmentos de red, uno común par el túnel l2tp (ip origen <> ip destino del túnel), más un rango de red nuevo, totalmente inventado. Este último será con el que haremos la trampa de mapear dicha subred a la subred común remota. Para el segmento de red de la VPN podéis reusar el mismo segmento o segmentos individuales (son IPs sin broacast, así que no hay problema). La parte servidora, nos quedaría así:
Como podéis ver, nos hemos inventado las subredes 192.168.11.0/24 para el uno, 192.168.12.0/24 para el dos y 192.168.13.0/24 para el tres. Esas serán las subredes a las que accederemos cuando queramos acceder a la subred 192.168.1.0/24 del otro extremo. Así, cuando hagamos ping a la 192.168.11.1, en verdad estaremos haciendo ping a la 192.168.1.1 del cliente1. A su vez, cuando hagamos ping a la 192.168.13.1, estaremos haciendo ping a la 192.168.1.1 del cliente 3. Dichas subredes se meten en al campo routes para que, en el router servidor, se cree una ruta dinámica que diga que a la subred X se llega por el túnel que levanta ese cliente, de manera automática (así no necesitaremos meter rutas estáticas).

Los clientes​

Pues lista la parte servidora, vamos a por la parte cliente. Para ella, vamos a utilizar equipos Mikrotik reseteados, sin la configuración por defecto. En ellos vamos a aplicar una configuración muy sencillita: un bridge con todos los puertos dentro, el cilente VPN, y un par de reglas de nat que hagan la magia de mapear cada subred inventada, más una ruta de retorno que nos mande a la casilla de salida. Tendríamos la siguiente configuración para cada cliente (se pueden aprovechar las variables de entorno declaradas al principio y usar esa configuración compo plantilla, para ir creando cada un import por cada equipo. Una vez listos, los subiremos al router y, partiendo de un equipo sin configuración, lo importaremos con /import clienteX.rsc

La magia la hacen las dos reglas de NAT: la primera, enmascara cualquier subred que no sea la original donde está pinachado ese router, permitiendo así que la 192.168.88.x del servidor llegue a su cliente, sin ser un elemento de su red. Al mismo tiempo, la segunda realiza la conversión entre subredes: todo lo que llegue con origen el que sea y destino la subred inventada, lo mapeas a la subred original que se repite. De esta manera, nosotros accederemos desde el servidor a la IP inventada, la cual tiene un mapeo 1:1 con la subred del router de operadora. Así cuando accedamos a la 192.168.11.1, estaremos accediendo a la 192.168.1.1 del cliente 1 (etc, como ya hemos explicado).

Sin más, espero que os guste este manual y os sea de utilidad. El compañero @genuino86, seguro lo agradecerá.

Saludos!

@pokoyo una vez más abriendo las posibilidades de nuestros aparatos, qué crack!!

Como siempre agradecido por tus aportes.

Saludos!

Además, esto mismo se puede usar a OSPF para acceder a los routers que tenemos por encima de nuestros mikrotik (por ejemplo, en el caso de tener un HGU en monopuesto). Simplemente configuramos una IP de la subred que nos inventemos en la interfaz que nos une al HGU (al igual que la IP de verdad), y, en lugar de anunciar la 192.168.1.0/24, anunciamos dicha subred inventada. La ruta se propagará a todos los elementos de la red OSPF, y simplemente tendremos que crear en netmap en los equipos donde tengamos un HGU por encima.

Seguro que a @diamuxin le gusta la idea

Saludos!

@pokoyo, me quito el sombrero!

Es una privilegio formar parte de esta comunidad con persona tan desinteresada en aportar sus conocimientos.

Saludos!

cp2t dijo:

@pokoyo, me quito el sombrero!

Es una privilegio formar parte de esta comunidad con persona tan desinteresada en aportar sus conocimientos.

Saludos!

Haz clic para expandir...

De nada majo, con que le saquéis partido, me sobra.

Saludos!

Es un placer tener gente como tu siempre dispuesta a ayudar.

Muchas gracias por todo lo que haces por nosotros!

Saludos.

Gran tutorial. Una consulta, ¿por qué l2tp y no wg? Últimamente habías basado todas las vpn en el nuevo protocolo.

Saludos!

Emulero dijo:

Gran tutorial. Una consulta, ¿por qué l2tp y no wg? Últimamente habías basado todas las vpn en el nuevo protocolo.

Saludos!

Haz clic para expandir...

Porque ese setup necesita de un cliente y un servidor bien diferenciados, donde el cliente esté constantemente tratando de reconectar al servidor si la conexión se cae.

No hay soluciones mágicas, y wireguard tampoco es una excepción. Cada tipo de VPN tiene sus peros, y en este caso vi más correcto el uso de L2TP/IPSec.

Saludos!