RPKI con GoRTR de Cloudflare – en Kubernetes!

RPKI con GoRTR de Cloudflare – en Kubernetes !

Hace un tiempo probé con RPKI, en esos días estaba tomando unos entrenamientos de MANRS, con RPKI podemos asegurar que los prefijos que recibimos vía BGP con de quien realmente deberían ser, en otras palabras, si por alguna razón un tercero mal intencionado se hace con un bloque de direcciones IP que no le pertenece, pero esta tiene ROA habilitado, el trabajo de RPKI es no permitir que esos bloques de direcciones IP sean insertados en nuestra tabla de enrutamiento.

https://github.com/cloudflare/gortr

Continuar leyendo «RPKI con GoRTR de Cloudflare – en Kubernetes!»

RIPE Atlas – Estado actual en República Dominicana.

RIPE Atlas – Estado actual en República Dominicana.

Para los que no saben que es RIPE Atlas, es un Proyecto de RIPE NCC, su meta es colectar información de las conexiones a Internet usando un pequeño “probe” que se coloca en la red de un usuario, empresa o proveedor de Internet. Luego este probe realiza pruebas predefinidas para colectar valores como latencia, jitter y hasta pruebas de puertos, probar si DNS está respondiendo en servidores específicos.

No es un proyecto nuevo, los primeros registros se iniciaron en el 2010. Desde entonces existen países que han recibido esto como una herramienta para mejorar, pero lamentablemente otros no lo han hecho de esa manera debido al poco apoyo recibido. Tomaremos como ejemplo Republica Dominicana.

En nuestro país actualmente tenemos registrados 49 probes de los cuales solo 15 están conectados hoy [20/10/2019]. Si miramos detenidamente podremos ver que el primer probe en DO se conecto a la red de Atlas hace 4 años y 17 días y tiene 2 años desconectado.

¿Por qué pasa esto?

Mi opinión es que luego de recibir este pequeño aparato y conectarlo a la red, el usuario no siente que esta obteniendo un beneficio y en cualquier momento decide desconectarlo porque ya entiende que no lo necesita, lamentablemente esto también pasa en empresas, si miramos la lista de probes abandonados ahí muchos que al parecer fueron registrados por una empresa o proveedor y sufrieron la misma suerte.

¿Como podemos mejorar esto?

Tenemos que comprometernos a mejorar la infraestructura de Internet, hasta el menor esfuerzo como es hospedar un probe de RIPE Atlas aporta a mejorar Internet ya que permite que instituciones con áreas dedicadas al desarrollo usen esta plataforma para realizar pruebas de conectividad y entender mejor como cambian las redes de interconexión a través de los años.

¿Qué puedo hacer luego de tener un Probe?

Con RIPE Atlas tenemos que cumplir una condición para poder hacer uso de la plataforma, tenemos que acumular créditos, estos créditos se pueden conseguir dejando nuestro probe encendido y conectado a la red para que genere crédito a nuestro favor o recibiendo una donación de otro usuario. Luego que contamos con créditos podemos crear nuestras propias métricas.

Por ejemplo, hace un tiempo cree una métrica para medir la latencia desde Republica Dominicana a los DNS Resolver de CloudFlare.

En esta conjuración solicite 20 probes, todos de Republica Dominicana, actualmente están participando solo 9.

En la pestana de Latest Results podemos ver los últimos resultados de esta métrica.

En esta pestaña podemos apreciar la cantidad de RTT y HOPs utilizados por el probe para alcanzar a 1.0.0.1 que es uno de los DNS Open Resolver de CF. Lamentablemente uno de los probe está fuera de línea.

Otra pestaña de la cual podemos sacar ventaja es Tracemon.

Esta nos entrega un mapa con los saltos que hicieron los probe para llegar a su destino final, en cada punto podemos ver IP utilizada y ASN al cual pertenece esa IP.

Esto que acabo de mostrar aquí son de las configuraciones mas sencillas que se pueden crear en la plataforma, no soy ningún experto, pero sigo intentando sacarle partido a RIPE Atlas. Actualmente tengo dos probes corriendo, uno con mi ASN ( AS207036 ) y otro detrás del ASN de CLARO.

Para cerrar, si estas interesado en hospedar un probe de manera seria y con compromiso de tenerlo conectado, contáctame, actualmente estoy registrado como Embassador en Republica Dominicana, esto quiere decir que puedo asignar probes de algunos que tengo disponible.

OpenWRT en aaNetworks – BGP, Anycast DNS & OpenDNS.

