Entorno de experimentación para generación y monitorización de tráfico P2P

Transcripción

1 ESTUDIOS DE INGENIERÍA DE TELECOMUNICACIÓN Entorno de experimentación para generación y monitorización de tráfico P2P REALIZADO POR: Alejandro Fernández Haro DIRIGIDO POR: Gabriel Maciá Fernández DEPARTAMENTO: Teoría de la Señal, Telemática y Comunicaciones Granada, Diciembre de 2010

2

3 ENTORNO DE EXPERIMENTACIÓN PARA GENERACIÓN Y MONITORIZACIÓN DE TRÁFICO P2P Alejandro Fernández Haro Palabras clave: P2P, generación de tráfico, monitorización distribuida, captura de tráfico, laboratorio, entorno de experimentación. Resumen: El modelo tradicional utilizado en Internet basado en la arquitectura cliente-servidor no es lo suficientemente eficiente para muchas de las aplicaciones que se pueden utilizar hoy en día, debido a la tendencia actual de diseñar servicios que hacen uso de la computación nube y demás entornos distribuidos. El rendimiento de estos ejemplos se puede ver afectado si todo el tráfico generado debe llegar a un servidor que solamente se encarga de reenviarlo. Las redes P2P mejoran el rendimiento de estas aplicaciones ya que los paquetes aprovechan toda la red, por lo que el tráfico no está concentrado en un solo punto de la misma. Ésta es la razón por la que es necesario estudiar esta tecnología y por la que se necesita un entorno de generación y monitorización de tráfico P2P. La intención de este proyecto consiste en diseñar ese entorno de generación y monitorización de tráfico P2P, teniendo en cuenta las características especiales que presentan este tipo de redes y las deficiencias de los sistemas de monitorización para la captura del tráfico en redes distribuidas. Keywords: P2P, traffic generation, distributed monitoring, traffic sniffing, laboratory, experimentation setting. Abstract: The traditional model used in the Internet based on client-server architecture is not efficient enough for most applications used nowadays, due to the current tendency to design services using cloud computing and more distributed enviroments. The performance in these enviroments would be reduced if all the traffic generated would traverse a node which just foward it. P2P networks leverage the performance of many applications, as the packets traverse from the whole network, so the traffic is not concentrated on just a point of it. That is the reason why it is necessary to study this technology and a P2P traffic generation and monitoring setting is needed. The goal in this project is to design a P2P traffic generation and monitoring setting, keeping in mind the special characteristics present in by this kind of networks avoiding some of the previous monitoring system flaws when capturing traffic from distributed networks.

4

5 D. Gabriel Maciá Fernández, profesor del departamento de Teoría de la Señal, Telemática y Comunicaciones de la Universidad de Granada, como director del Proyecto Fin de Carrera de D. Alejandro Fernández Haro. Informa: Que el presente trabajo, titulado: Entorno de experimentación para generación y monitorización de tráfico P2P. Ha sido realizado y redactado por el mencionado alumno bajo mi dirección y con esta fecha autorizo a su presentación. Granada, a 10 de Enero de 2011 Fdo: Gabriel Maciá Fernández.

6

7 Los abajo firmantes autorizan a que la presente copia de Proyecto Fin de Carrera se ubique en la Biblioteca del Centro y/o departamento para sea libremente consultada por las personas que lo deseen. Granada, a 10 de Enero de 2011 Fdo. Alejandro Fernández Haro. Fdo. Gabriel Maciá Fernández

8

9 Índice general 1. Introducción Redes P2P Qué es P2P? Tipos de redes P2P Clasificación según su grado de centralización Clasificación según su estructuración Mecanismos de seguridad Sistemas de monitorización de red Qué es un sistema de monitorización de red? Objetivos de este proyecto Motivación del proyecto Objetivos Análisis Requerimientos Requerimientos funcionales Requerimientos no funcionales Análisis del entorno de experimentación Análisis del laboratorio Análisis del sistema de gestión de monitorización distribuida Diseño Diseño del laboratorio Hardware y topología del entorno Configuración software Diseño del sistema de gestión de monitorización distribuida Sincronización de trazas Diseño del módulo Sonda Diseño del módulo Administrador Diseño del protocolo a nivel de aplicación

10 ÍNDICE GENERAL Implementación Implementación del laboratorio Montaje hardware Configuración de los equipos Instalación del software de generación de tráfico P2P y monitorización Implementación del sistema de gestión de monitorización distribuida Implementación del módulo Sonda Implementación del módulo Administrador Pruebas Pruebas del laboratorio Pruebas de conectividad en la red aislada Pruebas de acceso a Internet Pruebas emule Pruebas de accesibilidad Tabla resumen de las pruebas Pruebas del sistema de gestión de monitorización distribuida Pruebas de conexión Pruebas de cálculo de diferencia de relojes Pruebas de creación de una tarea Pruebas de cancelación de una tarea Pruebas de recopilación, mezcla y apertura de una tarea Tabla resumen de las pruebas Conclusiones Conclusiones Trabajo futuro

11 Índice de figuras 1.1. Arquitectura cliente-servidor Sistema de nodos peer-to-peer sin infraestructura central Escenario de intercambio de datos entre dos usuarios Red de acceso a Internet de un usuario medio Ventana principal de Wireshark Modos de acceso a Internet Topología de la red del laboratorio Interacción entre administradores y sondas en la red Diagrama de clases del módulo Sonda Diagrama de clases del módulo Administrador Protocolo a nivel de aplicación Esquema del cableado del laboratorio Interfaz gráfica del módulo Sonda Interfaz gráfica del módulo Administrador

12

13 Agradecimientos Este proyecto no habría sido posible de no ser por tres personas: Pedro, Gabriel y Rafa. Gracias a Pedro, porque en el tercer curso de estos estudios confió en mí y me dio la oportunidad de entrar en el departamento, permitiéndome así profundizar en mi interés sobre la telemática. Gracias a Gabriel, el director de este proyecto, porque siempre que he necesitado ayuda, no ha tardado en prestármela, ha gestionado toda la burocracia necesaria para que ésto llegara a buen puerto y no se ha desesperado con mi excesiva tranquilidad, sabiendo en todo momento cuándo y cómo motivarme para que no se congelase el ritmo de avance del trabajo. Y gracias a Rafa, quien, cuando estaba en un mar de dudas sobre qué carrera escoger, me habló de ésta de una manera que se convirtió en la primera, y casi única, opción que barajé en su momento. En lo oficial, gracias a la Universidad de Granada y a la beca de prácticas que me fue concedida puesto que se convirtió en el comienzo de la realización de éste proyecto fin de carrera. Gracias también al departamento de Teoría de la Señal, Telemática y Comunicaciones por la infraestructura y los equipos donados. Por otro lado, debo agradecer a mis padres y mi hermana, el apoyo y la comprensión prestados durante el trascurso de mis estudios y por cómo aún siguen mostrando la misma paciencia conmigo que cuando tenía que estar en brazos todo el día. Gracias a Marta por animarme en los momentos bajos y darme tantos momentos buenos que ayudan a afrontar los inconvenientes con mayor ímpetu. Gracias también a Jorge, Ramón, Dioni y Luis Carlos por todos los tirones de orejas que me habéis dado que me han hecho ser como soy. Y, al fin, gracias a mis compañeros de la carrera, a todos y cada uno de ellos por haber despertado mis dotes de liderazgo tras tratarme durante los cinco años como el delegado por defecto sin necesidad de más elecciones. Entre todos ellos, he de darles las gracias, especialmente, a Pablo, Pachus y Berta. Al primero, por las largas conversaciones que hemos tenido (y seguimos teniendo de vez en cuando) y a la irrompible pareja de prácticas, por permitirme ser uno de tres y enseñarme tanto en este tiempo. 13

14

15 Capítulo 1 Introducción El objetivo de este primer capítulo de introducción es proporcionar al lector una visión global del estado actual de las tecnologías involucradas durante la realización de este proyecto fin de carrera. Así pues se comentarán brevemente las características de las redes P2P comparándolas con la arquitectura cliente-servidor, utilizada tradicionalmente en Internet. Posteriormente se tratarán los aspectos más relevantes de los sistemas de monitorización de redes donde se mostrarán varios ejemplos comerciales Redes P2P En esta sección se realizará una breve introducción a las redes P2P de tal modo que, en primer lugar, se tratará una descripción de este tipo de redes para, a continuación, destacar las principales diferencias con el modelo cliente-servidor, comentando también, sus ventajas e inconvenientes frente a esta arquitectura. Tras ello, se realizará una clasificación de los tipos de red P2P mencionando ejemplos que se encuadren dentro de cada grupo Qué es P2P? Arquitectura cliente-servidor La arquitectura de red más extendida en Internet es la conocida como cliente-servidor. En este tipo de red se puede encontrar que los extremos de la conexión (los dos equipos que intercambian la información) cumplen dos roles bien diferenciados: Por un lado, un equipo (el servidor) pone a disposición del otro (el cliente) un conjunto de recursos en función de los servicios que pretenda ofrecer como, por ejemplo, los archivos de un sitio web. Por el otro, el cliente, normalmente, sólo se limita a realizar peticiones al servidor y a recibir toda la información contenida en la respuesta (siguiendo el ejemplo: los recursos de la web solicitada). El servidor suele ser accesible por todos o algunos clientes, dependiendo de su finalidad pública o privada, y atiende las peticiones de los clientes, respondiendo con la información o recursos solicitados. 15

16 CAPÍTULO 1. INTRODUCCIÓN 16 Figura 1.1: Arquitectura cliente-servidor. Al tratarse de un tipo de red donde todos los clientes se conectan al servidor y no entre ellos, es conocida como una red centralizada tal como se puede apreciar en el esquema mostrado en la Figura 1.1. Definición de red P2P La computación o trabajo en red P2P (Peer-to-Peer) es una arquitectura de aplicación distribuida que reparte tareas o cargas de trabajo entre los equipos pertenecientes a la misma, conocidos como pares (peers). En español, las redes P2P suelen ser, a menudo, traducidas como redes entre pares o redes entre iguales puesto que los pares disfrutan de los mismos privilegios en el entorno de dicha aplicación, trabajando de forma equitativa al aplicarseles a todos los mismos roles tanto de servidor como de cliente. En escenarios así se dice que los pares forman una red de nodos P2P (ver Figura 1.2). En este tipo de entornos los pares ponen a disposición de los otros participantes de la red una porción de sus recursos, tales como potencia de procesamiento, almacenamiento en disco o ancho de banda, sin la necesidad de una coordinación central realizada por servidores o host estables. 1 Los pares actúan tanto como proveedores como consumidores de recursos al contrario que el tradicional modelo cliente-servidor donde solamente los servidores proveen y los clientes consumen. El modelo cliente-servidor es muy útil en diversas aplicaciones como, por ejemplo, servidores web donde se almacenan los contenidos de un sitio web y espera la solicitud de un cliente para servírselos. Aún así, a medida que han ido surgiendo nuevas aplicaciones y servicios que hacen uso de las redes de datos, se ha podido comprobar que no resulta la solución más eficiente para sostenerlas. 1 Rüdiger Schollmeier, A Definition of Peer-to-Peer Networking for the Classification of Peer-to-Peer Architectures and Applications, First International Conference on Peer-to-Peer Computing, IEEE (2002).

17 CAPÍTULO 1. INTRODUCCIÓN 17 Figura 1.2: Sistema de nodos peer-to-peer sin infraestructura central. (a) Solución arquitectura cliente-servidor. (b) Solución arquitectura de red P2P. Figura 1.3: Escenario de intercambio de datos entre dos usuarios. Ventajas e inconvenientes de las redes P2P frente al modelo cliente-servidor Para explicar las ventajas e inconvenientes que presentan las redes P2P frente a la arquitectura tradicional de cliente-servidor, se utilizará a modo de ejemplo un escenario en el que dos equipos clientes pretenden intercambiar una información: Supóngase un escenario en el que dos usuarios están manteniendo una conversación mediante una aplicación de mensajería instantánea en la que no sólo intercambian sus opiniones mediante texto escrito sino que también comparten archivos privados tales como fotos o documentos importantes. En la Figura 1.3 (a) se puede observar que todos los paquetes intercambiados entre los equipos de los dos usuarios pertenecientes a la conversación deben atravesar un tercer nodo (el servidor) que realiza las funciones de puente entre ambos. Sin embargo, en la Figura 1.3 (b) se representa una conexión en la que todos los equipos de la red presentan las mismas funciones de servidor y cliente a la vez (una conexión P2P), por lo que no es necesario que un tercer equipo

