O OpenVPN derruba a sessão OTP mais tarde: o que a reautenticação exige

Do lado do cliente, parece uma desconexão aleatória uma hora depois do início de uma sessão de trabalho. O ícone da bandeja desaparece, o túnel é reconstruído e o log mostra uma falha de autenticação em vez de um erro de rede. O que realmente aconteceu foi que a sessão renegociou e o segundo handshake precisou de credenciais das quais o cliente já não tinha uma cópia válida. Um código de uso único que funcionou no login não pode funcionar de novo, então a renovação de chaves falha exatamente como projetado.

A correção é uma decisão sobre o que o segundo handshake deve apresentar, não um temporizador de nova tentativa mais longo.

Percorra a troca do ponto de vista do cliente

No login, o cliente envia o nome de usuário, a senha e um código do dispositivo token, e o servidor aceita a combinação. Depois a sessão corre até um gatilho de renegociação disparar, o que inicia um novo handshake TLS dentro do túnel existente. Esse handshake pede autenticação outra vez. Se o caminho de autenticação do servidor espera uma senha mais um código de uso único atual, o cliente não tem um código novo a oferecer, a menos que o usuário esteja presente para digitá-lo.

A maioria dos clientes não abre um prompt no meio da sessão, então o handshake expira e o túnel cai. O usuário vê uma reconexão, não um prompt de autenticação, e é por isso que o primeiro relato costuma culpar a rede.

auth-gen-token muda quem responde à segunda pergunta

A opção auth-gen-token permite que o servidor emita um token após um login bem-sucedido, e as renegociações posteriores apresentam esse token em vez de repetir a senha e o código. O manual documenta o tempo de vida e o comportamento de renovação, e o token precisa ser tratado como uma credencial com validade própria. No caminho padrão o servidor valida o token sozinho em vez de chamar novamente o autenticador externo de senha.

Com uma integração de autenticação externa, essa divisão muda. O plugin precisa entender o estado do token e aplicar as próprias verificações, porque o servidor já não é o único componente que decide se a sessão continua. Tratar o token como mais um código de uso único numérico não é uma implementação do recurso.

Decida o que acontece com o estado da conta

Um token que sobrevive ao acesso de uma conta é um buraco na política. Decida como uma conta desativada, uma associação de grupo removida ou um dispositivo revogado passam a valer enquanto um token ainda é válido. Tempos de vida curtos reduzem a janela; um caminho explícito de revogação a torna intencional. Escreva a resposta antes de ativar a opção, porque o caminho padrão não consulta o autenticador externo a cada renegociação.

Numa implantação com vários servidores, o segredo de assinatura do token precisa ser compartilhado, senão o cliente pode ser enviado para um nó que não consegue validar o token.

Teste expiração e reconexão, não apenas o login

Reduza o intervalo de renegociação num perfil de teste para que o segundo handshake aconteça enquanto você observa, depois acompanhe os dois logs. Confirme que o token é emitido no login, apresentado na troca de chaves e renovado ou reemitido conforme o tempo de vida configurado. Depois force a expiração do token e uma reconexão completa, porque um cliente que se reconecta sem erros ainda pode falhar no caminho da troca de chaves.

Teste a remoção da conta por último. Esse caso diz se a política que você escreveu é aplicada ou apenas documentada.

Não conserte desativando a renovação

Definir o intervalo de renegociação como zero nos dois pares remove o sintoma e, com ele, a rotação de chaves. Isso esconde um problema de repetição de credenciais atrás de uma mudança de política que ninguém revisou. Mantenha a renovação e escolha entre um token emitido pelo servidor e um novo desafio interativo conforme a presença de um usuário.

Um temporizador de nova tentativa mais longo não torna um código gasto válido de novo. Apenas atrasa a desconexão e torna o log mais difícil de ler.