OpenWRT puede ser que no necesite introducción pero aquí va, OpenWRT es un pequeño Linux que se instala en muchos dispositivos embeded. Después de muchos años siendo usuario de m0n0wall luego pfSense y por ultimo Vyatta, decidí usar este pequeño amiguito por el hardware que tengo disponible en este momento, tengo 2 Soekris, uno es 4801 y otro es 4501, ambos productos son bastante viejos.

La instalación en x86 (plataforma de Soekris) fue muy sencilla, estos son los pasos:

  1. descargar http://downloads.openwrt.org/attitude_adjustment/12.09/x86/generic/openwrt-x86-generic-combined-ext4.img.gz
  2. Usando 7-Zip extraer el archivo .img
  3. Usando dd en Linux o WinImage en Windows enviamos la imagen a nuestro CF.
  4. Nos aseguramos de tener la velocidad correcta en el Soekris, esta debe ser igual que la implementada por defecto en OpenWRT (38400).

En este punto deberíamos tener un OpenWRT listo para trabajar con él.

El Soekris 4801 (ELZAR) y el 4501 (WERNSTROM) forman parte de una Mesh VPN usando Tinc. Gracias a esto tengo varias localidades interconectadas vía VPN con poco mantenimiento requerido para funcionar.

En este post me centrare en como he hecho para tener filtro de DNS y Anycast DNS. Anycast es algo que no se ve en una red casera pero mi red desde hace tiempo dejo de ser normal. OpenWRT cuenta con un package manager (opkg) que nos permitirá instalar software para conseguir las funcionalidades que deseamos en nuestro OpemWRT. Lo primero, claro, es tener nuestro OpenWRT funcionando y con el NAT deshabilitado (ese es el caso en mi red), instalaremos  BGP (Quagga) y reconfiguraremos DNSmasq.

Instalando los paquetes.

Quagga es la suite que usaremos para tener BGP (OSPF lo uso para redistribuir rutas a mi Vyatta), esto nos ahorrara trabajo (tengo otros nodos con Quagga) ya que solo tendré que copiar parte de la configuración, cambiar ASN, router ID y otras mínimas líneas de la config.

opkg update

Estos son los paquetes instalados actualmente en ELZAR.

  • quagga
  • quagga-bgpd
  • quagga-libospf
  • quagga-libzebra
  • quagga-ospf6d
  • quagga-ospfd
  • quagga-vtysh
  • quagga-watchquagga
  • quagga-zebra

Ahora toca configurar e iniciar los servicios para tener BGP funcionando. La instalación es por defecto, esto quiere decir que tendremos /etc/quagga donde pondremos los archivos de configuración que se requieren.

Para que BGP (módulo de Quagga) funcione necesitamos tener configurado zebra.conf y bgpd.conf.

Configuración básica de estos archivos.

zebra.conf :

  • hostname -zebra
  • password MiSuperPassword
  • service advanced-vty
  • !
  • line vty
  • access-class vty
  • !

bgpd.conf :

  • hostname -bgpd
  • password MiSuperPassword
  • service advanced-vty
  • !
  • access-list vty permit 127.0.0.0/8
  • access-list vty deny any
  • !
  • line vty
  • access-class vty
  • exec-timeout 0 0
  • !

Con esto podemos iniciar el servicio de Quagga usando /etc/init.d/quagga start, ya tendremos el servicio de BGP funcionando pero aun no es suficiente para que OpenWRT cumpla con la tarea asignada, ahora toca configurar BGP conectándonos a la consola que está disponible en el puerto 2605 (telnet localhost bgpd) y nos pedirá el password que usamos en la configuración base (MiSuperPassword en este ejemplo). Una vez dentro configuraremos nuestro número autónomo, las subredes que anunciaremos desde este router y los vecinos a quienes estaremos anunciando estas subredes.

Esta es la configuración en ELZAR (un poco editada).

  • Current configuration:
  • !
  • hostname elzar-bgpd
  • password MiSuperPassword
  • service advanced-vty
  • !
  • router bgp 64845
  • bgp router-id 10.45.254.9
  • network 10.45.254.9/32
  • network 10.45.255.1/32

Toda la configuración después de estas líneas es relacionada a los vecinos (neighbors) con los cuales el servicio de BGP intercambia rutas.

Internamente son 3 router con BGP que usar el ASN 64845 y están agrupados así:

  • neighbor aaNetworksHQ peer-group
  • neighbor aaNetworksHQ remote-as 64845
  • neighbor aaNetworksHQ override-capability
  • neighbor aaNetworksHQ next-hop-self
  • neighbor aaNetworksHQ soft-reconfiguration inbound

De esta manera solo necesito hacer lo siguiente para establecer relación entre 2 routers con el mismo ASN:

  • neighbor 10.45.252.10 peer-group aaNetworksHQ
  • neighbor 10.45.252.10 update-source 10.45.252.9
  • neighbor 10.45.252.14 peer-group aaNetworksHQ
  • neighbor 10.45.252.14 update-source 10.45.252.13