18 CAPÍTULO 1. INTRODUCCIÓN 18 realice ninguna función que no tengan ya. De esta forma se puede crear una conexión directa 2 entre los dos equipos involucrados en la conversación. Con sólo describir los dos modelos propuestos en el ejemplo ya resalta una importante ventaja: la liberación y aprovechamiento de los recursos de la red. La principal diferencia entre ellos es la necesidad de un tercer equipo para llevar a cabo el intercambio de información. Para qué utilizar tres equipos en una tarea que se puede mantener con dos? Además, este efecto puede ser aún peor cuando no existe solamente una conversación entre dos equipos sino millones de ellas. En este último caso, tendríamos que disponer de un servidor que tuviera los recursos necesarios para realizar las funciones de puente en esa cantidad de transacciones. A medida que fuera aumentando el número de usuarios en la red, el servidor iría ocupando sus recursos de modo que llegaría un momento en el que se convertiría en el cuello de botella de las comunicaciones. En cambio, con una conexión P2P esa limitación desaparece. También, en relación a la existencia de un equipo intermedio, qué pasaría si el servidor analizase los mensajes o realizase una copia de los archivos que intercambian los usuarios? En ese caso, la privacidad de la información intercambiada podría verse seriamente vulnerada. Por ello, al eliminar el equipo servidor que realiza las funciones de puente aumentaría la privacidad de los datos transmitidos ya que los únicos equipos por los que circulan los datos serán los de los usuarios finales (ver nota al pie número 2). Por otro lado no todo son ventajas puesto que, actualmente, si atendemos a los accesos a Internet de los que un usuario medio suele disponer, están formados por uno o varios equipos que acceden a Internet a través de un router que realiza las traducciones de IPs y puertos, más conocido como NATs o NAPTs. Este proceso es necesario puesto que en este tipo de escenarios existen dos redes que están comunicadas a través del router: una red pública y otra privada. La red privada está formada por todos los equipos del usuario conectados a un concentrador o switch. Dicho concentrador está conectado a un módem que realice la comunicación con el exterior (red pública). Normalmente el concentrador y el módem suelen estar presentes en forma de un sólo equipo, comúnmente llamado encaminador (router). En cuanto a encaminamiento, todos los equipos dentro de la red privada poseen una dirección IP privada. Éstas tienen la característica de ser únicas en esa red pero pueden repetirse en cualquier otra red privada por lo que no son válidas para identificar un equipo a nivel global. Por contra, en la red pública las direcciones IP asignadas a los equipos son públicas y únicas a nivel global por lo que cualquier equipo al que se le ha asignado una IP de este tipo es accesible por cualquier otro equipo que tenga acceso a la red pública. Debido a ello, ningún equipo perteneciente a la red pública puede acceder directamente a uno con dirección IP privada por lo que existe la necesidad de que el router realice una traducción de la IP privada del equipo de su red interna a la dirección pública de la red externa de modo que el equipo externo que pretenda responder al mensaje sepa cómo encaminar su respuesta. Mientras tanto, el router va llevando un control de las traducciones que ha llevado a cabo para que, en caso de recibir la respuesta a la solicitud realizada por el equipo de la red privada, sepa a qué equipo debe entregársela. En cambio, cuando el router recibe un paquete desde la red pública 2 Es una conexión directa hablando a nivel de aplicación ya que en esta transferencia de datos necesariamente tendrán que participar otro tipo de nodos de la red tales como switches o routers para encaminar la información de uno a otro a nivel de enlace o red a menos que ambos extremos mantengan una conexión punto a punto.

19 CAPÍTULO 1. INTRODUCCIÓN 19 Figura 1.4: Red de acceso a Internet de un usuario medio. que no es respuesta a ninguna solicitud realizada desde la red privada, descarta el mensaje. La única excepción es que previamente se hayan configurado los parámetros necesarios para indicar al router a qué equipo de su red debe entregar la información recibida. Sabiendo esto, ahora se puede analizar qué ocurre con el ejemplo dado, suponiendo los dos modelos que se están comparando (también se va a suponer que los dos usuarios se encuentran en redes privadas diferentes y el servidor es accesible por ambos). En el caso del modelo cliente-servidor, como los dos usuarios están conectados al servidor podrían intercambiar la información con él mientras éste realiza su función de puente. En cambio, utilizando la arquitectura P2P, ningún usuario podría comenzar la conversación puesto que, suponiendo que conociesen la dirección IP pública del router de su interlocutor, la petición de conexión alcanzaría el router y éste, al no ser una respuesta a ninguna petición realizada desde su red interna, descartaría el mensaje a menos que el router estuviera previamente configurado para entregar ese tipo de peticiones al equipo del usuario final. Por otro lado, otro inconveniente que presentan las redes P2P frente a al modelo tradicional es referente a la autenticación de los usuarios: Para poder autenticarlos es necesario conocer sus credenciales. Este tipo de información no puede estar replicada en todos los equipos puesto que se vería vulnerada su seguridad y credibilidad ya que se podría hacer mal uso del conocimiento de la misma. Por ello es más recomendable disponer de la existencia de una entidad ajena a la conversación que pueda asegurar que los interlocutores son quienes dicen ser. Claro está que dicha entidad debe ser de confianza, aunque debido a que los objetivos de este proyecto fin de carrera no pretenden tratar temas de autenticación y seguridad, no se profundizará en el tema.

20 CAPÍTULO 1. INTRODUCCIÓN Tipos de redes P2P Las redes P2P pueden clasificarse en función de dos aspectos: su grado de centralización o según su estructuración Clasificación según su grado de centralización Atendiendo a su grado de centralización, las redes P2P pueden ser catalogadas dentro de tres grupos: redes P2P centralizadas, puras y mixtas. Redes P2P centralizadas Este tipo de red P2P se basa en una arquitectura de red similar a la estudiada en el modelo cliente-servidor. Las transmisiones, por tanto, se realizan a través del servidor central que realiza las funciones de punto de enlace entre los nodos y de control de la distribución de los nodos y sus recursos. Dos ejemplos de este tipo de redes son Napster y Audiogalaxy. Redes P2P puras Las redes P2P puras son aquellas que cumplen con la descripción formal de red P2P enunciada en el apartado Es decir, son aquellas redes en las que todos los nodos poseen los mismos privilegios y realizan el trabajo de forma equitativa sin la necesidad de un reparto centralizado desde un servidor o host estable. Dos redes muy famosas pertenecientes a este grupo son Overnet y Kad, las redes nativas sin servidores de los clientes edonkey y emule, respectivamente. Ambas redes basan su funcionamiento en variaciones del protocolo Kademlia el cual se encarga de descubrir la red de pares que comparten sus recursos. Más ejemplos de redes P2P puras son las redes Ares Galaxy, Gnutella, Freenet y Gnutella2. Redes P2P mixtas Otra solución que se planteó al problema del descubrimiento de los equipos pertenecientes a la red y los recursos compartidos consiste en un tipo de red que recogía lo mejor del modelo tradicional cliente-servidor y de la arquitectura P2P. Estas redes, clasificadas como mixtas o híbridas, disponen de uno o varios servidores donde se almacena la información del reparto de los recursos en la red y de los pares activos. De este modo, cuando un nuevo par accede a la red, se comunica con el servidor para presentar sus recursos disponibles. Así, en el momento en el que un par necesita utilizar alguno, realiza una petición al servidor, quien le indica qué par o pares pueden responder a sus necesidades. Unos ejemplos de redes de este tipo son BitTorrent, edonkey y Direct Connect y, aunque P2P se relacione comúnmente con la compartición de ficheros, en la actualidad este tipo de redes se utilizan en otros servicios muy bien conocidos como son Skype o Spotify.

21 CAPÍTULO 1. INTRODUCCIÓN Clasificación según su estructuración Por otro lado, si la clasificación se realiza en función a su estructuración, se pueden nombrar redes P2P estructuradas y no estructuradas. Redes P2P estructuradas En este tipo de redes se nombran usuarios responsables de una parte específica del contenido de la red. Así mantienen un tabla de hash distribuida en la que se asignan valores a cada contenido y usuario de la red. De este modo, cuando un usuario pretende acceder a un contenido específico, primero realiza una petición al usuario responsable del mismo. Éste, entonces, le responderá con la lista de usuarios en los que ese contenido está disponible. Ejemplos de este tipo de redes son aquellas basadas en el protocolo Kademlia. Redes P2P no estructuradas En las redes P2P no estructuradas, a diferencia de las anteriores, no se tiene un control de los contenidos disponibles en la red sino que, cada vez que un usuario requiere de un contenido, debe realizar una consulta que se propagará por inundación en la red tratando de llegar a todos los usuarios. De este modo, los que dispongan de dicho contenido, responderán confirmándolo. Procediendo así, se genera demasiado tráfico en la red desperdiciando el ancho de banda disponible. Algunas redes P2P no estructuradas son Napster, Gnutella, KaZaA y edonkey Mecanismos de seguridad De los mecanismos de seguridad utilizados en redes P2P, el que requiere mención en relación con este proyecto fin de carrera es el conocido como encriptación de protocolo o, como es llamado principalmente en los clientes de emule: ofuscación de protocolo. Este mecanismo de seguridad pretende cifrar los datos transmitidos de modo que los nodos intermedios, tales como encaminadores y demás elementos que participan en la transmisión de la información no sean capaces de interpretar la información transferida. Este mecanismo de seguridad se convertirá en una limitación del proyecto a estudiar en futuras versiones Sistemas de monitorización de red Una vez estudiadas las características más generales de las redes P2P, es necesario encontrar algún sistema que permita capturar el tráfico que generan para poder conocerlas más a fondo. Por ello, en esta sección se va a hablar de los sistemas de monitorización en red, su utilidad y algunos ejemplos comerciales Qué es un sistema de monitorización de red? El análisis del tráfico de una red es un ejercicio muy utilizado en el ámbito de las telecomunicaciones puesto que permite realizar actividades como recabar información sobre dicho tráfico

22 CAPÍTULO 1. INTRODUCCIÓN 22 y obtener estadísticas del mismo. Gracias a ello, se pueden cumplir objetivos como estudiar el flujo de mensajes que se intercambian en una sesión en la que se utilice un protocolo de interés, comprobar que una aplicación en red en fase de desarrollo está cumpliendo con el diseño de sus comunicaciones, detectar transmisiones no seguras o el envío masivo de tráfico innecesario por parte de un equipo afectado por malware con su correspondiente reducción del ancho de banda útil. Todo esto es posible gracias a los sistemas conocidos como de monitorización de red cuyo funcionamiento básico es la captura y el posterior análisis del tráfico que circula por el nodo en el que se está ejecutando. Algunos ejemplos comerciales de este tipo de sistemas son: Javvin Packet Analyser: Este analizador de protocolos es capaz de capturar paquetes Ethernet, analizar protocolos y reconstruir mensajes a nivel de aplicación. Interpreta todos los protocolos relacionados con TCP/IP y permite aplicar filtros. Según el fabricante sólo son necesarios 30 minutos de entrenamiento individual. Su precio es $249. Para más información consúltese la web del producto: Network General Sniffer Basic: Capaz de capturar paquetes Ethernet, incluye un análisis simple de protocolos (un análisis extendido sólo se puede encontrar en la versión Pro). Interpreta los protocolos relacionados con TCP/IP y, además, algunos de los más comunes que no están basados en TCP. Su entrenamiento es de una semana asistida por el fabricante y su precio es de más de $ Wildpackets Etherpeek: Posee las mismas características que el anterior aunque su precio ronda los $ Wireshark: Anteriormente conocido como Ethereal. Gracias a que cumple las mismas funciones que los sistemas anteriores, que dispone tanto de interfaz gráfica como por comandos, que es un proyecto de código abierto con una gran comunidad aportando mejoras diariamente y que es gratuito, es uno de los analizadores de protocolos más utilizado. Puesto que Wireshark es el sistema de monitorización de red más extendido de los mencionados, se realizará un estudio más profundo a sus características y funciones principales. En primer lugar, se comentará la ventana principal que presenta el programa, de la cual se muestra una captura de pantalla en la Figura 1.5. Si se comienza por la parte superior de la venta, lo primero que se muestra es la barra de menús donde, aparte de los habituales File (Archivo), Edit (Edición), View (Vista), Go (Ir), Tools (Herramientas) y Help (Ayuda), también están Capture (Capturar), Analyze (Analizar), Statistics (Estadísticas) y Telephony (Telefonía). El primero permite llevar el control de la captura, definiendo opciones como la interfaz de captura, la resolución de nombres en direcciones MAC o de red, actualizar la lista en tiempo real de paquetes mostrados en tiempo real o capturar en modo promiscuo (modo de captura en el que el nodo captura todo el tráfico al que tenga acceso vaya dirigido a él o no). El segundo permite realizar filtros, predefinidos o no, para que el análisis del tráfico sea más cómodo y selectivo. La tercera opción permite mostrar estadísticas, gráficas

23 CAPÍTULO 1. INTRODUCCIÓN 23 Figura 1.5: Ventana principal de Wireshark. y diagramas de flujo para el tráfico seleccionado. Por último, en el apartado Telefonía se ofrecen herramientas para decodificar el tráfico capturado que cumpla con el estándar o protocolo seleccionado y hasta, en algunos casos, se puede llegar a recuperar el audio de la conversación. Continuando el descenso por la interfaz gráfica, se encuentra una barra de botones que dan acceso a las opciones más utilizadas. A continuación se encuentra un campo en el que se pueden introducir parámetros del filtrado que se desea realizar a los paquetes capturados. En este aspecto, pulsando la opción Expression... se accederá a un cuadro de diálogo que ayudará a formular correctamente la petición de filtrado. En el siguiente paso hacia el fondo de la ventana, se encuentra el panel donde se muestra todos los paquetes capturados con la información del número de orden en el que se ha capturado, el momento en el que se ha hecho, el origen y el destino del paquete, el protocolo utilizado y una descripción resumida del mismo. Tras seleccionar un paquete de este panel, se mostrará en el mismo en los dos inferiores. El primero de ellos desglosa la información del mismo, clasificándola en función de la capa del modelo OSI a la que pertenece y presentándola en forma de árbol desplegable. El segundo muestra la estructura de la trama enviada en formato hexadecimal y ASCII Objetivos de este proyecto En esta sección se presentarán los motivos por los que es necesaria la utilización de un entorno de experimentación para la generación y monitorización de tráfico P2P, teniendo en cuenta las particularidades de estas redes. Tras ello, se procederá a definir los objetivos que

