EJERCICIO DE ENRUTAMIENTO CON DOS ROUTERS (II).

REDIRECCIÓN 26
IP: [Link] IP: [Link]
Switch Máscara: [Link] Switch Máscara: [Link] Switch
R-192 IP: [Link] R-172 IP: [Link] R-10
Máscara: [Link] Máscara: [Link]

R-W7-R1 R-W7-R2

R-UD-1 R-W7-1
IP: [Link] IP: [Link]
Máscara: [Link] R-W10-1 Máscara: [Link]
Gateway: [Link] IP: [Link] Gateway: [Link]
Máscara: [Link]
Gateway: ????

Figura 1
En este caso existen tres subredes ([Link]/16, [Link]/12, [Link]/8) interconectadas a través de dos routers, y se trata
de configurar todos los equipos, de manera que cualquiera de ellos pueda comunicarse con cualquier otro equipo,
independientemente de la subred a la que pertenezcan.
Dado que los routers que utilizamos no tienen capacidad de aprender rutas por sí mismos, es necesario que les enseñemos,
nosotros, por dónde tienen que dirigir el tráfico de una subred a otra. Para ello utilizaremos las denominadas rutas estáticas, que
no son otra cosa que reglas de enrutado, específicas, que se añaden a la tabla de enrutado de los routers para que puedan saber
qué hacer cuando tienen que remitir una trama a una subred determinada.
Empezaremos por la configuración general de los routers y de los equipos, dejando para el final el R-W10-1 ya que se trata de
un equipo al que se le pueden asignar distintas configuraciones.
1.- R-W7-R1.
A este equipo, de momento, tan solo debemos darle la configuración TCP/IP, que le corresponda a cada una de sus tarjetas, y
comprobar que tiene en funcionamiento el servicio de enrutado, tal y como se muestra en la Figura 2, mediante la ejecución del
comando ipconfig /all.
A la vista de la configuración dada, a cada una de sus tarjetas, comprobaremos, en el VirtualBox, que el adaptador de red 1 está
configurado en la red interna R-172 y el adaptador de red 2 en la red interna R-192.

Figura 2 Figura 3
2.- R-W7-R2.
Haremos lo mismo que en el caso del
R-W7-R1, Figura 3. Pero en esta
ocasión, y en coherencia con la
configuración dada a sus tarjetas, el
adaptador de red 1 debe pertenecer
a la red interna R-10 y el adaptador
de red 2 a la red interna R-172.
Una vez concluida la configuración Desde R-W7-R1 Desde R-W7-R2
inicial de los routers, Figura 4

26-EJERCICIO DE ENRUTAMIENTO CON DOS ROUTERS (II). REDIRECCIÓN. BLS. Curso 2019-2020 Página 1 de 14
comprobaremos que se “ven”, lanzando un ping desde cada uno de ellos hacia el otro, a través de la subred común [Link]/12,
tal y como se muestra en la Figura 4.
3.- R-UD-1.
A este equipo tan solo debemos darle la configuración TCP/IP que le corresponde,
Figura 5 (nótese que se utilizó la longitud del prefijo para establecer la máscara de
subred), y comprobar, en el VirtualBox, que su tarjeta de red se encuentra sobre la
red interna R-192.
Una vez establecida, y comprobada, la configuración del R-UD-1 es una buena
práctica estudiar a qué equipos llegamos haciendo ping desde él. Esto nos
permitirá entender el funcionamiento actual de la red y, en consecuencia, las
limitaciones que debemos superar mediante la correcta configuración de los routers
de la red propuesta.
Como siempre, empezaremos por hacer ping a la IP más próxima (se utiliza el
comando ping –c 4 [Link], para realizar, únicamente, 4 peticiones de eco),
es decir a la [Link]/16, que corresponde a la interfaz del router que
pertenece a nuestra subred. En este caso obtendremos la respuesta
correspondiente, tal y como se muestra en la Figura 6a. Figura 5

Ahora probaremos a la siguiente IP, la [Link]/12, que corresponde a la interfaz de la subred [Link]/12 de nuestro
router (R-W7-R1). También en esta ocasión obtenemos respuesta, Figura 6-b.
Animados por este resultado probamos, con la IP [Link]/12, que corresponde a la interfaz de la subred [Link]/12 del
router R-W7-R2. El resultado nos sorprende, Figura 6c. Nuestra máquina nos informa que envió todas y cada una de las
peticiones de eco ICMP y no recibió respuesta alguna, por parte de la interfaz de IP [Link]/12.

a) ping –c 4 [Link] b) ping –c 4 [Link] c) ping –c 4 [Link]

