新しいUbuntuでGlobalProtectのLinuxクライアントが失敗する理由

妥当な想定は、GlobalProtectポータルの.debが壊れている、あるいはベンダーが悪いビルドを出したというものだ。たいていはそうではない。ベンダーのLinux UIは今もQt5 WebKitにリンクしており、新しいUbuntuリリースはそれを同梱しなくなった。つまりパッケージは、ディストリビューションが意図的に外したライブラリを要求している。これは破損したダウンロードではなくパッケージングの不整合であり、その違いが、午後をパッケージの強制投入に費やすか、十分で別のクライアントを選ぶかを決める。

.debは壊れていない

ディストリビューションがもう提供しない依存関係は、ライブラリが引退した当然の結果だ。Qt5 WebKitは後のUbuntuアーカイブとDebianから外され、理由は需要の不足ではなくセキュリティ保守だった。そうなると、まだそれにリンクしているパッケージはどれだけよくビルドされていてもインストールできなくなる。

同じバグとして報告される二つの失敗は、実は同じではない。ライブラリのないリリースでは、インストーラが未解決の依存関係で止まる。クライアントが入ってからログインで失敗するリリースでは、埋め込みブラウザコンポーネント内部の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で送り、クライアントがそれを適用するので、欠けた経路はクライアントの不具合ではなく構成か選択の問題だ:

ip -4 addr show
ip route
resolvectl status

MTUは別に見る価値がある。GlobalProtectの構成は常にMTUをゼロと報告するので、クライアントはカプセル化のオーバーヘッドから見積もる。小さな要求は通るのに大きな転送が止まるのは古典的な症状で、対処は経路探索を切ることではなく接続に明示的なMTUを与えることだ。

IPv6はまた別の話だ。PANはGlobalProtect 4.0でこれを加え、OpenConnectの対応はバージョン9.0から実験的と説明されている。トンネルが上がったからといって、このアドレス体系がIPv4と同じに振る舞うと決めつけないこと。ゲートウェイがオープンソースのクライアントに満たせないposture検査を強いるなら、ベンダーのクライアントをサポートされたLTSリリースで、職場の機械が先に進んでいるなら仮想マシンの中で動かす。それがデスクトップを無傷に保ち、古い依存を自分で作り直せる境界の内側に置く。