Le minuteur d'inactivité du VPN compte le trafic, pas le clavier

Le minuteur qui déconnecte une session VPN inactive compte les paquets, pas les frappes au clavier. Il observe l'absence de communication sur le tunnel, donc un ordinateur portable avec du courrier, un agent de sauvegarde ou un client de messagerie en arrière-plan ne lui paraît jamais inactif. Ce seul fait explique les deux directions de la plainte habituelle : une session qui survit à un long déjeuner et une session qui meurt au milieu d'un travail actif. Décidez contre quelle horloge vous vous battez avant de chercher un réglage.

Ce que le minuteur observe réellement

Sur un Cisco ASA, le paramètre est vpn-idle-timeout, il se règle dans une politique de groupe ou d'utilisateur et il mesure une période sans activité de communication. L'unité est la minute, la valeur par défaut est héritée, et le contrôle s'exécute sur les compteurs de trafic de la session et non sur ce que le système d'exploitation sait des périphériques d'entrée. La passerelle n'a aucune idée de la présence d'un humain au clavier. Elle sait quand elle a vu pour la dernière fois un paquet de ce client.

La seconde horloge est vpn-session-timeout, et elle est absolue. Elle démarre à l'établissement de la session et expire quel que soit le niveau d'activité du tunnel. Une session qui se termine après exactement une heure d'usage intensif relève de ce minuteur, pas d'un minuteur d'inactivité, et aucune quantité de frappe ne la prolongera.

Lisez les deux valeurs avant de changer l'une ou l'autre, car elles échouent d'une manière qui paraît identique depuis la chaise de l'utilisateur.

Trois horloges différentes que les gens appellent inactivité

Trois politiques sans rapport sont décrites comme le minuteur d'inactivité, et une seule concerne le silence du réseau.

La troisième ligne est celle que les gens veulent vraiment quand ils disent que le VPN devrait se verrouiller quand quelqu'un s'éloigne. Un minuteur VPN ne peut pas mesurer la présence. Si l'exigence est qu'un ordinateur portable sans surveillance perde l'accès, cela relève de la politique de verrouillage d'écran et d'appareil, où elle peut être appliquée indépendamment du trafic de fond.

Mélanger les trois produit des demandes comme déconnecter après trente minutes sans frappe, qu'aucune passerelle VPN ne peut mettre en œuvre honnêtement.

Trouvez la politique qui possède cette connexion

Identifiez le client et le protocole avant de chercher un réglage. Le profil Cisco IPsec intégré de macOS, une connexion L2TP native et Cisco Secure Client n'exposent pas les mêmes contrôles, et une capture d'écran d'une case déconnecter si inactif dans l'un d'eux ne prouve rien pour les autres. Les profils natifs exposent peu de chose au-delà du serveur, du compte et du secret partagé. Le minuteur vit sur la passerelle.

Sur l'ASA, lisez la politique effective de l'utilisateur ou du groupe plutôt que la politique par défaut pour tout le monde :

show running-config group-policy NAME | include timeout
show vpn-sessiondb detail anyconnect filter name USER

La sortie de détail de session liste les délais d'inactivité et de session réellement appliqués, avec le temps restant. C'est la politique effective, héritage compris, ce qu'un extrait de running-config ne peut pas vous dire. Comparez-la au groupe dans lequel vous croyez que l'utilisateur se trouve, car une politique d'utilisateur prime sur la politique de groupe.

Pourquoi votre Mac semble connecté après trente minutes

Le trafic de fond est la réponse habituelle, et ce n'est pas un défaut. Le courrier, la synchronisation des photos, une vérification de mise à jour, un client de messagerie qui garde une socket ouverte ou un onglet de navigateur avec un web socket produisent chacun des paquets que la passerelle compte comme de l'activité. Le tunnel reste ouvert parce qu'il est réellement utilisé, simplement pas par vous. Regardez les compteurs plutôt que l'écran si vous voulez des preuves.

L'image inverse est la session qui tombe pendant que vous tapez, et c'est un délai de session ou un changement de politique de l'administrateur, pas de l'inactivité.

Il existe aussi un effet côté client qu'il vaut la peine de connaître. Certains clients envoient leurs propres signaux de maintien ou sondes de pair mort, et ces paquets remettent à zéro le compteur d'inactivité de la passerelle. C'est pourquoi un maintien ajouté pour vaincre un délai fonctionne, et c'est pourquoi c'est le mauvais outil : il change la preuve que voit le minuteur sans changer l'exigence d'autorisation derrière la politique.

Changez le bon paramètre sans en détruire l'intérêt

Si l'objectif est de terminer une classe de connexion après une inactivité réseau approuvée, demandez exactement cela dans le langage de la politique, et gardez la durée maximale de session comme une valeur distincte et délibérée. Testez-le ensuite selon la procédure de l'administrateur, travail de fond pris en compte.

Si l'objectif est d'arrêter l'accès quand une personne quitte le bureau, le VPN est la mauvaise couche pour l'appliquer.

N'ajoutez jamais un maintien générateur de trafic uniquement pour garder une session vivante au-delà d'une politique écrite pour y mettre fin. Cela transforme un contrôle en formalité, et cela se découvre lors d'un audit plutôt que dans un ticket. Changez la politique, ou changez l'exigence.