Resumen de las prácticas: ¿Qué hemos aprendido sobre las redes?

Ahora que el curso llega a su fin, no estaría de más realizar un breve repaso para recordar todo lo que hemos aprendido en las prácticas de la asignatura Redes de Ordenadores. En cada una de ellas el conocimiento que adquirimos fue:

• Práctica 1

Esta primera práctica nos permitió establecer nuestro primer contacto con la estructura de las redes: los diferentes niveles de TCP/IP y su función en la comunicación de datos. También nos familiarizamos con el Monitor de Red (Wireshark) para interpretar el funcionamiento de los protocolos Ethernet, ARP e IP, realizando capturas de paquetes y analizándolos. Por último conocimos cómo funcionaba el direccionamiento IP, la utilidad de las máscaras de subred y fuimos conociendo la topología de la red del laboratorio.

• Práctica 2

La segunda práctica fue la más extensa de las 3. Tras habernos familiarizado con el Monitor de Red en la práctica anterior, nos adentramos en el funcionamiento del protocolo ICMP, viendo el formato de sus mensajes y los distintos tipos de los mismos que existen. Podía tratarse de mensajes de información o de error, ocasionados por diversos motivos. Nosotros nos centramos en unos cuantos de ellos, aprendiendo al mismo tiempo cómo funcionaba la fragmentación de los paquetes IP. Finalmente, en el anexo de la práctica, fuimos capaces de conocer las rutas que siguen los paquetes desde su origen hasta que llegan a su destino, valiéndonos para ello de diversas herramientas web, a las que podemos acceder a través de algunos de los enlaces de este blog.

• Práctica 3

La última de las prácticas nos sirvió para conocer los protocolos presentes en el nivel de transporte de TCP/IP: TCP y UDP. La práctica se basó en el estudio de ambos protocolos, cada uno orientado a un tipo de aplicaciones, mediante la realización de diversos ejercicios en los que aprendimos otro término importante en las redes: los puertos.

Una vez realizada esta recopilación de los conocimientos adquiridos (obviamente no se han nombrado todos ni se han detallado, porque si no la entrada sería muy extensa), sólo queda decir que hemos aprendido cosas que la mayoría desconocíamos, por lo menos yo, y que resultan muy interesantes al explicarnos el funcionamiento de este mundo (virtual) al que solemos dedicar gran parte de nuestro tiempo sin pararnos a pensar en el gran trabajo interno que supone.

Gracias a todos los que hayáis seguido este blog y feliz verano!!!

P.D. Cuando acaben los exámenes, claro está ;)

Práctica 3 - Anexo ejercicio 7

En una ventana de MS-DOS y dentro del directorio raíz empleamos el programa ftp para enviar el fichero C:\p3.txt al servidor 172.20.41.241. Para ello, utilizamos la siguiente secuencia de comandos:

 

C:\ftp 172.20.41.241

Connectado a 172.20.41.241

220 Linux1.disc.ua.es FTP server (Version wu-2.4.2-academ[BETA-18-VR12](1)

Wed Jan 27 22:19:46 CST 1999) ready.

Usuario (172.20.41.241:(none)):alumnos

331 Password required for alumnos.

Contraseña:alumnos

230 User alumnos logged in.

ftp> bin

200 Type set to I

ftp> put p3.txt

200 PORT command successful.

150 Opening BINARY mode data connection for rfc1191.txt

226 Transfer complete.

ftp: 48730 bytes sent in 24.28 segundos 2.01 KB/s

ftp> quit

221-You have transferred 48730 bytes in 1 files.

221-Total traffic for this session was 49154 bytes in 1 transfers.

221-Thank you for using the FTP service on Linux1.disc.ua.es.

221 Goodbye.

 

En primer lugar ejecutamos el comando:

route add 172.20.41.241 mask 255.255.255.255 172.20.43.231

y después el resto de comandos anteriores

De esta forma obtenemos en el Monitor de red lo siguiente:

a) Determina con el monitor de red qué valor de MSS se ha negociado en la conexión TCP. Para ello visualiza TODOS los paquetes IP intercambiados entre tu PC y el servidor 172.20.41.241.

En el primer extremo el valor de MSS es 1460 bytes mientras que en el segundo es de 460. Por tanto el valor negociado de MSS en la conexión ftp es 460. Ahora bien, finalmente la MSS debe ser de 360 debido a que en una red intermedia sólo se llega a ese valor.

 

b) ¿Hay paquetes ICMP “fragmentation needed and the bit don't fragment was set”? Si la respuesta es afirmativa, ¿qué máquina envía el mensaje de error?

Sí, un paquete.  La máquina que envía este mensaje es 172.20.43.231, máquina a partir de la cual con el valor de MSS previamente negociado no pueden seguir su recorrido los segmentos TCP.

 

c) ¿Cómo afecta este mensaje ICMP al tamaño de los paquetes TCP intercambiados entre tu PC y el servidor 172.20.41.241?

