O temporizador de sesión VPN e o token de autenticación caducan por separado

Un corte de VPN pode ocorrer por motivos que desde o cliente parecen idénticos e non comparten nada por debaixo: a sesión do túnel rematou, saltou un temporizador de inactividade ou unha credencial que o cliente reutilizaba quedou obsoleta. Cada un ten un dono distinto e unha solución distinta. A secuencia de erros no momento do corte é o que os separa, e adoita ser unha soa liña.

Tres reloxos corren contra un só túnel, e só un deles é o túnel.

Tres reloxos distintos nun só túnel

O reloxo da sesión pertence á pasarela: unha duración máxima de conexión, un tempo de espera por inactividade ou ambos, e pecha o túnel cando se alcanza calquera dos dous. O reloxo do token pertence ao sistema de autenticación e decide canto tempo se pode presentar de novo unha credencial sen unha persoa. O reloxo da ruta pertence a calquera NAT ou cortalumes que estea entre o cliente e a pasarela, e fai caducar as asignacións dos fluxos que considera rematados. Os tres producen unha desconexión, e ningún produce a mesma liña de rexistro.

Só o primeiro é un concepto de VPN. Os outros dous tómanse da identidade e das redes, e confúndense con el con frecuencia.

Como se reutiliza realmente o token

Os servidores OpenVPN poden emitir un token de autenticación tras o inicio de sesión inicial, de modo que unha renegociación da canle de control non volve pedir credenciais ao usuario. O cliente segue presentando ese token e o servidor decide canto tempo segue sendo aceptable. Cando a vida do token é máis curta que o intervalo de renegociación, a seguinte renegociación falla e o cliente informa dun erro de autenticación en lugar dun tempo de espera. Por iso o mesmo perfil funciona durante unha hora e logo falla nun punto fixo.

O intervalo de renegociación é un axuste aparte. Cambialo move cando se presenta o token, non canto vive.

Como se ve cada caducidade desde o cliente

Un tempo de espera de sesión adoita chegar como unha desconexión limpa cun motivo do servidor, a miúdo tras unha duración previsible e sen ningún erro de autenticación asociado. Un tempo de espera por inactividade parece silencio: o túnel deixa de levar tráfico e entón o keepalive réndese. Unha caducidade de token chega como AUTH_FAILED no medio dunha sesión que funcionaba un segundo antes.

Lea a liña e logo mire o reloxo. Unha duración que coincide cun valor configurado non é casualidade.

Por que un contrasinal gardado non axuda

Un contrasinal na caché responde a un desafío por un contrasinal. Non prolonga a vida dun token nin satisface un desafío por un segundo factor ou unha comprobación do estado do dispositivo. Aumentar a frecuencia de reintentos, reducir os tempos de espera de conexión ou reimportar o perfil non cambia nada sobre canto tempo o sistema de identidade aceptará a credencial.

As solucións duradeiras son a vida correcta sobre o obxecto correcto, ou un fluxo de cliente que poida completar o desafío necesario sen unha persoa.

Que documentar e probar

Anote os tres valores: os límites de sesión e inactividade da pasarela, a vida do token e o tempo de espera de asignación relevante máis curto da ruta. Logo probe cada caducidade a propósito acurtando un valor, observando que informa o cliente e restaurándoo. Confirme que debe facer o usuario en cada fronteira, porque esixir un inicio de sesión completo cada hora é unha decisión de política que alguén debería ter tomado a propósito.

Un corte que chega sen ningún evento de autenticación pertence á ruta ou ao temporizador de inactividade, que é outra investigación con outras probas.