Configurando el gestor Nagios

En los posts anteriores (aquí y aquí) abordé cómo configurar los elementos que van a monitorizarse en la red para permitir su gestión desde el servidor Nagios. En este post voy a abordar la configuración de Nagios.

Nagios, de acuerdo a la instalación que tengo, mantiene la información de configuración en el directorio /usr/local/nagios/etc. Bajo este directorio y los subdirectorios correspondientes se encuentran una serie de ficheros de configuración.

El primer paso es traerse toda esta información de configuración al PC para poder editar los ficheros de forma más amigable (aunque vi/vim es un gran editor, prefiero hacerlo con UltraEdit). Después de los líos con la creación de una imagen y su montaje que tuve para transferir archivos desde el PC a una máquina virtual, descubrí que la forma más fácil de mover ficheros es a través de un pincho USB. Lo único que hay que hacer es añadir a las máquinas virtuales un controlador USB y, cuando se monta el controlador reconoce los dispositivos pinchados en el PC que ejecuta el vClient.

Reflexionando sobre el manejo de la cantidad de ficheros de configuración involucrados en el lab, se me ocurre que, probablemente sea una buena idea montar un control de versiones (por ejemplo, svn) para mantener gestionadas todas estas configuraciones (le echaré una pensada a lo largo de la semana).

Volviendo al tajo tras la digresión, lo que voy a hacer es organizar los elementos de configuración en una serie de subdirectorios, en la actualidad, lo que hay es un subdirectorio ‘objects’ con distintos objetos de configuración y uno ‘servers’ con los ficheros de configuración de los distintos hosts de la red. En el directorio raíz se encuentran los ficheros de configuración generales de Nagios. Mi plan es organizar la configuración de la siguiente forma:

• En el directorio raíz los ficheros de configuración generales: nagios.cfg, resource.cfg, cgi.cfg, nrpe.cfg y htpasswd.users.
• Subdirectorio commands. Ficheros .cfg de los distintos comandos.
• Subdirectorio contactgroups. Ficheros .cfg de los contact groups.
• Subdirectorio contacts. Ficheros .cfg de los contactos.
• Subdirectorio hostgroups. Ficheros .cfg de los grupos de hosts.
• Subdirectorio hosts. Ficheros .cfg de los distintos hosts existentes en el lab.
• Subdirectorio services. Ficheros .cfg de los distintos servicios.
• Subdirectorio servicegroups. Ficheros de .cfg correspondientes a los grupos de servicios.
• Subdirectorio timeperiods. Ficheros .cfg con la configuración de períodos de tiempo.

Para que surja efecto es necesario que, en el fichero de configuración general de nagios (nagios.cfg), se establezca que estos directorios deberán ser contemplados en la carga de la configuración:

Una vez completada esta labor, lo que queda es pasarla al servidor nagios y probar la configuración. Empleando el pincho usb la transferencia de la configuración es coser y cantar y tras unas mínimas correcciones consigo que la configuración sea correcta:

Re-arranco Nagios y me conecto a la interfaz web desde una máquina virtual Lubuntu conectada a la red de gestión.

Se ve que los tres hosts de mi red están levantados pero tengo cuatro problemas críticos:

Los cuatro problemas críticos tienen que ver con el router vyos, uno de ellos es el servicio SSH que no estará levantado y los otros tres están relacionados con SNMP. Voy a investigar qué pasa.

Al editar la definición del servicio Uptime me doy cuenta enseguida del error. La community del comando check_snmp está puesta a public y en el setup de SNMP del router VyOS la community que establecí es mylab. Un pequeño cambio en la configuración de los servicios basados en SNMP y este problema debería quedar arreglado:

En el caso del SSH, voy a levantar el servicio SSH en el router vyos:

Ya sólo queda comprobar la configuración de Nagios, re-arrancar el servicio y ver qué pasa:

A priori, todo pinta bien, veamos cómo está el router VyOS:

Todo verde, tarea completada (por ahora) queda por definir qué voy a monitorizar del router, pero eso ya será en otro lugar.

Monitorizando la red virtual (II)

En el post precedente abordé la configuración del servidor NRPE desplegado en mi servidor de syslog (ubsyslog) para poder ser monitorizado desde Nagios. En esta segunda parte, abordaré la configuración del router VyOS para poder ser monitorizado desde Nagios.

A diferencia del caso del servidor, la monitorización del router la voy a realizar empleando SNMP. Para ello, lo primero que tengo que hacer, es configurar el agente SNMP en el router VyOS.

Una vez configurado, comprobamos que desde el servidor Nagios podemos acceder a la información del agente SNMP mediante el comando snmpget:

