FortiGate SSL-VPN 接 DUO 2FA：两个不写在首页的关键坑

给 FortiGate（100F）的 SSL-VPN 加 DUO 二次验证，架构是标准做法：

FortiClient → FortiGate ──RADIUS──> DUO Authentication Proxy（装在 AD 服务器上）
                                        ├─ 一次验证：转发给 AD（LDAP）验密码
                                        └─ 二次验证：DUO 推送到用户手机

官方文档把安装步骤写得很清楚，但有两个坑不踩过不知道疼。

SSL-VPN + DUO 认证链路图，标注两个关键坑

完整认证链路和两个坑的位置——都出在 FortiGate 这一环

坑一：默认 5 秒超时，push 必死

FortiGate 的 remote auth 默认超时是 5 秒。DUO 的手机推送流程是：用户发起 VPN 连接 → 手机收到推送 → 掏出手机点批准——这一套下来 5 秒根本不够，结果就是：密码验证明明成功了，用户还没来得及点手机，FortiGate 已经判定认证失败。

症状极具迷惑性：输错密码立刻被拒（正常），密码正确反而「卡一下然后失败」。

修复要走 CLI（GUI 里没有这个选项）：

config system global
    set remoteauthtimeout 60
end

DUO 官方建议至少 60 秒，我们最终设了 120 秒，给手机不在手边的用户多留点余地。

坑二：用户组里残留 LDAP = 2FA 白装

配好 RADIUS server 之后，要把 SSL-VPN 用的用户组指向它。这里有个致命细节：

必须把组成员里原来的 LDAP server 替换成 RADIUS server，而不是「再加一个」。

如果组里 LDAP 和 RADIUS 并存，认证请求命中 LDAP 就直接放行了——密码对了就进，DUO 那一跳压根不会发生。界面上看 2FA「配好了」，实际上等于没有。装完一定要实测：正确密码登录，手机必须收到推送才算数；不弹推送就直接放行的，就是这个问题。

验证 checklist

正确密码 + 批准推送 → 成功登录；
正确密码 + 拒绝推送 → 登录失败（验证 2FA 真的在链路上）；
错误密码 → 立刻失败（不该触发推送）；
从零开始计时：用户从连接到批准推送的真实耗时，确认在 timeout 以内。

教训

涉及「人要操作手机」的认证链路，把所有超时都当嫌疑人。5 秒对机器是永恒，对掏手机的人只是个开始；
加固类变更（2FA、ACL）装完必须做负向测试——「拒绝推送能不能挡住登录」比「批准能不能进来」重要得多；
FortiGate 不少关键参数只在 CLI 里（remoteauthtimeout 就是），GUI 翻不到的时候去 CLI reference 搜一下再下结论。