Networking – Página 6 – ariel's weblog

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:

descargar http://downloads.openwrt.org/attitude_adjustment/12.09/x86/generic/openwrt-x86-generic-combined-ext4.img.gz
Usando 7-Zip extraer el archivo .img
Usando dd en Linux o WinImage en Windows enviamos la imagen a nuestro CF.
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).

KEMP LoadMaster Virtual – Graficas en Cacti.

Hace varios meses que estoy administrando un cluster HA de KEMP LoadMaster, hasta el momento estoy fascinado con la solución. Anteriormente había leído sobre ella, algunos videos en YouTube y uno que otro blog en la red.

Inicialmente solo era un solo LoadMaster (VLM) en un servidor dedicado Dell PowerEdge R420 con VMware ESXi 5.1 GA.

Todo de maravilla hasta que llegó el momento de agregarlo en Cacti, resulta que solo encontré 1 template para crear graficas de VS (Virtual Servers) y estaba algo “broken”, como todo programmer-wannabe empecé a cambiar cosas aquí y allá en el template y termine con algo funcional.

Por el momento tengo estadísticas de Active Connection & Total Connection tanto en HTTP como en HTTPS.

Descarga: https://www.dropbox.com/s/z2xgdvmhac1mr51/KEMP.rar

Site-to-Site con Vyatta y OpenVPN en Debian.

Hoy toca uno de Networking, como el titulo lo dice, esto no es solo de Virtualización!

Si como yo tienes varias localidades (nah!! Son varios servidores Dedicados con VMs las cuales uso para pruebas) y las quieres administrar directamente como si estuvieran conectadas en una red corporativa y sin problemas de port-forwarding, aquí tengo “una solución” para eso.

Desde hace un tiempo no uso pfSense, por qué? No me gusta OpenBGPd. Es algo lento en pfSense, esa es mi impresión. Además de eso, no creo que soportara una tabla full de BGP, en Vyatta actualmente en mi lugar de trabajo la tenemos en 2 servidores con Vyatta desde nuestro proveedor CLARO.

Bueno, lo de BGP será para otro post, ahora mismo para conectar nuestra localidad remota necesitaremos de un router que soporte OpenVPN en ambos lados, en mi casa tengo Vyatta y en el punto remoto un servidor Debian con OpenVPN instalado desde los paquetes. Necesitaremos los siguientes datos:

Red para el túnel: 10.45.252.252/30

Red en mi casa: 172.22.35.0/26

Red en punto remoto: 172.22.114.0/26

IP WAN en Vyatta-HOME: Dinámico (Gracias al DSL de CLARO)

IP WAN en Debian con OpenVPN: 173.208.168.10

Solo nos falta generar un key con OpenVPN para usarlo en este túnel:

openvpn –genkey –secret static.key

Con estos datos ya podemos configurar…..

En Debian con OpenVPN:

mode p2p          # modo peer to peer

proto udp           # protocolo UDP

lport 1194          # puerto local

dev-type tun     # tipo de interface, TUN porque sera en modo routing.

dev tun-home # nombre de la interface que se vera en ifconfig

tun-ipv6             # queremos IPv6, don’t we?

comp-lzo          # compression

cd /etc/openvpn         # directorio donde tendremos el key generado.

secret static.key        # el archive con el key

persist-key         # si paso algo con el tunel, mantener el key

persist-tun         # si pasa algo con el tunel, mantener la interface

status /var/log/home.openvpn.status.log # LOGs

log-append /var/log/home.openvpn.log   # mas LOGs

keepalive 20 120

verb 5            # Verbose!

ifconfig 10.45.252.253 10.45.252.254

Todo esto lo tendremos en /etc/openvpn en un archivo llamado home.conf, OpenVPN detecta todos los archivos con .conf al final y los ejecuta para crear la interface y todo lo necesario para establecer el túnel.

En el Vyatta:

Aquí es algo diferente ya que los desarrolladores de Vyatta adaptaron OpenVPN a su CLI, si ya ha usado Vyatta, saben lo bien elaborado que esta el CLI.

edit interface openvpn vtun1 #creamos la interface vtun1, no podemos usar nuestros propios nombres aqui.

set local-address 10.45.252.254                #Nuestro lado del tunel

set local-host 10.0.0.2 #IP en la WAN con el DSL de CLARO

set local-port 1194          #no es necesario

set mode site-to-site    #tipo de tunel

set openvpn-options «–com-lzo –persist-tun –tun-ipv6»          #ya que algunas opciones no estan soportadas, existe la opcion de openvpn-options donde podemos usar las que faltan.

set protocol udp              #protocolo a ser usado por el tunel

set remote-address 10.45.252.253          #lado remoto del tunel

set remote-host 173.208.168.10              #IP WAN del servidor con Debian, nuestro Vyatta siempre iniciara la conexion ya que tiene IP Dinamico.

set remote-port 1194    #puerto donde realizaremos la conexión

