Autenticación de AWS Client VPN: los permisos de IAM no son un método de inicio de sesión

Conceder a un usuario permiso para crear o describir un punto de enlace de AWS Client VPN no le permite conectarse a él. Son dos tipos distintos de identidad: IAM gobierna las llamadas a la API de AWS y el punto de enlace solo acepta los métodos de autenticación de cliente configurados en él. Así, un usuario puede tener amplios derechos en la consola y aun así no tener nada que el cliente VPN pueda presentar. Decida qué método confía el punto de enlace y luego decida si un túnel completo es la forma adecuada para el acceso que concede.

Una identidad de API no es una identidad de túnel

Cuando alguien dice «el rol de IAM está adjunto, por qué sigue fallando la VPN», la respuesta suele ser que ningún paso del flujo de conexión lee nunca ese rol. El cliente presenta un certificado, un nombre de usuario y una contraseña de AD, o una aserción SAML. El punto de enlace valida uno de ellos y después asigna una dirección.

IAM sigue importando, solo que más tarde y en otro lugar: crear el punto de enlace, asociar subredes, publicar rutas y escribir reglas de autorización son acciones de API. Mantenga esos permisos limitados a los operadores que los necesitan en lugar de dar a cada usuario la capacidad de reescribir las reglas de acceso del punto de enlace.

Elija entre los métodos que admite el punto de enlace

AWS Client VPN acepta autenticación mutua basada en certificado, autenticación de Active Directory y autenticación federada basada en SAML. Se requiere un certificado de servidor independientemente del método de cliente que elija, y una configuración que combine métodos exige que ambos tengan éxito, no uno.

Los certificados son los más baratos de implantar y los más fáciles de equivocar a escala, porque cada usuario necesita una credencial y cada salida necesita una revocación. La autenticación de directorio traslada ese ciclo de vida a un sistema existente. La federación lo traslada a un proveedor de identidad y añade un paso de navegador al cliente.

Lea la configuración del propio punto de enlace antes de depurar el cliente. Si la autenticación mutua está habilitada junto con un método basado en usuario, un cliente con un certificado válido pero sin cuenta de directorio seguirá fallando, y el error suele parecer un problema genérico de negociación.

La federación no es pasar claves de acceso

Una configuración SAML no introduce claves de acceso de IAM ni un token de rol asumido en el túnel. El proveedor de identidad autentica a la persona, devuelve una aserción y el punto de enlace la acepta bajo la confianza que haya configurado. La sesión resultante es una sesión VPN, no una sesión de la API de AWS.

Esa distinción decide quién puede diagnosticar qué. Los problemas del IdP aparecen como un error de navegador o de cliente antes de que exista ningún túnel, mientras que los problemas del túnel aparecen después de una aserción correcta. Pregunte cuál de los dos está mirando antes de abrir cualquiera de las dos consolas.

Después del inicio de sesión, las rutas y la autorización siguen decidiendo

La autenticación da una dirección a la sesión; no le da un destino. Las rutas del punto de enlace dicen al cliente a qué subredes enviar, las reglas de autorización deciden qué usuarios pueden llegar a cuáles de esas subredes, y los grupos de seguridad y los propios permisos del destino deciden el resto.

Por eso un usuario que se autentica correctamente puede seguir sin llegar a una base de datos. Compruebe la asociación de la tabla de rutas para la subred, la regla de autorización para el grupo del usuario y el grupo de seguridad en el destino en ese orden, porque cada uno produce un tipo distinto de tiempo de espera.

Para una base de datos privada, compare con la redirección de puertos

Si la tarea real es una conexión aprobada a una única base de datos privada, un túnel de red completo es una opción y no un requisito. AWS Systems Manager Session Manager puede abrir una sesión de redirección de puertos hacia un nodo administrado mediante IAM, y ese nodo llega a la base de datos en la red privada. El usuario nunca recibe una dirección VPC. El nodo administrado se convierte en el único host que puede llegar al puerto de la base de datos, que suele ser lo que pedía la revisión de seguridad. Después, los usuarios necesitan un cliente local y un comando de sesión en lugar de un perfil de VPN.

El intercambio es alcance frente a requisitos previos. La redirección de puertos necesita el agente SSM en el nodo administrado, accesibilidad de red desde ese nodo hasta la base de datos, el complemento de Session Manager en la máquina del usuario y permiso para iniciar esa sesión concreta. No es una ruta hacia todas las subredes y no transportará protocolos arbitrarios como lo hace un túnel.

En cualquier caso, mantenga la identidad propia de la base de datos. La verificación TLS y la autenticación de la base de datos no desaparecen porque la ruta se haya autorizado mediante IAM, y una sesión aprobada no dice nada sobre qué tablas puede leer el usuario.

Elija según el alcance y el ciclo de vida: un túnel cuando muchos usuarios necesitan muchos destinos y puede gestionar el ciclo de vida de certificados o de directorio; una sesión de redirección cuando un puñado de personas necesitan un solo servicio y prefiere no repartir direcciones de red. En cualquier caso, registre el método de autenticación, la regla de autorización y el inicio de sesión de la base de datos como tres hechos separados, porque fallan por separado.