24 CAPÍTULO 1. INTRODUCCIÓN 24 deberá cumplir el entorno creado al final de la implementación de este proyecto Motivación del proyecto La necesidad de la creación de un entorno de experimentación para la generación y monitorización de redes P2P surge a partir de las ventajas presentadas por las mismas frente al tradicional modelo cliente-servidor. Dichas ventajas consisten en una mejora en el rendimiento de las nuevas aplicaciones que hacen uso de las redes con arquitecturas distribuidas, como es el caso de la computación distribuida y similares. Debido a ello, es muy recomendable enfocar proyectos en el estudio de estas redes y la investigación de posibles mejoras, lo que conlleva a la utilización de un entorno de experimentación como el que se pretende implementar en este proyecto. Este entorno debe presentar unas características y funcionalidades que pueden difererir de otros no diseñados específicamente para este fin como, por ejemplo, la manera en la que se deberá monitorizar el tráfico Objetivos A continuación se pretenden fijar los objetivos de este proyecto para que cumpla las funciones necesarias de modo que el resultado final pueda ofrecer las funcionalidades necesarias en el estudio del funcionamiento de las redes P2P: Por ello, en primer lugar, se buscará el diseño y la implementación de un entorno que permita la generación de tráfico P2P tanto en ámbitos controlados como no controlados. Además, dicho entorno deberá disponer de un sistema de monitorización de tráfico que permita la captura y el posterior análisis conjunto del tráfico generado por todos los nodos pertenecientes a la red P2P en uso.

25 Capítulo 2 Análisis Este capítulo tiene como objetivo realizar un estudio de los requisitos que debe cumplir la solución desarrollada por este proyecto fin de carrera. Tras ésto, se analizarán posibles soluciones que los cumplan, identificando y explicando sus ventajas e inconvenientes Requerimientos A continuación se presentarán los requisitos del entorno de experimentación en función de su clasificación según si cubren aspectos funcionales o no funcionales. Los primeros identificarán las funciones de las que podrá disfrutar el usuario final, mientras que los segundos describirán el resto de características que se necesiten para el correcto funcionamiento del entorno Requerimientos funcionales En esta sección se describirán los requisitos que debe cumplir el entorno final implementado de cara a las posibilidades que presta al futuro usuario del mismo. Configuración a medida En primer lugar, los equipos pertenecientes al entorno de experimentación deben ser versátiles para que el usuario pueda plantear el mayor número de escenarios posibles de cara a realizar un estudio más profundo. Para ello, los equipos han de permitir ser configurados sin ninguna limitación por lo que deberán utilizar un sistema operativo que cumpla con esta condición. Multiplataforma El entorno de experimentación final no debe ser dependiente de una única plataforma o tecnología, sino que debe permitir el estudio de las redes P2P en la mayor cantidad posible de escenarios diferentes. Por ello, el entorno implementado deberá ser multiplataforma. 25

26 CAPÍTULO 2. ANÁLISIS 26 Capacidad de funcionar tanto en ambientes controlados como no controlados Se debe realizar una configuración del entorno de experimentación de manera que el usuario pueda decidir en cual trabajar en función de sus necesidades. Utilizar un entorno controlado permitirá poder realizar el estudio del tráfico de una manera más estricta y limpia (con el menor tráfico posible procedente de otras aplicaciones o equipos), mientras que, en ambientes no controlados puede influir otro tráfico no relacionado con el generado en el estudio, lo que permitirá obtener resultados más fiables como resultado de la investigación. Accesibilidad Los equipos del entorno de experimentación deberán ser accesibles desde cualquier otro nodo con acceso a Internet de modo que se le permita al usuario trabajar con él aunque sea físicamente imposible su acceso. Generación de tráfico P2P Para que se puedan realizar las pruebas pertinentes sobre tráfico P2P, el entorno configurado deberá incorporar el software necesario para la generación de tráfico. Éste debe permitir el uso de tráfico de diferentes tipos de red, tanto estructuradas como no estructuradas, puras y mixtas. También será de interés utilizar distintos clientes para una misma red de cara a las posibles diferencias que puedan presentar en su funcionamiento. Monitorización de tráfico Al igual que se requiere la instalación del software destinado a la generación de tráfico P2P, también se necesitan aplicaciones para la captura y posterior análisis del mismo. Gestión de la monitorización distribuida El entorno de experimentación deberá permitir al usuario programar la realización de capturas del tráfico de un modo distribuido desde un puesto de trabajo. Esta funcionalidad ha de ser capaz de llevar a cabo un control de las mencionadas capturas, de modo que, posteriormente, puedan ser visualizadas respetando el orden de aparición de los eventos en las transmisiones. Visibilidad de la actividad de monitorización Por otra parte, se presentará la opción de consultar el estado de las monitorizaciones en ejecución o programadas en el entorno. De este modo, si un usuario quiere utilizarlo para realizar un estudio pero se percata de que hay una tarea de monitorización programada para ese instante, debería abstenerse de usarlo para no introducir tráfico no deseado en la captura realizada. El mismo caso podría aplicarse para en el supuesto en el que el usuario desease desconectar el entorno pero no lo hiciese tras comprobar la existencia de una sesión de monitorización en curso.

27 CAPÍTULO 2. ANÁLISIS 27 Integración del software de gestión de la monitorización distribuida con el de monitorización de tráfico Deberá existir una integración de las opciones de monitorización de tráfico en las funciones de gestión de la monitorización distribuida. Así se podrá permitir al usuario la utilización de las primeras a través de las segundas, además del tratamiento y la visualización de la información de varias maneras distintas. Generación del menor tráfico no deseado posible Puesto que se desea implementar un entorno de experimentación, será necesario minimizar los factores externos que puedan llevar a una mala conclusión por los datos mostrados en los estudios. Por ello, se deberá realizar una configuración de manera que se genere el menor tráfico no deseado posible en la red para conseguir así que las capturas realizadas sean lo más cercanas posibles a las transmisiones realizadas por el escenario a estudiar. Ahorro de espacio en disco Es necesario que, en el entorno de experimentación, se realice un control de los ficheros generados en las sesiones de captura de tráfico. Estos archivos pueden llegar a presentar unos tamaños consideradamente grandes por lo que consumirán una gran parte de la capacidad de almacenamiento cuando, en ocasiones, ya no van a ser utilizados más. Por ello, será recomendable su organización y borrado, si procede, para poder reaprovechar los recursos de los que se disponga Requerimientos no funcionales En esta sección se describirán las características y funciones que debe cumplir la solución presentada al final de la realización de este proyecto fin de carrera pero que no son directamente aprovechadas por el usuario. Es decir, esta sección está dirigida a recopilar los requisitos que necesariamente debe implementar este proyecto pero que no pueden ser catalogados en la clasificación del apartado anterior. Escalabilidad El entorno de experimentación presentado han de funcionar de la misma manera independientemente del número de nodos relacionados con esta tarea y de si uno o varios de los equipos involucrados pertenecen a la red o son externos a ella. Portabilidad La mayoría de las funcionalidades presentadas deberán poderse ejecutar en el mayor número de sistemas operativos posible, de modo que sea reutilizable en otros entornos con diferentes escenarios y configuraciones.

28 CAPÍTULO 2. ANÁLISIS 28 Sencillez de uso Por último, todas las funcionalidades y opciones que integre el entorno de experimentación deben presentar la información y sus posibles acciones mediante una interfaz gráfica que habilite su uso al usuario sin la necesidad de una excesiva introducción de comandos. Además, el entorno de experimentación debe permitir al usuario una interacción con el mismo de una manera ordenada, para que el mismo pueda controlarlo todo desde un único puesto de trabajo Análisis del entorno de experimentación En esta sección se realizará un análisis que permita obtener una primera aproximación a las decisiones tomadas para el diseño del entorno de experimentación de modo que así se puedan cumplir los requisitos planteados anteriormente. División del trabajo en dos tareas globales El desarrollo del entorno de experimentación será dividido en dos bloques principales: En primer lugar se tratará la creación de un laboratorio donde se podrán realizar los estudios que se deseen bajo un entorno controlado y, por otro lado, para el caso de ambientes no controlados, será necesario capturar el tráfico de manera local en cada uno de los nodos que actúen, por lo que se requerirá de un sistema de gestión para la monitorización distribuida. En este último aspecto se ha tomado la decisión de realizar un desarrollo propio puesto que no se ha podido encontrar ninguna solución comercial existente que cumpliera los requisitos planteados Análisis del laboratorio A continuación se detallarán las soluciones propuestas a los requisitos que afectan a la implementación del laboratorio. Ambientes controlados y no controlados Para que se pueda analizar, tanto en ambientes controlados como en los no controlados, el comportamiento del tráfico P2P generado en el entorno de experimentación, será necesaria la configuración de dos redes: una que presente la característica de ser aislada y mantenga el control de los equipos asociados a ella y otra que permita el acceso a Internet, dando así el caracter no controlado. El entorno controlado permitirá generar el tráfico según las necesidades impuestas por el usuario, de modo que se pueden estudiar al detalle ciertos procesos o fases en la comunicación o, incluso provocar anomalías para conocer las reacciones a éstas. El tráfico que se analiza en este tipo de entornos no suele corresponder a los patrones que realmente utilizan los usuarios. Por otro lado, los ambientes no controlados permiten estudiar el tráfico realmente generado en la red por los usuarios. Ésto permite obtener conclusiones más fiables y coherentes con la realidad.

29 CAPÍTULO 2. ANÁLISIS 29 A continuación se presentará cómo se puede configurar el acceso a Internet de modo que el laboratorio se pueda utilizar también en los estudios realizados para entornos no controlados. Red de acceso a Internet En cuanto al acceso de los equipos a un entorno no controlado como Internet, se pueden realizar dos configuraciones distintas que disfrutan cada una de unas ventajas y unos inconvenientes. La primera solución consiste en la configuración de un acceso a Internet propio para cada equipo, representada en la Figura 2.1 (a). Con esta configuración cada uno de los equipos dispondrá de una conexión a Internet exclusiva en la que no se encuentre detrás de ningún cortafuegos o firewall y tenga asignada una dirección IP pública para él mismo. Gracias a ésto, los equipos están mucho más accesibles al resto de pares de la red ya que las comunicaciones no deben atravesar cortafuegos ni NATs. El problema que presenta es que, en situaciones normales, no se suele disponer de 3 conexiones con IPs públicas fácilmente. Otra posible opción que permite el acceso a Internet consiste en la conexión de los equipos a un enrutador con funciones de módem, a través del cual se encamine el tráfico hacia Internet (ver Figura 2.1 (b)). Éste es el escenario más habitual en una conexión de banda ancha comercial y cuenta con la ventaja de que permite conocer los mensajes intercambiados por los equipos de la red P2P para salvar la existencia de NATs. En cambio, ese mismo aspecto puede convertirse en un inconveniente porque puede bloquear tráfico interesante para el estudio. La disponibilidad de una conexión a Internet también permite realizar la configuración requerida para solventar el requisito de accesibilidad. Accesibilidad Para que un usuario pueda controlar de manera remota los equipos del laboratorio, será necesaria la configuración de un método de acceso. Por otra parte, para saber cómo acceder a los mismos, se planteará el uso de un sistema de nombres de dominio. De este modo, no será necesario memorizar la dirección pública asignada al equipo en su formato numérico (dirección IP), sino que, en su lugar se utilizará una dirección canónica, más cercana al lenguaje humano, por lo que también es más fácilmente identificable y recordable. Existe un problema añadido que se puede identificar a raíz del análisis de las conexiones realizadas a través de accesos convencionales a Internet. En ellos, la dirección IP pública se asigna mediante el protocolo DHCP, el cual se encarga de distribuir el rango de direcciones de las que dispone de manera que sean reutilizables. Así pues, cada vez que el equipo se desconecte de la red de acceso a Internet y vuelva a conectarse, será muy probable que la dirección que se le haya asignado sea distinta a la de la sesión anterior. Por tanto, es necesario que el servicio de nombres de dominio (DNS) sea dinámico, es decir, se actualice periódicamente. Multiplataforma Debido al requisito Multiplataforma, es necesario disponer de varios sistemas operativos con arquitecturas distintas en el laboratorio. Ésto puede ser solventado de dos maneras distintas:

30 CAPÍTULO 2. ANÁLISIS 30 (a) Conexión directa y propia de cada equipo. (b) Conexión indirecta a través un router. Figura 2.1: Modos de acceso a Internet. NOTA: Las conexiones representadas en la Figura 2.1 con líneas discontinuas pueden ser establecidas mediante enlaces cableados o inalámbricos. la primera se basa en la configuración de un número de equipos con un sistema operativo y otro grupo en el que se instale otro. Así se continuará debiendo disponer de tantos grupos de ordenadores como sistemas operativos distintos se deseen instalar. Con este método, suponiendo que, para realizar pruebas en un tipo de plataforma, sean necesarios x equipos y que se desea configurar solamente dos sistemas operativos distintos, el número de equipos requeridos será de 2x, el doble de los, inicialmente, necesarios para la realización de los estudios en el entorno. La segunda opción disponible consiste en la instalación de todos los sistemas operativos en el mismo equipo, lo cual, se puede llevar a cabo también, principalmente, de dos maneras: instalación nativa o mediante máquinas virtuales. Instalación nativa: Consiste en crear tantas particiones en el disco duro como sistemas operativos se pretendan instalar y alojarlos en ellas. El mayor inconveniente de esta solución es que cada equipo podrá ejecutar un solo sistema operativo a la vez y será necesario reiniciarlo para poder acceder a otro. Por otra parte, también presenta una ventaja derivada del mismo inconveniente: el equipo no tiene que repartir sus recursos hardware entre varios sistemas operativos por lo que el rendimiento es óptimo. Máquinas Virtuales: El concepto máquina virtual consiste en que, mediante software, se genera un equipo virtual utilizando porciones del hardware del equipo real. Ese equipo virtual es capaz de correr un sistema operativo completo e independiente del que se está ejecutando de forma nativa. En este contexto, el sistema operativo desde el que se ejecuta

