DNS y las IP anycast: ¿para que sirven?

jogofus
17 abr
4 Min. de lectura

Hace cosa de una semana, escribí en mi LinkedIn que, a raíz de lo que estaba pasando con los bloqueos indiscriminados de Cloudflare por parte de LaLiga, me propuse, a modo de reto (por eso de no saber quedarme quieto) montar una especie de CDN. Algo sencillo, pero funcional. Y sobretodo, con herramientas opensource.

Como digo, es que no me gusta estar quieto, y es una forma de demostrarme a mí mismo que este tipo de cosas no está reservada a unas cuantas corporaciones con mentes súper brillantes.

Para empezar con esta andadura, quería hacerlo con algo básico: el servicio DNS y que éste redirija a una web u otra según su localización.

De esto hablaré en otra entrada, pero básicamente es un servicio DNS que consulta a una BBDD en la que puede ver a qué país pertenece la IP que hace la petición y, según cual sea, redirige a un servidor u otro.

-¿Y si solo tienes un servidor DNS y está en Madrid y las consultas se hacen desde USA? ¿No seguirá habiendo un retraso en las peticiones?

+Exacto. Y de eso va esta entrada hoy. Vamos a tener varios servidores DNS repartidos y responderá el más cercano.

Interfaces loopback: necesarias para este propósito

Lo primero que tenemos que tener claro es qué es una interfaz loopback.

Una interfaz loopback es una interfaz virtual que, generalmente, se utiliza para enviarse datos a sí mismo a través del stack TCP/IP del kernel.

Todos conocemos la famosa IP 127.0.0.1. Pues bien, esta IP no es la única que se le puede asignar a la interfaz loopback, ya que su máscara de red es /8.

Que levante la mano quien no ha hecho un ping 127.0.0.1 para comprobar si tenía el ping habilitado.

Esta interfaz no está asociada a ninguna interfaz física, por lo que siempre estará UP, aunque no haya ningún cable físicamente conectado o hayamos hecho un shutdown de las interfaces físicas.

En linux, está representada por el nombre lo y se vería algo así:

Direcciones IP anycast

Tal y como dice Cloudflare en su página web:

Anycast es un método de direccionamiento y enrutamiento de red en el que las solicitudes entrantes se pueden dirigir a una variedad de ubicaciones o "nodos" diferentes. En el contexto de una CDN, Anycast suele dirigir el tráfico entrante al centro de datos más cercano

Cuando una interfaz loopback es utilizada para direccionamiento anycast, los routers pueden seguir anunciando estas direcciones sin verse afectados por un mal funcionamiento de hardware.

Además, como añadido, al ser el servidor más cercano el que responde, nos ayudará a mitigar un ataque DDoS.

Como sabéis, los ataques DDoS son ataques dirigidos hacia un servicio concreto desde IP de todo el mundo. Al poder redirigir según la ubicación, no se satura un único servidor, sino que se reparte la carga entre todos los que componen la red anycast.

La dirección IP anycast debe ser la misma en todos los equipos que queramos que participen.

¿Y como distribuimos esa red anycast? Mediante un protocolo de enrutamiento. Generalmente se usa BGP, pero como se trata de un entorno de pruebas yo lo he hecho con OSPF.

Como ya hablé en otra entrada de este blog exclusivamente de OSPF, es un protocolo de enrutamiento basado en el estado de enlace. Además, usa el algoritmos de Dijkstra para calcular la ruta más corta. Exactamente esto es lo que necesitamos para poder hacer funcionar la red anycast.

Interfaces dummy en Linux

Para poder hacer el laboratorio, necesitaremos asignar una IP en una interfaz loopback. Generalmente se desaconseja hacerlo directamente en la interfaz lo del servidor, por lo que crearemos una interfaz loopback con el módulo del kernel dummy.

modprobe dummy
ip link add lo0 type dummy
ip addr add 172.16.10.10/32 dev lo0
ip link set lo0 up

Una vez hecho esto, ya tenemos creada nuestra interfaz loopback. Esto lo he hecho en los dos servidores que van a hacer de servidor DNS.

Configuración OSPF

En todos los routers que pertenecen a la red, crearemos un area 0 para OSPF y anunciaremos las rutas mediante este metodo.

En la práctica, el propio servidor DNS también debería estar dentro del protocolo de enrutamiento dinámico para evitar caídas. En este laboratorio se ha hecho mediante rutas estáticas.

Se hace la configuración básica con las interfaces de red y configuramos OSPF.

Ejemplo de configuración de uno de los routers:

router ospf 1
 redistribute static subnets
 network 10.10.40.0 0.0.0.255 area 0
 network 10.10.30.0 0.0.0.255 area 0
 network 192.168.0.0 0.0.0.255 area 0
!

Con la primera linea nos aseguramos que las rutas estáticas también se anuncian a través de OSPF.

Configuración de ruta estática al servidor DNS:

ip route 172.16.10.10 255.255.255.255 192.168.0.10 10 permanent

Comprobamos que se han propagado las rutas:

Configuración DNS

Para hacer más sencillo el laboratorio, vamos a añadir en /etc/hosts la dirección IP y el dominio al que queremos acceder, de tal forma que quedaría así:

172.16.10.10	pruebas.test

Si nos conectamos via web desde los clientes, recibiremos distintas web:

Cliente1:

Cliente2:

Pero si apagamos una de las interfaces en un router, responderá el otro servidor DNS. En este caso, apago la interfaz e0/0 del router R7, por lo que está más próximo el servidor DNS1. Lo comprobamos:

¡Espero que os haya gustado!

Y para finalizar...

Me gustaría dedicar estas líneas para poder ayudar en una causa necesaria. Estamos recaudando fondos para ayudar a, Ellie una niña de 8 años con TEA, que necesita un perro de asistencia de la Asociación DogPoint.

Podéis colaborar dede el siguiente enlace: https://www.migranodearena.org/reto/un-amigo-para-ellie

Además, os podéis desgravar el 80% de lo que aportéis.

Animaos y colaborad por una buena causa.