Práctica 3: cuestión 2

Cuestión 2:

Rexec. Remote Shell es un servicio presente en un S.O. UNIX con TCP/IP que atiende el puerto TCP 512 en espera de peticiones de ejecución de comandos desde procesos remotos clientes. Utiliza TCP, por lo que trabaja con conexión. Para las prácticas se dispondrá de un programa para MS Windows (rexec.exe) que actúa como cliente. En una sesión de rexec.exe se pide inicialmente un nombre de usuario y password en la máquina servidora, y tras introducir estos, se pueden ejecutar comandos UNIX en dicha máquina. Nos servirá para estudiar una conexión TCP. Dentro de una máquina UNIX, el cliente es un programa de línea de comandos con esta sintaxis básica:

Emplear el programa rexec para ejecutar el comando ‘ls –l’ en la maquina con dirección
172.20.43.232 (Linux2). Utiliza para ello el usuario ‘alumnos’ y la clave ‘alumnos’. Con el monitor de red, analizar y estudiar la secuencia de paquetes TCP intercambiados en el establecimiento de la conexión entre la máquina del alumno y la 172.20.43.232. Utilizar para ello el filtro adecuado (direcciones y protocolos).


Como podemos ver, las tramas que aparecen son tcp y exec.


Comprueba las secuencias de conexión-desconexión TCP. ¿Son similares a las que se
detallan en la figura 6? (Puede que observes que el cliente contesta a una solicitud de SYN
del servidor con un RST. Esto ocurre porque el servidor trata de autentificar al cliente, algo
que no permite el PC).

Comparando las tramas que nos han salido en el monitor de red con la figura anterior, podemos afirmar que se obtiene una estructura similar en ambos casos.

Comprueba el valor de los puertos utilizados. Indica su valor.

Nuestro puerto es 2168.
El puerto del servidor al que nos conectamos es 512, salvo para las tramas de rst, ack, y para la trama syn anterior, que emplean el 113.

Analizar los valores de la ventana de receptor. ¿Cuál es más grande?

El más grande es 65535 que corresponde a la parte de liberar conexión.

Práctica 2: cuestión 2

Cuestión 2. Sobre la fragmentación de datagramas IP

Empleando el programa Monitor de Red de la misma forma que en la situación anterior, ejecutar:

C:\>ping –n 1 –l 2000 172.20.43.230 (…la opción –l especifica la cantidad de datos a enviar)

2.a. Filtra los paquetes en los que esté involucrada tu dirección IP. A continuación, describe el número total de fragmentos correspondientes al datagrama IP lanzado al medio, tanto en la petición de ping como en la respuesta. ¿Cómo están identificados en el Monitor de Red todos estos paquetes (ICMP, IP, HTTP, TCP…)? ¿qué aparece en la columna ‘info” del Monitor de Red?


Aparecen 4 tramas, 2 de petición y 2 de respuesta.


En la columna info aparece:

Echo (ping) requestFragmented IP protocol (proto=ICMP 0x01, off=1480, ID=4ea6)Echo (ping) replyFragmented IP protocol (proto=ICMP 0x01, off=1480, ID=4ea6)

2.b. ¿En cuantos fragmentos se ha “dividido” el datagrama original?

Se ha dividido en dos fragmentos.

2.c. Analiza la cabecera de cada datagrama IP de los paquetes relacionados con el “ping” anterior. Observa el campo “identificación”, “Flags” y “Fragment offset” de los datagramas. ¿Qué valor tienen en estos campos en los datagramas anteriores? Indica en la columna “dirección” si son de petición o respuesta. Muestra los datagramas en el orden de aparición del Monitor de Red.



2.d. ¿Qué ocurre en la visualización de los fragmentos de datagramas si introduces un filtro para ver únicamente paquetes de “icmp” en el Monitor de Red? ¿qué fragmentos visualizas ahora?

Solo las dos tramas que tienen el protocolo ICMP (tanto de petición como de respuesta).

2.e. ¿Para qué se pueden emplear los campos “Identificación”, “Flags” y “Fragment offset” de los datagramas IP?

La identificación se utiliza para saber si los datos pertenecen a un mismo datagrama, es como si le pusiésemos un nombre a todos los pertenecientes al mismo (Datagrama padre).

Los flags se utilizan para saber si un datagrama esta partido e indican el número de esa partición para saber cuantos quedan o si es el último.

Por último el fragment offset, se utiliza para el reensambaldo, ya que indica la posición a patir de la cual deben introducirse los datos de esa trama.

2.f. A continuación, se pretende observar que los datagramas pueden fragmentarse en unidades más pequeñas si tienen que atravesar redes en las que la MTU es menor a la red inicial en la que se lanzaron los paquetes originales. Inicia el Monitor de Red y captura los paquetes IP relacionados con el siguiente comando:
C:\>ping –n 1 –l 1600 10.3.7.0

(antes de contestar debes confirmar que en MSDOS el resultado del ping es correcto: paquetes enviados:1 , paquetes recibidos:1)

Indica el número total de datagramas en la red e identifica si son de petición o de respuesta (dirección):

Práctica 1: cuestión 2

Cuestión 2. Análisis estadístico de una captura de datos

A partir de una conexión y descarga de datos en la red se determinará cierta información que aparece en la misma. En primer lugar se iniciará el monitor de red y se realizarán las siguientes acciones para generar tráfico:

Con el navegador, realiza la descarga del programa PUTTY:
http://tartarus.org/~simon/putty-snapshots/x86/putty.zip

A continuación, una vez paralizada la captura. Con los datos obtenidos debes responder a las siguientes cuestiones:

2.a Calcula el porcentaje de paquetes IP existentes en la captura. (Paquetes IP / tramas totales *100).


El porcentaje de paquetes ip en la captura es: (33/210)*100 = 15,71%

2.b Calcula el porcentaje de paquetes IP enviados por la máquina del alumno.


El porcentaje de paquetes ip enviados son: (17/210)*100 = 8,09%

2.c Calcula el porcentaje de segmentos TCP recibidos por la máquina del alumno.


El porcentaje de segmentos tcp recibidos son: (16/210)*100 = 7,62%

2.d Calcula el porcentaje de paquetes que contengan el protocolo DNS en su interior.


El porcentaje de paquetes que contienen el protocolo DNS son: (2/210)*100 = 0,95%