31 CAPÍTULO 2. ANÁLISIS 31 la aplicación que genera la máquina virtual es conocido como el anfitrión, mientras que al que hace las funciones de segundo sistema operativo al ser ejecutado en el equipo virtual se le nombra como el huésped. Presenta la ventaja de poder disponer de dos sistemas operativos a la vez en un mismo equipo con sólo generar una máquina virtual. Además permite multiplicar el número de equipos que acceden a la red sin el gasto de nuevo hardware. Por contra, el mayor inconveniente conocido es que no presenta un rendimiento óptimo, puesto que varios sistemas operativos completos se encuentran consumiendo los recursos del mismo equipo. Generación y monitorización del tráfico P2P Para estas funcionalidades, será necesario seleccionar dos tipos distintos de redes P2P que permitan estudiar las diferencias entre ellas. Para el caso de una red estructurada y pura, se utilizará la red Kad, mientras que para el tipo de red no estructurada y mixta, edonkey. En cuanto al software de monitorización, el utilizado será Wireshark por ser gratuito y el más extendido en el campo de las telecomunicaciones Análisis del sistema de gestión de monitorización distribuida A continuación se realizará el análisis del sistema que se utilizará para la gestión de la monitorización distribuida en base a los requisitos definidos anteriormente. Carácter distribuido Debido a que, tal y como se comentó en la definición de los requisitos en este mismo capítulo, la monitorización se realizará de modo distribuido, por lo que será necesaria la gestión de la misma. Para ello, el sistema de gestión a desarrollar estará formado por dos módulos principales: un módulo administrador y otro al que se le llamará sonda. El primero dispondrá de las funciones de gestión propiamente dichas, mientras que el segundo cumplirá el papel de acometer las instrucciones ordenadas por el primero. La idea de funcionamiento de estos dos módulos consistirá en que un usuario podrá, desde el puesto de trabajo donde se ejecuta el administrador, controlar una red de sondas que realizarán la captura del tráfico en función de las órdenes del primero. Sincronización de las trazas Debido a que la captura del tráfico se realizará de manera distribuida, para que las capturas tomadas de esta forma se puedan fusionar en una sola, respetando el orden correcto de los mensajes transmitidos, se deberá establecer un mecanismo de sincronización de las trazas de modo que permita presentarlas de forma coherente con el orden del tráfico generado. Se profundizará en cómo realizarlo en el capítulo 3 de diseño.

32 CAPÍTULO 2. ANÁLISIS 32 Tecnologías de programación Por último se tratará de resolver el requisito de portabilidad. En este caso, principalmente, se puede hablar de dos soluciones: La primera está basada en tecnologías web. Gracias a ella, cualquier equipo con un navegador disponible podría acceder al sistema. El problema presentado por éstas es la limitación, fijada por seguridad, mediante la cual no se pueden ejecutar desde el navegador aplicaciones de terceros instaladas en el equipo, condición necesaria para asegurar el cumplimiento del requisito en el cual se valora la integración de este sistema con el software de monitorización. La segunda solución barajada, y finalmente seleccionada, consiste en la utilización del lenguaje de programación Java. Las aplicaciones que hacen uso de esta tecnología pueden ser ejecutadas en cualquier equipo que disponga del entorno de ejecución de la misma Java Runtime Enviroment (JRE). Además, esta tecnología sí permite la ejecución de comandos a nivel de la terminal (command prompt en Windows), por lo que se pueden ejecutar aplicaciones de terceras partes. Por otra parte, también se ha valorado la experiencia con esta plataforma del desarrollador de este proyecto.

33 Capítulo 3 Diseño En este capítulo se pretende describir el diseño de los módulos que componen el entorno de experimentación que resulte al final de este proyecto. Para ello, en primer lugar se realizará el diseño del laboratorio que formará el entorno pretendido y, a continuación, el del software de gestión de monitorización distribuida de desarrollo propio Diseño del laboratorio En esta sección se tratará el diseño del laboratorio para poder implementar en él una red de ordenadores capaz de cumplir con todos los requisitos nombrados en el capítulo 2. Para ello, se comenzará diseñando todas las características hardware y de topología del entorno. Y, más tarde, se procederá a la descripción de la configuración que debería realizarse al software escogido para proporcionar a los equipos las capacidades necesarias para el desarrollo de las actividades que deben ser capaces de realizar Hardware y topología del entorno Número necesario de equipos En primer lugar será necesario conocer el número de equipos de los que se debe disponer para llevar a cabo este proyecto. Para ello se ha de suponer el peor escenario en cuanto a número de equipos requeridos. Se tomará aquel en el que se pretende estudiar, bajo un entorno controlado, un tipo de red P2P centralizada o una mixta. Ambas redes presentan la necesidad de, al menos, dos equipos que intercambien su información y un servidor que realice la gestión de los usuarios y el contenido compartido de la red. Además, al pretender que los equipos trabajen en un entorno cerrado o controlado, los equipos necesarios deben permanecer a dicha red. Debido a ello, se precisará de, al menos, tres equipos en el laboratorio. Red aislada Para la implementación de la red aislada, es necesario implementar una topología en estrella en la que los equipos estén conectados mediante cable Ethernet a un concentrador o enrutador 33

34 CAPÍTULO 3. DISEÑO 34 que realizará el encaminamiento necesario para que los equipos puedan comunicarse. Así se evita que un equipo no autorizado pueda acceder a dicha red puesto que el único modo de incorporarse a la misma sería accediendo al lugar donde se encuentra el dispositivo de interconexión para conectarse a él físicamente. Para ello, será necesario que el switch utilizado deba disponer de un número de puertos Ethernet, como mínimo, igual al número de equipos de la red, los cuales, a su vez, deben disponer de una tarjeta de red cada uno con puerto Ethernet. En cuanto a direccionamiento, la única condición indispensable es que las direcciones IP de los equipos de esta red y la máscara de red sean tales que no identifiquen otras redes como internas a ésta (se ha de tener presente que esta red debe ser cerrada para asegurar que el entorno sea controlado). Por ello, la decisión tomada es utilizar la máscara de red Es suficiente para incluir a los equipos que formarán parte de la red y presenta la comodidad hacia el administrador de la misma para identificar redes distintas con solo atender al tercer octeto si se lee de izquierda a derecha. Es decir, una red podría identificarse por la dirección IP , permitiendo a los equipos pertenecientes a la misma adoptar direcciones dentro del rango al ; y otra red, distinta y externa a la anterior, podría utilizar cualquier otra dirección IP dentro del rango a , exceptuando la ya asignada. Por otro lado, otras redes externas serán las que utilicen direcciones IP con el primer o segundo octeto distinto. Por tanto, las direcciones IP seleccionadas para esta red, serán: Máscara de red: Dirección IP de la red: Dirección IP del enrutador: Dirección IP del primer equipo: Dirección IP del segundo equipo: Dirección IP del tercer equipo: Todas estas direcciones se configurarán para que sean estáticas (no se asignen automáticamente) de modo que se pueda asegurar que no variarán sin permiso del administrador de la red. Por otro lado, es recomendable asignar nombres a los equipos y configurarlos de modo que se preste al usuario la comodidad de no tener que memorizar esas direcciones para iniciar comunicaciones entre ellos. Un ejemplo de esto: Supóngase que el usuario quiere ejecutar el comando ping para comprobar la conectividad entre su puesto de trabajo y, por ejemplo, el tercer equipo. Para ello, desde un intérprete de línea de comandos, debería escribir ping En cambio, si el tercer equipo tiene asignado un nombre tal como tercerequipo, el usuario sólo tendría que ejecutar ping tercerequipo, algo más cómodo de recordar y de interpretar por ser más cercano al lenguaje humano. En este aspecto, se deben escoger nombres que sean fácilmente diferenciables, es decir, si se escogen nombres como equipoa, equipob, equipoc, etc., en el caso de analizar una serie de comandos de este estilo, será complicado atender la diferencia. Por ello, en este proyecto, al ser tres los equipos utilizados, se han seleccionados tres nombres que tengan relación

35 CAPÍTULO 3. DISEÑO 35 pero, a la vez sean fácilmente diferenciables: mortadelo, filemon y el super. Además, su configuración estará pensada para que, en el escenario de una red mixta o centralizada, los dos primeros ejecuten las aplicaciones cliente y el último realice las funciones de servidor. Red de acceso a Internet Debido a que el entorno en el que se pretende implementar el laboratorio dispone del acceso a cviugr-v2, una red inalámbrica mediante la cual se obtiene una conexión que se podría clasificar dentro de las del primer tipo en la diferenciación realizada en la sección 2.2.1, será la escogida para este proyecto fin de carrera. Aún así, el enrutador que realiza las funciones de intermediario en la red cerrada recién definida dispondrá de un puerto inalámbrico, inicialmente desactivado, a través del cual se pueda implementar la segunda opción en caso de necesidad. Las direcciones IP de esta red serán asignadas automáticamente por el proveedor del servicio de un modo no estático (no se asignan siempre las mismas direcciones IP) por lo que se necesitará configurar el servicio de DNS dinámico, el cual se comentará a continuación Configuración software DNS Dinámico Puesto que en la conexión cviugr-v2 las direcciones IP son asignadas automáticamente mediante el protocolo DHCP descrito en el capítulo 2, es necesario utilizar un método que permita vincular una dirección canónica o dominio con la dirección IP pública actual, por ejemplo: gracias a este servicio, el usuario puede utilizar una dirección de la forma mortadelo.tia.com, filemon.tia.com, super.tia.com o mortadelo.com, filemon.com, etc. para acceder de manera remota al equipo de interés desde cualquier otro nodo conectado a Internet, cuya configuración se realizará más adelante. Para que este servicio funcione es necesario actualizar la dirección IP pública asignada cada cierto periodo de tiempo. Por ello, se deberá instalar y ejecutar en cada inicio del sistema un cliente o demonio encargado de realizar esta actualización. De las diferentes opciones comerciales existentes, la solución escogida para este fin será la ofrecida por No-IP 1 en su versión gratuita, la cual presenta algunas limitaciones que no se pretenden tratar y se pueden consultar en el sitio web del servicio. Acceso remoto Para permitir controlar a los equipos del laboratorio desde cualquier nodo conectado a Internet se habilitará la funcionalidad de acceso remoto. Las soluciones que se barajarán son las siguientes: SSH: Permite acceder al equipo mediante una consola, utilizando el protocolo de seguridad SSH y cualquier programa que haga uso del mismo. Además, el acceso realizado mediante esta opción es seguro ya que el tráfico generado está cifrado de modo que las 1

36 CAPÍTULO 3. DISEÑO 36 capturas que se realicen en la red no pueden obtener las credenciales de acceso. Por último, comentar que también soporta la transferencia de archivos. X-Window: Es una variante de SSH. Utiliza el protocolo anterior para que el acceso al equipo sea de modo seguro pero, además, brinda la oportunidad de ver la interfaz gráfica del software utilizado. El mayor inconveniente que presenta es que cada vez que un usuario realiza un acceso, se genera una nueva sesión para el mismo por lo que si, por ejemplo, dos usuarios acceden remotamente y ejecutan cada uno una máquina virtual, el equipo al que se está accediendo deberá procesar y ejecutar ambas solicitudes, por lo que el rendimiento será ínfimo. Además, suponiendo el mismo ejemplo, si los dos usuarios desean monitorizar un tráfico generado bajo control, sus capturas se verán afectadas por el tráfico generado por el otro usuario. Por otra parte, si lo que se desea es acceder para ver los progresos de una tarea previamente encargada en una sesión presencial anterior, con este método no se podrán recuperar las aplicaciones y ventanas que quedaron abiertas en la misma. Por último, cabe recalcar que esta solución no es capaz de adaptar la gama de colores a la capacidad de la conexión por lo que, si se accede desde un lugar donde el ancho de banda es bajo, se percibirá una respuesta intermitente por parte del equipo remoto. VNC: Es otra opción de cara al acceso a las interfaces gráficas. Este modo de acceso permite recuperar la sesión abierta en la que se dejó al equipo en su última interacción con el mismo. Además, es capaz de adaptar la calidad de la imagen al ancho de banda disponible por lo que es más indicado en cuanto a requisitos de la red. Una de sus opciones es la de controlar el cursor del equipo al que se pretende acceder, de modo que, si está habilitada, sólo un usuario podrá controlarlo correctamente y, de este modo, puede conocer si hay otros usuarios accediendo al mismo. Por contra, a diferencia de los dos métodos anteriores, no permite la transferencia de archivos. Para este laboratorio se habilitarán los tres tipos de acceso puesto que las características propias de cada uno pueden resultar provechosas dependiendo del fin para el que se utilicen. Multiplataforma (varios sistemas operativos) Para dotar al laboratorio de un entorno multiplataforma, será necesario instalar, al menos, dos sistemas operativos: uno basado en entornos UNIX y otro en Windows. La opción seleccionada de entre las explicadas en el capítulo 2 para la realización de este laboratorio ha sido la creación de máquinas virtuales para aprovechar la característica de introducir más equipos en la red sin la necesidad de adquirir otros físicos. Ésto lleva a plantear la siguiente decisión: cuál será el sistema operativo anfitrión y cuál el huésped? Para decidirlo, hay que atender a otros requisitos fijados en el capítulo anterior. Especialmente aquel que pretende que los equipos (reales) sean altamente configurables. Ante este requisito, hay que decantarse por un sistema operativo basado en entornos UNIX para el equipo anfitrión, de modo que el huésped ejecutará Windows. Como entorno UNIX se ha elegido la distribución de Linux Ubuntu debido a la cercanía y los conocimientos de uso del mismo por parte del alumno. En cuanto a Windows, al ejecutarse