El router 10.45.252.10 es otro OpenWRT (wernstrom) el cual también funciona como Anycast DNS en mi red local, el router con 10.45.252.14 es un Vyatta que funciona como router para Internet y es quien agrupa todas las rutas que se puede distribuir hacia el OSPF internamente.

Al final terminamos con algo así:

  • router bgp 64845
  • bgp router-id 10.45.254.9
  • network 10.45.254.9/32
  • network 10.45.255.1/32
  • neighbor aaNetworks peer-group
  • neighbor aaNetworks remote-as 64635
  • neighbor aaNetworks update-source aanet
  • neighbor aaNetworks override-capability
  • neighbor aaNetworks soft-reconfiguration inbound
  • neighbor 10.45.252.10 peer-group aaNetworksHQ
  • neighbor 10.45.252.10 update-source 10.45.252.9
  • neighbor 10.45.252.14 peer-group aaNetworksHQ
  • neighbor 10.45.252.14 update-source 10.45.252.13

Ya tenemos a ELZAR conectado (Interfaces dedicadas hacia los demás routers) a sus vecinos e intercambiando rutas, Excelente!.

La idea es que ELZAR y WERNSTROM publiquen la dirección 10.45.255.1 y a su vez estén corriendo DNSmasq que por defecto viene instalado en OpenWRT. Antes de seguir, aquí dejo un pequeño diagrama de red para que se pueda entender la idea.

Otra configuración que debemos realizar es en zebra.conf, allí crearemos las interfaces donde tendremos las direcciones IP con /32, estas son la loopback (usada en router id & la IP para Anycast).

La configuración en ELZAR es la siguiente:

  • Current configuration:
  • !
  • hostname elzar-zebra
  • password MiSuperPassword
  • service advanced-vty
  • !
  • interface aanet
  • ipv6 nd suppress-ra
  • !
  • interface eth0
  • description «testing»
  • ipv6 address 2001:470:b24c:f021::1/126
  • ipv6 nd suppress-ra
  • !
  • interface eth1
  • ipv6 address 2001:470:b24c:ff22::2/126
  • ipv6 nd suppress-ra
  • !
  • interface eth2
  • ipv6 address 2001:470:b24c:dead::9/64
  • ipv6 nd suppress-ra
  • !
  • interface lo
  • ip address 10.45.254.9/32
  • ipv6 address 2001:470:b24c:254::9/128
  • ip address 10.45.255.1/32
  • !
  • access-list vty permit 127.0.0.0/8
  • access-list vty deny any
  • !
  • ip forwarding
  • ipv6 forwarding
  • !
  • !
  • line vty
  • access-class vty
  • !
  • End

Aquí se pueden ver las 2 direcciones IP.

En este momento las direcciones de loopback y la usada para Anycast son visibles en los demás routers de mi red.

Configurando DNSmasq al estilo OpenWRT.

OpenWRT tiene su método de configuración, aunque la mayoría de los paquetes instalables se pueden configurar vía su propio método, algunas veces es mejor hacerlo así.

DNSmasq es configurado desde /etc/config específicamente en el archivo dhcpd.

Luego procedemos a editar el dnsmasq.conf ubicado en /etc, aquí podemos realizar configuración de la forma oficial y soportada por el proyecto de dnsmasq. La configuración es muy extensa pero lo más importante y relacionado con esta entrada es:

  • listen-address=10.45.255.1
  • #Send most DNS lookups to opendns.com
  • server=208.67.222.222
  • server=208.67.220.220
  • #aaNetworks request to internal servers
  • server=/aanetworks.org/172.22.35.66
  • #server=/aanetworks.org/10.45.254.7
  • server=/172.in-addr.arpa/172.22.35.66
  • server=/10.in-addr.arpa/172.22.35.66
  • server=/aanetworks.local/172.22.35.50
  • server=/aanetworks.local/172.22.35.100

No me gusta que OpenDNS me responda bogus-nxdomain así que agregamos lo siguiente:

  • #blocked opendns.com bogus-nx
  • bogus-nxdomain=67.215.65.130
  • bogus-nxdomain=67.215.65.132
  • bogus-nxdomain=208.67.222.222
  • bogus-nxdomain=208.67.220.220

Reiniciamos DNSmasq para probar que nuestro IP para Anycast DNS sea utilizado como IP preferido para escuchar en los puertos de DNS.

Desde un cliente de la red, con una dirección de 172.22.35.0/26 esto es lo que tenemos cuando hacemos un dnslookup.

También un traceroute desde el mismo cliente que se realizó el nslookup.