Ancien IOS SSL VPN : paquet, profil, passerelle et session

Vous trouvez un programme d’installation client sur la mémoire flash du routeur et concluez que le SSL VPN est configuré. C’est un composant sur quatre, et les trois autres décident si quelqu’un peut se connecter. Sur l’ancien IOS SSL VPN, les pièces sont des objets distincts : le paquet client de tête de réseau, un profil client facultatif, la passerelle WebVPN qui termine TLS, et le contexte plus la politique de groupe qui portent l’authentification et les paramètres de session. Oubliez-en un et la panne semble identique de l’extérieur.

L’exemple de configuration SSL VPN d’IOS de Cisco, bâti sur IOS 15.3 avec AnyConnect 3.1, est utile précisément parce qu’il garde ces objets séparés. Lisez-le comme la description de cette implémentation plus ancienne, non comme une recommandation de déployer ces versions.

Premièrement, le paquet : ce qu’il est et ce qu’il n’est pas

Le paquet de tête de réseau fournit le logiciel client pour une seule plateforme. Il n’est ni le profil ni l’écouteur, et un fichier posé sur la mémoire flash prouve seulement que quelqu’un a téléversé quelque chose. Il ne prouve pas qu’une session s’en soit jamais servie, que la plateforme corresponde à l’appareil de l’utilisateur, ni que la passerelle y fasse référence.

Vérifiez le nom exact du fichier, la plateforme qu’il vise et l’endroit où la configuration pointe vers lui. Un paquet Windows ne vous dit rien des téléphones, et un fichier téléversé qu’aucun objet de passerelle ne mentionne relève du stockage, pas de la configuration. Un paquet qui correspond à la plateforme mais n’est jamais associé au service ne sera proposé à aucun utilisateur. Pas davantage celui dont le nom de fichier diffère de la valeur attendue par la configuration.

Deuxièmement, le profil : des réglages, pas du logiciel

Un profil client facultatif porte des réglages qu’un administrateur prépare séparément, comme des listes de serveurs ou des préférences client. Le confondre avec un programme d’installation est courant, car les deux arrivent sous forme de fichiers aux noms similaires. Si le déploiement attend un profil, son absence change ce que le client fait après la connexion, pas s’il se connecte.

Inventoriez les deux artefacts et notez lequel la passerelle référence réellement. Cette seule ligne évite une catégorie de tickets de support où deux personnes parlent de fichiers différents.

Troisièmement, l’écouteur et l’identité TLS

L’objet passerelle définit l’adresse et le port que le monde extérieur atteint et le certificat présenté pendant la poignée de main. Un navigateur qui atteint une page de portail, un client qui termine l’authentification et une application qui atteint un serveur privé sont trois observations distinctes, et seule la première est un test de l’écouteur. Quand la poignée de main échoue, rien en aval n’importe encore, aussi vérifiez la chaîne de certificats et le nom avant de modifier une politique.

Notez l’identité attendue quelque part. Un certificat renouvelé ou remplacé est la raison la plus fréquente pour qu’un déploiement qui fonctionnait le mois dernier cesse de fonctionner ce mois-ci.

Quatrièmement, le contexte et la politique avec son modèle virtuel

Le contexte et la politique de groupe lient l’authentification au comportement de session : pool d’adresses, routes fractionnées, DNS et réseaux internes qu’un utilisateur peut atteindre. L’exemple documenté rattache son contexte à un modèle virtuel qui fournit le comportement d’interface par session, et ces objets côté serveur existent indépendamment de tout ce qu’un utilisateur télécharge.

Quand un utilisateur s’authentifie mais n’atteint rien, la faute se situe généralement ici plutôt que dans le client. Comparez le pool, les routes remises au client et l’ACL qui autorise le trafic ultérieur, et confrontez-les à ce que l’utilisateur signale, non à ce que la conception prévoyait.

Vérifiez dans l’ordre et arrêtez-vous au premier échec

Parcourez les quatre composants dans l’ordre où une connexion les rencontre : écouteur, authentification, politique, puis comportement du client. Confirmez TLS avec l’identité attendue, authentifiez un compte fiable, lisez l’adresse et les routes attribuées depuis la session, et seulement ensuite comparez la plateforme du client au paquet. S’arrêter au premier échec garde une seule variable en jeu, et c’est la différence entre une réparation et une supposition.

Pour un téléphone ou tout client hors de cet exemple historique de bureau, obtenez le véritable contrat client et passerelle pris en charge au lieu de supposer que le flux Windows se généralise. Changer un protocole demandé ne transformera pas un profil IKEv2 en ce service SSL VPN, et installer un paquet de bureau ne démontre rien sur la prise en charge mobile.