AWS Client VPN: a sesión iníciase, pero non se chega á subrede

O seu cliente di Connected, o certificado é válido e a páxina da intranet segue esgotando o tempo de espera. Esa fenda case nunca é autenticación. AWS Client VPN autoriza os destinos por separado do inicio de sesión, e as dúas causas habituais son un valor de grupo que non coincide co que enviou o provedor de identidade e unha regra de destino máis específica que gaña á regra ampla. Ambas se ven na configuración do endpoint cando sabe onde mirar.

A sesión iniciouse; a regra non coincidía

A autenticación responde quen é o usuario. As regras de autorización responden a que prefixos de rede pode chegar esa identidade. Un usuario pode superar a primeira e fallar na segunda, e o cliente non lle dá moito máis que unha conexión que se mantén mentres cada petición esgota o tempo de espera.

Comece confirmando que o endpoint ten unha regra de autorización cuxo destino contén o enderezo que falla. Se non hai ningunha regra coincidente, a conexión compórtase correctamente; o que falta é a política.

De onde vén realmente o valor do grupo

Con Active Directory, o campo access-group contén o SID do grupo, non o seu nome de visualización. Con federación SAML, contén o ID ou o nome do grupo que realmente leva o atributo de grupo SAML configurado. Copie o valor da assertion ou da consulta ao directorio, non dunha páxina wiki.

Un grupo de IAM é outro plano de control. O permiso para administrar un endpoint de Client VPN non converte un grupo de IAM no grupo VPN dun usuario, e pegar un nome de grupo de IAM no campo access-group non o traduce a un SID de AD nin a un valor de atributo SAML.

Un grupo cun nome semellante noutro directorio non demostra nada. Comprobe o método de autenticación do endpoint e a pertenza ou a assertion do usuario nese mesmo sistema.

Gaña o prefixo máis longo, incluído 0.0.0.0/0

A autorización avalíase pola coincidencia de prefixo máis longa, e a regra de todos os destinos avalíase ao final, non primeiro. Engada unha regra 10.46.0.0/16 para Engineering e unha regra 0.0.0.0/0 para todos, e un usuario fóra de Engineering segue sen poder chegar a 10.46.20.10 mediante a regra ampla.

Aquí é onde unha corrección pode saír mal. Borrar a regra estreita restaura o acceso do usuario e ademais concede esa subrede a toda identidade cuberta pola regra ampla. Construíu a matriz de grupo a rede antes de borrar nada e anote que grupos deben chegar a que rango. Estas regras só permiten; non hai entrada de denegación para recortar unha excepción dun permiso amplo.

Os cambios tamén necesitan unha conexión nova para xulgarse con xustiza. Volva conectar o cliente despois de editar as regras e probe de novo.

Separe a autorización da ruta de datos

Unha regra que coincide non é unha ruta. O endpoint necesita unha subrede asociada e unha entrada na táboa de rutas para o destino, e o grupo de seguridade do recurso de destino debe aceptar o tráfico. O tráfico de retorno e o DNS tamén teñen que funcionar.

Probe un usuario que debería ter éxito e un usuario que debería quedar excluído. Ambos poden iniciar sesión mentres só un chega á subrede, e esa diferenza é a evidencia que busca.

Se un enderezo IP funciona pero un nome de host non, mire o resolutor antes de tocar a autorización. Se ningunha ruta cobre o enderezo, corrixa a asociación ou a táboa de rutas. Se o paquete chega e o servizo rexéitao, a política dese servizo é a seguinte parada. Ampliar a matriz de autorización a todos os usuarios oculta cal desas capas estaba realmente rota.

Antes de pechar o ticket, rexistre a orixe de identidade, o valor exacto do grupo, os prefixos de destino e a ruta que transporta o tráfico. Ese rexistro converte o seguinte informe de conectado pero sen acceso nunha comparación de dous minutos no canto doutra rolda de conxecturas.