phpIPAM, como su nombre compuesto lo indica, es el manejo y administración, por medio de lenguaje PHP, de las direcciones del Protocolo de Internet (en inglés «Internet Protocol Address Managament» y que abreviaremos como IPAM), lo que hace al software con un nombre muy singular, pnemotécnico pues (¿metanombre?). En este artículo revisaremos cómo podremos utilizar phpIPAM más bien como una herramienta auxiliar, aunque veremos que tiene ciertos componentes basados en la monitorización, ¡vamos!
phpIPAM y Pandora FMS.
En un artículo anterior explicamos qué era una calculadora de IP y cómo funciona y además sobre el cómo está implementado en Pandora FMS. Lo cierto es que desde mayo de 2014 (y formalmente liberada en la versión 5.1 ) Pandora FMS incluye IPAM como una extensión muy útil para el manejo, descubrimiento y asociaciones de agentes existentes, registro de comentarios en cada una de las direcciones IP, así como la capacidad de establecer excepciones, siempre desde el punto de vista de la monitorización. Las detecciones de direcciones IP bien puede ser por medio de ping o por las direcciones IP que nos entreguen los agentes que previamente tengamos registrados: Pandora FMS se encargará de hacernos las equivalencias y correspondencias sin mayor labor de nuestra parte.
Además, cuando las detecciones están regidas por los agentes en Pandora FMS, tenemos la ventaja de conocer sus sistemas operativos, los cuales son representados gráficamente en la extensión IPAM. Podremos establecer alertas para cuando una dirección IP cambie, también el ver un panorama general con todas las direcciones o bien de manera filtrada: los dispositivos activos, los gestionados, etc. y sus posibles combinaciones.
A todas estas ¿cuál ventaja supone el utilizar phpIPAM?
phpIPAM
Existe una gran variedad de software disponible para trabajar con IPAM y en este artículo veremos con detenimiento el software phpIPAM como una herramienta auxiliar pero primero repasaremos los conceptos que envuelven las direcciones IP ya que no es cualquier cuestión baladí: sin este concepto abstracto el Internet no sería posible, ¡la monitorización muchísimo menos!
Introducción.
Hoy en día en todas las empresas -e incluso es bastante probable que en cada hogar- existe una red de área local. En los albores del Internet se planificó el sistema de direcciones IP de tal manera que se hizo la previsión de reservar tres clases de redes para uso privado en las redes de área local. Dichas direcciones se denominan direcciones privadas y evidentemente se puede repetir en cada diferente empresa y/o cada diferente hogar. Es decir, a lo interno, cada organización puede por medio de estas direcciones privadas conectar sus dispositivos y hasta cada dispositivo pudiera tener una o más direcciones IP (por ejemplo, un ordenador portátil puede estar conectado por cable ethernet, por su antena «wifi» integrada y además una antena «wifi» conectada por puerto USB; generalmente los servidores web son redundantes y tiene 2 conexiones ethernet para tráfico de datos y al menos una conexión ethernet para monitorización).
Las direcciones, de hecho, estarán repetidas en cada organización pero no hay ningún problema porque no están conectadas entre sí… y aquí es donde viene el Internet, la interconexión de las redes privadas por medio del protocolo de traslado de direcciones (NAT) ya que en Internet cada dirección IP pública es única y los enrutadores obtienen una dirección IP pública la cual «comparten» hacia lo interno de cada organización.
La práctica numérica (calculadoras IP).
¿Cuántas direcciones IP necesitamos en nuestra organización? Pues dijimos que hay tres clases para uso privado:
- Clase A: 10.0.0.0 a 10.255.255.255 (8 bits red, 24 bits anfitrión).
- Clase B: 172.16.0.0 a 172.31.255.255 (16 bits red, 16 bits anfitrión)
- Clase C: 192.168.0.0 a 192.168.255.255 (24 bits red, 8 bits anfitrión)
Dicho rápidamente, la clase A permite una sola red con millones de direcciones IPv4, la clase B permite 16 redes y cada una de ellas con miles de direcciones IP y la clase C permite cientos de direcciones IPv4 (exactamente 253 porque 0 y 255 tienen otros usos que veremos más adelante). Existen otras clases de redes que para este artículo no representa mayor relevancia, la clase D para multidifusión «multicast«y clase E para investigación y desarrollo.
Ahora bien, en la realidad, para nuestras mentes, las redes clase C se adaptan a nuestras necesidades en el hogar y en las pequeñas empresas y llevar cuenta de una o dos docenas de dispositivos en el enrutador que comparte una dirección IP pública para toda la red privada es fácil y práctico de llevar y administrar.
Pero en los otros casos, miles y hasta millones de direcciones IP es una auténtica pesadilla, una empresa muy laboriosa. Para estos casos tenemos que seguir exactamente los mismos pasos que hizo la Corporación de Internet para la Asignación de Nombres y Números («Internet Corporation for Assigned Names and Numbers», ICANN por sus siglas en inglés): asignar a cada uno de los departamentos una subred y delegar así la autoridad en los jefes de departamento. Pero anotar y registrar todo ello sobrepasa fácilmente las capacidades de una hoja de cálculo y he aquí que entra en acción -y con ese motivo fue desarrollado- nuestro software de estudio el día de hoy, phpIPAM.
Breve historia de phpIPAM.
La primera versión pública fue la 0.1 y para noviembre de 2014 phpIPAM lanza su versión 1.1 de la mano y obra del señor Miha Petkovsek, en enero de 2016 la versión 1.2 y en julio de 2017 se liberó la versión 1.3. A noviembre de 2017 apenas ha llegado a la versión 1.3.1 y eso habla mucho de lo bien pensado cuando se diseñó originalmente. De hecho esa versión 1.1 tiene gran cantidad de características y correcciones y como bien lo dice el refrán «experiencia es el nombre que la gente da a sus propios errores».
Está desarrollado bajo la modalidad de software libre, licencia GNU 3 desde junio de 2015 cuando se mudaron los repositorios a GitHub y al parecer su fuente de financiamiento son las donaciones, tanto de dinero como alojamiento web ya que este software resulta muy beneficioso para los que proveen acceso a Internet y/o las empresa que ofrecen alojamiento web. De hecho la página demostrativa está en una máquina virtual dedicada, cortesía de una empresa de webhosting. Este modelo de software libre ha reunido una muy selecta comunidad por lo que de fama goza muy poca el phpIPAM y es difícil hallar información al respecto: aquí en este artículo arrojamos un poco de luz sobre el asunto.
Instalación de phpIPAM.
A diferencia de los detalles históricos, hay muchos tutoriales sobre phpIPAM en la red, unos mejores que otros; nosotros lo probamos sobre Ubuntu 16 y de allí obtuvimos las capturas de imágenes que apreciáis. Lo primero que hicimos al finalizar la instalación fue subir nuestro propio logo para efectos de evaluación y rellenar los datos que identifican a nuestro servidor de prueba incluyendo el envío de correo electrónico lo cual es muy importante para recibir las alertas, que no son tan frecuentes debido a la naturaleza del trabajo.
En resumen se necesita un servidor de base de datos MySQL, un servidor web Apache, los adecuados permisos de muro de fuego firewall para cuando hagamos una exploración de nuestra red o redes de área local… e incluso las subredes, lo que nos lleva al siguiente punto.
Subredes (o mejor dicho: cómo funciona phpIPAM).
No todos trabajamos con empresas de alojamiento web o proveedoras de acceso a Internet por lo que los ejemplos aquí tratados se basan en las direcciones privadas que describimos al principio. Os aseguramos que todo lo aquí descrito se aplica en la Internet y hay organizaciones «haciendo dinero» con ayuda de phpIPAM, quien a su vez también dona la FreeBSD Foundation, así que todo esto es un ciclo sin fin.
Las tareas de phpIPAM es llevar cuenta (y almacenar la información en una base de datos MySQL) de:
- Nuestros dispositivos y sus direcciones IP.
- Nuestros armarios o racks de ordenadores
- Nuestros circuitos (con ayuda de las API de Google Maps)
- Soporta autenticación por LDAP lo cual ya nos va ahorrando trabajo.
- Llevar registro de las redes privadas virtuales.
- Las NATs que tengamos creadas para que nuestros equipos se conecten a lo externo.
- ¡Incluso tiene para uno hacer anotaciones al resto del grupo en una suerte de micro Wikipedia! (aunque no la recomendamos para llevar una gestión de incidencias tal vez se podría llevar en orden cronológico tipo causa/efecto/solución para no tropezar dos veces con las mismas piedras).
- También las subredes que tengamos creadas.
Para hablar de las subredes, tarea rutinaria y de difícil sincronización entre equipos de trabajo, primero tenemos que explicar cómo se manejan y el por qué su razón de ser. En los lejanos años de 1980 los artefactos que se encargaban de conectar a la Internet, eran dispositivos muy básicos y se necesitaba que, además, fueran rápidos recibiendo y enviando la información. Surgió así la necesidad de crear subredes de trabajo pero los equipos no contaban con la tecnología necesaria y con recursos de memoria muy limitados. La solución fue crear máscaras de subred como una manera de que dichos dispositivos pudieran discernir de manera rápida si el mensaje o datagrama recibido pertenecía a la subred que le habían designado para trabajar.
Es por ello que la máscara permite distinguir en la dirección IP la parte que identifica la red de la parte que identifica al dispositivo pero con la salvedad que lo hace con números binarios. Las máscaras de red tienen el mismo formato de las direcciones IPv4 pero siempre con valores para cada octeto siempre a uno, por ejemplo la máscara de red para una red privada clase A que vayamos a crear en phpIPAM sería la siguiente:
11111111.00000000.00000000.00000000
O sea, en notación decimal, 255.0.0.0 ya que nuestra red privada puede así contener millones de direcciones IPv4 (la multiplicación de los tres últimos octetos 255 x 255 x 255 = 16581375 aproximadamente porque las dirección cero identifica la red y 255 se utiliza para multidifusión). Ahora imaginemos que sí, que es posible que tengamos en nuestra organización al menos un millón de dispositivos ¿cómo harían los aparatos para mantener el transporte y envío de los paquetes o datagramas con tal volumen de usuarios?
La solución práctica de aquella época fue aplicar una operación AND (una operación AND es una simple multiplicación) a cada dirección de paquete y la máscara de red y así podremos determinar si es para la red -o subred, ya veremos más adelante-. Supongamos de un paquete va dirigido a 10.0.7.23 en nuestra red privada clase A
00000010.00000000.00000007.00010111 <-paquete dirigido a 10.0.7.23 11111111.00000000.00000000.00000000 <- máscara de red 255.0.0.0 00000010.00000000.00000000.00000000 <-oper. AND resulta 10.0.0.0 (multiplicación) (¿recuerdan que los ceros en los tres últimos octetos representan a nuestra red?)
Acá hay algo que está implícito: nuestra máscara de red, «la que escogimos» está implícita porque una red clase A el primer octecto identifica a la red, o sea 8 caracteres por lo que en una notación llamada CIDR (que implica la dirección de nuestra red y la máscara de red juntas) se representa de la siguiente sencillamente de la siguiente manera: 10.0.0.0/8
Creación de una subred privada.
Ahora pongamos por caso que en nuestra red privada clase A necesitamos una subred donde colocaremos las máquinas para nuestras pruebas de programación. Para ello 253 direcciones IPv4 son más que suficientes así que de mutuo acuerdo con nuestro equipo de trabajo nos asignan 10.0.0.0/24 esto quiere decir que en la red privada clase A 10.0.0.0 tendremos asignada una máscara de red 255.255.255.0 y volviendo al ejemplo numérico último, pero con nuestra máscara de red:
00000010.00000000.00000111.00010111 <-paquete dirigido a 10.0.7.23 11111111.11111111.11111111.00000000 <- máscara de red 255.255.255.0 00000010.00000000.00000111.00000000 <-oper. AND resulta 10.0.7.0 (no es nuestra red, nuestra red está identificada como 10.0.0.0)
Subred pública.
A finales de siglo paso pronto nos dimos cuenta que las direcciones IPv4 estaban agotándose debido al crecimiento exponencial del Internet, así que la ICANN se percató que a muchos Proveedores de Internet («Internet Service Providers» o ISP) se le asignaron bloques muy grandes lo cual ocasionó direcciones IPv4 ociosas. La decisión, pues, fue salomónica: asignar mediante máscaras de red para cada proveedor a fin de ajustar al tamaño adecuado y aunque no lo creáis ellos (sus ordenadores) hacen estos cálculos millones de veces al día: comparar direcciones contra máscaras de red para saber si están en su subred (hoy en día, en realidad, hay otros mecanismos implementados en los ahora existentes módems, enrutadores, concentradores y repetidores pero el concepto básico sigue siendo el mismo). Por eso comentamos que muchas organizaciones se benefician del uso de phpIPAM para registrar y planificar las direcciones asignadas.
Subredes con máscara de longitud variable.
Si han comprendido hasta este punto lo que hemos explicado de la manera más didáctica posible, incluso que puede escandalizar a algunos académicos y/o profesionales podemos avanzar al concepto de máscaras de red de longitud variable: tan sencillo como que no están limitadas a los valores por octetos (8, 16 y 24) sino a cualquier otro valor, como por ejemplo 10.0.0.0/28 para nuestro ejemplo (os dejamos esta para que practiquéis con vuestra calculadora IP).
Creación de usuarios y grupos en phpIPAM.
A pesar de la larga introducción, necesaria base conceptual, comenzamos con recomendar que al trabajar con phpIPAM se comience con la creación de grupos y luego de usuarios. Por defecto phpIPAM trae por defecto dos grupos creados: grupo de administradores y grupo de invitados. Esto simplemente nos permitirá agrupar nuestros usuarios a la hora de una búsqueda o visualización o para tener en nuestra mente algún tipo de orden pero solo eso, es decir no provee ninguna otra utilidad derechos de escritura y/o escritura ni tampoco su herencia.
En la parte de creación de usuarios sí que tendremos el panorama completo: crear un usuario como usuario normal o administrador a la vez que nos mostrará los grupos que hayamos creado (recordando que no es vinculante la descripción del grupo con su clasificación de usuario, un grupo que se describa como «Administradores Remotos» no significa que sus usuarios tengan derechos de Administradores). Muchas veces la simplicidad es bienvenida, con utilizar los dos grupos que vienen creados podremos trabajar, a menos que la organización sea extraordinariamente grande, cosa difícil porque repetimos: aquí los usuarios somos pocos y muy selectos para trabajar en el área de administración y planeamiento de las direcciones IP.
Al crear un usuario nos mostrará la manera sobre cómo se autenticarán nuestros usuarios y solo veremos dos opciones: por base de datos local y por Apache que es un método anticuado y basado en ficheros que no recomendamos. Nuestra elección natural será por LDAP sin embargo primero deberemos activar en nuestro servidor Apache la librería php-ldap y reiniciar el servicio. En total son siete formas de autenticación posibles:
- Local.
- Apache.
- Active Directory (AD).
- LDAP.
- NetIQ.
- Radius.
- SAMLv2.
Calculadora IP.
Una vez hayamos abonado el terreno para trabajar podremos crear nuestras redes y subredes. La manera más fácil que observamos es ir a la calculadora IP integrada, introducir nuestro CIDR asignado o el que nosotros mismos crearemos en el caso de las redes privadas: phpIPAM calculará y mostrará todos los valores y se ofrecerá a crear una red con ese resultado e incluso sus subredes. Acotación importante: si se solapan algunas subredes o subredes phpIPAM nos lo indicará en un hermoso aviso de letras rojas.
Una vez hayamos colocado correctamente los valores CIDR podremos asignar a los grupos de usuario los derechos correspondientes sobre esa red o subred (notar que aquí sí se heredan los derechos de manera opcional). ¡Aquí resaltamos de nuevo la curiosa manera de manejar los derechos de lectura y escritura en phpIPAM!
Exploración de dispositivos en phpIPAM.
Para facilitar las labores de agregado phpIPAM tiene la utilidad de utilizar el programa ping para contactar a los dispositivos a nuestra red o subred creada previamente, pero acá viene lo interesante, dos maneras más una para los dispositivos que ya tengamos y otra para los nuevos dispositivos:
- Por medio de agentes: esto es similar a Pandora FMS, es decir, un software instalado en cada máquina y adecuado al sistema operativo presente. En ambiente Windows el Active Directory nos permitirá masificar dicha tarea y en GNU/Linux por SSH y guiones bien diseñados podremos manejar a voluntad cientos o incluso miles de máquinas.
- Aquí lo novedoso y muy útil:
- Podremos al instalar nuevos dispositivos configurarlos con el nombre de la red o subred.
- Con su respectivo guion se conecte con la API de phpIPAM.
- Consulta la última dirección IP libre de ese rango.
- Se auto asigne dicho valor.
- Confirma a phpIPAM y queda registrado en la base de datos MySQL.
- De esta manera phpIPAM se convierte en una especie de DHCP con la diferencia que solo se consulta una sola vez: cuando se instala la máquina o dispositivo virtual (también puede ser real, aplica igual pero evidentemente que un ser humano está encargado del proceso, esto sucedería al montar los «racks» de la granja de servidores, los cuales a su vez contienen las máquinas virtuales ¿se ubican?).
- El concepto es poderoso para ahora los tiempos que corren, que estamos de lleno con máquinas virtuales que incluso pueden levantar nuestros propios clientes a voluntad en nuestras granjas de servidores (cada quien que escoja su sistema operativo para el hipervisor que tengamos configurado con phpIPAM).
- Por supuesto también incluye rutinas de eliminación, en caso de que los dispositivos virtuales sean borrados o los dispositivos reales sean mudados o desincorporados de su labor.
phpIPAM: herramienta auxiliar.
En la sección anterior estriba el principal funcionamiento como herramienta auxiliar de phpIPAM pero el asunto no termina allí ya que también puede registrar nuestros servidores DNS, el monitoreo de direcciones IP ociosas así como dispositivos en funcionamiento o no con un simple ping, fping o pear ping.
También incluye el utilizar agentes, registrar y administrar NATs así como un monitoreo básico con SNMP pero primero deberemos configurar nuestro servidor Apache con el módulo php-snmp y luego configurar los dispositivos a monitorear y/o consultar. Incluso nos permitirá crear SNMP traps, los cuales son útiles para la creación de alertas de eventos. Para una mejor compresión en este vuestro blog dedicamos una entrada completa sobre los aspectos básicos a consultar por medio de SNMP.
phpIPAM: exportar e importar datos.
Ya para finalizar, phpIPAM tiene la opción de importar o exportar datos en formato de hoja de cálculo de las secciones que necesitemos o bien podremos exportar (más no importar) la base de datos completa en formato SQL ¡o en una gran hoja de cálculo!
En el caso de la importación de datos debemos seguir un protocolo bien detallado, a fin de tener una compatibilidad exacta de los datos:
Automatización en la exportación de datos.
Aunque la opción de hoja de cálculo está disponible, recomendamos el desarrollar por medio de la API unos guiones que permitan extraer datos actualizados y saber si han habidos cambios en la red y cuáles son esos cambios, si hemos agregado o quitados dispositivos, nosotros mismos o nuestros clientes a quienes les hayamos delegado la creación de máquinas virtuales y así poder monitorizar con Pandora FMS la infraestructura completa.
Para ir un paso más allá también podríamos crear un complemento o plugin para Pandora FMS que consulte directamente en la base de datos en busca de cambios pero es un tema avanzado, no sería un plugin normal (evidentemente que con derechos de solo lectura, siempre de phpIPAM hacia Pandora FMS).
Conclusión.
Para poder monitorizar con Pandora FMS debemos, primero que nada, tener qué monitorizar. Avizoramos un gran futuro si con phpIPAM, creado en software libre y al cual tenemos acceso a su código fuente, logramos obtener datos sobre qué dispositivos debemos monitorear de una manera casi completamente automatizada, manteniendo a los equipos de planificación y desarrollo de infraestructura completamente separados del equipo de monitoreo y mantenimiento. Visualizamos entonces, ¡una excelente relación simbiótica entre ambos productos de software!
Por favor déjanos tus comentarios u opiniones y gustosamente os responderemos.