Las reglas de AWS Client VPN van en el recurso, no en la subred

El personal necesita llegar a una aplicación en la VPC y no debe llegar al listener de base de datos de la misma instancia, así que alguien añade una segunda subred pública para el endpoint de VPN y da el requisito por cumplido. La ubicación de la subred cambia el enrutamiento y la disponibilidad. No concede ni niega un solo puerto. El permiso que expresa el requisito vive en el destino, en el grupo de seguridad del recurso, y el límite de la VPN aporta el asa a la que se refiere esa regla.

La ubicación de la subred es enrutamiento, no autorización

Dónde se sitúa la asociación de red del endpoint decide qué tabla de rutas transporta el tráfico de los clientes y qué zonas de disponibilidad sobreviven a un fallo. No dice nada sobre qué puerto de qué instancia puede alcanzar ese tráfico. Dos clientes asociados a la misma subred siguen llegando con la misma identidad de origen, y el recurso no puede distinguirlos por el nombre de la subred.

Empieza mejor por el requisito: quién llama, qué recurso, qué puerto de servicio y en qué dirección. Después elige el modelo de regla que pueda expresar esas cuatro cosas en el destino. Ese planteamiento suele eliminar por completo la subred adicional del diseño.

El grupo de asociación de Client VPN es el asa

Para un endpoint de AWS Client VPN asociado a una subred, la disposición documentada es concreta. Aplica el grupo de seguridad previsto a las asociaciones de red de destino del endpoint y luego permite el tráfico necesario en el grupo de seguridad del recurso usando ese grupo de Client VPN como origen.

En concreto, el grupo de la instancia de aplicación permite el puerto de la aplicación desde el grupo de asociación, y nada más. El procedimiento de acceso al recurso de AWS describe esa relación, y conviene mantener la misma política de grupo en cada subred con la que se asocia el endpoint, porque una asociación obsoleta con un grupo distinto amplía el límite sin hacer ruido.

Esa regla no autentica a nadie. El inicio de sesión es un control aparte, y la ruta hasta el recurso es un tercero. Los tres deben cumplirse antes de que llegue una petición. El que falle decide qué corrección es la correcta, y cambiar la regla es la respuesta acertada solo para el primero.

Lo que un solo grupo de asociación no puede distinguir

Cada cliente detrás del mismo grupo de asociación llega al recurso como el mismo origen de grupo de seguridad. Dos usuarios con roles distintos son indistinguibles en esa capa, por mucho que se nombre o etiquete el grupo. La autorización de grupos externos de Client VPN limita el acceso por prefijo de destino para un grupo de directorio o SAML, lo que es más grueso que un rol de recurso y debe tratarse como un límite de red, no como un sistema de identidad.

Las distinciones más finas pertenecen a la aplicación. Un listener de base de datos que debe permanecer cerrado para la mayoría del personal está mejor protegido si no es accesible en absoluto en el prefijo permitido que si se espera que la pertenencia al grupo siga ordenada.

Renombrar el grupo no crea una identidad, y duplicarlo por equipo solo multiplica las asociaciones que hay que auditar.

No copies esa regla en todos los diseños de VPN

Una puerta de enlace EC2 VPN autogestionada, un dispositivo de inspección enrutado y un Client VPN gestionado son tres rutas de paquetes distintas. Establece qué dirección de origen llega realmente al recurso, si hay traducción por medio y qué mecanismos de referencia admite el servicio en esa ruta.

Reenviar el tráfico por un dispositivo intermedio no conserva una referencia de grupo de seguridad de origen como lo hace el tráfico directo entre instancias. AWS documenta que esos diseños pueden necesitar las direcciones privadas de origen o los CIDR adecuados en lugar de una referencia de grupo. El procedimiento de Client VPN gestionado no demuestra que el grupo adjunto de cada puerta de enlace funcione como un token de identidad universal para los paquetes reenviados.

Un solo salto NAT en la ruta basta para romper la suposición, y el fallo parece una regla que está presente pero nunca coincide.

Revisa el límite efectivo

Lee cada grupo de seguridad adjunto al recurso, porque las reglas de permiso se combinan y una regla estrecha no anula otra más amplia en otro grupo. Después comprueba la ACL de red, el cortafuegos del host y la autorización propia de la aplicación, que son capas separadas con errores separados.

Termina con una petición permitida y otra deliberadamente excluida contra el mismo recurso. La pareja demuestra el límite, mientras que una única conexión correcta solo demuestra que algo está abierto. Confirma la ruta, el origen efectivo y el puerto de servicio previsto, no la subred que contiene el endpoint.

Orden de trabajo: escribe el requisito de cuatro partes, adjunta el grupo a las asociaciones, limita la regla del recurso al puerto, verifica un permiso y una denegación, y solo entonces plantea dividir subredes por motivos de enrutamiento.