Figura 6
A la vista de este resultado cabría pensar que el problema se encuentra en R-W7-R1 que, por alguna razón que no alcanzamos
a entender, no envía las peticiones a R-W7-R2, a pesar de que ambos están en la misma subred y por lo tanto, para R-W7-R1,
es una comunicación, de lo más normal, con su propia subred.
Para comprobar la veracidad de nuestra hipótesis, levantamos un sniffer y le configuramos, en el VirtualBox, su adaptador de
red para que trabaje sobre la red interna R-172. Lanzaremos el ping [Link], desde R-UD-1, y veremos qué captura el
sniffer.
El resultado de la captura, mostrado en la
Figura 7 (para realizar esta captura se
utilizó el filtro de captura: arp or icmp), no
deja lugar para la duda. El R-W7-R2 recibe
todas y cada una de las peticiones de eco
que le hizo el R-UD-1, ya que circulan por
el enlace entre el R-W7-R1 y él mismo, tal
como pone de manifiesto la captura
realizada sobre ese enlace (red interna R-
Figura 7
172). Por otro lado, el diálogo ARP, de la
Figura 7, pone de manifiesto el perfecto entendimiento entre ambos equipos.
Según esto, ¿por qué no responde el R-W7-R2? La respuesta es sencilla, porque no sabe cómo enviar la contestación.
Veamos, tal y como puede comprobarse en la Figura 7 (captura efectuada en R-172 utilizando el filtro de captura: arp or icmp),
las peticiones de eco que realiza el R-UD-1 le llegan, como no podía ser de otra manera, con la IP de origen [Link]. Una
vez recibidas, el R-W7-R2 se dispone a responder a cada una de ellas, pero no sabe cómo llegar a la subred [Link]/16. Él,
de momento, solo conoce las redes que le son propias, es decir la [Link]/12 y la [Link]/8 el resto del mundo le es
absolutamente desconocido y, además, carece de recursos para conocerlo. Somos nosotros quienes debemos enseñarle el
camino a esa subred.
Cuando un ordenador tiene que comunicarse con cualquier otro, incluida su propia IP, lo primero que hace es consultar su tabla
de enrutado, que, a efectos prácticos, es su “libro de rutas”. Toda ruta que no figure en su tabla de enrutado, simplemente no
existe para la máquina y, en consecuencia, nunca podrá llegar al destino de esa ruta inexistente en su tabla de enrutado.
Para ver el contenido de la tabla de enrutado del R-W7-R2, ejecutamos el comando route print y nos presenta la tabla que se
muestra en la Figura 8.
Para poder interpretar la tabla de enrutado, es necesario conocer algunas cosas.
En primer lugar, indicar, que cada una de las filas de esa tabla constituye una regla de enrutado, apareciendo en la columna
“Destino de red” el destino de cada una de las reglas. Ese destino puede ser una subred (en cuyo caso aparecerá, en esa

26-EJERCICIO DE ENRUTAMIENTO CON DOS ROUTERS (II). REDIRECCIÓN. BLS. Curso 2019-2020 Página 2 de 14
columna, el identificador de subred correspondiente, reglas 1, 4, 7 y 10 de la Figura 8) o una dirección de host (reglas 2, 3, 5, 6,
8, 9 y 11 de la Figura 8).
En la columna “Máscara de red”, figura la máscara que debe aplicarse al “Destino de red” correspondiente, para saber que parte
del mismo es fijo (bits a 1 en la máscara) y cual es variable. Esta es la razón por la cual en las reglas de host aparece la máscara
[Link], ya que el destino es, estrictamente, la IP que se indica en la regla, sin variabilidad posible.
En la tercera columna, “Puerta de enlace”, consta la IP asociada a la interfaz a cuya MAC debe dirigirse la trama que pretende
enviarse al destino indicado por la regla en cuestión; en el caso de tratarse de una IP de la propia máquina, figurará como “En
vínculo”.
En la columna “Interfaz” se le muestra, a la máquina, a través de cuál de sus IP, asociadas a sus interfaces, debe enviar las
tramas hacia el destino indicado. Además de esta información para el equipo, la columna “Interfaz” nos indica a qué interfaz está
ligada esa regla de enrutado, de manera que si, por la razón que sea, esa interfaz no se encuentra activa; la regla de enrutado
en cuestión desaparecerá de la tabla y dejará de ser funcional. Reincorporándose, a la tabla de enrutado, cuando la interfaz se
vuelva a encontrar disponible.
Por último, la columna “Métrica”, que solo tiene sentido cuando existen varias rutas posibles para un mismo destino, ya que es
el parámetro que se utiliza para priorizarlas, eligiéndose la ruta activa de métrica menor.
Analicemos las distintas reglas de la tabla de
enrutado del R-W7-R2, Figura 8.
1.- En esta regla se indica que para alcanzar
cualquier IP de la subred [Link] (“Destino
de red”), con máscara de 8 bits (“Máscara de
red”), las tiene en vínculo (“Puerta de enlace”)
usando la interfaz correspondiente a la IP
[Link] (“Interfaz”). En lenguaje
convencional se traduce diciendo, que para
comunicarse con cualquier nodo de su propia
subred ([Link]/8), debe enviar las tramas,
directamente, a través de su interfaz con IP
[Link].
2.- Indica que cuando quiera comunicarse con la
IP [Link] (obsérvese que, al tratarse de
una dirección de host, la máscara de red es
[Link], lo que indica que en el Figura 8
“Destino de la red” no cabe ningún tipo de
variabilidad) debe dirigirse a su interfaz con idéntica IP. En pocas palabras, le indica a la máquina que la IP [Link] es
ella misma.
3.- Esta regla le indica, al R-W7-R2, que cuando tenga la necesidad de enviar un mensaje de broadcast dirigido, a la subred
[Link]/8 (IP [Link]), debe hacerlo a través de su propia interfaz [Link]. Obsérvese que la “Máscara de red”
indica que, en este caso, tampoco se admite ningún tipo de modificación sobre la dirección indicada en el “Destino de red”
(regla de host).
4.- En esta regla se instruye, al R-W7-R2, para que direccione cualquier IP de la subred [Link]/8 a la IP del bucle local
([Link]/8). Recuérdese que, cuando se trató el direccionamiento IPv4, ya se indicó que toda la subred [Link]/8 estaba
reservada para el bucle local.
5.- Indica que cuando quiera comunicarse con la IP [Link] (obsérvese que, al tratarse de una dirección de host, la máscara
de red es [Link], lo que indica que en el “Destino de la red” no cabe ningún tipo de variabilidad) debe dirigirse a
su interfaz con idéntica IP. En pocas palabras, le indica a la máquina que la IP [Link] es ella misma.
6.- Esta regla le indica, al R-W7-R2, que cuando tenga la necesidad de enviar un mensaje de broadcast dirigido, a la subred
[Link]/8 (IP [Link]), debe hacerlo a través de su propia interfaz [Link]. Obsérvese que la “Máscara de red”
indica que, en este caso, tampoco se admite ningún tipo de modificación sobre la dirección indicada en el “Destino de red”
(regla de host).
7.- Es equivalente a la regla 1, pero para la subred [Link]/12; que es la segunda de las redes a las que pertenece el router.
8.- Es equivalente a la regla 2, pero para la subred [Link]/12.
9.- Esta regla es paralela a la regla 3, pero referida a la subred [Link]/12. Nótese que en “Destino de red” la dirección de
broadcast dirigido es al [Link] que es la que le corresponde a la subred [Link]/12.
10.- Hacen referencia a la subred de multicast [Link]/4 (antigua clase D) e indica que tiene habilitado el soporte multicast en
todas las interfaces sobre la subred multicast indicada.
11.- Le indican, al R-W7-R2, que puede enviar mensajes de difusión (de broadcast limitado) a través de cualquiera de sus
interfaces, adviértase que se utiliza una regla de host para indicar que solo es de aplicación para la IP [Link].
Tal y como se había comentado, el R-W7-R2 no tiene ninguna regla de enrutado para la subred [Link]/16, razón por la cual
le resulta imposible responder a la petición de eco del R-UD-1.
Para incorporarle esa regla y que pueda responder al R-UD-1 debemos utilizar el siguiente comando genérico, recuerde que se
requiere elevación:

26-EJERCICIO DE ENRUTAMIENTO CON DOS ROUTERS (II). REDIRECCIÓN. BLS. Curso 2019-2020 Página 3 de 14
 route add [dirección_destino] mask [máscara acorde con el destino] [IP a través de la cual se alcanza el destino]
De manera que, en nuestro caso concreto, sería:
route add [Link] mask [Link] [Link]
Obsérvese que se usa la máscara [Link], para indicar que es una ruta válida para cualquier IP de la subred utilizada como
destino. Por otro lado, es evidente que el puente de unión entre el R-W7-R2 y la subred [Link]/16, es el R-W7-R1 y la
interfaz de la subred común, entre ellos, es la de IP [Link], que es la que se indica, por ser la única a la que el R-W7-R2
tendrá acceso para llegar a la subred destino.