37 CAPÍTULO 3. DISEÑO 37 en una máquina virtual, se requiere una versión que sea poco pesada de ejecutar. Por tanto, la versión escogida es Windows XP. Para terminar con el diseño de la multiplataforma, hay que comentar que, para que los equipos virtuales aparezcan de forma lógica como equipos conectados directamente a la red habrá que generar una interfaz de red virtual a la que se conectará la máquina virtual. Además, dicha interfaz deberá estar ligada con la interfaz de red real mediante un puente, también virtual. Con esta configuración, se puede obtener una topología lógica de la red como la mostrada en la Figura 3.1. (atiéndase también a las direcciones IP asignadas a las nuevos equipos ) Generación de tráfico P2P Para dotar a los equipos de la capacidad de generar tráfico P2P en las redes edonkey y Kad, se utilizará un software que sea compatible con ellas. Para ello, los clientes más indicados son emule para entornos Windows y amule para el resto. Por otra parte, si se van a realizar pruebas en un entorno controlado, también es necesario que el servidor que gestiona la red edonkey esté presente en la red. Por ello, se hará uso del software eserver, el cual está disponible para sistemas operativos basados en Linux y Windows. Monitorización del tráfico Para realizar esta tarea, se concluyó en el capítulo 2 que el software a utilizar será Wireshark. Éste software también incluye varias funciones que se pueden ejecutar desde un intérprete de línea de comandos permitiendo así, su acceso desde otras aplicaciones, lo que ayudará a la implementación de la integración de éste en el sistema de gestión de monitorización distribuida Diseño del sistema de gestión de monitorización distribuida Para gestionar la monitorización del tráfico de la red de un modo distribuido, permitiendo así que el usuario pueda programar la ejecución simultánea de capturas del tráfico en todos los equipos desde un solo puesto de trabajo, es necesario disponer de un sistema con mencionada finalidad. En este proyecto fin de carrera se realizará un desarrollo propio de dicha utilidad. El sistema estará basado en dos módulos claramente diferenciados: Un módulo Sonda y un Administrador, cuya distribución en la red puede ser similar a la mostrada en la Figura 3.2. Además, ambos módulos presentarán en común la siguiente característica: Integración con el paquete Wireshark Tal y como se adelantó en el capítulo 2, ambas aplicaciones harán uso de distintas funcionalidades que ofrece el paquete Wireshark y su interfaz de línea de comandos. El primer módulo lo utilizará para detectar las interfaces de red desde las que es posible observar el tráfico y para realizar el propio proceso de captura con volcado a un fichero mediante el comando tshark. Mientras tanto, el segundo módulo hará uso de mergecap, también presente en este paquete, para fusionar las capturas de una misma sesión procedentes de otras capturas;

38 CAPÍTULO 3. DISEÑO 38 Figura 3.1: Topología de la red del laboratorio.

39 CAPÍTULO 3. DISEÑO 39 Figura 3.2: Interacción entre administradores y sondas en la red. de tshark para leer el archivo creado a partir de esta fusión y de wireshark para abrir el mismo archivo bajo la interfaz gráfica del paquete Sincronización de trazas Antes de proceder al diseño de los dos módulos que formarán parte del sistema de gestión de monitorización distribuida, es necesario realizar la decisión de cómo se asegurará la coherencia de las trazas con el orden cronológico de generación del tráfico. Para cumplir esta funcionalidad el equipo desde el que se ejecuta el módulo administrador del software de gestión de monitorización distribuida debe llevar un control de sincronización de las trazas. Para ello, será necesario conocer la diferencia entre los relojes internos de los equipos involucrados en la monitorización del tráfico. Existen, principalmente, dos opciones con las que llevarlo a cabo: La primera es la sincronización de los relojes de los equipos. De esta forma la diferencia entre dichos relojes es mínima por lo que se puede actuar como si fuese nula. Esta solución presenta dos problemas: Por un lado, implementar un sistema de sincronización de relojes que modifique la hora del sistema operativo puede que entre en conflicto con el servicio nativo del mismo y la hora se vuelva a modificar, deshaciendo así el cambio realizado por este sistema. Por otro lado, si hay que sincronizar los relojes de la red, se necesita un equipo que sirva de referencia de tiempo. Cuál se escoge? Si se decide que el administrador realice esa función, puede entrar en conflicto con otro administrador que se esté ejecutándo en la red y, si se nombra a un equipo para que realice esa gestión en la red, los equipos de fuera de la misma pueden estar ligados a otro servidor de tiempo. Debido a los problemas presentados por la anterior, se utilizará una segunda opción consistente en el cálculo de la mencionada diferencia de relojes y utilizarla para fijar la fecha de programación de captura de tráfico a base de aplicar esa diferencia calculada a la fecha que el

40 CAPÍTULO 3. DISEÑO 40 Figura 3.3: Diagrama de clases del módulo Sonda. usuario decidió establecer para la tarea. Este tipo de gestión de los relojes se deberá, por tanto, realizar en el módulo administrador puesto que es el encargado de programar las horas de inicio y fin de las tareas. Así pues, se profundizará más en el diseño de la realización de este cálculo en la subsección Diseño del módulo Sonda Este módulo será el encargado de permitir la comunicación entre el administrador y el equipo donde se está ejecutando. Gracias a él, el administrador será capaz de programar capturas del tráfico y recopilarlas. En la Figura 3.3 se incluye un diagrama con las clases de las que dispondrá, su interacción entre ellas, utilidad y los principales atributos. Interfaz gráfica informativa La interfaz gráfica mostrada al ejecutar este módulo deberá ofrecer la información más relevante en el sistema. Esta información está formada por el número de administradores conectados en ese momento a la sonda, la interfaz de captura que se está utilizando (pudiendo cambiarla manualmente desde la misma) y, como datos más importantes, las tareas programadas y su información de estado como el administrador que la ordenó, la fase de ejecución en la que se encuentra y el periodo en el que está programado que funcione. Aparte de la selección de la interfaz de captura a utilizar, el usuario no podrá ejecutar ninguna otra acción sobre la misma. Aún así, puesto que se pretende acceder a las interfaces de red para realizar las capturas, aunque sea a través del comando tshark, será necesario que este módulo sea ejecutado en modo administrador.

41 CAPÍTULO 3. DISEÑO 41 Comunicación con el administrador Puesto que la sonda se limitará a realizar las acciones indicadas desde el administrador, se debe mantener una comunicación con el mismo. Además, la sonda ha de poder ser accedida por varios administradores ya que varios de ellos pueden necesitar sus capturas de tráfico a la vez. Por ello, tras ejecutarse, se abrirá un puerto de escucha de peticiones donde sólo pueden llegar, inicialmente, peticiones de conexión. El puerto de escucha por defecto será el ya que se ha realizado una pequeña investigación y no se ha encontrado su uso en otras aplicaciones. Aún así, se permitirá el cambio de dicho puerto mediante la edición de su archivo de configuración. Una vez establecida la conexión, la sonda permanecerá a la espera de nuevas órdenes por parte del administrador para, una vez recibidas, ejecutarlas en función de lo indicado por éste. Gestión de los recursos Las capturas de tráfico, pueden generar archivos realmente pesados. Por este motivo, si no se lleva una gestión de los mismos, es muy probable que éstos terminen llenando el disco duro disponible. El módulo sonda, por tanto, debe gestionar los archivos utilizados para no hacer un uso abusivo de la capacidad de almacenamiento del equipo donde se ejecutan. Esta gestión consistirá en que los ficheros que almacenan capturas realizadas y ya han sido enviadas al administrador, serán borradas del sistema liberando así un recurso que puede utilizarse para próximas capturas Diseño del módulo Administrador El fin de este módulo es que el usuario que lo maneje tenga acceso a todas las sondas distribuidas en la red desde un único puesto de trabajo, pudiendo programar en ellas nuevas tareas de captura simultáneas y realizando la recolecta de las mismas para, finalmente, mostrarlas fusionadas en una sola. Para realizar estas funciones, se va a proceder al diseño del mismo (su diagrama de clases se puede ver en la Figura 3.4). Comunicación con la sonda El módulo administrador debe ser capaz de realizar conexiones con las sondas que se le indiquen. Para ello intentará conectarse a la dirección IP y puerto destino y, tras una primera presentación o handshake, se calculará la diferencia de relojes y la latencia existente en la red mediante su Round-Trip-Time. Tras esto, se mantendrá la conexión activa aunque, para evitar sobrecarga de mensajes en la red, no se hará mediante el envío de mensajes periódicos a nivel de la aplicación sino que se confiará en los mecanismos utilizados a un nivel más bajo. Esta conexión será utilizada para enviar todas las peticiones necesarias y recibir sus respuestas. En cambio, en el proceso de recolecta de las trazas, el administrador abrirá el puerto para la recepción del fichero que contiene la información de la captura.

42 CAPÍTULO 3. DISEÑO 42 Figura 3.4: Diagrama de clases del módulo Administrador. Gestión de la diferencia de relojes Para que las capturas de la red se realicen de manera sincronizada, tal y como se explicó en la subsección 3.2.1, es necesario que se realice un control sobre las diferencias de relojes existentes entre los equipos mediante el cálculo de la misma y su posterior aplicación en la correción de las horas de inicio y fin de cada sonda. Para calcular la diferencia de relojes, una primera aproximación consiste en el envío, por parte del administrador, de un mensaje con una marca de tiempo (en adelante MTA1), que debe ser respondida desde la sonda con su marca de tiempo (MTS). Tras recibir la respuesta, el administrador realiza la diferencia entre ambas marcas de tiempo cuyo resultado comprende la diferencia de los relojes más el retardo sufrido por los paquetes al atravesar la red. (MT S MTA1) = (Di f.relo jes + Retardo) El siguiente paso debe consistir en calcular el retardo que introduce la red para restárselo al valor ya calculado y así obtener la diferencia final entre los relojes. La obtención del retardo puede obtenerse a partir de tres maneras: Uso del ping nativo: Los sistemas operativos incluyen un comando ping que permite conocer si un destino en la red es accesible y el retardo que se ha introducido en los paquetes transmitidos hacia ese destino. Es el más preciso pero presenta dos inconvenientes: El primero es que, puesto que se está desarrollando un software multiplataforma y este comando es nativo, será necesario hacer una versión del cálculo para cada sistema operativo distinto. El segundo inconveniente consiste en que puede ser que el puerto propio utilizado por el comando esté bloqueado en el equipo de destino.

43 CAPÍTULO 3. DISEÑO 43 Uso de la función en Java isreachable(): Esta función actúa de modo muy similar al comando anterior puesto que indica si el otro extremo está accesible con las diferencias de que se puede ejecutar en cualquier sistema operativo sin tener que especificar nada y que no indica el retardo de la red, por lo que para conocerlo se puede medir el tiempo que tarda en ejecutarse dicha función. Tras varias pruebas realizadas, se descarta esta función puesto que también realiza una conexión nueva al puerto 7 del otro equipo y, aparte de poder encontrar ese puerto bloqueado y no dar un resultado válido, también falsea la medida puesto que se incluye el tiempo destinado al establecimiento de la nueva conexión. Uso de una nueva marca de tiempo: Si se modifica el intercambio de mensajes anterior y se añade la obtención de una nueva marca de tiempo, se pueden calcular los dos sumandos de la parte derecha de la ecuación anterior. La modificación a los mensajes anteriores consiste en añadir en el mensaje de respuesta de la sonda al administrador el MTA1 que acaba de recibir. De este modo el intercambio de mensajes seguiría la siguiente secuencia: El administrador envia un mensaje con su marca de tiempo, MTA1, la sonda responde a ese mensaje reenviando de vuelta el MTA1 y añadiéndole su marca de tiempo, MTS. Al recibir la respuesta, el administrador obtiene otra marca de tiempo, MTA2, de modo que, mediante la diferencia de las marcas de tiempo del administrador se obtiene el tiempo que tarda la información en viajar desde el administrador a la sonda y volver, conocido como Round-Trip-Time o RTT. Si se supone que la red es simétrica, se puede afirmar que el retardo sufrido por el paquete en un trayecto es igual a la mitad del RTT. (MT S MTA1) ( ) MTA2 MTA1 2 = Di f.relo jes + Retardo RT T 2 Di f.relo jes Finalmente, para obtener una medida fiable, se debe realizar este cálculo en un gran número de repeticiones y obtener la media aritmética de la misma. El número de repeticiones variará en función de la precisión que se requiera o se pueda ofrecer. El último aspecto a comentar es que, para que los mensajes sufran de un menor retardo para poder realizar estos cálculos, hay que desactivar el algoritmo de Nagle (aunque con ello se genere más tráfico en la red). Interfaz gráfica La interfaz gráfica del módulo administrador debe permitir al usuario realizar todas las operaciones disponibles de un modo directo y sin tener que buscarlas entre muchas ventanas. Dispondrá solamente de tres: la ventana principal en la que se integrará el gestor de sondas, una opción para crear una nueva tarea y otra que permita mostrar una segunda ventana encargada de gestionar las tareas programadas, pudiendo ver su estado, borrarlas o abrirlas una vez se ha terminado de recolectar y fusionar las capturas, lo que llevaría a una última ventana donde se mostraría el visor de la tarea completa.

