1.-
Pregunta
Respuesta
·
PRÁCTICA
DE REDES.
·
CAPA
DE TRANSPORTE (TCP, UDP) --- 1 parte
·
En esta práctica
sobre la pila de protocolos TCP/IP nos vamos a ocupar de lo que se conoce
como capa de transporte. La capa de
transporte se encarga, entre otras cosas, de empaquetar la información en
paquetes de tamaño adecuado (limitarlo, por ejemplo, a las características de
la red física, que podría no soportar paquetes de tamaños superiores a…), de
verificar que todos los paquetes de una comunicación han llegado a destino
(dependiendo del protocolo que usemos), de comprobar que los paquetes no estén
corruptos…
·
Los dos protocolos
principales de la capa de transporte son TCP (Transmission Control Protocol) y
UDP (User Datagram Protocol). A lo largo de la práctica veremos algunas de sus
características. También recuperaremos el protocolo DNS (Domain Name Server) y
veremos la necesidad de contar con servidores DNS en nuestro ordenador para
poder acceder a Internet, cómo se pueden configurar los servidores DNS y cómo
funciona el protocolo.
·
Antes de empezar la
práctica vamos a recuperar el programa para monitorizar el tráfico de red
(http://www.wireshark.org/). Instálalo en tu ordenador. Ejecútalo, y dentro del
menú “Capture”, en la opción “Interfaces”, elige la interfaz de red activa.
Recupera y anota la IP de tu ordenador por medio del comando “ipconfig” (de las
distintas interfaces de red que aparezcan debes seleccionar la correspondiente
a “Adaptador de Ethernet – Conexión de área local”).
·
Ahora crea un filtro
en Wireshark como el siguiente para conseguir aislar sólo el tráfico que tiene
como origen o destino tu máquina: host ip-de-tu-maquina
PUEDES VER LA
SINTÁXIS DE FORMACIÓN DE LOS FILTROS EN WIRESHARK EN
ESTE LINK.
http://wiki.wireshark.org/CaptureFilters.
·
A lo largo de la
práctica, a medida que Wireshark captura más paquetes, es probable que su
comportamiento se ralentice. En ese caso puedes detenerlo (“Capture ->
Stop”) y reiniciarlo (“Capture -> Interfaces -> Start ) (ten en cuenta
que empezará una nueva sesión o captura cada vez que lo arranques y se perderán
los paquetes ya capturados).
·
Pregunta
1
Abre pestañas independientes en
tu navegador y accede a estas direcciones:
193.147.0.103
185.15.76.85
1.1 ¿Qué páginas se han abierto?
·
Portal todo FP inicio
·
http://www.iesgrancapitan.org/portal/
·
Filtra en Wireshark
toda la actividad DNS que ha habido al abrir las páginas anteriores (escribe “dns”
en la ventana “Filter:”). El protocolo DNS es el que permite, a partir de una
dirección URL, resolver su IP para que las cabeceras de la capa de red se
puedan formar correctamente.
1.2.- ¿Ha necesitado el ordenador conectarse a los servidores DNS para
resolver las anteriores direcciones? ¿Se ha conectado antes o después de hacer
las solicitudes HTTP?
No a necesitado el ordenador conectarse a los servidores DNS para
resolver las anteriores direcciones. No es necesario conectarse a los
servidores, pues le estamos dando una dirección IP, y no necesita resolver el
nombre porque ya una dirección IP.
Se ha conectado antes de hacer las solicitudes HTTP porque no se
conecta directamente HTTP sino que realiza una conversación. Por lo tanto, se a
conectado primero con protocolo TCP donde ha iniciado la conexión entre el servidor y
nosotros, para permitir el envio de datos en protocolo hipertexto.
Pregunta 2
Vamos ahora a ver
cómo funciona la capa de transporte. Dentro de la misma podemos encontrar principalmente
dos protocolos, TCP y UDP. Filtra en Wireshark la comunicación que ha tenido
lugar entre tu ordenador y la página web en 74.125.159.105. Puedes crear un
filtro como: host la_ip_de_tu_maquina and host 185.15.76.85. Observa la lista
de paquetes que has recuperado.
2.1 ¿A qué protocolos pertenecen?
74.125.159.105 me
sale página caída.
Protocolos TCP.
Recupera el mensaje
de protocolo HTTP cuya “info” sea exactamente “GET / HTTP/1.1” y ábrelo (botón
derecho sobre el mismo, opción “Show Packet in New Window”). Observa las
cabeceras TCP. Anota el valor de los puertos “Src” (puerto de tu máquina) y
“Dst” (puerto del servidor). La comunicación entre máquinas siempre se hace a
través de puertos de las mismas. Mientras dura una comunicación, cada máquina
mantiene el mismo puerto escuchando y mandando mensajes. Algunos protocolos
tienen un puerto asignado por defecto; por ejemplo, cuando te conectes a un
servidor a través del protocolo http, lo normal es que el servidor utilice su puerto
80 para esa comunicación (¿es cierto en este caso?). Si te conectas por ftp,
por defecto el servidor utilizará el puerto 21.
Si es correcto.
2.2 Vamos a observar
ahora la comunicación que ha habido a través del puerto de tu computadora.
En primer lugar,
vamos a filtrar los paquetes de los que hemos sido origen (o src). Aplica el
siguiente filtro: tcp.srcport eq puerto_de_tu_maquina
¿Cuál es la IP de origen de dichas
comunicaciones? ¿Y la de destino? ¿Qué recursos web se han solicitado por HTTP a
través de ese puerto?
IP de origen: 193.147.0.103/
IP de destino: 192.168.1.128
Recursos web que se
han solicitado por HTTP:Control de protocolo, puertos de destino y origen…
2.3 Veamos ahora los
paquetes de los que hemos sido destinatarios (dst). Aplica el siguiente filtro:
tcp.dstport eq puerto_de_tu_maquina
¿Cuál
es la IP de origen de dichas comunicaciones? ¿Y la de destino? ¿Qué mensajes
HTTP se han enviado a través de ese puerto?
IP de origen:
193.147.0.103/
IP de destino:
192.168.1.128
Recursos web que se
han solicitado por HTTP:Control de protocolo, puertos de destino y origen…
Aparte de la
información sobre los puertos, las cabeceras TCP contienen información que nos
va a permitir asegurar la correcta recepción de los paquetes. Copia los números
“Sequence number” y “Next Sequence
Number” dentro de la cabecera TCP del mensaje “GET / HTTP/1.1”. Ahora crea el siguiente filtro: tcp.ack eq
next_sequence_number
Responde a las
preguntas:
¿Qué
mensajes contienen el número next_sequence_number? ¿La respuesta del servidor
“HTTP/1.1 200 OK” contiene el next_sequence_number?
los mensajes de siguientes secuencias de numeros que se transmiten al enviar el mensaje
si contiene el next - sequence-number.
Pulsa el botón
derecho sobre el mensaje cuya “info” es “HTTP/1.1 200 OK”, opción “Show Packet
in New Window” y trata de comprobar, en la sección de cabeceras de “Reassembled
TCP Segments”, qué paquetes han sido “reensamblados” para construir el mensaje
de respuesta HTTP.
Anota
sus números y comprueba si aparecen también entre los mensajes filtrados por la regla “tcp.ack
eq next_sequence_number”.
HTTP/1.1 201
HTTP/1.1 202
HTTP/1.1 203
HTTP/1.1 204
Tratemos de dar una
explicación al anterior hecho. Cuando tu ordenador hace una solicitud a un
servidor, genera números “Sequence Number” y “Next Sequence Number”. Estos
números son generados de forma aleatoria.
Cuando el servidor
responda a tu mensaje, siempre incluirá un campo “Acknowledgment number” en el
que enviará el número que nuestro ordenador le envió como “Next Sequence
Number”. Así nuestro ordenador consigue distinguir las respuestas a las
distintas solicitudes que le haya hecho a ese servidor.
De no existir los
números “Sequence” y “Acknowledgment”, nos sería imposible distinguir las
distintas comunicaciones con una misma máquina, y por tanto no podríamos
reconstruir sus mensajes
