Azure VPN Client 3.4 se déconnecte chaque heure : fréquence de connexion

Un utilisateur se connecte, travaille, puis est déconnecté une fois par heure avec un message indiquant que l’authentification auprès de Microsoft Entra a expiré. La reconnexion fonctionne et le cycle se répète comme au chronomètre. Sur une passerelle point à site où rien n’a été déployé, ce schéma désigne l’identité plutôt que le tunnel. Azure VPN Client 3.4.0 a commencé à appliquer la fréquence de connexion de l’accès conditionnel pendant une session établie, une stratégie que les clients précédents n’évaluaient qu’à la connexion.

Passez les six vérifications ci-dessous dans l’ordre. Chacune confirme ou écarte le calendrier, et s’arrêter trop tôt est la façon de reconstruire une passerelle pour rien.

Étape 1 : lire le message exact

Le libellé sépare les couches. Un message sur l’expiration de l’authentification Entra est une affirmation sur le jeton ; une erreur de tunnel ou d’association de sécurité ne l’est pas. Notez aussi le temps écoulé, mesuré de la connexion à la déconnexion plutôt que depuis le début de la journée de travail.

Si l’utilisateur peut se reconnecter immédiatement et que la passerelle affiche toujours un tunnel sain, vous avez affaire à une expiration de jeton et non à un pair mort.

Étape 2 : obtenir la version du client

Lisez la version dans l’application, pas dans l’enregistrement de déploiement. Le changement est arrivé avec 3.4.0, donc 3.3.1 et les versions antérieures maintiennent un tunnel établi quelle que soit la stratégie. Un portable non géré avec une version plus ancienne se comporte parfaitement pendant que le reste de l’équipe tombe toutes les heures : c’est le genre de fracture qui renvoie les gens vers la passerelle. La version est une propriété du client, et la passerelle ignore quelle version est connectée.

Mettez d’abord à jour un appareil de test et surveillez l’horloge. Un appareil qui commence à tomber à l’intervalle de la stratégie après la mise à jour confirme le mécanisme sans toucher à la stratégie de production.

Étape 3 : trouver où vit la stratégie

La fréquence de connexion est un paramètre d’accès conditionnel de la stratégie qui cible l’application d’entreprise Azure VPN. Elle ne se trouve pas sur la ressource de passerelle VPN, ni dans la configuration point à site, ni dans le profil client. Cherchez l’application Azure VPN dans la liste des stratégies et lisez les contrôles de session.

Deux stratégies peuvent s’appliquer à un utilisateur, et la plus stricte l’emporte : une valeur que vous n’avez jamais définie peut donc être celle en vigueur. Vérifiez une stratégie de base à l’échelle du locataire ainsi que celle propre à l’application. L’étendue du rapport compte aussi : une stratégie qui exclut un groupe produit une population au comportement différent, sans explication évidente.

Étape 4 : faire le calcul

La déconnexion survient une heure après la valeur de fréquence de connexion, dans le comportement que Microsoft documente pour ce client : une fréquence de sept heures donne donc environ huit heures de connectivité. Ce décalage explique qu’une valeur choisie pour une journée de huit heures paraisse cassée l’après-midi alors qu’un test de neuf heures semble correct. Convertissez la plainte en chiffres avant de changer quoi que ce soit : heure de connexion, heure de déconnexion, différence, puis comparaison avec la valeur de la stratégie plus une heure.

Si la différence ne correspond pas à cette somme, l’hypothèse du calendrier est fausse et vous devez cesser d’ajuster la stratégie.

Étape 5 : distinguer un calendrier d’un rekey

Le rekey IPsec, la détection de pair mort et les délais d’inactivité produisent des coupures irrégulières liées au volume de trafic ou au silence, pas à un chronomètre. Un utilisateur coupé en pleine transmission et un utilisateur coupé après un déjeuner inactif décrivent des mécanismes différents. Demandez ce que faisait l’utilisateur dans la minute précédant la déconnexion.

Les problèmes de certificat ont encore un autre visage : le client échoue à se connecter au lieu de perdre une session active, et l’échec est immédiat. Une demande MFA qui ne se termine jamais se présente comme un blocage, non comme une coupure horaire nette suivie d’une reconnexion réussie.

Étape 6 : déployer sans surprise

Annoncez la mise à jour du client avant qu’elle n’atteigne les utilisateurs via le store, car le changement de comportement est livré avec le client. Choisissez la fréquence selon l’exigence : une valeur qui couvre la journée de travail pour l’ergonomie, ou une valeur courte si un portable perdu doit perdre l’accès rapidement. Consignez l’exigence qui l’a emporté, car le même réglage produit à la fois la protection et la plainte. Confirmez ensuite le choix sur un appareil exécutant la nouvelle version au lieu d’extrapoler depuis un pilote resté sur l’ancienne.

Gardez le message, la version, la valeur de la stratégie et l’intervalle mesuré dans une seule note. Ce dossier répond au prochain signalement en une minute plutôt qu’en une reconstruction.