Um temporizador VPN inativo conta o tráfego, não a atividade do teclado
Um tempo limite de inatividade do gateway monitora os pacotes no túnel, não no teclado. Separe os temporizadores de inatividade, de sessão e de bloqueio de tela antes de alterar qualquer um deles.
O temporizador que desconecta uma sessão VPN ociosa conta pacotes, não pressionamentos de tecla. Ele observa a ausência de comunicação no túnel, de modo que um laptop com e-mail, um agente de backup ou um cliente de bate-papo em segundo plano nunca pareça ocioso. Esse fato explica ambas as direções da reclamação habitual: uma sessão que sobrevive a um longo almoço e uma sessão que morre no meio do trabalho ativo. Decida com qual relógio você está lutando antes de procurar uma configuração.
O que o cronômetro realmente observa
Em um Cisco ASA, o botão é vpn-idle-timeout, definido sob uma política de grupo ou de usuário, e mede um período sem atividade de comunicação. A unidade é minutos, o padrão é herdado e a verificação é executada nos contadores de tráfego da sessão, e não em qualquer coisa que o sistema operacional saiba sobre os dispositivos de entrada. O gateway não tem ideia se há um humano no teclado. Ele sabe quando viu pela última vez um pacote daquele cliente.
O segundo relógio é o tempo limite da sessão VPN e é absoluto. Ele começa quando a sessão é estabelecida e expira independentemente da ocupação do túnel. Uma sessão que termina após exatamente uma hora de uso intenso é esse cronômetro, não um cronômetro ocioso, e nenhuma digitação irá estendê-lo.
Leia os dois valores antes de alterá-los, pois eles falham de maneira que parecem idênticas na cadeira do usuário.
Três relógios diferentes que as pessoas chamam de inativos
Três políticas não relacionadas são descritas como temporizador ocioso, e apenas uma delas trata do silêncio 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 linha é aquela que as pessoas realmente desejam quando dizem que a VPN deve bloquear quando alguém se afasta. Um temporizador VPN não pode medir a presença. Se o requisito for que um laptop autônomo perca o acesso, isso pertence ao bloqueio de tela e à política do dispositivo, onde pode ser aplicado independentemente do tráfego em segundo plano.
A mistura dos três produz solicitações como desconexão após trinta minutos sem digitação, o que nenhum gateway VPN pode implementar honestamente.
Encontre a política proprietária desta conexão
Identifique o cliente e o protocolo antes de procurar uma configuração. O perfil Cisco IPsec do macOS integrado, uma conexão L2TP nativa e o Cisco Secure Client não expõem os mesmos controles, e uma captura de tela de uma caixa de seleção desconectar se ocioso em um deles não é evidência sobre os outros. Os perfis nativos expõem pouco além do servidor, da conta e do segredo compartilhado. O cronômetro fica no gateway.
No ASA, leia a política efetiva para o usuário ou grupo em vez da política padrão para todos:
show running-config group-policy NAME | include timeout
show vpn-sessiondb detail anyconnect filter name USERA saída detalhada da sessão lista os tempos limite de inatividade e de sessão que foram realmente aplicados, com o tempo restante. Essa é a política efetiva, incluindo a herança, que um trecho de configuração em execução não pode lhe dizer. Compare-o com o grupo em que você acredita que o usuário pertence, porque uma política de usuário substitui a política de grupo.
Por que o seu Mac parece conectado depois de trinta minutos
O tráfego em segundo plano é a resposta usual e não é um bug. Correio, sincronização de fotos, uma verificação de atualização, um cliente de bate-papo mantendo um soquete aberto ou uma guia do navegador com um websocket produzem pacotes que o gateway conta como atividade. O túnel permanece aberto porque está sendo genuinamente usado, mas não por você. Observe os contadores em vez da tela se quiser uma prova.
A imagem espelhada é a sessão que é interrompida enquanto você digita, que é um tempo limite da sessão ou uma alteração de política do administrador, não ociosidade.
Também há um efeito do lado do cliente que vale a pena conhecer. Alguns clientes enviam seus próprios keepalives ou sondagens de pares mortos, e esses pacotes redefinem o contador ocioso do gateway. É por isso que um keepalive adicionado para anular um tempo limite funciona e é a ferramenta errada: altera a evidência que o cronômetro vê sem alterar o requisito de autorização por trás da política.
Mude o botão direito sem quebrar a ponta dele
Se o objetivo é encerrar uma classe de conexão após inatividade de rede aprovada, peça exatamente isso na linguagem da política e mantenha a duração máxima da sessão como um valor separado e deliberado. Em seguida, teste-o sob o procedimento do administrador com trabalho em segundo plano contabilizado.
Se o objetivo é interromper o acesso quando uma pessoa sai da mesa, a VPN é a camada errada para aplicá-lo.
Nunca adicione um keep-alive gerador de tráfego apenas para manter uma sessão ativa após uma política escrita para encerrá-la. Isso converte um controle em uma formalidade e é encontrado em uma auditoria e não em um ticket. Altere a política ou altere o requisito.