El temporizador de inactividad de la VPN cuenta tráfico, no teclado
El tiempo de espera de inactividad de la pasarela vigila los paquetes del túnel, no su teclado. Separe los temporizadores de inactividad, sesión y bloqueo de pantalla antes de cambiar cualquiera.
El temporizador que desconecta una sesión de VPN inactiva cuenta paquetes, no pulsaciones de teclado. Observa la ausencia de comunicación en el túnel, así que un portátil con correo, un agente de copias de seguridad o un cliente de chat en segundo plano nunca le parece inactivo. Ese único hecho explica las dos direcciones de la queja habitual: una sesión que sobrevive a una comida larga y una sesión que muere en mitad de un trabajo activo. Decida contra qué reloj está luchando antes de buscar un ajuste.
Qué observa realmente el temporizador
En un Cisco ASA el parámetro es vpn-idle-timeout, se configura en una política de grupo o de usuario y mide un periodo sin actividad de comunicación. La unidad son minutos, el valor predeterminado se hereda y la comprobación se ejecuta contra los contadores de tráfico de la sesión, no contra lo que el sistema operativo sabe de los dispositivos de entrada. La pasarela no tiene ni idea de si hay una persona ante el teclado. Sabe cuándo vio por última vez un paquete de ese cliente.
El segundo reloj es vpn-session-timeout y es absoluto. Empieza cuando se establece la sesión y caduca sin importar lo ocupado que esté el túnel. Una sesión que termina tras exactamente una hora de uso intenso es ese temporizador, no un temporizador de inactividad, y ninguna cantidad de escritura la prolongará.
Lea ambos valores antes de cambiar cualquiera de ellos, porque fallan de formas que desde la silla del usuario parecen idénticas.
Tres relojes distintos a los que la gente llama inactividad
Tres políticas no relacionadas se describen como el temporizador de inactividad, y solo una de ellas trata del silencio de la red.
| Measure | What it observes | How it fails |
|---|---|---|
| Gateway idle timeout | No packets from the client on the tunnel | Drops after a quiet period, survives background traffic |
| Gateway session timeout | Elapsed time since the session was established | Drops at a fixed interval no matter how active the tunnel is |
| Screen lock and device policy | Human presence at the device | Session stays up while the laptop sits unattended and unlocked |
La tercera fila es la que la gente realmente quiere cuando dice que la VPN debería bloquearse cuando alguien se aleja. Un temporizador de VPN no puede medir la presencia. Si el requisito es que un portátil desatendido pierda el acceso, eso pertenece a la política de bloqueo de pantalla y de dispositivo, donde puede imponerse con independencia del tráfico de fondo.
Mezclar los tres produce peticiones como desconectar tras treinta minutos sin escribir, que ninguna pasarela de VPN puede implementar con honestidad.
Encuentre la política que posee esta conexión
Identifique el cliente y el protocolo antes de buscar un ajuste. El perfil Cisco IPsec integrado de macOS, una conexión L2TP nativa y Cisco Secure Client no exponen los mismos controles, y una captura de una casilla de desconectar si está inactivo en uno de ellos no es prueba sobre los demás. Los perfiles nativos exponen poco más allá del servidor, la cuenta y el secreto compartido. El temporizador vive en la pasarela.
En el ASA, lea la política efectiva del usuario o del grupo en lugar de la política predeterminada para todos:
show running-config group-policy NAME | include timeout
show vpn-sessiondb detail anyconnect filter name USERLa salida de detalle de la sesión enumera los tiempos de inactividad y de sesión que se aplicaron realmente, junto con el tiempo restante. Esa es la política efectiva, herencia incluida, algo que un extracto de running-config no puede decirle. Compárela con el grupo en el que cree que está el usuario, porque una política de usuario anula la de grupo.
Por qué su Mac parece conectado después de treinta minutos
El tráfico de fondo es la respuesta habitual, y no es un error. El correo, la sincronización de fotos, una comprobación de actualizaciones, un cliente de chat que mantiene un socket abierto o una pestaña del navegador con un web socket generan cada uno paquetes que la pasarela cuenta como actividad. El túnel sigue abierto porque se está usando de verdad, solo que no por usted. Mire los contadores en lugar de la pantalla si quiere pruebas.
La imagen inversa es la sesión que cae mientras escribe, y eso es un tiempo de espera de sesión o un cambio de política del administrador, no inactividad.
También hay un efecto del lado del cliente que conviene conocer. Algunos clientes envían sus propias señales de mantenimiento o sondeos de par muerto, y esos paquetes reinician el contador de inactividad de la pasarela. Por eso funciona una señal de mantenimiento añadida para vencer un tiempo de espera, y por eso es la herramienta equivocada: cambia la prueba que ve el temporizador sin cambiar el requisito de autorización que hay detrás de la política.
Cambie el parámetro correcto sin romper su propósito
Si el objetivo es terminar una clase de conexión tras una inactividad de red aprobada, pida exactamente eso en el lenguaje de la política y mantenga la duración máxima de sesión como un valor aparte y deliberado. Después pruébelo según el procedimiento del administrador con el trabajo de fondo tenido en cuenta.
Si el objetivo es detener el acceso cuando una persona deja el escritorio, la VPN es la capa equivocada para imponerlo.
Nunca añada una señal de mantenimiento que genere tráfico solo para mantener viva una sesión más allá de una política escrita para terminarla. Eso convierte un control en una formalidad, y se descubre en una auditoría, no en un ticket. Cambie la política, o cambie el requisito.