Juniper 还是 Pulse 网关：该用哪种 OpenConnect 协议

为 OpenConnect 选协议是配对练习，不是查品牌。登录页写着 Juniper 的网关可能提供 Network Connect、Pulse 或两者，而客户端默认值两个都不是。靠猜的代价是登录失败，更糟的是开出一个把协议不匹配怪到凭据头上的支持工单。在把主机名填进配置之前，先确认服务。

OpenConnect 把旧协议称为 nc，新协议称为 pulse，两者都在同一个二进制里。你选的标志改变的是登录交换，不是连接成功后的路由。

两个协议名共用一段产品历史

Juniper 的 Network Connect 与后来的 Pulse Secure 客户端，是同一类设备在不同时期暴露的不同协议。OpenConnect 为前者写了 nc 处理器，为后者写了 pulse 处理器。它们是各自独立的代码路径和请求格式，所以支持其中一个并不能说明另一个。

差异在登录对话里立刻显现：端点、表单字段以及客户端报告第二个因素被拒的方式，在两个处理器之间都不一样。

在命令行上选择只是改一个词：Network Connect 用 openconnect --protocol=nc vpn.example.com，Pulse 用 openconnect --protocol=pulse vpn.example.com。两次尝试都是真正的连接尝试，会重新配置路由和 DNS，所以要有意识地执行。不要在命令行上放密码，也不要为了绕过协议错误而关闭证书校验，因为那只是掩盖不匹配，并没有修复它。如果要看客户端发了什么，--dump-http-traffic 会打印交换内容，通常能认出网关期望的处理器。

让协议与网关实际暴露的服务匹配

设备只回应它被配置提供的协议。纯 Pulse 服务即使凭据正确也会拒绝 nc 登录，而旧的 Network Connect 服务没有可应答的 pulse 端点。问管理员启用了哪一种，以及他们支持哪个客户端。改过名字的设备、过期的 wiki 页面和熟悉的 Web 门户，都是弱证据。

知道协议后，确认周边要求：证书或令牌认证、认证组选择，以及任何端点合规检查。这些决定了命令行客户端究竟能否完成登录。

认证可以在协议之前先把问题定下来

部署可能要求客户端证书、通过浏览器走一趟 SAML，或在放行前由主机检查器检查机器。OpenConnect 的 pulse 处理器记录了其中一些流程的兼容性限制，nc 处理器也有自己的缺口。浏览器里能用的密码只能证明账号有效，不能证明任意 CLI 或桌面插件能走完同一串流程。一旦涉及主机检查器，客户端就需要管理员提供的包装脚本。没有它，登录会在第一个响应后卡住，看起来像协议故障，实际缺的是合规步骤。

认证组选择是另一个常见卡点，因为有多组的网关会要求客户端指明其中一组。

在命令行上，--authgroup="Employees" 提供这个选择，省略它可能让会话落进拒绝该账号的默认组。使用证书时，--certificate 指向客户端证书和密钥，之后网关仍可能要求令牌。在围绕它做任何自动化之前，先用详细输出完整跑一遍。

当桌面前端无法表达这个选择时

图形前端自带各自的功能集，较旧的插件可能早于你需要的协议。NetworkManager 的 OpenConnect 集成把选择存进连接数据，所以 nmcli connection modify "Office VPN" vpn.data "protocol=pulse" 可以设置编辑器里看不到的值。先确认已安装的插件版本支持这个键，再假定修改已生效。

如果菜单只提供 PPTP 或 L2TP，选其中任何一个都不会把 Pulse 服务变成那种协议。应安装受批准的集成，而不是改用菜单碰巧列出的东西。

登录仍然失败时该记录什么

记录四件事：所选协议、客户端与插件版本、预期的认证流程，以及第一个带状态码而非超时返回的错误。这组信息能把错误的处理器与缺失的证书、被拒的认证组或被拦下的合规检查区分开。详细输出同样值得保留，因为它显示的是失败的那次请求，而不只是症状。

成功之后，把可用的命令或配置留在网关名旁边。否则下一个连接的人还会重复同样的品牌对协议之猜。