O temporizador de inactividade da VPN conta tráfico, non teclado
O tempo de espera de inactividade da pasarela vixía os paquetes do túnel, non o seu teclado. Separe os temporizadores de inactividade, sesión e bloqueo de pantalla antes de cambiar calquera.
O temporizador que desconecta unha sesión de VPN inactiva conta paquetes, non pulsacións de teclado. Observa a ausencia de comunicación no túnel, así que un portátil con correo, un axente de copias de seguridade ou un cliente de chat en segundo plano nunca lle parece inactivo. Ese único feito explica as dúas direccións da queixa habitual: unha sesión que sobrevive a unha comida longa e unha sesión que morre no medio dun traballo activo. Decida contra que reloxo está a loitar antes de buscar un axuste.
Que observa realmente o temporizador
Nun Cisco ASA o parámetro é vpn-idle-timeout, configúrase nunha política de grupo ou de usuario e mide un período sen actividade de comunicación. A unidade son minutos, o valor predeterminado hérdase e a comprobación execútase contra os contadores de tráfico da sesión, non contra o que o sistema operativo sabe dos dispositivos de entrada. A pasarela non ten nin idea de se hai unha persoa diante do teclado. Sabe cando viu por última vez un paquete dese cliente.
O segundo reloxo é vpn-session-timeout e é absoluto. Comeza cando se establece a sesión e caduca independentemente do ocupado que estea o túnel. Unha sesión que remata tras exactamente unha hora de uso intenso é ese temporizador, non un temporizador de inactividade, e ningunha cantidade de escritura a prolongará.
Lea ambos os valores antes de cambiar calquera deles, porque fallan de formas que desde a cadeira do usuario parecen idénticas.
Tres reloxos distintos aos que a xente chama inactividade
Tres políticas sen relación descríbense como o temporizador de inactividade, e só unha delas trata do silencio da rede.
| 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 |
A terceira fila é a que a xente realmente quere cando di que a VPN debería bloquearse cando alguén se afasta. Un temporizador de VPN non pode medir a presenza. Se o requisito é que un portátil desatendido perda o acceso, iso pertence á política de bloqueo de pantalla e de dispositivo, onde se pode impoñer independentemente do tráfico de fondo.
Mesturar os tres produce peticións como desconectar tras trinta minutos sen escribir, que ningunha pasarela de VPN pode implementar con honestidade.
Atope a política que posúe esta conexión
Identifique o cliente e o protocolo antes de buscar un axuste. O perfil Cisco IPsec integrado de macOS, unha conexión L2TP nativa e Cisco Secure Client non expoñen os mesmos controis, e unha captura dunha caixa de desconectar se está inactivo nun deles non é proba sobre os demais. Os perfís nativos expoñen pouco máis alá do servidor, a conta e o segredo compartido. O temporizador vive na pasarela.
No ASA, lea a política efectiva do usuario ou do grupo en lugar da política predeterminada para todos:
show running-config group-policy NAME | include timeout
show vpn-sessiondb detail anyconnect filter name USERA saída de detalle da sesión enumera os tempos de inactividade e de sesión que se aplicaron realmente, xunto co tempo restante. Esa é a política efectiva, herdanza incluída, algo que un extracto de running-config non lle pode dicir. Compárea co grupo no que cre que está o usuario, porque unha política de usuario anula a de grupo.
Por que o seu Mac parece conectado despois de trinta minutos
O tráfico de fondo é a resposta habitual, e non é un erro. O correo, a sincronización de fotos, unha comprobación de actualizacións, un cliente de chat que mantén un socket aberto ou unha pestana do navegador cun web socket xeran cada un paquetes que a pasarela conta como actividade. O túnel segue aberto porque se está usando de verdade, só que non por vostede. Mire os contadores en lugar da pantalla se quere probas.
A imaxe inversa é a sesión que cae mentres escribe, e iso é un tempo de espera de sesión ou un cambio de política do administrador, non inactividade.
Tamén hai un efecto do lado do cliente que convén coñecer. Algúns clientes envían os seus propios sinais de mantemento ou sondas de par morto, e eses paquetes reinician o contador de inactividade da pasarela. Por iso funciona un sinal de mantemento engadido para vencer un tempo de espera, e por iso é a ferramenta equivocada: cambia a proba que ve o temporizador sen cambiar o requisito de autorización que hai detrás da política.
Cambie o parámetro correcto sen romper o seu propósito
Se o obxectivo é rematar unha clase de conexión tras unha inactividade de rede aprobada, pida exactamente iso na linguaxe da política e manteña a duración máxima de sesión como un valor aparte e deliberado. Despois probéneo segundo o procedemento do administrador co traballo de fondo tido en conta.
Se o obxectivo é deter o acceso cando unha persoa deixa o escritorio, a VPN é a capa equivocada para impoñelo.
Nunca engada un sinal de mantemento que xere tráfico só para manter viva unha sesión máis alá dunha política escrita para rematala. Iso converte un control nunha formalidade, e descóbrese nunha auditoría, non nun ticket. Cambie a política, ou cambie o requisito.