entorno de experimentación para generación y...

ESTUDIOS DE INGENIERÍA DE TELECOMUNICACIÓN

Entorno de experimentación para generación ymonitorizació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

ENTORNO DE EXPERIMENTACIÓN PARA GENERACIÓN Y MONITORIZACIÓN DETRÁFICO P2P

Alejandro Fernández Haro

Palabras clave: P2P, generación de tráfico, monitorización distribuida, captura de tráfico, la-boratorio, entorno de experimentación.

Resumen: El modelo tradicional utilizado en Internet basado en la arquitectura cliente-servidorno es lo suficientemente eficiente para muchas de las aplicaciones que se pueden utilizar hoy endía, debido a la tendencia actual de diseñar servicios que hacen uso de la computación nube ydemás entornos distribuidos. El rendimiento de estos ejemplos se puede ver afectado si todo eltrá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 aprovechantoda la red, por lo que el tráfico no está concentrado en un solo punto de la misma. Ésta es larazón por la que es necesario estudiar esta tecnología y por la que se necesita un entorno degeneració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ónde tráfico P2P, teniendo en cuenta las características especiales que presentan este tipo de redes ylas 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, experi-mentation setting.

Abstract: The traditional model used in the Internet based on client-server architecture is notefficient enough for most applications used nowadays, due to the current tendency to designservices using cloud computing and more distributed enviroments. The performance in theseenviroments would be reduced if all the traffic generated would traverse a node which just fowardit.

P2P networks leverage the performance of many applications, as the packets traverse fromthe whole network, so the traffic is not concentrated on just a point of it. That is the reason whyit is necessary to study this technology and a P2P traffic generation and monitoring setting isneeded.

The goal in this project is to design a P2P traffic generation and monitoring setting, keepingin mind the special characteristics present in by this kind of networks avoiding some of theprevious monitoring system flaws when capturing traffic from distributed networks.

D. Gabriel Maciá Fernández, profesor del departamento de Teoría de la Señal, Telemática yComunicaciones 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.

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

Índice general

1. Introducción 151.1. Redes P2P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.1.1. ¿Qué es P2P? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.1.2. Tipos de redes P2P . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

1.1.2.1. Clasificación según su grado de centralización . . . . . . . . 201.1.2.2. Clasificación según su estructuración . . . . . . . . . . . . . 21

1.1.3. Mecanismos de seguridad . . . . . . . . . . . . . . . . . . . . . . . . 211.2. Sistemas de monitorización de red . . . . . . . . . . . . . . . . . . . . . . . . 21

1.2.1. ¿Qué es un sistema de monitorización de red? . . . . . . . . . . . . . . 211.3. Objetivos de este proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1.3.1. Motivación del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . 241.3.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2. Análisis 252.1. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.1.1. Requerimientos funcionales . . . . . . . . . . . . . . . . . . . . . . . 252.1.2. Requerimientos no funcionales . . . . . . . . . . . . . . . . . . . . . . 27

2.2. Análisis del entorno de experimentación . . . . . . . . . . . . . . . . . . . . . 282.2.1. Análisis del laboratorio . . . . . . . . . . . . . . . . . . . . . . . . . . 282.2.2. Análisis del sistema de gestión de monitorización distribuida . . . . . . 31

3. Diseño 333.1. Diseño del laboratorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.1.1. Hardware y topología del entorno . . . . . . . . . . . . . . . . . . . . 333.1.2. Configuración software . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2. Diseño del sistema de gestión de monitorización distribuida . . . . . . . . . . . 373.2.1. Sincronización de trazas . . . . . . . . . . . . . . . . . . . . . . . . . 393.2.2. Diseño del módulo Sonda . . . . . . . . . . . . . . . . . . . . . . . . 403.2.3. Diseño del módulo Administrador . . . . . . . . . . . . . . . . . . . . 413.2.4. Diseño del protocolo a nivel de aplicación . . . . . . . . . . . . . . . . 45

9

ÍNDICE GENERAL 10

4. Implementación 484.1. Implementación del laboratorio . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.1.1. Montaje hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.1.2. Configuración de los equipos . . . . . . . . . . . . . . . . . . . . . . . 494.1.3. Instalación del software de generación de tráfico P2P y monitorización 57

4.2. Implementación del sistema de gestión de monitorización distribuida . . . . . . 614.2.1. Implementación del módulo Sonda . . . . . . . . . . . . . . . . . . . 614.2.2. Implementación del módulo Administrador . . . . . . . . . . . . . . . 64

5. Pruebas 695.1. Pruebas del laboratorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.1.1. Pruebas de conectividad en la red aislada . . . . . . . . . . . . . . . . 695.1.2. Pruebas de acceso a Internet . . . . . . . . . . . . . . . . . . . . . . . 705.1.3. Pruebas eMule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715.1.4. Pruebas de accesibilidad . . . . . . . . . . . . . . . . . . . . . . . . . 725.1.5. Tabla resumen de las pruebas . . . . . . . . . . . . . . . . . . . . . . 74

5.2. Pruebas del sistema de gestión de monitorización distribuida . . . . . . . . . . 745.2.1. Pruebas de conexión . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.2.2. Pruebas de cálculo de diferencia de relojes . . . . . . . . . . . . . . . 765.2.3. Pruebas de creación de una tarea . . . . . . . . . . . . . . . . . . . . . 765.2.4. Pruebas de cancelación de una tarea . . . . . . . . . . . . . . . . . . . 775.2.5. Pruebas de recopilación, mezcla y apertura de una tarea . . . . . . . . . 785.2.6. Tabla resumen de las pruebas . . . . . . . . . . . . . . . . . . . . . . 79

6. Conclusiones 806.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Índice de figuras

1.1. Arquitectura cliente-servidor. . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.2. Sistema de nodos peer-to-peer sin infraestructura central. . . . . . . . . . . . . 171.3. Escenario de intercambio de datos entre dos usuarios. . . . . . . . . . . . . . . 171.4. Red de acceso a Internet de un usuario medio. . . . . . . . . . . . . . . . . . . 191.5. Ventana principal de Wireshark. . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.1. Modos de acceso a Internet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.1. Topología de la red del laboratorio. . . . . . . . . . . . . . . . . . . . . . . . . 383.2. Interacción entre administradores y sondas en la red. . . . . . . . . . . . . . . 393.3. Diagrama de clases del módulo Sonda. . . . . . . . . . . . . . . . . . . . . . . 403.4. Diagrama de clases del módulo Administrador. . . . . . . . . . . . . . . . . . 423.5. Protocolo a nivel de aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.1. Esquema del cableado del laboratorio. . . . . . . . . . . . . . . . . . . . . . . 494.2. Interfaz gráfica del módulo Sonda. . . . . . . . . . . . . . . . . . . . . . . . . 624.3. Interfaz gráfica del módulo Administrador. . . . . . . . . . . . . . . . . . . . . 65

11

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 oportunidadde 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 hatardado en prestármela, ha gestionado toda la burocracia necesaria para que ésto llegara a buenpuerto y no se ha desesperado con mi excesiva tranquilidad, sabiendo en todo momento cuándoy 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 unamanera 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 con-cedida 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 lainfraestructura y los equipos donados.

Por otro lado, debo agradecer a mis padres y mi hermana, el apoyo y la comprensión pres-tados durante el trascurso de mis estudios y por cómo aún siguen mostrando la misma pacienciaconmigo que cuando tenía que estar en brazos todo el día. Gracias a Marta por animarme en losmomentos bajos y darme tantos momentos buenos que ayudan a afrontar los inconvenientes conmayor ímpetu. Gracias también a Jorge, Ramón, Dioni y Luis Carlos por todos los tirones deorejas 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 des-pertado mis dotes de liderazgo tras tratarme durante los cinco años como el delegado por defectosin necesidad de más elecciones. Entre todos ellos, he de darles las gracias, especialmente, a Pa-blo, Pachus y Berta. Al primero, por las largas conversaciones que hemos tenido (y seguimosteniendo de vez en cuando) y a la irrompible pareja de prácticas, por permitirme ser uno de tresy enseñarme tanto en este tiempo.

13

Capítulo 1

Introducción

El objetivo de este primer capítulo de introducción es proporcionar al lector una visión globaldel estado actual de las tecnologías involucradas durante la realización de este proyecto fin decarrera. Así pues se comentarán brevemente las características de las redes P2P comparándolascon la arquitectura cliente-servidor, utilizada tradicionalmente en Internet.

Posteriormente se tratarán los aspectos más relevantes de los sistemas de monitorización deredes donde se mostrarán varios ejemplos comerciales.

1.1. Redes P2P

En esta sección se realizará una breve introducción a las redes P2P de tal modo que, enprimer lugar, se tratará una descripción de este tipo de redes para, a continuación, destacar lasprincipales diferencias con el modelo cliente-servidor, comentando también, sus ventajas e in-convenientes frente a esta arquitectura. Tras ello, se realizará una clasificación de los tipos dered P2P mencionando ejemplos que se encuadren dentro de cada grupo.

1.1.1. ¿Qué es P2P?

Arquitectura cliente-servidor

La arquitectura de red más extendida en Internet es la conocida como cliente-servidor. Eneste tipo de red se puede encontrar que los extremos de la conexión (los dos equipos que in-tercambian la información) cumplen dos roles bien diferenciados: Por un lado, un equipo (elservidor) pone a disposición del otro (el cliente) un conjunto de recursos en función de los servi-cios 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 con-tenida 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 finalidadpública o privada, y atiende las peticiones de los clientes, respondiendo con la información orecursos solicitados.

15

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 laFigura 1.1.

Definición de red P2P

La computación o trabajo en red P2P (Peer-to-Peer) es una arquitectura de aplicación distri-buida que reparte tareas o cargas de trabajo entre los equipos pertenecientes a la misma, conoci-dos como pares (peers). En español, las redes P2P suelen ser, a menudo, traducidas como redesentre pares o redes entre iguales puesto que los pares disfrutan de los mismos privilegios en elentorno de dicha aplicación, trabajando de forma equitativa al aplicarseles a todos los mismosroles tanto de servidor como de cliente. En escenarios así se dice que los pares forman una redde nodos P2P (ver Figura 1.2).

En este tipo de entornos los pares ponen a disposición de los otros participantes de la reduna porción de sus recursos, tales como potencia de procesamiento, almacenamiento en discoo ancho de banda, sin la necesidad de una coordinación central realizada por servidores o hostestables.1 Los pares actúan tanto como proveedores como consumidores de recursos al contrarioque el tradicional modelo cliente-servidor donde solamente los servidores proveen y los clientesconsumen.

El modelo cliente-servidor es muy útil en diversas aplicaciones como, por ejemplo, servido-res web donde se almacenan los contenidos de un sitio web y espera la solicitud de un clientepara servírselos. Aún así, a medida que han ido surgiendo nuevas aplicaciones y servicios quehacen uso de las redes de datos, se ha podido comprobar que no resulta la solución más eficientepara sostenerlas.

1Rüdiger Schollmeier, A Definition of Peer-to-Peer Networking for the Classification of Peer-to-Peer Architectu-res and Applications, First International Conference on Peer-to-Peer Computing, IEEE (2002).


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 arquitec-tura tradicional de cliente-servidor, se utilizará a modo de ejemplo un escenario en el que dosequipos “clientes” pretenden intercambiar una información:

Supóngase un escenario en el que dos usuarios están manteniendo una conversación me-diante una aplicación de mensajería instantánea en la que no sólo intercambian sus opinionesmediante texto escrito sino que también comparten archivos privados tales como fotos o docu-mentos importantes.

En la Figura 1.3 (a) se puede observar que todos los paquetes intercambiados entre los equi-pos de los dos usuarios pertenecientes a la conversación deben atravesar un tercer nodo (elservidor) que realiza las funciones de puente entre ambos. Sin embargo, en la Figura 1.3 (b) serepresenta una conexión en la que todos los equipos de la red presentan las mismas funciones deservidor y cliente a la vez (una conexión P2P), por lo que no es necesario que un tercer equipo


realice ninguna función que no tengan ya. De esta forma se puede crear una conexión directa2

entre los dos equipos involucrados en la conversación.Con sólo describir los dos modelos propuestos en el ejemplo ya resalta una importante ven-

taja: la liberación y aprovechamiento de los recursos de la red. La principal diferencia entre elloses 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 seraú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 necesariospara realizar las funciones de puente en esa cantidad de transacciones. A medida que fuera au-mentando el número de usuarios en la red, el servidor iría ocupando sus recursos de modo quellegaría un momento en el que se convertiría en el cuello de botella de las comunicaciones. Encambio, 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 servidoranalizase los mensajes o realizase una copia de los archivos que intercambian los usuarios? Enese caso, la privacidad de la información intercambiada podría verse seriamente vulnerada. Porello, al eliminar el equipo servidor que realiza las funciones de puente aumentaría la privacidadde los datos transmitidos ya que los únicos equipos por los que circulan los datos serán los delos usuarios finales (ver nota al pie número 2).

Por otro lado no todo son ventajas puesto que, actualmente, si atendemos a los accesos aInternet de los que un usuario medio suele disponer, están formados por uno o varios equiposque acceden a Internet a través de un router que realiza las traducciones de IPs y puertos, másconocido como NATs o NAPTs. Este proceso es necesario puesto que en este tipo de escenariosexisten 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 concentradoro switch. Dicho concentrador está conectado a un módem que realice la comunicación con elexterior (red pública). Normalmente el concentrador y el módem suelen estar presentes en formade un sólo equipo, comúnmente llamado encaminador (router).

En cuanto a encaminamiento, todos los equipos dentro de la red privada poseen una direc-ción IP privada. Éstas tienen la característica de ser únicas en esa red pero pueden repetirse encualquier otra red privada por lo que no son válidas para identificar un equipo a nivel global. Porcontra, en la red pública las direcciones IP asignadas a los equipos son públicas y únicas a nivelglobal por lo que cualquier equipo al que se le ha asignado una IP de este tipo es accesible porcualquier 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 unocon dirección IP privada por lo que existe la necesidad de que el router realice una traducción dela IP privada del equipo de su red interna a la dirección pública de la red externa de modo que elequipo externo que pretenda responder al mensaje sepa cómo encaminar su respuesta. Mientrastanto, el router va llevando un control de las traducciones que ha llevado a cabo para que, encaso 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