Figura 10
En la Figura 9 se muestra, el comando ejecutado y la tabla
de enrutado, con la nueva regla incorporada.
Si todo funciona como es debido, ahora el ping del R-UD-1
hacia la IP [Link] del R-W7-R2 debe obtener su
repuesta, tal y como se muestra en la Figura 10.
Las rutas establecidas por el administrador, tal y como
Figura 9 acabamos de hacer se denominan rutas estáticas, ya que,
salvo que las modifique el propio administrador, no
cambiarán. El contrapunto de este tipo de rutas son las denominadas rutas dinámicas, que son aquellas que el propio router
aprende e incorpora a su tabla de enrutado de forma dinámica. Para que un router pueda hacer este tipo de gestión de aprendizaje
de rutas, es necesario que esté dotado de los recursos necesarios, tal como el protocolo RIPv2 (Routing Information Protocol,
Protocolo de Información de Enrutamiento).
Para comprobar otra de las características de la ruta que acabamos de incorporar, en la tabla de enrutado del R-W7-R2, vamos
a reiniciar, no apagar, el R-W7-R2.
Una vez reiniciado el R-W7-R2, repetiremos el ping a [Link] desde R-UD-1. Y nos sorprenderá el hecho de que ya no
obtengamos respuesta. Para comprobar el origen de este repentino cambio de comportamiento, iremos al R-W7-R2 y
comprobaremos el estado de la tabla de enrutado (ejecutando el comando route print). Si nos fijamos con detenimiento,
advertiremos que la regla que habíamos incorporado, a su tabla de enrutado, ha desaparecido. La razón es sencilla, una ruta
estática que se incorpora con el comando que nosotros usamos, es una ruta estática no permanente (no persistente), debido a
que es suficiente con reiniciar el equipo para que desaparezca de la tabla de enrutado.
Si deseamos introducir una ruta estática permanente (persistente), en la tabla de enrutado de un sistema Windows, debemos
utilizar el parámetro -p en el comando route. De manera que, en esta ocasión, la incorporaremos de forma permanente
(persistente), mediante el comando:
route -p add [Link] mask [Link] [Link]
En la Figura 11 se muestra el comando ejecutado y la tabla
de enrutado con la nueva regla incorporada. Obsérvese que
la nueva regla se incorporó, correctamente, en la tabla de
enrutado y, además, el sistema nos informa que se incorporó
como ruta persistente, mostrándola de nuevo en un apartado
específico en la parte inferior de la pantalla. Ni que decir
tiene, que una ruta estática persistente no desaparece de la
tabla de enrutado, aunque se apague o reinicie el sistema.
Es importante destacar, una vez más, que una ruta de
enrutado persistente estará activa, únicamente, si se
encuentra en la tabla de enrutado, no teniendo nada que ver
el que aparezca en la sección de rutas persistente, que solo
sirve para indicarnos que el sistema tiene, o no, rutas de ese
tipo.
Si en algún momento deseamos eliminar una ruta de la tabla
de enrutado (sea permanente o no), en un sistema Windows,
debemos utilizar el parámetro delete en el comando route.
Por ejemplo, si deseáramos eliminar la ruta que acabamos
de introducir, ejecutaríamos el comando route de la forma
siguiente: Figura 11

route delete [Link] mask [Link] [Link]

26-EJERCICIO DE ENRUTAMIENTO CON DOS ROUTERS (II). REDIRECCIÓN. BLS. Curso 2019-2020 Página 4 de 14
Se debe ser muy cuidadoso, a la hora de eliminar rutas de una tabla de enrutado, sobre todo si existen muchas y con cierto
parecido.
Si lo que se desea es eliminar todas las rutas estáticas, permanentes o no, introducidas en la tabla de enrutado se utiliza el
parámetro -f del comando route:
route -f
Tras la ejecución de esta orden debe reiniciarse el equipo; de hecho, en algunas versiones de Windows es absolutamente
obligatorio hacerlo, ya que elimina la tabla de enrutado por completo; borrando, incluso, la puerta de enlace configurada a través
del entorno gráfico.
En cualquier caso, no olvide que puede obtener la información completa del comando route, ejecutándolo en la forma route ? o
consultando el Anexo, al final de estas páginas.
4.- MÉTODO DE BÚSQUEDA EN LA TABLA DE ENRUTADO.
Tal y como ya se comentó, los posibles destinos, “Destino de red”, que Inicio
pueden aparecer en una tabla de enrutado pueden ser direcciones IP
de subred o direcciones IP de host. Según esto podría darse el caso, y
se da, de tener en la misma tabla de enrutamiento una ruta para una
subred y otra ruta específica para un host de esa subred. ¿Cómo ¿Dispongo de
una regla para la IP Sí
gestionaría esa aparente duplicidad, en la tabla de enrutamiento, el
solicitada?
sistema?, la respuesta está en conocer la lógica que utiliza en esas
búsquedas.
No
Utilizaremos la Figura 12 para ilustrar el procedimiento. Cuando se trata
de buscar una regla, en la tabla de enrutado, lo primero que intenta
encontrar, el sistema, es una regla específica para la IP en cuestión. ¿Dispongo de
Para lo cual comenzará buscando una coincidencia absoluta entre la IP una regla para la Sí
a la que quiere acceder y los destinos de las reglas de la tabla con subred de la IP
solicitada?
máscara de 32 bits, es decir con las reglas de host, ya que esa máscara
de red, en la tabla de enrutado, indica que esa regla es de aplicación
No
exclusiva para el destino indicado de forma literal, sin ningún tipo de
posible variación.
Si en la primera búsqueda, entre las reglas de host, no se halla ninguna
No ¿Tengo configurado Sí
coincidencia, buscará una ruta para la subred a la que pertenezca la IP. un gateway?
En este tipo de búsqueda pueden presentarse tres casos distintos de
búsqueda con resultado positivo:
a) Que se encuentre una única regla de enrutado aplicable al destino
solicitado, en cuyo caso se ejecutaría sin más. Gestionar el envío
Host según la regla de
b) Que se encontraran más de una regla aplicables con idéntico inalcanzable enrutado
correspondiente
destino, en este supuesto se seleccionaría aquella que dispusiera
de una métrica menor (menor valor en la columna métrica de la
tabla). Un ejemplo, de esta circunstancia, se muestra en la Figura
13, en la que aparecen tres reglas de subred, activas, con destino
en la [Link]/16 pero con distinta métrica. En este caso se Fin
aplicaría la correspondiente a la puerta de enlace [Link], Figura 12
por disponer de la menor métrica de las tres, 21.
Este supuesto se estudiará con detenimiento en su momento; no se preocupe si, a día de hoy, esto le aclara poco.
No se contempla la posibilidad de que puedan existir reglas con igual destino e idéntica métrica, ya que tal circunstancia
sería incorrecta y, por ejemplo, nunca podría darse utilizando protocolos de enrutamiento dinámico.
c) Que se encontraran más de una regla, con distintos destinos, pero aplicables en el caso de la IP buscada. Por ejemplo,
supongamos que se desea comunicar con la interfaz configurada con la IP [Link], desde el equipo cuya tabla de
enrutado se muestra en la Figura 14.

Figura 13 Figura 14

26-EJERCICIO DE ENRUTAMIENTO CON DOS ROUTERS (II). REDIRECCIÓN. BLS. Curso 2019-2020 Página 5 de 14
 Lo primero que debemos tener presente, es que, en ningún caso, el equipo origen de la comunicación, tendrá certeza sobre
