UNIVERSIDAD CATÓLICA ANDRÉS BELLO
FACULTAD DE INGENIERÍA
ESCUELA DE TELECOMUNICACIONES
Cátedra: Laboratorio de Telemática II
Informe Práctico # 5:
Luis Espinoza 26510403
PRELABORATORIO
1. ¿Qué son las traducciones NAT dinámicas?
La NAT dinámica son un conjunto de direcciones públicas y son asignadas según el orden
de llegada en un router con NAT dinámico. Cuando un dispositivo interno solicita acceso a
una red externa, la NAT dinámica asigna una dirección IPv4 pública disponible del conjunto.
En la figura de abajo observamos que la PC3 accede a internet mediante la primera
dirección disponible del conjunto de NAT dinámica. Las demás direcciones siguen
disponibles para utilizarlas.
Figura 1. NAT Dinámico
2. ¿Qué son los pools IP NAT?
Primeramente, un pool es un conjunto de direcciones IP, que posteriormente podrá ser
utilizada por un servidor, pppoe, dhcp, pptp, …o cualquier otro servicio que precise
asignación dinámica de direcciones IP. Entonces un pool IP NAT son un rango de direcciones
IP que se asignan para la traducción de NAT según sea necesario. Por lo general, este
conjunto es un grupo de direcciones públicas.
Para configurar un pool IP NAT en un router, el comando que se utiliza para ello es el
siguiente:
Ip nat pool nombre primera-ip última-ip {netmask máscara-red | prefijo – length longitud –
prefijo}
Fuente: Cisco Acceso a la WAN, Guía de estudio de CCNA Exploration, pág.262.
([Link]
3. ¿Puede un solo enrutador habilitado para NAT permitir que algunos usuarios usen
NAT
y otros usuarios en la misma interfaz Ethernet para continuar usando sus propias
direcciones IP?
Si, si queremos que un enrutador habilitado con NAT traduzca algunas direcciones IP
privadas a IP públicas para poder tener comunicación desde una red Interna a una red externa
o viceversa, podemos utilizar una lista de acceso (ACL), la cual nos permite bloquear las
PC’s que no deseemos que sean traducidas. Todas las sesiones en el mismo host se traducirán
o pasarán por el enrutador y no se traducirán.
Se pueden utilizar listas de acceso, listas de acceso extendidas y mapas de rutas para
definir reglas mediante las cuales se traducen los dispositivos IP. Siempre se deben
especificar la dirección de red y máscara de subred adecuada. La palabra clave any no debe
usarse en lugar de la dirección de red. Con la configuración de NAT estática, cuando el
paquete no coincide con ninguna configuración estática, el paquete se enviará sin traducción.
4. Cuando un traceroute se realiza a través de un enrutador NAT, ¿debería mostrar la
dirección NAT-Global o debería filtrar la dirección NAT-Local?
Al hacer uso del comando traceroute desde el exterior siempre se debe devolver la
dirección global, porque después del router con NAT es una red externa (Outside). Como
ejemplo esta la siguiente figura:
Si se hace uso del comando traceroute a partir del router NAT la próxima dirección a
mostrar es el próximo salto que este presente para llevar los paquetes del servidor DHCP al
lugar de interés un caso podría ser que la interfaz fa 0/0 del router ISP tenga la direccion
[Link]/24 configurada este será el siguiente salto mostrado al usar tracerotue es
decir una dirección NAT-Global.
5. ¿Qué es una ACL extendida?
Las ACL extendidas proporcionan un mayor control que las ACL estándar. La ACL
extendida permite o deniega el acceso según la dirección IP de origen, la dirección IP de
destino, el tipo de protocolo y los números de puertos. Dado que las ACL extendidas pueden
ser muy específicas, tienen a aumentar su tamaño rápidamente. Cuantas más sentencias
contenga una ACL, más difícil será administrarla.
Ahora bien, las ACL extendidas usan un número de access-list que va de 100 a 199 y 2000
a 2699. Las mismas reglas que se aplican a las ACL estándar se aplican también a las ACL
extendidas. Una diferencia clave en la sintaxis de las ACL extendidas es el requisito de
especificar un protocolo después de la condición de permitir o denegar. Es te protocolo puede
ser IP, e indicar todo el tráfico IP, o puede indicar el filtrado en un protocolo IP específico,
como TCP, UDP, ICMP.
Google Sites (2016, 11 de agosto). CONFIGURACIÓN. ACL extendida numerada.
[Link]
de-routers/9-acls-en-routers-cisco/10-configuracion-acls-extendida-numerada
6. ¿Qué es una máscara WILCARD?
Una máscara wildcard es una máscara de bits que indica qué partes de una dirección de
IP son relevantes para la ejecución de una determinada acción. Las máscaras wildcard y las
máscaras de subred se diferencian en la forma en que establecen la coincidencia entre los
unos y ceros binarios. Las máscaras wildcard utilizan las siguientes reglas para establecer la
coincidencia entre los unos y ceros binarios:
• Bit 0 de máscara wildcard: se establecer la coincidencia con el valor del bit
correspondiente en la dirección.
• Bit 1 de máscara wildcard: se omite el valor del bit correspondiente en la dirección.
En la figura 2, se muestra cómo las diferentes máscaras wildcard filtran las direcciones
IP. Recuerde que, en el ejemplo, el valor binario 0 indica un bit que debe coincidir y el
valor binario 1 indica un bit que se puede ignorar.
Figura 2. Funcionamiento de la Máscara Wildcard
En la tabla de la figura 3, se muestran los resultados de la aplicación de una máscara
wildcard [Link] a una dirección IPv4 de 32 bits. Recuerde que un 0 binario indica un
valor con coincidencia.
Figura 3. Obtención de la Máscara Wildcard
Las máscaras wildcard también se utilizan para configurar algunos protocolos de routing
IPv4, como OSPF, a fin de habilitar el protocolo en interfaces específicas.
7. ¿Cómo se aplica una ACL dentro de la configuración de un router?
ACL´s estándar:
Router(config)# access-list numACL permit |deny origen [wild-mask] → El comando de
configuración access-list define una ACL estándar con un número entre 1 y 99
Se aplican a las interfaces con:
Router(config-if)# ip access-group numACL in|out
• In: Tráfico a filtrar que entra por la interfaz del router
• Out: Tráfico a filtrar que sale por la interfaz del router.
ACL´s extendidas:
Router(config)# access-list numACL {permit|deny} protocolo fuente [mascara-fuente
destino mascara-destino operador operando]
Asociar ACL a la interfaz:
Router(config-if)# ip acess-group numACL {in | out}
Mifsud, Elvira (2012, 12 de septiembre). Listas de control de acceso (ACL) - Utilización de
ACLs en routers.
[Link]
de-control-de-acceso-acl?start=3
LABORATORIO
1.1- Configurar topología de red en GNS3 según los parámetros indicados en la figura 1.1
Figura 1.1 Topología de red NAT dinámico
Antes de pasar con el siguiente punto, se cambio la nube por MV (Kali-Linux) simulando
que es la salida a la red externa, para ello se configuro un ip estática dentro del rango de
direcciones de la red D ([Link]/28) fue la dirección asignada y la que al configurar con
éxito se probo para ver si la conexión era exitosa.
Figura 1.1 Prueba de Conectividad desde PC1 a la MV
Es bueno también analizar la captura de paquetes con Wireshark para que se exhiban todos
los pasos que se ejecutan para establecer la conexión de estos dos dispositivos de la topología
montada.
Figura 1.2 Captura de paquetes con Wireshark
Al observar la captura de paquetes con Wireshark se ve el proceso realizado al utilizar el
comando ping desde PC1, donde se identifican las direcciones ip de cada dispositivo PC1 y
MV, además del protocolo de enrutamiento que se hizo para que toda la topología fuera capaz
de comunicarse. El protocolo de enrutamiento elegido fue el OSPF y se ve el proceso de
envió de los paquetes Hello, los que irán actualizando las tablas de enrutamiento de cada
router de la topología
1.2- Configurar NAT dinámico (dirección IP de traducción 201.X.4.5/28) X = a los 2
últimos números de su cédula.
En la imagen se puede ver la configuración que se realizó en R1 con
el comando show running-config, donde se ve las interfaces del
router con sus ip y el nat que se configuro en cada interfaz y el
protocolo de enrutamiento usado (OSPF) y el pool que se pidió creo,
aquí vemos los pasos indicados en el punto 1.2. Ahora describiré
cada parte sombreada de esta imagen.
• Ip nat inside: las interfaces configuradas son las
fastethernet 0/0 y 0/1, las cuales describen las redes
interiores de la topología
• Ip nat outside: la interfaz configurada (serial 0/0) conecta
la red interna con la externa, permitiendo el acceso de las
PC de las redes A y B para poder acceder a la MV que
simula la red externa.
• Configuración del protocolo OSPF: vemos las redes
conectadas directamente al router y colocamos el comando
router ospf 3, colocando la red, la mascara wildcard y el
área donde queremos que pertenezca.
• Pool público: pueden ser utilizados por cualquier usuario
de un APN si no tienen un medio específico configurado
para obtener la dirección IP. En la misma se definen una
dirección publica para asignar indicada en el documento de
la práctica, descrita en la configuración como ip nat pool
PUBLICO [Link]/28. Las redes a las que se les
permitirán el acceso a la red externa (A y B). También se
traducirán las direcciones que están permitidas por el ACL
con el pool PUBLICO.
1.3- Proceso de NAT dinámico: Con la configuración anterior, en topología de red de la
Figura 1, se muestra el proceso de traducción de NAT entre los clientes (las 4 PC´s)
y el servidor web.
a) Pruebas conectividad de las redes privadas a la red pública. Con el comando tracert
verifica la conectividad entre los clientes y el servidor web. ¿Qué se puede concluir?
Figura 1.3.1 Prueba de conectividad usando el comando trace desde PC4 a la MV
Aquí tenemos la prueba de conectividad realizado en una de las PC que se ubican en las
redes privadas y se ve que con el comando trace usado para GNS3 para describir los saltos
que siguen los paquetes para llegar a su destino, vemos que la cantidad de saltos es 3, lo que
nos indica que no se generan cambios al usar NAT, ya que la misma cantidad de saltos se
mostraron al hacer uso del comando sin el NAT configurado previamente. Es importante que
el pool de direcciones usadas determina que tenemos una red para acceso público, lo que
restringe la capacidad de usuarios que tendrán acceso a la red externa, por el robusto filtrado
que se tiene por lo que, en las demás PC, nos mostrara el mensaje de destino inalcanzable a
la hora de realizar un ping a la dirección de la MV ([Link]/28).
b) Ahora pruebas conectividad del servido a los clientes. Use el comando tracert. ¿Qué
se puede concluir?
Figura 1.3.2 Prueba de conectividad con el comando traceroute
En esta ocasión vemos que si trazamos la ruta hacia la PC desde la que se hizo el primer
ping ([Link]/24) perteneciente a la red B, identificada como la PC4, nos muestra los
saltos a realizar para llegar a la red y finalmente a la PC, pero el uso del ACL como se
mencionó antes hace que los demás hosts de la topología no tengan acceso a la red externa
por lo que al usar el comando traceroute no se concluye que saltos deben realizar para poder
llegar al host destino. Se puede decir que el primer salto es [Link], el segundo salto es
[Link] y el tercer salto es [Link], la última dirección difiere a la de sin NAT, por esto
podemos ver que ocurren conflictos a la hora de el acceso de todos los hosts a la red externa.
El servidor o cualquier host de la parte externa ve a cualquier host cliente de la red interna
con la dirección [Link], cuando deseemos establecer comunicación con la red interna, lo
que causa un conflicto y veamos muchos mensajes de destino inalcanzable.
1.4- Verificación de NAT: con el comando
Router #show ip nat translations
Figura 1.4.1 Verificación de NAT
Ahora pasaremos a ver la captura de paquetes con Wireshark haciendo ping desde el
servidor simulado por la MV virtual para ver que se puede destacar de la misma
Figura 1.4.2 Captura de paquetes Wireshark (servidor – host/cliente)
Se observa que la dirección que responde es la de la red pública ([Link]/28), lo que nos
indica que la configuración del pool público permite el acceso de un host de la red B,
identificado como PC4 ([Link]), donde se ve que la red externa logra comunicarse con
la dirección dada al pool, pero no puede lograr hacer llegar los paquetes al cliente de manera
adecuada por lo que vemos que no existe respuesta. Esto todo es generado por la
configuración NAT realizada en la que un cliente puede comunicarse con una red externa,
pero la red externa no tiene permitido el acceso a las redes internas, lo que es muy
conveniente a nivel de seguridad para no sufrir ataques que puedan perjudicar el buen
funcionamiento de nuestras redes.
Por otro lado, se observa todas las traducciones dinámicas realizadas en el router que
divide las redes interna y externa (R1). El comando muestra todas las traducciones estáticas
que se configuraron y todas las traducciones dinámicas que se crearon a causa del tráfico.
b) También puede utilizar el comando show running-config y buscar los comandos de
NAT, ACL, interfaz o conjunto con los valores requeridos. Examínelos
detenidamente y corrija cualquier error que detecte.
Anteriormente mostré la configuración del R1,
mostrando todo acerca de la configuración del
NAT dinámico, se nos indica que si vemos un
error lo corrijamos, en este caso no existe se
configuro de manera correcta, solo con un alto
nivel restrictivo para los clientes, que si lo
queremos modificar el pool PUBLICO, debe
permitir o dotar de mayor numero de redes
publicas de acceso para que cada host puede ser
capaz de acceder a la red externa.
Segunda sesión: Filtrado de paquetes con ACL (Access Control List)
Las listas de acceso ACL constituyen una eficaz herramienta para el control de la red,
añaden la flexibilidad necesaria para filtrar el flujo de paquetes que entran y sale de las
diferentes interfaces de los router.
Figura 4. Topología de red Filtrado de paquetes
4.1 Configurar topología según los parámetros indicados en la figura2. Puede usar
cualquier protocolo de enrutamiento estudiado en el Laboratorio.
Pasaremos a configurar cada uno de los routers de la topología, con el protocolo de
enrutamiento OSPF, agregando las direcciones pertinentes en cada caso. Además, le
asignaremos las IP a cada PC dependiendo de la zona donde pertenezcan. En la siguiente
imagen se puede apreciar la configuración realizada en el router 1.
Figura 2.1 Configuración R1 (comando show running-config)
Antes de filtrar los paquetes se
muestra que todo esta funcionando
correctamente y los saltos que se
realizan para llegar de una PC a otra.
4.2 Filtrado de paquetes:
– Bloquear los paquetes ICMP de salida del Router1 por la interfaz Serial 0/1
– Bloquear los paquetes ICMP de entrada del Router3 en la interfaz Serial 0/0
– Bloquear los paquetes TCP del servidor Web.
Definiendo mi lista extendida.
Denegar todos los paquetes ICMP de
cualquier origen a cualquier destino.
Asignando a la interfaz serial 0/1 como
salida.
CASO 1: Bloquear los paquetes ICMP de salida del Router1 por la interfaz Serial 0/1
Tenemos como resultado al bloquear los paquetes ICMP de la salida del router 1 por la
interfaz serial 0/1, que se produzca el filtrado de los paquetes lo que no es más que restringir
el acceso de información de un host a otro si se desea en este caso al host de la RED C.
Se observa que se recibe un mensaje de comunicación prohibida, esto ocurre porque el paquete
HELLO se sigue enviando entre la interfaz serial 0/1 de R1 y la interfaz serial 0/0 del R3, lo podemos
comprobar con el comando show ip ospf Neighbor:
Para solucionar la problemática presente, se debe denegar el paquete HELLO que se envía
del router R3 al router R1, donde se debe colocar el siguiente comando en R1:
R1(config-ext-nac1)# deny ospf host [Link] host [Link]
La imagen de la izquierda describe el proceso para denegar el envío de paquetes HELLO,
el que trata de actualizar las tablas de enrutamiento dinámico constantemente y que al tener
este filtro de paquetes no permite que se establezca conexión entre los hosts que involucraban
a la interfaz serial 0/1, al colocar el comando anteriormente expuesto se logro corregir el
problema y que al hacer ping nuevamente (emitir paquetes ICMP) se logre la comunicación
esperada.
CASO 2: Bloquear los paquetes ICMP de entrada del Router3 en la interfaz Serial 0/0
Al conocer el funcionamiento del filtrado de paquetes hecho previamente se puede pasar
directamente a configurar de manera similar, es decir, logrando que los paquetes HELLO no
llegue de R3 a R1.
Figura 2.2 Ping exitosos a host que involucran a la interfaz por donde se filtraron los
paquetes (ICMP)
Poco que agregar se ve que si siguen los pasos de filtrado se debe establecer conexión
entre host sin presentar problemas.
CASO 3: Bloquear los paquetes TCP del servidor Web.
Antes de pasar el proceso de bloqueo de paquetes TCP, se comprueba que el filtrado de
paquetes realizado anteriormente fue deshabilitado con éxito, para ello anteponemos la
palabra no al comando ip access-list extended LAN, y al hacerlo comprobamos que al hacer
un ping la conexión se establezca.
Figura 2.3 Prueba de conectividad desde PC3 a MV (Kali-Linux)
Ahora bien, se procedera a filtar los paquetes TCP desde router 1 para que se muestre el
mensaje prohibitivo al tratar de hacer ping a direcciones que contengan contenido http.
Figura 2.4 Configuración para Filtrado de Paquetes TCP
Se observa que al usar el filtrado de paquetes los
paquetes ICMP generados de PC3 a la MV no
llegaran al destino, se muestran los dos casos
usando el comando ping y el comando trace.
Esto se puede solucionar, pero es importante
decir que de momento no se tiene acceso al
servidor simulado por la MV.
Para solucionar esto haremos algo similar a los casos anteriores con la diferencia que
filtraremos los paquetes ICMP para que si puedan ir desde PC3 a cualquier host de la red A
([Link]/24).
Figura 2.5 Filtrado de Paquetes ICMP
Al realizar el filtrado de los paquetes
ICMP se puede observar que se logra
conectividad entre host y la ruta que
llevan a cabo los paquetes para llegar a
su destino.
Como conclusión de todo lo hecho a lo largo de esta experiencia práctica vemos que NAT
dinámico nos permite decidir quienes tendrán acceso a nuestra red interna y quienes no,
viéndolo desde este punto es una muy buena medida a nivel de seguridad, ya que nos protege
de cualquier ataque que se quiera hacer a nuestra red desde un agente externo. Por otro lado,
el filtrado de paquetes es una manera de decidir que trafico de paquetes queremos dejar pasar
en nuestra red y como deben hacer estos para llegar de un lugar a otro.
Referencias Bibliográficas
• Jairo, Lara, 2021. PRÁCTICA#5 Filtrado de Paquetes y Traducción de Direcciones (NAT)
en Redes IP
• Configuración de NAT Dinámica
• [Link]
• Funcionamiento de ACL de IP
• [Link]
• Filtrado de paquetes
• [Link]
html/[Link]
