Práctica 3

Cuestión 1

Udp.exe. Este sencillo programa para MS Windows nos permitirá enviar y recibir paquetes UDP, especificando también su contenido, a un número de puerto y una IP destinos especificados para comprobar el funcionamiento de este protocolo.

1a/ Utilizar el programa udp.exe para realizar un envío de datos al puerto 7 (eco) o al puerto 13 (hora y día) del servidor Linux1 (10.3.7.0). Para ello basta especificar la dirección IP y el puerto del servidor, colocar algún texto en la ventana y pulsar el botón “Envía UDP”. Con el monitor de red, analiza la secuencia de paquetes UDP que se desencadenan cuando se envía como datos una palabra, por ejemplo “hola”. Utiliza el filtro adecuado en el Monitor de Red (direcciones y protocolos).

ENVIO DATOS AL PUERTO 7 echo

ENVIO DATOS AL PUERTO 13 daytime

1b/ Prueba de nuevo udp.exe, pero enviando un texto mucho más grande (sobre 2Kbytes). Esto se puede hacer copiando parte de algún fichero de texto en la ventana de udp.exe. ¿Se produce fragmentación IP de los paquetes UDP? Estudia las longitudes del paquete UDP y las de los paquetes IP que aparecen. Detalla los paquetes (fragmentados o no) que observas en el Monitor (indica el valor del identificador, flags, tamaño, etc…)

En el envio, el mensaje UDP se ha fragmentado en dos mensajes IP FRAGMENT mas un mensaje ECHO REQUEST que contiene la cabecera UDP. Mientras que el mensaje ECHO REPLY, vuelve a nuestra maquina dividida en 6 IP FRAGMENT mas un mensaje ECHO REPLY con cabecera UDP.

• A partir de los datos podemos deducir que la MTU de nuestra subred es de 1500 bytes. Pero el tamaño mínimo de MTU en las subredes que ha atravesado nuestro mensaje es de 500 bytes.

DATAGRAMA	PROTOCOLO	DIRECCIÓN	FLAGS	OFFSET	IDENTIFY
1	ECHO	REQUEST	0×02	0	0×6a53
2	IP	REQUEST	0×02	1480	0×6a53
3	IP	REQUEST	0×00	2960	0×6a53
4	ECHO	REPLY	0×02	0	0×009c
5	IP	REPLY	0×02	480	0×009c
6	IP	REPLY	0×02	960	0×009c
7	IP	REPLY	0×02	1440	0×009c
8	IP	REPLY	0×02	1920	0×009c
9	IP	REPLY	0×02	2400	0×009c
10	IP	REPLY	0×00	2880	0×009c

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: rsh .
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).

2a/ 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).

Figura 6

Estos son los resultados que hemos obtenido:

La parte intermedia no es de fiar y es de esperar que no salga igual que lo que debería salir según la figura 6. Esto es debido a que debido a la aplicación, al navegador o incluso del antivirus o firewall que estemos utilizando, este proceso puede variar en sus pasos intermedios. En este ejemplo podemos ver incluso mensajes [RST] que reinician la conexión.

Sí podemos ver sin embargo que coincide tanto en la parte inicial como en la final. Al inicio nuestra máquina envía un [SYN] y la máquina de destino responde con un [SYN, ACK], respondiendo a su vez nuesttra máquina con un [ACK]. Para acabar la conexión podemos ver que nuestra máquina manda el [FIN] y es respondida por el destino con un [ACK].

2b/ Comprueba el valor de los puertos utilizados. Indica su valor

El puerto local es variable. Comienza a partir de 1024 y a cada aplicación que utilice una conexión le asigna un número creciente. En este caso el valor es de 1367, pero si lo volvieramos a intentar cambiaría. El puerto de servidor, por el contrario, es fijo para cada función. En este caso el valor obtenido es 512 y siempre tomará este valor si repetimos el proceso.

PUERTO LOCAL	PUERTO SERVIDOR
1367	512

2c/ Analiza los valores de la ventana del receptor. ¿Cuál es más grande?

• Win se utiliza para informar del número de bytes que el emisor del paquete es capaz de aceptar al recibir.Este valor depende de la porción que queda libre en su buffer de recepción. Si vale 0 indica que no se van a aceptar datos (aunque si los ACK, RST, FIN…).

