37-Ejercicio Nat Varias Rutas

EJERCICIO DE ENRUTAMIENTO CON VARIAS RUTAS Y NAT EN WINDOWS SERVER 2022 37
R-WS-R1
R-W7-1 IP: 25.0.0.100
IP: 192.168.0.1 Máscara: 255.0.0.0
Máscara: 255.255.255.0 IP: 44.44.0.200
Gateway: 192.168.0.100 Máscara: 255.255.0.0 Switch
IP: 66.16.0.100 R-66
Máscara: 255.255.255.0 R-W7-3
IP: 66.16.0.1
Máscara: 255.255.255.0
R-WS-R4
Gateway: 66.16.0.100
IP: 44.44.0.100
Máscara: 255.255.0.0
IP: 192.168.0.100
Máscara: 255.255.255.0
Switch Switch Switch

R-192 R-44 R-25
66.16.0.0/24 9.0.0.0/24
192.168.0.0/24 66.16.0.0/24
192.168.0.0/24 9.0.0.0/24
R-WS-R2 R-WS-R3
Switch Switch
IP: 35.5.1.100 IP: 9.0.0.100
R-W7-2 R-35 R-9 R-W7-4
Máscara: 255.255.255.0 Máscara: 255.255.255.0
IP: 192.168.0.2 IP: 44.44.0.201 IP: 25.0.0.101 IP: 9.0.0.1
Máscara: 255.255.255.0 Máscara: 255.255.0.0 Máscara: 255.0.0.0 Máscara: 255.255.255.0
Gateway: 192.168.0.100 IP: 35.5.1.101 Gateway: 9.0.0.100
Máscara: 255.255.255.0
Figura 1
Establecer las configuraciones TCP/IP en todas las interfaces de los equipos, tal y como se indica en la Figura 1.
1.- ENRUTAMIENTO SIN NAT EN R-WS-R4.
Lo primero que debemos hacer es definir las rutas, entre subredes finales (nos olvidaremos de las subredes de infraestructura
para uso de los rúteres), que deseamos manejar (Figura 1), para poder estudiar qué reglas de enrutamiento es necesario
incorporar en cada rúter. Una buena herramienta para estructurar las posibles rutas, y que no se nos olvide ninguna, es usar una
tabla como la que sigue.
Subred destino ()
192.168.0.0/24 (R-192) 66.16.0.0/24 (R-66) 9.0.0.0/24 (R-9)
() Subred origen
(R-192)  R-WS-R4  R-WS- (R-192)  R-WS-R4 R-WS-
192.168.0.0/24 (R-192)
R1  (R-66) R2  R-WS-R3  (R-9)
(R-66)  R-WS-R1  R-WS- (R-66)  R-WS-R1  R-WS-
66.16.0.0/24 (R-66)
R4  (R-192) R3  (R-9)
(R-9)  R-WS-R3  R-WS-R2 (R-9)  R-WS-R3  R-WS-R1
9.0.0.0/24 (R-9)
 R-WS-R4  (R-192)  (R-66)
Obsérvese que, en el detalle de las rutas, se tacharon los rúteres terminales, ya que no hay que incorporarles regla alguna, con
respecto a la ruta en cuestión, pues ellos mismos pertenecen a la subred destino.
Para la selección de estas rutas, de entre todas las posibles, se siguió el criterio del menor coste en saltos (etapas de enrutado)
y en caso de igualdad se prefirió aquella que, en el esquema, parece más directa.
De acuerdo con todo lo anterior, habría que introducir las siguientes reglas de enrutamiento en los correspondientes rúteres
(recuerde que se requiere elevación):
R-WS-R4:
192.168.0.0 (R-192)  66.16.0.0 (R-66)
route -p add 66.16.0.0 mask 255.255.255.0 44.44.0.200
192.168.0.0 (R-192)  9.0.0.0 (R-9)
route -p add 9.0.0.0 mask 255.255.255.0 44.44.0.201
Quedando su tabla de enrutado tal y como se muestra en la Figura 2.
R-WS-R1:
66.16.0.0 (R-66)  192.168.0.0 (R-192)
route -p add 192.168.0.0 mask 255.255.255.0 44.44.0.100
66.16.0.0 (R-66)  9.0.0.0 (R-9)
37-EJERCICIO DE ENRUTAMIENTO CON VARIAS RUTAS Y NAT EN WINDOWS SERVER 2022. BLS. Curso 2023-2024 Página 1 de 10
route -p add 9.0.0.0 mask 255.255.255.0 25.0.0.101
R-WS-R2:
192.168.0.0 (R-192)  9.0.0.0 (R-9)
route -p add 9.0.0.0 mask 255.255.255.0 35.5.1.101
9.0.0.0 (R-9)  192.168.0.0 (R-192)
route -p add 192.168.0.0 mask 255.255.255.0 44.44.0.100
R-WS-R3:
9.0.0.0 (R-9)  192.168.0.0 (R-192)
route -p add 192.168.0.0 mask 255.255.255.0 35.5.1.100
9.0.0.0 (R-9)  66.16.0.0 (R-66)
route -p add 66.16.0.0 mask 255.255.255.0 25.0.0.100
Tabla de enrutado de R-WS-R1 Tabla de enrutado de R-WS-R2

