La nueva red

Como soy un poco culo inquieto, he decidido cambiar de nuevo la red doméstica. En abril había montado la conectividad de mi entorno lab sobre la base de un antiguo router WiFi tuneado con OpenWRT. El entorno lab era una subred (192.168.2.0/24) que se conectaba a la red doméstica a través del susodicho router en modo repetidor.

Lo cierto es que la disposición funcionaba pero el rendimiento del enlace radio era muy mejorable. Para mejorar el rendimiento, decidí cambiar la arquitectura de la red.

En primer lugar adquirí un par de PLCs de la marca Devolo. En concreto, el producto dLAN 1200+ Starter Kit PLC que proporciona conectividades de Gb Ethernet sobre la red eléctrica. El aspecto que tienen los cacharros es el siguiente:

devolo-dlan-1200-plc-pl1110856_0

Un poco aparatosos pero, la realidad es que funcionan muy bien. Empleando estos PLCs puedo conectar a velocidades de Gb el router de acceso a Internet con los dispositivos que tengo en el lab y descargar la WiFi del lab.

Adicionalmente, para proporcionar conectividad, adquirí un switch de 8 puertos, en concreto un Netgear GS308 de 8 puertos 10/100/1000Mb. Sin embargo yo creo que es mas un hub que un switch.

5168e9kwtrL._SL1200_

Una vez establecidas todas las conexiones, fue necesario reconfigurar la red. Ahora, los equipos de la red cableada están dentro de la red doméstica (192.168.1.0/24) y no es necesaria una segunda subred para el lab. Esto requiere quitar alguna ruta estática configurada en el router de acceso a Internet así como la configuración de las direcciones IP de las interfaces del servidor ESXi.

Otra ventaja es que el PC de sobremesa que tengo está accesible a toda la casa sin necesidad de cambiar la conexión. Esto es importante ya que el PC actúa como servidor de impresión y tiene varios discos compartidos. Pot otra parte, al liberar el router OpenWRT voy a poder empezar a jugar con Kismet.

En resumen, el aspecto que tiene mi red doméstica es ahora así:

ca1

Ahora un servidor de nombres

1. Introducción

Una vez completada la configuración de la red de gestión, voy a empezar a configurar distintos servidores en el entorno. Para empezar, voy a desplegar un servidor de nombres, basado en bind para mi entorno.

El servidor DNS, como no podía ser de otra forma, lo voy a instalar en la DMZ. La red virtual del lab, va tomando forma de este modo:

dns3

2. Creación y preconfiguración de la máquina virtual

Creo una máquina virtual con la configuración estándar (1GB de RAM y 10 GB de disco):

dns1

Instalo el sistema operativo, Ubuntu para no variar. Antes de ponerme con el despliegue de bind, tengo una serie de tareas que completar:

a) En primer lugar me toca configurar la segunda tarjeta de red para que se conecte a la red de gestión. Esto es, a priori, sencillo, no hay más que configurar la interfaz de gestión en /etc/network/interfaces

dns7

dns8

b) El segundo aspecto a configurar es enviar los logs al servidor de logs. Editamos el fichero /etc/rsyslog.conf y añadimos al final la línea correspondiente:

dns9

c) Por último, necesitamos instalar NRPE y configurarlo para poder monitorizar el servidor DNS desde Nagios. Los pasos a seguir están descritos aquí. Asimismo, tengo que crear los objetos necesarios en el servidor de Nagios para que la monitorización sea efectiva. Finalmente, ya tengo controlado el nuevo servidor en Nagios:

dns10

3. Instalando bind

Instalo el paquete bind9, las utilidades asociadas y la documentación:

dns11

Compruebo que el servicio named esté a la escucha en el puerto 53:

dns12

Todo correcto pero voy a hacer que sólo resuelva para IPv4. Para ello edito el fichero /etc/default/bind9 y añado –4 al parámetro OPTIONS.

dns13

Rearranco el servicio y verifico que no esté escuchando en el puerto 53 en IPv6:

dns14

4. Configurando bind

Ahora voy a configurar bind para que sea el servidor de nombres de mi dominio lab (tcantos.local).

Editamos el fichero de opciones de configuración de bind (/etc/bind/named.conf.options), añadiendo un acl para las redes de mi lab y configurando las opciones de acuerdo a mi entorno. El fichero queda de la siguiente forma:

dns15

A continuación vamos a definir las zonas. Para ello editamos el fichero /etc/bind/named.conf.local. Definimos una zona de resolución directa para las distintas redes del entorno lab y cuatro zonas de resolución inversa para las distintas redes:

dns16

dns17

Ahora definimos los ficheros de datos de bind para la resolución directa e inversa:

  • tcantos.local.db

dns18

  • 2.1.10.db (servidores de backend)

dns20

  • 3.1.10.db (Red de estaciones de trabajo)

dns21

  • 2.168.192.db (DMZ)

dns19

  • 199.168.192.db (Red de Gestión)

dns22

Una vez creados los ficheros necesarios, los llevamos al servidor y verificamos la configuración, las zonas y rearrancamos el servidor bind.

dns23

Finalmente, configuramos los clientes. En los servidores ubuntu editamos el fichero /etc/resolvconf/resolv.conf.d/head para añadir las líneas necesarias y ejecutamos resolvconf:

dns24

Verificamos el funcionamiento del servidor dns con dig y nslookup:

dns25

dns26

dns27

Parece que todo funciona, sólo queda configurar el resto de los equipos.

Probando la nueva red

Como he contado aquí y aquí, he reconfigurado la red del entorno lab para que sea más eficiente. Ahora llegó el momento de probar los cambios realizados y que todo funciona de acuerdo a lo esperado.

Para probar la conectividad con la DMZ voy a conectar a la misma una máquina virtual Lubuntu con dirección IP 192.168.2.130:

red20

1. Conectividad desde el PC conectado a la red lab

red18

red19

red21

red22

2. Conectividad desde el PC conectado a la WiFi doméstica

Para esto desactivo la conexión ethernet y activo la conexión WiFi.

red27

red28

red29

3. Conectividad desde la DMZ

red23

red24

red25

red26

Parece que todo funciona correctamente.

Replanteando la red (II)

En esta segunda parte voy a concretar los pasos seguidos para reconfigurar la red en el sentido anticipado en el post anterior. En principio, los elementos que tengo que tocar son:

  • El router de acceso a Internet
  • El router con OpenWRT
  • El PC de sobremesa
  • El servidor ESXi
  • Las redes virtuales del lab.

Vamos a ir paso a paso con cada uno de los elementos:

Cambios en el router de acceso a Internet

Este cambio es, a priori, uno de los más fáciles. No hay más que añadir ruta estática que envíe el tráfico dirigido a la red 192.168.2.0/24 a la interfaz WAN del router OpenWRT que tiene la dirección 192.168.1.2. Para ello, nos conectamos a la interfaz web de administración del router y configuramos la ruta estática:

red3

Cambios en el router con OpenWRT

Aquí es donde está realmente la chicha. Nos conectamos a la interfaz web del router basada en Luci:

red4

A continuación deshabilitamos la interfaz pseudobridge (starbridge) que implementaba el relay entre la red doméstica y la red del lab. Además eliminamos el paquete ralayd que ya no necesitamos (lo siento no tengo captura de pantalla de esto).

Configuramos la interfaz wireless estableciendo la dirección IP estática 192.168.1.2. Esta interfaz está asociada a la zona de firewall WAN.

red5
Creamos una interfaz que haga asociada a la LAN del lab y configuramos la dirección IP 192.168.2.1 (gateway de la LAN del lab). Asociamos esta interfaz a la zona de firewall LAN:

red6

Creamos dos rutas estáticas: una que dirija el tráfico hacia la LAN doméstica e internet hacia la interfaz wireless y otra que dirija el tráfico hacia la subred 192.168.2.128/25 (DMZ) hacia la dirección IP 192.168.2.4 donde va a estar el router VyOS virtual.

