OpenConnect csd-wrapper：登录前先审计脚本

把 --csd-wrapper 加进配置文件，就是把一个本地脚本交给登录时运行它的守护进程，因此你面前的决策是一次代码审查，而不是一个偏好开关。这个选项之所以存在，是为了能替换网关的主机检查组件，它需要你提供脚本的路径。以下内容都默认部署负责人已经说过需要哪种姿态检查；如果那一部分还没定，先把它定下来。这份手册有四步：定位失败的阶段、阅读脚本、选择它运行的身份、并证明结果。

第 1 步：定位失败的阶段

客户端最后一条消息通常与 cookie 有关，而那是链条的末端，不是起点。HTTPS 登录、服务器证书检查、认证交换和姿态组件都排在那条消息之前。

记录所用版本和登录地址，然后在自己的终端上保留详细输出重试一次。读第一条不是重试的错误，而不是记录的最后一行。 如果日志在点名任何评估组件之前就停住了，那说明包装脚本还不是你的问题。此时加上它，只会扩大你日后必须防守的面。

openconnect --version
openconnect --verbose --user="$VPN_USER" vpn.example.com </dev/null

把记录保存在本地，因为 cookie 和认证响应都是访问凭据。把痕迹贴进聊天线程就是凭据泄露，哪怕评估步骤看上去无害。只分享错误文本和它出现的位置，绝不分享载荷。

第 2 步：在脚本进入配置之前读完它

包装脚本的可信度只等于你审查过的那一版，所以要钉住该版本，并把哈希存在审批备注旁边。下面两条命令在读取任何一行之前，就给你一个指纹和一次廉价的语法检查。它们还给了下一位固定引用，当文件活在包管理之外时这一点很重要。两条命令都不会告诉你脚本做什么，所以跑完继续读。

sha256sum ./vpn-csd-wrapper.sh
bash -n ./vpn-csd-wrapper.sh

带着四个问题读整个文件：它是否发起出站 HTTP 调用，是否读取凭据文件或环境变量，是否写到临时目录之外，是否有分支在什么都没测量的情况下报告姿态通过。最后那种模式就是附了一条日志的策略绕过。抄来的包装脚本往往把它藏在看起来可信的检查后面。如果脚本在看设备之前就认定设备没问题，就停在这里。

也要检查被打包的载荷，因为可读的头部并不能证明文件其余部分没问题。从论坛帖子里下载脚本，并不会因为它名字像某个真实的主机检查组件就变得可信。记录谁安装的、来自哪里、将如何更新。

grep -nE 'base64 -d|xxd -r|eval |curl |wget ' ./vpn-csd-wrapper.sh

第 3 步：选择包装脚本运行的身份

--csd-user 会在 CSD、TNCC 或 HIP 程序执行期间降低权限。那个账户属于本地执行安排的一部分，而不是提交给网关的用户名。

给包装脚本一个专用账户：没有交互式 shell、没有 sudo 权限、也没有它不需要的组成员身份。授予它读取脚本及所检查的特定文件的权限，然后在动 VPN 配置之前先测试降权。在这里发现问题，比在客户端内部发现更便宜。

sudo -u vpn-csd /usr/local/libexec/vpn-csd-wrapper.sh

降低权限能限制坏脚本造成的损害。但它不审查代码、不让报告变真实，也不证明网关管理员接受这种实现符合设备策略。

第 4 步：让改动可回退

编辑前先备份配置，并把包装脚本放在版本控制里，这样回滚能恢复已知哈希，而不是到处找副本。把脚本路径、哈希、执行用户和审批人写在同一处。

要回退，就去掉该选项、重启客户端，并确认原来的错误回来了。如果回退后网关仍然拒绝登录，说明还有别的东西变了，找出那处差异要排在重试包装脚本之前。在整个变更窗口内保留上一份副本，对多数团队来说意味着直到下一个维护窗口过去。

上线成功后要检查两件事而不是一件：隧道能起来，以及本应通不过姿态检查的设备仍被拒绝。对所有人都能连上，并不能证明评估在你的改动中存活了下来。

会制造第二个问题的捷径

不要让助手在没有运行必需检查的情况下上报合规状态，也不要为了匹配另一个操作系统而覆盖平台标识。声称是别的平台，并不能证明真实设备符合策略。它留给你的，是一个在今后每次登录时都说谎的客户端。

关闭服务器验证、重放旧的 cookie、叠加未经审查的脚本，都是拿看得见的失败换看不见的失败。如果已安装的客户端无法完成受支持的流程，请申请一个获批的替代方案，而不是把现有的掰弯。

OpenConnect 手册 分别记录了 --csd-wrapper 和 --csd-user，而这正是关键提示：脚本和身份是两个决定。分别审查它们，并把两者都写下来。这样登录提示就不再是你靠粘贴代码去解的谜。