Figura 2
En todos los casos, las rutas podrían haberse incorporado utilizando la herramienta gráfica, disponible a través de la herramienta
de administración del servicio de enrutado.
Una vez configurados los rúteres, debe ser posible hacer un tracert entre todos los equipos terminales; y el resultado del mismo
debe coincidir con la ruta propuesta en el análisis. Recuérdese, que puede ser necesario habilitar, en los rúteres, la excepción
ICMP correspondiente a la conexión saliente de tiempo de vida excedido para los paquetes IPv4, en el supuesto de que no lo
esté. En caso contrario no se obtendrá respuesta del rúter, en cuestión, a los comandos tracert.
Resultados de los comandos tracert y ping desde la LAN (R-W7-1 (192.168.0.1/24) o R-W7-2 (192.168.0.2/24)).
Resultados de los comandos tracert y ping desde R-W7-3 (66.16.0.1/24).
Resultados de los comandos tracert y ping desde R-W7-4 (9.0.0.1/24).
Tal y como puede comprobarse en los tracert y ping anteriores, al existir una única ruta entre los distintos orígenes y destinos,
la correlación entre los resultados de los tracert y el valor obtenido para el TTL, de los ping, es perfecta, poniendo de manifiesto
que en las rutas de ida y los caminos de vuelta, los paquetes atraviesan el mismo número de rúteres y, en este caso, idénticos
equipos.
Además, en el caso de los tracert, se constata que coinciden con lo esperado, en función de las reglas de enrutado incorporadas
a cada uno de los rúteres.
R-WS-R1
R-W7-1 IP: 25.0.0.100
IP: 192.168.0.1 Máscara: 255.0.0.0
Máscara: 255.255.255.0 IP: 44.44.0.200
IP: 66.16.0.100 R-66
Máscara: 255.255.255.0 R-W7-3
IP: 66.16.0.1
Máscara: 255.255.255.0
R-WS-R4-NAT
Gateway: 66.16.0.100
IP: 44.44.0.100
Máscara: 255.255.0.0
IP: 192.168.0.100
Máscara: 255.255.255.0

R-192 R-44 R-25
66.16.0.0/24 9.0.0.0/24
44.44.0.0/16 66.16.0.0/24
44.44.0.0/16 9.0.0.0/24
R-WS-R2 Switch R-WS-R3 Switch

