Aventuras con BGP.

Cuanto tiempo!  Algunos me han preguntado que si ya no planeaba escribir más en el blog (no muchos, pero si me han preguntado.).

Por cuestiones de trabajo, poco a poco fui descuidando el blog a un punto que ahora veo que se han perdido imágenes de algunas entradas, eso me pasa por usar Dropbox como proveedor de contenidos. Eso es algo que puedo arreglar más adelante, ahora al tema de la entrada.

A mediados de 2016 pude notar que viarios participantes de dn42 estaban usando ASN públicos asignados por ARIN, que chulo no? así que comencé a investigar y termine adquiriendo un Numero Autónomo público. Para que se preguntaran algunos, la respuesta es que desde hace mucho tiempo tengo una adicción al routing a un nivel que en mi pequeña red de la casa estoy corriendo BGP + OSPF para distribuir las rutas internamente.

Después de varios meses de jugar con el ASN y cambiar todos los Debian + Quagga que tenían ASN privado (64635 – 64714) al nuevo y reluciente ASN público (207036), comenzar a anunciar asignaciones de IPv6 (ya casi todo esta dual-stack, yija!!!!), termine con una asignación /22 de IPv4.

Entonces, como esta aaNetworks al día de hoy con relación a networking?

https://aanetworks.org/

 

 

 

 

 

 

 

 

Se puede conseguir más información en BGP.he.net

http://bgp.he.net/AS207036

Usando pfBlockerNG en pfSense 2.2.2

pfSense es el firewall OpenSource favorito para mí, desde mucho tiempo lo he usado dentro de mi red casera y de tal manera lo he usado en lugares donde he trabajado.

Una de las ventajas de este firewall son sus plugins que nos ayudan a adicionar funcionalidades, pfBlockerNG es uno de ellos y este nos trae funcionalidades de bloqueo de direcciones IP de países y la creación de Alias basados en listas públicas o listas creadas por uno mismo, en mi caso he creado una lista personalizada con todas las direcciones asignadas por LACNIC a República Dominicana.

Para entender cómo funciona pfBlockerNG he usado una guía publicada en Security Artwork (Bloqueando tráfico con pfBlockerNG). Luego utilizando un poco de bash scripting he creado un pequeño script que descarga la lista oficial de LACNIC, la filtra buscando .DO y luego crea un archivo de TXT con el formato necesario para que pfBlockerNG pueda hacer uso de él.

Este alias lo uso para varias configuraciones en mi red local, como por ejemplo no hacer uso de la VPN creada usando PIA y que todo tráfico “local” sea enviado sin encriptar.

Posiblemente para otros esto no tengan ninguna utilidad pero a mí me pareció bien poder tener una excepción y no enviar ese tráfico vía VPN.

http://aanetworks.org/iprange/

FreeLoadBalancer.org – Kemp LoadMaster para el HomeLab.

KEMP es un proveedor de soluciones para alta disponibilidad y balanceo de carga (LoadMaster), mi primer contacto con el producto fue buscando una solución tipo empresarial para reemplazar Ngnix y/o Apache (mod_proxy). Uno de los primeros escenarios donde leí sobre el despliegue de las soluciones de LoadMaster (LVM100 para ser exacto) fue con vSphere Web Client y Exchange Server.

Cuando fue mi turno de desplegar LoadMaster lo hice usando ESXi como plataforma y en ese momento use dos servidores físicos cada uno con una VM de LoadMaster.

Para ese momento KEMP no tenía una versión gratuita como lo hace ahora y por esta razón no podía jugar con la solución en el homelab, ahora todo cambia, hace varios días KEMP anuncio la versión gratuita que tanto he esperado e inmediatamente un VLM y estoy probando como configurar la plataforma y reemplazar un ZenLoadBalancer que tengo corriendo desde hace un tiempo y es el usado para publicar muchos de los servicios que uso de prueba o uso personal.

La configuración tradicional de un LoadMaster es para tener alta disponibilidad de un aplicativo web, digamos un Lync, Exchange o VMware Horizon View. En mi caso la idea de usar LoadMaster (como lo ha sido con ZenLoadBalancer) es poder publicar todo lo que necesite ya sea HTTP(80) o HTTPS(443) usando una única dirección IP (o varias si es necesario). Me gustaría aclarar que la solución ZenLoadBalancer no me ha fallado y ha cubierto la necesidad que tenía, entonces porque cambiarlo?

La decisión podría decirse que es personal ya que pienso, es más probable que termine administrando un LoadMaster a que me encuentre o que decida instalar ZenLoadBalancer en un ambiente empresarial.

Las funcionalidades, si miramos en http://freeloadbalancer.com. Podemos ver que la versión gratuita nos trae Layer4-7 Load Balancer, Reverse Proxy, Edge Security, WAF (Web Application Firewall) y GSLB (Global Server Load Balanceing), para ser versión gratuita tiene buena pinta, la única funcionalidad que podría hacer falta es HA pero como esto esta apuntado a pequeñas empresas o homelab como es mi caso puede que sea la razón de que no esté disponible HA.

