O temporizador de sessão VPN e o token de autenticação expiram em separado

Uma queda de VPN pode acontecer por motivos que parecem idênticos do lado do cliente e não têm nada em comum por baixo: a sessão do túnel terminou, um temporizador de inatividade disparou ou uma credencial que o cliente reutilizava ficou obsoleta. Cada um tem um dono diferente e uma correção diferente. É a sequência de erros no momento da queda que os separa, e geralmente é uma só linha.

Três relógios correm contra um único túnel, e só um deles é o túnel.

Três relógios diferentes num único túnel

O relógio da sessão pertence ao gateway: uma duração máxima de ligação, um tempo limite de inatividade ou ambos, e encerra o túnel quando qualquer um deles é atingido. O relógio do token pertence ao sistema de autenticação e decide durante quanto tempo uma credencial pode ser apresentada de novo sem uma pessoa. O relógio do caminho pertence a qualquer NAT ou firewall entre o cliente e o gateway, e deixa expirar os mapeamentos dos fluxos que considera concluídos. Os três produzem uma desconexão, e nenhum produz a mesma linha de registo.

Só o primeiro é um conceito de VPN. Os outros dois são emprestados da identidade e das redes, e são rotineiramente confundidos com ele.

Como o token é realmente reutilizado

Os servidores OpenVPN podem emitir um token de autenticação após o início de sessão inicial, pelo que uma renegociação do canal de controlo não volta a pedir credenciais ao utilizador. O cliente continua a apresentar esse token e o servidor decide durante quanto tempo ele permanece aceitável. Quando a vida do token é mais curta do que o intervalo de renegociação, a renegociação seguinte falha e o cliente comunica um erro de autenticação em vez de um tempo limite. É por isso que o mesmo perfil funciona durante uma hora e depois falha num ponto fixo.

O intervalo de renegociação é uma definição separada. Alterá-lo desloca o momento em que o token é apresentado, não durante quanto tempo ele vive.

Como cada expiração se vê do lado do cliente

Um tempo limite de sessão chega normalmente como uma desconexão limpa com um motivo do lado do servidor, muitas vezes após uma duração previsível e sem qualquer erro de autenticação. Um tempo limite de inatividade parece silêncio: o túnel deixa de transportar tráfego e depois o keepalive desiste. Uma expiração de token chega como AUTH_FAILED no meio de uma sessão que funcionava um segundo antes.

Leia a linha e depois olhe para o relógio. Uma duração que corresponde a um valor configurado não é coincidência.

Porque é que uma palavra-passe guardada não ajuda

Uma palavra-passe em cache responde a um desafio para uma palavra-passe. Não prolonga a vida de um token e não satisfaz um desafio para um segundo fator ou uma verificação do estado do dispositivo. Aumentar a frequência das tentativas, encurtar os tempos limite de ligação ou reimportar o perfil não muda nada quanto ao tempo durante o qual o sistema de identidade aceitará a credencial.

As correções duradouras são a vida certa no objeto certo, ou um fluxo de cliente que consiga completar o desafio necessário sem uma pessoa.

O que documentar e testar

Anote os três valores: os limites de sessão e de inatividade do gateway, a vida do token e o tempo limite de mapeamento relevante mais curto no caminho. Depois teste cada expiração de propósito, encurtando um valor, observando o que o cliente comunica e repondo-o. Confirme o que o utilizador tem de fazer em cada fronteira, porque exigir um início de sessão completo a cada hora é uma decisão de política que alguém deveria ter tomado de propósito.

Uma queda que chega sem qualquer evento de autenticação pertence ao caminho ou ao temporizador de inatividade, e isso é outra investigação com outras provas.