red7

Finalmente, configuramos las reglas de firewall que permitan el paso del tráfico desde la LAN doméstica (WAN en este router) y la LAN de lab:

red8

Con esto, el router OpenWRT debería quedar configurado.

Configuración del PC de sobremesa

La configuración del PC de sobremesa no debería ser un arco de iglesia. Abrimos el centro de redes y recursos compartidos, abrimos el enlace de los adaptadores, pinchamos el adaptador ethernet, seleccionamos Propiedades:

red9

Editamos las propiedades del protocolo de Internet versión 4, asignamos la dirección IP a 192.168.2.2, la máscara de subred a 255.255.255.128 y la puerta de enlace a 192.168.2.1. Establecemos los valores de los DNS de Telefónica y ¡listo!:

red10

Configuración del servidor ESXi

La configuración a realizar en el servidor ESXi consiste en establecer la nueva dirección IP para la interfaz de red de administración. Para ello, arrancamos el servidor y, en la consola, establecemos la dirección IP de la interfaz de administración a 192.168.2.3, la máscara de subred a 255.255.255.128 y la puerta de enlace a 192.168.2.1.

Configuración del servidor entorno virtual

Para configurar el entorno virtual, habilito la conexión ethernet del PC de sobremesa y deshabilito la WiFi y me conecto al servidor ESXi a través de vCenter:

red11

red12

Arrancamos el router VyOS y nos conectamos a la consola. Cambiamos, en primer lugar la dirección IP estática de la interfaz WAN.

red13

Cambiamos la interfaz de la DMZ para darle el direccionamiento correspondiente a la subred 192.168.2.128/25.

red14

red15

Configuramos la ruta estática de salida

red16

Finalmente eliminamos la reglas de NAT para la DMZ:

red17

En principio la red debería estar configurada y funcionando. En el próximo post vamos a realizar las pruebas.

Replanteando la red (I)

Comenté en un post anterior cómo había configurado la red para acceder al servidor ESXi. Esencialmente, lo que hice fue configurar un antiguo Router ADSL como un bridge WiFi mediante la instalación de OpenWRT. El esquema de la solución de conectividad que tengo desplegado es el siguiente.

red1

Tengo contratado el paquete Fusión fibra con Movistar. La ONT y el router están instalados en el salón y, directamente conectado al router están: el teléfono, el descodificador de Imagenio, un Android TV y una Play 3. Como la WiFi no llega  muy bien a toda la casa, instalé un repetidor WiFi.

A la WiFi se conectan los teléfonos móviles de la familia (4), los portátiles
de la familia (3), un par de tablets, un par de Kindles y, en la habitación de trabajo un PC de sobremesa que tiene conectados un escáner, una impresora y  varios discos duros compartidos en red. Además, en esta habitación de trabajo, está el router tuneado, al que se conectan por cable de red las dos interfaces del servidor ESXi y una Raspberry PI 2.

La solución de conectividad para el servidor ESXi basada en un pseudobridge sobre OpenWRT. La solución funciona pero, es cierto que, no a mi entera satisfacción.

El problema fundamental es que todo el tráfico del servidor ESXi pasa por la WiFi. Teniendo en cuenta que la WiFi no es uno de los puntos fuertes del router que suministra Telefónica, y el uso que la familia hace de ella, las probabilidades de saturarla son muy altas (prácticamente una certeza). Además la puñetera WiFi tiene cierta tendencia a caerse.

La idea es, dado que el PC de sobremesa (que es donde tengo instalado el
vCenter) tiene una interfaz ethernet (además de la WiFi), conectar esta interfaz al router con OpenWRT y las dos NICs del servidor ESXi. Esto haría que el tráfico del lab, con la excepción del tráfico Internet, se canalizaría por el router y no a través de la WiFi y me permitiría aprovechar el mayor ancho de banda de las conexiones de cobre.