En principio esto está funcionando queda decidir qué objetos vamos a monitorizar desde el servidor Nagios.

Monitorizando la red virtual (I)

Una vez instalado Nagios en el servidor designado para ello, el siguiente paso en el camino es monitorizar el resto de los elementos. Ahora mismo, mi red está así:

Los elementos a monitorizar (por ahora) son, además del propio servidor Nagios, el servidor de Syslog y el router Vyos. Lo que hay que hacer es configurar el servidor Nagios para poder realizar la monitorización. No tengo mucha idea de cómo va esto pero, a priori, el secreto consiste en atacar el router VyOS a través de SNMP y los servidores a través del plugin NRPE.

En este post voy a cubrir la configuración del servidor NRPE en el servidor de syslog.

Para poder monitorizar el servidor de syslog, lo que hay que hacer, en primer lugar, es instalar NRPE y los plugin de Nagios:

add@ubsyslog~$ sudo apt-get update 
add@ubsyslog~$ sudo apt-get install nagios-plugins nagios-nrpe-server

El siguiente paso es editar el fichero de configuración del servidor NRPE. Este fichero es /etc/nagios/nrpe.cfg. En este fichero, establecemos el host desde donde se van a lanzar los comandos de monitorización (servidor ubnagios):

y las directivas include para estructurar el contenido de la configuración:

Dentro del directorio nrpe.d voy a crear un fichero de configuración (cmds.cfg) que contiene los comandos que van a utilizarse para monitorizar el servidor remoto.

En el caso del servidor ubsyslog, lo que, inicialmente, voy a monitorizar es:

• Que el servidor esté vivo. Esto se lleva a cabo lanzando un ping desde el servidor de monitorización por lo que, en local, no hay que hacer nada.
• El número de usuarios conectados al servidor. Para ello empleamos el plugin nrpe check_users estableciendo un nivel de warning a 5 y el nivel crítico a 10.
• La carga del servidor. Se monitoriza mediante el comando check_load de forma que eleve un aviso si los niveles de carga (de acuerdo a la salida del comando uptime) superan 5,10 y 15 y lanza un nivel crítico cuando estos niveles superan los valores 30, 25 y 20.
• La ocupación del disco duro del servidor (sistema de ficheros ‘/’), empleando el comando check_disk. El comando emitirá un warning cuando el espacio libre en el disco duro baje del 20% y un aviso crítico cuando el espacio libre esté por debajo del 10%. Es importante saber cuál es el dispositivo en el que se monta el sistema raíz que, en el caso del servidor ubsyslog, es /dev/dm-0 (obtenido mediante el comando ‘df –h /’).
• El número total de procesos. Para esto, se utiliza el comando check_total_procs, estableciendo un nivel de warning en 150 y el nivel crítico en 200.
• El espacio de swap libre. Para obtener este valor empleamos el comando check_swap estableciendo el nivel de warning al 20% y el nivel crítico al 10%.
• El espacio utilizado por los logs (directorio /var/log). Para obtener esto empleamos el comando check_folder_size estableciendo los niveles de warning y crítico respectivamente a 5GB y 6GB (el disco duro total inicial es de 10GB).

El fichero cmds.cfg queda de la siguiente forma:

Antes de continuar voy a hacer un breve inciso sobre cómo configurar el comando check_folder_size.sh (yo lo renombré a check_folder_size2.sh) ya que el conseguir que funcione supuso un esfuerzo considerable.

El shell script check_folder_size.sh lo descargué al PC donde ejecuto el vSphere client desde el sitio de internet de Nagios Exchange. Una vez en el PC, surgió el problema de cómo llevarlo a la máquina virtual, la solución que empleé, fue crear una imagen ISO, subirla a vSphere y montarla en la unidad de CD de la máquina virtual. Aquí explican más o menos el mecanismo.

A continuación, tuve un pequeño problema con los permisos. Tuve que cambiar el usuario y los permisos del fichero:

add@ubsyslog:/usr/lib/nagios/plugins$ sudo chown nagios:nagios check_folder_size2.sh
add@ubsyslog:/usr/lib/nagios/plugins$ sudo chmod 755 check_folder_size2.sh

Una vez completado todo esto, conseguí que el comando funcionara en local. Ahora llega la hora de probar que todos los comandos funcionan en remoto desde el servidor de nagios (ubnagios) utilizando el comando check_nrpe:

Todo funciona OK y esto me va a servir de plantilla para siguientes configuraciones.

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:

1. Conectividad desde el PC conectado a la red lab

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

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

3. Conectividad desde la DMZ

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:

Cambios en el router con OpenWRT

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

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.

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:

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.

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:

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:

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!:

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:

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

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