la máscara de subred utilizada en la definición de la IP destino, razón por la cual debe buscar en su tabla de enrutado por
aproximación.
Tal y como vemos en la Figura 14, el equipo del ejemplo dispone de reglas de enrutado para las siguientes subredes
destino: [Link]/8, [Link]/16 y [Link]/24. De manera que, comparando estas subredes de destino con la IP
en cuestión, [Link], es fácil deducir que la regla correspondiente a la subred [Link]/24 no sería de aplicación;
ya que en ella se establece que deben coincidir los tres primeros bytes (máscara de 24 bits) y en este caso eso no se
cumple, ya que en la IP destino el tercer byte tiene el valor 7 y en la regla el valor 5. Por el contrario, las otras dos reglas sí
podrían aplicarse, ya que la IP comienza por 192, con lo cual se ajusta a la regla correspondiente a la subred destino
[Link]/8, y, además, el segundo byte de la IP tiene el valor 168 con lo cual también se ajusta a la regla con destino en
la subred [Link]/16.
La cuestión que se plantea es, ¿cuál de las dos reglas se utilizaría?. La respuesta a esta pregunta se encuentra en las
máscaras de subred utilizadas en las reglas, ya que siempre se utiliza la regla de enrutado cuya máscara de subred tuviera
mayor longitud de prefijo, de entre todas las aplicables. Según esto, en este ejemplo se utilizaría la regla correspondiente a
la subred [Link]/16 enrutándose a través de la puerta de enlace de IP [Link], tal y como se establece en ella.
d) En la hipótesis de que tampoco la segunda de las búsquedas, referida a la regla de subred, tuviera éxito, se aplicaría, de
existir, la regla genérica de enrutado, que, tal y como se verá al tratar la configuración del R-W10-1, está definida como una
especie de cajón de sastre, que se utilizará para cualquier destino no conocido, entendiendo por destino no conocido todo
aquel para el que no se disponga de una regla específica en la tabla.
e) Si, finalmente, tampoco estuviera definida una regla genérica, el sistema no dispondría de ninguna regla aplicable al caso,
con lo cual simplemente se daría por vencido y retiraría el paquete de la red.
5.- R-W7-1.
A la hora de configurar el R-W7-1 lo único que debemos hacer es darle la
configuración TCP/IP que le corresponde y que se muestra en la Figura 15.
Realizando las pruebas paralelas a las efectuadas para el R-UD-1, nos
encontramos con un comportamiento semejante al visto para el R-UD-1.
Haciendo un ping a [Link], la IP del router de nuestra subred, debemos
obtener la respuesta correspondiente.
Haciendo un ping a [Link], la otra IP del router de nuestra subred, también
debemos obtener respuesta.
Haciendo un ping a [Link], una de las IP de R-W7-R1, no debemos obtener
respuesta (indicándonos el R-W7-1, a través de la consola, “Tiempo de espera
agotado para esta solicitud”). La razón de este comportamiento, es idéntica a la
discutida para el R-UD-1 cuando intentaba contactar con la IP [Link] del R-
W7-R2. Ya que, como se muestra en la Figura 16, el R-W7-R1 recibe las
peticiones de eco, pero no las responde (la captura de la Figura 16 se realizó sobre
la red interna R-172 y utilizando como filtro de captura: arp or icmp). Adviértase
que el diálogo ARP, tramas 1 y 2 de la Figura 16, pone de manifiesto una perfecta
conexión entre ambos equipos.
Figura 15
Para solucionar este contratiempo incorporaremos, en la tabla de enrutado de R-
W7-R1, la regla que lo instruya sobre cómo llegar a la subred [Link]/8 a través de la IP [Link] del R-W7-R2. Para ello
ejecutaremos, en R-W7-R1, el siguiente comando:
route -p add [Link] mask [Link] [Link]

Figura 16
En la Figura 17 se muestra el comando ejecutado y la tabla de
enrutado con la nueva regla de enrutamiento incorporada.
Adviértase el uso del parámetro -p, en el comando route, para
incorporar la nueva ruta estática como permanente
(persistente).
Una vez incorporada la nueva regla de enrutamiento en R-W7-
R1, el R-W7-1 ya debe obtener la respuesta correspondiente,
del R-W7-R1, a sus solicitudes de eco ICMP, tal y como se
muestra en la Figura 18.
Llegados a este punto, ambos routers disponen de reglas de
enrutado específicas para las subredes a las que no pueden Figura 17
acceder directamente, por no pertenecer a ellas: el R-W7-R1

26-EJERCICIO DE ENRUTAMIENTO CON DOS ROUTERS (II). REDIRECCIÓN. BLS. Curso 2019-2020 Página 6 de 14
dispone de una regla de acceso a la subred [Link]/8 a través de la IP
[Link]/12 y el R-W7-R2 de otra para llegar a la [Link]/16 a través
de la IP [Link]/12.
Según esto, haciendo un ping a la IP del R-UD-1 ([Link]/16), desde el R-
W7-1, deberíamos obtener la respuesta correspondiente. Y exactamente lo
mismo, debería ocurrir, al solicitar un eco a la IP [Link]/8, del R-W7-1, desde
el R-UD-1.
En la Figura 19 se muestran los resultados de ambas peticiones de eco. Figura 18
Al observar las repuestas de los ping obtenidos en la Figura 19, quizá nos llame la atención el hecho de obtener unos valores
de TTL de 62 y 126 para las respuestas del R-UD-1 y del R-W7-1, respectivamente. En primer lugar, debemos recordar que el
valor inicial del TTL de los paquetes, por defecto, en sistemas GNU/Linux es de 64 y en sistemas Windows de 128 y que este
valor lo disminuye, en una unidad, cada uno de los routers por el que atraviesa el paquete IP. Encargándose el router que hace
el TTL cero, de retirar el paquete de la red y, en su caso, de notificar tal circunstancia al nodo origen del paquete.
Eco de respuesta, TTL= 127

Eco de respuesta, TTL= 63

IP: [Link]/12 IP: [Link]/12

IP: [Link]/16 IP: [Link]/8

Eco de respuesta, TTL= 128

Eco de respuesta, TTL= 126
Switch
R-W7-R1 R-172 R-W7-R2

Eco de respuesta,

Eco de respuesta,
TTL= 64

TTL= 62
Switch Switch
R-192 R-10

R-W10-1
IP: [Link]/12

R-UD-1 Respuesta del ping [Link] R-W7-1

IP: [Link]/16 IP: [Link]/8
Respuesta del ping [Link]
Gateway: [Link] Gateway: [Link]

Figura 19 Figura 20
En nuestro caso, las dos respuestas atraviesan dos routers, por lo tanto, ambas se reciben, en sus correspondientes destinos,
con un valor inicial del campo TTL de la trama, disminuido en dos unidades. En la Figura 20 se muestra, gráficamente, la
disminución de cada uno de ellos.
Obviamente, en el caso del ping [Link] desde el R-UD-1, Figura 10, se obtiene un TTL de 127 porque solo se atraviesa
un router, el R-W7-R1.
Una vez configurados los routers y los nodos extremos, le llega el turno al R-W10-1.
6.- R-W10-1.
Lo primero será comprobar que el adaptador de red está configurado, en el VirtualBox, para trabajar en la red interna R-172, que
es la que le corresponde a esta máquina, según el esquema de la Figura 1.
Este equipo presenta la singularidad de encontrarse en la subred que sirve de puente entre las subredes [Link]/16 y
[Link]/8; de forma que dispone de dos caminos posibles para salir de su subred, bien utilizando el R-W7-R1 o bien el R-W7-
R2.
Tal y como están configurados los routers, será absolutamente indiferente, a efectos de funcionamiento, el ponerle como puerta
de enlace la IP de uno o la
del otro.
Empezaremos por
configurarle como puerta
de enlace la IP del R-W7-
R1, [Link] (Figura
21) y estudiaremos que
ocurre.
Lo primero será comprobar
la entrada que genera, en la
tabla de enrutado, la
configuración de una
puerta de enlace en el
entorno gráfico (ejecutando
el comando route print).
En la Figura 22 se
muestran la tabla de
enrutado IPv4 del R-W10- Figura 21 Figura 22