44 CAPÍTULO 3. DISEÑO 44 Gestor de sondas El gestor de sondas se encontrará situado en la ventana principal de este módulo y permitirá añadir o borrar sondas de la lista. Una lista que será guardada en los archivos de configuración de la aplicación de modo que, al ejecutar de nuevo el software, se volverán a recuperar. Por otra parte, también permite iniciar la conexión o desconexión de la(s) sonda(s) seleccionada(s) y mostrar su información sobre la diferencia de relojes y el RTT. Gestor de tareas Este gestor formará parte de una ventana que podrá ser abierta desde la principal mediante un botón llamado Tareas. En esta nueva ventana se presentará el estado de las tareas programadas con sus fechas de inicio y fin y la etiqueta de identificación asignada al crearlas. Se incluirá un botón que permitirá abrir la captura de tráfico asignada a la tarea una vez haya finalizado. Además, se dispondrá de otra opción para borrar la tarea. Ésta tendrá doble función: en caso de no haber comenzado la captura, cancelará su programación y, en el caso opuesto en el que ya se haya completado, borrar el archivo final. No se podrá cancelar una tarea que esté ejecutándose en ese momento. Por otro lado, la opción crear una nueva tarea estará situada en la ventana principal, puesto que, para utilizarla, habrá que seleccionar las sondas involucradas y pulsar el botón correspondiente a esta opción. A continuación se pedirán las horas de inicio y fin y se creará la tarea en las sondas seleccionadas. Cuando se crea una nueva tarea, el administrador le asociará una etiqueta identificativa única que permitirá nombrarla sin la necesidad de ningún dato extra. Esta etiqueta estará formada por el nombre en la red del equipo del administrador y una marca de tiempo en milisegundos. Visor de tarea completa Es la última ventana de la que dispondrá este software. En ella habrá un panel donde mostrar toda la captura en un formato legible para el usuario, una lista desplegable donde poder elegir el filtro a aplicar y un botón que permitirá abrir esa captura de tráfico con el software Wireshark. Gestión de recursos Al igual que ocurre en las sondas, el administrador también debe llevar un control de los archivos de capturas utilizados para no llenar rápido e inútilmente el disco duro del equipo donde se está ejecutando. Esto afecta, especialmente, al proceso de recolección de las capturas de las sondas, puesto que será necesario almacenar esos ficheros recibidos antes de fusionarlos en uno. Por ello, se seguirá el siguiente orden: 1. Creación de un directorio en la carpeta Capturas con el nombre de la etiqueta identificativa de la tarea. 2. Se almacenarán los ficheros recibidos en el directorio recién creado.

45 CAPÍTULO 3. DISEÑO Se realizará la fusión de los ficheros generando otro directamente en la carpeta Capturas, con el nombre de la etiqueta identificativa de la tarea. 4. Se borrará el directorio creado en el paso 1, eliminando también los ficheros que haya dentro Diseño del protocolo a nivel de aplicación Para la comunicación entre los dos módulos diseñados anteriormente en este capítulo, es necesario marcar unas pautas y definir unos mensajes para cada orden que pueda realizar el administrador a las sondas. El intercambio de mensajes también se puede ver en la Figura : Mensajes de conexión Cuando el administrador pretenda conectarse a una sonda, enviará un mensaje tipo HELLO. Este mensaje requerirá de un parámetro que se ha comentado anteriormente en el apartado de Gestión de la diferencia de relojes, la marca de tiempo MTA1. Este mensaje debe ser contestado por la sonda con otro mensaje tipo HELLO, que será distinto al enviado por el administrador para no crear confusiones. Los parámetros que se añadirán serán el MTA1 recibido y la marca de tiempo de la sonda, MTS. Mensaje de desconexión Este mensaje es unidireccional, es decir, solamente lo enviará el administrador a la sonda. Es un mensaje tipo BYE. De este modo, cuando el administrador envía el mensaje, se considera a sí mismo desconectado. No existe el problema de que la sonda no lo reciba debido a que, al ser un protocolo a alto nivel, las capas inferiores pertenecientes a TCP/IP realizarán los reenvíos necesarios. Aún así, si por algún casual no llega el mensaje a su sonda destinataria, no supone ningún problema puesto que ésta no realizará ninguna función sin que el administrador se lo indique. Al no haber administrador al otro lado de la comunicación, no realizará nada y la comunicación terminará muriendo por su timeout. Mensajes para crear una nueva tarea El administrador comenzará la conversación con un mensaje tipo TAREA cuyos parámetros serán tres: la etiqueta identificativa asignada, su hora de inicio y su hora de finalización. La sonda deberá responder confirmando la creación de la tarea mediante otro mensaje tipo TAREA, pero distinto al del administrador. Mensajes para recopilar una tarea Cuando una tarea haya cumplido su hora de finalización, el administrador esperará un corto periodo de tiempo para dar lugar a que las sondas terminen con los procesos de cerrar el fichero 2 La pendiente en la transmisión de los mensajes no tiene relación con el tiempo de transferencia.

46 CAPÍTULO 3. DISEÑO 46 (a) Conexión. (b) Desconexión. (c) Nueva tarea. (d) Recopilar tarea. (e) Cancelar tarea. Figura 3.5: Protocolo a nivel de aplicación

47 CAPÍTULO 3. DISEÑO 47 de captura y demás. Entonces el administrador enviará el mensaje GETTAREA cuyo parámetro es la etiqueta identificativa de la tarea. Si la sonda dispone de la misma, responderá a la petición con un mensaje OKTAREA y procederá al envío del archivo con la captura. En caso de no disponer de la misma, enviará el mensaje NOTAREA. Mensajes para cancelar una tarea programada Si el usuario decide cancelar una tarea programada antes de su comienzo, el administrador enviará un mensaje BORRARTAREA al que se le añadirá como parámetro la etiqueta identificativa de la misma y esperará la respuesta de la sonda, la cual enviará el mensaje OKBORRAR si ha realizado la acción correctamente o NOBORRAR si se ha producido algún problema en el proceso.

48 Capítulo 4 Implementación Este capítulo tiene como finalidad indicar todos los pasos realizados en la implementación de este proyecto fin de carrera. Para ello, en primer lugar se procederá al montaje del laboratorio y su posterior configuración. Más tarde, se instalará todo el software necesario y, por último, se explicará el proceso de programación del sistema de gestión de monitorización distibuida Implementación del laboratorio En esta sección se pretende comentar los pasos a seguidos para la implementación del laboratorio diseñado en el capítulo 3. El orden que se seguirá para ello es el siguiente: Montaje hardware del laboratorio, configuración del mismo e instalación del software requerido Montaje hardware Para la implementación del laboratorio, se llegó a la conclusión en el capítulo de diseño de la necesidad de tres ordenadores equipados con una tarjeta de red con un puerto Gigabit Ethernet. Además, se dispondrá de un enrutador de ADSL comercial con 4 puertos LAN Gigabit Ethernet y una interfaz inalámbrica. Éste servirá de elemento de interconexión para los equipos por lo que estarán conectados a él mediante cables Ethernet. Por otro lado, la conexión inalábrica a la red de acceso a Internet, se realizará mediante de tres adaptadores inalámbricos conectados, cada uno, a uno de los equipos del laboratorio a través de uno de sus puertos USB. Por último, serán necesarios un monitor, un teclado y un ratón, los cuales estarán conectados a los tres equipos mediante un conmutador PS/2 KVM. La opción comercial escogida para éste es el modelo DKVM-4K de D-Link. Éste dispositivo permite controlar hasta cuatro equipos mediante el uso de un conjunto monitor+teclado+ratón. Dispone de un botón para conmutar secuencialmente entre cada uno de ellos aunque también permite utilizar atajos de teclado para su control de modo que, si se pulsa dos veces seguidas la tecla Ctrl y, a continuación, algún modificador, se llevará a cabo la acción. Los principales modificadores son los siguientes: 48

49 CAPÍTULO 4. IMPLEMENTACIÓN 49 Figura 4.1: Esquema del cableado del laboratorio. Teclas de desplazamiento izquierda o derecha: Se conmuta al equipo anterior o al siguiente, respectivamente. Teclas con los números del 1 al 4: Conmuta el control al equipo cuya posición es la indicada por el número. La Figura 4.1 presenta el esquema del cableado del laboratorio. Como indica la leyenda las conexiones azules son un conjuto de cables PS/2 para el ratón y el teclado y VGA para el monitor, mientras que las conexiones en negro son enlaces Ethernet. En la figura se ha obviado el cableado necesario para la alimentación de los tres equipos, la pantalla y el enrutador. Todo el material mencionado ha sido proporcionado por el departamento de Teoría de la Señal, Telemática y Comunicaciones de la Universidad de Granada Configuración de los equipos Instalación del sistema operativo nativo El primer paso tras realizar todo el conexionado de la red consiste en la instalación del sistema operativo que se ejecutará de manera nativa en los equipos. En el capítulo 3 se decidió que éste fuese Ubuntu. Para ello, desde otro equipo funcional, se accederá a la web de la distribución1 y se descargará la última versión en formato.iso. Una vez finalizada la descarga, se grabará en un CD que se insertará en los equipos para realizar la instalación. El proceso consiste en un asistente en el que hay que responder cuestiones del tipo idioma, zona horaria, espacio de disco utilizado para la instalación (elegido el por defecto ofrecido bajo la opción utilizar todo el disco ), nombre del equipo, nombre de usuario y contraseña. En todos los equipos se respon1

50 CAPÍTULO 4. IMPLEMENTACIÓN 50 derán las cuestiones con los mismos datos, excepto en el campo para establecer el nombre del equipo. Conexión a Internet Una vez instalado el sistema operativo, el siguiente paso consistirá en dotar a los equipos de conexión a Internet puesto que el método más cómodo de instalación de software es mediante el comando apt, el cual, durante su ejecución, realiza el proceso de descarga del instalador de la aplicación requerida y lo ejecuta. Por ello se introducirá en un puerto USB uno de los adaptadores inalámbricos, se hará clic con el ratón en el icono del Network Manager situado en la barra superior y se seleccionará la red cviugr-v2. A continuación se rellenarán los campos tal y como se indica en el tutorial disponible en la web del Centro de Servicios de Informática y Redes de Comunicaciones, CSIRC 2 : En seguridad inalámbrica, se seleccionará WPA & WPA2 Enterprise. En la lista desplegable de autenticación, se elegirá Tunneled TLS. Como identidad anónima se escribirá anonymous@ugr.es, o anonymous@correo.ugr.es si el correo que se proporcionará en los campos de las credenciales es el de un alumno. Para el certificado CA, se descargará de la misma web. En el apartado autenticación interna, se escogerá PAP y, por último, en los apartados usuario y clave se utilizarán las credenciales del correo de la Universidad de Granada. Actualizar el sistema operativo nativo Para asegurar el mejor funcionamiento posible en cuanto a posibles bugs, mayor rendimiento y seguridad, es recomendable realizar una actualización completa del sistema de modo que todo se encuentre en la última versión. Para ello se utilizará el siguiente comando, ejecutándolo en una terminal: sudo apt-get update && sudo apt-get upgrade A continuación se introducirá la contraseña del usuario configurada en el proceso de instalación y se esperará a que el proceso termine. Configuración de las interfaces de la red controlada Una vez el sistema operativo está configurado y actualizado, es necesario continuar con la configuración de las interfaces de la red controlada. Como se comentó en el capítulo anterior, hay que establecer las direcciones IP de los equipos manualmente. En primer lugar, se configurará el enrutador mediante el acceso a su interfaz gráfica en forma de página web destinada a este fin. Para ello se consultará la dirección IP de la puerta de acceso (gateway) para esa interfaz mediante el comando: route print 2

51 CAPÍTULO 4. IMPLEMENTACIÓN 51 A continuación se accederá, mediante un navegador web, a la misma dirección. Este procedimiento mostrará la página web de configuración del enrutador, en la cual se desactivará el puerto de WLAN (conexión inalámbrica) y se establecerán la dirección IP y su máscara de red Por último, se deberá indicar que no se desea hacer uso del servidor DHCP incorporado. Éste servidor se encarga de asignar automáticamente direcciones IP a los equipos que se conecten. El siguiente paso consiste en la configuración de las interfaces de red de los equipos. El modo manual de definir la dirección IP de una interfaz es mediante el comando: ifconfig interfaz down ifconfig interfaz direcciónip netmask máscaradered up Donde interfaz es la interfaz de la red a la que se le quiere asignar la dirección IP direcciónip con la máscara de red máscaradered. Estas ordenes requieren ser ejecutadas con permisos de administración, por lo que se les añadirá el comando sudo al inicio. De este modo para establecer en el equipo 1, filemón, la dirección IP /24 ( /24 es otra forma de representar que su máscara de red es ), se ejecutarán las siguientes instrucciones: sudo ifconfig eth0 down sudo ifconfig eth netmask up Este procedimiento habría que repetirlo en cada equipo asignando su dirección en la red. El inconveniente de realizar la configuración de este modo consiste en que cada vez que se reinicie la conexión o el equipo, habrá que ejecutar esos comandos otra vez. Para evitarlo, se introducirá esta configuración en uno de los archivos del sistema. El más indicado para este fin es el que se encuentra en la siguiente ruta 3 : /etc/network/interfaces En este archivo se definen las características propias de cada interfaz y el modo en el que se activan o desactivan, actuando de una manera especial según se indique. De este modo, para la configuración de la interfaz de la que se está hablando, habrá que insertar las siguientes líneas en el mencionado archivo de configuración (habrá que editarlo con privilegios de administrador): auto eth0 iface eth0 inet static address network netmask En esta distribución. Es posible que en otras, cambie su localización.

