Azure VPN Client 3.4 se desconecta cada hora: frecuencia de inicio de sesión
No es la puerta de enlace: el cliente ahora aplica la frecuencia de inicio de sesión a mitad de sesión y el túnel muere al ritmo de la directiva. Versión, desfase y comprobaciones.
Un usuario se conecta, trabaja y luego lo desconectan una vez por hora con un mensaje de que la autenticación con Microsoft Entra ha caducado. La reconexión funciona y el ciclo se repite como un cronómetro. En una puerta de enlace de punto a sitio donde no se desplegó nada, ese patrón apunta a la credencial y no al túnel. Azure VPN Client 3.4.0 empezó a aplicar la frecuencia de inicio de sesión del Acceso Condicional durante una sesión establecida, una directiva que los clientes anteriores solo evaluaban al iniciar sesión.
Recorra las seis comprobaciones siguientes en orden. Cada una confirma o descarta el calendario, y detenerse antes de tiempo es como se reconstruye una puerta de enlace sin motivo.
Paso 1: leer el mensaje exacto
El texto separa las capas. Un mensaje sobre la caducidad de la autenticación Entra es una afirmación sobre el token; un error de túnel o de asociación de seguridad no lo es. Anote también el tiempo transcurrido, medido desde la conexión hasta la desconexión y no desde el inicio de la jornada.
Si el usuario puede reconectarse de inmediato y la puerta de enlace sigue mostrando un túnel sano, se trata de la caducidad del token y no de un par muerto.
Paso 2: obtener la versión del cliente
Lea la versión en la aplicación, no en el registro de despliegue. El cambio llegó con 3.4.0, así que 3.3.1 y anteriores mantienen vivo un túnel establecido independientemente de la directiva. Un portátil no administrado con una compilación anterior se comporta perfectamente mientras el resto del equipo cae cada hora: es el tipo de división que hace volver a la gente hacia la puerta de enlace. La versión es una propiedad del cliente, y la puerta de enlace no sabe qué compilación está conectada.
Actualice primero un dispositivo de prueba y vigile el reloj. Un dispositivo que empieza a caer en el intervalo de la directiva tras la actualización confirma el mecanismo sin tocar la directiva de producción.
Paso 3: encontrar dónde vive la directiva
La frecuencia de inicio de sesión es un ajuste de Acceso Condicional en la directiva que apunta a la aplicación empresarial Azure VPN. No está en el recurso de puerta de enlace VPN, ni en la configuración de punto a sitio, ni en el perfil del cliente. Busque la aplicación Azure VPN en la lista de directivas y lea los controles de sesión.
Dos directivas pueden aplicarse a un usuario, y gana la más estricta, así que un valor que nunca configuró puede ser el vigente. Compruebe una directiva base para todo el inquilino y también la específica de la aplicación. El alcance del informe también importa: una directiva que excluye a un grupo produce una población con un comportamiento distinto y sin explicación evidente.
Paso 4: hacer las cuentas
La desconexión llega una hora después del valor de frecuencia de inicio de sesión, en el comportamiento que Microsoft documenta para este cliente; una frecuencia de siete horas da unas ocho horas de conectividad. Ese desfase explica que un valor elegido para una jornada de ocho horas parezca roto por la tarde mientras una prueba de nueve horas se ve bien. Convierta la queja en números antes de cambiar nada: hora de conexión, hora de desconexión, diferencia y luego comparación con el valor de la directiva más una hora.
Si la diferencia no coincide con esa suma, la hipótesis del calendario es falsa y debe dejar de ajustar la directiva.
Paso 5: separar un calendario de un rekey
El rekey de IPsec, la detección de par muerto y los tiempos de inactividad producen cortes irregulares ligados al volumen de tráfico o al silencio, no a un cronómetro. Un usuario cortado en mitad de una transferencia y otro cortado tras una comida inactiva describen mecanismos distintos. Pregunte qué estaba haciendo el usuario en el minuto anterior a la desconexión.
Los problemas de certificado tienen otra cara: el cliente no logra conectar en lugar de perder una sesión activa, y el fallo es inmediato. Una solicitud MFA que nunca se completa se presenta como un cuelgue, no como un corte horario limpio seguido de una reconexión correcta.
Paso 6: desplegar sin sorpresas
Anuncie la actualización del cliente antes de que llegue a los usuarios por la tienda, porque el cambio de comportamiento viaja con el cliente. Elija la frecuencia según el requisito: un valor que cubra la jornada por usabilidad, o un valor corto si un portátil perdido debe perder el acceso rápido. Registre qué requisito ganó, ya que el mismo ajuste produce tanto la protección como la queja. Luego confirme la elección en un dispositivo con la nueva compilación en lugar de extrapolar de un piloto que usaba la anterior.
Guarde el mensaje, la versión, el valor de la directiva y el intervalo medido en una sola nota. Ese registro responde al siguiente aviso en un minuto en lugar de exigir una reconstrucción.