26-EJERCICIO DE ENRUTAMIENTO CON DOS ROUTERS (II). REDIRECCIÓN. BLS. Curso 2019-2020 Página 7 de 14
1; ya que, al tratarse de un sistema de pila dual, TCP/IPv4 y TCP/IPv6, debe disponer de una tabla de enrutado para cada una
de las versiones de direccionamiento IP que soporta.
Ciñéndonos a la tabla de enrutado IPv4, de la Figura
22, comprobaremos que la regla correspondiente a la IP: [Link] IP: [Link]
Máscara: [Link] Switch Máscara: [Link]
puerta de enlace, tiene como “Destino de red” y R-W7-R1 MAC: [Link] R-172 MAC: [Link] R-W7-R2
“Máscara de red” la entrada [Link]; lo que podría
traducirse diciendo que es una regla de enrutado que
tiene como destino cualquiera no conocido, ya que se IP: [Link] IP: [Link]
Máscara: [Link] Máscara: [Link]
utilizará para todos aquellos que carezcan de una MAC: [Link] MAC: [Link]
regla específica en la tabla de enrutado, tal y como 4 1
puede comprobarse en la Figura 12. 2 3 Switch Switch
R-192 R-10
Según esto, cuando R-W10-1 necesite comunicarse
con cualquier IP que no sea de su propia subred, lo
que hará será enviar las tramas a su gateway,
independientemente de su destino final.
Adviértase que la configuración de la puerta de
enlace, a través del entorno gráfico, generó una regla R-W10-1
persistente; apareciendo en la sección IP: [Link]/12
Gateway: [Link]
correspondiente de la Figura 22. MAC: [Link]
R-UD-1 R-W7-1
IP: [Link]/16 IP: [Link]/8
Para comprobar el correcto funcionamiento de la red, Gateway: [Link] Petición de eco Gateway: [Link]
lanzaremos unos ping desde el R-W10-1 hacia el R- MAC: [Link] Eco MAC: [Link]
UD-1 y el R-W7-1 y comprobaremos qué rutas Figura 23
siguen, tanto las peticiones de eco como las
repuestas correspondientes.
a) ping –n 1 [Link] (R-UD-1).
Para realizar la captura de este ping,
será necesario levantar dos sniffers,
uno trabajando sobre la red interna R-
192 y otro sobre la R-172.
Haremos una sola petición de eco (-n
1) para obtener capturas más
cómodas de analizar, ya que las
repeticiones en las peticiones de eco
no añaden nada a nuestro objetivo.
1.- El R-W10-1 analiza la IP destino
que le proporcionamos en la
propia petición de eco y acude a su
tabla de enrutado, comprobando
que la única ruta aplicable al caso,
Figura 12, es la que corresponde a
su puerta de enlace (R-W7-R1). 4
1
Con lo cual compone un paquete
cuya IP de destino sea la Capturas en R-172
[Link] y una trama con la
MAC de destino correspondiente a
la de la interfaz de su subred del
router (probablemente necesite
gestionar un diálogo ARP para
averiguar esta MAC),
[Link]. La IP y la MAC
de origen son las propias. Figura
23-1 y Figura 24-1.
2.- R-W7-R1 recibe la petición de eco
(request) y analiza la IP de destino
que figura en el paquete que
contenía la trama (recuérdese que
los routers hacen gestión a nivel
de red). Recurre a su tabla de
enrutado y se encuentra con que
posee una regla específica para 2 3
alcanzar cualquier IP de la subred
Capturas en R-192
[Link]/16 (Figura 17), en la
que se le indica que debe Figura 24
enrutarla, directamente, a través de su interfaz de IP [Link]. Con esta información compone una nueva trama, en la
que incorpora el paquete recibido, tras restarle 1 al campo TTL del mismo, utilizando como MAC de destino la que le

26-EJERCICIO DE ENRUTAMIENTO CON DOS ROUTERS (II). REDIRECCIÓN. BLS. Curso 2019-2020 Página 8 de 14
 corresponde al R-UD-1, [Link] (quizá necesitara hacer una petición ARP para conocerla) y como MAC origen
coloca la de su interfaz de la subred [Link]/16 ([Link]). Figura 23-2 y Figura 24-2.
3.- El R-UD-1 recibe la petición de eco (request) y la responde. Para ello analiza la IP a la cual debe responderle, [Link],
que será la que conste en el campo IP origen del paquete recibido. Acude a su tabla de enrutado y descubre que debe
enviársela a su gateway (R-W7-R1), con lo cual compone un paquete con la IP de destino [Link] e IP origen la propia.
Este paquete IP lo incorporará en una trama con MAC de destino [Link], que corresponde a la de la interfaz de
su router (quizá gestionará un diálogo ARP para averiguarla) y como MAC de origen la suya. Figura 23-3 y Figura 24-3.
4.- El R-W7-R1 recibe la respuesta del eco (reply) y tras acudir a su tabla de enrutado descubre que tiene una ruta para cualquier
IP de la subred [Link]/12 a través, directamente, de su interfaz de IP [Link]. Con lo cual incorpora el paquete
recibido, tras disminuir en uno su campo TTL, en una nueva trama con la MAC de destino que le corresponde a R-W10-1
([Link].0B. Previamente quizá gestionara un diálogo ARP) y como MAC origen, la de su interfaz de IP [Link]
([Link]). Figura 23-4 y Figura 24-4.
b) ping –n 1 [Link] (R-W7-1).
Para realizar la captura de este ping, será necesario IP: [Link] IP: [Link]
levantar dos sniffers, uno trabajando sobre la red R-W7-R1
Máscara: [Link] Switch Máscara: [Link]
R-W7-R2
MAC: [Link] R-172 MAC: [Link]
interna R-172 y otro sobre la R-10. 2
Haremos una sola petición de eco (-n 1) para obtener
capturas más cómodas de analizar, ya que las IP: [Link] IP: [Link]
Máscara: [Link] Máscara: [Link]
repeticiones en las peticiones de eco no añaden nada MAC: [Link] MAC: [Link]
a nuestro objetivo. 1 5
Switch Switch
4 3
1.- El R-W10-1 analiza la IP destino que le R-192 R-10
proporcionamos en la propia petición de eco y
acude a su tabla de enrutado, comprobando que
la única ruta aplicable al caso, Figura 12, es la que
corresponde a su puerta de enlace (R-W7-R1).
Con lo cual compone un paquete IP cuya IP de
destino sea la [Link] y la IP origen la propia.
R-W10-1
Ese paquete lo incorporará en una trama en la que IP: [Link]/12
figurará como MAC de destino la de la interfaz de Gateway: [Link]
MAC: [Link]
su subred del router (probablemente necesite R-UD-1 R-W7-1
IP: [Link]/16 IP: [Link]/8
gestionar un diálogo ARP para averiguar esta Gateway: [Link] Petición de eco Gateway: [Link]
MAC), [Link]. Siendo la MAC de MAC: [Link] Eco MAC: [Link]
origen la de su propia interfaz. Figura 25-1 y Figura 25
Figura 26-1.
2.- R-W7-R1 recibe la petición
de eco (request) y analiza la
IP de destino que figura en
el paquete que contenía la
trama (recuérdese que los
routers hacen gestión a
nivel de red). Recurre a su
tabla de enrutado y se
encuentra con que posee
una regla específica para 1 Mensaje ICMP de redirección
alcanzar cualquier IP de la
subred [Link]/8 (Figura
17), en la que se le indica
que debe enrutarla a través
de su interfaz de IP
[Link] hacia la
interfaz de IP [Link].
Con esta información
compone una nueva trama,
en la que incorpora el
paquete recibido tras
disminuir en una unidad el
valor de su campo TTL,
utilizando como MAC de
destino la que le
corresponde a la interfaz de
IP [Link] del R-W7-
R2, [Link]
(quizá necesitara hacer una
2 5
petición ARP para
conocerla), incorporando Capturas en R-172
como MAC origen la de su Figura 26

