Linux の Check Point VPN:SNX は自分でダウンロードして入れるものではない
Linux 用の Check Point インストーラーはどこにもありません。SNX はゲートウェイのポータルから渡され、Mobile Access ブレードが必要で、古いディストリビューション一覧とともに生きています。
Check Point の Linux クライアントを探しても、インストーラーの置かれたダウンロードページは見つかりません。その不在はパッケージングの穴ではありません。Check Point の Linux 向けリモートアクセスクライアントは SSL Network Extender、つまり SNX で、ブラウザーで認証したあとにゲートウェイが渡してくれます。これが飲み込めれば、残りの混乱も筋が通ります。この話題の記事がほぼすべて何年も前のものなのもそのためです。
俗説:ダウンロードしてインストールするクライアントがある
その期待は他のあらゆるベンダーから来ています。OpenVPN、WireGuard、そしてほとんどの商用クライアントはパッケージかリポジトリーを公開していて、インストールは自分だけで決めるローカルな判断です。Check Point は Linux ではそう動きません。現行のゲートウェイ版の公式ダウンロードに単体のインストーラーはなく、探しても古いフォーラムのスレッドや第三者のミラーが出てくるだけです。
そのミラーは無用どころか有害です。ビルドは、それを配るゲートウェイと一致していなければならないからです。
SNX の正体と、どこから来るのか
SNX はバイナリー名が snx のコマンドラインクライアントで、ブラウザーでゲートウェイに対して開始したセッションを通じてインストールされます。以前は Java アプレットが、プロンプトに同意したあとにダウンロードとインストールを行っていました。仕組みは年々変わりましたが、配布元は変わっていません。ゲートウェイは自分に合うビルドを配るので、クライアントとゲートウェイの版は連動し、古いパッケージからコピーしたクライアントはゲートウェイがまだ会話している間だけ動きます。
これは、クライアント側の作業が意味を持つ前にゲートウェイ側が整っていなければならないということも意味します。Mobile Access Software Blade のライセンスと設定が必要で、それがなければインストール元のポータルがありません。ポータルを出していないゲートウェイに対しては、クライアント側でどれだけ努力してもセッションはできません。
自分のユーザー名でクライアントをゲートウェイに向け、何を報告するのかを読み取ります:
snx -s vpn.example.com -u your.name
制約はインストーラーではなく、ディストリビューションの対応です
SNX についてベンダーが対応をうたうディストリビューションの一覧は短く、古いものです。公開された記事では Ubuntu 17.04 あたりで止まり、同じ時期の openSUSE、Fedora、RHEL のいくつかの版が並び、いまも Ubuntu 12.10 が載っています。これは一覧がどう古びるかを示すもので、あなたのマシンに何が必要かではありません。現在のディストリビューションはそもそも載っていません。
動くトンネルを期待する前に、ライブラリーの不一致を想定してください。よくある三つは、64ビットシステムで欠けている32ビットライブラリー、バイナリーが一度もリンクされていない OpenSSL の版、そしてクライアントがビルドしようとするカーネルモジュールです。パッケージを推測するのではなく、欠けているシンボルを読みます:
ldd $(command -v snx) | grep "not found"
そのうえで、実際に接続するゲートウェイの版のサポート記事を確認してください。ブログの一覧は互換性の表明ではなく、新しいディストリビューションが新しいクライアントを意味するわけでもありません。
画面なしの作業を可能にする X11 の細部
SNX は X11 ライブラリーを必要としますが、動いている X サーバーは必要としません。この違いが、画面のないホストで SSH 越しに動くクライアントと、出力もなく固まったように見えるクライアントのすべての差です。別の版からコピーした束ではなく、自分のディストリビューションが提供するライブラリーパッケージを入れ、トンネルを必要とするセッションからクライアントを実行してください。
接続したら、インターフェースとルートの両方を、どちらも信じる前に読みます:
ip -brief addr show
ip route show
SNX はトンネルインターフェースを作り、ポータルが定めたルートをインストールします。そのルートはあなたではなくゲートウェイの判断なので、欠けたプレフィックスはクライアントの不具合ではなくゲートウェイ側のプロファイルの問題です。同時に DNS も確認してください。分割トンネルのプロファイルは、想定していないリゾルバーを押し込むことがよくあります。
SNX がまったく間違った答えである場合
Check Point のゲートウェイは IPsec とL2TPのクライアント対サイト接続も終端でき、それらは strongSwan、Libreswan、NetworkManager の L2TP プラグインで動きます。それはゲートウェイの設定であり、クライアントの小技ではありません。ゲートウェイが Mobile Access ポータルだけを公開しているなら、IPsec クライアントには交渉する相手がありません。ログには認証失敗ではなくタイムアウトが出ます。何かを入れる前に、どのリモートアクセス用ブレードが有効かを確認してください。
ここでの制約はすべてゲートウェイ側にあります。ブレード、ライセンス、クライアントのビルド、ルートのプロファイルです。CLI は何年も動いています。壊れているのは、Linux 対応とは自分が所有し管理するパッケージのことだという思い込みです。