2Es una conexión directa hablando a nivel de aplicación ya que en esta transferencia de datos necesariamentetendrán que participar otro tipo de nodos de la red tales como switches o routers para encaminar la información deuno a otro a nivel de enlace o red a menos que ambos extremos mantengan una conexión punto a punto.


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 indicaral 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 dosmodelos que se están comparando (también se va a suponer que los dos usuarios se encuentranen 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 servidorpodrí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 conver-sación puesto que, suponiendo que conociesen la dirección IP pública del router de suinterlocutor, la petición de conexión alcanzaría el router y éste, al no ser una respuestaa ninguna petición realizada desde su red interna, descartaría el mensaje a menos que elrouter estuviera previamente configurado para entregar ese tipo de peticiones al equipodel usuario final.

Por otro lado, otro inconveniente que presentan las redes P2P frente a al modelo tradicional esreferente a la autenticación de los usuarios: Para poder autenticarlos es necesario conocer suscredenciales. Este tipo de información no puede estar replicada en todos los equipos puesto quese vería vulnerada su seguridad y credibilidad ya que se podría hacer mal uso del conocimientode la misma. Por ello es más recomendable disponer de la existencia de una entidad ajena a laconversación que pueda asegurar que los interlocutores son quienes dicen ser. Claro está quedicha entidad debe ser de confianza, aunque debido a que los objetivos de este proyecto fin decarrera no pretenden tratar temas de autenticación y seguridad, no se profundizará en el tema.


1.1.2. Tipos de redes P2P

Las redes P2P pueden clasificarse en función de dos aspectos: su grado de centralización osegún su estructuración.

1.1.2.1. Clasificación según su grado de centralización

Atendiendo a su grado de centralización, las redes P2P pueden ser catalogadas dentro de tresgrupos: 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 modelocliente-servidor. Las transmisiones, por tanto, se realizan a través del servidor central que realizalas funciones de punto de enlace entre los nodos y de control de la distribución de los nodos ysus 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 enun-ciada en el apartado 1.1.1. Es decir, son aquellas redes en las que todos los nodos poseen losmismos privilegios y realizan el trabajo de forma equitativa sin la necesidad de un reparto cen-tralizado desde un servidor o host estable. Dos redes muy famosas pertenecientes a este gruposon Overnet y Kad, las redes nativas sin servidores de los clientes eDonkey y eMule, respecti-vamente. Ambas redes basan su funcionamiento en variaciones del protocolo Kademlia el cualse encarga de descubrir la red de pares que comparten sus recursos. Más ejemplos de redes P2Ppuras 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 pertenecientesa la red y los recursos compartidos consiste en un tipo de red que recogía lo mejor del modelotradicional cliente-servidor y de la arquitectura P2P. Estas redes, clasificadas como mixtas ohíbridas, disponen de uno o varios servidores donde se almacena la información del reparto delos recursos en la red y de los pares activos. De este modo, cuando un nuevo par accede a lared, se comunica con el servidor para presentar sus recursos disponibles. Así, en el momento enel que un par necesita utilizar alguno, realiza una petición al servidor, quien le indica qué par opares 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 deficheros, en la actualidad este tipo de redes se utilizan en otros servicios muy bien conocidoscomo son Skype o Spotify.


1.1.2.2. 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 nombrarredes P2P estructuradas y no estructuradas.

Redes P2P estructuradas

En este tipo de redes se nombran usuarios responsables de una parte específica del conte-nido de la red. Así mantienen un tabla de hash distribuida en la que se asignan valores a cadacontenido y usuario de la red. De este modo, cuando un usuario pretende acceder a un conteni-do específico, primero realiza una petición al usuario responsable del mismo. Éste, entonces, leresponderá con la lista de usuarios en los que ese contenido está disponible. Ejemplos de estetipo 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 delos 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 todoslos usuarios. De este modo, los que dispongan de dicho contenido, responderán confirmándo-lo. Procediendo así, se genera demasiado tráfico en la red desperdiciando el ancho de bandadisponible. Algunas redes P2P no estructuradas son Napster, Gnutella, KaZaA y eDonkey.

1.1.3. Mecanismos de seguridad

De los mecanismos de seguridad utilizados en redes P2P, el que requiere mención en relacióncon este proyecto fin de carrera es el conocido como encriptación de protocolo o, como esllamado principalmente en los clientes de eMule: ofuscación de protocolo.

Este mecanismo de seguridad pretende cifrar los datos transmitidos de modo que los nodosintermedios, tales como encaminadores y demás elementos que participan en la transmisión dela información no sean capaces de interpretar la información transferida. Este mecanismo deseguridad se convertirá en una limitación del proyecto a estudiar en futuras versiones.

1.2. Sistemas de monitorización de red

Una vez estudiadas las características más generales de las redes P2P, es necesario encontraralgú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 yalgunos ejemplos comerciales.

1.2.1. ¿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 telecomu-nicaciones puesto que permite realizar actividades como recabar información sobre dicho tráfico


y obtener estadísticas del mismo. Gracias a ello, se pueden cumplir objetivos como estudiar elflujo 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 suscomunicaciones, detectar transmisiones no seguras o el envío masivo de tráfico innecesario porparte 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 cuyofuncionamiento básico es la captura y el posterior análisis del tráfico que circula por el nodo enel que se está ejecutando.

Algunos ejemplos comerciales de este tipo de sistemas son:

Javvin Packet Analyser: Este analizador de protocolos es capaz de capturar paquetesEthernet, analizar protocolos y reconstruir mensajes a nivel de aplicación. Interpreta to-dos los protocolos relacionados con TCP/IP y permite aplicar filtros. Según el fabricantesólo son necesarios 30 minutos de entrenamiento individual. Su precio es $249. Para másinformación consúltese la web del producto: http://www.javvin.com/packet.html

Network General Sniffer Basic: Capaz de capturar paquetes Ethernet, incluye un análisissimple 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 comunesque no están basados en TCP. Su entrenamiento es de una semana asistida por el fabricantey su precio es de más de $6000. http://www.netscout.com/

Wildpackets Etherpeek: Posee las mismas características que el anterior aunque su pre-cio ronda los $1000. http://www.wildpackets.com/

Wireshark: Anteriormente conocido como Ethereal. Gracias a que cumple las mismasfunciones que los sistemas anteriores, que dispone tanto de interfaz gráfica como por co-mandos, que es un proyecto de código abierto con una gran comunidad aportando mejo-ras diariamente y que es gratuito, es uno de los analizadores de protocolos más utilizado.http://www.wireshark.org/

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 primerlugar, se comentará la ventana principal que presenta el programa, de la cual se muestra unacaptura 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 demenú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), Statis-tics (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 MACo de red, actualizar la lista en tiempo real de paquetes mostrados en tiempo real o capturar enmodo promiscuo (modo de captura en el que el nodo captura todo el tráfico al que tenga accesovaya dirigido a él o no). El segundo permite realizar filtros, predefinidos o no, para que el análisisdel tráfico sea más cómodo y selectivo. La tercera opción permite mostrar estadísticas, gráficas


Figura 1.5: Ventana principal de Wireshark.

y diagramas de flujo para el tráfico seleccionado. Por último, en el apartado Telefonía se ofre-cen herramientas para decodificar el tráfico capturado que cumpla con el estándar o protocoloseleccionado 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 danacceso a las opciones más utilizadas. A continuación se encuentra un campo en el que se puedenintroducir parámetros del filtrado que se desea realizar a los paquetes capturados. En este aspec-to, pulsando la opción Expression... se accederá a un cuadro de diálogo que ayudará a formularcorrectamente la petición de filtrado.

En el siguiente paso hacia el fondo de la ventana, se encuentra el panel donde se muestratodos 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 yuna descripción resumida del mismo. Tras seleccionar un paquete de este panel, se mostrará enel mismo en los dos inferiores. El primero de ellos desglosa la información del mismo, clasifi-cá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 hexadecimaly ASCII.

1.3. Objetivos de este proyecto

En esta sección se presentarán los motivos por los que es necesaria la utilización de unentorno de experimentación para la generación y monitorización de tráfico P2P, teniendo encuenta las particularidades de estas redes. Tras ello, se procederá a definir los objetivos que


deberá cumplir el entorno creado al final de la implementación de este proyecto.

1.3.1. Motivación del proyecto

La necesidad de la creación de un entorno de experimentación para la generación y mo-nitorización de redes P2P surge a partir de las ventajas presentadas por las mismas frente altradicional modelo cliente-servidor. Dichas ventajas consisten en una mejora en el rendimientode las nuevas aplicaciones que hacen uso de las redes con arquitecturas distribuidas, como esel caso de la computación distribuida y similares. Debido a ello, es muy recomendable enfocarproyectos en el estudio de estas redes y la investigación de posibles mejoras, lo que conlleva ala utilización de un entorno de experimentación como el que se pretende implementar en esteproyecto. Este entorno debe presentar unas características y funcionalidades que pueden difere-rir de otros no diseñados específicamente para este fin como, por ejemplo, la manera en la quese deberá monitorizar el tráfico.

1.3.2. Objetivos

A continuación se pretenden fijar los objetivos de este proyecto para que cumpla las funcio-nes necesarias de modo que el resultado final pueda ofrecer las funcionalidades necesarias en elestudio del funcionamiento de las redes P2P:

Por ello, en primer lugar, se buscará el diseño y la implementación de un entorno que permitala generación de tráfico P2P tanto en ámbitos controlados como no controlados. Además, dichoentorno deberá disponer de un sistema de monitorización de tráfico que permita la captura y elposterior análisis conjunto del tráfico generado por todos los nodos pertenecientes a la red P2Pen uso.

Capítulo 2

Análisis

Este capítulo tiene como objetivo realizar un estudio de los requisitos que debe cumplir lasolución desarrollada por este proyecto fin de carrera. Tras ésto, se analizarán posibles solucionesque los cumplan, identificando y explicando sus ventajas e inconvenientes.

2.1. Requerimientos

A continuación se presentarán los requisitos del entorno de experimentación en función de suclasificación según si cubren aspectos funcionales o no funcionales. Los primeros identificaránlas funciones de las que podrá disfrutar el usuario final, mientras que los segundos describiránel resto de características que se necesiten para el correcto funcionamiento del entorno.

2.1.1. Requerimientos funcionales

En esta sección se describirán los requisitos que debe cumplir el entorno final implementadode 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áti-les para que el usuario pueda plantear el mayor número de escenarios posibles de cara a realizarun estudio más profundo. Para ello, los equipos han de permitir ser configurados sin ningunalimitació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 otecnología, sino que debe permitir el estudio de las redes P2P en la mayor cantidad posible deescenarios diferentes. Por ello, el entorno implementado deberá ser multiplataforma.

25

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 usua-rio pueda decidir en cual trabajar en función de sus necesidades. Utilizar un entorno controladopermitirá poder realizar el estudio del tráfico de una manera más estricta y limpia (con el menortráfico posible procedente de otras aplicaciones o equipos), mientras que, en ambientes no con-trolados 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 otronodo con acceso a Internet de modo que se le permita al usuario trabajar con él aunque seafísicamente imposible su acceso.

Generación de tráfico P2P

Para que se puedan realizar las pruebas pertinentes sobre tráfico P2P, el entorno configuradodeberá incorporar el software necesario para la generación de tráfico. Éste debe permitir el usode 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 posiblesdiferencias 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 captu-ras del tráfico de un modo distribuido desde un puesto de trabajo. Esta funcionalidad ha de sercapaz 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 con-sultar 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 demonitorización programada para ese instante, debería abstenerse de usarlo para no introducirtráfico no deseado en la captura realizada. El mismo caso podría aplicarse para en el supuesto enel que el usuario desease desconectar el entorno pero no lo hiciese tras comprobar la existenciade una sesión de monitorización en curso.


Integración del software de gestión de la monitorización distribuida con el de monitoriza-ción de tráfico

Deberá existir una integración de las opciones de monitorización de tráfico en las funcionesde gestión de la monitorización distribuida. Así se podrá permitir al usuario la utilización de lasprimeras a través de las segundas, además del tratamiento y la visualización de la informaciónde varias maneras distintas.

Generación del menor tráfico no deseado posible

Puesto que se desea implementar un entorno de experimentación, será necesario minimizarlos factores externos que puedan llevar a una mala conclusión por los datos mostrados en losestudios. Por ello, se deberá realizar una configuración de manera que se genere el menor tráficono deseado posible en la red para conseguir así que las capturas realizadas sean lo más cercanasposibles 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 ficherosgenerados en las sesiones de captura de tráfico. Estos archivos pueden llegar a presentar unostamaños consideradamente grandes por lo que consumirán una gran parte de la capacidad dealmacenamiento cuando, en ocasiones, ya no van a ser utilizados más. Por ello, será recomen-dable su organización y borrado, si procede, para poder reaprovechar los recursos de los que sedisponga.

2.1.2. Requerimientos no funcionales

En esta sección se describirán las características y funciones que debe cumplir la soluciónpresentada al final de la realización de este proyecto fin de carrera pero que no son directa-mente aprovechadas por el usuario. Es decir, esta sección está dirigida a recopilar los requisitosque necesariamente debe implementar este proyecto pero que no pueden ser catalogados en laclasificación del apartado anterior.

Escalabilidad

El entorno de experimentación presentado han de funcionar de la misma manera indepen-dientemente del número de nodos relacionados con esta tarea y de si uno o varios de los equiposinvolucrados 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úmerode sistemas operativos posible, de modo que sea reutilizable en otros entornos con diferentesescenarios y configuraciones.


Sencillez de uso

Por último, todas las funcionalidades y opciones que integre el entorno de experimentacióndeben presentar la información y sus posibles acciones mediante una interfaz gráfica que habilitesu uso al usuario sin la necesidad de una excesiva introducción de comandos. Además, el en-torno de experimentación debe permitir al usuario una interacción con el mismo de una maneraordenada, para que el mismo pueda controlarlo todo desde un único puesto de trabajo.

2.2. Análisis del entorno de experimentación

En esta sección se realizará un análisis que permita obtener una primera aproximación a lasdecisiones tomadas para el diseño del entorno de experimentación de modo que así se puedancumplir 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: Enprimer lugar se tratará la creación de un laboratorio donde se podrán realizar los estudios que sedeseen 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 quese requerirá de un sistema de gestión para la monitorización distribuida. En este último aspectose ha tomado la decisión de realizar un desarrollo propio puesto que no se ha podido encontrarninguna solución comercial existente que cumpliera los requisitos planteados.

2.2.1. Análisis del laboratorio

A continuación se detallarán las soluciones propuestas a los requisitos que afectan a la im-plementació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á necesariala configuración de dos redes: una que presente la característica de ser aislada y mantenga elcontrol de los equipos asociados a ella y otra que permita el acceso a Internet, dando así elcaracter “no controlado”.

El entorno controlado permitirá generar el tráfico según las necesidades impuestas por elusuario, de modo que se pueden estudiar al detalle ciertos procesos o fases en la comunicacióno, incluso provocar anomalías para conocer las reacciones a éstas. El tráfico que se analiza eneste 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 generadoen la red por los usuarios. Ésto permite obtener conclusiones más fiables y coherentes con larealidad.


A continuación se presentará cómo se puede configurar el acceso a Internet de modo que ellaboratorio 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 puedenrealizar dos configuraciones distintas que disfrutan cada una de unas ventajas y unos inconve-nientes.

La primera solución consiste en la configuración de un acceso a Internet propio para ca-da equipo, representada en la Figura 2.1 (a). Con esta configuración cada uno de los equiposdispondrá de una conexión a Internet exclusiva en la que no se encuentre detrás de ningún cor-tafuegos o firewall y tenga asignada una dirección IP pública para él mismo. Gracias a ésto, losequipos están mucho más accesibles al resto de pares de la red ya que las comunicaciones nodeben 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 equiposa 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 comercialy cuenta con la ventaja de que permite conocer los mensajes intercambiados por los equipos dela red P2P para salvar la existencia de NATs. En cambio, ese mismo aspecto puede convertirseen 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 re-querida 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 alos 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ónIP), 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 conexionesrealizadas a través de accesos convencionales a Internet. En ellos, la dirección IP pública seasigna mediante el protocolo DHCP, el cual se encarga de distribuir el rango de direcciones delas que dispone de manera que sean reutilizables. Así pues, cada vez que el equipo se desconectede la red de acceso a Internet y vuelva a conectarse, será muy probable que la dirección que sele haya asignado sea distinta a la de la sesión anterior. Por tanto, es necesario que el servicio denombres de dominio (DNS) sea dinámico, es decir, se actualice periódicamente.