Implementar esta solución supone convertir el pseudobridge en un router y segregar la LAN del lab de la LAN doméstica (192.168.1.0/24). Para el lab configuraré una nueva LAN (192.168.2.0/24). Las tareas a realizar son:

  1. Reconfigurar el router OpenWRT. Es necesario configurar la interfaz Wan (WiFi) con la dirección IP (192.168.1.2), deshabilitar la funcionalidad de pseudobridge y, en la parte LAN configurar dos subredes: la 192.168.2.0/25 para el PC de sobremesa (192.168.2.2) y las NIC del servidor ESXi (192.168.2.3 – Gestión y 192.168.2.4). La otra subred (192.168.2.128/25) la voy a dejar para el direccionamiento de la DMZ en el entorno virtual.
  2. Reconfigurar el router de banda ancha para añadir una ruta estática que dirija el tráfico destinado a la red 192.168.2.0/24 al router OpenWRT (192.168.1.2).

El esquema de red quedaría:

red2

Las ventajas que se me ocurre, proporciona esta solución son:

  1. Reducir el tráfico a través de la WiFi.
  2. Acelerar el acceso desde el vCenter a las máquinas virtuales.
  3. Evitar el doble NAT en la salida a Internet desde las máquinas virtuales (las de la DMZ).

Por otra parte, las desventaja fundamental es que el PC de sobremesa, al estar en una subred distinta al resto de los PCs, no puede compartir la impresora ni los discos duros sin desplegar un servidor de dominio (cosa que no pienso hacer). La solución pedestre es habilitar la interfaz ethernet cuando vaya a jugar con el lab y habilitar la interfaz WiFi el resto del tiempo.

Cómo hacerlo en el siguiente post.

La conectividad

Como ya he comentado en algún post anterior, el servidor que adquirí para mi lab casero no tiene (ni pretendo ponerle) conectividad WiFi dado que en la habitación donde trabajo sólo tengo conectividad WiFi, era necesario que buscara una solución de conectividad. En principio, esa solución de conectividad pasaba bien por instalar una solución de cableado PLC o bien buscar algún tipo de bridge WiFi. En cualquier caso, parecía claro que algo me iba a tocar comprar.

Resulta que tengo por casa un par de modems router ADSL antiguos y una idea era reutilizar uno de estos como base para la solución de conectividad del servidor. Los cacharros son un D-Link 2740B y un Belkin F5D7632-4.

d-link-dsl-2740b.3391432

DCP_1498

Buceando por Internet, encontré que existía un firmware, basado en Linux, DD-WRT que permite reciclar este tipo de equipos. Ni corto ni perezoso, busco en su base de datos si alguno de mis equipos estaba soportado pero, desgraciadamente, ninguno lo estaba. Mi gozo en un pozo, parece que no me libro de comprar un nuevo cacharro.

Buscando en Internet, descubro un nuevo sitio donde mantienen firmware open source para routers: OpenWRT. Al parecer, OpenWRT es un esfuerzo más open mientras que DD-WRT tiene una vertiente más comercial. Ambos parten de la misma base de código que no es otra cosa que un Linux embebido.

Busco en la base de datos de openWRT y descubro que para el Belkin no hay esperanza, sin embargo, el D-Link está soportado. Así que ¡manos a la obra! Ni la web de OpenWrt es de las más amigables del mundo ni yo me entero muy bien de cómo están organizadas las versiones de software así que en la página correspondiente al modelo de mi router me entero que la imagen que tengo que instalar es la experimental que tiene el problema que no tiene la interfaz web  Luci pero como se puede instalar a posteriori pues nada, a por ello.