Configuramos la ruta estática de salida

Finalmente eliminamos la reglas de NAT para la DMZ:

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.

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:

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.

Instalando Nagios (II)

En el post anterior abordé la descarga, configuración inicial, construcción e instalación de Nagios. En este post voy a cubrir la descarga, configuración, construcción e instalación de plugins y NRPE.

Capítulo 4. Descarga e instalación de los plug-ins

En primer lugar, para la descarga de los plugins de Nagios accedemos a este sitio para ver la última versión de éstos. En el momento de escribir esto se trata de la versión 2.1.1.

Al igual que en el caso de Nagios, utilizamos curl para la descarga del tarball:

Descomprimimos …

add@ubnagios~$ tar –xvf nagios-p*

Configuramos y construimos …

add@ubnagios~$ cd nagios-p* add@ubnagios~/nagios-plugins-2.1.1$ ./configure --with-mail=/usr/sbin/sendmail --with-nagios-group=nagios --with-command-group=nagcmd
add@ubnagios~/nagios-plugins-2.1.1$ make

y, finalmente, instalamos …

add@ubnagios~/nagios-plugins-2.1.1$ sudo make install

Capítulo 5. Descarga e instalación de NRPE

NRPE es el Nagios Remote Plugin Executor. Al igual que en el caso anterior, averiguamos, en primer lugar, cuál es la última versión de NRPE accediendo a este sitio. En el momento de escribir esto, se trata de la versión 2.15.

Usando curl, descargamos el tarball…

Descomprimimos …

add@ubnagios~$ tar –xvf nrpe*

Configuramos, construimos e instalamos …

add@ubnagios~$ cd nrpe* add@ubnagios~/nrpe-2.15$ ./configure --enable-command-args --with-nagios-user=nagios --with-nagios-group=nagios --with-ssl=/usr/bin/openssl --with-ssl-lib=/usr/lib/x86_64-linux-gnu
add@ubnagios~/nrpe-2.15$ make all
add@ubnagios~/nrpe-2.15$ sudo make install
add@ubnagios~/nrpe-2.15$ sudo make install-xinetd
add@ubnagios~/nrpe-2.15$ sudo make install-daemon-config

Por último editamos el script de arranque de xuinetd (/etc/xinet.d/nrpe) para añadir la dirección IP del servidor Nagios en el parámetro only_from:

Finalmente rearrancamos el servicio xinetd:

add@ubnagios~$ sudo service xinetd restart

Con esto hemos completado la instalación de Nagios. En el siguiente post trataré de la configuración de Nagios.

Instalando Nagios (I)

El siguiente paso en la configuración de mi entorno lab es instalar un servidor Nagios para la supervisión y control de los distintos servidores del entorno. En este post y en el siguiente abordaremos la instalación de Nagios y, en un tercero, la configuración de Nagios.

Prólogo

El primer paso en la instalación de Nagios es crear un servidor virtual Ubuntu con 1GB de RAM y 10GB de disco y con el stack LAMP. La selección del stack LAMP la hacemos durante la instalación de Ubuntu.

Arrancamos la máquina virtual y actualizamos los paquetes instalados. A continuación, ya que hemos desplegado un servidor de syslog, hacemos la configuración necesaria para que los logs de este equipo vayan al servidor de syslog.

Para ello, editamos el fichero /etc/rsyslog.conf y añadimos, al final del fichero, la línea:

*.*	@192.168.199.2

El host 192.168.199.2 es el servidor de syslog.

Re-arrancamos el servicio rsyslog y ya tenemos el equipo preparado para el despliegue de Nagios.

Para el despliegue de Nagios voy a ir siguiendo los pasos que se describen en este sitio. A ver si, por una vez, consigo hacer las cosas a la primera. La instalación de Nagios se va a realizar creando los binarios a partir del código fuente.

Capítulo 1. Creando los usuarios

Vamos a crear un usuario “nagios” y un grupo “nagcmd” y a añadir el usuario nagios a este grupo:

Capítulo 2. Actualizando el sistema e instalando las dependencias

La actualización del sistema la realizamos mediante el comando siguiente:

add@ubnagios~$ sudo apt-get update

A continuación vamos a instalar las dependencias necesarias para la compilación de Nagios:

add@ubnagios~$ sudo apt-get install build-essential libgd2-xpm-dev openssl libssl-dev xinetd apache2-utils unzip

Capítulo 3. Descarga e instalación de Nagios

El siguiente paso a abordar es la descarga, compilación e instalación de Nagios. De acuerdo a lo que dice en el sitio web, la última versión disponible es la 4.1.1. Así que vamos a descargar el tarball correspondiente, mediante curl.

