Herramienta para la monitorización de redes privadas basada en sondas

Equation Chapter 1 Section 1 Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Herramienta para la monitorización de redes privadas basada en sondas Autor: Alejandro Rodríguez Chavarría Tutor: Vicente Jesús Mayor Gallego Dpto. Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 20 2 5 II III Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Herramienta para la monitorización de redes privadas basada en sondas Autor: Alejandro Rodríguez Chavarría Tutor: Vicente Jesús Mayor Gallego Profesor Ayudante Doctor Dpto. de Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2025 IV V Trabajo Fin de Grado: Herramienta para la monitorización de redes privadas basada en sondas Autor: Alejandro Rodríguez Chavarría Tutor: Vicente Jesús Mayor Gallego El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: Presidente: Vocales: Secretario: Acuerdan otorgarle la calificación de: Sevilla, 2025 El Secretario del Tribunal VI VII A mi familia A mis maestros A mis compañeros VIII IX Agradecimientos El hecho de escribir estas líneas y la presente memoria significa un hito muy importante en mi vida en todos los ámbitos. Todo se remonta a una tarde de verano de 2019, cuando recién acabado Bachillerato y sin saber que haría en el futuro, comenzó este viaje en el momento que descubrí la ingeniería de telecomunicaciones. Fue gracias a una divertida historia, pero sobre todo a mi interés por las tecnologías desde pequeño por lo que decidí adentrarme en esta etapa tan desafiante. Una etapa que está por finalizar muy pronto y que me convertirá en un profesional dedicado al campo de las telecomunicaciones, un objetivo que persigo desde el primer día que estuve en la Escuela Técnica Superior de Ingeniería de Sevilla. Estos años han estado llenos de experiencias, positivas y negativas, que me han hecho desarrollarme en lo personal y no solo en lo académico, pero sobre todo han estado llenos de mucho aprendizaje y conocimiento que cada vez más me hacen sentirme orgulloso de la decisión que tomé al elegir este grado. Experiencias que me han enseñado que las cosas pueden llegar a costar mucho (más de lo que uno piensa), pero que cuando las consigues es de las mejores sensaciones que se pueden tener, no hay nada tan gratificante como aprobar ese examen que tantos intentos te ha costado. Pero por supuesto no todo es un camino fácil, detrás de todos los logros conseguidos hasta ahora quedan también días duros de mucho trabajo y poco descanso, también momentos de estrés y mucha frustración. Quiero agradecer enormemente y de corazón a mis padres, porque hoy nada sería igual sin ellos. Su incansable esfuerzo y sacrificio para poder ayudarme todos estos años está siendo muy importante y está consiguiendo que el día de mañana me convierta en ingeniero. No me puedo olvidar de mi hermano y Laura, que gracias a ellos tuve donde pasar mi primer año en Sevilla fuera de casa para poder ir cada día a la escuela. Gracias a ellos empecé a aprender a manejarme por mí solo en el día a día y se me hizo más fácil adaptarme a vivir en una ciudad. Mis más sinceros agradecimientos al resto de mis familiares, que me han ayudado cuando lo he necesitado. Y a mis abuelos por educarme desde pequeño junto a mis padres y hacer que hoy sea como soy. Gracias a mis amigos y compañeros, con los que he compartido momentos de estudio, exámenes, pero sobre todo muchas risas. Los primeros años fueron los más amenos gracias a ellos, y hacían que las semanas fueran más entretenidas. Tristemente, no hemos seguido el mismo ritmo estos últimos años y su falta se ha notado. Pero cada año han ido surgiendo nuevas amistades de las que estoy muy feliz. Estoy seguro de que conseguirán su objetivo, y espero que nuestros caminos se vuelvan a cruzar profesionalmente como ya pasó durante el grado. Mis más profundos agradecimientos a todos mis profesores y maestros desde que era pequeño, por enseñarme lo que es el esfuerzo y la constancia y por descubrirnos el mundo con sus enseñanzas y conocimientos, pero sobre todo por motivarnos a buscar nuestro propósito en la vida. Quiero hacer mención especial a los grandes profesionales que he tenido como profesores en este grado, especialmente a Juan Manuel Vozmediano y mi tutor Vicente Jesús, que han hecho que me apasione por la telemática. También quiero agradecer a mi tutor por su ayuda con este proyecto y a Álvaro, autor de dockerlab, por ayudarme con el uso de su herramienta. Por último, gracias a Belén, una persona que me ha cambiado la vida desde que nos conocimos y que está siendo un apoyo incondicional desde entonces en mi transcurso por este grado, tanto en lo emocional como en lo académico. Una persona envidiable y encantadora, y que orgullosamente digo que es la mejor ingeniera de telecomunicaciones del mundo. Alejandro Rodríguez Chavarría Sevilla, 2025 XVI ÍNDICE DE TABLAS Tabla 1–1. Tabla comparativa de las distintas herramientas de monitorización 4 Tabla 1–2. Duraciones de las fases del proyecto 6 Tabla 2–1. RF-001 7 Tabla 2–2. RF-002 8 Tabla 2–3. RF-003 8 Tabla 2–4. RF-004 8 Tabla 2–5. RF-005 9 Tabla 2–6. RF-006 9 Tabla 2–7. RF-007 9 Tabla 2–8. RF-008 10 Tabla 2–9. RF-009 10 Tabla 2–10. RF-010 10 Tabla 2–11. RF-011 11 Tabla 2–12. RNF-001 11 Tabla 2–13. RNF-002 11 Tabla 2–14. RNF-003 12 Tabla 2–15. RNF-004 12 Tabla 2–16. RNF-005 12 Tabla 2–17. RNF-006 13 Tabla 2–18. RNF-007 13 Tabla 2–19. Tabla de definición de la API REST 20 XVII XVIII ÍNDICE DE ILUSTRACIONES Ilustración 2–1. Esquema escenario real 14 Ilustración 2–2. Diagrama de secuencia del handshake inicial 16 Ilustración 2–3. Diagrama de secuencia de la operación del sistema 18 Ilustración 2–4. Diagrama de secuencia de la autenticación de la sonda 19 Ilustración 3–1. Diagrama de flujo del coordinador 22 Ilustración 3–2. Diagrama de flujo de la sonda 27 Ilustración 3–3. Estructura general de directorios 39 Ilustración 3–4. Estructura de /escenario1 40 Ilustración 3–5. Estructura de /escenario2 41 Ilustración 3–6. Estructura de /escenario3 42 Ilustración 3–7. Estructura de /srcdocker 43 Ilustración 4–1. Esquema escenario 1 49 Ilustración 4–2. Estado inicial de /escenario1 50 Ilustración 4–3. Ejecución del escenario 1 50 Ilustración 4–4. Terminales del escenario 1 50 Ilustración 4–5. Ficheros generados en el escenario 1 51 Ilustración 4–6. Esquema escenario 2 51 Ilustración 4–7. Estado inicial de /escenario2 52 Ilustración 4–8. Creación del escenario 2 52 Ilustración 4–9. Estado final de /escenario2 52 Ilustración 4–10. Despliegue de los contenedores 53 Ilustración 4–11. Logs del coordinador y las sondas 53 Ilustración 4–12. Volúmenes creados y su contenido 54 Ilustración 4–13. Esquema escenario 3 54 Ilustración 4–14. Creación del escenario 3 55 Ilustración 4–15. Logs del coordinador en el escenario 3 55 XIX XX ÍNDICE DE CÓDIGOS Código 3–1. Imports y variables globales del coordinador 22 Código 3–2. Función receiveKeepalive() 23 Código 3–3. Función sendToken() 23 Código 3–4. Función sendConfig() 24 Código 3–5. Función recibeInforme() 24 Código 3–6. Función enviarTurno() 25 Código 3–7. Función funcIperf() 25 Código 3–8. Función checkAlive() 25 Código 3–9. Arranque del programa 26 Código 3–10. Imports y variables globales de la sonda 27 Código 3–11. Función initProbe() 28 Código 3–12. Función getToken() 28 Código 3–13. Función getConfig() 28 Código 3–14. Función mandarKeepalive() 29 Código 3–15. Función pruebaICMP() 29 Código 3–16. Función pruebaDNS() 30 Código 3–17. Función pruebaTCP() 30 Código 3–18. Función pruebaHTTP() 31 Código 3–19. Función pruebaIperf() 32 Código 3–20. Arranque del programa 33 Código 3–21. Fichero de configuracion de pruebas 34 Código 3–22. Fichero de configuración de la red Docker del escenario 2 35 Código 3–23. Fichero de configuración de la red Docker del escenario 3 35 Código 3–24. Fichero requirements.txt 37 Código 3–25. Shell-script crea.sh 43 Código 3–26. Shell-script ejecuta.sh 44 Código 3–27. Shell-script elimina.sh 45 Código 3–28. Volúmenes del coordinador 46 Código 3–29. Volúmenes de la sonda 46 XXI 1 1 INTRODUCCIÓN as redes de comunicación son esenciales en el mundo moderno, facilitando la conexión y el intercambio de datos entre dispositivos a nivel global. Estas redes abarcan desde las redes de área local (LAN), que interconectan dispositivos dentro de un mismo espacio físico como una oficina o un hogar, hasta las redes de área amplia (WAN), que cubren grandes distancias y permiten la comunicación entre distintas regiones o países. En este vasto ecosistema, las redes privadas juegan un papel crucial al proporcionar un entorno seguro y exclusivo para la transmisión de datos dentro de una organización o grupo específico, garantizando la protección de la información y el control sobre el acceso a los recursos compartidos. Este Trabajo de Fin de Grado presenta una herramienta diseñada para la monitorización de redes privadas, NetWatcher. Utilizando sondas distribuidas que realizan pruebas de rendimiento de la red periódicamente, midiendo parámetros como latencia y ancho de banda, entre otros. Los resultados obtenidos por estos equipos se envían a un equipo coordinador central, que llevará un registro de estos resultados distinguiendo el origen de cada prueba. Implementado con Python, Flask y Docker, este sistema facilita la configuración, análisis y optimización de redes, mejorando la gestión y la detección de problemas en entornos privados. 1.1. Objetivos La finalidad de esta herramienta es permitir la monitorización y estudio de redes privadas para obtener conclusiones del rendimiento de la red. Con esto podemos realizar funciones relacionadas con la gestión de redes para mantenerlas y mejorar el rendimiento de éstas. Los objetivos más destacados serían:  Detección de Problemas de Rendimiento: La herramienta realiza pruebas periódicas de rendimiento midiendo parámetros como la latencia o el ancho de banda para identificar posibles cuellos de botella o degradaciones en el servicio. Detectar estos problemas de manera temprana permitirá a los administradores de red tomar medidas correctivas antes de que afecten significativamente a los usuarios.  Optimización de Recursos: Al analizar los datos recopilados, la herramienta puede proporcionar información sobre el rendimiento de la red, permitiendo a los administradores ajustar la asignación de recursos y optimizar el rendimiento general. Esto puede incluir la redistribución de ancho de banda, la optimización de configuraciones de red y la actualización de hardware o software.  Análisis de Tendencias: La herramienta permite realizar un seguimiento histórico del rendimiento de la red, facilitando el análisis de tendencias y patrones a lo largo del tiempo. Este análisis puede ayudar a predecir problemas futuros, planificar mejoras y evaluar el impacto de cambios recientes en la red.  Generación de Informes Detallados: La capacidad de generar informes detallados sobre el estado y el rendimiento de la red ayuda a los administradores a comprender mejor las condiciones actuales y a tomar decisiones basadas en datos concretos. Estos informes podrían incluir métricas clave, gráficos de rendimiento y análisis de problemas recurrentes.  Prevención de Fallos: Al identificar anomalías y problemas de manera proactiva, la herramienta ayuda a prevenir fallos graves en la red. La detección temprana de problemas permite implementar soluciones antes de que se conviertan en fallos críticos que podrían afectar la operatividad de la red. L Cualquier tecnología lo suficientemente avanzada es indistinguible de la magia. - Arthur C. Clarke - Introducción 2 2  Mejora Continua: La retroalimentación obtenida del análisis de datos facilita la implementación de estrategias de mejora continua. Los administradores pueden así ajustar las configuraciones de red, actualizar equipos y modificar políticas en función de la información obtenida para asegurar que la red se mantenga en óptimas condiciones. 1.2. Estado del Arte Veamos a continuación herramientas similares de monitorización y en que se diferencian y asemejan del proyecto realizado para este Trabajo Fin de Grado. Lo compararemos con tres herramientas muy utilizadas hoy en día, mostrando las principales características en una tabla comparativa para mayor visualización y claridad de las diferencias y similitudes. 1.2.1 UptimeRobot UptimeRobot es un servicio de monitoreo de sitios web que permite a los administradores y desarrolladores controlar el estado de sus páginas y aplicaciones en línea. Su propósito principal es asegurarse de que un sitio web esté funcionando correctamente y notificar a los usuarios si el sitio experimenta algún tiempo de inactividad o interrupciones en el servicio. Utiliza nodos monitores distribuidos por el mundo para minimizar los fallos de precisión que pudieran ocurrir en las mediciones. Este servicio no exige apenas rendimiento a los equipos ya que está desplegado en la nube y posee una web con una interfaz de usuario amigable que permite seguir la monitorización en tiempo real. UptimeRobot verifica periódicamente si el sitio web, servidor o servicio monitorizado está en línea y funcionando correctamente. Además, es capaz de medir métricas de HTTP/S, ping, DNS, puertos TCP, palabras clave de un sitio web (keywords), SSL, cron jobs y parámetros SNMP. También puede enviar alertas instantáneas por varios medios (correo electrónico, SMS, etc) cuando un sitio web se cae o vuelve a estar en línea. Además, proporciona informes detallados sobre la actividad y estado del sitio web, ayudando a analizar el rendimiento general e identificar patrones de fallos. Dispone de una API que permite a los desarrolladores implementar el servicio en aplicaciones y herramientas propias, y además ofrece distintos planes de suscripción premium con diferentes ventajas, incluyendo también un plan gratuito. [4] 1.2.2 Uptime-Kuma Uptime-Kuma es una herramienta de monitoreo de uptime de código abierto, diseñada para permitir a los usuarios monitorear la disponibilidad de sitios web y servicios de una manera fácil y personalizable. Su popularidad ha crecido debido a su interfaz amigable y la flexibilidad que ofrece al ser autoalojada. UptimeKuma es relativamente liviano y puede ejecutarse en servidores de baja especificación, como una Raspberry Pi o servidores virtuales pequeños (VPS). Sin embargo, para grandes infraestructuras, se recomienda un servidor con más recursos, especialmente si se monitorean muchos servicios en intervalos cortos. Generalmente la instalación es en local, pudiendo ser desplegado en Docker o en el propio equipo. En este último caso son necesarios una serie de requisitos para su correcta instalación, que pueden consultarse en el repositorio oficial cuyo enlace se encuentra en la bibliografía de este documento. En el repositorio también se encuentran los pasos a seguir para lograr la instalación en ambos casos. También puedes desplegar Uptime-Kuma en servidores cloud como AWS, DigitalOcean, Linode, o cualquier proveedor de VPS, siempre que puedas ejecutar contenedores Docker o Node.js. Esta herramienta es completamente gratuita, ya que se trata de un proyecto de código abierto. La única inversión requerida sería la del servidor donde se aloje. Todas las comprobaciones y monitoreos se realizan desde el servidor en el que está instalado. Esto significa que el monitoreo proviene de una única ubicación, lo cual puede ser suficiente para muchos casos de uso, pero puede no detectar problemas regionales en diferentes partes del mundo. No obstante, dado que es autoalojado, puedes configurar múltiples instancias en diferentes ubicaciones para simular una red de sondas distribuidas. 3 3 Herramienta para la monitorización de redes privadas basada en sondas Uptime-Kuma tiene una interfaz web muy moderna y fácil de usar, donde se pueden ver todas las métricas y servicios que están siendo monitorizados. Además, ofrece gráficos y visualizaciones de los datos históricos de uptime, lo que facilita la identificación de patrones o problemas de disponibilidad. También es capaz de generar alertas y notificarlas por una gran variedad de medios (+90). Por último, mide métricas de HTTP/S (entre ellas, keywords y JSON queries), TCP, ping, DNS, push, servidores de Steam y contenedores Docker. [5] 1.2.3 Grafana Grafana es una plataforma de código abierto utilizada para la observación, monitoreo y análisis de datos, especialmente diseñada para crear paneles visuales interactivos que permiten a los usuarios visualizar métricas en tiempo real y a lo largo del tiempo. Grafana es altamente personalizable y flexible, lo que lo convierte en una herramienta fundamental en entornos de monitoreo de infraestructura y aplicaciones. Una de sus mayores fortalezas es que permite a los usuarios extraer datos de múltiples fuentes, agregarlos y visualizar diferentes métricas clave en un único panel de control. Puede ejecutarse en entornos tanto de baja como de alta complejidad. Los requisitos de hardware dependen en gran medida del tamaño de la infraestructura que se desee monitorizar y la cantidad de datos que se gestionen. Para implementaciones pequeñas, un servidor modesto con 2-4 GB de RAM suele ser suficiente. Sin embargo, para entornos de monitoreo grandes con varias fuentes de datos y alta frecuencia de consultas, se recomienda utilizar hardware más robusto, como servidores con más núcleos de CPU y mayor cantidad de memoria RAM. Grafana puede instalarse en servidores locales utilizando distribuciones de Linux, Windows, o contenedores Docker. También está disponible como servicio en la nube (Grafana Cloud), y en clústeres de Kubernetes. Es gratuito y de código abierto, pero también ofrece planes de pago con características avanzadas. La versión gratuita open-source ofrece todas las funcionalidades básicas, lo que incluye la creación de paneles y alertas, junto con la integración de múltiples fuentes de datos. Los planes incluyen funcionalidades adicionales como mayor retención de datos, usuarios ilimitados, alertas avanzadas y soporte técnico prioritario. Los planes de pagos están diseñados para empresas que necesitan escalabilidad y funciones empresariales. Grafana no está basado directamente en sondas (como en otros sistemas de monitoreo), pero puede ser usado en conjunto con sistemas que sí utilizan sondas, como Prometheus. Esto permite monitorizar aplicaciones distribuidas y obtener datos desde diferentes ubicaciones geográficas y redes. Prometheus utiliza sondas para recolectar datos de diferentes partes del sistema, que luego son visualizados y gestionados dentro de Grafana. Uno de sus puntos fuertes es la interfaz de usuario web que posee, altamente intuitiva y personalizable. Permite a los usuarios crear paneles que muestran visualizaciones interactivas de los datos en tiempo real. Además, Grafana permite compartir paneles con otros usuarios. Grafana puede visualizar una amplia gama de métricas según las fuentes de datos conectadas, como la disponibilidad y el rendimiento de sitios web y APIs a través de HTTP/S, la correcta resolución de registros DNS, y diversas métricas del sistema operativo como CPU, memoria y disco. Además, puede mostrar logs de aplicaciones, especialmente cuando se integra con Loki, monitorizar consultas SQL y el rendimiento de bases de datos, y trabajar eficazmente con bases de datos de series temporales como Prometheus, que captura datos a lo largo del tiempo. También permite añadir métricas personalizadas por el usuario mediante sus integraciones. [6] 1.2.4 NetWatcher Detallemos en más profundidad las características del proyecto desarrollado para este Trabajo Fin de Grado. NetWatcher es una herramienta de monitorización de redes privadas basada en sondas, está pensada para desplegarse en varias sondas situadas en distintos lugares de la red, aunque también se puede implementar en un entorno Docker. Su desarrollo es motivo de la necesidad de estudiar el rendimiento de las redes privadas, midiendo parámetros de importancia, realizando pruebas con cada sonda y recolectando los resultados de éstas en el equipo del coordinador. Puede desplegarse en casi cualquier equipo, pues no requiere un gran rendimiento por parte de éstos. Además, posee una interfaz de usuario interactiva y simple usando la línea de comandos. Diseño 10 10 Estado Implementado Tabla 2–8. RF-008 RF-009 Detención del funcionamiento Descripción Una sonda deberá parar sus procesos si se introduce ‘q’ por teclado. En el caso del coordinador, se hará con la combinación de teclas Ctrl+C Datos específicos Si una sonda o el coordinador es un contenedor de Docker, se detendrá con Ctrl+C. Importancia Baja Prioridad Baja Estado Implementado Tabla 2–9. RF-009 RF-010 Generación de informes Descripción El coordinador generará un informe por cada tipo de prueba con los datos de las métricas medidas en las pruebas por cada sonda Datos específicos  Cada informe permitirá distinguir qué sonda ha mandado sus resultados  Cada sonda enviará los resultados de cada prueba cada vez que se realicen, además de la fecha y hora en que se completó la prueba Importancia Muy alta Prioridad Alta Estado Implementado Tabla 2–10. RF-010 RF-011 Gestión de turnos de la prueba Iperf Descripción El coordinador gestionará cuando le toca a cada sonda realizar la prueba de Iperf Datos específicos Debido a la naturaleza de Iperf, es necesario que sólo 1 sonda realice la prueba al mismo tiempo. Por tanto, el coordinador se encargará de crear una lista de espera con turnos para mantener un orden, permitiendo que las pruebas Iperf se completen correctamente Importancia Muy alta Prioridad Alta Estado Implementado 11 11 Herramienta para la monitorización de redes privadas basada en sondas Tabla 2–11. RF-011 2.1.2 No funcionales En cuanto a los requisitos no funcionales, aquellos que definen características de calidad o restricciones técnicas del sistema, contamos con los siguientes: RNF-001 Uso de la herramienta Descripción La herramienta se podrá usar mediante línea de comandos Datos específicos Con la línea de comandos podremos montar cada uno de los escenarios, ejecutarlos y también borrarlos Importancia Muy alta Prioridad Alta Estado Implementado Tabla 2–12. RNF-001 RNF-002 Docker Descripción Será necesario el uso de Docker y docker-compose para algunos escenarios Datos específicos Para el escenario 2 y 3 se hace uso de Docker, de forma que se usa una red de contenedores donde varios de ellos tendrán el rol de sonda y sólo uno el rol de coordinador Importancia Muy alta Prioridad Alta Estado Implementado Tabla 2–13. RNF-002 RNF-003 Estado de las sondas Descripción Se comprobará periódicamente el estado de las sondas (up/down) Datos específicos El coordinador comprueba cada 18 segundos el estado de cada sonda mediante los mensajes Keep-Alive recibidos de cada una, realizando acciones concretas con cada sonda según su estado Importancia Alta Prioridad Alta Diseño 12 12 Estado Implementado Tabla 2–14. RNF-003 RNF-004 Archivos de configuración Descripción Se requieren algunos archivos de configuración en formato yml Datos específicos Es necesario un archivo de configuración para establecer como van a ser las pruebas que realicen las sondas. Para los escenarios 2 y 3, se necesita un archivo de configuración para cada uno, que definirán las características del escenario como cantidad de nodos, IPs, etc Importancia Alta Prioridad Media Estado Implementado Tabla 2–15. RNF-004 RNF-005 Comunicación sonda-coordinador Descripción La comunicación entre las sondas y el coordinador hará uso de una API REST Flask Datos específicos Las sondas se comunicarán mediante la API con el coordinador para las siguientes funciones:  Solicitud de token  Solicitud de configuración de pruebas  Envío de mensajes Keep-Alive  Envío de informes de pruebas  Solicitud de turnos para la prueba de Iperf Importancia Muy alta Prioridad Alta Estado Implementado Tabla 2–16. RNF-005 RNF-006 Comportamiento no bloqueante Descripción Las diferentes funciones de sonda y coordinador se gestionarán mediante hilos Datos específicos Al iniciar la ejecución de la sonda y coordinador, cada uno deberá arrancar los hilos que tengan definidos. Al finalizar la ejecución, los hilos se detendrán de manera ordenada mediante la función join(). 13 13 Herramienta para la monitorización de redes privadas basada en sondas Se deberán usar los hilos, en la medida de lo posible, para las funciones que desempeñan tanto las sondas como el coordinador. Para las funciones relacionadas con Iperf hay que usar la librería Multiprocessing, ya que con hilos no se logra detener de la manera esperada. Importancia Muy alta Prioridad Alta Estado Implementado Tabla 2–17. RNF-006 RNF-007 Implementación de pruebas para varios casos de uso Descripción Dockerlab es una herramienta Docker utilizada para generar el docker-compose Datos específicos Es necesario el uso de Dockerlab para poder generar el docker-compose que levantará los contenedores necesarios en los escenarios 2 y 3. Requerirá la existencia de un archivo .yml de configuración que contendrá los datos necesarios para definir estos escenarios o parte de ellos. Importancia Muy alta Prioridad Alta Estado Implementado Tabla 2–18. RNF-007 2.1.3 Fuera del alcance Todo el sistema se ha diseñado para funcionar a través de una interfaz de línea de comandos (CLI), con almacenamiento local de los resultados en formato texto (.txt), sin requerir infraestructura externa ni componentes visuales complejos. No obstante, dada la limitación de tiempo, recursos y el enfoque académico del proyecto, se han dejado fuera del alcance varios aspectos que, si bien enriquecerían la solución final, no eran esenciales para el cumplimiento de los objetivos fundamentales. A continuación, se detallan los principales elementos excluidos:  Interfaz gráfica de usuario (GUI): Una de las principales carencias del sistema es la ausencia de una interfaz gráfica amigable y visual. Aunque la CLI proporciona una interacción funcional, no resulta la opción más intuitiva para usuarios sin experiencia técnica. El desarrollo de una GUI permitiría, por ejemplo, una gestión más accesible y eficiente de las sondas, la configuración de pruebas y la visualización en tiempo real de los resultados.  Persistencia avanzada de datos y backups: Actualmente, los datos generados por las sondas se almacenan localmente en archivos de texto simples, lo que limita la escalabilidad, la consulta eficiente de históricos y la integración con otras herramientas. La implementación de una base de datos centralizada permitiría una mejor gestión de los datos, además de posibilitar la ejecución de copias de seguridad automáticas y la recuperación ante fallos del sistema.  Visualización avanzada de resultados: Otra funcionalidad excluida es la generación de visualizaciones gráficas (gráficas de línea, de barras, etc.) que permitirían interpretar los datos de forma más intuitiva. Esta característica sería especialmente útil para identificar patrones de comportamiento, detectar anomalías en la red o realizar análisis comparativos a lo largo del tiempo. Diseño 14 14  Sistema de alertas y notificaciones: Aunque las sondas detectan incidencias, no se ha implementado un sistema automático de alertas que informe al usuario en tiempo real mediante correo electrónico, mensajería o cualquier otro canal. Este tipo de funcionalidad es esencial en entornos de producción para una respuesta rápida ante fallos críticos.  Gestión remota de las sondas: La configuración y ejecución de las pruebas debe realizarse actualmente de forma local en cada equipo. Un sistema de gestión centralizada y remota de las sondas permitiría una mayor flexibilidad, facilitando su administración desde el equipo coordinador sin necesidad de acceso físico a cada nodo.  Seguridad y autenticación: El proyecto no contempla mecanismos avanzados de seguridad en la comunicación entre sondas y el coordinador, ni autenticación de usuarios. Para un entorno real podría ser fundamental implementar cifrado de datos, autenticación de dispositivos y control de accesos. 2.2. Arquitectura Para validar el funcionamiento del sistema desarrollado, se han diseñado y probado tres escenarios distintos que permiten evaluar el comportamiento del sistema en configuraciones de complejidad creciente. Estos escenarios no solo permiten comprobar la comunicación entre sondas y el coordinador en diferentes condiciones, sino también observar cómo escala el sistema y cómo responde en entornos más realistas que simulan una red distribuida. En todos los casos, el sistema sigue el mismo principio de funcionamiento: las sondas ejecutan pruebas predefinidas y envían los resultados al coordinador, que centraliza la recogida de datos. Al fin y al cabo, este proyecto trata de simular el comportamiento del sistema desarrollado en escenarios reales, por lo que los escenarios realizados no tendrán una precisión exacta, pero si se aproximarán en gran medida a un escenario real. Téngase en cuenta que hay muchísimas configuraciones posibles dado que el escenario se puede hacer tan complejo como se quiera. La siguiente ilustración muestra una posibilidad de como podría desplegarse el sistema en la realidad: Ilustración 2–1. Esquema escenario real Este ejemplo muestra las siguientes características:  El coordinador podría cifrar sus conexiones hacia el exterior haciendo uso de un proxy HTTPS, mientras que las sondas pueden estar tras una NAT. Este proxy y la NAT se pueden implementar en el despliegue, por tanto, su implementación no será parte del desarrollo de este proyecto.  Esto sería una arquitectura lógica si nuestro coordinador esta fuera de la red donde se encuentran las sondas, estando por ejemplo alojado en un entorno cloud. Podría tener también sondas en su misma 15 15 Herramienta para la monitorización de redes privadas basada en sondas subred, si por ejemplo ese entorno cloud es privado y perteneciera a la misma organización a la que pertenece el coordinador.  Tanto las sondas como el coordinador se comunican por API REST usando HTTP, además las sondas hacen algunas pruebas mediante este protocolo, por lo que el uso de un proxy que cifre las conexiones es muy recomendable si los elementos están repartidos por distintas zonas geográficas y sus comunicaciones atraviesan la red pública. 2.3. Descripción de los procedimientos En este apartado se describen los diferentes procedimientos que llevan a cabo los componentes del sistema desarrollado. El sistema está compuesto por un coordinador o servidor y varias sondas o clientes, los cuales realizan tanto tareas individuales como procesos coordinados para alcanzar los objetivos de funcionamiento definidos. Cada elemento cumple funciones específicas, pero también interactúan entre sí a través de mecanismos de comunicación, formando un conjunto integrado y cooperativo. A continuación, se detallan algunos de los procedimientos implementados, que permiten garantizar la comunicación sonda-coordinador y el correcto funcionamiento del sistema completo. 2.3.1 Handshake inicial Este procedimiento es el primero que realiza la sonda al arrancar. La siguiente ilustración muestra de forma visual como sucede este proceso entre la sonda y el coordinador. Cuando la sonda arranca comprueba si existe el archivo token.txt, en caso afirmativo continúa la ejecución, pero si el archivo no existe, lo crea. Este archivo almacena el token de la sonda, el cuál es generado y enviado por el coordinador. Lo siguiente en suceder es la comprobación del token, si en token.txt no existe un token, la sonda solicita uno al coordinador, que lo crea y lo devuelve. Si existe un token en token.txt, la sonda lo cargará y no necesitará solicitar uno nuevo. A continuación, la sonda solicita al coordinador la configuración de las pruebas, esto es, datos necesarios que necesita la sonda para poder realizar los distintos tipos de pruebas. Además, en la misma solicitud, la sonda envía su token como parámetro, que el coordinador usará para verificar si esa sonda tiene autorización para recibir la configuración. Si la sonda está autorizada, el coordinador le enviará la configuración, que contiene un id. Por último, la sonda manda un mensaje HELLO tipo Keep-Alive con una solicitud en la que manda los parámetros ‘msg’ e ‘id’. Con este mensaje el coordinador podrá verificar el estado de la sonda (operativa o no operativa). Este mensaje se repite cada 15 segundos y a partir de este instante la sonda realiza repetidamente el resto de sus procesos hasta que se detenga. Diseño 16 16 Ilustración 2–2. Diagrama de secuencia del handshake inicial 2.3.2 Operación La operación del sistema consta de varios procesos realizándose simultáneamente, tanto en las sondas como en el coordinador. Esta parte del funcionamiento es la más importante pues en ella se realizan todas las funciones principales del sistema, que son hacer las pruebas y enviar los resultados. Vamos a ir explicando la siguiente ilustración que muestra un diagrama de secuencia simplificado de lo que ocurre en cada momento. Téngase en cuenta que todos los bloques de loop se ejecutan a la vez, ya que el sistema se ha diseñado para que realice todas las pruebas al mismo tiempo, junto con otras funciones. Por tanto, podemos ignorar el orden que siguen estos bloques en la ilustración. La ilustración representa algunos valores y parámetros concretos, esto es porque así se ha probado durante el desarrollo, pero no implica que solo sean válidos esos valores, ya que son completamente modificables. Comenzamos con el primer bloque loop. Este bucle es el encargado de mandar un mensaje de tipo Keep-Alive al coordinador, en este caso cada 15 segundos. Este mensaje llega al coordinador mediante una petición GET con parámetros msg=HELLO e id=id_sonda (id que va en la configuración enviada por el coordinador). El coordinador utiliza estos mensajes para llevar un seguimiento del estado de la sonda (operativa o no operativa) y así poder adaptar su funcionamiento en tiempo real, he aquí la importancia de enviar el id en la solicitud. El siguiente bloque trata de la prueba de ICMP o de ping. En esta prueba la sonda hace un ping a una IP específica, en este caso 8.8.8.8, y tras recibir las respuestas, procesa los datos y concluye los valores de los parámetros de interés. Una vez se han recogido y guardado los resultados en un fichero, estos se mandan al coordinador mediante una petición POST al endpoint /informe pasando el parámetro prueba=icmp. Por último, el coordinador recibe los resultados y los recoge en un fichero. Se realiza cada 10 segundos. El bloque que continúa es el respectivo a la prueba de DNS. Esta prueba consiste en la resolución de varios destinos y tras procesar las respuestas recibidas se obtienen los resultados que nos interesan. De la misma manera que en la prueba de ICMP, los resultados se guardan en fichero (cada prueba almacena los resultados en un fichero dedicado a esa prueba) y se envían al coordinador mediante una petición POST al endpoint /informe con el parámetro prueba=dns. Por último, el coordinador recibe los resultados y los recoge en un fichero. Se realiza cada 20 segundos. 17 17 Herramienta para la monitorización de redes privadas basada en sondas El siguiente bloque es el de la prueba TCP. La sonda se conecta a 142.250.74.206:80 mediante un socket TCP y concluye los resultados de interés de la respuesta recibida. Estos resultados se almacenan en fichero y se envían con petición POST al coordinador pasando el parámetro prueba=tcp, que los almacena en un fichero. Se realiza cada 25 segundos. Seguimos con el bloque de la prueba de HTTP. Una prueba en la que la sonda realiza una petición GET a un destino concreto y tras la respuesta recibida concluye unos resultados que se almacenan en fichero y se envían al coordinador mediante petición POST pasando el parámetro prueba=http. El coordinador recibe los resultados en el cuerpo de la petición y los guarda en fichero. Se realiza cada 15 segundos. Por último, queda el bloque de la prueba Iperf. Esta prueba se trata de manera diferente a las anteriores. Antes de comenzar la conexión cuya respuesta dará los resultados, la sonda debe solicitar un turno al coordinador, esto se hace mediante una petición GET a /turno, pasando los parámetros ‘id’ y ‘fin’=False. Esto es así debido a que el servidor Iperf en el coordinador no es capaz de atender a más de una sonda al mismo tiempo, por tanto, el coordinador lleva a cabo una gestión de turnos. El parámetro ‘id’ identifica a la sonda, y el parámetro ‘fin’, gestionado por la sonda, indicará al coordinador cuando una sonda ha terminado su prueba, y así el turno se asignará a la siguiente sonda en la cola. La sonda esperará a que sea su turno para continuar. Una vez sea su turno, la sonda inicia una conexión Iperf con el coordinador que se mantiene durante 5 segundos. Una vez acabada se recogen los resultados, se almacenan en fichero, y se envían al coordinador mediante petición POST al endpoint /informe pasando el parámetro prueba=iperf. El coordinador recibe los resultados y los guarda en fichero. Tras esto, la sonda envía de nuevo una petición GET a /turno con los parámetros ‘id’ y ‘fin’=True, que harán que el coordinador elimine de la lista de espera de turnos a la sonda que acaba de realizar la prueba, y el turno pasará a otra sonda. El servidor Iperf en el coordinador escucha en el puerto 5201. Diseño 18 18 Ilustración 2–3. Diagrama de secuencia de la operación del sistema 19 19 Herramienta para la monitorización de redes privadas basada en sondas 2.3.3 Autenticación de la sonda Este procedimiento es bastante simple en comparación a los anteriores, y estaría incluido en el handshake inicial. La seguridad aquí implementada es muy simple y es una de las limitaciones del sistema que se puede mejorar de manera más robusta. Veamos cual es su función y como se consigue la autenticación. Se muestra una ilustración con un diagrama de secuencia sencillo del proceso. Cuando una sonda inicia, puede o no tener ya un token que previamente recibió del coordinador, este token está formado por 64 caracteres hexadecimales aleatorios. Al iniciar, la sonda siempre solicitará la configuración de las pruebas que tiene que realizar, mediante una petición GET a /config pasando el parámetro ‘token’. El hecho de pasar el token sirve para que el coordinador pueda detectar si esa sonda tiene autorización para conseguir la configuración de las pruebas. El coordinador mantiene una lista llamada ‘listaTokens’ que almacena todos los tokens que han ido creándose y asignándose según se han ido solicitando. En el coordinador, estos tokens residen en un archivo tokens.txt, que sirve de persistencia, así cuando el coordinador se inicia, los tokens de ese fichero son cargados en ‘listaTokens’. Entonces, cuando el coordinador recibe una solicitud en /config, comprueba si el token que está mandando esa sonda solicitante existe en la lista. Si existe, el acceso se concederá, pues se trata de una sonda que previamente ha solicitado y almacenado un token que el coordinador entregó. Si no existe, se denegará el acceso. Una sonda siempre debería tener un token, ya que el token siempre se solicita en el primer arranque, y posteriormente se solicita la configuración. Por tanto, una sonda siempre tendrá un token a la hora de solicitar la configuración, en caso contrario, se considerará una sonda sospechosa y no recibirá configuración. Ilustración 2–4. Diagrama de secuencia de la autenticación de la sonda 2.4. Definición de la API REST Dado que en este proyecto tenemos varios equipos o procesos comunicándose entre ellos, se ha desarrollado una API REST usando Flask, que permite la comunicación entre las sondas y el coordinador. Esta API comprende todas las funciones necesarias para que la comunicación sonda-coordinador sea efectiva y se cumplan los objetivos de funcionamiento de este sistema. El coordinador será el encargado de levantar el servidor REST en el puerto 5000, desde donde escuchará todas las peticiones que realicen las sondas a través de la API. A continuación, se presenta una tabla que definirá la API REST implementada. Implementación 26 26 sintaxis el programa finalizará. En ipGuardada se carga <COORDINADOR_IP>. Sólo habrá un hilo, que ejecutará la función checkAlive() y la función funcIperf() se gestionará con la librería multiprocessing, ya que con threading presentaba algunos problemas. A continuación, se intenta abrir el fichero tokens.txt, que si no existiera se crea automáticamente, y una vez abierto se cargan los tokens y los ids en listaTokens y listaIDs respectivamente. Esto se debe a la intención de mantener un poco de persistencia y agilizar el funcionamiento del sistema ahorrando tiempo en algunos aspectos como la solicitud de tokens. Por último, se arranca el hilo de checkAlive(), el proceso de funcIperf() y la API en la IP <COORDINADOR_IP> y puerto 5000. Cuando se quiera parar el programa, basta con hacer Ctrl+C y se cerrarán todos los hilos y procesos abiertos ordenadamente. Código 3–9. Arranque del programa Dado que en este proyecto se trata con varios escenarios y algunos usan distintas tecnologías, se tienen dos versiones de coordinador.py y sonda.py. Una versión para los escenarios locales y otra para la adaptación a Docker. En los escenarios que usan Docker se usan volúmenes de Docker para almacenar los ficheros, y por tanto es necesario adaptar en cada código las rutas relativas de los ficheros para que se almacenen en el lugar correcto. 3.3 Sonda Pasamos ahora con la sonda, de gran importancia también, pues es quien realiza las pruebas y las manda al coordinador. Vamos a ver poco a poco el código explicando sus partes. Téngase en cuenta que en este código muchas funciones tienen un bucle while con la condición not detener (not detenerIperf para pruebaIperf()), esto conseguirá que esas funciones terminen su actividad en cuanto introduzcamos una ‘q’ por teclado para detener la sonda manualmente (mencionado en RF-009). También hay que mencionar que todos los informes añaden el id de la sonda y la fecha y hora en que se genera el informe. Mostremos primero un diagrama de flujo de todo su funcionamiento y posteriormente el código. Tengamos en cuenta que habrá varios procesos ejecutándose simultáneamente hasta que se de la orden de parar el programa completo: 27 27 Herramienta para la monitorización de redes privadas basada en sondas Ilustración 3–2. Diagrama de flujo de la sonda Ya en el código, comenzamos por los módulos o librerías que la sonda necesita importar, destacando: requests, con la que podremos hacer peticiones HTTP; multiprocessing y threading, que permitirá la ejecución simultánea de varias funciones del código; iperf3, responsable de configurar el cliente Iperf; ping3, para la prueba ICMP; dns.resolver, para la prueba de DNS; y socket, para la prueba de TCP. Más abajo nos encontramos con las variables globales, las cuáles se irán comentando y viendo su uso conforme vayamos viendo el resto del código. Código 3–10. Imports y variables globales de la sonda La función initProbe() es simplemente una función de arranque para poner a punto la sonda. En los escenarios realizados, la sonda y el coordinador se inician casi al mismo tiempo, pero la sonda está programada con un sleep de 3 segundos para dar un pequeño margen de tiempo para que el coordinador inicie por completo, y así puedan empezar a comunicarse sin problema. Lo siguiente es la lectura de token.txt, una sonda siempre pedirá un token en su primer arranque, y luego la configuración de pruebas (independientemente de si es el Implementación 28 28 primer arranque o no). Si no es el primer arranque, un token debería estar almacenado en token.txt, que se lee en esta función para cargar el token en memoria y por tanto solicitar sólo la configuración de pruebas. Código 3–11. Función initProbe() Con la función getToken() la sonda podrá solicitar un token al coordinador. Primero realiza la petición a la API y luego guarda la respuesta en el fichero token.txt, esa respuesta viene en formato JSON, que se guarda en la variable global datos como diccionario y en el fichero se guarda el valor del único campo del diccionario, en este caso, el token. Código 3–12. Función getToken() La función getConfig() es la que hace posible solicitar la configuración de pruebas. Se realiza la petición a /config enviando el token en los parámetros de la URL, con el que el coordinador comprobará si la sonda está autorizada. La respuesta se guarda en configDict, un diccionario que contendrá la configuración de las pruebas y un ID para la sonda (siempre que esté autorizada). Código 3–13. Función getConfig() La función mandarKeepalive() se hará cargo de enviar mensajes HELLO de tipo Keep-Alive al coordinador cada 15 segundos para mantener viva la conexión. Principalmente, la función hace una petición a /keepalive mandando el mensaje HELLO y el id de la sonda en la URL como parámetros, posteriormente se hacen 15 sleeps de 1 segundo para cumplir la periodicidad descrita, y la función se repite. Esta función es sensible al mecanismo de detención manual de la sonda. 29 29 Herramienta para la monitorización de redes privadas basada en sondas Código 3–14. Función mandarKeepalive() La prueba de ICMP se gestiona con la función pruebaICMP(). Comienza con un ping de 4 peticiones a la IP indicada en la configuración de pruebas y en cuánto se reciben las respuestas se calcula el retardo medio y el % de pérdidas. A continuación, se genera el informe de los resultados y se almacena en pruebasICMP.txt, posteriormente el informe se envía con petición POST a /informe, mandando el tipo de prueba como parámetro. Por último, la función espera los segundos necesarios para cumplir el periodo indicado en la configuración de pruebas y la función se repite. Esta función es sensible al mecanismo de detención manual de la sonda. Código 3–15. Función pruebaICMP() La función pruebaDNS() es la que maneja las pruebas de DNS. Comienza haciendo 3 resoluciones de DNS y tomando el retardo de cada una, los destinos vienen indicados en la configuración de pruebas. Estos resultados los va guardando de uno en uno en pruebasDNS.txt y enviando de uno en uno a /informe mediante petición POST enviando el tipo de prueba como parametro, esto es así para mantener el texto en la estructura deseada. Por último, la función espera los segundos necesarios para cumplir el periodo indicado en la configuración de pruebas y la función se repite. Esta función es sensible al mecanismo de detención manual de la sonda. Implementación 30 30 Código 3–16. Función pruebaDNS() La función pruebaTCP() ejecuta las pruebas de TCP. Comienza estableciendo una conexión TCP a la IP y puerto indicados en la configuración de pruebas, midiendo el retardo. Una vez se tienen los resultados, se genera el informe y se almacena en pruebasTCP.txt y posteriormente se envia mediante petición POST a /informe mandando el tipo de prueba como parámetro. Por último, la función espera los segundos necesarios para cumplir el periodo indicado en la configuración de pruebas y la función se repite. Esta función es sensible al mecanismo de detención manual de la sonda. Código 3–17. Función pruebaTCP() Las pruebas HTTP se gestionan con la función pruebaHTTP(). Comienza con una petición GET a la URL indicada en la configuración de pruebas y se toman el retardo y el status de la respuesta. Una vez se tiene el informe preparado se almacena en pruebasHTTP.txt y se envía mediante petición POST a /informe mandando 31 31 Herramienta para la monitorización de redes privadas basada en sondas el tipo de prueba como parámetro. Por último, la función espera los segundos necesarios para cumplir el periodo indicado en la configuración de pruebas y la función se repite. Esta función es sensible al mecanismo de detención manual de la sonda. Código 3–18. Función pruebaHTTP() La función pruebaIperf() se encarga de las pruebas de Iperf. Esta prueba comienza con una petición GET a /turno pasando como parámetros el id de la sonda y ‘fin’=False. Se hace esta petición por la necesidad de solicitar un turno para esta prueba debido a las limitaciones del servidor. La respuesta será el id de la sonda que tiene el turno actual (si no hay ninguna sonda en la lista de turnos la respuesta es 0), y la sonda comprueba si ese id es el suyo. En caso negativo la sonda esperará 1 segundo y volverá a empezar de nuevo. En caso afirmativo, la sonda abre una conexión Iperf hacia la IP del coordinador y el puerto especificado en la configuración de pruebas. Esta prueba durará el tiempo especificado en la configuración de pruebas y una vez finalice se tomarán los resultados (ancho de banda enviado y recibido y RTT medio) para generar un informe que se almacenará en pruebasIperf.txt y se enviará mediante petición POST a /informe mandando el tipo de prueba como parámetro. Una vez terminada la prueba, el parámetro ‘fin’ se cambia a True y se vuelve a hacer petición a /turno enviando el id y ‘fin’, esto hará que el coordinador elimine a la sonda de la lista y le pase el turno a la siguiente. Posteriormente ‘fin’ volverá a valer False para que la sonda pueda volver a hacer la prueba más tarde. Por último, la función espera 2 segundos y se repite. Esta función es sensible al mecanismo de detención manual de la sonda. Implementación 32 32 Código 3–19. Función pruebaIperf() Por último, se muestra el código donde la sonda inicia todas sus funciones. Es necesario que el comando que ejecute a la sonda sea python sonda.py <COORDINADOR_IP> ya que si no se usa esa sintaxis el programa finalizará. En ipGuardada se carga <COORDINADOR_IP>. Habrá 6 hilos y la función pruebaIperf() se gestionará con la librería multiprocessing, ya que con threading presentaba algunos problemas. A continuación, se intenta abrir el fichero token.txt, que si no existiera se crea automáticamente. A partir de este momento, se arranca el hilo de la función initProbe(), y hasta que no finalice, el programa no avanzará. Tras esto se arrancan el resto de los hilos y el proceso de la función pruebaIperf(). Por último, el programa se quedará en un bucle esperando recibir una ‘q’ por teclado que, en caso de recibirla, hará finalizar todos los hilos y procesos de manera ordenada, dando lugar como consecuencia a la finalización o apagado de la sonda. 33 33 Herramienta para la monitorización de redes privadas basada en sondas Código 3–20. Arranque del programa 3.4 Ficheros de configuración Se comentarán ahora los ficheros de configuración usados en el proyecto. En este proyecto hay dos tipos: fichero de configuración de pruebas, y fichero de configuración de red Docker. 3.4.1 Fichero de configuración de pruebas Como su nombre indica, este fichero de configuración contiene las características de las pruebas que las sondas van a realizar. Se le ha dado el nombre de config.yml, por lo que es un fichero en formato .yml. A continuación, se muestra una imagen de su contenido y se explicarán sus campos: Implementación 34 34 Código 3–21. Fichero de configuracion de pruebas  El campo id define un identificador para la sonda, este campo, inicialmente a None, se rellenará con el id que el coordinador le asigne a la sonda que solicita la configuración.  El campo pruebas es una lista que contiene la configuración para cada tipo de prueba. Cada prueba se distingue con el campo tipo, que es una lista cuyo nombre es el tipo de prueba. o En la prueba de tipo ping (ICMP) existen los siguientes campos: dest, que indica el destino al que realizar el ping; y periodo, que indica cada cuanto tiempo (en segundos) se realizará la prueba. o En la prueba de tipo DNS existen los siguientes campos: destinos, que es una lista con varios destinos a los que realizar una consulta de DNS; y periodo, que indica cada cuanto tiempo (en segundos) se realizará la prueba. o En la prueba de tipo TCP existen los siguientes campos: ip, que indica la IP a la que conectarse mediante socket; port, que indica el puerto al que se quiere conectar mediante socket; y periodo, que indica cada cuanto tiempo (en segundos) se realizará la prueba. o En la prueba de tipo HTTP existen los siguientes campos: url, que indica la URL a la que se hará una petición GET; y periodo, que indica cada cuanto tiempo (en segundos) se realizará la prueba. o En la prueba de tipo Iperf existen los siguientes campos: serverPort, que indica el puerto del servidor Iperf al que hay que conectarse para realizar la prueba; y duracion, que indica la duración (en segundos) de la conexión Iperf que se realiza para la prueba. 3.4.2 Fichero de configuración de red Docker Procedemos ahora a explicar el fichero de configuración utilizado para levantar redes de Docker, junto con sus campos y valores. Concretamente, estos ficheros especifican las características de los contenedores que formarán la red Docker. Los ficheros serán utilizados por la herramienta Dockerlab para generar esas redes, que estarán definidas en un fichero docker-compose. En este proyecto se han desarrollado dos ficheros, uno para el escenario 2 y otro para el escenario 3. Se les ha dado también el nombre de config.yml, por lo que son ficheros en formato .yml. Pese a tener los mismos nombres y coincidir con el fichero de configuración de pruebas, se sitúan en rutas distinas, por lo que el sistema los diferenciará sin problemas. A continuación, se muestran imágenes de éstos y se explicarán sus contenidos: 35 35 Herramienta para la monitorización de redes privadas basada en sondas Código 3–22. Fichero de configuración de la red Docker del escenario 2 Código 3–23. Fichero de configuración de la red Docker del escenario 3 Ambos ficheros tienen varios campos en común, pero en el caso del escenario 2 hay algunos campos que sólo aparecen en ese fichero. Comentaremos el fichero del escenario 2:  El campo escenario2 es una lista que contiene las características mas fundamentales de la red Docker del escenario. El campo network indica la subred que tendrá esa red de Docker, en la que se desplegarán los contenedores obteniendo cada uno una IP de esa subred. El campo nodes es una lista que indica que tipos de nodos se desplegarán en la subred, en este caso, coordinador y sonda. o El campo coordinador es una lista que contiene las características del contenedor que actuará como un nodo de tipo coordinador. Contiene los siguientes campos:  El campo image indica la imagen que utilizará el contenedor. Una imagen de Docker es una plantilla inmutable que contiene todo lo necesario para ejecutar una aplicación: código, dependencias, configuraciones y sistema operativo base. En este caso se usa la imagen de python:3.10.12, es decir, el contenedor ejecutará un archivo python.  El campo script indica que el contenedor podrá ejecutar un shell-script al iniciar, en este caso coordinador.sh.  El campo ip indica la IP que se le asignará a ese contenedor en la subred. De esta forma podemos asignar una IP manualmente. o El campo sonda es una lista que contiene las características del contenedor que actuará como un nodo de tipo sonda. Contiene los siguientes campos:  El campo image indica la imagen que utilizará el contenedor. En este caso se usa la imagen de python:3.10.12, es decir, el contenedor ejecutará un archivo python.  El campo script indica que el contenedor podrá ejecutar un shell-script al iniciar, en este caso sonda.sh.  El campo replicas indica cuántos contenedores de tipo sonda con la misma configuración se van a desplegar. En este caso, las IPs de estas réplicas se asignarán automáticamente.  El campo needs es una lista que indica las dependencias de este tipo de contenedor, en este caso, la sonda será dependiente del coordinador, por tanto, primero se despliega el coordinador y después las sondas. Implementación 42 42  Ficheros de resultados: Estos ficheros de texto contienen los informes de las pruebas realizadas. Cuando las sondas realizan pruebas, recogen los resultados en estos ficheros y posteriormente envían esos resultados al coordinador. Ilustración 3–6. Estructura de /escenario3 Por último, queda por detallar el directorio /srcdocker:  /coordinador: Este directorio contiene el código fuente del programa coordinador que ejecutarán los contenedores Docker en los distintos escenarios además del fichero de configuración de pruebas. o coordinador.py: Código fuente del coordinador adaptado para su uso en contenedores Docker. o config.yml: Fichero de configuración de pruebas.  /sonda: Este directorio contiene el código fuente del programa sonda que ejecutarán los contenedores Docker en los distintos escenarios. o sonda.py: Código fuente de la sonda adaptado para su uso en contenedores Docker. 43 43 Herramienta para la monitorización de redes privadas basada en sondas Ilustración 3–7. Estructura de /srcdocker 3.5.2.2 Creación de escenarios Como se ha comentado, podemos crear los escenarios haciendo uso del Shell-script crea.sh. Concretamente este script nos permite crear los escenarios 2 y 3, ya que el escenario 1 se puede ejecutar directamente debido a su simplicidad. Cuando ejecutamos crea.sh (con el comando ./crea.sh dentro del directorio TFG), introducimos por teclado el número del escenario que queremos crear (2 o 3), y el script comenzará a buscar el fichero de configuración del escenario (si no existe, pedirá crearlo) y el docker-compose del escenario seleccionado. Si no hay dockercompose creado, se activará el entorno virtual de Python para asegurar que esté activo. Tras esto se hace uso de dockerlab, que gracias al fichero de configuración del escenario puede crear el archivo docker-compose, el cuál se modificará haciendo uso de modCompose.py para conseguir el escenario completo deseado. A continuación, se muestra el código de crea.sh: Código 3–25. Shell-script crea.sh Implementación 44 44 3.5.2.3 Ejecución de escenarios En la estructura general de directorios se mencionaba qué función desempeña el Shell-script ejecuta.sh. Vamos a comentar cómo se realiza la ejecución de los distintos escenarios del proyecto. Cuando ejecutamos ejecuta.sh (con el comando ./ejecuta.sh dentro del directorio TFG) nos solicita introducir el número del escenario a ejecutar. Si hemos seleccionado el 1, el script lanza los scripts sonda.sh y coordinador.sh contenidos en /escenario1, que lanzarán un terminal con la sonda y otro con el coordinador, respectivamente. Si hemos seleccionado el 2, se busca el fichero de configuración del escenario y el docker-compose y se levantan los contenedores con docker-compose up (línea 67). En el caso del escenario 3, se hace prácticamente idéntico que con el escenario 2, solo que además de levantar contenedores, el coordinador se ejecuta con el script coordinador.sh contenido en /escenario3 y tambien se lanza un terminal que ejecuta una sonda en local. Lógicamente los escenarios (excepto el escenario 1) deben estar creados para poder ejecutarlos. A continuación, se muestra el código ejecuta.sh: Código 3–26. Shell-script ejecuta.sh 3.5.2.4 Eliminación de escenarios Previamente se comentaba la existencia de un Shell-script dedicado a la eliminación de escenarios. Concretamente este script nos permite eliminar los escenarios 2 y 3, ya que el escenario 1 debido a su simplicidad no necesita crearse, por tanto, tampoco necesita eliminarse. Es importante tener en cuenta que, antes de crear o ejecutar un escenario que involucra componentes Docker, se debe eliminar cualquier otro escenario que también utilice Docker. Esto se debe a que ciertos elementos de Docker pueden interferir entre sí, aunque pertenezcan a escenarios diferentes. Se va a explicar brevemente como funciona el script elimina.sh. Cuando ejecutamos elimina.sh (con el comando ./elimina.sh dentro del directorio TFG) nos solicita introducir el número del escenario a eliminar (2 o 3). Posteriormente se eliminan los contenedores (deteniéndolos antes), volúmenes, red Docker y docker-compose asociados al escenario seleccionado. Este proceso es general, por tanto, el escenario 2 y el 3 se eliminarán de la misma manera. A continuación, se muestra el código elimina.sh: 45 45 Herramienta para la monitorización de redes privadas basada en sondas Código 3–27. Shell-script elimina.sh 3.5.2.5 Despliegue de escenario Docker Ya se ha comentado varias veces de la presencia de Docker en este proyecto, pues se usa en dos de los tres escenarios desarrollados. Pero aún no se ha explicado con qué propiedades se despliegan los contenedores en el escenario. En este apartado se va a explicar cómo sucede esto. Si un escenario presenta una parte Docker quiere decir que, entre otras cosas, habrá contenedores que actúen como sondas o como coordinador. Sabemos que tanto las sondas como el coordinador almacenan ficheros con diversos tipos de información en los directorios donde se encuentra su código fuente, pero ¿dónde almacena un contenedor esos ficheros? La respuesta es, volúmenes. Un volumen en Docker es una carpeta gestionada por Docker que se localiza en el sistema de archivos del host, y se monta dentro del contenedor en una ruta específica. Gracias a esto, podemos guardar los ficheros que genere nuestro contenedor, aunque lo detengamos, y así poder recuperar esos ficheros en futuras ejecuciones de ese contenedor. También hace posible cargar ficheros de nuestro host dentro del contenedor cuando arranca. Resumidamente, un volumen es una ruta interna del contenedor que apunta a una ruta del host, lo que haya dentro de la ruta del host será cargado en la ruta del contenedor, y los cambios realizados dentro de la ruta del contenedor (por ejemplo, añadir ficheros) se verán reflejados en la ruta del host. Vemos que gracias a los volúmenes podemos conseguir que los contenedores puedan funcionar igual que una sonda o coordinador local, ya que se estaría consiguiendo persistencia de los archivos. Como ya se ha comentado previamente, los contenedores usan un código fuente ligeramente distinto a los que usan las sondas o el coordinador en local. Esta diferencia radica principalmente en que las rutas de los ficheros hacen referencia a la carpeta en la que se almacenan dentro del contenedor. A continuación, se muestran fragmentos del fichero docker-compose del escenario 2, donde se pueden ver los distintos volúmenes que tienen tanto una sonda como el coordinador. Para el escenario 3 aplica de la misma manera, la única diferencia es la cantidad de nodos y el tipo de nodo (sólo hay sondas). En el caso del coordinador:  Existe un volumen dedicado para que el contenedor pueda usar el código fuente del coordinador (incluido el fichero de configuración de pruebas). Se encuentra en /workspace/codes, que apunta a /home/dit/TFG/srcdocker/coordinador. Implementación 46 46  Existe un volumen dedicado para que el contenedor pueda ejecutar el Shell-script coordinador.sh al arrancar. Se encuentra en /workspace/coordinador.sh, que apunta a /home/dit/TFG/escenario2/coordinador.sh.  Existe un volumen dedicado para que el contenedor pueda disponer de las librerías de Python desde el principio, evitando tener que descargarlas e instalarlas en cada arranque. Se encuentra en /usr/local/lib/python3.10/site-packages, que apunta a /home/dit/TFG/.venv/lib/python3.10/sitepackages.  Existe un volumen dedicado para que el contenedor almacene los ficheros que genera, como el fichero tokens.txt o los que contienen los informes de las pruebas. Se encuentra en /workspace/data, que apunta a volumenC. volumenC se encuentra en el sistema de archivos del host, dentro de /var/lib/docker/volumes. Este nombre (volumenC) será distinto en cada nodo (sea sonda o coordinador) para poder diferenciarse del volumen de otro nodo.  /workspace es el directorio por defecto donde se sitúa el contenedor al arrancar. Código 3–28. Volúmenes del coordinador En el caso de la sonda:  Existe un volumen dedicado para que el contenedor pueda usar el código fuente de la sonda. Se encuentra en /workspace/codes/sonda.py, que apunta a /home/dit/TFG/srcdocker/sonda/sonda.py.  Existe un volumen dedicado para que el contenedor pueda ejecutar el Shell-script sonda.sh al arrancar. Se encuentra en /workspace/sonda.sh, que apunta a /home/dit/TFG/escenario2/sonda.sh.  Existe un volumen dedicado para que el contenedor pueda disponer de las librerías de Python desde el principio, evitando tener que descargarlas e instalarlas en cada arranque. Se encuentra en /usr/local/lib/python3.10/site-packages, que apunta a /home/dit/TFG/.venv/lib/python3.10/sitepackages.  Existe un volumen dedicado para que el contenedor almacene los ficheros que genera, como el fichero token.txt o los que contienen los resultados de las pruebas. Se encuentra en /workspace/data, que apunta a volumenS0. volumenS0 se encuentra en el sistema de archivos del host, dentro de /var/lib/docker/volumes.  /workspace es el directorio por defecto donde se sitúa el contenedor al arrancar. Código 3–29. Volúmenes de la sonda 47 47 Herramienta para la monitorización de redes privadas basada en sondas Por último, merece la pena mencionar que los Shell-script que ejecutan los programas sonda y coordinador (sonda.sh y coordinador.sh respectivamente), están adaptados para poder funcionar dentro del contenedor, de forma que la ejecución se sitúa dentro de /workspace/codes antes de ejecutar el código fuente. Además, cada contenedor instala iperf3 en el arranque, ya que, al ser un contenedor, todo lo que haya hecho se pierde al cerrarse, salvo que esté usando volúmenes y estén debidamente configurados. En este caso no se usan los volúmenes para tener iperf3 en los contenedores, por tanto, se decidió instalarlo en el arranque del contenedor. 49 4 PRUEBAS na vez abordadas las fases de diseño e implementación del sistema, es fundamental validar su correcto funcionamiento y verificar que cumple con los requisitos establecidos. Esta fase permite detectar posibles errores, comprobar la estabilidad del sistema y asegurar que las funcionalidades implementadas responden adecuadamente ante distintos escenarios de uso. Se han diseñado pruebas que abarcan tanto aspectos funcionales como de rendimiento, con el objetivo de evaluar la calidad global del sistema antes de su entrega final. En este apartado se detallan las pruebas realizadas y los resultados obtenidos. A continuación, se describen los tres escenarios de prueba propuestos junto con ilustraciones: 4.1 Escenario 1: Escenario local básico En este primer caso, tanto la sonda como el coordinador se ejecutan en un mismo equipo, utilizando la dirección de loopback (127.0.0.1) para su comunicación. Este entorno sirve como prueba inicial de concepto, donde se verifica el correcto funcionamiento de los módulos principales del sistema sin interferencias externas, problemas de red o restricciones de firewall. Ilustración 4–1. Esquema escenario 1 Vamos a mostrar el funcionamiento de este escenario: Primero, en la siguiente ilustración, veamos como el directorio /escenario1 no contiene por defecto los ficheros de texto de los tokens ni los ficheros de los resultados de las pruebas: U Pruebas 50 50 Ilustración 4–2. Estado inicial de /escenario1 Ahora, comenzaremos ejecutando el Shell-script ejecuta.sh, que nos permite ejecutar los escenarios: Ilustración 4–3. Ejecución del escenario 1 Una vez ejecutado nos aparecen los terminales con la sonda y el coordinador, mostrando cada uno los logs respectivos de cada programa. En el terminal de la sonda, podemos ver al inicio todo el proceso de arranque, incluso la configuración recibida, y después empezaría ya cada prueba y el resto de las funciones que se ejecutan simultáneamente, como el envío del mensaje HELLO. En la terminal del coordinador, al inicio se puede observar como recibe las peticiones de la sonda y como responde a esas peticiones (token y configuración), posteriormente puede verse como recibe los informes y como va haciendo un seguimiento del estado de la sonda. Ilustración 4–4. Terminales del escenario 1 Si ahora vemos de nuevo el contenido del directorio, podremos ver como se han generado los ficheros de texto que almacenan el token y los resultados de las pruebas. En la siguiente ilustración se puede ver como el contenido 51 51 Herramienta para la monitorización de redes privadas basada en sondas de estos ficheros es coherente. El token que almacena la sonda esta también almacenado en el coordinador y asociado a un ID, y los resultados de las pruebas se han almacenado correctamente (se muestra por ejemplo pruebasHTTP.txt). Ilustración 4–5. Ficheros generados en el escenario 1 4.2 Escenario 2: Escenario en misma subred El segundo escenario introduce un entorno más complejo simulado mediante contenedores Docker en una misma subred. Se despliega un total de diez sondas, cada una en su propio contenedor, y un coordinador también en su propio contenedor, todos conectados a una misma red virtual de Docker tipo Bridge (10.10.10.0/24). Esta configuración permite evaluar la capacidad del sistema para gestionar múltiples sondas de forma concurrente, manteniendo una comunicación eficiente y estable dentro de una red controlada. La Ilustración 4–6, se puede entender como que tanto las sondas como el coordinador están conectados a un switch virtual que permite la agrupación del tráfico total entre cada sonda y el coordinador. Entre las sondas y la red pública (Internet) ocurre lo mismo. Por razones de simplificación de la ilustración, no se incluye el switch en la misma. Ilustración 4–6. Esquema escenario 2 Conclusiones 58 58 una cierta curva de aprendizaje y posibles problemas relacionados con redes virtuales, volúmenes y permisos en sistemas operativos anfitriones. 5.2 Líneas de continuación A pesar de que el sistema desarrollado cumple con los objetivos fundamentales propuestos, existen diversas líneas de mejora que permitirían convertirlo en una solución más completa, robusta y adaptable a entornos reales de monitorización de red. Una de las ampliaciones más relevantes sería el desarrollo de una interfaz gráfica de usuario, que sustituya o complemente la actual interfaz de línea de comandos. Esta mejora facilitaría una interacción más intuitiva, especialmente para usuarios sin conocimientos técnicos, y permitiría una gestión más accesible de las sondas, las configuraciones de pruebas y la visualización de resultados. Otra mejora importante sería la integración de una base de datos centralizada, que sustituya el almacenamiento local en archivos de texto. Esto no solo optimizaría la gestión y consulta de los datos recogidos, sino que también facilitaría tareas como la realización de copias de seguridad, el análisis histórico de datos y la integración con otras herramientas externas. De forma complementaria, la incorporación de visualizaciones gráficas como gráficos de líneas, barras o mapas de calor permitiría interpretar de manera más eficiente los resultados recopilados, facilitando la detección de patrones, tendencias o posibles anomalías en la red. También se contempla como mejora la implementación de un sistema de alertas y notificaciones en tiempo real. Esta funcionalidad permitiría informar automáticamente al usuario ante la detección de fallos críticos o valores anómalos mediante canales como el correo electrónico o la mensajería instantánea, contribuyendo a una respuesta rápida y proactiva. En paralelo, dotar al sistema de capacidades para gestionar las sondas de forma remota desde el equipo coordinador mejoraría significativamente su usabilidad, ya que permitiría configurar, activar o desactivar pruebas sin necesidad de acceder físicamente a cada nodo de red. Por último, una línea de trabajo fundamental sería la mejora de la seguridad del sistema. La implementación de cifrado en las comunicaciones entre sondas y coordinador, junto con mecanismos de autenticación y control de acceso, resultan esenciales para proteger los datos transmitidos y garantizar la integridad del sistema en entornos de producción. En conjunto, estas posibles ampliaciones suponen una evolución natural del sistema actual, alineada con los requisitos que presentaría su aplicación en contextos reales, y abren la puerta a futuras fases de desarrollo más ambiciosas y especializadas. 5.3 Aprendizaje personal La realización de este Trabajo de Fin de Grado ha supuesto una experiencia muy enriquecedora tanto a nivel técnico como personal. A lo largo del proyecto, he tenido la oportunidad de consolidar y ampliar mis conocimientos en áreas clave que me interesaban desde el inicio, como el lenguaje de programación Python, el uso de contenedores con Docker, y el diseño e implementación de APIs REST. Estas tecnologías, ampliamente utilizadas en el ámbito profesional, me han permitido desarrollar competencias prácticas directamente aplicables en entornos reales. Este proyecto ha tenido un valor especial por su estrecha relación con el campo de las redes de telecomunicaciones, que es una de las áreas que más me apasiona dentro de la titulación. Poder aplicar los conocimientos adquiridos durante la carrera en un sistema que mide y monitoriza el rendimiento de red ha sido especialmente gratificante, ya que me ha permitido unir teoría y práctica en un contexto funcional y concreto. Asimismo, el desarrollo del proyecto me ha permitido mejorar mis habilidades de planificación, organización y resolución de problemas, enfrentándome a retos técnicos que he resuelto de manera autónoma o investigando soluciones por mi cuenta. Este proceso me ha ayudado a crecer como futuro profesional y a reforzar mi confianza en el desarrollo de proyectos complejos desde cero. En definitiva, este trabajo ha sido una oportunidad para poner en práctica mis intereses, explorar nuevas herramientas y afianzar mi vocación por el ámbito de las redes y sistemas, lo que refuerza mi motivación para seguir profundizando en este campo en el futuro. 59 59 Herramienta para la monitorización de redes privadas basada en sondas Bibliografía y Referencias 60 60 BIBLIOGRAFÍA Y REFERENCIAS [1] Web oficial de Python: https://www.python.org/ [2] Web oficial de Flask: https://flask.palletsprojects.com/en/3.0.x/ [3] Web oficial de Docker: https://www.docker.com/ [4] Web oficial de UptimeRobot: https://uptimerobot.com/ [5] Repositorio oficial de Uptime-Kuma: https://github.com/louislam/uptime-kuma [6] Web oficial de Grafana: https://grafana.com/ [7] Web oficial de Visual Studio Code: https://code.visualstudio.com/ [8] Página de docker-compose en la web de Docker: https://docs.docker.com/compose/ [9] Paquete gnome-terminal de los repositorios de Ubuntu: https://manpages.ubuntu.com/manpages/xenial/man1/gnome-terminal.1.html [10] Web oficial de PyPi: https://pypi.org/