Este mensaje hace que los paquetes se envíen con un tamaño de 360 bytes de datos, ya que la MTU de la siguiente red que sigue a la máquina emisora del mensaje ICMP es de 400 (360+20+20). Si no se hubiese producido ese mensaje de error los paquetes TCP tendrían el tamaño establecido por la MSS negociada en conexión, 460 bytes.

 

d) ¿Reenvía tu PC algún paquete TCP al servidor?

Sí, tenemos 3 mensajes de retransmisión de TCP para que se vuelvan a reenviar los paquetes enviados con el anterior valor de MSS, antes de que se produjese el error de destino inalcanzable y cambiase a 360.

 

e) ¿Fragmenta IP algún paquete TCP?

No, IP no fragmenta ningún paquete TCP, sino que los forma inicialmente de manera que ajusten su tamaño al máximo permitido en las redes que van a atravesar.

Práctica 3 - Ejercicio 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.

Tendremos un mensaje ICMP “Fragmentation Needed”, de tipo 3 y código 4.

 

b. Indica la MTU del camino de camino completo.

La MTU del camino completo es 500, el menor valor presente en las redes que deben atravesar los paquetes para llegar al destino.

 

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.

Práctica 3 - Ejercicio 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.

Usando como nivel de transporte UDP:

Sin embargo, usando como nivel de transporte TCP:

La diferencia como vemos es que en el nivel de transporte TCP se mantiene en todo momento la cabecera TCP en cada segmento, mientras que en UDP, por el hecho de fragmentar, sólo se mantiene la cabecera UDP en el primer fragmento.

Práctica 3 - Ejercicio 5

Realizamos 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?

Tras introducir los comandos anteriores que se aprecian en la figura, lo que obtenemos en el Monitor de red es lo siguiente:

Se observan distintos intentos de conexión seguidos de reseteos al no poder establecer la conexión ya que las máquinas tienen esta opción deshabilitada.

Práctica 3 - Ejercicio 4

Utilizamos 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?

La MSS que se negocia entre los extremos tiene un valor de 460 bytes porque, a pesar de que en el extremo inicial podría ser de 1460, en el extremo final sólo puede ser de 460, de modo que se coge el valor más pequeño.

El tamaño de los segmentos TCP transportados dentro de los paquetes IP es en este caso de 460 bytes más 20 bytes de cabecera.

En este caso no tenemos ningún mensaje Destination Unrecheable porque desde un principio se negocia un tamaño de paquetes que servirá para todas las redes que hay que atravesar para llegar al destino.

Práctica 3 - Ejercicio 3

Utilizamos el programa rexec para ejecutar el comando ‘cat file1.txt’ en el servidor 172.20.43.232 (Linux2). La información recibida es de varios miles de bytes y la recibiremos 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 ha fragmentado esos segmentos porque los segmentos TCP llevan el bit “don’t fragment” activado, pues los paquetes se conforman con el tamaño máximo permitido para que no sea necesaria la fragmentación. Así pues, el tamaño de los segmentos TCP es de 1460 bytes de datos, más 20 de cabecera TCP.

Práctica 3 - Ejercicio 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 disponemos 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 introducirlos, podemos 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 .

Empleamos el programa rexec para ejecutar el comando ‘ls –l’ en la máquina con dirección 172.20.43.232 (Linux2). Utilizamos para ello el usuario ‘alumnos’ y la clave ‘alumnos’. Con el monitor de red, analizamos y estudiamos 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. Utilizamos para ello el filtro adecuado (direcciones y protocolos).

 

• Comprobamos las secuencias de conexión-desconexión TCP. ¿Son simialres a las observadas 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).
  

Sí son similares las secuencias de conexión y desconexión TCP que obtenemos a las observadas en la figura 6. En primer lugar en la conexión observada en dicha figura tenemos la secuencia SYN-ACK/SYN-ACK y esto mismo observamos en los 3 primeros paquetes que muestra la captura. Y, en cuanto a la desconexión, la figura establece que la secuencia es ACK-FIN-ACK, la cual también encontramos en los 3 últimos paquetes de la captura. Observamos también la respuesta a la solicitud de SYN del servidor con un RST. 

• Comprobamos el valor de los puertos utilizados e indicamos su valor.

El valor del puerto de nuestra máquina es 1105, mientras que el del servidor es 512. Pero estos valores cambian en un determinado momento (durante la autentificación) y sólo durante éste, siendo ahora el puerto de nuestra máquina el 113 y el del servidor 2057. Esto ocurre porque para realizar la autentificación son necesarios unos puertos que otorguen mayor seguridad que los anteriores.

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

La ventana de receptor más grande es la de nuestra máquina, con un valor de 65535 bytes. Sin embargo, el tamaño de la ventana de receptor de la máquina destino es tan sólo de 5840 bytes.