26-EJERCICIO DE ENRUTAMIENTO CON DOS ROUTERS (II). REDIRECCIÓN. BLS. Curso 2019-2020 Página 9 de 14
 interfaz de la subred [Link]/16 ([Link]). Figura 25-2 y Figura 26-2.
Al tiempo que prepara la trama para su envío al R-W7-2, remite al R-W10-1 un mensaje ICMP de redirección (ICMP tipo 5),
Figura 26, cuyo significado se verá, con detalle, más adelante.
3.- R-W7-R2 recibe la petición
de eco (request) y analiza la
IP de destino que figura en
el paquete que contenía la
trama (recuérdese que los
routers hacen gestión a
nivel de red). Recurre a su
tabla de enrutado y se
encuentra con que posee
una regla específica para
alcanzar cualquier IP de la
subred [Link]/8 (Figura
11), en la que se le indica
que debe enrutarla,
directamente, a través de su
interfaz de IP [Link].
Con esta información
3 4
compone una nueva trama
en la que incorpora el Capturas en R-10
paquete recibido, tras Figura 27
restarle uno al valor de su
campo TTL, y dispone como MAC de destino la que le corresponde al R-W7-1, [Link] (quizá necesitara hacer
una petición ARP para conocerla) y como MAC origen coloca la de su interfaz de la subred [Link]/16 ([Link]).
Figura 25-3 y Figura 27-3.
4.- El R-W7-1 recibe la petición de eco (request) y la responde. Para ello analiza la IP a la cual debe responderle, [Link],
que será la que conste en el campo IP origen del paquete recibido. Acude a su tabla de enrutado y descubre que debe
enviársela a su gateway (R-W7-R2), con lo cual compone un paquete, portador del eco solicitado, con la IP de destino
[Link] y su propia IP como IP origen. El paquete lo incorporará a una trama
en la que indicará como MAC de destino la [Link], que corresponde
a la de la interfaz de su router (quizá gestionara un diálogo ARP para averiguarla)
y su propia MAC como origen. Figura 25-4 y Figura 27-4.
5.- El R-W7-R2 recibe la respuesta del eco (reply) y tras acudir a su tabla de
enrutado descubre que tiene una ruta para cualquier IP de la subred
[Link]/12, alcanzables, directamente, a través de su interfaz de IP
[Link]. Con lo cual compone una nueva trama, en la que incorpora el
paquete recibido tras restarle uno al campo TTL del mismo, con la MAC de
destino que le corresponde a R-W10-1 ([Link], quizá, previamente,
gestionara un diálogo ARP) y como MAC origen la de su interfaz de IP
[Link]/12 ([Link]). Figura 25-5 y Figura 26-5.
Obsérvese como, en este caso, a diferencia del anterior, el camino de la petición del
eco no coincide con el del propio eco. Ida y vuelta se realizan por rutas distintas
debido a la configuración del R-W10-1 y de los routers R-W7-R1 y R-W7-R2.
Tal y como se había dicho, configurando el R-W10-1 con la puerta de enlace
[Link] (R-W7-R1), se obtiene la respuesta correspondiente de R-UD-1
Figura 28
IP: [Link] IP: [Link] IP: [Link] IP: [Link]
Máscara: [Link] Switch Máscara: [Link] Máscara: [Link] Switch Máscara: [Link]
R-W7-R1 MAC: [Link] R-172 MAC: [Link] R-W7-R2 R-W7-R1 MAC: [Link] R-172 MAC: [Link] R-W7-R2
2

IP: [Link] IP: [Link] IP: [Link] IP: [Link]

Máscara: [Link] Máscara: [Link] Máscara: [Link] Máscara: [Link]
MAC: [Link] MAC: [Link] MAC: [Link] MAC: [Link]
5 1 1 4
3 4 Switch Switch Switch Switch 3 2
R-192 R-10 R-192 R-10

R-W10-1 R-W10-1
IP: [Link]/12 IP: [Link]/12
Gateway: [Link] Gateway: [Link]
R-UD-1 MAC: [Link] R-W7-1 R-UD-1 MAC: [Link] R-W7-1
IP: [Link]/16 IP: [Link]/8 IP: [Link]/16 IP: [Link]/8
Gateway: [Link] Petición de eco Gateway: [Link] Gateway: [Link] Petición de eco Gateway: [Link]
MAC: [Link] Eco MAC: [Link] MAC: [Link] Eco MAC: [Link]

Rutas del ping [Link] Rutas del ping [Link]

Figura 29

26-EJERCICIO DE ENRUTAMIENTO CON DOS ROUTERS (II). REDIRECCIÓN. BLS. Curso 2019-2020 Página 10 de 14
([Link]/16) y de R-W7-1 ([Link]/8). Pero, ¿qué ocurriría si le configuramos, como puerta de enlace, la IP [Link]
(R-W7-R2)?, Figura 28.
Pues obtendríamos respuesta de ambos nodos, tal y como se muestra en la Figura 30, pero en este caso las rutas, de la petición
de eco y del propio eco, serían las mostradas en la Figura 29. Que corresponden a las inversas de las vistas con anterioridad,
Figura 24 y Figura 25.
A la hora de configurar el R-W10-1 existe la posibilidad de incorporarle, a su tabla
de enrutado, dos nuevas reglas, una para la subred [Link]/16 y otra para la
subred [Link]/8 con lo cual podríamos conseguir que, dependiendo de su destino,
utilizara el R-W7-R1 o el R-W7-R2. Para ello tan solo debemos incorporar, las rutas
indicadas, mediante la ejecución de las órdenes siguientes:
route -p add [Link] mask [Link] [Link]
route -p add [Link] mask [Link] [Link]
Al igual que ocurría en el caso del Windows 7, en el Windows 10 abriendo la consola
con el usuario Jefe, aun formando parte del grupo de los Administradores locales,
no se nos permitirá ejecutar esas órdenes, indicándonos que “La operación
solicitada requiere elevación”. Lo que significa que debemos abrir una consola de
administración, la forma más sencilla de abrirla es acudir al menú Inicio, escribir en
el buscador cmd y en el icono que se presenta, una vez realizada la búsqueda,
Figura 31, seleccionamos la opción “Ejecutar como administrador”, tras lo cual
debemos aceptar que el programa realice cambios en el equipo. En el supuesto de
que se dispusiera del icono de la consola en el menú inicio, se podrá abrir como
administrador acudiendo a la opción “Más” de su menú contextual, botón derecho
del ratón, tal y como se muestra en la Figura 32. Figura 30

