SSL VPN 认证超时致大量用户无法远程办公的定位

Wed, 17 Apr 2024 07:50:00 +0000

问题背景

公司使用 FortiGate 防火墙自带的 SSL VPN 功能为远程办公用户提供接入服务，认证方式为 LDAP + Radius 双因子认证，LDAP 对接 AD 域控做身份验证，Radius 对接企业微信的 OTP 验证码。高峰期在线 VPN 用户约 150 人。

故障现象

周一早上 7:45，IT 服务台陆续收到超过 30 个 VPN 连接失败的工单。现象一致：用户在 FortiClient 中输入账号密码后，界面长时间显示"正在连接"，约 60 秒后提示"认证失败"或"连接超时"。到 8:30 高峰期时，VPN 在线用户数从平时的 120 人骤降至 8 人。

FortiGate 日志中大量出现：

1
2

SSL VPN login failed: LDAP authentication timeout for user zhangsan
(Connection timed out)

排查过程

第一步：确认网络连通性

1
2

$ ping vpn.company.com            # 正常，SSL端口可达
$ curl -k https://vpn.company.com:443/remote/login  # 登录页正常加载

VPN 网关本身可达，认证页面正常——问题出在认证后端。

第二步：单独测试 LDAP

在 FortiGate 上执行 LDAP 诊断：

1
2

# 进入 FortiOS CLI
diagnose test authserver ldap <server-name> zhangsan password

输出显示 LDAP 查询超时。登录 AD 域控检查：

PS> Get-Service -Name NTDS, DNS, KDC | Select Name, Status
Name  Status
----  ------
NTDS  Running
DNS   Running
KDC   Running    # 所有服务运行正常

1
2

PS> netstat -ano | findstr :389   # LDAP 端口正常监听
PS> netstat -ano | findstr :88    # Kerberos 端口正常监听

AD 服务全部运行中，端口正常。

第三步：检查时间同步——找到根因

PS C:\> w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 1
Precision: -6 (15.625ms per tick)
Root Delay: 0.0000000s
Root Dispersion: 10.0000000s
ReferenceId: 0x4C4F434C (source IP:  192.168.1.100)  # 指向自己？
Last Successful Sync Time: 2024-04-14 03:00:05        # 3天前！
Source: Local CMOS Clock                               # 源是CMOS时钟！
Poll Interval: 10 (1024s)

域控 NTP 服务在 4 月 14 日之后停止同步外部时间源，本地 CMOS 时钟已经漂移了 +7 分钟。

PS C:\> net time \\dc01
Current time at \\dc01 is 2024-04-17 7:57:32

PS C:\> w32tm /stripchart /computer:pool.ntp.org
07:50:15, +423.8716583s    # 与标准时间偏差7分钟！

FortiGate 通过 NTP 同步了标准时间，而 AD 域控快了 7 分钟。Kerberos 协议要求客户端和 KDC 之间的时间偏差不超过 5 分钟（默认），超过后票据验证失败。

第四步：确认 Kerberos 认证失败

在 FortiGate 侧做更详细的抓包：

packet: src=10.1.1.10:389 dst=10.1.2.1:52345
LDAP bindRequest => response: 
  resultCode: invalidCredentials (49)
  errorMessage: 80090308: LdapErr: DSID-0C0905EF, 
  data 52e, v3839

错误码 52e 表示凭据无效，但在域控日志中实际是 KRB_AP_ERR_SKEW（时钟偏差过大），只是 LDAP 层包装成了通用认证失败。

解决方案

紧急修复：

1
2
3

# 域控上强制执行 NTP 时间同步
w32tm /config /syncfromflags:manual /manualpeerlist:"pool.ntp.org,0x9" /update
w32tm /resync /force

验证：FortiGate 上执行 diagnose test authserver ldap 重新测试，认证成功。
验证 Kerberos 票据：

`1`	`klist tickets # 确认新票据时间戳正确`

同步完成后，VPN 登录在 3 分钟内逐步恢复。

根因分析

直接原因：AD 域控的 Windows Time 服务在上周系统更新后配置丢失，回退为使用本地 CMOS 时钟，3 天内漂移了 7 分钟。Kerberos 协议要求时间偏差 ≤5 分钟，超限后票据验证失败，LDAP 认证超时。

深层原因：

域控未配置冗余的 NTP 源（只配了一个内部 NTP，该 NTP 本身就是域控自己）
FortiGate 的 LDAP 超时设置过短（10 秒），且错误提示不区分"服务器不可达"和"认证失败"
缺少域控 NTP 同步状态监控

预防措施

NTP 冗余配置：域控配置至少 3 个外部 NTP 源，避免单点故障
NTP 监控告警：通过 Zabbix 监控域控 NTP 同步状态和时间偏差
Kerberos 容错参数：评估将最大时钟偏差从 5 分钟调整到 10 分钟的可行性
LDAP 超时优化：将 FortiGate LDAP 超时设置为 30 秒，并区分超时类型记录日志
定期巡检：每月检查所有域控的时间同步状态

总结

一个看似与网络毫无关系的"AD 域控时间不准"问题，最终演变成了全公司远程办公中断。Kerberos 协议对时间的严格要求是双刃剑——既提供了防重放攻击的安全保障，又在时间偏差时成为故障源。对于依赖多系统协同的认证链路（VPN → LDAP → AD/Kerberos），时间同步是最容易被忽视但又最致命的一环。

SSL VPN on Zero Day Notes