Una ACL en R1 contiene solo estas entradas:
access-list 101 permit tcp 10.10.10.0 0.0.0.255 any eq 443 access-list 101 permit icmp any any
¿Qué le sucede a un paquete HTTP originado en 10.10.10.25 y con destino a 198.51.100.10 si se aplica la ACL 101 en la ruta del tráfico?
Elige la mejor respuesta.
Respuesta correcta
HTTP utiliza el puerto TCP 80, no el 443. Debido a que la ACL no incluye un permiso para ese tráfico, es descartado por el deny implícito al final de la ACL. La entrada de ICMP no es relevante porque el paquete es TCP.
Se permite porque la subred de origen está permitida.
La ACL no permite de forma general la subred de origen; utiliza una entrada de ACL extendida que permite únicamente tráfico TCP destinado al puerto 443, no todo el tráfico de esa subred. Un paquete HTTP de esa subred tiene como destino el puerto 80, lo que no cumple con la condición de puerto de destino de la única sentencia permit de TCP. Dado que la subred de origen por sí sola no es suficiente para coincidir con la ACL, el paquete no es permitido por dicha sentencia y cae en el deny implícito al final de la ACL 101.
Es denegado por el deny implícito.
El paquete HTTP, que utiliza el puerto TCP 80, no coincide con la primera entrada de la ACL, la cual permite específicamente tráfico TCP solo para el puerto de destino 443. Tampoco coincide con la segunda entrada, que permite tráfico ICMP. Como el paquete no coincide con ninguna sentencia `permit` explícita dentro de la ACL 101, es procesado por el `deny ip any any` implícito que existe al final de cada lista de control de acceso de Cisco. Este mecanismo asegura que el paquete HTTP sea denegado.
Es traducido por NAT antes de que se verifique la ACL.
Esta opción aplica incorrectamente el rol de NAT en el filtrado de paquetes. En Cisco IOS, el orden de procesamiento de NAT y ACL depende de la interfaz y la dirección (por ejemplo, el NAT inside puede ocurrir antes de una ACL saliente), pero no se proporciona ninguna configuración de NAT en el escenario. Incluso si NAT estuviera presente, solo reescribiría las direcciones IP, no el puerto de destino TCP del HTTP 80 al HTTPS 443. Por lo tanto, el paquete sigue sin coincidir con el permit explícito para el puerto 443 y finalmente es denegado por el deny implícito.
Se convierte a HTTPS automáticamente.
Los routers no reescriben automáticamente protocolos de capa de aplicación ni cambian puertos de destino. HTTP y HTTPS son protocolos distintos que utilizan diferentes puertos TCP (80 frente a 443), y la ACL evalúa el puerto de destino literal en la cabecera del paquete. A menos que se configure una pasarela de nivel de aplicación o una regla de inspección explícita para alterar el puerto —lo cual no está presente en este escenario exclusivo de ACL—, el paquete HTTP permanece en el puerto 80 y no puede coincidir con el permit para 443. En consecuencia, el paquete viola el deny implícito y es descartado.
Las Access Control Lists (ACLs) son herramientas de seguridad fundamentales en redes Cisco que filtran el tráfico según criterios definidos, como direcciones IP de origen y destino, protocolos y números de puerto. Las ACLs se procesan de forma secuencial y, una vez que un paquete coincide con una entrada, la acción correspondiente de permit o deny se aplica de inmediato. Si ninguna entrada coincide, un deny implícito al final de la ACL descarta el paquete por defecto. Este comportamiento garantiza que solo pase el tráfico explícitamente permitido, lo que mejora la seguridad de la red y el control del tráfico. En este escenario, la ACL 101 permite tráfico TCP originado en la subred 10.10.10.0/24 solo si tiene como destino cualquier dirección en el puerto 443 (HTTPS). También permite todo el tráfico ICMP sin importar el origen o el destino. Dado que el tráfico HTTP utiliza el puerto TCP 80, un paquete de 10.10.10.25 a 198.51.100.10 en el puerto 80 no coincide con ninguna sentencia permit. En consecuencia, la regla de deny implícito de la ACL bloquea este paquete HTTP. Esto demuestra la importancia de especificar los protocolos y puertos correctos en las ACLs para evitar descartes de tráfico no deseados. Una trampa común en el examen es asumir que permitir una subred en una ACL permite automáticamente todo el tráfico de esa subred. Sin embargo, las ACLs son explícitas y requieren coincidencias exactas en el protocolo y los números de puerto. Otra trampa es malinterpretar la regla de deny implícito, la cual descarta silenciosamente los paquetes que no coinciden sin generar registros por defecto. En la práctica, esto significa que los administradores de red deben diseñar cuidadosamente las ACLs para incluir todas las sentencias permit necesarias y comprender que cualquier tráfico que no esté explícitamente permitido será denegado, lo que garantiza un comportamiento de red predecible y seguro.
Sobre estas preguntas de práctica
Esta es una de las preguntas de práctica originales de 200-301 de Courseiva, escrita para aprender y nunca copiada de exámenes reales ni de dumps.
Traducida del original en inglés con IA y revisada para comprobar el sentido. Los códigos de examen, los comandos y los nombres de productos se mantienen tal como aparecen en el examen.