Figura 31 Figura 32
Una vez abierta la consola podremos verificar que realmente se trata de una consola de administración porque el directorio de
trabajo, que aparece en la prompt de la misma, será C:\Windows\system32 en lugar del directorio personal del usuario Jefe
(C:\Users\Jefe), al igual que ocurre en los sistemas Windows 7.
En la Figura 33 se muestra las órdenes ejecutadas y el contenido de la tabla de enrutado, una vez incorporadas las nuevas rutas.
En la Figura 34 se dibujan las rutas de los ping, a los nodos [Link]/16 y [Link]/8, utilizando las reglas de enrutado
incorporadas a la tabla de R-W10-1, Figura 33.
Optando por esta solución no haría falta, en este caso
concreto, configurarle ninguna puerta de enlace al R-W10-1,
pues no tiene posibilidad alguna de acceder a ninguna otra
subred, distinta de las contempladas en las reglas
incorporadas a su tabla de enrutado.

IP: [Link] IP: [Link]

Máscara: [Link] Switch Máscara: [Link]
R-W7-R1 MAC: [Link] R-172 MAC: [Link] R-W7-R2

IP: [Link] IP: [Link]

Máscara: [Link] Máscara: [Link]
MAC: [Link]
4 1 1 4 MAC: [Link]
2 3 Switch Switch 3 2
R-192 R-10

R-W10-1
IP: [Link]/12
Gateway: [Link]
R-UD-1 MAC: [Link] R-W7-1
IP: [Link]/16 IP: [Link]/8
Gateway: [Link] Peticiones de eco Gateway: [Link]
MAC: [Link] Ecos MAC: [Link]

Figura 33 Figura 34

26-EJERCICIO DE ENRUTAMIENTO CON DOS ROUTERS (II). REDIRECCIÓN. BLS. Curso 2019-2020 Página 11 de 14
Esta forma de proceder no suele ser habitual en la vida real, ya que editar las tablas de enrutado, de todos y cada uno de los
nodos de una red, puede ser un trabajo muy laborioso y sometido a todo tipo de errores, razón por la cual suele dejarse todo el
trabajo de enrutamiento en manos de los routers y es en ellos, y solo en ellos, en donde se realiza toda la labor de administración
y de establecimiento de las rutas a las distintas redes.
7.- REDIRECCIÓN.
Tal y como se aprecia en la Figura 26,
cuando se le configuró al R-W10-1,
como puerta de enlace, la IP
[Link] (R-W7-R1), en las
capturas del sniffer correspondientes a
las comunicaciones con el R-W7-1 (IP
[Link]/8), aparecía un mensaje
ICMP de redirección, Figura 26
(mensaje ICMP de tipo 5), cuyo
significado y función nos son, de
momento, desconocidos.
Para estudiar el significado de este tipo
de mensajes, lo primero que haremos
será generalizar las circunstancias en
las cuales puede aparecer. Para ello,
configuraremos, en el R-W10-1, la
Figura 35
puerta de enlace [Link]/12,
correspondiente al R-W7-R2, y lanzaremos un ping al R-UD-1 (ping [Link]), capturando el tráfico en R-172 con el filtro
de captura icmp. El resultado de todo ello debe de ser el mostrado en la Figura 35.
Tal y como puede apreciarse, en la Figura 35, también en estas circunstancias aparecen los mensajes ICMP de redirección y,
de acuerdo con la captura del sniffer, aparece uno por cada petición eco que recibe el router, R-W7-R2, desde el R-W10-1.
Empezaremos el análisis por la trama 1 de las recogidas en la Figura 35, como parece evidente esa trama corresponde a la
primera petición de eco que lanza el R-W10-1, cuyo direccionamiento del nivel de enlace de datos tiene como destino su router,
el R-W7-R2, y su campo TTL un valor de 128. El router recibe esa trama y tras verificar la IP destino, del paquete IP que
transporta, acude a su tabla de enrutado, y se encuentra una regla que le indica que para alcanzar cualquier IP de la subred
[Link]/16 debe reenviar el paquete a la interfaz de IP [Link]/12 (R-W7-R1), Figura 11.
Consultada su tabla de enrutado, el R-W7-R1 advierte
que debe realizar ese reenvío hacia otra IP de su propia
subred, subred que comparte con el equipo origen del
paquete que debe enrutar (R-W10-1 de IP
[Link]/12), de manera que le resulta fácil deducir
que lo mejor que puede hacer el R-W10-1, para esta
conexión, es dirigirse directamente al R-W7-R1 y no
importunarlo a él. Convencido de todo ello, se lo
comunica al R-W10-1 a través del mensaje ICMP de
redirección, cuyo contenido se muestra en la Figura 36.
Nótese, en el direccionamiento del nivel de red que,
efectivamente, se trata de un mensaje del R-W7-R1
([Link]/12) para el R-W10-1 ([Link]/12) a
Figura 36
través del cual le informa de que, para la comunicación
en curso, su mejor opción sería enviar los paquetes a la IP [Link] (R-W7-R1) directamente.
Adviértase que, en el caso anterior, Figura 26, era el R-W7-R1 el que le comunicaba al R-W10-1 que, para tal comunicación, su
mejor opción sería el R-W7-R2, señalándole en el mensaje la IP [Link]/12.
Enviada la notificación de redirección al R-W10-1, el R-W7-R2 cumple con su trabajo y reenvía la petición de eco ICMP hacia el
R-WS-R1, tal y como le indica su tabla de enrutado, con un TTL de 127 (trama 3 de la Figura 35).
En la trama 4, de la Figura 35, se recoge la respuesta desde el R-UD-1 ([Link]/16), que, tras pasar por R-W7-R1, la
recibirá el R-W10-1 con un TTL de 63.
Como parece evidente, el mensaje ICMP de redirección enviado por el R-W7-R2 al R-W10-1 tenía como finalidad el que este
último aprendiera la nueva ruta, hacia el R-UD-1, y no volviera a dirigir, al R-W7-R2, las peticiones de eco para el R-UD-1.
A juzgar por la captura mostrada en la Figura 35, el R-W10-1 hizo caso omiso de la información del R-W-R2 y siguió mandando
las peticiones de eco, al R-UD-1, a través del R-WS-R2, lo que provocó que este último le reiterara, a cada petición de eco
recibida, el mensaje ICMP de redirección, tramas 6, 10 y 14.
A la vista de todo ello, la cuestión a dilucidar es por qué el R-W10-1 no tomó nota de la nueva, y más eficaz, ruta hacia el R-UD-
1. Pues la razón se encuentra en el cortafuegos del R-W10-1. Por defecto, la configuración del cortafuegos de los sistemas
Windows no permite conexiones entrantes de mensajes ICMP de redirección (mensajes ICMP tipo 5, Figura 36), ya que la
aceptación de este tipo de mensaje, por los equipos, los hace vulnerables a los denominados ataques de redireccionamiento