52 CAPÍTULO 4. IMPLEMENTACIÓN 52 Con esto ya estaría configurada la interfaz y protegida frente a reinicios, tanto del equipo como de la conexión. En el capítulo 3 también se habló de la necesidad de que las máquinas virtuales -que se configurarán más tarde- aparezcan en la red como si se tratase de equipos independientes y reales. Por ello es necesario configurar las interfaces para que éstos reciban sus paquetes y puedan actuar como si estuvieran directamente conectados a la red. Antes, es necesario recordar la diferencia entre un conmutador o enrutador y un puente (bridge), mencionado en el capítulo 1. Un bridge, es un elemento de interconexión que permite extender la longitud de una red pero que, a diferencia de un conmutador o enrutador, no realiza ninguna función de encaminamiento. Ésto es lo que se necesita para dotar a las máquinas virtuales de conexión a la red, pero, como son equipos creados dentro de los ordenadores físicos, el puente también debe ser emulado por éstos. Para ello, se necesitan seguir los siguientes pasos: En primer lugar, será necesario la creación de una interfaz virtual a la que se conectará la máquina virtual. Para ello, es necesario disponer del comando tunctl, perteneciente al paquete uml-utilities. Se instalará mediante el comando: sudo apt-get install uml-utilities Ahora, para crear una interfaz virtual y que ésta sea accesible por el usuario, se ha de utilizar el comando: sudo tunctl -u usuario Con ello se creará una interfaz llamada tap0 que se podrá configurar como cualquier interfaz real. El siguiente paso será la creación del puente y la asignación de las interfaces que lo compondrán. Pero antes, hay que instalar el conjunto de utilidades para la creación de los puentes, incluidas en el paquete bridge-utils: sudo apt-get install bridge-utils A continuación, se deben configurar las interfaces que formarán parte del puente de modo que acepten todos los paquetes que reciban. Sean para ellas o no. Ésto se puede realizar de dos maneras: Fijando la dirección IP de la interfaz a de modo que actúe como si todo lo que circula por la red, fuese para ella. Indicándole a la interfaz que actúe en modo promiscuo mediante la adición de la opción promisc al comando ifconfig. La interfaz tap0 será configurada mediante el primer método mientras que para la interfaz eth0, como requiere una dirección IP para identificar al equipo físico en la red, se utilizará la segunda opción. La dirección IP de la máquina virtual se asignará más tarde de forma estática a través de la configuración del sistema operativo huésped. Así pues, se ejecutarán los comandos:

53 CAPÍTULO 4. IMPLEMENTACIÓN 53 sudo ifconfig tap up sudo ifconfig eth netmask promisc up Ahora sí se puede crear el puente br0 y añadirle ambas interfaces mediante las instrucciones: sudo brctl addbr br0 sudo brctl addif br0 tap0 sudo brctl addif br0 eth0 sudo ifconfig br0 up Con ésto ya estaría establecido el puente y se podría utilizar. El inconveniente presentado por esta configuración es el mismo que el comentado anteriormente en el establecimiento de la dirección IP de la interfaz eth0. Por tanto, se solucionará del mismo modo: el archivo interfaces contendrá, entonces, las siguientes líneas: auto lo iface lo inet loopback auto eth0 iface eth0 inet static address network netmask pre-up ifconfig eth0 promisc up auto tap0 iface tap0 inet manual up ifconfig $IFACE up down ifconfig $IFACE down tunctl_user usuario auto br0 iface br0 inet static address network netmask bridge_ports eth0 tap0 Con esto, el usuario no tendrá que repetir los comandos explicados anteriormente para establecer las direcciones IP, cada vez que inicie el ordenador. Por último, para facilitar la identificación de los equipos y que el usuario no necesite memorizar todas las direcciones IP de los equipos, tanto físicos como virtuales, se asignarán nombres que los equipos sepan traducir en esas direcciones. Ésto se realiza mediante la configuración, con privilegios de administrador, del archivo hosts, disponible en las siguientes localizaciones:

54 CAPÍTULO 4. IMPLEMENTACIÓN 54 Ubuntu: /etc/hosts Windows: C:\Windows\system32\drivers\etc\hosts Al mencionado archivo se deben añadir las siguientes líneas para conseguir esta manera de actuar: filemon filemonxp mortadelo mortadelodisfrazao mortadeloxp super superxp En esta lista, se puede observar que todos los equipos que estarán en la red serán los que ejecutan su sistema operativo nativo y una versión virtual de éstos con Windows XP. Además, en un equipo, existirá una segunda máquina virtual, mortadelodisfrazao, cuyo fin será ofrecer un servidor edonkey alternativo mediante el que se podrá estudiar si hay comunicación entre servidores o no. En ese caso también será necesario una interfaz de red virtual, tap1, para él que se creará del mismo modo que las interfaces tap0. Creación de la máquina virtual El software utilizado para la creación y gestión de las máquinas virtuales será VirtualBox puesto que se presenta como una solución gratuita y muy potente para este fin. Además, existe una gran comunidad que aporta mejoras constantes y que ha conseguido que el buen rendimiento en Ubuntu la sitúe como la primera opción a utilizar para la virtualización de máquinas. Su instalación será tan sencilla como ejecutar el comando sudo apt-get install virtualbox-ose-qt Una vez instalada la aplicación, se procederá a la creación de la máquina virtual con Windows XP. Para ello, se debe ejecutar la aplicación y seleccionar en la ventana principal, la opción Nueva. Ésto dirigirá a un asistente en el que se elegirá el nombre identificativo de la máquina virtual, el sistema operativo que se pretende instalar, la memoria RAM de la dispondrá y el tamaño del disco duro virtual que se utilizará para la misma. Al finalizar el asistente, ya estará creada la máquina virtual, a la cual habrá que instalar un sistema operativo. Para ello, se debe acceder a la configuración de la misma, apartado Almacenamiento, y vincular el lector de CD al físico del equipo anfitrión, donde se debe introducir un disco de instalación de Windows XP. Se acepta la nueva configuración e inicia la máquina virtual. Una vez iniciada, se mostrará el asistente de instalación de Windows XP, cuyas cuestiones habrá que responder para completarla. En cuanto al acceso de la máquina virtual a la red, se deberá configurar, en primer lugar, en la ventana de configuración de la misma, habiéndola detenido previamente. Entonces, en el apartado Adaptadores de red, habrá que seleccionar el acceso directo a la interfaz tap0 (tap1 en el caso de mortadelodisfrazao). Una vez aceptada la configuración, se iniciará de nuevo la

55 CAPÍTULO 4. IMPLEMENTACIÓN 55 máquina virtual. Cuando el sistema operativo haya terminado de arrancarse, habrá que dirigirse a Inicio, Conexiones de red. Desde ahí se accederá a la interfaz de red, donde se establecerán manualmente los parámetros de la red en su configuración de TCP/IP. En el mismo lugar, se desactivará la configuración de descubrimiento del resto de los equipos, de modo que, así, se reducirá el tráfico no deseado generado en la red. Por otra parte, al igual que es recomendable mantener el sistema operativo anfitrión actualizado, también lo es en el huésped. Por ello, es necesario dotarlo de acceso a Internet para que pueda descargar sus últimas actualizaciones. La manera de hacerlo será mediante la creación de una nueva interfaz en la máquina virtual con una conexión tipo NAT. Además habrá que realizar una configuración extra en el equipo anfitrión, el cual actuará de enrutador reenviando el tráfico generado por la máquina virtual y realizando las funciones propias de un NAT. Para habilitar esta función, habrá que seguir los siguientes pasos: En primer lugar, hay que habilitar el reenvío de tráfico mediante el comando: sudo sysctl net.ipv4.ip_forward=1 Tras este paso, el equipo anfitrión será capaz de reenviar el tráfico de tipo IPv4 que reciba. El problema es que el tráfico de respuesta, no será reencaminado a su destino final puesto que todavía no se traducen las direcciones mediante NAT. Para activarlo, es necesario el uso del comando iptables: sudo iptables -t nat -A POSTROUTING -j SNAT --to-source direcciónip Con direcciónip, la dirección de la interfaz que da acceso a Internet, es decir, la inalámbrica. Con esta configuración, el equipo huésped será capaz de acceder a Internet y poder actualizarse. Estos dos comandos habrá que ejecutarlos tras cada reinicio, cada vez que se desee que el sistema operativo de la máquina virtual acceda a Internet. No se va a configurar de modo permanente puesto que la mayor parte de los estudios se pretende que se realicen en un entorno controlado. Una vez esté lista la configuración de la máquina virtual en un equipo, se utilizará la opción duplicar para guardar una copia de seguridad en caso de cualquier incidente y para copiarla a otros equipos de modo que se ahorre trabajo. Ésto, actualmente, no puede ser realizado mediante interfaz gráfica, sino que se tendrá que hacer mediante el siguiente comando: VBoxManage clonehd archivoorigen.vdi archivodestino.vdi Donde archivoorigen.vdi es el archivo que simula ser el disco duro del sistema y archivodestino.vdi una copia del anterior disponible para mover y exportar. En el caso de querer copiar el disco duro, es necesario utilizar este método puesto que, si simplemente se copia el archivoorigen.vdi, no funcionará en una nueva máquina virtual. Cabe también mencionar que esta acción sólo duplica el disco duro virtual, por lo que mientras que sí se aprovechará la configuración software del sistema operativo, instalaciones incluidas, no ocurrirá lo mismo con la de la máquina virtual, debiendo repetirla en cada equipo.

56 CAPÍTULO 4. IMPLEMENTACIÓN 56 Acceso remoto El último paso en la configuración de los equipos tendrá como fin habilitar los tres modos de acceso remoto comentados en el capítulo 3: SSH, X-Window y VNC. El primer modo está activado por defecto. De este modo, cualquier usuario que conozca la dirección IP del equipo, el nombre del usuario y su contraseña podrá acceder mediante este método con sólo ejecutar en el equipo desde el que accede: ssh usuario@direcciónip El siguiente método, X-Window, está basado en el anterior y, para activarlo, sólo es necesario modificar una línea dentro del archivo de configuración del mismo, localizado en /etc/ssh/sshd_config. La línea a modificar es: X11Forwarding yes Con esta opción habilitada, el usuario remoto que desee acceder lo realizará mediante el siguiente comando: ssh -X usuario@direcciónip Hay que tener en cuenta que, tanto en este caso como el anterior, la dirección IP que hay que indicar es la del equipo al que se pretende acceder, al igual que el usuario indicado debe existir en tal equipo. Por último, para habilitar el acceso remoto mediante VNC en Ubuntu, hay que realizar los siguientes pasos: 1. Desde el escritorio, ir al apartado Administración, Preferencias y seleccionar Escritorio remoto para abrir la ventana de configuración de esta opción. 2. A continuación, se marcará la única casilla disponible Permitir a otros usuarios ver mi escritorio. 3. Activar la casilla Requerir que un usuario introduzca una contraseña y fijarla en el cuadro indicado. 4. Desactivar la opción anterior Debe confirmar cada acceso a este equipo. Si se mantiene así, cada vez que el usuario intentase acceder, necesitaría de otro que aceptase su conexión. 5. Por último, cerrar la ventana de configuración. Una vez habilitado este tipo de acceso, el usuario podrá acceder a él mediante algún programa compatible con él. En sistemas operativos basados en Linux, la aplicación por defecto para este tipo de conexiones es Vinagre, en MacOS X también se soporta esa funcionalidad desde el mismo Finder (el explorador de archivos) en el menú Ir, opción Conectarse al servidor... e introduciendo en el cuadro de diálogo abierto vnc://direcciónip. En Windows, en cambio, se requiere de un software adicional para esta funcionalidad. Se recomienda la aplicación gratuita VNCViewer.

57 CAPÍTULO 4. IMPLEMENTACIÓN 57 DNS dinámico Tras configurar el acceso remoto, es necesario que el usuario conozca en todo momento la dirección IP pública de acceso a Internet. Puesto que la red utilizada asigna esa dirección de modo dinámico se debe requerir del uso de un DNS dinámico. Como se diseñó en el capítulo 3, la solución utilizada será la ofrecida por No-IP. Para ello, se requiere que el cliente que envía la dirección IP a los servidores del servicio para actualizar el registro se esté ejecutando continuamente en el equipo. Por tanto, se instalará la aplicación mediante el comando: sudo apt-get install noip2 A continuación, habrá que indicar que este demonio comience a ejecutarse al inicio del sistema. Para ello se accederá a la opción Sistemas al inicio, dentro del submenú Preferencias en la pestaña Sistema del panel superior del escritorio. Una vez abierta la ventana de configuración, se elegirá la acción Añadir para, luego, rellenar los campos Nombre, Órden y Comentario como sigue: Nombre: No-IP Órden: noip2 Comentario: Actualizar DNS. Por último, para que la instrucción se pueda ejecutar con sin necesidad de petición de contraseña, se modificarán los permisos de su archivo de configuración mediante el comando: chmod 777 /var/lib/noip2/noip2.conf Ésto, aunque permite que otros usuarios puedan acceder al archivo, no implica un problema al robo de claves puesto que el archivo está cifrado Instalación del software de generación de tráfico P2P y monitorización Tras haber realizado toda la configuración de los equipos y sus máquinas virtuales, sólo falta instalar el software que será el encargado de generar el tráfico P2P y monitorizarlo. En concreto serán necesarias 4 aplicaciones para este fin, tanto en sus versiones para Windows como para Linux: el software que deben ejecutar los pares P2P, el del servidor de la red edonkey, Wireshark y el sistema de gestión de monitorización distribuida (con sus dos módulos: Sonda y Administrador). Clientes P2P En primer lugar, para los pares P2P, el software que se decidió en el capítulo 3 que se iba a utilizar sería emule para los equipos con sistema operativo Windows y amule para entornos basados en Linux. Para ello, en las máquinas virtuales se instalará la aplicación, en su última versión, descargada de la web del proyecto emule 4. El proceso de instalación consistirá en la 4

58 CAPÍTULO 4. IMPLEMENTACIÓN 58 ejecución del archivo descargado y completar el asistente que presenta. Por otra parte, en los sistemas anfitrión, se realizará la instalación mediante la ejecución del comando: sudo apt-get install amule Servidores edonkey En cuanto a los servidores de la red edonkey, su instalación consiste en la creación de una carpeta donde se deben incluir dos archivos: el ejecutable (distinto en función del tipo de sistema operativo) y el archivo de configuración donkey.ini. En este último archivo, los parámetros a configurar son: Flag name desc console maxclients threads public verbose Descripción Nombre del servidor que será mostrado en la lista de servidores de los clientes. Descripción que será mostrada en la lista de servidores de los clientes. Si el valor es true, se podrán ejecutar comandos en la interfaz de línea de comandos y las salidas serán reflejadas en el mismo lugar. Número máximo de clientes admitidos en el servidor. Número de hebras creadas para manejar las peticiones de los clientes. Se recomienda tener 5 cada 100 clientes. Si el valor es true, el servidor se comunicará con otros servidores que conozca a su alrededor. Estos servidores propagarán su consulta a los clientes conectados a ellos. Si el valor es true, se mostrará más información en el archivo de registro (log). Por defecto true Utilizado Servidor de prueba Servidor que se intentará configurar para que funcione bien. true false false false true