Descomprimimos …

add@ubnagios~$ tar –xvf nagios*

Configuramos …

add@ubnagios~$ cd nagios*
add@ubnagios~/nagios-4.1.1$ ./configure --with-mail=/usr/sbin/sendmail --with-nagios-group=nagios --with-command-group=nagcmd

y construimos …

add@ubnagios~/nagios-4.1.1$ make all

Ahora instalamos Nagios, ficheros de configuración y scripts de inicialización.

add@ubnagios~/nagios-4.1.1$ sudo make install
add@ubnagios~/nagios-4.1.1$ sudo make install-commandmode
add@ubnagios~/nagios-4.1.1$ sudo make install-init
add@ubnagios~/nagios-4.1.1$ sudo make install-config
add@ubnagios~/nagios-4.1.1$ sudo /usr/bin/install -c -m 644 sample-config/httpd.conf /etc/apache2/sites-available/nagios.conf

Finalmente, para poder lanzar comandos a través de la interfaz web, añadimos el usuario del seervidor web, www-data al grupo nagcmd.

add@ubnagios~/nagios-4.1.1$ sudo usermod -G nagcmd www-data

Continuaremos en la segunda parte instalando los plugins y NRPE.

Un servidor para logs

Los logs proporcionan información sobre el estado del sistema, centralizando los logs en único servidor me va a permitir tener un punto de supervisión único del estado de salud de mi lab.

El estándar para la recogida de logs es syslog y, por lo tanto, lo que voy a hacer es configurar un servidor Ubuntu, conectado a la red de gestión para la recolección de logs mediante el protocolo syslog. Inicialmente voy a dotar al servidor de 1GB de RAM y 10GB de disco.

El primer paso es, por lo tanto, crear la máquina virtual:

Lo que quiero conseguir es que el directorio /var/log aparezca un fichero de log para cada uno de los servidores con la dirección IP del servidor. El servicio syslog está implementado a través del programa rsyslog y su fichero de configuración es, naturalmente, rsyslog.conf. Edito, por lo tanto este fichero:

add@ubsyslog:~$ sudo vi /etc/rsyslog.conf

Para centralizar los logs en el servidor vamos a permitir que el servidor de logs escuche en los puertos TCP y UDP estándar. Para ello eliminamos los comentarios (borramos el ‘#’ al comienzo de la línea) de las líneas del fichero de configuración que configuran los puertos de escucha y que son las siguientes:

#$ModLoad imudp
#$UDPServerRun 514
#$ModLoad imtcp
#$InputTCPServerRun 514

El siguiente paso es definir una plantilla para los ficheros de log a los que se van a dirigir los logs recibidos en el servidor. Como ya comenté, la idea es que los ficheros de log de cada servidor se identifiquen por la dirección IP del servidor.

Para conseguir esto, añadimos las siguientes líneas al fichero de configuración antes de la sección de directivas globales.

$template ServerLogs,"/var/log/%FROMHOST-IP%/%PROGRAMNAME%.log"
*.*  ?ServerLogs
& ~

Como las cosas en Linux no son siempre intuitivas voy a explicar un poco que es lo que significa cada una de las líneas:

• La primera línea le dice a rsyslog que la plantilla, de nombre ‘ServerLogs’, escribe en ficheros de log en subdirectorios, cuyo nombre es la dirección IP del equipo bajo el directorio /var/log. El nombre de esos ficheros de log es el nombre del programa que genera el mensaje y la extensión ‘.log’.
• La segunda línea le dice a rsyslog que aplique la plantilla ServerLogs a todos los mensajes de log recibidos (de ahí el *.*).
• Por último, la tercera línea, es una regla de redirección que le dice a rsyslog que una vez procesados los mensajes por la regla ServerLogs detenga el proceso posterior de los mensajes. Sin esta regla los mensajes se recogerían dos veces.

El fichero de configuración quedaría:

Por último, reiniciamos el servicio rsyslog y comprobamos que el servicio escucha en los puertos correspondientes mediante el comando netstat:

add@ubsyslog:~$ sudo service rsyslog restart
add@ubsyslog:~$ sudo netstat -tulpn | grep rsyslog

El comando produce una salida como:

Ahora vamos a configurar los clientes de syslog, en este caso, el router VyOS para que envíe la información de log para todas las facilities de nivel notice o superior a nuestro servidor syslog.

En el servidor syslog vemos que se han creado directorios con la dirección IP de localhost y del router y que éstos contienen los ficheros de log.

Caso cerrado, por ahora. El siguiente paso va a ser el configurar un Nagios para la gestión de los equipos en la red.

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.

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.