26-EJERCICIO DE ENRUTAMIENTO CON DOS ROUTERS (II). REDIRECCIÓN. BLS. Curso 2019-2020 Página 12 de 14
ICMP1, que pueden convertirse en cooperadores necesarios de, por ejemplo, ataques MITM2 (Man In The Middle, hombre en el
medio o ataque de intermediario), ataques pitufo3 (smurf) o su variante Fraggle.
Para probar la capacidad del R-W10-1, de aprender de los mensajes de redirección recibidos, será necesario crear una regla de
entrada, en su cortafuegos, para que acepte tales mensajes ICMP.
Para ello obraremos de forma idéntica a lo hecho para crear la excepción de los ping, pero seleccionando la opción “Redirigir”
en la lista de personalización de la configuración de ICMP, tal y como se muestra en la Figura 37. Una vez seleccionada la opción
indicada, pulsar le tecla Intro, para hacer efectiva la elección, y concluir la configuración de la regla tal y como se hizo con la del
ping.

Figura 37 Figura 38
Establecida la nueva regla, en el cortafuegos del R-W10-1, la probaremos repitiendo el ping al R-UD-1 (ping [Link]) y
capturando los mensajes ICMP en R-172, tal y como se hizo para la realizar la captura mostrada en la Figura 35, recuerde que
el R-W10-1 debe de tener configurado el R-W7-R2 (IP [Link]) como puerta de enlace.
Lanzado el ping [Link], desde el R-W10-1, el resultado de la captura, en R-172, debe de ser el mostrado en la Figura 38.
En él puede comprobarse como, a diferencia de lo ocurrido anteriormente, Figura 35, el R-W7-R2 tan solo lanza un mensaje
ICMP de redirección, trama 2 de la Figura 38, indicándole al R-W10-1 el camino a través del R-W7-R1 (IP [Link]), Figura
36. En esta ocasión el R-W10-1 aprende la nueva ruta y las tres siguientes peticiones de eco ICMP, tramas 5, 7 y 9, las dirige
directamente al R-W7-R1, ya que para ellas no se captura el reenvío R-WS-R2  R-WS-R1 con TTL 127, que sí se ve para la
primera de las peticiones de eco ICMP, trama 3 de la Figura 38.
Del análisis de la captura mostrada en la Figura 38 es fácil deducir que la nueva regla del cortafuegos permite que el R-W10-1
aprenda nuevas reglas de enrutado enviadas a través de los mensajes ICMP de redirección. Las reglas de enrutado así
aprendidas no se guardan en la tabla de enrutado convencional, si no en una caché IP, dispuesta para tal fin, y con una vida de,
aproximadamente, 10 s, de acuerdo con la documentación de Microsoft. Por otro lado, debe señalarse que se almacenan como
reglas de host, lo que las hace específicas para la IP que las generó.
Por último es importante advertir, que nunca debe permitirse que un equipo acepte mensajes de redirección, ya que los riesgos
asumidos superan, con mucho, sus posibles bondades.

1
Véase: [Link]
2
Véase: [Link]
3
Véase: [Link]

26-EJERCICIO DE ENRUTAMIENTO CON DOS ROUTERS (II). REDIRECCIÓN. BLS. Curso 2019-2020 Página 13 de 14
 ANEXO
COMANDO ROUTE (Windows W10)
Manipula tablas de enrutamiento de red.
ROUTE [-f] [-p] [-4|-6] comando [destino] [MASK máscara_red] [puerta_enlace] [METRIC métrica] [IF interfaz]
-f Borra las tablas de enrutamiento de todas las entradas de puerta de enlace. Si se usa junto con uno de los
comandos, se borrarán las tablas antes de ejecutarse el comando.
-p Cuando se usa con el comando ADD, hace una ruta persistente en los arranques del sistema. De manera
predeterminada, las rutas no se conservan cuando se reinicia el sistema. Se pasa por alto para todos los demás
comandos, que siempre afectan a las rutas persistentes apropiadas.
-4 Forzar el uso de IPv4.
-6 Forzar el uso de IPv6.
comando Alguno de los siguientes:
PRINT Imprime una ruta
ADD Agrega una ruta
DELETE Elimina una ruta
CHANGE Modifica una ruta existente
destino Especifica el host.
MASK Especifica que el siguiente parámetro es el valor de 'máscara_red'.
máscara_red Especifica un valor de máscara de subred para esta entrada de ruta. Si no se especifica, se usa de forma
predeterminada el valor [Link].
puerta_enlace Especifica la puerta de enlace.
interfaz El número de interfaz para la ruta especificada.
METRIC Especifica la métrica; por ejemplo, costo para el destino.
Todos los nombres simbólicos usados para el destino se consultan en el archivo de base de datos de red, NETWORKS. Los
nombres simbólicos para la puerta de enlace se consultan en el archivo de base de datos de nombre de host, HOSTS.
Si el comando es PRINT o DELETE, destino o puerta_enlace pueden ser un carácter comodín, (se especifica como un asterisco
'*') o se puede omitir el argumento puerta_enlace.
Si destino contiene un carácter * o ?, se tratará como un modelo del shell y solo se imprimirán las rutas de destino coincidentes.
El carácter '*' coincide con cualquier cadena y '?' coincide con cualquier carácter.
Ejemplos: 157.*.1, 157.*, 127.*, *224*.
La coincidencia de patrones solo se permite en el comando PRINT.
Notas de diagnóstico:
Si MASK no es válido se genera un error, como cuando (DEST & MASK) != DEST
Ejemplo> route ADD [Link] MASK [Link] [Link] IF 1
Error al agregar la ruta: El parámetro de máscara especificado no es válido. (Destino & Máscara) != Destino.
Ejemplos:
> route PRINT
> route PRINT -4
> route PRINT -6
> route PRINT 157* .... solo imprime lo que coincida con 157*
> route ADD [Link] MASK [Link] [Link] METRIC 3 IF 2
destino^ ^mascara ^puerta de ^métrica ^interfaz
enlace del enlace
Si no se proporciona IF, intenta buscar la mejor interfaz para una puerta de enlace específica.
> route ADD 3ffe::/32 3ffe::1
> route CHANGE [Link] MASK [Link] [Link] METRIC 2 IF 2
CHANGE solo se usa para modificar la puerta de enlace o la métrica.
> route DELETE [Link]
> route DELETE 3ffe::/32

26-EJERCICIO DE ENRUTAMIENTO CON DOS ROUTERS (II). REDIRECCIÓN. BLS. Curso 2019-2020 Página 14 de 14