IP: 35.5.1.100 IP: 9.0.0.100
R-W7-2 R-35 R-9 R-W7-4
Máscara: 255.255.255.0 Máscara: 255.255.255.0
IP: 192.168.0.2 IP: 44.44.0.201 IP: 25.0.0.101 IP: 9.0.0.1
Máscara: 255.255.255.0
Figura 3
2.- ENRUTAMIENTO CON NAT EN R-WS-R4.
Para realizar esta segunda parte del ejercicio, convertiremos el R-WS-R4 en el R-WS-R4-NAT, Figura 3, mediante la instalación
y configuración del NAT sobre la dirección pública 44.44.0.100/16, por el procedimiento ya conocido.
Una vez configurado el NAT, y reiniciado el servicio de enrutamiento, probaremos el funcionamiento del ping desde la LAN
(R-W7-1 o R-W7-2) a R-W7-3 y comprobaremos que funciona normalmente. Por el contrario, el ping a R-W7-4, también desde
la LAN (R-W7-1 o R-W7-2), dejó de funcionar. ¿Por qué?
Para responder a la pregunta, veamos qué ocurre cuando se estudian las posibles rutas incorporando un enrutamiento NAT a la
salida de la subred 192.168.0.0/24.
La gran diferencia es que una vez funcionando el servicio NAT, en el R-WS-R4-NAT, no circularán por la red tramas, conteniendo
paquetes, con origen o destino en la subred 192.168.0.0/24, esta subred quedará oculta al mundo exterior por la subred
44.44.0.0/16, de manera que no será posible acceder a ella directamente. Según esto, en las tablas que usaremos para estudiar
las posibles rutas, no figurará la subred 192.168.0.0/24 pero sí la 44.44.0.0/16, ya que será, ésta, la entrada a la subred “oculta”
tras el servicio NAT.
En coherencia con esto, el ping a R-W7-4 falla porque R-WS-R3 no sabe llegar a la subred 44.44.0.0/16, ya que la ruta a la
192.168.0.0/24 ya no le es útil. Por el contrario, en el caso del ping a R-W7-3, R-WS-R1 sí sabe llegar a la subred 44.44.0.0/16,
ya que pertenece a ella, y por eso se obtiene la respuesta correspondiente.
En la Figura 4 se muestran las capturas, en R-35 y R-9, correspondientes a un ping -n 1 9.0.0.1 desde R-W7-1, filtradas por
icmp. En ellas puede comprobarse que la petición de eco ICMP llega a R-W7-4, con IP origen 44.44.0.100, y éste responde a
esa IP (Echo reply), respuesta que no es enrutada por R-WS-R3, pues carece de la regla adecuada para poder alcanzar tal
destino y, en consecuencia, nunca llegará a R-W7-1.
R-WS-R3
Captura en la subred 35.5.1.0/24 (R-35) Captura en la subred 9.0.0.0/24 (R-9)

Figura 4
De acuerdo con lo anterior, construiremos una tabla para analizar las nuevas reglas de enrutado a incorporar en los rúteres.
Adviértase que se eliminó toda referencia a la subred 192.168.0.0/24 de la tabla.
Subred destino ()
44.44.0.0/16 (R-44) 66.16.0.0/24 (R-66) 9.0.0.0/24 (R-9)
() Subred origen
(R-44)  R-WS-R1  (R-66) (R-44)  R-WS-R2  R-WS-
44.44.0.0/16 (R-44)
R3  (R-9)
(R-66)  R-WS-R1  (R-44) (R-66)  R-WS-R1  R-WS-
66.16.0.0/24 (R-66)
R3  (R-9)
(R-9)  R-WS-R3  R-WS-R2 (R-9)  R-WS-R3  R-WS-R1
9.0.0.0/24 (R-9)
 (R-44)  (R-66)
Siguiendo el contenido de la tabla, reconfiguraremos los rúteres de la forma siguiente (se recomienda, primero, eliminar todas
las rutas anteriores (route -f) y, posteriormente, reiniciar los rúteres).
R-WS-R4-NAT (las reglas de enrutado en este rúter no cambian):
192.168.0.0 (R-192)  66.16.0.0 (R-66)
route -p add 66.16.0.0 mask 255.255.255.0 44.44.0.200
192.168.0.0 (R-192)  9.0.0.0 (R-9)
route -p add 9.0.0.0 mask 255.255.255.0 44.44.0.201
R-WS-R1:
66.16.0.0 (R-66)  9.0.0.0 (R-9)
route -p add 9.0.0.0 mask 255.255.255.0 25.0.0.101
Tabla de enrutado de R-WS-R3 Tabla de enrutado de R-WS-R4-NAT

