Cuestión Tracert

Rutas de los paquetes en la red

En este ejercicio se pretende que el alumno descubra la ruta que siguen los paquetes desde un nodo origen a un nodo destino con la información proporcionada por la herramienta de trazado de rutas. Debido a las limitaciones que posee el comando tracert o traceroute desde la ubicación del laboratorio, vamos a hacer uso de servidores de rutas externos, desde los que calcularemos la ruta a nuestra máquina o a cualquier otro nodo mundial.

Accede a la web http://tracert.com/trace_exe.html . Desde este sitio podemos lanzar la petición de traza de rutas desde diferentes servidores de la red.

- Realiza una petición de traza desde Australia (red Telstra.net) hacia la dirección http://www.ua.es/ . ¿Qué ciudades recorren los paquetes hasta que llegan a la Universidad de Alicante? ¿Cuántos routers son atravesados por paquetes (aproximadamente)?

Las ciudades que atraviesan los paquetes son: Melbourne, Sydney, Hong Kong, Maine, alguna ciudad del centro de los EEUU, Hollywood (Florida), Madrid, Valencia y Alicante.

Posiblemente en lugar de pasar los paquetes por Maine, entraran por alguna ciudad de California. Pero al utilizar un programa gratuito GeoIptool las bases de datos no tienen porque estar actualizadas y la ubicación de dicha dirección IP puede haber cambiado de lugar.

Los paquetes atraviesan aproximadamente 15 routers.

- Realiza una petición de traza desde Rusia hasta la web de http://www.sony.com/ . Indica la ubicación de los routers por los que pasan los paquetes hasta que llegan al servidor web. Para traducir las abreviaturas por los nombres de ciudades o aeropuertos ayúdate de la web http://www.sarangworld.com/TRACEROUTE/showdb-2.php3 .Dibuja en el mapa de la Figura 11 el camino de los paquetes.

Observando las abreviaturas que aparecen en los puntos por los que pasan los paquetes se puede concluir, a excepción de las dos primeras ciudades que las he extraido con la herramienta de localización por IP porque no encontraba la correspondencia con las abreviaturas, que la ruta que siguen los paquetes es la siguiente: Novosibirsk, Moscú, Frankfurt, Amsterdam, Nueva York, Chicago, San Jose, Los Angeles, San Diego.


- Repite el ejercicio, pero esta vez solicita la conexión con la web del Gobierno federal de Argentina http://www.argentina.gov.ar/ desde Paris (Eu.org). ¿Qué proveedor de red se encarga de encaminar los datos en la mayor parte del camino?



Las ciudades por las que pasa son: Paris, Galicia y Buenos Aires.

El proveedor que se encarga de encaminar los datos en la mayor parte de los caminos es Telefónica.


Compara los resultados si accedes desde Paris (Eu.org) al diario http://www.clarin.com/. Dibuja los caminos.



Las ciudades por las que pasa son: Paris, Washington, Atlanta, Miami y Buenos Aires.

El proveedor que se encarga de encaminar los datos en la mayor parte de los caminos es Cogentco.

Anexo

Herramientas de rutas de paquetes - Tracert/Traceroute

Una de las curiosidades más llamativas de la red es saber la ruta que siguen los paquetes o datagramas hasta que llegan a su destino.

Traceroute es una herramienta de diagnóstico de redes que permite visualizar la ruta de los paquetes que se dirigen desde un equipo a otro. Con esta herramienta se obtiene además una estadística o latencia de red de esos paquetes, lo que viene a ser una estimación de la distancia a la que están los extremos de comunicación. El comando se denomina traceroute en UNIX y linux, mientras que en Windows recibe el nombre de tracert.

¿Cómo funciona?

El funcionamiento del comando es sencillo. Se basa en un error ICMP TTL excedido en tránsito.

Tracert funciona enviando mensajes ICMP de solicitud de eco con distintos TTL; Traceroute, en cambio, envía mensajes UDP. El campo TTL de la cabecera IP de los paquetes es un número entero que se decrece en cada nodo por el que pasa el paquete. De esta forma, cuando el campo TTL llega al valor 0 ya no se reenviará más, sino que el nodo que lo esté manejando en ese momento lo descartará. Lo que hacen los comandos de traza de rutas es mandar paquetes a la red de forma que el primer paquete posea un valor TTL=1, el segundo un TTL=2, etc. De esta forma, el primer paquete será eliminado en el primer nodo al que llegue (ya que éste nodo decrementará el valor TTL, valiendo cero). Cuando un nodo elimina un paquete, envía al emisor un mensaje de error indicando la incidencia. Tracer usa esta respuesta para averiguar la dirección IP del nodo que desechó el paquete, que será el primer nodo de la red. La segunda vez que se manda un paquete, el TTL vale 2, por lo que pasará el primer nodo y llegará al segundo, donde será descartado, devolviendo de nuevo un mensaje de error. Esto se hace de forma sucesiva hasta que el paquete llega a su destino.

