Por que uma reconexão VPN volta a pedir credenciais

Um túnel que funcionou durante horas pede uma palavra-passe no momento em que o portátil acorda, e nada na configuração mudou. O que mudou foi o estado da credencial que a reconexão tentou reutilizar. Três tipos de material governam isso, e apenas um deles sobrevive a um intervalo arbitrário.

Leia qual o cliente pediu, porque os três expiram com relógios diferentes e falham com mensagens diferentes.

Três tipos de material reutilizável

Uma palavra-passe em cache é um segredo guardado pelo cliente, e mantém-se válida até a conta a alterar. Um token de sessão é emitido pelo servidor após um início de sessão bem-sucedido, tem a sua própria duração e pode ser revogado a qualquer momento. Um bilhete de sessão TLS ou uma associação de segurança IKE é estado de protocolo, barato de retomar e completamente independente da sua palavra-passe. Cada um é emitido por um componente diferente, e cada um expira nos seus próprios termos.

O primeiro sobrevive a um reinício, o segundo sobrevive normalmente a uma suspensão, e o terceiro pode não sobreviver de todo a uma mudança de rede. Confundi-los produz a correção errada, como repor uma palavra-passe que nunca foi rejeitada.

O próprio pedido é o diagnóstico. Uma janela de navegador ou um código de segundo fator significa que o servidor exigiu autenticação interativa, enquanto uma falha silenciosa sem pedido significa que o cliente nunca chegou suficientemente longe para ser questionado.

Renovar chaves não é reautenticar

Uma renovação de chaves substitui as chaves mantendo a identidade autenticada, e é por isso que acontece silenciosamente de vez em quando num túnel saudável. A reautenticação repete a própria verificação de identidade, e é esse o evento que precisa de si. O IKEv2 separa explicitamente os dois, e um par pode exigir uma reautenticação completa num intervalo configurado, independentemente de quantas renovações de chaves tenham ocorrido entretanto. Os dois eventos parecem idênticos do exterior até ler qual deles o registo nomeia.

O OpenVPN comporta-se da mesma forma no seu próprio vocabulário: um intervalo de renegociação atualiza o canal de dados, e um token de autenticação pode ser devolvido ao cliente para evitar um início de sessão completo na ligação seguinte. Esse token tem uma duração, e o servidor decide se o aceita novamente.

Assim, uma reconexão após oito horas pode falhar onde uma reconexão após oito minutos teve sucesso, sem qualquer alteração de configuração de ambos os lados. É toda a explicação para um pedido que só aparece depois do almoço.

Quando o cliente não consegue concluir o novo desafio

Uma política que exige um passo no navegador falhará num cliente que não tem forma de o mostrar. Servidores sem interface, scripts de arranque e perfis antigos criados para autenticação apenas com palavra-passe batem todos nessa parede, e a falha aparece muitas vezes como um tempo limite genérico em vez de um erro de autenticação.

As transições de dispositivo e de rede também podem cair dentro de uma janela de avaliação da política, pelo que uma passagem de Wi-Fi para um hotspot coincide com uma verificação que aconteceria de qualquer forma. A coincidência faz a rede parecer culpada quando a causa é o temporizador.

openvpn --config client.ovpn --verb 3 2>&1 | grep -i -E "reneg|auth"
ipsec statusall | grep -i -E "rekey|reauth"

A primeira linha mostra eventos de renegociação e autenticação no registo do próprio cliente, e a segunda mostra as associações de segurança que um par strongSwan detém neste momento. Compare as marcas temporais com o momento em que o pedido apareceu; uma correspondência confirma o temporizador e não a rede.

O que relatar, e o que não desativar

Se um início de sessão manual funcionar e a reutilização automática falhar de forma consistente, diga exatamente isso ao operador. Isso nomeia o componente: o caminho de reutilização, não a credencial. Inclua a hora da falha, a conta em uso e o tipo de pedido que viu.

Não desative o segundo fator, não ignore a validação do certificado e não cole credenciais num script para tornar a reconexão silenciosa. Cada uma dessas ações remove a verificação que a política existe para impor, e cada uma transforma um pedido de início de sessão num incidente.

Peça antes o fluxo suportado: um cliente que consiga concluir o desafio, uma duração de token adequada ao dia de trabalho, ou um perfil não interativo aprovado para a máquina que não pode perguntar. São todas decisões de configuração que alguém pode aprovar, o que um contorno não é.