Figura 5
R-WS-R2:
44.4.0.0 (R-44)  9.0.0.0 (R-9)
route -p add 9.0.0.0 mask 255.255.255.0 35.5.1.101
R-WS-R3:
9.0.0.0 (R-9)  44.44.0.0 (R-44)
route -p add 44.44.0.0 mask 255.255.0.0 35.5.1.100
9.0.0.0 (R-9)  66.16.0.0 (R-66)
route -p add 66.16.0.0 mask 255.255.255.0 25.0.0.100
Una vez configurados todos los rúteres; tanto el R-W7-1 como el R-W7-2 saldrán con la IP privada 44.44.0.100, tal y como puede
verse en las capturas mostradas en la Figura 6 (realizadas sobre R-44, filtrando por el protocolo ICMP), correspondientes a un
ping desde R-W7-1 (192.168.0.1/24) y R-W7-2 (192.168.0.2/24) a R-W7-3 (66.16.0.1/24) y R-W7-4 (9.0.0.1/24).
a) ping -n 1 66.16.0.1 (tramas 1 y 2) y ping -n 1 9.0.0.1 (tramas 3 y 4) desde b) ping -n 1 66.16.0.1 (tramas 1 y 2) y ping -n 1 9.0.0.1 (tramas 3 y 4) desde
192.168.0.1/24 (R-W7-1). 192.168.0.2/24 (R-W7-2).
Figura 6
Obsérvese, Figura 6, que, tal y como ya se indicó, no circula ninguna trama, por la red pública, conteniendo paquetes con origen
o destino en la subred 192.168.0.0/24.
Al mismo tiempo puede verse, en la Figura 7, como el resultado del tracert desde la LAN (R-W7-1 o R-W7-2) no cambia con
respecto a los obtenidos usando enrutamiento convencional, como es natural, a pesar de haber cambiado las reglas de enrutado
en los rúteres.
Figura 7
Observando las respuestas de los tracert, Figura 7, llama la atención que se obtenga una traza más de las esperadas, ya que
entre la traza correspondiente al R-WS-R4-NAT (IP 192.168.0.100) y el R-WS-R1 (IP 44.44.0.200), en el tracert -d 66.16.0.1, o
el R-WS-R2 (IP 44.44.0.201), en el tracert -d 9.0.0.1, no cabría esperar traza alguna, pues no existe ningún rúter entre ellos.
Para intentar descubrir cuál es el origen de este curioso comportamiento, acudiremos a las capturas, realizadas sobre R-192 y
R-44, que se muestra en la Figura 8, y que corresponde a un tracert a 66.16.0.1/24 desde R-W7-1, con IP 192.168.0.1/24, que
debe salir de la subred privada con la IP pública 44.44.0.100/16.
Captura en R-192 Captura en R-44

Figura 8
Fijándonos en la captura realizada sobre R-192, es fácil deducir que la tramas 1 a 6 corresponden a las peticiones de eco
enviadas con TTL=1, que retira de la red el R-WS-R4, TTL=0, notificándolo desde la IP 192.168.0.100 y que constituyen la
primera traza del tracert, Figura 7.
Las tramas 7 a 9, de las capturadas sobre R-192, corresponden a las peticiones de eco lanzadas por el R-W7-1 con TTL=2, que
se capturan sobre R-44, una vez enrutados los paquetes IPv4, en las tramas 1 a 3. Tal y como puede constatarse esas peticiones
de eco no obtiene respuesta alguna, constituyendo la segunda de las tramas del tracert de la Figura 7. Para saber la razón por
la cual no se obtiene la respuesta esperada, desde la IP 44.44.0.200, del R-WS-R1, debemos fijarnos en la dirección origen de
esos paquetes. Tal y como puede verse en la captura realizada sobre R-44, Figura 8, en la columna source, origen, figura como
IP origen de esos paquetes la IP 192.168.0.1, con lo cual cuando llegan a R-WS-R1 este les hará el TTL=0 y los retirará de la
red, pero cuando va a comunicarlo, al origen de esos paquetes, la IP 192.168.0.1, no le es posible porque, emulando el
comportamiento de los rúteres públicos reales, carece de ruta para las subredes privadas (recuérdese que a R-WS-R1 solo lo
instruimos sobre la ruta a la subred 9.0.0.0/24), con lo cual no puede notificarlo; lo que da como resultado una traza de asteriscos,
al sobrepasar los tiempos de espera (time out) para cada una de las tres peticiones de eco ICMP lanzadas por el equipo de la
LAN.
El origen de este curioso comportamiento se encuentra en un bug del proceso de enrutamiento con NAT del Windows Server
2022, ya presente en versiones anteriores de este sistema operativo, según el cual a los paquetes que recibe con un TTL=2 le
resta 1 a este valor, pero no le hace el SNAT (NAT origen), enviándolos a la red pública con la IP privada original, lo que provoca
que nunca recibiremos respuesta alguna ligada a esos paquetes.
Siguiendo con los errores del NAT en los sistemas Windows Server 2022, cabe indicar que a los paquetes a los que le hace el
NAT, les resta 2, en lugar de 1, y le hace el SNAT correspondiente, este nuevo error es el que permite que en el tracert de la
Figura 7 se obtenga la respuesta desde el R-WS-R1, en la IP 44.44.0.200. Veamos, si acudimos a las capturas realizadas sobre
R-192, de la Figura 8, podremos comprobar como en la trama 10 viaja un paquete con TTL=3, cuando ese paquete es enrutado,
viaja en la trama 4 de la captura realizada sobre R-44 y lo hace con un TTL=1, lo que significa que el R-WS-R4 le restó 2. En
estas condiciones será el R-WS-R4 el que haga el TTL=0 y, por lo tanto, el que comunicará tal circunstancia, desde su IP
44.44.0.200, generando la tercera línea del tracert de la Figura 7.
Exactamente lo mismo podría decirse con respecto a R-WS-R2 en el tracert a 9.0.0.1/24.
Como puede comprobarse en este ejercicio, el NAT permite que el ISP1 (Internet Service Provider, proveedor de servicios de
Internet) se preocupe exclusivamente de su red, sin tener en cuenta, para nada, lo que se haga en las subredes privadas ocultas
tras sus IP públicas.
Una prueba palpable, de la afirmación anterior, puede obtenerse reconfigurando los equipos de la subred 192.168.0.0/24 a la
subred 10.0.0.0/8, por ejemplo, tal y como se muestra en la Figura 9.
R-WS-R1
R-W7-1 IP: 25.0.0.100
IP: 10.0.0.1 Máscara: 255.0.0.0
Máscara: 255.0.0.0 IP: 44.44.0.200
IP: 66.16.0.100
R-66 R-W7-3
Máscara: 255.255.255.0
IP: 66.16.0.1
Máscara: 255.255.255.0
R-WS-R4-NAT
Gateway: 66.16.0.100
IP: 44.44.0.100
Máscara: 255.255.0.0
IP: 10.0.0.100
Máscara: 255.0.0.0

