合理的假设是:你从 GlobalProtect 门户下载的 .deb 坏了,或者厂商发布了有问题的构建。通常并非如此。厂商的 Linux 界面仍链接 Qt5 WebKit,而较新的 Ubuntu 发行版不再提供它,所以这个包在要求一个被你的发行版有意移除的库。这是打包不匹配,不是下载损坏;而这个区别决定了你是在花一下午强行塞包,还是花十分钟换一个客户端。

.deb 没有坏

发行版不再携带的依赖,是库退役后的正常结果。Qt5 WebKit 从后来的 Ubuntu 软件源和 Debian 中被移除,原因是安全维护,而不是需求不足。一旦如此,任何仍链接它的包都无法安装,无论构建得多好。

两种失败被报成同一个 bug,其实不是。在没有该库的发行版上,安装器会停在未满足的依赖处。在客户端能装上、但登录时失败的发行版上,你看到的是内嵌浏览器组件里的 TLS 或 SAML 握手问题。前者是打包问题,后者是运行时问题,两者都不是把旧库复制进现代桌面就能修的。

确认依赖,而不是强行塞入

显式安装这个包,让工具点出未解决的依赖,而不是只给你一份摘要。然后问:你的发行版到底有没有候选包,因为“此处不可用”和“暂时从这个镜像缺失”会导向完全不同的决定:

sudo apt install ./GlobalProtect_UI_deb-*.deb
apt-cache policy libqt5webkit5
apt-cache rdepends --installed libqt5webkit5

如果 apt-cache policy 没有报告任何候选包,就别再尝试安装它,转而挑选替代方案。有意思的不是缺失的包名,而是厂商的依赖图没有跟随用户实际运行的发行版一起演进。

强行塞入旧包会对桌面做什么

流传的绕法是从旧发行版里拉来这个库。在当前的 Ubuntu 上,这会导致 Qt5 次版本冲突:旧包会把 libqt5core5t64 往回拖,随后已安装的 KDE 和 PyQt 包开始要求被降级的库不再提供的 ABI 版本。结果是破坏无关应用程序的部分升级,这比一开始那个下午糟糕得多。

这个结果是可预期的,而不是运气差。Qt 对次版本的 ABI 期望很严格,一个发行版只提供一套自洽的组合。混入另一个发行版的一个库不是定点修复,而是第二次、控制更差的升级。

同样的建议适用于失败的运行时版本。为了让旧客户端的握手通过而降低全系统的 OpenSSL 安全级别,等于为了修一个应用而改动机器上的每一条 TLS 连接,包括你之后出事时要用到的包管理器。

openconnect 说的是这个协议

OpenConnect 直接实现了 GlobalProtect 的协议,而 协议说明 既描述了调用方式,也描述了两个服务器接口之间的分工。门户负责下发设置和网关列表,网关负责终结隧道:

openconnect --protocol=gp vpn.example.com
openconnect --protocol=gp --authgroup=staff vpn.example.com

如果门户没有列出你需要的网关,--usergroup=gateway,或者以 /gateway 结尾的 URL,就会跳过门户这一步。当提供多个网关时,--authgroup=NAME 会在其中选择。认证是用户名加密码,可选地再加客户端证书;SAML 网关在实践中通过 network-manager-openconnect 工作,而不是手敲命令行。

带有严格 posture 策略的网关可能还要求在发放隧道前提交 HIP 报告。OpenConnect 能生成并提交,但如果网关要求一份它无法产出的清单,任何参数都改不了那条策略;那是服务器端的决定。

验证隧道,并知道 openconnect 修不了什么

别信成功提示,去看隧道实际应用了什么。网关以 XML 下发路由和配置,客户端再应用,所以缺少路由是配置或选择问题,不是客户端 bug:

ip -4 addr show
ip route
resolvectl status

MTU 值得单独看。GlobalProtect 的配置总是报告 MTU 为零,所以客户端要靠封装开销来估算。小请求能过、大传输卡住是典型症状,解法是在连接上显式设定 MTU,而不是关掉路径发现。

IPv6 又是另一回事。PAN 在 GlobalProtect 4.0 中加入了它,而 OpenConnect 的支持从 9.0 版起被标为实验性,所以别因为隧道起来了就以为这个地址族会像 IPv4 一样表现。如果网关强制一项开源客户端无法满足的 posture 检查,就在受支持的 LTS 发行版上运行厂商客户端,工作站已经升级的话就放进虚拟机。这样桌面保持完整,旧依赖被限在你还能重建的边界之内。

相关文章