Azure VPN Client 3.4 desliga-se de hora a hora: frequência de início de sessão

Um utilizador liga-se, trabalha e depois é desligado uma vez por hora com uma mensagem de que a autenticação com o Microsoft Entra expirou. A reconexão funciona e o ciclo repete-se como um cronómetro. Num gateway ponto-a-site onde nada foi implementado, esse padrão aponta para a credencial e não para o túnel. O Azure VPN Client 3.4.0 começou a aplicar a frequência de início de sessão do Acesso Condicional durante uma sessão estabelecida, uma política que os clientes anteriores só avaliavam no início de sessão.

Percorra as seis verificações abaixo por ordem. Cada uma confirma ou elimina o calendário, e parar cedo é a forma de reconstruir um gateway sem motivo.

Passo 1: ler a mensagem exata

O texto separa as camadas. Uma mensagem sobre a expiração da autenticação Entra é uma afirmação sobre o token; um erro de túnel ou de associação de segurança não é. Registe também o tempo decorrido, medido da ligação à desconexão e não desde o início do dia de trabalho.

Se o utilizador consegue reconectar-se imediatamente e o gateway continua a mostrar um túnel saudável, está perante expiração do token e não um par morto.

Passo 2: obter a versão do cliente

Leia a versão na aplicação, não no registo de implementação. A alteração chegou com 3.4.0, pelo que 3.3.1 e anteriores mantêm um túnel estabelecido vivo independentemente da política. Um portátil não gerido com uma compilação mais antiga comporta-se perfeitamente enquanto o resto da equipa cai de hora a hora: é o tipo de divisão que faz as pessoas voltar ao gateway. A versão é uma propriedade do cliente, e o gateway não sabe que compilação está ligada.

Atualize primeiro um dispositivo de teste e vigie o relógio. Um dispositivo que começa a cair no intervalo da política após a atualização confirma o mecanismo sem tocar na política de produção.

Passo 3: descobrir onde vive a política

A frequência de início de sessão é uma definição do Acesso Condicional na política que visa a aplicação empresarial Azure VPN. Não está no recurso de gateway VPN, nem na configuração ponto-a-site, nem no perfil do cliente. Procure a aplicação Azure VPN na lista de políticas e leia os controlos de sessão.

Duas políticas podem aplicar-se a um utilizador, e a mais restritiva ganha, pelo que um valor que nunca definiu pode ser o que está em vigor. Verifique uma política de base para todo o inquilino e também a específica da aplicação. O âmbito do relatório também importa: uma política que exclui um grupo produz uma população com comportamento diferente e sem explicação óbvia.

Passo 4: fazer as contas

A desconexão ocorre uma hora depois do valor da frequência de início de sessão, no comportamento que a Microsoft documenta para este cliente, pelo que uma frequência de sete horas dá cerca de oito horas de conectividade. Esse desvio explica porque um valor escolhido para um dia de oito horas parece avariado à tarde enquanto um teste de nove horas parece bem. Converta a queixa em números antes de mudar algo: hora de ligação, hora de desconexão, diferença e depois comparação com o valor da política mais uma hora.

Se a diferença não corresponder a essa soma, a hipótese do calendário está errada e deve parar de ajustar a política.

Passo 5: separar um calendário de um rekey

O rekey IPsec, a deteção de par morto e os tempos limite de inatividade produzem quedas irregulares ligadas ao volume de tráfego ou ao silêncio, não a um cronómetro. Um utilizador cortado a meio de uma transferência e outro cortado após um almoço inativo descrevem mecanismos diferentes. Pergunte o que o utilizador estava a fazer no minuto anterior à desconexão.

Os problemas de certificado têm outra cara: o cliente falha a ligação em vez de perder uma sessão ativa, e a falha é imediata. Um pedido MFA que nunca termina apresenta-se como um bloqueio, não como um corte horário limpo seguido de uma reconexão bem-sucedida.

Passo 6: implementar sem surpresas

Anuncie a atualização do cliente antes de chegar aos utilizadores pela loja, porque a mudança de comportamento vem com o cliente. Escolha a frequência a partir do requisito: um valor que cubra o dia de trabalho pela usabilidade, ou um valor curto se um portátil perdido tiver de perder o acesso depressa. Registe qual requisito venceu, pois a mesma definição produz tanto a proteção como a queixa. Depois confirme a escolha num dispositivo com a nova compilação em vez de extrapolar de um piloto que usava a antiga.

Guarde a mensagem, a versão, o valor da política e o intervalo medido numa só nota. Esse registo responde ao próximo alerta num minuto em vez de exigir uma reconstrução.