Azure VPN Client 3.4 desconéctase cada hora: frecuencia de inicio de sesión
Non é a pasarela: o cliente agora aplica a frecuencia de inicio de sesió no medio da sesió, polo que o túnel mor ao ritmo da política. Versión, desfase e comprobacións.
Un usuario conéctase, traballa e despois desconcéctase unha vez por hora cunha mensaxe de que a autenticación con Microsoft Entra caducou. A reconexión funciona e o ciclo repítese como un cronómetro. Nunha pasarela punto a sitio onde non se despregou nada, ese patrón apunta a a credencial e non ao túnel. Azure VPN Client 3.4.0 comezou a aplicar a frecuencia de inicio de sesión do acceso condicional durante unha sesión establecida, unha política que os clientes anteriores só avaliaban ao iniciar sesión.
Percorra as seis comprobacións seguintes por orde. Cada unha confirma ou descarta o calendario, e parar demasiado pronto é como se reconstrúe unha pasarela para nada.
Paso 1: lea a mensaxe exacta
A redacción separa as capas. Unha mensaxe sobre a caducidade da autenticación Entra é unha afirmación sobre o token; un erro de túnel ou de asociación de seguridade non o é. Anote tamén o tempo transcorrido, medido da conexión á desconexión e non desde o comezo da xornada.
Se o usuario pode reconectar de inmediato e a pasarela segue mostrando un túnel san, está ante a caducidade do token e non ante un par morto.
Paso 2: obteña a versión do cliente
Lea a versión na aplicación, non no rexistro de despregamento. O cambio chegou coa 3.4.0, así que a 3.3.1 e anteriores manteñen vivo un túnel establecido independentemente da política. Un portátil non xestionado cunha compilación anterior compórtase perfectamente mentres o resto do equipo cae cada hora: é o tipo de división que fai volver a xente cara á pasarela. A versión é unha propiedade do cliente, e a pasarela non sabe que compilación está conectada.
Actualice primeiro un dispositivo de proba e vixíe o reloxo. Un dispositivo que comeza a caer no intervalo da política despois da actualización confirma o mecanismo sen tocar a política de produción.
Paso 3: atope onde vive a política
A frecuencia de inicio de sesión é un axuste do acceso condicional na política que apunta á aplicación empresarial Azure VPN. Non está no recurso de pasarela VPN, nin na configuración punto a sitio, nin no perfil do cliente. Busque a aplicación Azure VPN na lista de políticas e lea os controis de sesión.
Dúas políticas poden aplicarse a un usuario, e gaña a máis estrita, así que un valor que nunca definiu pode ser o vixente. Comprobe tanto unha política base para todo o inquilino como a específica da aplicación. O alcance do informe tamén importa: unha política que exclúe un grupo produce unha poboación con comportamento distinto e sen explicación evidente.
Paso 4: faga os cálculos
A desconexión chega unha hora despois do valor de frecuencia de inicio de sesión, no comportamento que Microsoft documenta para este cliente, así que unha frecuencia de sete horas dá unhas oito horas de conectividade. Este desfase explica que un valor escollido para unha xornada de oito horas pareza roto pola tarde mentres unha proba de nove horas parece correcta. Converta a queixa en números antes de cambiar nada: hora de conexión, hora de desconexión, diferenza e despois comparación co valor da política máis unha hora.
Se a diferenza non coincide con esa suma, a hipótese do calendario é falsa e debe deixar de axustar a política.
Paso 5: separe un calendario dunha rekey
A rekey IPsec, a detección de par morto e os tempos de inactividade producen cortes irregulares ligados ao volume de tráfico ou ao silencio, non a un cronómetro. Un usuario cortado no medio dunha transferencia e outro cortado despois dun xantar inactivo describen mecanismos distintos. Pregunte que estaba facendo o usuario no minuto anterior á desconexión.
Os problemas de certificado teñen outra cara: o cliente non consegue conectar en vez de perder unha sesión activa, e o fallo é inmediato. Unha solicitude MFA que nunca remata preséntase como un bloqueo, non como un corte horario limpo seguido dunha reconexión correcta.
Paso 6: despregue sen sorpresas
Anuncie a actualización do cliente antes de que chegue aos usuarios pola tenda, porque o cambio de comportamento viaxa co cliente. Escolla a frecuencia segundo o requisito: un valor que cubra a xornada por usabilidade, ou un valor curto se un portátil perdido ten que perder o acceso axiña. Anote que requisito gañou, xa que o mesmo axuste produce tanto a protección como a queixa. Despois confirme a elección nun dispositivo coa nova compilación en vez de extrapolar dun piloto que usaba a anterior.
Garde a mensaxe, a versión, o valor da política e o intervalo medido nunha soa nota. Ese rexistro responde ao seguinte aviso nun minuto en lugar de esixir unha reconstrución.