R-10 R-44 R-25
66.16.0.0/24 9.0.0.0/24
44.44.0.0/16 66.16.0.0/24
44.44.0.0/16 9.0.0.0/24
R-WS-R2 Switch R-WS-R3 Switch

IP: 35.5.1.100 IP: 9.0.0.100
R-W7-2 R-35 R-9 R-W7-4
Máscara: 255.255.255.0 Máscara: 255.255.255.0
IP: 10.0.0.2 IP: 44.44.0.201 IP: 25.0.0.101 IP: 9.0.0.1
Máscara: 255.255.255.0
Figura 9
Una vez cambiadas las configuraciones, en las interfaces de red de los equipos de la LAN, podrán ejecutarse los tracert a R-
W7-3 y R-W7-4 desde la LAN (R-W7-1 o R-W7-2), obteniéndose la respuesta correspondiente a cada caso (se recomienda
reiniciar R-WS-R4-NAT después de cambiarle la configuración de la interfaz de la LAN) y mostradas en la Figura 10.
Figura 10
El resultado anterior reitera la independencia de la LAN dentro de la red, siempre y cuando se salga de ella con un enrutamiento
NAT.
3.- EL NAT Y LA REPETICIÓN DE SUBREDES PRIVADAS.
Una de las consecuencias de la independencia de la LAN oculta tras un enrutamiento NAT, es el hecho de que puedan existir
muchos millones de redes locales sobre las mismas subredes privadas, ya que los equipos de cada una de ellas saldrán a la
WAN con una única y singular IP pública, suministrada por el correspondiente ISP (Internet Service Provider, proveedor de
servicios de Internet).
En este ejercicio, la red 44.44.0.0/16, simulará la red pública, concedida por el organismo correspondiente, de nuestro ISP.
Para comprobar la veracidad de este hecho, reconfiguraremos la red según lo mostrado en la Figura 11, en la que existen dos
subredes 10.0.0.0/8, con todas sus direcciones IP duplicadas, ocultas detrás de sus correspondientes rúteres NAT (R-WS-R4-
NAT y R-WS-R5-NAT). Para la virtualización de esta situación es muy importante hacer una segmentación correcta en la
R-WS-R1
IP: 25.0.0.100
R-W7-1
R-WS-R4-NAT Máscara: 255.0.0.0
IP: 10.0.0.1
IP: 44.44.0.100 IP: 44.44.0.200
Máscara: 255.0.0.0
Máscara: 255.255.0.0 Máscara: 255.255.0.0
Gateway: 10.0.0.100
IP: 10.0.0.100 IP: 66.16.0.100 Switch
Máscara: 255.0.0.0 Máscara: 255.255.255.0 R-66 R-W7-3
IP: 66.16.0.1
Máscara: 255.255.255.0
Gateway: 66.16.0.100
Switch
R-10
44.44.0.0/16 66.16.0.0/24 Switch Switch
44.44.0.0/16 9.0.0.0/24 R-44 R-25
Switch
R-10-1 66.16.0.0/24 9.0.0.0/24
Switch
R-35
R-WS-R5-NAT R-WS-R2 R-WS-R3 Switch