Para más información de las diferencias se puede ver directamente en http://freeloadbalancer.com

La razón de este post es tratar de documentar los pasos y configuraciones que necesite para poder usar LoadMaster como un Reverse Proxy que es actualmente como uso ZenLoadMaster en mi homelab, una diferencia que aplica en mi homelab es que dos de los host ESXi están en un datacenter a unas cuantas miles de millas de mi localidad y me conecto con ellos a través de una VPN tipo mesh (Tinc VPN). Para LoadMaster los Real Servers no están en la misma subred e inicialmente falla al ser agregados en los Virtual Servers si no hacemos los cambios necesarios, esto podría aplicar si los VirtualServers están en 192.168.100.0/24, los RealServers están en 192.168.200.0/24 y el LoadMaster está en modo One-ARM.

Aquí un pequeño diagrama de red donde se ve un VLM en un lado de la red:

Lo primero que debemos hacer es definir algunos Content Rules.

 

 

En mi caso quedo algo asi:

Aquí se puede ver mientras modifico una regla llamada guacamole:

Procedemos a agregar un Virtual Server, en mi configuración inicialmente tendré un Virtual Server para el puerto 80 y otro para el puerto 443.

En Advanced Properties habilitamos Content Switching.

Ahora toca crear los SubVS que queramos o necesitemos. Actualmente solo tengo 2 en la parte de HTTP:

Como se puede ver en la imagen anterior, ya estos 2 SubVS tienen Content Rules habilitadas y seleccionadas, si hacemos click en el numero podremos remover o agregar otro Content Rule.

Con relación a los Real Servers, estos serán agregados en cada SubVSs, cuando usamos Content Rule los Real Servers podrían ser el mismo ya que el Content Rule se encargaría de definir el Host Header y re-direccionar el tráfico a donde sea necesario.

Lo importante es tener en cuenta los Content Rule, allí es donde decidiremos cuales dominios serían los aceptados, esto es parecido a los Virtual Name de Apache.

Otra configuración que tuve que aplicar en mi caso fue habilitar fue la de Eable Non-Local Real Servers que se encuentra en System Configuration > Miscellaneous Options > Network Options., además de esto los Virtual Servers no pueden tener habilitado Transparency.

Aquí la documentación oficial -> https://support.kemptechnologies.com/hc/en-us/articles/201849033-How-do-I-add-remote-Real-Servers

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.

Conectividad… Si, ESXi loves Gigabit Networking.

1G es uno de los requerimientos más obvios en una infraestructura de ESXi (vSphere!), la última vez que intente activar vMotion en una tarjeta de red sincronizada a 100M me presento un hermoso warning donde decía que el mínimo es 1G. Últimamente este no es un problema ya que las nuevas tendencias son de 10G y más, si más!

Un tema diferente es el HomeLAB. Los switches Gigabit dependiendo el modelo son caros y si lo conseguimos a un precio moderado entonces nos sale cara la factura de la luz y no podemos estar cerca de ellos por lo ruidoso que son. Desde hace un tiempo estoy usando hardware de Mikrotik (link) para routing y cosas relacionadas a OSPF & BGP (hasta MPLS se puede probar en estos aparaticos!), aunque desde hace tiempo el fuerte de ellos es el routing decidieron lanzar producto para conectividad LAN (me refiero a un switch).

El primer modelo que lanzaron fue el RB250GS (http://routerboard.com/RB250GS) que parece no fue tan popular (problemas?). El sucesor de este es el RB260GS (http://routerboard.com/RB260GS) que agrego un puerto SFP.

Pros: Baratos, bajo consumo.

Cons: El software, solo 5 puertos.

Aunque nunca he usado uno de estos equipos la diferencia con cualquier otro producto de Mikrotik es el software que viene con él, para este equipo MT desarrollo una nueva plataforma llamada SwOS la cual parece que no tuvo aceptación y apunta a que fue abandonada en favor del ya establecido RouterOS.

Además de lanzar 2 equipos dedicados a Switching, Mikrotik también cuenta con una línea de bajo costo. Los RB2011 (http://routerboard.com/RB2011iL-IN), estos cuentan con 10 puertos de conectividad donde 5 son 100M y otros 5 son Gigabit. Es una buena alternativa a los RB250 0 RB260 con SwOS.

Las opciones anteriores tienen ya un tiempo en el mercado, pero ahora Mikrotik ha lanzada una nueva plataforma llamada CRS (Cloud Core Switch) y estos Switches cuentan con 24 puertos Gigabit. Suena excelente para un HomeLAB y además el precio es bastante asequible.

Estoy pensando seriamente cambiar mi Cisco Catalyst 2960G por un CRS125-24G-1S-RM (http://routerboard.com/CRS125-24G-1S-RM).