Pourquoi un utilisateur distant ASA atteint le sous-réseau mais pas l’application
Les routes prouvent que le tunnel fonctionne, pas que l’utilisateur peut ouvrir l’application. Lisez le filtre reçu par la session, puis testez une connexion autorisée et une connexion refusée.
Votre utilisateur se connecte, obtient une adresse, fait un ping vers un serveur du sous-réseau de l’application et ne peut toujours pas ouvrir le service dessus. Cette combinaison est normale sur un ASA, parce que un tunnel réussi et une autorisation exploitable sont décidés par des réglages différents. La liste de tunnel partagé a choisi quelles destinations entraient dans le tunnel ; un filtre VPN et les règles d’accès propres à la destination décident ce que la requête déchiffrée peut atteindre. Parcourez les trois décisions dans l’ordre au lieu d’élargir la liste de routes jusqu’à ce que quelque chose change.
Trois décisions faciles à confondre
L’admission répond si l’utilisateur peut établir le tunnel : identifiants, certificat et tout second facteur. La sélection de route répond quelles destinations le client envoie dans ce tunnel. L’autorisation répond si la requête déchiffrée peut atteindre le service. Seule la troisième produit l’erreur que l’utilisateur signale.
Un moyen rapide de les distinguer est de demander ce qu’une modification casserait. Retirer une route de la liste partagée arrête le trafic vers ce sous-réseau sans rien accorder ; ajouter une ACE au filtre VPN accorde une destination sans changer ce que le client tunnelise.
| Setting | What it decides | Symptom when it is wrong |
|---|---|---|
| Connection profile and authentication | Whether the tunnel is built | Login fails, no address assigned |
| Split-tunnel network list | Which destinations the client routes into the tunnel | Subnet unreachable from the client, everything else fine |
| VPN filter (ACL) | Which decrypted flows are permitted | Tunnel up, ping may work, TCP service refused or dropped |
Lisez le filtre que la session a réellement reçu
Partez de la session active et non de la configuration que vous croyez applicable. show vpn-sessiondb detail anyconnect affiche la politique de groupe attribuée et le nom du filtre attaché à cette session. Si le champ est vide, aucun filtre n’impose rien et le blocage vient d’ailleurs.
Lisez ensuite la politique qui possède la valeur, valeurs par défaut comprises, car un filtre peut être hérité plutôt qu’écrit là où vous regardez :
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
Comparez le nom du filtre de la session avec l’ACL que vous venez de modifier. Une ACL au nom similaire que l’utilisateur n’a jamais reçue ne peut pas changer la politique de ressources de cette session, et c’est la raison la plus courante pour qu’une modification qui semble correcte reste sans effet.
La précédence explique le reste. Pour le réglage du filtre, un enregistrement DAP prime sur les attributs de nom d’utilisateur, et ceux-ci priment sur la politique de groupe. Quand une session affiche un filtre que vous n’attendiez pas, cherchez une politique DAP correspondant à cet utilisateur avant de toucher au groupe.
La liste partagée et le filtre sont des champs distincts
Sur ASA 9.x, la politique de groupe contient split-tunnel-network-list et vpn-filter comme des réglages différents, et le guide des politiques de groupe 9.22 les documente séparément précisément pour cette raison. La liste de réseaux est une indication de routage pour le client ; le filtre est une liste de contrôle d’accès appliquée au trafic déchiffré.
Cette distinction compte quand un utilisateur a besoin d’un seul service HTTPS dans un sous-réseau. Placez le sous-réseau dans la liste partagée pour que les paquets entrent dans le tunnel, puis n’autorisez que ce service dans le filtre. Élargir la liste de routes n’autorise rien, et la réduire n’est pas un mécanisme d’application.
Vérifiez si une ACL d’interface est même sur le chemin
Le trafic d’accès distant déchiffré ne traverse pas toujours l’ACL de l’interface externe comme on le suppose. Là où sysopt connection permit-vpn est activé, l’ASA applique son contournement VPN documenté pour ce trafic, tandis que les filtres VPN applicables s’appliquent encore ensuite. Vérifiez le réglage avec show run all sysopt plutôt qu’en raisonnant à partir du schéma de topologie.
Dans tous les cas, le pare-feu propre à l’hôte de destination et l’autorisation de l’application restent sur le chemin. Une règle ASA qui autorise TCP 443 ne fait pas accepter l’utilisateur par l’application.
Acceptez le changement aussi avec une connexion refusée
Un test autorisé seul prouve très peu, car un tunnel fonctionnel produit le même premier paquet qu’un filtre existe ou non. Ouvrez le service prévu depuis le client, puis tentez une destination qui doit rester fermée et confirmez qu’elle échoue pour la bonne raison.
Notez quatre faits en fermant le ticket : l’identité admise, la politique et le filtre que la session a réellement reçus, les destinations de la liste partagée et la ressource que l’utilisateur était autorisé à atteindre. Ces quatre éléments expliquent où le trafic est contrôlé sans transformer une liste de routes en pare-feu.
Si le service refuse encore après que le filtre l’autorise, passez à l’hôte : adresse d’écoute, pare-feu de l’hôte et mappage des utilisateurs propre à l’application. À ce stade, le tunnel a fait son travail, et d’autres changements sur l’ASA n’ajoutent que du risque.