AWS Client VPN: la sessió s’inicia, però no s’arriba a la subxarxa

El client diu Connected, el certificat és vàlid i la pàgina de la intranet continua esgotant el temps d’espera. Aquesta diferència gairebé mai no és autenticació. AWS Client VPN autoritza les destinacions per separat de l’inici de sessió, i les dues causes habituals són un valor de grup que no coincideix amb el que va enviar el proveïdor d’identitat i una regla de destinació més específica que guanya la regla àmplia. Totes dues són visibles a la configuració de l’endpoint quan saps on mirar.

La sessió s’ha iniciat; la regla no coincidia

L’autenticació respon qui és l’usuari. Les regles d’autorització responen a quins prefixos de xarxa pot arribar aquesta identitat. Un usuari pot superar la primera i fallar la segona, i el client no et dona gaire més que una connexió que es manté mentre cada petició esgota el temps d’espera.

Comença confirmant que l’endpoint té una regla d’autorització la destinació de la qual conté l’adreça que falla. Si no hi ha cap regla coincident, la connexió es comporta correctament; el que falta és la política.

D’on surt realment el valor del grup

Amb Active Directory, el camp access-group conté el SID del grup, no el seu nom de visualització. Amb federació SAML, conté l’ID o el nom del grup que porta realment l’atribut de grup SAML configurat. Copia el valor de l’assertion o de la consulta al directori, no d’una pàgina wiki.

Un grup IAM és un pla de control diferent. El permís per administrar un endpoint de Client VPN no converteix un grup IAM en el grup VPN de l’usuari, i enganxar un nom de grup IAM al camp access-group no el tradueix a un SID d’AD ni a un valor d’atribut SAML.

Un grup amb un nom semblant en un altre directori no demostra res. Comprova el mètode d’autenticació de l’endpoint i la pertinença o l’assertion de l’usuari en aquest mateix sistema.

Guanya el prefix més llarg, inclòs 0.0.0.0/0

L’autorització s’avalua per la coincidència de prefix més llarga, i la regla de totes les destinacions s’avalua l’última, no la primera. Afegeix una regla 10.46.0.0/16 per a Engineering i una regla 0.0.0.0/0 per a tothom, i un usuari fora d’Engineering continua sense poder arribar a 10.46.20.10 a través de la regla àmplia.

Aquí és on una correcció pot sortir malament. Esborrar la regla estreta restaura l’accés de l’usuari i també concedeix aquesta subxarxa a tota identitat coberta per la regla àmplia. Construeix la matriu de grup a xarxa abans d’esborrar res i anota quins grups han d’arribar a quin rang. Aquestes regles només permeten; no hi ha cap entrada de denegació per retallar una excepció d’un permís ampli.

Els canvis també necessiten una connexió nova per jutjar-se amb justícia. Torna a connectar el client després d’editar les regles i prova de nou.

Separeu l’autorització del camí de dades

Una regla que coincideix no és una ruta. L’endpoint necessita una subxarxa associada i una entrada a la taula de rutes per a la destinació, i el grup de seguretat del recurs objectiu ha d’acceptar el trànsit. El trànsit de retorn i el DNS també han de funcionar.

Prova un usuari que hauria de tenir èxit i un usuari que hauria de quedar exclòs. Tots dos poden iniciar sessió mentre només un arriba a la subxarxa, i aquesta diferència és l’evidència que vols.

Si una adreça IP funciona però un nom d’amfitrió no, mira el resolutor abans de tocar l’autorització. Si cap ruta no cobreix l’adreça, arregla l’associació o la taula de rutes. Si el paquet arriba i el servei el refusa, la política d’aquest servei és la següent parada. Ampliar la matriu d’autorització a tots els usuaris amaga quina d’aquestes capes estava realment trencada.

Abans de tancar el tiquet, registra la font d’identitat, el valor exacte del grup, els prefixos de destinació i la ruta que porta el trànsit. Aquest registre converteix el proper informe de connectat però sense accés en una comparació de dos minuts en lloc d’una altra ronda d’endevinalles.