IP: 10.0.0.100 IP: 35.5.1.100 IP: 9.0.0.100
R-W7-2 R-9 R-W7-4
Máscara: 255.0.0.0 Máscara: 255.255.255.0 Máscara: 255.255.255.0
IP: 10.0.0.1 IP: 44.44.0.101 IP: 44.44.0.201 IP: 25.0.0.101 IP: 9.0.0.1
Máscara: 255.0.0.0 Máscara: 255.255.0.0 Máscara: 255.255.0.0 Máscara: 255.0.0.0 Máscara: 255.255.255.0
Máscara: 255.255.255.0
Figura 11
infraestructura del VirtualBox, para lo cual se asigna a una
de las subredes 10.0.0.0/8 la red interna R-10 y a la otra
subred 10.0.0.0/8 la R-10-1, tal y como se muestra en la
Figura 11.
Al R-WS-R5-NAT se le configurarán idénticas reglas de
enrutado que al R-WS-R4-NAT, es decir:
192.168.0.0 (R-192)  66.16.0.0 (R-66)
route -p add 66.16.0.0 mask 255.255.255.0 44.44.0.200
192.168.0.0 (R-192)  9.0.0.0 (R-9)
route -p add 9.0.0.0 mask 255.255.255.0 44.44.0.201
Quedando su tabla de enrutado tal y como se muestra en la
Figura 12.
Obviamente a R-WS-R5-NAT hay que habilitarle el NAT
sobre la tarjeta de IP pública (44.44.0.101/16).
Concluida la configuración de los equipos, tanto desde R-
W7-1 como desde R-W7-2 debe ser posible alcanzar a R- Figura 12
W7-3 y a R-W7-4, ya que, a efectos de la WAN, el R-W7-1
será el equipo de IP 44.44.0.100 y el R-W7-2 será el de IP 44.44.0.101, tal y como atestigua la Figura 13; correspondiente a la
captura en R-44 de un ping -n 1 66.16.0.1 desde R-W7-1 (tramas 1 y 2 de la Figura 13) y desde R-W7-2 (tramas 3 y 4 de la
Figura 13).
Como es conocido, el NAT fue, y es, un
mecanismo vital para, por un lado, alargar la
vida útil del direccionamiento IPv4 y, por otro,
permitir la “universalización” del acceso a
Internet. Sin duda este mecanismo plantea
problemas y establece limitaciones, pero fue, y
es, sin vacilar, vital para que las redes e Internet Figura 13
llegaran a ser lo que son en la actualidad.
4.- LIGAR UNA REGLA DE ENRUTADO A UNA INTERFAZ ESPECÍFICA EN SISTEMA WINDOWS.
Tal y como ya se conoce, cuando en un sistema se introduce una regla de enrutado, automáticamente se asocia a la interfaz de
red, del equipo, a través de la cual es alcanzable, directamente, la puerta de enlace indicada en la mencionada regla. Figurando
esta relación en la tabla de enrutado correspondiente.
Normalmente, cuando la nueva regla se introduce a través de la línea de comandos, el establecimiento de esa relación se deja
en manos del propio sistema. Para verificar tal afirmación, bastará con ver cualquiera de las reglas introducidas a lo largo de este
ejercicio, y comprobar que en ninguna de ellas se hace mención alguna a la interfaz de red a la cual se desea ligar la regla en
concreto.
En sistemas Windows, por el contrario, sí es obligatorio indicar esta relación
cuando se utiliza el entorno gráfico, para incorporar la regla de enrutado, tal y
como se muestra en la Figura 14. De hecho, si nos equivocáramos, en la elección
de la interfaz correspondiente, el sistema aceptaría la regla, pero no la
incorporaría a su tabla de enrutado.
En algunas ocasiones, es necesario ligar una regla de enrutado a una interfaz
específica del equipo. Por ejemplo, supóngase un rúter con dos interfaces
configuradas sobre la misma subred, si a ese rúter se le incorporara una ruta con
la puerta de enlace en esa misma subred, ¿a cuál de las dos interfaces posibles
la relacionaría? La respuesta a esta pregunta es, que depende.
Para evitar esta ambigüedad se utiliza el parámetro if (interface, interfaz)
incorporado en la regla de enrutado, de forma paralela al parámetro dev (device,
dispositivo), de los sistemas GNU/Linux, ya conocido. El problema que presenta
el uso de este parámetro, en sistemas Windows, es buscar la referencia a la NIC Figura 14
correspondiente, ya que varía de unos equipos a otros y no existe, como en sistemas GNU/Linux, un nombre simbólico general,
como por ejemplo enp0s3, si no que se trata de un identificador numérico que asigna cada equipo en función de su configuración
específica.
Supongamos que se dispone de un sistema con dos interfaces
configuradas sobre la subred 192.168.0.0/24, con las IP
192.168.0.1/24, en el adaptador Ethernet, y 192.168.0.2/24, en el
Ethernet 2, tal y como se muestra en la Figura 15, y se desea
incorporarle una ruta estática para la subred 55.55.0.0/16 a través de
la puerta de enlace 192.168.0.254/24 de manera tal que ese enlace se
gestione, específicamente, a través de la interfaz configurada con la IP
192.168.0.1/24. En este caso, podría incorporarse la ruta utilizando el
entorno gráfico, si el equipo dispone de él, o bien a través de la línea
de comandos utilizando el parámetro if.
En este segundo supuesto, lo primero que debemos hacer es
averiguar el identificador numérico que el sistema le asignó a la interfaz
que nos interesa. Para ello ejecutaremos un route print, y en el listado
de interfaces, previo a la tabla de enrutado, localizamos el primer
adaptador y leemos el identificador que estábamos buscando que, en
nuestro caso, y de acuerdo con lo mostrado en la Figura 16, sería el Figura 15
15. Con lo cual, la orden para introducir la regla de enrutado, de forma persistente, sería:
route -p add 55.55.0.0 mask 255.255.0.0 192.168.0.254 if 15
Figura 16 Figura 17
Una vez ejecuta la orden, Figura 17, podrá comprobarse, en la tabla de enrutado, que la nueva regla realmente quedó ligada a
la interfaz de IP 192.168.0.1/24, tal y como se deseaba.
Adviértase, en la Figura 16, o en la Figura 17, que a la segunda de las interfaces de red se le asignó el identificador numérico 3
y al bucle local el 1.
5.- NOTAS FINALES.
1
Para ISP, véase: https://es.wikipedia.org/wiki/Proveedor_de_servicios_de_internet

