Introducción
Una aplicación pública de entregas tiene ruta a Internet, dirección pública y permiso HTTP en su grupo de seguridad, pero el cliente A no puede leerla. La ACL de su subred permite el puerto de destino de la solicitud y bloquea el puerto de retorno del cliente. Diagnosticarás y repararás esa ruta, observarás la prioridad de reglas y restaurarás la configuración inicial.
Completa primero Connect Privately to S3 with a VPC Endpoint. Este entorno nuevo suministra su propia aplicación, subredes pública y privada, ruta pública, dirección, grupo y ACL personalizada. La CLI está configurada. Conserva esos recursos y la red de referencia. Modifica solo la regla indicada y elimina la denegación temporal al limpiar. El estado final reproduce intencionadamente el fallo inicial; no elimina la aplicación suministrada.
Relación con certificaciones
Esta práctica básica corresponde a estos temas de examen.
- Cloud Practitioner (CLF-C02) · Tarea 3.5: Funciones básicas de grupos de seguridad y ACL de VPC.
- Solutions Architect – Associate (SAA-C03) · Tarea 1.2: Controles de seguridad de subred y condiciones de acceso a aplicaciones.
- CloudOps Engineer – Associate (SOA-C03) · Tarea 5.3: Diagnóstico de conectividad mediante reglas ACL y puertos de respuesta.
- Advanced Networking – Specialty (ANS-C01) · Tarea 3.1: Práctica básica de reglas ordenadas y comprobación del retorno real.
Inspeccionar el límite de subred de la aplicación
Localiza la aplicación y compara ruta, grupo de seguridad y ACL antes de cambiar nada.
Usa Terminal y abre AWS View al lado. La dirección privada de la aplicación pública es 10.20.1.10. El cliente A es 198.51.100.10 y B es 198.51.100.20. El grupo suministrado concede solo a A TCP 80. El puerto 8081 no tiene autorización de servicio.
cd /home/labex/project
Selecciona la VPC por la etiqueta Name. Los filtros seleccionan recursos, la consulta extrae el ID y $(...) lo guarda:
VPC_ID=$(aws ec2 describe-vpcs \
--filters Name=tag:Name,Values=application-network \
--query 'Vpcs[0].VpcId' \
--output text)
Guarda la subred pública y su interfaz suministrada:
SUBNET_ID=$(aws ec2 describe-subnets \
--filters "Name=vpc-id,Values=$VPC_ID" Name=tag:Name,Values=public-subnet \
--query 'Subnets[0].SubnetId' \
--output text)
ENI_ID=$(aws ec2 describe-network-interfaces \
--filters "Name=subnet-id,Values=$SUBNET_ID" \
--query 'NetworkInterfaces[0].NetworkInterfaceId' \
--output text)
Consulta la dirección privada, asociación pública y grupo adjunto:
aws ec2 describe-network-interfaces \
--network-interface-ids "$ENI_ID" \
--query 'NetworkInterfaces[].{Private:PrivateIpAddress,Public:Association.PublicIp,Groups:Groups}' \
--output json
Consulta la tabla asociada a esa subred:
aws ec2 describe-route-tables \
--filters "Name=association.subnet-id,Values=$SUBNET_ID" \
--query 'RouteTables[].{Routes:Routes,Associations:Associations}' \
--output json
La dirección pública está asociada y la ruta activa 0.0.0.0/0 apunta a una puerta de enlace de Internet. Guarda y consulta el grupo:
GROUP_ID=$(aws ec2 describe-security-groups \
--filters "Name=vpc-id,Values=$VPC_ID" Name=group-name,Values=supplied-application \
--query 'SecurityGroups[0].GroupId' \
--output text)
aws ec2 describe-security-groups \
--group-ids "$GROUP_ID" \
--query 'SecurityGroups[].{Inbound:IpPermissions,Outbound:IpPermissionsEgress}' \
--output json
La entrada permite TCP 80 desde 198.51.100.10/32, con la salida predeterminada suministrada. Conserva estas reglas.
Una ACL de red controla el tráfico que cruza el límite de una subred. Cada subred tiene una ACL; una ACL puede servir a varias. A diferencia de un grupo con estado, la ACL es sin estado: permitir una solicitud no permite automáticamente su respuesta. Selecciona la ACL asociada:
ACL_ID=$(aws ec2 describe-network-acls \
--filters "Name=association.subnet-id,Values=$SUBNET_ID" \
--query 'NetworkAcls[0].NetworkAclId' \
--output text)
Consulta identidad, asociaciones y entradas separadas de entrada y salida:
aws ec2 describe-network-acls \
--network-acl-ids "$ACL_ID" \
--query 'NetworkAcls[].{ID:NetworkAclId,Default:IsDefault,Associations:Associations,Entries:Entries}' \
--output json
Es la ACL personalizada application-acl, no la predeterminada. Su regla 100 permite a A TCP destino 80 en ambas direcciones. Egress: false significa entrada y true, salida. El protocolo 6 es TCP. El tráfico sin coincidencia alcanza la denegación final, * en AWS View y 32767 en CLI.
En AWS View, pulsa Request application · client A: devuelve Connection failed pese a la ruta y el permiso del grupo. Request application · client B y Request port 8081 también fallan. Mantén este Terminal abierto para conservar los ID.
Reparar la regla del puerto de retorno del cliente
Sustituye el puerto de salida incorrecto manteniendo la dirección limitada al cliente.
La solicitud HTTP va del puerto efímero elegido por el cliente al puerto 80 del servidor. La respuesta va del 80 al puerto del cliente. En ambas direcciones, la ACL compara el puerto de destino del paquete. Una regla de salida con destino 80 no admite esa respuesta.
El rango efímero depende del cliente iniciador. En este ejercicio permite el rango común 1024–65535 solo hacia A, 198.51.100.10/32; no es un valor predeterminado universal de los sistemas operativos. Sustituye la regla de salida 100: --egress selecciona salida y --port-range el rango de destino:
aws ec2 replace-network-acl-entry \
--network-acl-id "$ACL_ID" \
--rule-number 100 \
--protocol 6 \
--rule-action allow \
--egress \
--cidr-block 198.51.100.10/32 \
--port-range From=1024,To=65535
Una sustitución correcta no imprime salida. Consulta las entradas:
aws ec2 describe-network-acls \
--network-acl-ids "$ACL_ID" \
--query 'NetworkAcls[].Entries' \
--output json
La entrada 100 sigue permitiendo TCP 80 desde A. La salida 100 permite ahora destinos 1024–65535 hacia el mismo cliente. Las denegaciones predeterminadas y la asociación no cambian.
En AWS View, vuelve a pulsar Request application · client A. La nueva solicitud devuelve Application online, origen 198.51.100.10 y destino 80. Request application · client B y Request port 8081 siguen fallando. La solicitud y su respuesta atraviesan la ACL sin ampliar la entrada del grupo ni de la ACL a otros clientes.
Ejemplo: entrada 100 permite TCP 80 desde A y salida 100 permite destinos de respuesta 1024–65535 hacia A. Ambos sentidos muestran la denegación final y la solicitud real devuelve Application online. Los ID pueden variar.
Observar una denegación de número menor
Inserta intencionadamente una denegación coincidente antes del permiso de entrada para observar la prioridad.
Las reglas se evalúan de menor a mayor en cada dirección. La primera coincidencia decide; las siguientes no se consideran. Añade entrada temporal 90 para denegar TCP 80 desde A. --ingress selecciona entrada; crear 90 no sobrescribe 100:
aws ec2 create-network-acl-entry \
--network-acl-id "$ACL_ID" \
--rule-number 90 \
--protocol 6 \
--rule-action deny \
--ingress \
--cidr-block 198.51.100.10/32 \
--port-range From=80,To=80
Consulta las entradas:
aws ec2 describe-network-acls \
--network-acl-ids "$ACL_ID" \
--query 'NetworkAcls[].Entries' \
--output json
La denegación de entrada 90 coincide antes del permiso 100. La salida 100 sigue admitiendo puertos de retorno y el grupo sigue permitiendo HTTP de A. Ninguno anula la denegación anterior de la ACL.
Cuando AWS View muestre entrada 90, pulsa Request application · client A. La nueva solicitud falla; B y 8081 siguen bloqueados. Un éxito anterior es histórico: solicita de nuevo después de cambiar reglas. Conserva 90 para la comprobación y elimínala en el siguiente paso.
Eliminar la denegación temporal y comprobar el acceso
Elimina solo la denegación anterior y comprueba que el retorno reparado sigue funcionando.
Borra entrada 90. La dirección importa: entrada y salida tienen numeraciones independientes:
aws ec2 delete-network-acl-entry --network-acl-id "$ACL_ID" --rule-number 90 --ingress
Consulta de nuevo:
aws ec2 describe-network-acls \
--network-acl-ids "$ACL_ID" \
--query 'NetworkAcls[].Entries' \
--output json
La regla 90 no existe. Entrada 100 permite TCP 80 de A, salida 100 sus puertos de retorno, y el resto sigue denegado. Conserva asociación original, grupo, ruta y dirección pública.
En AWS View, una nueva Request application · client A devuelve Application online. Request application · client B y Request port 8081 siguen fallando. El grupo con estado permite respuestas de solicitudes admitidas, pero la ACL sin estado necesita ambos sentidos; quitar la denegación restablece este límite independiente.
Restaurar la configuración ACL inicial suministrada
Deshaz el cambio de retorno y confirma que no queda ninguna denegación temporal, conservando los recursos.
Restaura salida 100 al destino 80 suministrado. Esta limpieza reproduce el fallo inicial; no es la regla recomendada para respuestas HTTP funcionales:
aws ec2 replace-network-acl-entry \
--network-acl-id "$ACL_ID" \
--rule-number 100 \
--protocol 6 \
--rule-action allow \
--egress \
--cidr-block 198.51.100.10/32 \
--port-range From=80,To=80
Consulta el inventario completo de ACL de la VPC con sus asociaciones. Las etiquetas eliminables no son prueba suficiente de limpieza:
aws ec2 describe-network-acls \
--filters "Name=vpc-id,Values=$VPC_ID" \
--query 'NetworkAcls[].{ID:NetworkAclId,Default:IsDefault,Associations:Associations,Entries:Entries}' \
--output json
La regla temporal 90 debe faltar. La ACL personalizada sigue asociada a la subred pública. Ambas entradas 100 coinciden con A TCP destino 80; las denegaciones finales permanecen. La subred privada conserva su ACL predeterminada. No borres ni sustituyas ACL, subredes, aplicación, grupo, puerta de enlace ni dirección suministrados.
Consulta el grupo original para confirmar sus reglas:
aws ec2 describe-security-groups \
--group-ids "$GROUP_ID" \
--query 'SecurityGroups[].{Inbound:IpPermissions,Outbound:IpPermissionsEgress}' \
--output json
En AWS View, una nueva Request application · client A vuelve a fallar porque su puerto de retorno ya no está permitido. B y 8081 siguen bloqueados. Un error de API o una red no disponible no prueba limpieza: el inventario autenticado debe funcionar y la ruta configurada real debe producir esos resultados.
Ejecuta la comprobación de este paso.
Resumen
Localizaste la ACL de la aplicación y diagnosticaste el rango de respuesta ausente. La sustitución de salida restauró HTTP real para A mientras otros orígenes y puertos seguían bloqueados. Una denegación de entrada de menor número demostró el orden de primera coincidencia; eliminarla restauró el acceso.
Conservaste grupo, rutas, direcciones y asociaciones, eliminaste la denegación temporal y restauraste la configuración original.
