Bullet Proof (warrior mode) Multihomed VPN-HA

Buenas,

Muchos de los que trabajamos en este mundo “IT” vivimos la disponibilidad de las comunicaciones y el acceso remoto como si fuera la misma sangre que corre por nuestra galaxia digital. Al fin y al cabo, si tienes que gestionar, dar soporte o comprobar N^M clientes, no te puedes permitir no tener acceso 😉

Así que un buen día nos dió por diseñar lo que llamamos el acceso remoto tolerante a las contingencias de red y bloqueos no controlados habituales. Obviamente, no nos referimos a poner IODINE en producción (jiji, todavía no estamos tan asilvestrados). Se trata más bien de un poco de taller de networking alternativo, fuera de los usos normales, pero ilustrando igualmente ciertos conceptos aplicables que pueden resultar interesantes. Así que, básicamente: ¿Por qué? Por que nos gusta 🙂

De hecho, en una galaxia lejana, muy lejana, por el año 2005, curioseábamos ya con este tipo de mecanismos 😉

Como siempre: Show me a diagram, please, ASAP! así que aquí va lo que hemos montado en este mini laboratorio:

post_vpnbulletproof_esquemageneral

 

De base, lo que nos planteamos como objetivos son:

  1. Obviamente, poder acceder siempre al host.
  2. Que no se pierda la conexión si falla uno de los túneles y tiene que conmutar [!].
  3. Siempre que se pueda, por el túnel UDP en primer lugar, que es lo mas indicado y si este no está disponible por el túnel TCP443 y como última opción el túnel DNS.

Para el primer punto, está claro que lo que tenemos que hacer es publicar a nivel de routing una interfaz virtual / o de loopback, en los mundos de GNU/Linux: dummy network interface. Para el segundo y tercer punto, está claro que tenemos que optar por un protocolo de routing dinámico que anuncie por cada uno de los túneles la IP que estamos queriendo acceder, pero con diferentes pesos, métricas/distancias.

Por tanto, nuestros ingredientes para construir el bunker de comunicaciones:

Y en cuanto a tecnologías:

Y para montar todo esto, obviamente, nos ha hecho falta una máquina virtual tras NAT, y el respectivo terminador de túneles.

 Primer paso: Definiendo el direccionamiento

En nuestro proyecto, aunque no sea para nada productivo, tb hay que definir el direccionamiento 😉 así que este es el planteamiento, así se entenderán mejor luego las rutas y tal:

  • Interfaces de Loopback. El servidor será 10.131.131.1/32 en su dummy0, y el cliente-agente 10.132.132.2/32, lo mismo, en su dummy0.
  • Túnel UDP: Será de tipo tun, ptp tal que: servidor 10.141.141.1 y cliente 10.141.141.2
  • Túnel TCP443: Lo mismo, tipo tun, ptp y tal que: servidor 10.142.142.1 y cliente 10.142.142.2
  • Túnel DNS: Aquí IODINE no nos permite tun ptp, así que usamos el rango: 10.55.55.0/24

 

Túnel 1/3: Lanzando el túnel sencillo (UDP, PSK)

Este el túnel mas sencillo, por supuesto, tiraremos de OpenVPN, y en este caso con PSK, sin infraestructura PKI ni nada complejo.

Antes de nada, generamos clave PSK tal que:

La configuración en el lado servidor:

y lo arrancamos y verificamos tal que:

La configuración en el lado cliente es igualmente mínima:

Una vez lo levantamos, verificamos que pingamos bien extremo a extremo:

y el ping fluyendo:

 

Túnel 2/3: Lanzando el túnel TCP vía HTTP Proxy

Una vez más, para este tipo de túnel optamos por OpenVPN, ya que soporta perfectamente TCP y la utilización de un proxy (vía método standard CONNECT, permitido normalmente cuando el puerto destino es HTTPS(443)).

Utilizaremos la misma clave PSK del túnel UDP (túnel1). Tendríamos por tanto en el lado servidor:

Y en el lado cliente, recordemos que habíamos comentado de hacerlo a través de un Proxy (con lo que hemos desplegado un micro squid para simularlo):

Una vez levantado, el ping funciona correctamente:

 

Túnel 3/3: Tunelizando por DNS con IODINE

De IODINE se ha hablado mucho siempre, sobre todo cuando se trata de portales de acceso tipo hot-spot en redes wireless y simialres, la documentación de la página oficial la verdad es que es muy clara, así que simplemente nos limitaremos a comentar por encima

Como primer paso, tenemos que tener un dominio o subdominio, nosotros hemos optado por: warriors.irontec.com, que hemos dado de alta ya y apuntado correctamente su registro de nameserver tal que:

Para el tema del payload y rendimiento, cuanto mas corto sea el subdominio mejor.

En el server 88.xx.xx.xx arrancamos el servicio IODINE, con password ‘test’ de prueba:

y comprobamos:

 

Ahora solo nos falta arrancar el cliente IODINE en el lado del agente vpn, tan sencillo como:

Nota: Hay que reemplazar 10.X.X.X por la IP del DNS local que tengamos.

Como veis, en este ejemplo hemos optado por usar la opción -r, porque sino IODINE es muy listo y envía directamente el tráfico, y no estaríamos en un entorno realmente capado 🙂

y por último, comprobar, en primer lugar que tenemos el interface dns0 levantado y la ruta configurado:

y lo mas evidente, que tenemos ping:

¡Bingo! Tenemos ya un agente desplegado que tiene los 3 métodos de comunicación levantados y operativos 🙂

Orquestando las rutas con Quagga y BGPD

Quagga es algo que usamos mucho por aquí y nos encanta, así que antes o después acabaremos hablando en detalle.

En este caso, comentaremos simplemente que hemos optado por eBGP, podríamos haber utilizado otro protocolo de routing dinámico, pero este el que mas nos convence, nos gusta mucho el concepto de session y los temas de local preference y weight, así que this is our choice 😉 Dicho esto:

  • Servidor: Será el AS 65001
  • Cliente/Agente: Será el AS 65002

Con, esto tras instalar quagga y habilitar el daemon bgp en daemons.conf, la configuración nos queda tal que:

Cliente:

De esto, lo que nos interesa comentar es el tema de usar weights diferentes, para poder permitir la elección del mejor camino.

Servidor, es muy parecido tb:

 

Y ahora, hay que verificarlo, con un clásico show ip bgp obtenemos en el cliente:

Se puede observar la marca > de la selección, en este caso via 10.141.141.1, que es el túnel UDP 🙂

Y dicho esto, si lo comprobamos de base:

Está funcionando, el cliente pinga desde su interfaz loopback al servidor, a su interfaz loopback tb 🙂

¿Pero que sucede si por ejemplo bloqueamos el tráfico saliente UDP 1194  de tal forma que la VPN UDP no puede establecerse?

Para probarlo, en el servidor por ejemplo:

y al de poco tiempo (BGP Hold Time y tal), podemos ver que ahora la ruta ha cambiado sola mágicamente 😉

¿No es esto cool total? 🙂 Por aquí se ha comentado incluso de aplicar técnicas de MCTL: Missed Calls Transport Layer 😉

Bromas a parte, nos hemos permitido orientar este post desde el punto de vista algo alternativo y diferente, pero los conceptos de routing dinámico y tunneling como podéis sospechar son perfectamente válidos para otros escenarios, que esperemos en breve poder comentarlos desde perspectivas más globales.

 



¿Te gusta este post? Es solo un ejemplo de cómo podemos ayudar a tu empresa...
Sobre Gorka Gorrotxategi

CTO en Irontec, en el frente técnico desde un par de lustros ya, para todo lo que tenga que ver con Networking, VoIP y Sistemas, en ese orden :D) Desde @zetagor escribo algo, pero poco verbose la verdad

Queremos tu opinión :)