AWS Client VPN : la connexion aboutit, mais le sous-réseau reste inaccessible
Une connexion réussie à AWS Client VPN n’autorise pas chaque sous-réseau. Vérifiez la valeur du groupe et la règle de destination la plus spécifique avant d’élargir l’accès.
Votre client affiche Connected, le certificat est valide et la page intranet expire toujours. Cet écart n’est presque jamais l’authentification. AWS Client VPN autorise les destinations séparément de la connexion, et les deux causes habituelles sont une valeur de groupe qui ne correspond pas à ce que le fournisseur d’identité a envoyé et une règle de destination plus spécifique qui l’emporte sur la règle large. Les deux sont visibles dans la configuration du point de terminaison quand on sait où regarder.
La connexion a réussi ; la règle ne correspondait pas
L’authentification répond à la question de savoir qui est l’utilisateur. Les règles d’autorisation répondent à celle des préfixes réseau que cette identité peut atteindre. Un utilisateur peut réussir la première et échouer à la seconde, et le client ne vous donne guère plus qu’une connexion qui reste établie pendant que chaque requête expire.
Commencez par confirmer que le point de terminaison possède une règle d’autorisation dont la destination contient l’adresse en échec. S’il n’existe aucune règle correspondante, la connexion se comporte correctement ; c’est la politique qui manque.
D’où vient réellement la valeur du groupe
Avec Active Directory, le champ access-group contient le SID du groupe, pas son nom d’affichage. Avec la fédération SAML, il contient l’ID ou le nom du groupe que l’attribut de groupe SAML configuré transporte réellement. Copiez la valeur depuis l’assertion ou depuis l’interrogation de l’annuaire, pas depuis une page wiki.
Un groupe IAM est un autre plan de contrôle. L’autorisation d’administrer un point de terminaison Client VPN ne fait pas d’un groupe IAM le groupe VPN d’un utilisateur, et coller un nom de groupe IAM dans le champ access-group ne le traduit ni en SID AD ni en valeur d’attribut SAML.
Un groupe au nom similaire dans un autre annuaire ne prouve rien. Vérifiez la méthode d’authentification du point de terminaison et l’appartenance ou l’assertion de l’utilisateur dans ce même système.
Le préfixe le plus long l’emporte, y compris 0.0.0.0/0
L’autorisation est évaluée selon la correspondance de préfixe la plus longue, et la règle pour toutes les destinations est évaluée en dernier, pas en premier. Ajoutez une règle 10.46.0.0/16 pour Engineering et une règle 0.0.0.0/0 pour tous : un utilisateur hors Engineering ne peut toujours pas atteindre 10.46.20.10 par la règle large.
C’est ici qu’un correctif peut mal tourner. Supprimer la règle étroite rétablit l’accès de l’utilisateur et accorde aussi ce sous-réseau à toute identité couverte par la règle large. Construisez la matrice groupe-réseau avant de supprimer quoi que ce soit, et notez quels groupes sont censés atteindre quelle plage. Ces règles ne font qu’autoriser ; il n’existe aucune entrée de refus pour découper une exception dans une autorisation large.
Les changements exigent aussi une connexion neuve pour être jugés équitablement. Reconnectez le client après avoir modifié les règles, puis testez de nouveau.
Séparez l’autorisation du chemin de données
Une règle qui correspond n’est pas une route. Le point de terminaison a besoin d’un sous-réseau associé et d’une entrée de table de routage pour la destination, et le groupe de sécurité de la ressource cible doit accepter le trafic. Le trafic de retour et le DNS doivent aussi fonctionner.
Testez un utilisateur qui devrait réussir et un utilisateur qui devrait rester exclu. Les deux peuvent se connecter alors qu’un seul atteint le sous-réseau, et cette différence est la preuve que vous cherchez.
Si une adresse IP fonctionne mais pas un nom d’hôte, regardez le résolveur avant de toucher à l’autorisation. Si aucune route ne couvre l’adresse, corrigez l’association ou la table de routage. Si le paquet arrive et que le service le refuse, la politique de ce service est l’étape suivante. Élargir la matrice d’autorisation à tous les utilisateurs masque laquelle de ces couches était réellement cassée.
Avant de clôturer le ticket, notez la source d’identité, la valeur exacte du groupe, les préfixes de destination et la route qui porte le trafic. Cette note transforme le prochain signalement connecté mais sans accès en une comparaison de deux minutes au lieu d’un nouveau cycle d’hypothèses.