37-Ejercicio Nat Varias Rutas

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

37-Ejercicio Nat Varias Rutas

Cargado por

Copyright:

Formatos disponibles

EJERCICIO DE ENRUTAMIENTO CON VARIAS RUTAS Y NAT EN WINDOWS SERVER 2022 37

Switch Switch Switch

Tabla de enrutado de R-WS-R1 Tabla de enrutado de R-WS-R2

Tabla de enrutado de R-WS-R3 Tabla de enrutado de R-WS-R4

Resultados de los comandos tracert y ping desde R-W7-3 (66.16.0.1/24).

Resultados de los comandos tracert y ping desde R-W7-4 (9.0.0.1/24).

Switch Switch Switch

R-WS-R2 Switch R-WS-R3 Switch

Captura en la subred 35.5.1.0/24 (R-35) Captura en la subred 9.0.0.0/24 (R-9)

Tabla de enrutado de R-WS-R1 Tabla de enrutado de R-WS-R2

Tabla de enrutado de R-WS-R3 Tabla de enrutado de R-WS-R4-NAT

Captura en R-192 Captura en R-44

Switch Switch Switch

R-WS-R2 Switch R-WS-R3 Switch

R-WS-R5-NAT R-WS-R2 R-WS-R3 Switch

También podría gustarte