Multiplataforma

Debido al requisito Multiplataforma, es necesario disponer de varios sistemas operativoscon arquitecturas distintas en el laboratorio. Ésto puede ser solventado de dos maneras distintas:


(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 esta-blecidas mediante enlaces cableados o inalámbricos.

la primera se basa en la configuración de un número de equipos con un sistema operativo yotro grupo en el que se instale otro. Así se continuará debiendo disponer de tantos grupos deordenadores como sistemas operativos distintos se deseen instalar. Con este método, suponiendoque, para realizar pruebas en un tipo de plataforma, sean necesarios x equipos y que se deseaconfigurar solamente dos sistemas operativos distintos, el número de equipos requeridos será de2x, 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 operativosen 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 sistemasoperativos se pretendan instalar y alojarlos en ellas. El mayor inconveniente de esta solu-ción es que cada equipo podrá ejecutar un solo sistema operativo a la vez y será necesarioreiniciarlo para poder acceder a otro. Por otra parte, también presenta una ventaja deriva-da del mismo inconveniente: el equipo no tiene que repartir sus recursos hardware entrevarios 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 equipovirtual 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


la aplicación que genera la máquina virtual es conocido como el anfitrión, mientras que alque hace las funciones de segundo sistema operativo al ser ejecutado en el equipo virtualse le nombra como el huésped. Presenta la ventaja de poder disponer de dos sistemasoperativos a la vez en un mismo equipo con sólo generar una máquina virtual. Ademáspermite multiplicar el número de equipos que acceden a la red sin el gasto de nuevohardware. Por contra, el mayor inconveniente conocido es que no presenta un rendimientoóptimo, puesto que varios sistemas operativos completos se encuentran consumiendo losrecursos del mismo equipo.

Generación y monitorización del tráfico P2P

Para estas funcionalidades, será necesario seleccionar dos tipos distintos de redes P2P quepermitan estudiar las diferencias entre ellas. Para el caso de una red estructurada y pura, seutilizará 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 elmás extendido en el campo de las telecomunicaciones.

2.2.2. 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 lamonitorizació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ítu-lo, la monitorización se realizará de modo distribuido, por lo que será necesaria la gestión de lamisma. 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 se-gundo cumplirá el papel de acometer las instrucciones ordenadas por el primero. La idea defuncionamiento de estos dos módulos consistirá en que un usuario podrá, desde el puesto detrabajo donde se ejecuta el administrador, controlar una red de sondas que realizarán la capturadel 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 capturastomadas de esta forma se puedan fusionar en una sola, respetando el orden correcto de los men-sajes transmitidos, se deberá establecer un mecanismo de sincronización de las trazas de modoque 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.


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 nave-gador 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 deterceros instaladas en el equipo, condición necesaria para asegurar el cumplimiento del requisitoen 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 len-guaje de programación Java. Las aplicaciones que hacen uso de esta tecnología pueden ser eje-cutadas en cualquier equipo que disponga del entorno de ejecución de la misma Java RuntimeEnviroment (JRE). Además, esta tecnología sí permite la ejecución de comandos a nivel de laterminal (command prompt en Windows), por lo que se pueden ejecutar aplicaciones de terceraspartes. Por otra parte, también se ha valorado la experiencia con esta plataforma del desarrolladorde este proyecto.

Capítulo 3

Diseño

En este capítulo se pretende describir el diseño de los módulos que componen el entorno deexperimentación que resulte al final de este proyecto. Para ello, en primer lugar se realizará eldiseño del laboratorio que formará el entorno pretendido y, a continuación, el del software degestión de monitorización distribuida de desarrollo propio.

3.1. Diseño del laboratorio

En esta sección se tratará el diseño del laboratorio para poder implementar en él una red deordenadores capaz de cumplir con todos los requisitos nombrados en el capítulo 2. Para ello, secomenzará 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 paraproporcionar a los equipos las capacidades necesarias para el desarrollo de las actividades quedeben ser capaces de realizar.

3.1.1. 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 disponerpara llevar a cabo este proyecto. Para ello se ha de suponer el peor escenario en cuanto a númerode equipos requeridos. Se tomará aquel en el que se pretende estudiar, bajo un entorno contro-lado, un tipo de red P2P centralizada o una mixta. Ambas redes presentan la necesidad de, almenos, dos equipos que intercambien su información y un servidor que realice la gestión de losusuarios y el contenido compartido de la red. Además, al pretender que los equipos trabajen enun entorno cerrado o controlado, los equipos necesarios deben permanecer a dicha red. Debidoa 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 estrellaen la que los equipos estén conectados mediante cable Ethernet a un concentrador o enrutador

33

CAPÍTULO 3. DISEÑO 34

que realizará el encaminamiento necesario para que los equipos puedan comunicarse. Así seevita que un equipo no autorizado pueda acceder a dicha red puesto que el único modo de incor-porarse a la misma sería accediendo al lugar donde se encuentra el dispositivo de interconexiónpara conectarse a él físicamente. Para ello, será necesario que el switch utilizado deba dispo-ner de un número de puertos Ethernet, como mínimo, igual al número de equipos de la red, loscuales, 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 IPde los equipos de esta red y la máscara de red sean tales que no identifiquen otras redes comointernas a ésta (se ha de tener presente que esta red debe ser cerrada para asegurar que el entornosea controlado).

Por ello, la decisión tomada es utilizar la máscara de red 255.255.255.0. Es suficiente paraincluir a los equipos que formarán parte de la red y presenta la comodidad hacia el administradorde la misma para identificar redes distintas con solo atender al tercer octeto si se lee de izquierdaa derecha. Es decir, una red podría identificarse por la dirección IP 192.168.2.0, permitiendoa los equipos pertenecientes a la misma adoptar direcciones dentro del rango 192.168.2.1 al192.168.2.254; y otra red, distinta y externa a la anterior, podría utilizar cualquier otra direcciónIP dentro del rango 192.168.0.0 a 192.168.255.0, 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: 255.255.255.0

Dirección IP de la red: 192.168.2.0

Dirección IP del enrutador: 192.168.2.1

Dirección IP del primer equipo: 192.168.2.10

Dirección IP del segundo equipo: 192.168.2.20

Dirección IP del tercer equipo: 192.168.2.30

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 quese preste al usuario la comodidad de no tener que memorizar esas direcciones para iniciar comu-nicaciones entre ellos. Un ejemplo de esto: Supóngase que el usuario quiere ejecutar el comandoping 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 192.168.2.30”. Encambio, si el tercer equipo tiene asignado un nombre tal como “tercerEquipo”, el usuario sólotendría que ejecutar “ping tercerEquipo”, algo más cómodo de recordar y de interpretar por sermá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 analizaruna serie de comandos de este estilo, será complicado atender la diferencia. Por ello, en esteproyecto, al ser tres los equipos utilizados, se han seleccionados tres nombres que tengan relación


pero, a la vez sean fácilmente diferenciables: “mortadelo”, “filemon” y el “super”. Además, suconfiguración estará pensada para que, en el escenario de una red mixta o centralizada, los dosprimeros 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 accesoa cviugr-v2, una red inalámbrica mediante la cual se obtiene una conexión que se podría clasificardentro de las del primer tipo en la diferenciación realizada en la sección 2.2.1, será la escogidapara este proyecto fin de carrera. Aún así, el enrutador que realiza las funciones de intermediarioen 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 direccionesIP de esta red serán asignadas automáticamente por el proveedor del servicio de un modo noestático (no se asignan siempre las mismas direcciones IP) por lo que se necesitará configurar elservicio de DNS dinámico, el cual se comentará a continuación.

3.1.2. Configuración software

DNS Dinámico

Puesto que en la conexión cviugr-v2 las direcciones IP son asignadas automáticamente me-diante el protocolo DHCP descrito en el capítulo 2, es necesario utilizar un método que permitavincular 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 re-mota al equipo de interés desde cualquier otro nodo conectado a Internet, cuya configuración serealizará más adelante.

Para que este servicio funcione es necesario actualizar la dirección IP pública asignada cadacierto periodo de tiempo. Por ello, se deberá instalar y ejecutar en cada inicio del sistema uncliente 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-IP1 en su versión gratuita, la cual presenta algunas limitaciones que no sepretenden 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 In-ternet se habilitará la funcionalidad de acceso remoto. Las soluciones que se barajarán son lassiguientes:

SSH: Permite acceder al equipo mediante una consola, utilizando el protocolo de segu-ridad SSH y cualquier programa que haga uso del mismo. Además, el acceso realizadomediante esta opción es seguro ya que el tráfico generado está cifrado de modo que las

1http://www.no-ip.com/


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 alequipo sea de modo seguro pero, además, brinda la oportunidad de ver la interfaz gráfi-ca del software utilizado. El mayor inconveniente que presenta es que cada vez que unusuario realiza un acceso, se genera una nueva sesión para el mismo por lo que si, porejemplo, dos usuarios acceden remotamente y ejecutan cada uno una máquina virtual, elequipo al que se está accediendo deberá procesar y ejecutar ambas solicitudes, por lo queel rendimiento será ínfimo. Además, suponiendo el mismo ejemplo, si los dos usuariosdesean monitorizar un tráfico generado bajo control, sus capturas se verán afectadas porel tráfico generado por el otro usuario. Por otra parte, si lo que se desea es acceder paraver 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 abiertasen la misma. Por último, cabe recalcar que esta solución no es capaz de adaptar la gamade colores a la capacidad de la conexión por lo que, si se accede desde un lugar dondeel ancho de banda es bajo, se percibirá una respuesta intermitente por parte del equiporemoto.

VNC: Es otra opción de cara al acceso a las interfaces gráficas. Este modo de accesopermite recuperar la sesión abierta en la que se dejó al equipo en su última interaccióncon el mismo. Además, es capaz de adaptar la calidad de la imagen al ancho de bandadisponible por lo que es más indicado en cuanto a requisitos de la red. Una de sus opcioneses 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 conocersi hay otros usuarios accediendo al mismo. Por contra, a diferencia de los dos métodosanteriores, no permite la transferencia de archivos.

Para este laboratorio se habilitarán los tres tipos de acceso puesto que las características propiasde 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 la-boratorio ha sido la creación de máquinas virtuales para aprovechar la característica de introducirmás equipos en la red sin la necesidad de adquirir otros físicos. Ésto lleva a plantear la siguientedecisión: ¿cuál será el sistema operativo anfitrión y cuál el huésped? Para decidirlo, hay queatender a otros requisitos fijados en el capítulo anterior. Especialmente aquel que pretende quelos equipos (reales) sean altamente configurables. Ante este requisito, hay que decantarse por unsistema operativo basado en entornos UNIX para el equipo anfitrión, de modo que el huéspedejecutará Windows.

Como entorno UNIX se ha elegido la distribución de Linux Ubuntu debido a la cercanía ylos conocimientos de uso del mismo por parte del alumno. En cuanto a Windows, al ejecutarse


en una máquina virtual, se requiere una versión que sea poco pesada de ejecutar. Por tanto, laversión escogida es Windows XP.

Para terminar con el diseño de la multiplataforma, hay que comentar que, para que los equi-pos 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, di-cha 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 laFigura 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 soneMule para entornos Windows y aMule para el resto.

Por otra parte, si se van a realizar pruebas en un entorno controlado, también es necesarioque el servidor que gestiona la red eDonkey esté presente en la red. Por ello, se hará uso delsoftware 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 delínea de comandos permitiendo así, su acceso desde otras aplicaciones, lo que ayudará a laimplementación de la integración de éste en el sistema de gestión de monitorización distribuida.

3.2. 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, permitiendoasí que el usuario pueda programar la ejecución simultánea de capturas del tráfico en todos losequipos desde un solo puesto de trabajo, es necesario disponer de un sistema con mencionadafinalidad. 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 unAdministrador, 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 funciona-lidades 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 posibleobservar el tráfico y para realizar el propio proceso de captura con volcado a un fichero medianteel comando tshark. Mientras tanto, el segundo módulo hará uso de mergecap, también presenteen este paquete, para fusionar las capturas de una misma sesión procedentes de otras capturas;


Figura 3.1: Topología de la red del laboratorio.


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 mismoarchivo bajo la interfaz gráfica del paquete.

3.2.1. Sincronización de trazas

Antes de proceder al diseño de los dos módulos que formarán parte del sistema de gestión demonitorización distribuida, es necesario realizar la decisión de cómo se asegurará la coherenciade 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 administradordel software de gestión de monitorización distribuida debe llevar un control de sincronización delas trazas. Para ello, será necesario conocer la diferencia entre los relojes internos de los equiposinvolucrados en la monitorización del tráfico. Existen, principalmente, dos opciones con las quellevarlo a cabo:

La primera es la sincronización de los relojes de los equipos. De esta forma la diferenciaentre dichos relojes es mínima por lo que se puede actuar como si fuese nula. Esta soluciónpresenta dos problemas: Por un lado, implementar un sistema de sincronización de relojes quemodifique la hora del sistema operativo puede que entre en conflicto con el servicio nativo delmismo 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 dereferencia 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 nombraa un equipo para que realice esa gestión en la red, los equipos de fuera de la misma pueden estarligados a otro servidor de tiempo.

Debido a los problemas presentados por la anterior, se utilizará una segunda opción con-sistente en el cálculo de la mencionada diferencia de relojes y utilizarla para fijar la fecha deprogramación de captura de tráfico a base de aplicar esa diferencia calculada a la fecha que el


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 inicioy fin de las tareas. Así pues, se profundizará más en el diseño de la realización de este cálculoen la subsección 3.2.3.

3.2.2. Diseño del módulo Sonda

Este módulo será el encargado de permitir la comunicación entre el administrador y el equipodonde se está ejecutando. Gracias a él, el administrador será capaz de programar capturas deltrá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 rele-vante en el sistema. Esta información está formada por el número de administradores conectadosen ese momento a la sonda, la interfaz de captura que se está utilizando (pudiendo cambiar-la manualmente desde la misma) y, como datos más importantes, las tareas programadas y suinformación de estado como el administrador que la ordenó, la fase de ejecución en la que seencuentra 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 ningunaotra acción sobre la misma. Aún así, puesto que se pretende acceder a las interfaces de red pararealizar las capturas, aunque sea a través del comando tshark, será necesario que este módulosea ejecutado en modo administrador.


Comunicación con el administrador

Puesto que la sonda se limitará a realizar las acciones indicadas desde el administrador, sedebe mantener una comunicación con el mismo. Además, la sonda ha de poder ser accedida porvarios 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 14015 ya que seha realizado una pequeña investigación y no se ha encontrado su uso en otras aplicaciones. Aúnasí, 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 porparte 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 selleva una gestión de los mismos, es muy probable que éstos terminen llenando el disco duro dis-ponible. El módulo sonda, por tanto, debe gestionar los archivos utilizados para no hacer un usoabusivo 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.

3.2.3. 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 dis-tribuidas en la red desde un único puesto de trabajo, pudiendo programar en ellas nuevas tareasde captura simultáneas y realizando la recolecta de las mismas para, finalmente, mostrarlas fu-sionadas en una sola. Para realizar estas funciones, se va a proceder al diseño del mismo (sudiagrama 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 leindiquen. Para ello intentará conectarse a la dirección IP y puerto destino y, tras una primerapresentación o handshake, se calculará la diferencia de relojes y la latencia existente en la redmediante su Round-Trip-Time.

Tras esto, se mantendrá la conexión activa aunque, para evitar sobrecarga de mensajes enla red, no se hará mediante el envío de mensajes periódicos a nivel de la aplicación sino quese confiará en los mecanismos utilizados a un nivel más bajo. Esta conexión será utilizada paraenviar todas las peticiones necesarias y recibir sus respuestas. En cambio, en el proceso derecolecta de las trazas, el administrador abrirá el puerto 14020 para la recepción del fichero quecontiene la información de la captura.


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 lasubsección 3.2.1, es necesario que se realice un control sobre las diferencias de relojes existentesentre los equipos mediante el cálculo de la misma y su posterior aplicación en la correción delas horas de inicio y fin de cada sonda.

Para calcular la diferencia de relojes, una primera aproximación consiste en el envío, porparte del administrador, de un mensaje con una marca de tiempo (en adelante MTA1), que de-be ser respondida desde la sonda con su marca de tiempo (MTS). Tras recibir la respuesta, eladministrador realiza la diferencia entre ambas marcas de tiempo cuyo resultado comprende ladiferencia 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árseloal valor ya calculado y así obtener la diferencia final entre los relojes. La obtención del retardopuede obtenerse a partir de tres maneras:

Uso del ping nativo: Los sistemas operativos incluyen un comando ping que permite co-nocer si un destino en la red es accesible y el retardo que se ha introducido en los paquetestransmitidos hacia ese destino. Es el más preciso pero presenta dos inconvenientes: Elprimero es que, puesto que se está desarrollando un software multiplataforma y este co-mando es nativo, será necesario hacer una versión del cálculo para cada sistema operativodistinto. El segundo inconveniente consiste en que puede ser que el puerto propio utilizadopor el comando esté bloqueado en el equipo de destino.


Uso de la función en Java isReachable(): Esta función actúa de modo muy similar alcomando anterior puesto que indica si el otro extremo está accesible con las diferenciasde que se puede ejecutar en cualquier sistema operativo sin tener que especificar nada yque no indica el retardo de la red, por lo que para conocerlo se puede medir el tiempoque tarda en ejecutarse dicha función. Tras varias pruebas realizadas, se descarta estafunció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énfalsea la medida puesto que se incluye el tiempo destinado al establecimiento de la nuevaconexión.

Uso de una nueva marca de tiempo: Si se modifica el intercambio de mensajes anterior yse añade la obtención de una nueva marca de tiempo, se pueden calcular los dos sumandosde la parte derecha de la ecuación anterior. La modificación a los mensajes anterioresconsiste en añadir en el mensaje de respuesta de la sonda al administrador el MTA1 queacaba 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 aese mensaje reenviando de vuelta el MTA1 y añadiéndole su marca de tiempo, MTS. Alrecibir 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 quetarda la información en viajar desde el administrador a la sonda y volver, conocido comoRound-Trip-Time o RTT. Si se supone que la red es simétrica, se puede afirmar que elretardo 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úmerode repeticiones y obtener la media aritmética de la misma. El número de repeticiones variará enfunció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 retardopara poder realizar estos cálculos, hay que desactivar el algoritmo de Nagle (aunque con ello segenere 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 ope-raciones disponibles de un modo directo y sin tener que buscarlas entre muchas ventanas. Dis-pondrá solamente de tres: la ventana principal en la que se integrará el gestor de sondas, unaopción para crear una nueva tarea y otra que permita mostrar una segunda ventana encargadade gestionar las tareas programadas, pudiendo ver su estado, borrarlas o abrirlas una vez se haterminado de recolectar y fusionar las capturas, lo que llevaría a una última ventana donde semostraría el visor de la tarea completa.


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ónde 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) seleccio-nada(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 unbotón llamado “Tareas”. En esta nueva ventana se presentará el estado de las tareas programadascon 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 deno haber comenzado la captura, cancelará su programación y, en el caso opuesto en el que ya sehaya completado, borrar el archivo final. No se podrá cancelar una tarea que esté ejecutándoseen ese momento.

Por otro lado, la opción “crear una nueva tarea” estará situada en la ventana principal, puestoque, para utilizarla, habrá que seleccionar las sondas involucradas y pulsar el botón correspon-diente a esta opción. A continuación se pedirán las horas de inicio y fin y se creará la tarea enlas sondas seleccionadas.

Cuando se crea una nueva tarea, el administrador le asociará una etiqueta identificativa únicaque permitirá nombrarla sin la necesidad de ningún dato extra. Esta etiqueta estará formada porel 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 mostrartoda la captura en un formato legible para el usuario, una lista desplegable donde poder elegir elfiltro 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 losarchivos de capturas utilizados para no llenar rápido e inútilmente el disco duro del equipodonde se está ejecutando. Esto afecta, especialmente, al proceso de recolección de las capturasde las sondas, puesto que será necesario almacenar esos ficheros recibidos antes de fusionarlosen uno. Por ello, se seguirá el siguiente orden:

1. Creación de un directorio en la carpeta “Capturas” con el nombre de la etiqueta identifi-cativa de la tarea.

2. Se almacenarán los ficheros recibidos en el directorio recién creado.


3. 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 hayadentro.

3.2.4. 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, esnecesario marcar unas pautas y definir unos mensajes para cada orden que pueda realizar eladministrador a las sondas. El intercambio de mensajes también se puede ver en la Figura 3.22:

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á dis-tinto al enviado por el administrador para no crear confusiones. Los parámetros que se añadiránserá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 consideraa sí mismo desconectado. No existe el problema de que la sonda no lo reciba debido a que, alser un protocolo a alto nivel, las capas inferiores pertenecientes a TCP/IP realizarán los reenvíosnecesarios.

Aún así, si por algún casual no llega el mensaje a su sonda destinataria, no supone ningúnproblema 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ónterminará muriendo por su timeout.

Mensajes para crear una nueva tarea

El administrador comenzará la conversación con un mensaje tipo TAREA cuyos parámetrosserá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 tipoTAREA, pero distinto al del administrador.

Mensajes para recopilar una tarea

Cuando una tarea haya cumplido su hora de finalización, el administrador esperará un cortoperiodo de tiempo para dar lugar a que las sondas terminen con los procesos de cerrar el fichero

2La pendiente en la transmisión de los mensajes no tiene relación con el tiempo de transferencia.


(a) Conexión. (b) Desconexión. (c) Nueva tarea.

(d) Recopilar tarea.

(e) Cancelar tarea.

Figura 3.5: Protocolo a nivel de aplicación


de captura y demás. Entonces el administrador enviará el mensaje GETTAREA cuyo parámetroes la etiqueta identificativa de la tarea.

Si la sonda dispone de la misma, responderá a la petición con un mensaje OKTAREA yprocederá al envío del archivo con la captura. En caso de no disponer de la misma, enviará elmensaje NOTAREA.

Mensajes para cancelar una tarea programada

Si el usuario decide cancelar una tarea programada antes de su comienzo, el administradorenviará un mensaje BORRARTAREA al que se le añadirá como parámetro la etiqueta identifi-cativa de la misma y esperará la respuesta de la sonda, la cual enviará el mensaje OKBORRARsi ha realizado la acción correctamente o NOBORRAR si se ha producido algún problema en elproceso.

Capítulo 4

Implementación

Este capítulo tiene como finalidad indicar todos los pasos realizados en la implementaciónde este proyecto fin de carrera. Para ello, en primer lugar se procederá al montaje del laboratorioy su posterior configuración. Más tarde, se instalará todo el software necesario y, por último, seexplicará el proceso de programación del sistema de gestión de monitorización distibuida.

4.1. Implementación del laboratorio

En esta sección se pretende comentar los pasos a seguidos para la implementación del la-boratorio diseñado en el capítulo 3. El orden que se seguirá para ello es el siguiente: Montajehardware del laboratorio, configuración del mismo e instalación del software requerido.

4.1.1. Montaje hardware

Para la implementación del laboratorio, se llegó a la conclusión en el capítulo de diseño de lanecesidad 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 Ethernety una interfaz inalámbrica. Éste servirá de elemento de interconexión para los equipos por loque 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 detres adaptadores inalámbricos conectados, cada uno, a uno de los equipos del laboratorio a travésde uno de sus puertos USB.

Por último, serán necesarios un monitor, un teclado y un ratón, los cuales estarán conectadosa los tres equipos mediante un conmutador PS/2 KVM. La opción comercial escogida para éstees el modelo DKVM-4K de D-Link. Éste dispositivo permite controlar hasta cuatro equiposmediante el uso de un conjunto monitor+teclado+ratón. Dispone de un botón para conmutarsecuencialmente entre cada uno de ellos aunque también permite utilizar atajos de teclado parasu control de modo que, si se pulsa dos veces seguidas la tecla Ctrl y, a continuación, algúnmodificador, se llevará a cabo la acción.

Los principales modificadores son los siguientes:

48

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 si-guiente, respectivamente.

Teclas con los números del 1 al 4: Conmuta el control al equipo cuya posición es laindicada por el número.

La Figura 4.1 presenta el esquema del cableado del laboratorio. Como indica la leyenda lasconexiones azules son un conjuto de cables PS/2 para el ratón y el teclado y VGA para elmonitor, mientras que las conexiones en negro son enlaces Ethernet. En la figura se ha obviadoel 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 laSeñal, Telemática y Comunicaciones de la Universidad de Granada.

4.1.2. 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 sis-tema 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 dis-tribución1 y se descargará la última versión en formato .iso. Una vez finalizada la descarga, segrabará en un CD que se insertará en los equipos para realizar la instalación. El proceso consisteen un asistente en el que hay que responder cuestiones del tipo idioma, zona horaria, espacio dedisco utilizado para la instalación (elegido el por defecto ofrecido bajo la opción “utilizar todoel disco”), nombre del equipo, nombre de usuario y contraseña. En todos los equipos se respon-

1http://www.ubuntu.com/


derán las cuestiones con los mismos datos, excepto en el campo para establecer el nombre delequipo.

Conexión a Internet

Una vez instalado el sistema operativo, el siguiente paso consistirá en dotar a los equipos deconexión a Internet puesto que el método más cómodo de instalación de software es medianteel comando apt, el cual, durante su ejecución, realiza el proceso de descarga del instaladorde la aplicación requerida y lo ejecuta. Por ello se introducirá en un puerto USB uno de losadaptadores inalámbricos, se hará clic con el ratón en el icono del Network Manager situado enla barra superior y se seleccionará la red cviugr-v2. A continuación se rellenarán los campos taly como se indica en el tutorial disponible en la web del Centro de Servicios de Informática yRedes de Comunicaciones, CSIRC2:

En seguridad inalámbrica, se seleccionará WPA & WPA2 Enterprise. En la lista desplega-ble de autenticación, se elegirá Tunneled TLS. Como identidad anónima se escribirá [email protected], o [email protected] si el correo que se proporcionará en los campos delas credenciales es el de un alumno. Para el certificado CA, se descargará de la misma web. Enel apartado autenticación interna, se escogerá PAP y, por último, en los apartados usuario yclave 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 rendimientoy seguridad, es recomendable realizar una actualización completa del sistema de modo que todose encuentre en la última versión. Para ello se utilizará el siguiente comando, ejecutándolo enuna 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óny 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 laconfiguració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 formade 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

2http://csirc.ugr.es/informatica/RedUGR/CVI/ConectarCVI-UGR/cviugr2/linux.html


A continuación se accederá, mediante un navegador web, a la misma dirección. Este procedi-miento mostrará la página web de configuración del enrutador, en la cual se desactivará el puertode WLAN (conexión inalámbrica) y se establecerán la dirección IP 192.168.2.1 y su máscara dered 255.255.255.0. Por último, se deberá indicar que no se desea hacer uso del servidor DHCPincorporado. Éste servidor se encarga de asignar automáticamente direcciones IP a los equiposque se conecten.

El siguiente paso consiste en la configuración de las interfaces de red de los equipos. Elmodo manual de definir la dirección IP de una interfaz es mediante el comando:

ifconfig interfaz downifconfig 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ónIPcon la máscara de red máscaraDeRed.

Estas ordenes requieren ser ejecutadas con permisos de administración, por lo que se les aña-dirá el comando sudo al inicio. De este modo para establecer en el equipo 1, filemón, la direcciónIP 192.168.2.10/24 (“/24” es otra forma de representar que su máscara de red es 255.255.255.0),se ejecutarán las siguientes instrucciones:

sudo ifconfig eth0 downsudo ifconfig eth0 192.168.2.10 netmask 255.255.255.0 up

Este procedimiento habría que repetirlo en cada equipo asignando su dirección en la red. Elinconveniente de realizar la configuración de este modo consiste en que cada vez que se reiniciela 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 seencuentra en la siguiente ruta3:

/etc/network/interfaces

En este archivo se definen las características propias de cada interfaz y el modo en el que seactivan 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á queinsertar las siguientes líneas en el mencionado archivo de configuración (habrá que editarlo conprivilegios de administrador):

auto eth0iface eth0 inet staticaddress 192.168.2.10network 192.168.2.0netmask 255.255.255.0

3En esta distribución. Es posible que en otras, cambie su localización.


Con esto ya estaría configurada la interfaz y protegida frente a reinicios, tanto del equipo comode la conexión.

En el capítulo 3 también se habló de la necesidad de que las máquinas virtuales -que se confi-gurarán más tarde- aparezcan en la red como si se tratase de equipos independientes y reales. Porello es necesario configurar las interfaces para que éstos reciban sus paquetes y puedan actuarcomo si estuvieran directamente conectados a la red. Antes, es necesario recordar la diferenciaentre 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 dife-rencia de un conmutador o enrutador, no realiza ninguna función de encaminamiento. Ésto es loque se necesita para dotar a las máquinas virtuales de conexión a la red, pero, como son equiposcreados dentro de los ordenadores físicos, el puente también debe ser emulado por éstos. Paraello, se necesitan seguir los siguientes pasos:

En primer lugar, será necesario la creación de una interfaz virtual a la que se conectará lamáquina virtual. Para ello, es necesario disponer del comando tunctl, perteneciente al paqueteuml-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 elcomando:

sudo tunctl -u usuario

Con ello se creará una interfaz llamada tap0 que se podrá configurar como cualquier interfazreal.

El siguiente paso será la creación del puente y la asignación de las interfaces que lo com-pondrá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 queacepten todos los paquetes que reciban. Sean para ellas o no. Ésto se puede realizar de dosmaneras:

Fijando la dirección IP de la interfaz a 0.0.0.0 de modo que actúe como si todo lo quecircula por la red, fuese para ella.

Indicándole a la interfaz que actúe en modo promiscuo mediante la adición de la opciónpromisc 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 segundaopción. La dirección IP de la máquina virtual se asignará más tarde de forma estática a través dela configuración del sistema operativo huésped. Así pues, se ejecutarán los comandos:


sudo ifconfig tap0 0.0.0.0 upsudo ifconfig eth0 192.168.2.10 netmask 255.255.255.0

promisc up

Ahora sí se puede crear el puente br0 y añadirle ambas interfaces mediante las instrucciones:

sudo brctl addbr br0sudo brctl addif br0 tap0sudo brctl addif br0 eth0sudo ifconfig br0 up

Con ésto ya estaría establecido el puente y se podría utilizar. El inconveniente presentado por estaconfiguración es el mismo que el comentado anteriormente en el establecimiento de la direcciónIP de la interfaz eth0. Por tanto, se solucionará del mismo modo: el archivo interfaces contendrá,entonces, las siguientes líneas:

auto loiface lo inet loopback

auto eth0iface eth0 inet staticaddress 192.168.2.10network 192.168.2.0netmask 255.255.255.0pre-up ifconfig eth0 promisc up

auto tap0iface tap0 inet manualup ifconfig $IFACE 0.0.0.0 updown ifconfig $IFACE downtunctl_user usuario

auto br0iface br0 inet staticaddress 192.168.2.10network 192.168.2.0netmask 255.255.255.0bridge_ports eth0 tap0

Con esto, el usuario no tendrá que repetir los comandos explicados anteriormente para establecerlas direcciones IP, cada vez que inicie el ordenador.

Por último, para facilitar la identificación de los equipos y que el usuario no necesite memo-rizar todas las direcciones IP de los equipos, tanto físicos como virtuales, se asignarán nombresque 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:


Ubuntu: /etc/hostsWindows: C:\Windows\system32\drivers\etc\hosts

Al mencionado archivo se deben añadir las siguientes líneas para conseguir esta manera deactuar:

192.168.2.10 filemon192.168.2.11 filemonxp192.168.2.20 mortadelo192.168.2.21 mortadelodisfrazao192.168.2.22 mortadeloxp192.168.2.30 super192.168.2.33 superxp

En esta lista, se puede observar que todos los equipos que estarán en la red serán los queejecutan 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á ofrecerun servidor eDonkey alternativo mediante el que se podrá estudiar si hay comunicación entreservidores o no.

En ese caso también será necesario una interfaz de red virtual, tap1, para él que se creará delmismo 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á VirtualBoxpuesto que se presenta como una solución gratuita y muy potente para este fin. Además, existeuna gran comunidad que aporta mejoras constantes y que ha conseguido que el buen rendimientoen 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 WindowsXP. Para ello, se debe ejecutar la aplicación y seleccionar en la ventana principal, la opciónNueva. Ésto dirigirá a un asistente en el que se elegirá el nombre identificativo de la máquinavirtual, el sistema operativo que se pretende instalar, la memoria RAM de la dispondrá y eltamañ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 debeacceder a la configuración de la misma, apartado Almacenamiento, y vincular el lector de CD alfísico del equipo anfitrión, donde se debe introducir un disco de instalación de Windows XP. Seacepta la nueva configuración e inicia la máquina virtual.

Una vez iniciada, se mostrará el asistente de instalación de Windows XP, cuyas cuestioneshabrá 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 elapartado Adaptadores de red, habrá que seleccionar el acceso directo a la interfaz tap0 (tap1en el caso de mortadelodisfrazao). Una vez aceptada la configuración, se iniciará de nuevo la


máquina virtual. Cuando el sistema operativo haya terminado de arrancarse, habrá que dirigirsea Inicio, Conexiones de red. Desde ahí se accederá a la interfaz de red, donde se estableceránmanualmente los parámetros de la red en su configuración de TCP/IP. En el mismo lugar, sedesactivará la configuración de descubrimiento del resto de los equipos, de modo que, así, sereducirá el tráfico no deseado generado en la red.

Por otra parte, al igual que es recomendable mantener el sistema operativo anfitrión actua-lizado, también lo es en el huésped. Por ello, es necesario dotarlo de acceso a Internet para quepueda descargar sus últimas actualizaciones. La manera de hacerlo será mediante la creación deuna nueva interfaz en la máquina virtual con una conexión tipo NAT. Además habrá que realizaruna configuración extra en el equipo anfitrión, el cual actuará de enrutador reenviando el tráficogenerado por la máquina virtual y realizando las funciones propias de un NAT. Para habilitaresta 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. Elproblema es que el tráfico de respuesta, no será reencaminado a su destino final puesto quetodavía no se traducen las direcciones mediante NAT. Para activarlo, es necesario el uso delcomando iptables:

sudo iptables -t nat -A POSTROUTING -j SNAT --to-sourcedirecció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 actuali-

zarse. Estos dos comandos habrá que ejecutarlos tras cada reinicio, cada vez que se desee queel sistema operativo de la máquina virtual acceda a Internet. No se va a configurar de modopermanente puesto que la mayor parte de los estudios se pretende que se realicen en un entornocontrolado.

Una vez esté lista la configuración de la máquina virtual en un equipo, se utilizará la opciónduplicar para guardar una copia de seguridad en caso de cualquier incidente y para copiarla aotros equipos de modo que se ahorre trabajo. Ésto, actualmente, no puede ser realizado medianteinterfaz 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 archivoDes-tino.vdi una copia del anterior disponible para mover y exportar. En el caso de querer copiar eldisco duro, es necesario utilizar este método puesto que, si simplemente se copia el archivoOri-gen.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 mien-tras que sí se aprovechará la configuración software del sistema operativo, instalaciones inclui-das, no ocurrirá lo mismo con la de la máquina virtual, debiendo repetirla en cada equipo.


Acceso remoto

El último paso en la configuración de los equipos tendrá como fin habilitar los tres modosde 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 conozcala dirección IP del equipo, el nombre del usuario y su contraseña podrá acceder mediante estemé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 necesariomodificar 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 siguien-te 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 queindicar es la del equipo al que se pretende acceder, al igual que el usuario indicado debe existiren tal equipo.

Por último, para habilitar el acceso remoto mediante VNC en Ubuntu, hay que realizar lossiguientes pasos:

1. Desde el escritorio, ir al apartado Administración, Preferencias y seleccionar Escritorioremoto 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 miescritorio.

3. Activar la casilla Requerir que un usuario introduzca una contraseña y fijarla en el cuadroindicado.

4. Desactivar la opción anterior Debe confirmar cada acceso a este equipo. Si se mantieneasí, 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 programacompatible con él. En sistemas operativos basados en Linux, la aplicación por defecto paraeste tipo de conexiones es Vinagre, en MacOS X también se soporta esa funcionalidad desdeel mismo Finder (el explorador de archivos) en el menú Ir, opción Conectarse al servidor... eintroduciendo en el cuadro de diálogo abierto vnc://direcciónIP. En Windows, en cambio, serequiere de un software adicional para esta funcionalidad. Se recomienda la aplicación gratuitaVNCViewer.


DNS dinámico

Tras configurar el acceso remoto, es necesario que el usuario conozca en todo momento ladirección IP pública de acceso a Internet. Puesto que la red utilizada asigna esa dirección demodo dinámico se debe requerir del uso de un DNS dinámico. Como se diseñó en el capítu-lo 3, la solución utilizada será la ofrecida por No-IP. Para ello, se requiere que el cliente queenvía la dirección IP a los servidores del servicio para actualizar el registro se esté ejecutandocontinuamente 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 lapestañ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 comosigue:

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 alrobo de claves puesto que el archivo está cifrado.

4.1.3. 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ólofalta instalar el software que será el encargado de generar el tráfico P2P y monitorizarlo. Enconcreto serán necesarias 4 aplicaciones para este fin, tanto en sus versiones para Windowscomo 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 yAdministrador).

Clientes P2P

En primer lugar, para los pares P2P, el software que se decidió en el capítulo 3 que se ibaa utilizar sería eMule para los equipos con sistema operativo Windows y aMule para entornosbasados en Linux. Para ello, en las máquinas virtuales se instalará la aplicación, en su últimaversión, descargada de la web del proyecto eMule4. El proceso de instalación consistirá en la

4http://www.emule-project.net/


ejecución del archivo descargado y completar el asistente que presenta. Por otra parte, en lossistemas 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 unacarpeta donde se deben incluir dos archivos: el ejecutable (distinto en función del tipo de sistemaoperativo) y el archivo de configuración donkey.ini. En este último archivo, los parámetros aconfigurar son:

Flag Descripción Pordefecto Utilizado

nameNombre del servidor que será

mostrado en la lista de servidores delos clientes.

Servidor de prueba

descDescripción que será mostrada en la

lista de servidores de los clientes.

Servidor que seintentará configurar

para que funcione bien.

console

Si el valor es true, se podrán ejecutarcomandos en la interfaz de línea de

comandos y las salidas seránreflejadas en el mismo lugar.

true true

maxClientsNúmero máximo de clientes

admitidos en el servidor.6000 200

threads

Número de hebras creadas paramanejar las peticiones de los clientes.

Se recomienda tener 5 cada 100clientes.

5 10

public

Si el valor es true, el servidor secomunicará con otros servidores que

conozca a su alrededor. Estosservidores propagarán su consulta a

los clientes conectados a ellos.

false false

verboseSi el valor es true, se mostrará más

información en el archivo de registro(log).

false true


Flag Descripción Pordefecto Utilizado

welcome[#]

Mensajes de bienvenida que enviaráel servidor al cliente cuando éste sehaya conectado. El símbolo # puedeser cualquier número, sabiendo que

cada uno, comenzando por el cero, esuna línea. Normalmente, aparecerán

en el registro del mismo.

Un texto cualquiera debienvenida.

tableSize

Tamaño de la tabla para guardar lainformación de los archivos que se

comparten por parte de los pares. Suvalor debe ser un número primo.

2333 7001

thisIPEs la dirección IP de este servidor.

Solo es necesario si el mecanimos dedeterminación de la dirección IP falla.

La dirección IP delservidor.

logFileSi el valor es true, la salida delservidor será almacenada en unarchivo de registro llamado log.

false No utilizado

portPuerto po el cual el servidor recibe las

conexiones.4661 No utilizado

seedIP

Dirección IP del servidor semilla. Esla dirección de un servidor al que se

puede conectar para obtener la lista deotros servidores y unirse a la redeDonkey. Esta opción ralentiza la

velocidad del servidor.

No utilizado

seedPortEl puerto del servidor semilla

explicado en la descripción delparámetro anterior.

4661 No utilizado

typePosibles valores: key (para buscar

archivos por palabras clave) osubstring (búsqueda por subcadenas).

key No utilizado

maxVersionLa máxima versión con la que el

servidor permite conectarse.1000 No utilizado

minVersionLa mínima versión compatible con

este servidor.39 60

Una vez realizada la configuración, para ejecutar el servidor bastará con invocarlo desde unintérprete de línea de comandos.


Wireshark

El siguiente software a instalar es el paquete Wireshark. Su instalación en Windows es prác-ticamente igual que la de eMule. Se deberá acceder a la página web oficial del producto5 ydescargar el instalador del programa para este sistema operativo. Después se ejecutará el archivodescargado y se procederá a seguir los pasos indicados en el asistente. Tras finalizar el asistenteya estará instalada la aplicación. Aún así, en Windows, se requieren unos pasos extra para poderejecutar sus comandos desde la consola sin tener que indicar continuamente el directorio dondeestá instalado. Ésto es, se va a modificar la variable de estado PATH. Para ello hay que dirigirseal icono de Mi PC y hacer clic en él con el botón derecho del ratón. En el menú contextual, seelegirá la opción Propiedades. A continuación, en la ventana abierta, hay que escoger la pestañaOpciones avanzadas donde se pulsará el botón Variables de entorno. En la nueva sub-ventanaque se abrirá, en la lista inferior, se modicará la variable Path, añadiendo al final del valor que yaposee un punto y coma seguido de la ruta absoluta del directorio donde Wireshark se encuentrainstalado.

En Ubuntu, la instalación consistirá en la ejecución del comando que instala los paqueteswireshark (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 paqueteWireshark, ya configurado, y, como mínimo, del entorno de ejecución de Java (JRE). Esta segun-da 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óndel 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 oficialde esta tecnología6 y descargar el instalador para ese tipo de sistemas operativos. Tras ello, seejecutará el archivo y se completará el proceso de instalación siguiendo las indicaciones delasistente.

Una vez se cumplen todos los requisitos para el correcto funcionamiento del software degestión de monitorización distribuida, se procederá a su instalación. Ésta consistirá, al igual queen el caso del servidor de eDonkey, en copiar el directorio que contiene ambos programas aldestino deseado por el usuario.

5http://www.wireshark.org/6http://www.java.com/


Tras este proceso, se podrá ejecutar el software Adminstrador mediante la ejecución en uninté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 ad-ministrador:

sudo java -jar directorioDeInstalación/Sonda.jar

4.2. Implementación del sistema de gestión de monitorización dis-tribuida

Antes de su instalación, explicada en la sección anterior, se deberá realizar la implementa-ción de este sistema. Para ello, se va a explicar en este apartado el algoritmo y la estructuraciónde ambos módulos. Su desarrollo se ha realizado utilizando el lenguaje de programación Javadebido a que permite su ejecución en varias plataformas distintas sin la necesidad de distinguiren la fase de implementación entre cada una de ellas. También se ha escogido este entorno valo-rando los conocimientos previos y experiencia del alumno en esta tecnología. El código fuentese 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 delmódulo Sonda mientras que, en la segunda se comentará la realizada para el módulo Adminis-trador.

4.2.1. Implementación del módulo Sonda

Este módulo hará uso de un archivo de configuración llamado sonda.conf. En él se almace-nará el parámetro puerto, el cual indica el puerto de escucha que utilizará el socket que acepta laspeticiones de conexión de los administradores que pretenden acceder a ella. Su interfaz gráficamuestra en la Figura 4.2.

La implementación del módulo Sonda se ha realizado mediante siete clases que se enume-rará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 mainjunto con otras funciones que permiten acceder a los objetos principales creados en lamisma (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 necesariospara mostrar la información actualizada en ella, a la vez que otras funciones para accedera las opción marcada por el usuario en la ventana mostrada sobre la interfaz de red que sedebe utilizar para capturar el tráfico.

SondaAboutBox.java: Clase definida exclusivamente para mostrar el diálogo de infor-mación Acerca de...


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 aten-der las peticiones de conexión y gestionar los administradores conectados y las tareasprogramadas.

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 comoadministradores 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 igualque la clase anterior, se crearán tantos objetos Tarea como tareas haya programadas en lasonda.

Mensajes.java: Es una clase muy simple donde se definen de forma estática los mensajesque forman parte del protocolo de aplicación utilizado. Está dividida en dos subclases queidentifican quién es el emisor de cada uno de ellos.

Una vez definidas las clases utilizadas, se procederá a identificar los principales bloques deejecución de este módulo. Éstos son la inicialización del programa, la aceptación de peticionesde los administradores y la gestión y ejecución de tareas. A continuación se describirán losprocedimientos 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 deSondaView.


Durante la creación del objeto Sonda se carga el archivo de configuración sonda.conf, elcual incluye el parámetro puerto. Éste parámetro indica el puerto que debe abrirse a la esperade peticiones de conexión por parte de los administradores. Si se produce un error de lecturadel archivo, se creará uno nuevo con los valores predeterminados puerto:14015. Tras ésto, seinicializan la lista de tareas y la de administradores y se comienza a atender las peticiones deconexión mediante un objeto de la clase ServerSocket. Por último, se ejecuta una hebra encargadade comprobar periódicamente el estado de los administradores conectados para borrarlos en casode desconexión.

Por otro lado, durante la creación del objeto SondaView se realiza la configuración de todoslos componentes pertenecientes a la ventana mostrada. Para ello, entre otras acciones, se debeobtener la lista de interfaces de red disponibles para la captura de tráfico. Ésto se consiguemediante la ejecución del comando

tshark -D

y la lectura de su respuesta. Por último, se inician otras dos hebras encargadas de actualizarlos datos mostrados en la ventana informativa. El fin de una es llevar el control del número deadministradores 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 paraatender las peticiones de conexión de los administradores. Por ello, cuando se recibe una, esnecesario 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 unnuevo 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 defini-dos 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 admi-nistrador remoto.

Entre las peticiones que es capaz de atender se encuentran los mensajes destinados a calcularla latencia y la diferencia de relojes entre los equipos, el de despedida y cierre de conexión ylos de creación, cancelación y recolección de tareas. En todos ellos, las acciones realizadasconsisten en la ejecución de la acción requerida y su respuesta a través del mismo canal decomunicación existente, excepto en el caso de recolección de la tarea, en el cual, para el envíodel archivo de la captura de tráfico, se debe establecer una nueva conexión al puerto 14020 deladministrador. Esta decisión en la implementación ha sido tomada tras comprobar que, entre eltráfico capturado puede haber mensajes de control pertenecientes al protocolo de este sistema ypuede 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


sin haber recibido antes una orden desde el administrador, el momento de la creación de lastareas 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 peti-ción de una nueva tarea, la Sonda creará un nuevo objeto Tarea, el cual, durante su creaciónestablecerá 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 ja-va.util.Timer encargada de ejecutar la tarea cuando sea la hora de inicio. El comando que seejecutará 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 etiquetaidentificativa única asignada a la tarea y seg el tiempo en segundos hasta el final de la ejecuciónde 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 alcomienzo de la captura.

-n Desactiva la resolución de nombres (genera menostrá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.

4.2.2. Implementación del módulo Administrador

Este módulo permitirá al usuario acceder al control de las sondas de modo que pueda encar-garles 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 sondasque él elija, mostrándole, al final del proceso, un resultado en el que estén fusionadas todas lascapturas realizadas de modo que se pueda obtener un control del tráfico que ha circulado por lared 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 secrean 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 dela aplicación. En ella estarán reflejadas las opciones e información de gestión de las sondasy la capacidad de ver y crear tareas.


(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.


AdministradorAboutBox.java: Clase en la que se ha diseñado el cuadro de diálogo re-ferente al Acerca de... de la aplicación.

TareasBox.java: Ventana secundaria en la que se permitirá al usuario realizar la gestiónde las tareas programadas de modo que, en ella, podrá ver su información más relevante,borrarlas o abrirlas cuando todo el proceso de recolecta haya finalizado.

TareaBox.java: Clase que define la ventana que mostrará el resultado final de las capturascuando se hayan recolectado y fusionado. Añade también la función de filtrado para versolamente el tráfico P2P y un botón para abrir la captura en Wireshark donde se podránejecutar más acciones con ella.

Admin.java: Se trata de la clase que ejecuta el corazón del administrador. En ella serealiza la gestión de las sondas y las tareas. Dispone de una lista con objetos de las clasesque representan a cada una de ellas y funciones para trabajar con ellas.

Sonda.java: Principalmente incluye el modo de comunicación para indicar órdenes a lassondas, aunque también implementa el método para la obtención de la diferencia de relojesy el RTT.

Tarea.java: Permite crear objetos Tarea con los que llevar el control de las sondas impli-cadas en ella, sus horarios de inicio y fin y demás datos de estado. También se encarga degestionar la recolecta de sí misma.

Mensajes.java: Al igual que en el módulo Sonda, define los mensajes diseñados para lautilización en el protocolo de la aplicación. Debe ser idéntico a su homónimo en el otromódulo.

Una vez definidas las clases utilizadas en esta implementación, se continuará la subsección conla descripción de los bloques de ejecución principales del módulo Administrador. Se dividiránen tres: la inicialización de la aplicación, la gestión de las sondas y su control de los relojes y lagestión de tareas y recursos.

Inicialización

Al igual que en el módulo sonda, al ejecutar la aplicación se realiza un proceso de confi-guración inicial. Ésta comienza con la creación de el objeto Admin, el cual, en su contructor,inicia una nueva lista de tareas vacía para esta sesión y carga la de sondas existentes en su últimaejecución y almacenadas en el fichero sondas.list. Si el archivo no existe, se crea uno nuevo yvacío.

A continuación, se invoca y muestra el objeto AdministradorView donde se generan los ele-mentos de la ventana principal de la aplicación y se inicia una hebra encargada de actualizarperiódicamente los datos mostrados de la sonda seleccionada en la lista.


Gestión de las sondas

Tras el proceso de inicialización, el usuario ya podrá realizar la gestión de las sondas en laventana principal mostrada. Las acciones permitidas en este aspecto consisten en añadir o borrarsondas de la lista y conectarse a ellas. Las dos primeras también actualizan el archivo que lasalmacena sobre la marcha. La última opción, por otro lado, además de conectarse a la sondaremota, incluye la obtención de la diferencia entre los relojes de los dos extremos para lo quees necesario también el cálculo del retardo que introduce la red a los paquetes. Ésto se realizamediante el método diseñado en el capítulo 3 en el que el administrador envía un mensaje consu marca de tiempo, MTA1, el cual es respondido por la sonda, incluyendo el MTA1 recibido ysu propia marca de tiempo, MTS. Tras recibir la respuesta, el administrador obtiene una nuevamarca de tiempo MTA2, utilizada para obtener el RTT de la red mediante la operación restaRT T = MTA2−MTA1. A continuación, aplicando la suposición de que la red es simétrica, seafirma que el retardo introducido en un trayecto es igual a la mitad del RTT: Retardoestimado =RT T

2 . Por último, al calcular la diferencia de MTS y MTA1, se obtiene un valor igual a la sumade diferencia de relojes y el retardo MT S−MTA1 = Di f .Relo jes+Retardo. De este modo, si aese valor se le resta la estimación del retardo (la mitad del RTT), se obtendrá aproximadamentela diferencia de los relojes: MT S−MTA1− RT T

2 = Di f .Relo jes+Retardo−Retardoestimado ≈Di f .Relo jes

Ahora, ¿cómo se obtienen las marcas de tiempo? En la clase System de Java existen dos mo-dos de obtener el tiempo con diferentes unidades cada uno: System.currentTimeMillis() devuelveel tiempo actual expresado en los milisegundos que han pasado desde las 12 de la noche del 1 deenero de 1970, mientras que System.nanoTime() ofrece una medida de tiempo en nanosegundos.Lo más apropiado sería utilizar la segunda puesto que, con ella, en un principio, se obtendría ma-yor precisión. El problema que lo impide es que la muestra respecto a la que está dado el tiempodevuelto por esta función es arbitraria, por lo que, tal como indica en la documentación de Java,es un buen recurso para comparar tiempos de forma local, pero no entre varios ordenadores. Portanto, la sensibilidad de la medida realizada se limita a la unidad de milisegundos.

Por último, hay que recalcar que cada sonda de la lista es idenficada como un objeto Sondaperteneciente a la lista del administrador en la clase Admin.

Gestión de las tareas

El fin de este módulo es poder programar tareas a las sondas para, al final del proceso dispo-ner de una captura de la red conjunta. Por ello, este bloque de gestión de tareas es muy impor-tante. En él se deben ofrecer las opciones de creación, monitorización de su estado, cancelación,recopilación y acceso al resultado final. Todas ellas serán explicadas a continuación:

En primer lugar, la creación de una nueva tarea comenzará cuando el usuario accione elbotón para tal fin situado en la ventana principal e introduzca las horas de inicio y fin. Entoncesse producirá el envío de la orden de creación de una tarea a las sondas seleccionadas de la lista enel momento de la pulsación del botón. En el envío también se especifica la etiqueta identificativaasignada a la tarea junto con los horarios de inicio y fin de la misma, corregidos aplicando ladiferencia de relojes. La creación de la etiqueta identifcativa asignada se genera, inicialmente,a partir de la unión del nombre del equipo en la red y una marca de tiempo. Por otra parte, el


administrador programa la ejecución de la recolección de las capturas para la hora de fin más unmargen de cinco segundos donde se le da tiempo a los otros equipos a que cierren sus archivosde captura.

El estado de la ejecución de la tarea creada se podrá ver en la tabla presentada en la ventanade gestión de tareas, a la cual se puede acceder mediante la opción “Tareas” en la ventanaprincipal. Desde ésta, mientras la tarea no ha llegado a su comienzo, se podrá cancelar pulsandoel botón “Borrar”. Esta acción se llevará a cabo mediante el envío de un mensaje de cancelaciónde la tarea a todas las sondas implicadas. Por contra, si la tarea ya ha dado comienzo pero aún noha terminado, no estará disponible esa acción y, si ya ha finalizado el proceso, el botón servirápara borrar el archivo de captura.

En cuanto a la recopilación de los ficheros obtenidos de la captura en cada sonda, se ejecutaráautomáticamente cuando llegue el momento programado en la creación de la tarea. El envío delos ficheros se realizará de manera secuencial y los archivos recibidos serán almacenados en undirectorio nombrado igual que la etiqueta identificativa de la tarea. Si, por cualquier razón, daerror y no obtiene ninguna captura, se vuelve a ejecutar una vez más. En cambio, cuando sedisponga de todos los ficheros, se realizará la fusión de los mismos mediante el comando:

mergecap -w archivoDestino.cap archivo1.cap archivo2.cap ...

Por último, para no malgastar el uso del disco duro, tras la ejecución de la fusión de los archivos,se borrará el directorio donde se almacenaron las partes.

En cuanto al acceso al resultado final, en la ventana de gestión de tareas, se habilitará elbotón “Abrir” en el momento en el que se compruebe que el archivo está disponible. Al accio-narlo, se muestra otra ventana formada por un panel donde mostrar el tráfico capturado, una listadesplegable donde elegir si mostrar todo el tráfico o sólo el de tipo P2P y un botón que permitaabrir ese fichero de captura con la aplicación Wireshark. Para generar el texto a mostrar en elpanel de tráfico, se requiere del comando

tshark -r archivoCaptura.cap -n [-R “edonkey||bittorrent”]

con archivoCaptura.cap, el archivo que contiene la captura de tráfico. Lo escrito entre corche-tes indica el añadido que hay que adjuntar si se desea utilizar el filtro P2P del que dispone laaplicación.

Por otra parte, para abrir el archivo en Wireshark, se hace uso de la instrucción:

wireshark -r archivoCaptura.cap

para Ubuntu y Windows. En cambio, para MacOS, es necesario ejecutar:

open archivoCaptura.cap -a /Applications/Wireshark.app

suponiendo que la aplicación Wireshark se encuentra instalada en esa ruta.Gracias a la apertura de la captura con este último programa, se permiten realizar muchas

más opciones y trabajo sobre él como son mejores opciones de filtrado y la extracción de esta-dísticas.

Capítulo 5

Pruebas

A continuación se comprobará el correcto funcionamiento del entorno implementado enel capítulo anterior. Para ello se diseñará una batería de pruebas que deben ser completadasde manera exitosa. Éstas serán realizadas en el siguiente orden: en primer lugar se procederá aprobar la correcta configuración del laboratorio, mediante la comprobación de la conectividad enlas dos redes, el funcionamiento de la red eMule y la disponibilidad de los diferentes métodosde acceso remoto. Más tarde, se analizará el comportamiento del sistema de monitorizacióndistribuida bajo diferentes escenarios, englobando conexiones locales, en la red controlada y laexterna, con uno o varias sondas y administradores.

5.1. Pruebas del laboratorio

En esta sección se realizarán las pruebas necesarias para comprobar el correcto estado delas dos redes implementadas y la configuración de los equipos. En primer lugar se comprobarála conectividad de los equipos físicos y máquinas virtuales en la red interna y la de acceso aInternet para, más tarde analizar el funcionamiento de la red eMule y los diferentes tipos deaccesos remotos configurados.

5.1.1. Pruebas de conectividad en la red aislada

Con las siguientes pruebas se pretenderá comprobar el correcto estado de la red aislada.Para ello se realizarán una serie de pings entre los equipos, tanto físicos como virtuales. Puestoque la ejecución de un ping se toma por correcta cuando un equipo envía su mensaje ICMPEcho Request y es respondido por el destino del mismo, se comprueba así que la conectividades correcta en ambos sentidos, por lo que no será necesario ejecutar el comando en todos losordenadores.

El requisito inicial para la realización de estas pruebas es tener todos los equipos encendidosy corriendo sus máquinas virtuales.

69

CAPÍTULO 5. PRUEBAS 70

Desde un equipo físico: ping a los demás equipos físicos

Descripción: Con uno de los equipos físicos, desde su sistema operativo anfitrión, abrir unaterminal y ejecutar el comando ping seguido del nombre del equipo destino tres veces, una porcada uno de los equipos físicos existentes en la red: super, filemon y mortadelo.

Resultado: El resultado de esta prueba ha resultado ser el esperado. Todos los pings realizadosdesde el equipo utilizado, super, se han ejecutado correctamente, mostrando un retardo en la redde, en torno a 0.300 ms.

Desde un equipo físico: ping a los demás equipos virtuales

Descripción: Esta prueba se realizará del mismo modo que la anterior, con la diferencia de quelos destinos serán los equipos emulados en las máquinas virtuales, es decir: superxp, filemonxp,moradeloxp y mortadelodisfrazao.

Resultado: En este caso, también se recibieron correctamente las respuestas a los pings reali-zados desde el equipo que se utilizó, filemon.

Desde una máquina virtual: ping a los demás equipos físicos

Descripción: Se repetirá el proceso de la primera prueba, pero esta vez desde el commandprompt de Windows XP ejecutándose en una máquina virtual.

Resultado: Efectivamente, el equipo probado, superxp, ha sido capaz de completar todos lospings realizados a los sistemas operativos anfitriones: super, filemon y mortadelo.

Desde una máquina virtual: ping a los demás equipos virtuales

Descripción: Realización de pings con destinatarios todos los equipos emulados en las má-quinas virtuales: superxp, filemonxp, moradeloxp y mortadelodisfrazao.

Resultado: Todos los pings ejecutados desde el equipo seleccionado, filemonxp, han dado losresultados satisfactorios que se esperaban.

5.1.2. Pruebas de acceso a Internet

En esta subsección se realizarán las pruebas para comprobar el funcionamiento del acceso aInternet. El método utilizado será la ejecución en los equipos de un ping a una dirección externade Internet. Este método sólo sirve para comprobar si la conectividad es correcta pero no puededemostrar que no lo sea. La razón de semejante afirmación se basa en que algunos destinos enInternet, pueden tener bloqueados ciertos puertos, por lo que, si se intenta acceder a ellos, elresultado que se mostrará es que no pueden ser alcanzados, sin especificar si es por un problemade conexión o por configuración del administrador del equipo.


Con todo esto, en el momento en que se realice un ping con éxito a cualquier direcciónexterna a la red, se dará por válida la conexión.

Desde un equipo físico: ping a una dirección de Internet

Descripción: En primer lugar se realizará el ping desde el sistema operativo anfitrión. Paraello se ejecutará el siguiente comando en una terminal:

ping alejandrofh.es

Resultado: Durante la ejecución de la instrucción se resolvió la dirección IP asignada a esadirección canónica (lo que ya indica que está correctamente conectado a Internet) y, a continua-ción, se envió la petición de eco ICMP que fue respondida correctamente.

Desde una máquina virtual: ping a una dirección de Internet

Descripción: Se pretende realizar la misma comprobación, pero desde un sistema operativohuésped. En primer lugar se comprobará que es necesaria la configuración indicada en el capítulo4 por lo que se ejecutará el mismo comando que en el escenario anterior y se podrá ver que noes alcanzable. Después se establecerá la configuración necesaria para proporcionarle acceso aInternet a las máquinas virtuales como se indica en esta misma memoria y se repetirá el comandoejecutado.

Resultado: Tal y como cabía esperar, en el primer intento se mostraba el mensaje:

La solicitud de ping no pudo encontrar el host alejandrofh.es. Compruebe elnombre y vuelva a intentarlo.

En cambio, tras la segunda prueba con todo correctamente configurado, se recibieron las res-puestas al ping correctamente.

5.1.3. Pruebas eMule

Para comprobar el correcto funcionamiento de la red eMule configurada que generará eltráfico P2P a analizar, se realizará una batería de pruebas que constará de los siguientes pasos:en primer lugar, los clientes se conectarán al servidor eDonkey, a continuación, uno de elloscompartirá un archivo que deberá aparecer en las búsquedas realizadas en los otros. Por último,se descargará ese fichero.

Conectar clientes al servidor de eDonkey

Descripción: Lo primero en realizar será la comprobación de los parámetros fijados, especial-mente thisIP, en el archivo donkey.ini, en el cual se almacena la configuración del servidor. Trasésto, se iniciará desde una terminal o un intérprete de comandos el archivo ejecutable para elmismo.


Más tarde se ejecutarán los clientes en los demás equipos, procurando la utilización tanto deaMule en Linux como de eMule en Windows, y se accederá al apartado donde se puede indicar elservidor al que se pretende conectar. Se seleccionará el recientemente ejecutado para conectarse(si no aparece en la lista, habrá que introducirlo mediante su dirección IP y el puerto de escucha).Entonces se comprobará que la conexión se realizó correctamente. Además, se debe comprobareste funcionamiento para ambas redes de acceso.

Resultado: La conexión mediante la red de acceso a Internet se realizó sin problemas en todoslos clientes, mientras que la establecida a través de la red controlada presentó un problema: losclientes aMule, los eMule no pusieron impedimento, no permitían añadir un servidor cuya direc-ción IP pertenecía al rango de las privadas. Ésto se solventó accediendo al apartado de seguridaden las preferencias de la aplicación y desactivando el bloqueo de éste tipo de direcciones IP.

Compartir un fichero y que aparezca en las búsquedas

Descripción: Una vez que los clientes han establecido la conexión, se añadirá en uno de ellosun archivo para compartir y se buscará en los demás para comprobar que se muestra la opciónde descarga y que el descubrimiento de los archivos funciona correctamente.

Resultado: Inmediatamente después de añadir el fichero a la lista de recursos compartidos,se realizó una búsqueda sin resultados. Tras unos minutos intentándolo sí acabó mostrándosepor lo que se supondrá que este retardo es debido a la frecuencia de actualización de la tabla dearchivos en el servidor.

También se realizó una nueva prueba desconectando el cliente que compartía el fichero yvolviéndolo a conectar. Mediante éste método se tardó lo mismo en descubrir el archivo. Sesupondrá, por tanto, que el servidor almacena el estado del historial de clientes de modo que,si éstos sufren un corte de conexión, al volver no deban intercambiar todos los mensajes dedescubrimiento de nuevo, sino que se realizará en función de la mencionada frecuencia de ac-tualización.

Transmitir el fichero

Descripción: Tras localizar el fichero buscado en la prueba anterior, realizar la descarga delmismo y comprobar que se realiza correctamente.

Resultado: Ningún problema en este aspecto. Todo funcionó correctamente.

5.1.4. Pruebas de accesibilidad

En cuanto a pruebas de la implementación del laboratorio se refiere, las últimas que se rea-lizarán serán las que comprueben el correcto funcionamiento de los tres métodos de accesoremoto. Para ello se accederá a los equipos desde uno externo al laboratorio y a la red, conecta-do a Internet. El ordenador utilizado es un portátil conectado a la red inalámbrica eduroam (la


configuración es la misma que para cviugr-v2, aunque puede variar en función del sistema ope-rativo utilizado por lo que se recomienda utilizar el tutorial elaborado por el Centro de Serviciosde Informática y Redes de Comunicaciones de la Universidad de Granada).

Los accesos se realizarán indicando como direcciones destino las creadas en el servicio No-IP para este fin. De este modo también se comprobará el correcto desempeño de la funcionalidadDNS dinámico.

Acceso mediante SSH

Descripción: Desde una terminal se ejecutará el comando:

ssh usuario@direcciónIP

Después se introducirá la contraseña de acceso de ese usuario y se comprobará que, efectivamen-te, es el equipo al que se deseaba acceder mediante la creación de un archivo de texto que listesus interfaces de red y su posterior visualización desde el equipo accedido mediante su controllocal en el laboratorio. Para la creación del archivo de texto mediante la interfaz de comandos,se ejecutará la instrucción:

ifconfig > archivo.txt

Resultado: Se pudo comprobar la correcta creación del fichero, por lo que se puede afirmarque el acceso mediante SSH también funcionó.

Acceso mediante X-Window

Descripción: Para comprobar este tipo de acceso a la interfaz gráfica mediante SSH, se debeejecutar el siguiente comando desde el equipo externo al laboratorio:

ssh -X usuario@direcciónIP

Esta vez, en lugar de crear un archivo de texto mediante la interfaz de comandos, se ejecutará uneditor de textos y se creará de esa manera. Así pues, el comando ejecutado es:

gedit archivo.txt

Cuando se muestre la aplicación abierta en el equipo desde el que se está accediendo, se escribiráun texto cualquiera para luego corroborar que es a ese equipo al que se ha accedido. Por otraparte, se comprobará que en el equipo accedido no se muestra la ventana del editor de textosabierto.

Resultado: Puesto que el archivo de texto se encontraba en el ordenador al que se había ac-cedido y se ha podido ver el programa gedit con su interfaz gráfica. Se da como existosa estaprueba.

Por otra parte, se confirma lo indicado en el capítulo 3: este tipo de acceso remoto creauna sesión nueva para el que accede, de modo que un usuario local u otro remoto no podránpercatarse de la existencia de otro usuario.


Acceso mediante VNC

Descripción: Por último, se realizará una prueba de acceso mediante VNC. Para ello es ne-cesario un cliente o visor de escritorios remotos VNC como vinagre en Linux o VNCViewer enWindows. La prueba se realizará desde la aplicación nativa incorporada en MacOS X, sistemaoperativo corriendo en el equipo desde el que se accede a los del laboratorio. Para iniciar elacceso hay que dirigirse a la opción Conectarse al servidor... del menú Ir dentro de la aplicaciónFinder (el explorador de archivos de este sistema operativo). En el cuadro de diálogo habrá queindicar la URI que incluya el protocolo y la dirección del destino, por ejemplo:

vnc://direcciónIP

Tras ésto, se introducirá la contraseña asociada a esta funcionalidad (que no la de usuario) y, conello se habrá accedido al escritorio remoto. Se comprobará que las ventanas vistas mediante estemétodo son las mismas que las mostradas directamente en el monitor conectado al equipo.

Resultado: El resultado de esta prueba ha sido el esperado, por lo que se puede afirmar que laconexión está realizada de una manera correcta.

5.1.5. Tabla resumen de las pruebas

Aspecto probado Pruebas realizadasConectividad en la red aislada ping desde un equipo físico a los demás.

ping desde un equipo físico a los virtuales.ping desde una máquina virtual a los equipos físicos.ping desde una máquina virtual a las demás.

Acceso a Internet ping desde un equipo físico a una dirección de Internet.ping desde una máquina virtual a una dirección de Internet.

eMule Conectar clientes al servidor de eDonkey.Compartir fichero y que aparezca en las búsquedas.Transmitir el fichero.

Accesibilidad Acceso mediante SSHAcceso mediante X-WindowAcceso mediante VNC

5.2. Pruebas del sistema de gestión de monitorización distribuida

Tras comprobar que la implementación del laboratorio responde como debería, se procederáahora a comprobar el funcionamiento del sistema de gestión de monitorización distribuida desa-rrollado. Para ello se realizarán unas pruebas destinadas a comprobar que el proceso de conexiónes correcto y, más tarde, se hará lo propio con las funciones de gestión de las tareas. En todas laspruebas que se van a realizar, se tomará como estado inicial, aquel en el que haya terminado larealización de la prueba anterior (si ha sido exitosa).


5.2.1. Pruebas de conexión

En primer lugar se comprobará si los equipos son capaces de realizar el proceso de conexión.Para ello la prueba sólo requerirá un estado inicial con todos los equipos encendidos.

Conexión a localhost

Descripción: Tomando como equipo en el que trabajar a el super, se iniciará el módulo Sondacon derechos de administración

sudo java -jar Sonda.jar

y el módulo Administrador en el entorno de usuario

java -jar MRDv2.jar

Entonces, en la segunda aplicación, se añadirá una sonda cuya dirección IP y puerto son 127.0.0.1y 14015, respectivamente. A continuación se accionará el botón Conectar y se esperará hasta verla indicación de estado como Conectado.

Resultado: Se realizó correctamente y de un modo bastante rápido.

Conexión a un equipo de la red controlada

Descripción: Con el administrador ejecutado en el super, sólo falta iniciar otro módulo Sonda,pero esta vez en un equipo distinto al anterior y perteneciente a la red controlada, en este caso,filemon. Al igual que en la prueba anterior, desde el administrador iniciado en el super se añadela sonda indicando la dirección IP y el puerto de éste, filemon:14015 y se pulsa Conectar. Mástarde se comprueba si la indicación de estado los identifica como conectados.

Resultado: Al igual que la prueba anterior, se obtuvo el resultado esperado y la conexión seestableció igual de rápido.

Conexión a un equipo de la red externa

Descripción: Se repite todo el proceso pero con la sonda iniciada en un equipo externo a la redy sin cortafuegos entre medias. Para obtener su dirección IP se ejecutará el comando ifconfig.

Resultado: La conexión se terminó realizando, pero esta vez tardó casi cinco minutos y medio.Ésto es debido a que, puesto que el RTT en esa conexión es de 31ms y se realizan diez mil repeti-ciones para calcular la media de la diferencia de relojes, 0,031segundos×10000repeticiones =310segundos ≈ 5minutos,21segundos.


5.2.2. Pruebas de cálculo de diferencia de relojes

Ahora se comprobará que el resultado de la diferencia entre los relojes, es el correcto. Como,realmente, no se dispone de medios para esta medición, se aplicará un método de confirmaciónaproximada, es decir, se atenderá visualmente para ver qué equipo va adelantado y si es pormucho tiempo (>1 segundo) o el cambio se realiza en décimas o menos.

Sonda en localhost

Descripción: En la ventana del administrador, se obtendrá la diferencia de relojes de la infor-mación presentada para la sonda ejecutada en el mismo equipo y a la que está conectado.

Resultado: En el panel, se indican 0 milisegundos de diferencia entre los relojes, algo total-mente lógico y válido, puesto que se trata del mismo ordenador.

Sonda en un equipo de la red controlada

Descripción: En la ventana del administrador, ejecutándose en el super, se obtendrá la dife-rencia de relojes de éste con la sonda ejecutándose en filemon.

Resultado: Se indican -143 milisegundos y, en la comprobación, se puede ver que el reloj defilemon está retrasado por menos de un segundo.

Sonda en un equipo de la red externa

Descripción: Se realizará lo mismo que en la prueba anterior, con la diferencia de que la sondacon la que se compara ahora, es la ejecutada en el equipo externo.

Resultado: Se marcan -187 milisegundos y, realmente, se parece mucho el comportamiento alde la prueba anterior.

EXTRA: Prueba entre dos equipos con mayor diferencia horaria

Descripción: Se realizará una conexión entre un equipo ejecutando el administrador y otro,retrasado unos 40 segundos, con la sonda iniciada y se comprobará el tiempo marcado.

Resultado: Se calculan -39436 milisegundos, muy cercanos a los 40 segundos.

5.2.3. Pruebas de creación de una tarea

En esta prueba se comprobará si la orden Nueva Tarea funciona correctamente.


Sonda en localhost

Descripción: En la ventana del módulo Administrador se selecciona de la lista la sonda eje-cutada en el mismo equipo y se acciona el botón Nueva Tarea. Se introduce una hora futura deinicio y otra de fin y se comprueba en la sonda que la nueva tarea creada está programada.

Resultado: Todo correcto.

Sonda en un equipo de la red controlada y otra en localhost

Descripción: Se debe realizar la misma prueba que en la anterior, pero seleccionando en lalista a la vez (mediante la tecla Ctrl) la sonda de filemon y la de localhost.

Resultado: Las tareas se crearon correctamente.

Sonda en un equipo de la red externa, otra en un equipo de la red controlada y otra enlocalhost

Descripción: La prueba se realizará de igual modo que la anterior, aunque añadiendo a laselección, la sonda en el equipo exterior.

Resultado: Al igual que en los casos anteriores, las tareas fueron programadas tal y como sehabía pedido.

5.2.4. Pruebas de cancelación de una tarea

Con las tareas anteriores programadas, se realizará una prueba de cancelación de las mismas.Para ello, desde la interfaz gráfica del módulo Administrador, ejecutado en el super, se acciona elbotón Tareas, el cual abrirá una nueva ventana en la que deberían mostrar las tres tareas creadas.

Sonda en localhost

Descripción: En la última ventana abierta, se selecciona la primera tarea de la lista, ya que fuela primera en ser programada, y se escoge la opción Borrar. Ésta debe desaparecer de la lista detareas en el administrador y en la sonda de localhost.

Resultado: Efectivamente, la tarea desaparece de la lista.


Descripción: Se realizarán los mismos pasos que en la anterior, pero con el añadido de que sepodrá comprobar que la tarea ha sido borrada de la sonda en filemon.

Resultado: La tarea es borrada en ambas sondas y desaparece de la lista del administrador.



Descripción: A las acciones de las anteriores se les añade la comprobación en la sonda delequipo externo.

Resultado: De igual forma que en las ejecuciones anteriores, la tarea es borrada de las tressondas asociadas a ella.

5.2.5. Pruebas de recopilación, mezcla y apertura de una tarea

En esta prueba se volverá a crear una tarea y se dejará ejecutar con el fin de conocer si elresultado final del proceso es el esperado. Durante el proceso de captura, se realizarán pingsa las sondas involucradas. En este proceso se recopilarán las diferentes capturas (si las hay) yse realizará la mezcla de las mismas. Más tarde, el usuario accederá a la ventana de gestiónde tareas, seleccionará la creada para esta prueba, cuyo estado debe indicarla como Listo, yse accionará al botón Abrir. Tras ésto, se comprobará el panel donde se muestra el archivo decaptura y, por último, el acceso a Wireshark para analizar esa captura.

Sonda en localhost

Descripción: Se realizará la prueba explicada únicamente para la sonda ejecutada en local-host.

Resultado: Funcionamiento correcto, aunque no tenga mucha lógica este escenario por sí solo,ya que, para realizar una captura de tráfico dentro del mismo equipo, es más cómodo ejecutarladirectamente desde Wireshark.


Descripción: Se repetirá la anterior añadiéndole la sonda de filemon.

Resultado: Al final se pudieron ver los pings recibidos por ambas sondas.


Descripción: Ídem a las anteriores con la salvedad de que también se utilizará la sonda delequipo externo.

Resultado: Todas las sondas fusionadas correctamente y mostrando el tráfico final tanto en laventana implementada para ello, como en Wireshark.


5.2.6. Tabla resumen de las pruebas

Aspecto probado Administrador Sondalocalhost

Conexión super filemonequipo externo

localhostCálculo de diferencia de relojes super filemon

equipo externolocalhost

Creación de una tarea super localhost y filemonlocalhost, filemony equipo externo

localhostCancelación de una tarea super localhost y filemon

localhost, filemony equipo externo

localhostRecopilación, mezcla y apertura de una tarea super localhost y filemon

localhost, filemony equipo externo

Capítulo 6

Conclusiones

En este capítulo se destacarán las conclusiones obtenidas tras la realización de este pro-yecto. Por otra parte, más tarde se propondrán posibles mejoras al entorno de experimentaciónplanteado para que se puedan implementar en trabajo futuro.

6.1. Conclusiones

Durante el transcurso del desarrollo de este proyecto, se han podido extraer las siguientesconclusiones:

1. En primer lugar, se ha entendido que un entorno de experimentación idóneo debe con-templar la posibilidad de uso en entornos controlados y, también, no controlados. Los pri-meros son importantes porque permiten realizar pruebas específicas sobre ciertos aspectoscríticos que se requieran estudiar. En cambio, el estudio en entornos no controlados otorgauna visión más fiable y acorde con situaciones reales.

2. Para los entornos controlados se ha implementado un laboratorio cuya red está aislada.Así el usuario puede introducir únicamente el tráfico que sea de su interés para el estudioy, prácticamente, no presenta ningún tráfico extra que le pueda inducir a confusión en lafase de análisis de las capturas.

3. Por otra parte, para los entornos no controlados, al no pertenecer a una red de acceso co-mún, es necesaria la captura del tráfico de un modo distribuido en el que cada equipo,cuyo tráfico es relevante en el estudio, debe monitorizarlo. Para ello, en este proyecto, seha desarrollado una herramienta que permite gestionar las capturas distribuidas, realizan-do, además, el proceso de recolección de las mismas.

4. En este proyecto también se ha comprendido la importancia del problema de sincroniza-ción de las trazas obtenidas de manera distribuida, puesto que permite mostrar el tráficocapturado de forma coherente y fiel a la realidad. En este aspecto, se llegó a la conclusiónde que es mejor calcular la diferencia de los relojes de los equipos involucrados y tenerlaen cuenta cuando haga falta que sincronizar los relojes de los equipos.

80

CAPÍTULO 6. CONCLUSIONES 81

5. Además, para la obtención de la diferencia de relojes y la gestión de las tareas de mo-nitorización de modo distribuido se ha diseñado un protocolo de comunicación entre lassondas y el administrador de modo que pretende ofrecer estas funciones de gestión conla menor generación de tráfico posible en la red, para, así, no afectar a la calidad de lascapturas realizadas. También, en el diseño de los mensajes intercambiados se ha tenidoen cuenta que éstos no pueden ser confundidos con otros por lo que un mensaje no puedeincluir en su inicio otro que ya estuviera establecido. Es decir, suponiendo la existencia deun mensaje TAREA que realice una función, no puede existir otro como TAREANUEVApuesto que, el receptor del mensaje puede leer solo la primera parte y realizar la opciónincorrecta. En su lugar debería usarse el mensaje NUEVATAREA.

6. Por último, se han realizado pruebas exhaustivas para evaluar si el entorno de experimen-tación implementado es válido para el estudio de tráfico P2P. Los resultados obtenidosconfirman que la implementación realizada se ajusta a las necesidades que permiten eltrabajo en este campo.

6.2. Trabajo futuro

Aunque las conclusiones obtenidas en el apartado anterior muestren que el entorno de expe-rimentación implementado es muy válido para el estudio de tráfico P2P, se pueden proponer unaserie de mejoras para futuras versiones y modificaciones del mismo:

Conexión a Internet de las máquinas virtuales

En cuanto al laboratorio, para las máquinas virtuales, se realizó una configuración que lespermite el acceso a Internet a través de la conexión perteneciente al sistema anfitrión, quien selo proporciona mediante la realización de las funciones de NAT. Esto implica que, pese a que ladirección IP asignada en la red cviugr-v2 es pública, las máquinas virtuales no son directamenteaccesibles desde Internet. Aunque ésto puede presentar ventajas en cuanto a la diversidad delos estudios que se pueden realizar, como se comentó en el capítulo 2, también presenta unalimitación en cuanto a las pruebas de la red Kad desde Windows, en entornos no controlados.

Las soluciones a ésta podrían seguir tres ramas:

La apertura de los puertos deseados en el NAT de modo que se realice el reenvío hacia lamáquina virtual.

La adquisición de una interfaz de red inalámbrica y su configuración exclusiva para lamáquina virtual.

La configuración de la conexión mediante otro puente virtual que enlace una nueva inter-faz con la que accede a Internet.

Sincronización de trazas

En cuanto a la sincronización de las trazas y la gestión de la diferencia entre los relojes, sedeberían realizar varias mejoras de modo que el resultado sea más preciso: En primer lugar, se

CAPÍTULO 6. CONCLUSIONES 82

debe idear un sistema que no suponga el retardo introducido en la red como igual a la mitaddel RTT. Ésto quizá pueda ser posible mediante la obtención de las diferencias MTA1−MT Sy MT S−MTA2 y, a partir de ahí obtener, de algún modo, la relación del retardo por trayectofrente al RTT.

Por otra parte, también debería tenerse en cuenta el tiempo destinado al procesamiento enlos extremos de la conexión. Así, el tiempo transcurrido durante la ejecución de las instruccionespara la formación del mensaje de respuesta y mientras se realizan los cálculos intermedios noafectará a la medida. Este tiempo, actualmente, es despreciable (en torno a 0.5 nanosegundospor instrucción) pero si se mejora la sensibilidad de la aplicación, se debe empezar a tener encuenta.

Además de la búsqueda de mejor precisión, también sería necesario añadir una funcionalidadque redujera el número de muestras de diferencia entre los relojes tomadas para el cálculo de lamedia en función del RTT de la red. Así se podría evitar que el proceso de conexión se conviertaen un proceso tan lento en algunas redes.

Sistema de gestión de monitorización distribuida: Interfaz gráfica y funciones

Si se atiende al sistema de gestión de monitorización distribuida, los siguientes pasos a rea-lizar sobre él, aparte de los indicados anteriormente sobre la sincronización de las trazas, debenimplementar la independencia de la terminal, de modo que las notificaciones sobre posibleserrores durante la ejecución se muestren en la interfaz gráfica.

Por otro lado, deberían mejorarse las funciones Nueva tarea y Borrar tarea. La primerapodría mostrar más opciones y posibles filtros aplicables, mientras que la segunda permitiría lacancelación de una tarea de captura durante su ejecución.

Además, los datos introducidos por el usuario deberán comprobarse antes de ejecutar laacción. De este modo se asegurará el correcto funcionamiento de la aplicación y la seguridadde los equipos, ya que cualquier usuario malintencionado puede utilizar esta vulnerabilidad paraejecutar acciones que puedan afectar al equipo (no hay que olvidarse de que el receptor final dela instrucción es la Sonda que se está ejecutando con privilegios de administrador).

Y por último, en cuanto a la conectividad del sistema, habría que buscar una solución quepermita su utilización cuando están situados tras un NAT y que no requiera la apertura de lospuertos para su reenvío.

entorno de experimentación para generación y...

Documents