Otras aplicaciones

Existen otras aplicaciones como "Visual Route" que se basan en Traceroute/Tracert para obtener una información gráfica de la ruta que siguen los paquetes desde el origen hasta su destino. En estos casos, se emplea la información generada por la orden Traceroute/Tracert junto con la información de los nodos obtenida de bases de datos públicas como RIPE (foro colaborativo de redes IP).

En Internet existen una serie de lugares que proporcionan servidores de traceroute, y que nos informan de los resultados de la ejecución de una orden traceroute desde ese host hasta el nuestro u otro que se le especifique. A estos servidores se les suelen llamar Looking Glass. Esto es de gran ayuda a la hora de realizar mapas de caminos para los paquetes desde cualquier ubicación del mundo. En el sitio web de traceroute (http://www.traceroute.org/) se encuentran recogidos algunos de los sitios web que ofrecen la posibilidad de realizar trazas al sitio que se les indique.

De la información que obtenemos de los programas de rutas hay que tener en cuenta lo siguiente:

• Cada proveedor de red puede tener su propio sistema de código de máquinas.
• Los routers pueden describir en su nombre la topología o infraestructura en la que están ubicados (T1, T3, FDDI, ATM, HSSI, ETH, ...).
• Los códigos de nombre de los routers suelen tener 3 letras, como el código del aeropuerto más cercano. (Base de datos de código de aeropuertos: http://www.airportcitycodes.com/codewisecodes.aspx
• Los nombres de los routers también pueden incluir la dirección IP, una abreviatura especial, o seguir un código de nombres ya extendido como los que se encuentran en la siguiente web: http://www.sarangworld.com/TRACEROUTE/showdb-2.php3
• Existen también herramientas que a partir de la dirección IP del router nos permite conocer su ubicación como: http://www.geoiptool.com/

Cuestión 5

Mensaje ICMP "Time Exceeded"

Dentro del mensaje ICMP Time Exceeded se analizará el de código 0: Time to Live exceeded in Transist (11/0). En primer lugar, inicia el monitor de red para capturar paquetes IP relacionados con la máquina del alumno y ejecuta el comando:

C:\> ping -i 1 -n 1 10.3.7.0

Para filtrar los paquetes en los que está involucrada mi dirección IP aplico el filtro ip.src==172.20.43.202 ip.dst==172.20.43.202 && !nbns, siendo 172.20.43.202 mi dirección IP.

5.a. Finaliza la captura e indica la máquina que envía el mensaje "ICMP Time to Live exceeded in Transit"... ¿Puedes saber su IP y su MAC? (identifica la máquina en la topología del anexo)

La máquina que envía el mensaje "ICMP Time to Live exceeded in Transit" es la que tiene la puerta de enlace que usamos en prácticas (router Cisco 1720), su IP es la 172.20.43.230 y su MAC es 00:07:0E:8C:8C:FF. Es lógico que sea esta máquina porque al tener un tiempo de vida (TTL) igual a 1 solo conseguirá atravesar un router.



Inicia de nuevo la captura y ejecuta a continuación el comando:



C:\> ping -i 2 -n 1 10.3.7.0




5.b. Finaliza la captura y determina qué máquina envía ahora el mensaje "ICMP Time to Live exceeded in Transit"... Averigua y anota la IP y la MAC origen de este mensaje de error. ¿Pertenecen ambas direcciones a la misma máquina? (identifica las máquinas en la topología del anexo)




La IP origen de este mensaje de error es la 10.4.2.5 (Cisco 2513) y la MAC 00:07:0E:8C:8C:FF. No pertenecen a la misma máquina, la MAC pertenece a la máquina anterior (la puerta de enlace del laboratorio, Cisco 1720).



Por último, inicia de nuevo la captura y realiza un ping a la siguiente dirección:



C:\> ping -i 50 -n 1 10.3.7.12





5.c. Finaliza la captura y observa el mensaje de error ICMP que aparece en el monitor de red. ¿Qué tipo y código tiene asociado ese mensaje? ¿Qué crees que está sucediendo al intentar conectarte a esa máquina y obtener ese mensaje de error? ¿En qué subred estaría ubicada?

Este mensaje tiene asociado el tipo 11 y código 0.

Al intentar conectarse a una máquina que no existe se produce un bucle cerrado entre máquinas Linux 1 y Linux 2 hasta que se agota el tiempo de vida del paquete.

5.d. Repite el ejercicio pero esta vez eleva el tiempo de vida del paquete a 160. ¿Observas el mismo resultado con la misma rapidez? ¿En cuál de los dos casos ha tardado más la respuesta del ping (en MSDOS)?


C:\> ping -i 160 -n 1 10.3.7.12

Se observa como en este caso el resultado tarda más en aparecer.

Cuestión 4

Mensaje ICMP "Redirect"

Inicia el Monitor de Red. A continuación ejecuta los comandos:

C:\>route delete 10.4.2.1 (si ya ha sido borrada la ruta, avisa con un error)

C:\>ping -n 1 10.4.2.1

(antes de contestar debes confirmar que en MSDOS el resultado del Ping es correcto: paquetes enviados: 1, paquetes recibidos: 1, sino debes repetir los dos comandos anteriores y el proceso de captura en el Monitor de Red)

En base a los paquetes capturados, filtra sólo los datagramas que contengan tu dirección IP y contesta a las siguientes preguntas:

Para filtrar los paquetes en los que está involucrada mi dirección IP aplico el filtro ip.src==172.20.43.202 ip.dst==172.20.43.202 && !nbns, siendo 172.20.43.202 mi dirección IP.

4.a. ¿Cuántos datagramas IP están involucrados en todo el proceso? Descríbelos... (tipo, código y tamaño)

Hay 3 datagramas IP involucrados en el proceso que se describen a continuación:

- El primero es de tipo 8 y código 0, lo cual quiere decir que es una solicitud de eco. El camino que recorre es desde mi máquina hasta la 10.4.2.1 (a la que he mandado el ping).

- El segundo es de tipo 5 y código 1, y va desde la puerta de enlace 172.20.43.230 a mi máquina 172.20.43.202. El mensaje de tipo 5 quiere decir que es una redirección y al ser de tipo 1 redirecciona datagramas para el host.

- El tercero es de tipo 0 y código 0, por tanto, es una respuesta de eco. El camino que recorre el datagrama es desde la máquina origen 10.4.2.1 hasta la mia 172.20.43.202.

4.b. Dibujar gráficamente el origen y destino de cada datagrama (como se ha realizado en la figura 7, pero incorporando el direccionamiento IP correcto de las máquinas involucradas).

4.c. ¿Observas los mismos datagramas en el Monitor de Red con respecto a los que se comentan en la explicación teórica del Redirect? ¿Por qué puede suceder esto?

El datagrama que no aparece es la copia del echo que realiza el router uno (puerta de enlace predeterminada 172.20.43.230), esto es debido a que el switch realiza un filtrado por seguridad que consiste en que los mensajes entre routers no puedan ser visualizados por el resto de equipos de la red.

4.d. ¿Las direcciones MAC e IP de todas las tramas capturadas con el Monitor de Red hacen referencia al mismo interfaz de red? Indica en qué casos la respuesta es afirmativa y en que casos la dirección IP especifica un interfaz de red que no se corresponde con el mismo interfaz indicado por la MAC.

4.e. ¿Qué máquina o interfaz de red envía el mensaje ICMP Redirect?

La máquina que envía el mensaje ICMP Redirect es la CISCO 1720 (172.20.43.230),, que es la puerta de enlace predeterminada.

4.f. ¿Qué dato importante para tu PC transporta en su interior ese mensaje de Redirect? ¿Transporta algún otro tipo de información extra?

Cada mensaje de redireccionamiento contiene un campo de 32 bits llamado dirección de internet del encaminador que contiene la IP de salida correcta para la máquina emisora.

4.g. Observa los campos "Identificación", "TTL" y "Cheksum" del datagrama que se envió originalmente. A continuación, analiza el contenido del mensaje Redirect. ¿Puedes encontrar la mima identificación dentro de los datos (no cabecera) del mensaje ICMP Redirect? ¿Qué ocurre con los campos TTL y Cheksum del datagrama transportado por el Redirect?

Datagrama enviado originalmente:

-Identificación: 0x5314; TTL=128; Cheksum: 0x03ca

Mensaje Redirect:

-Identificación: 0x5314; TTL=127; Cheksum: 0x04ca

La identificación del ambos datagramas es la misma ya que se trata del mismo mensaje.

El TTL del mensaje Redirect es una unidad inferior al original porque ha atravesado un router.

En el campo Cheksum varía un número al haber variado en una unidad el valor del TTL.