59 CAPÍTULO 4. IMPLEMENTACIÓN 59 Flag welcome[#] tablesize thisip logfile port seedip seedport type maxversion minversion Descripción Mensajes de bienvenida que enviará el servidor al cliente cuando éste se haya conectado. El símbolo # puede ser cualquier número, sabiendo que cada uno, comenzando por el cero, es una línea. Normalmente, aparecerán en el registro del mismo. Tamaño de la tabla para guardar la información de los archivos que se comparten por parte de los pares. Su valor debe ser un número primo. Es la dirección IP de este servidor. Solo es necesario si el mecanimos de determinación de la dirección IP falla. Si el valor es true, la salida del servidor será almacenada en un archivo de registro llamado log. Puerto po el cual el servidor recibe las conexiones. Dirección IP del servidor semilla. Es la dirección de un servidor al que se puede conectar para obtener la lista de otros servidores y unirse a la red edonkey. Esta opción ralentiza la velocidad del servidor. El puerto del servidor semilla explicado en la descripción del parámetro anterior. Posibles valores: key (para buscar archivos por palabras clave) o substring (búsqueda por subcadenas). La máxima versión con la que el servidor permite conectarse. La mínima versión compatible con este servidor. Por defecto Utilizado Un texto cualquiera de bienvenida false La dirección IP del servidor. No utilizado 4661 No utilizado No utilizado 4661 No utilizado key No utilizado 1000 No utilizado Una vez realizada la configuración, para ejecutar el servidor bastará con invocarlo desde un intérprete de línea de comandos.

60 CAPÍTULO 4. IMPLEMENTACIÓN 60 Wireshark El siguiente software a instalar es el paquete Wireshark. Su instalación en Windows es prácticamente igual que la de emule. Se deberá acceder a la página web oficial del producto 5 y descargar el instalador del programa para este sistema operativo. Después se ejecutará el archivo descargado y se procederá a seguir los pasos indicados en el asistente. Tras finalizar el asistente ya estará instalada la aplicación. Aún así, en Windows, se requieren unos pasos extra para poder ejecutar sus comandos desde la consola sin tener que indicar continuamente el directorio donde está instalado. Ésto es, se va a modificar la variable de estado PATH. Para ello hay que dirigirse al icono de Mi PC y hacer clic en él con el botón derecho del ratón. En el menú contextual, se elegirá la opción Propiedades. A continuación, en la ventana abierta, hay que escoger la pestaña Opciones avanzadas donde se pulsará el botón Variables de entorno. En la nueva sub-ventana que se abrirá, en la lista inferior, se modicará la variable Path, añadiendo al final del valor que ya posee un punto y coma seguido de la ruta absoluta del directorio donde Wireshark se encuentra instalado. En Ubuntu, la instalación consistirá en la ejecución del comando que instala los paquetes wireshark (donde también se incluye el comando mergecap) y tshark: sudo apt-get install wireshark tshark Sistema de gestión de monitorización distribuida Para la ejecución de este software de desarrollo propio, será necesario disponer del paquete Wireshark, ya configurado, y, como mínimo, del entorno de ejecución de Java (JRE). Esta segunda plataforma ya se encuentra instalada por defecto en algunas versiones de Ubuntu. Aún así, para asegurar la disponibilidad que ésta y otras herramientas básicas, se realizará la instalación del paquete ubuntu-restricted-extras mediante la ejecución del comando: sudo apt-get install ubuntu-restricted-extras Aún así, si se prefiere instalar solamente el paquete del entorno de ejecución de Java, bastará con el comando: sudo apt-get install default-jre Por otra parte, para su instalación en los entornos Windows, habrá que acceder a la web oficial de esta tecnología 6 y descargar el instalador para ese tipo de sistemas operativos. Tras ello, se ejecutará el archivo y se completará el proceso de instalación siguiendo las indicaciones del asistente. Una vez se cumplen todos los requisitos para el correcto funcionamiento del software de gestión de monitorización distribuida, se procederá a su instalación. Ésta consistirá, al igual que en el caso del servidor de edonkey, en copiar el directorio que contiene ambos programas al destino deseado por el usuario

61 CAPÍTULO 4. IMPLEMENTACIÓN 61 Tras este proceso, se podrá ejecutar el software Adminstrador mediante la ejecución en un intérprete de línea de comandos de la instrucción: java -jar directoriodeinstalación/mrdv2.jar Para el caso de la ejecución del software Sonda, será necesario iniciarlo con privilegios de administrador: sudo java -jar directoriodeinstalación/sonda.jar 4.2. Implementación del sistema de gestión de monitorización distribuida Antes de su instalación, explicada en la sección anterior, se deberá realizar la implementación de este sistema. Para ello, se va a explicar en este apartado el algoritmo y la estructuración de ambos módulos. Su desarrollo se ha realizado utilizando el lenguaje de programación Java debido a que permite su ejecución en varias plataformas distintas sin la necesidad de distinguir en la fase de implementación entre cada una de ellas. También se ha escogido este entorno valorando los conocimientos previos y experiencia del alumno en esta tecnología. El código fuente se podrá encontrar en el medio digital que acompaña a esta documentación. Este apartado se dividirá en dos subsecciones: en la primera se tratará la implementación del módulo Sonda mientras que, en la segunda se comentará la realizada para el módulo Administrador Implementación del módulo Sonda Este módulo hará uso de un archivo de configuración llamado sonda.conf. En él se almacenará el parámetro puerto, el cual indica el puerto de escucha que utilizará el socket que acepta las peticiones de conexión de los administradores que pretenden acceder a ella. Su interfaz gráfica muestra en la Figura 4.2. La implementación del módulo Sonda se ha realizado mediante siete clases que se enumerarán a continuación, indicando la principal funcionalidad de cada una de ellas: SondaApp.java: Es la clase que inicia la aplicación. En ella se incluye el método main junto con otras funciones que permiten acceder a los objetos principales creados en la misma (objetos Sonda y SondaView) de los que se hablará más adelante. SondaView.java: En ella se define la interfaz gráfica e incluye los métodos necesarios para mostrar la información actualizada en ella, a la vez que otras funciones para acceder a las opción marcada por el usuario en la ventana mostrada sobre la interfaz de red que se debe utilizar para capturar el tráfico. SondaAboutBox.java: Clase definida exclusivamente para mostrar el diálogo de información Acerca de...

62 CAPÍTULO 4. IMPLEMENTACIÓN 62 Figura 4.2: Interfaz gráfica del módulo Sonda. Sonda.java: Es el corazón de la aplicación. En ella se centralizan las funciones para atender las peticiones de conexión y gestionar los administradores conectados y las tareas programadas. Administrador.java: En ella se definen las funciones de comunicación con sus homónimos. Durante la ejecución de la aplicación, existirán tantos objetos de esta clase como administradores que estén conectados a la sonda. Tarea.java: Gestiona los parámetros y la ejecución de la tarea a la que representa. Al igual que la clase anterior, se crearán tantos objetos Tarea como tareas haya programadas en la sonda. Mensajes.java: Es una clase muy simple donde se definen de forma estática los mensajes que forman parte del protocolo de aplicación utilizado. Está dividida en dos subclases que identifican quién es el emisor de cada uno de ellos. Una vez definidas las clases utilizadas, se procederá a identificar los principales bloques de ejecución de este módulo. Éstos son la inicialización del programa, la aceptación de peticiones de los administradores y la gestión y ejecución de tareas. A continuación se describirán los procedimientos que se ejecutarán en cada uno de ellos y cómo se han implementado. Inicialización Este bloque es el ejecutado nada más iniciar la aplicación. En él se creará el objeto Sonda, encargado de realizar las gestiones de los administradores y las tareas, y una nueva instancia de SondaView.

63 CAPÍTULO 4. IMPLEMENTACIÓN 63 Durante la creación del objeto Sonda se carga el archivo de configuración sonda.conf, el cual incluye el parámetro puerto. Éste parámetro indica el puerto que debe abrirse a la espera de peticiones de conexión por parte de los administradores. Si se produce un error de lectura del archivo, se creará uno nuevo con los valores predeterminados puerto: Tras ésto, se inicializan la lista de tareas y la de administradores y se comienza a atender las peticiones de conexión mediante un objeto de la clase ServerSocket. Por último, se ejecuta una hebra encargada de comprobar periódicamente el estado de los administradores conectados para borrarlos en caso de desconexión. Por otro lado, durante la creación del objeto SondaView se realiza la configuración de todos los componentes pertenecientes a la ventana mostrada. Para ello, entre otras acciones, se debe obtener la lista de interfaces de red disponibles para la captura de tráfico. Ésto se consigue mediante la ejecución del comando tshark -D y la lectura de su respuesta. Por último, se inician otras dos hebras encargadas de actualizar los datos mostrados en la ventana informativa. El fin de una es llevar el control del número de administradores conectados, mientras que la otra actualiza la lista de tareas asignadas a la sonda. Administradores En el bloque anterior, una de acciones llevadas a cabo era la apertura de un puerto para atender las peticiones de conexión de los administradores. Por ello, cuando se recibe una, es necesario gestionarla. Este es el fin de este bloque. Tras recibir una petición de conexión, se añade en la lista definida para tal fin de la Sonda un nuevo objeto Administrador al que se le indica el Socket asignado en esa conexión. Durante la creación del mismo, se intercambian entre los dos módulos los mensajes definidos para el proceso de conexión y, al final del mismo, se ejecutará una hebra destinada a atender, acometer y responder las peticiones que se realicen a partir de entonces desde el módulo administrador remoto. Entre las peticiones que es capaz de atender se encuentran los mensajes destinados a calcular la latencia y la diferencia de relojes entre los equipos, el de despedida y cierre de conexión y los de creación, cancelación y recolección de tareas. En todos ellos, las acciones realizadas consisten en la ejecución de la acción requerida y su respuesta a través del mismo canal de comunicación existente, excepto en el caso de recolección de la tarea, en el cual, para el envío del archivo de la captura de tráfico, se debe establecer una nueva conexión al puerto del administrador. Esta decisión en la implementación ha sido tomada tras comprobar que, entre el tráfico capturado puede haber mensajes de control pertenecientes al protocolo de este sistema y puede llevar a confusiones. Tareas El último gran bloque que conforma esta aplicación es el encargado de gestionar las tareas. Puesto que, debido al diseño del sistema completo, el módulo Sonda no realiza ninguna decisión

64 CAPÍTULO 4. IMPLEMENTACIÓN 64 sin haber recibido antes una orden desde el administrador, el momento de la creación de las tareas y su envío final dependerá de lo indicado en las peticiones recibidas en el bloque anterior. Así pues, cuando en el bloque de comunicación con el administrador se recibe una petición de una nueva tarea, la Sonda creará un nuevo objeto Tarea, el cual, durante su creación establecerá sus parámetros principales (ID, horas de inicio y fin, administrador que la encargó y sus variables de estado de ejecución). Además creará una cuenta atrás mediante la clase java.util.timer encargada de ejecutar la tarea cuando sea la hora de inicio. El comando que se ejecutará para la realización de la captura es el siguiente: tshark -i interfazdered -t r -n -w IDdeTarea.cap -a duration:seg Donde interfazdered es la seleccionada por el usuario para capturar, IDdeTarea es la etiqueta identificativa única asignada a la tarea y seg el tiempo en segundos hasta el final de la ejecución de la tarea. Los parámetros utilizados tienen el siguiente significado: Parámetro Significado -i interfazdered Intefaz de red utilizada para capturar el tráfico. -t r Las marcas de tiempo utilizadas son relativas al comienzo de la captura. -n Desactiva la resolución de nombres (genera menos tráfico). -w IDdeTarea.cap Guarda la captura en el archivo indicado. -a duration:seg Duración de la captura. Transcurridos seg segundos se detendrá. Por otro lado, para no llenar de archivos obsoletos el disco duro del equipo donde se está ejecutando este módulo, tras enviar el archivo de captura al administrador que la haya encargado, se borra del sistema Implementación del módulo Administrador Este módulo permitirá al usuario acceder al control de las sondas de modo que pueda encargarles tareas de manera remota. La principal ventaja es esta utilidad consiste en que, con ella, el usuario será capaz de programar una tarea de captura de tráfico común para todas las sondas que él elija, mostrándole, al final del proceso, un resultado en el que estén fusionadas todas las capturas realizadas de modo que se pueda obtener un control del tráfico que ha circulado por la red lo más completo posible. La interfaz gráfica que presenta se puede observar en la Figura 4.3 Para la implementación de este módulo, se han utilizado las siguientes clases de Java: Administrador.java: Se trata de la clase encargada del inicio de la aplicación. En ella se crean el objeto de la clase Admin y el de AdministradorView, comentados más adelante. AdministradorView.java: En ésta se define la ventana principal de la interfaz gráfica de la aplicación. En ella estarán reflejadas las opciones e información de gestión de las sondas y la capacidad de ver y crear tareas.

65 CAPÍTULO 4. IMPLEMENTACIÓN 65 (a) Ventana principal. (b) Ventana de gestión de tareas. (c) Visor de tarea o captura realizada. Figura 4.3: Interfaz gráfica del módulo Administrador.