Azure VPN Client 3.4 每小时断线：登录频率

一名用户连接、正常工作，然后每小时被断开一次，提示与 Microsoft Entra 的身份验证已过期。重新连接有效，循环像秒表一样重复。在什么都没部署的 point-to-site 网关上，这种模式指向凭据而不是隧道。Azure VPN Client 3.4.0 开始在已建立的会话中执行条件访问的登录频率，而旧版客户端只在登录时评估这条策略。

按顺序完成下面六项检查。每一项要么确认时间表，要么排除它，而过早停下正是白白重建网关的原因。

第 1 步：读准确的消息

措辞区分层次。关于 Entra 身份验证过期的消息是针对令牌的；隧道或安全关联错误则不是。还要记下经过的时间，从连接量到断开，而不是从上班开始。

如果用户能立刻重连，网关也仍显示健康的隧道，那看到的是令牌过期，而不是对端死亡。

第 2 步：查客户端版本

在应用里读版本，不要在部署记录里读。变化随 3.4.0 到来，因此 3.3.1 及更早版本会无视策略让已建立的隧道保持存活。一台未托管、装着旧版本的笔记本一切正常，而团队其余人每小时掉线：正是这种分化把人送回网关。版本是客户端的属性，网关并不知道连的是哪个版本。

先更新一台测试设备并盯着钟。更新后在策略间隔上开始掉线的设备，在不碰生产策略的情况下确认了机制。

第 3 步：找出策略在哪里

登录频率是针对 Azure VPN 企业应用的那条策略里的条件访问设置。它不在 VPN 网关资源上，不在 point-to-site 配置里，也不在客户端配置文件中。在策略列表里搜索 Azure VPN 应用，读取会话控制。

一个用户可能适用两条策略，更严格的那条会赢，所以你没设过的值可能就是生效值。既要检查整个租户的基线策略，也要检查应用专属策略。报表范围也很重要：排除某个组的策略会产出一批行为不同、却没有明显解释的人。

第 4 步：算一算

断开发生在登录频率值之后一小时，这是 Microsoft 为该客户端记录的行为，所以七小时的频率大约给出八小时连通。正是这个偏移让为八小时工作日选的值在下午显得坏了，而九小时的测试看起来正常。改动任何东西之前，先把抱怨变成数字：连接时间、断开时间、差值，再与策略值加一小时比较。

如果差值对不上这个和，时间表假设就是错的，应当停止调整策略。

第 5 步：把时间表和 rekey 分开

IPsec rekey、死对端检测和空闲超时产生的掉线与流量大小或安静有关，而不与秒表有关。传输中途掉线的用户和午休无操作后掉线的用户在描述不同的机制。问用户断开前一分钟在做什么。

证书问题又是另一副样子：客户端连不上，而不是丢掉工作中的会话，而且失败是立即的。永远完不成的 MFA 提示表现为卡住，而不是干净的每小时掉线后紧跟一次成功重连。

第 6 步：不要制造意外地推行

在客户端更新通过商店到达用户之前先通知，因为行为变化随客户端一起交付。按需求选择频率：为了可用性选覆盖工作日的值，或者如果丢失的笔记本必须尽快失去访问权就选短值。记录哪条需求获胜，因为同一个设置既产生保护也产生抱怨。然后在新版本的设备上确认选择，而不是从跑旧版本的试点外推。

把消息、版本、策略值和测得的间隔放在一条记录里。那条记录用一分钟回答下一份报告，而不是重建。