vpncli -s 与 GUI 对比：登录 Cisco Secure Client

vpnui.exe 由人手动输入，或者用脚本配合 -s 通过标准输入向 vpncli.exe 提供答案，Cisco Secure Client 面对同样的登录提示提供了这两种答法。后者让定时连接成为可能，不必去抓取 GUI 的画面，同时也把一次登录变成一个必须像凭据一样保护的文件。该选哪一种，取决于机器前有没有人，以及密码多久轮换一次。两种方式都不会改变网关要问什么，只改变由谁来回答。

两条路径最终通向同一条隧道，所以这里比较的是运维，而不是协议。

应答同样提示的两种方式

GUI 路径本身就是交互式的：客户端提问，有人回答，只要那个人不去动它，会话就一直存在。在有真人使用的笔记本上这是正确选择，因为提示会随网关的认证方式变化，而且没有人需要把明文密码留在磁盘上。

脚本路径适合自助终端、实验机器或无人值守的定时任务。代价写得明明白白：你接受磁盘上放一个凭据文件，换取无人值守的连接。如果网关支持证书或 SAML 认证，这笔交易通常就不划算了，因为文件存在只是为了回答那些更强的认证方式根本不会问到的问题。

不要在同一台机器上同时混用两者。命令行和图形客户端会争夺同一份会话状态，这就是下一节要讲的问题。

应答文件必须包含什么

客户端的提问是有顺序的——网关、有时是组选择、用户名、密码，以及任何横幅确认。能全部答上的文件大致如下，其中填入真实的值：

connect vpn.example.com
MyGroup
alice
correct-horse-battery
y

构建这个文件的可靠办法是手动连接一次，记下你输入的每一行和按下的每一次回车，然后原样复现整个序列。把组和用户名存在配置文件里的部署，可能需要在那些提示不再出现的位置补空行，而最后一行仍然需要自己的换行。少一行的文件通常会在最后一个提示处卡住，而不是给出明确的错误，所以常常被归咎于网络。把文件和自己的记录对照两遍，一遍看顺序，一遍看空行。

把文件放在任何同步目录之外，并且只让运行任务的那个账户可读。这个密码是明文，所以文件就是凭据：不进仓库、不放共享盘、不作为工单附件。客户端不会就这些提醒你任何一句。

为什么必须先关掉 GUI

先结束 GUI 进程，再从它自己的安装目录运行 CLI，因为工作目录和客户端构建版本都有影响。一个示意用的包装脚本：

@echo off
taskkill /IM vpnui.exe /F >nul 2>&1
cd /d "%PROGRAMFILES(x86)%\Cisco\Cisco Secure Client"
vpncli.exe -s < C:\secure\login.txt

退出码在这里不是可靠的成败信号。客户端会打印进度，并把隧道留在单独的进程里，所以要读输出里的连接状态行，确认之后才开始依赖 VPN 的工作。

如果跳过关闭 GUI，脚本看起来在运行，而现有会话仍停留在用户留下的状态。这种故障看起来时有时无，正是那种能熬过一周猜测的 bug。

确认会话，而不是假设它有

脚本返回后，检查只有隧道内部才存在的东西——一台内网主机，或只有企业解析器才会应答的 DNS 后缀。同时读取客户端输出里的连接状态行，其余情况一律当作失败，而不是「慢一点的成功」。在会话已经建立时重跑文件，可能把客户端留在半配置状态，所以要么先断开，要么在会话存在时跳过登录。

然后确定重连由谁负责。一个 ping 内网地址并重跑登录的循环可以让自助终端在线数月，也可能在密码第一次轮换时把账户锁死。给尝试次数设上限，超限就告警，并让身份团队去轮换文件，而不是让过期密码一直重试到被锁定。

旧的 vpnclient.exe 并不是同一个工具

同一套自动化还有更早的名字，两者并不能互换。已退役的 Cisco IPsec 客户端使用 vpnclient.exe，在一条命令行里带上 connect 动词、配置文件名称、用户名和密码等内联参数；而 vpncli.exe 期望的是标准输入上的提示序列，配合 -s。因此把旧论坛脚本抄到今天机器上，得到的是一条能运行、什么都不显示、最后却怪到网关头上的命令。

在改动任何参数之前，先确认装的是哪个客户端，以及脚本实际调用的是哪一个。名字差别小到在定时任务里会被忽略，而当继承来的脚本在升级后不再工作时，这是第一件要核实的事。