win=5840

win=0

Práctica 3. Cuestión 3

Utiliza el programa rexec para ejecutar el comando ‘cat ifconfig.txt’ en el servidor 172.20.43.232 (Linux2). La información recibida es de varios miles de bytes y se recibirá en segmentos TCP de gran tamaño. ¿IP ha fragmentado estos segmentos? ¿Por qué ocurre esto? ¿Cuál es el tamaño de los segmentos TCP?

• IP no fragmenta los segmentos ya que el protocolo TCP impide la fragmentación como medida de seguridad. Para asegurar el correcto funcionamiento, TCP implementa unos segmentos adecuados a la red donde esté trabajando. Calcula el MSS (máximo tamaño de segmento que corresponde a la MTU-20 bytes – 20 bytes [En nuestro caso MTU=1500----->MSS=1460])

Práctica 3. Cuestión 4

Utiliza el programa rexec para ejecutar el comando ‘cat file1.txt’ en el servidor 10.3.7.0. ¿Qué valor de MSS se negocia entre los extremos de la comunicación? ¿Cuál es el tamaño de los segmentos TCP transportados dentro de los paquetes IP? ¿Qué diferencia existe respecto al caso anterior?

A simple vista no parece haber demasiada diferencia con respecto al caso anterior:

Pero si nos fijamos en los valores remarcados con un recuadro verde podemos ver que el valor del MSS es 460. En este caso sí que se han fragmentado los segmentos, ajustándose al tamaño de la subred que debe atravesar.

Práctica 3. Cuestión 5

Realiza una conexión FTP a la máquina de un compañero de clase. ¿Qué obtienes en el Monitor de Red al intentar realizar esta conexión?

• El ordenador se conecta al pc del compañero, pero no recibimos ninguna respuesta TCP del pc conectado. El servicio TCP de los ordenadores están deshabilitados. Nuestra maquina realiza tres intentos de conexión al servicio FTP con el mensaje syn, en las tres ocasiones el pc de destino responde con un mensaje de reset y la conexión se debe volver a realizar

Práctica 3. Cuestión 6

Determinar el número de paquetes UDP que se generan (indicando el formato de los paquetes: cabeceras, etc…), cuando el nivel de transporte envía 1000 bytes de datos en una red Ethernet con MTU de 500 bytes. Hacer lo mismo considerando que el nivel de transporte utilizado fuera TCP.

RESULTADO TEÓRICO

UDP	20	8	472
Ip fragment	20	480
Ip fragment	20	48

RESULTADO PRÁCTICO

Como podemos ver en la imagen, el resultado práctico coincide con lo que hemos calculado. Hemos remarcado en la imagen la longitud del último de los tres paquetes, 48 bytes.

Práctica 3. Cuestión 7

En base a la topología que se muestra a continuación:

Considerando que todos los equipos presentes en dicha topología cumplen la RFC 1191. Determina el número de segmentos que se generan al mandar un paquete TCP con 1500 bytes de datos desde la máquina ‘A’ a la máquina ‘E’:
a. Número, tipo y código de paquetes ICMP.

Se genera un mensaje de error ICMP

TIPO	3(Destino inaccesible)
CODIGO	4 (Se necesita fragmentación)
NUEVA MTU	500

b. Indica la MTU del camino completo.

• La MTU será la menor de las MTU del camino recorrido, segun marca la norma RFC 1191. Con anterioriodidad a la aparición de esta norma, se negociaba el tamaño de MSS entre la MTU de la red del emisor y la MTU de la red del destino lo que podría provocar errores si los datos atravesasen redes intermedias con MTU menores. Con la utilización de la norma, el emisor envia dos o tres paquetes tcp, investigando las MTU intermedias. Si se reciben mensajes de error ICMP se cambiará la forma de actuación respecto al tamaño futuro de los paquetes TCP. En este caso, tendremos una MTU=500

c. Una vez determinada la MTU del camino, mostrar la longitud total de cada paquete TCP construido en la fragmentación al mandar un paquete TCP original con 1500 bytes de datos. Indicar la estructura (cabeceras incluidas) de la trama Ethernet en la que se encapsulan los paquetes.

tcp	20	20	460
tcp	20	20	460
tcp	20	20	460
tcp	20	20	120