Para la instalación del firmware voy a usar una Raspberry PI 2 que tengo con un Kali Linux. Me conecto a Internet con la Rasp a treavés de la WiFi y descargo las imágenes de OpenWRT, del firmware de mi router de la página de D-Link (por si acaso) y la última versión de Luci. A partir de este momento comienza el show, cojo aire y hago lo siguiente:

  1. Desconecto la rasp de la WiFi haciendo un down de la interfaz.
  2. Conecto un cable de red al puerto ethernet de la Rasp y a uno de los puertos del router.
  3. Configuro la interfaz ethernet de la Rasp a la dirección IP 192.168.1.2.
  4. Hago un reseteo del router en la forma específica para la carga inicial de firmware.
  5. 5. Abro una sesión de navegador a la dirección 192.168.1.1 (router) y me aparece una interfaz que me pide que seleccione la imagen a instalar.
  6. Selecciono la imagen a instalar (OpenWRT) y ¡adelante!
  7. Después de un par de minutos el router arranca, hago SSH al router y … ¡Me conecto!. Primer paso conseguido.

Ahora toca instalar Luci, pues vamos a por ello. ¡Coño! primer problema, para descargarme los paquetes, necesito que el router se conecte a internet y para esto tengo que configurar la interfaz WiFi del router para que se conecte a la WiFi casera, evitar el conflicto de direcciones IP, … Pero como no hay nada que perder, a por ello. Despues de una hora y un bote de cerveza está conseguido, hay ping desde el OpenWRT al 8.8.8.8 (DNS de Google) y lanzamos la descarga e instalación de Luci. Esto es fácil como en Ubunto pero en vez de apt opt.

Primera cagada, el dispositivo no tiene suficiente memoria para guardar el paquete e  instalarlo. Efectivamente, hago un df y todo está al 100%. ¡Mierda! al final va a haber que buscar un cacharro nuevo. Abro otro bote de Mahou y me pongo a mirar en Amazon qué comprar …

Antes de meter el pedido en Amazon de un repetidor WiFi con puerto Ethernet voy a hacer un último intento, voy a buscar en la última release de OpenWRT (Chaos Calmer) si hay una imagen estándar para mi router (la Wiki de mi modelo de router era antigua) y, efectivamente, la hay. Me la bajo a la Rasp y vuelvo a repetir los pasos numerados arriba. Esta vez el router arranca y, al conectarme, a través de HTTP aparece la página de Luci. ¡Cojonudo! ahora a configurar el bridge en modo cliente WiFi.

Descubro que lo que tengo que hacer es configurar un cliente WiFi en modo pseudobridge con relayd. Para no equivocarme sigo la receta y, en algún punto, la cago y no chuta. Después de un rato intentándolo decido que lo mejor es comenzar de cero y, por tercera vez, cargo la imagen en la flash, vuelvo a configurarla y esta vez lo consigo. Ya tengo mi bridge.

Configurando VyOS (II)

En este post voy a describir las tareas de configuración final del router virtual VyOS que instalé en mi entorno lab. En la entrada anterior, dejé configurada la conectividad básica del router y en este voy a configurar la salida a Internet desde las LANes creadas.

He creado una máquina virtual Lubuntu para probar la conectividad desde cada una de las LANes hacia Internet. En primer lugar, configuro el adaptador de red para que se conecte a la LAN de estaciones de trabajo (10.1.3.0/24) y vamos a comprobar que, al arrancar, el cliente obtiene una dirección IP del servidor DHCP configurado para esta subred en el router y esta IP debería estar en el rango 10.1.3.128-10.1.3-254:

config2_1

El cliente ha obtenido la dirección IP 10.1.3.128. Desde el cliente se debería poder hacer ping a las interfaces del router:

config2_2

Sin embargo no hay ping ni hacia el router doméstico ni hacia internet:

config2_3

El problema es que el router no puede encaminar direcciones del rango 10.x.x.x. Es necesario configurar una regla de NAT en el router virtual para poder tener salida a internet desde las subredes:

config2_4

Una vez configurado el NAT podemos comprobar que tenemos conectividad hacia Internet y la red local doméstica:

config2_5

Y deberíamos tener también el servicio de nombres (en la configuración DHCP establecimos como servidor de nombres el de Google: 8.8.8.8):

config2_6

Ya sólo queda realizar la misma configuración para las otras LANes.