Linux 上の SNX：32 ビットライブラリとリセットされるリゾルバー

Linux 上の SNX はローダー、ルートテーブル、リゾルバーのいずれかで失敗し、どれもログイン問題に見えます。4 つの症状を順に処理してください。

Check Point の SSL Network Extender は Linux 上で四つの見分けやすい形で失敗し、そのうち三つはログイン問題と誤読されます。バイナリが起動しない、起動してもルートを残さない、接続しても名前解決が死ぬ、ブラウザーのポータルは動くがコマンドラインは動かない、のいずれかです。この順に処理してください（それぞれが次の入口条件だからです）。

症状一：ログインの前にローダーが拒否する

ファイアウォールから取得したインストーラーは32 ビットの setuid-root バイナリを /usr/bin/snx に置きます。64 ビットのディストリビューションでは、i386 アーキテクチャーを有効にし、リンク先のライブラリが揃うまで動きません。

sudo dpkg --add-architecture i386
sudo apt update
sudo apt install libstdc++5:i386 libstdc++6:i386 libx11-6:i386 libpam0g:i386
ldd /usr/bin/snx | grep "not found"

not found の一覧が空であることが、その後のすべての関門です。必要なパッケージの正確な組み合わせはリリースごとに変わります：ある成功報告では libstdc++5:i386、libx11-6:i386、libpam0g:i386 が必要で、別の報告では libstdc++6:i386 も必要でした。別のディストリビューション向けに書かれたチュートリアルからパッケージ一覧をコピーするのではなく、ldd を読んでください。

snx がまったく見つからない場合、インストーラーが完了しなかったか、PATH の外にインストールされています。これは別の障害であり、システムにアーキテクチャーを追加する前に確認する価値があります。command -v snx で確認し、インストーラーが報告したディレクトリを見てください。バイナリが単に存在しないマシンに i386 パッケージを追加しても何も直りません。

症状二：ログインは成功するが何もルーティングされない

ログインに成功すると tunsnx が作られ、ルーティングテーブル自体が編集されるので、他の何かを変える前に実際に何が存在するかを確認してください。

ip -br addr show tunsnx
ip route | grep tunsnx
snx -d

解体には snx -d を使ってください。プロセスを kill するとインターフェースとそのルートが残り、次の試行は認証情報とは無関係な理由で失敗します。最初のログインではサーバー署名が /etc/snx/ の下に記録されるため、無人スクリプトはそもそも動く前に一回の対話実行を必要とすることがあります。この状態を削除するのは、サーバーを再承認するつもりのときだけにしてください。

症状三：トンネルが上がるまで名前は解決される

静かに壊れるのはこれです。snx はプッシュされた DNS サーバーを /etc/resolv.conf に直接書き込みます。そのパスが /run/systemd/resolve/ へのシンボリックリンクである場合、次のリゾルバーイベントで編集が失われることがあり、切断後もプッシュされたエントリがそのまま残ることがあります。

二つの構成が機能しますが、選択は最初の検索結果が示したものではなく、意図的に行うべきです。

  • ファイルを引き取る：シンボリックリンクを静的ファイルに置き換え、libnss-resolve とその i386 版をインストールすれば、ファイルが下から書き換えられても名前サービスに代替手段が残ります。
  • systemd-resolved を所有者のままにしてトンネルリンクを登録します：resolvectl dns tunsnx 10.0.0.10、次に resolvectl domain tunsnx corp.example、そして resolvectl status で確認します。

接続する前に VPN 以前のネームサーバーを記録してください。ファイルを手で編集した場合、後でプッシュされたエントリを削除することは手順の一部であり、任意の後片付けではありません（切断後も社内 DNS を保持したままのノート PC は、他の何も解決できなくなるためです）。

症状四：ポータルは動くが CLI は動かない

最近のファイアウォールのリリースではミドルウェアがブラウザーからローカルの Java デーモンに移り、ポータルはポート 14186 のローカルエージェントと通信します。このアドレスにはブラウザーの証明書例外と実行中のプロセスが必要です。

ps ax | grep cshell
/usr/bin/cshell/launcher

コマンドラインは別の経路です：snx -s vpn.example.com -u user で、~/.snxrc がサーバー、ユーザー名、再認証の設定を保持します。ポータルのセッションが動くことは CLI が正しくインストールされているかを何も語らず、素のクライアントはワンタイムコードを扱いません。

節約より高くつくコンテナーの近道

snx は tun モジュールを確認し、なければ読み込み、トンネルインターフェースを作り、ルートを書き換えてトラフィックを通します。これをコンテナー内で再現するには /dev と /lib/modules をマウントし、広い権限を与える必要があり、ホストのネットワーク管理の大半をコンテナーに渡すことになります。

本当にサンドボックスが必要なときは、仮想マシンのほうが境界としてきれいです：クライアントは変更してよいカーネルを受け取り、ホストはルートテーブルを保ちます。与えたことを後悔する権限に午後を費やす前に、そちらを選んでください。

関連記事