set shared-secret-key-file          #archivo con el mismo key que usamos en el servidor.

commit

save

nota: no podemos usar comentarios en Vyatta, todo después del # no puede ser introducido en el CLI.

Al momento de hacer commit en Vyatta la configuración se aplica y este iniciara la conexión al servidor con OpenVPN, ahora debemos iniciar el OpenVPN en el servidor con Debian:

/etc/init.d/openvpn start home.conf

Automáticamente nuestro túnel debe subir y podemos hacer ping desde nuestro Vyatta hacia Debian usando la red 10.45.252.252/30.

Desde Vyatta: ping 10.45.252.253

Ahora solo nos faltaría que nuestro Vyatta y Debian sepan que redes maneja cada cual, esto en Vyatta lo podemos hacer así:

set protocol static route 172.22.114.0/26 next-hop 10.45.252.253

En nuestro servidor con Debian:

ip route add 172.22.35.0/26 via 10.45.252.254 dev tun-home

Ya nuestros equipos en ambos lados deben tener conectividad uno al otro usando el túnel.

HomeLAB

Ariel Antigua Networks – (aaNetworks)

aaNetworks

homelab infrastructura.

Iniciemos con el hardware.

networking:

En esta sección tenemos varios routers y switches.

    -   WAN1 – este es el equipo que la mayoría tenemos en casa, es asignado por CLARO para los clientes con Fibra Óptica, mi velocidad de internet actual es 300Mbps/75Mbps.
    -   WAN2 – Internet de Orbit Cable, entregado vía Fibra Óptica. Solo tiene 10Mbps/5Mbps, lamentablemente esta detrás de CGNAT.
    -   firewall01 - Peplink Balance 20X
    -   firewall02 – Sophos XG 115 corriendo opnSense 27
    -   nixon – Mikrotik RB3011-RM – este equipo forma parte de una nube MPLS y es un router de borde.
    -   zapp – Mikrotik RB2011-RM – este es el route principal de la red.
    -   lrrr –   Mikrotik RB493AH – router para pruebas de PPPoE, MPLS y VPLS.
    -   brrr –  Mikrotik RB750Gr3 – router para pruebas de PPPoE, MPLS y VPLS.
    -   ndnd – Mikrotik RB2011L-RM – router para pruebas de PPPoE, MPLS y VPLS.
    -   elzar – Mikrotik RB2011-RM – router para pruebas de PPPoE, MPLS y VPLS.
    -   CORE0 – Zyxel GS-1900 – Switch principal de la red.
    -   CORE02 - Ubiquiti Aggreation - 10Gbe switch for vSAN/vMotion and Data Traffic
    -   Atlas1 – RIPE Atlas sensor (Probe #28779) – este equipo directamente no se controla, es parte del proyecto Atlas de RIPE NCC. (¡¡¡4 anos en funcionamiento !!!)
    -   Atlas2 – RIPE Atlas Sensor (Probe #51981) – este sensor reporta estadísticas usando el internet de CLARO.
    -   Atlas3 – RIPE Atlas Sensor (Probe #XXXXX ) – este sensor reporta estadísticas usando el internet de ORBIT.
    -   Ubiquiti UCK – Generación 1 cloud key.

servers:

Supermicro decomisionado.

    -   Intel(R) Atom(TM) CPU D2500 @ 1.86GHz
    -   6GB de RAM
    -   SSD 60GB Sandisk
    -   2x 1Gb NIC

2x HP Z440

    -   Intel Xeon E5-2640 v4
    -   128GB of DDR4
    -   1 Samsung SSD 970 EVO 1TB
    -   1 Kingston SSD 240G (ESXi installed here)
    -   1 Intel SSD DC S3700 1.6TB
    -   1 10Gb Dual port SFP+ HP NC560


store – unRAID 6 – almacenamiento centralizado para las necesidades de File Services. Además de storage con unRAID se tiene la facilidad de correr Docker/VM. Alguno de los contenedores corriendo aquí son Plex, Syncthing, Sonarr, Radarr y algún otro que olvide ahora mismo.

    -   Ahora es una VM en ESXi7.0 (esxi1)
    -   Supermicro X9SRL
    -   Intel Xeon E5-2680 v2
    -   128GB de RAM
    -   2x 2TB Hard disks
    -   2x 4TB Hard disks
    -   2x 3TB Hard disks
    -   1x Intel SSD PCIe 1.6 TB
    -   More SSDs for VMs….
    -   2x 1Gb NIC
    -   10Gb NIC – aún no se ha conectado, el CRS cuenta con dos puertos 10GB.
    -   Rosewill RSV-L4000 – 4U

Equipos que no estan en el rack.

2x HP Proliant EC200a

    -   Intel(R) Xeon(R) CPU D-1518 @ 2.20GHz
    -   64GB de RAM
    -   1x SSD 240GB
    -   1 Intel SSD DC S3700 1.6TB
    -   1x M.2 NVMe 500GB

homelab for 20231208