AWS Client VPN: la sesión se inicia, pero no se llega a la subred

Su cliente dice Connected, el certificado es válido y la página de la intranet sigue agotando el tiempo de espera. Esa brecha casi nunca es autenticación. AWS Client VPN autoriza los destinos por separado del inicio de sesión, y las dos causas habituales son un valor de grupo que no coincide con lo que envió el proveedor de identidad y una regla de destino más específica que gana a la regla amplia. Ambas se ven en la configuración del endpoint cuando sabe dónde mirar.

La sesión se inició; la regla no coincidía

La autenticación responde quién es el usuario. Las reglas de autorización responden a qué prefijos de red puede llegar esa identidad. Un usuario puede superar la primera y fallar en la segunda, y el cliente no le da mucho más que una conexión que se mantiene mientras cada petición agota el tiempo de espera.

Empiece confirmando que el endpoint tiene una regla de autorización cuya destino contiene la dirección que falla. Si no hay ninguna regla coincidente, la conexión se comporta correctamente; lo que falta es la política.

De dónde sale realmente el valor del grupo

Con Active Directory, el campo access-group contiene el SID del grupo, no su nombre para mostrar. Con federación SAML, contiene el ID o el nombre del grupo que realmente lleva el atributo de grupo SAML configurado. Copie el valor de la assertion o de la consulta al directorio, no de una página wiki.

Un grupo de IAM es otro plano de control. El permiso para administrar un endpoint de Client VPN no convierte un grupo de IAM en el grupo VPN de un usuario, y pegar un nombre de grupo de IAM en el campo access-group no lo traduce a un SID de AD ni a un valor de atributo SAML.

Un grupo con un nombre parecido en otro directorio no demuestra nada. Compruebe el método de autenticación del endpoint y la pertenencia o la assertion del usuario en ese mismo sistema.

Gana el prefijo más largo, incluido 0.0.0.0/0

La autorización se evalúa por la coincidencia de prefijo más larga, y la regla de todos los destinos se evalúa al final, no primero. Añada una regla 10.46.0.0/16 para Engineering y una regla 0.0.0.0/0 para todos, y un usuario fuera de Engineering sigue sin poder llegar a 10.46.20.10 mediante la regla amplia.

Aquí es donde una corrección puede salir mal. Borrar la regla estrecha restaura el acceso del usuario y además concede esa subred a toda identidad cubierta por la regla amplia. Construya la matriz de grupo a red antes de borrar nada y anote qué grupos deben llegar a qué rango. Estas reglas solo permiten; no hay entrada de denegación para recortar una excepción de un permiso amplio.

Los cambios también necesitan una conexión nueva para juzgarse con justicia. Vuelva a conectar el cliente después de editar las reglas y pruebe de nuevo.

Separe la autorización de la ruta de datos

Una regla que coincide no es una ruta. El endpoint necesita una subred asociada y una entrada en la tabla de rutas para el destino, y el grupo de seguridad del recurso de destino debe aceptar el tráfico. El tráfico de retorno y el DNS también tienen que funcionar.

Pruebe un usuario que debería tener éxito y un usuario que debería quedar excluido. Ambos pueden iniciar sesión mientras solo uno llega a la subred, y esa diferencia es la evidencia que busca.

Si una dirección IP funciona pero un nombre de host no, mire el resolutor antes de tocar la autorización. Si ninguna ruta cubre la dirección, corrija la asociación o la tabla de rutas. Si el paquete llega y el servicio lo rechaza, la política de ese servicio es la siguiente parada. Ampliar la matriz de autorización a todos los usuarios oculta cuál de esas capas estaba realmente rota.

Antes de cerrar el ticket, registre el origen de identidad, el valor exacto del grupo, los prefijos de destino y la ruta que transporta el tráfico. Ese registro convierte el siguiente informe de conectado pero sin acceso en una comparación de dos minutos en lugar de otra ronda de conjeturas.