LinuxでのKerio VPNクライアント：5つの確認を順番に

LinuxにKerio VPNクライアントをインストールしてもデスクトップにアイコンは現れず、プライベートネットワークには到達できません。これは壊れたインストールではなく、このクライアントの正常な姿です。GFIのLinux向け手順はコマンドラインでの設定とサービススクリプトを説明しており、GUIは一切ありません。以下の確認を順番に進めてください。それぞれが異なる層を取り除くからです。最初の失敗がどこで止めるべきかを教え、先へ飛ばすことは通常、問題ではなかったパッケージを作り直すことを意味します。

ビルドがマシンと一致するか確認する

まず、dpkg がマシンを何と見ているか、パッケージが何向けに作られたかから始めます。通常の64ビットシステムでは dpkg --print-architecture は amd64 を出力し、ベンダーのページは通常のDebianパッケージの隣にamd64パッケージを載せています。実際にインストールしたファイル名のリリース文字列を読み、両者が一致すると仮定しないでください。

2013年のi386向けアーカイブは、--force-architecture を渡したからといって64ビットになるわけではありません。強制すると外来のバイナリが入り、まだ起動するランチャーの陰に依存関係の失敗が隠れ、デーモンが誤ったライブラリを読み込むこともあります。お手持ちのリリースが32ビットのみなら、32ビット環境で実行するか、ゲートウェイの管理者に最新ビルドを依頼してください。

依存関係の行も確認します。dpkg -s kerio-control-vpnclient | grep -i depends はパッケージが何を期待するかを示し、満たされないバージョン指定や欠けたランタイムライブラリはクライアントのログではなくここに現れます。

パッケージのウィザードで設定する

クライアントは設計上アプリ一覧に項目を持たないため、アイコンが無いことは設定の成否を何も語りません。ウィザードを次のコマンドで開き直し、sudo dpkg-reconfigure kerio-control-vpnclient その問いに答えます。VPNエンドポイント、アカウント情報、サーバー証明書のフィンガープリントです。

フィンガープリントの問いは、誤ったサーバーが勝てる唯一の場所と考えてください。値は、ゲートウェイを運用する管理者から得たサーバー情報と比較し、エンドポイントが提示するものと比べてはいけません。検証できないフィンガープリントを受け入れると、この一覧の残りは飾りになります。ピンが保存された後では、悪意あるサーバーは本物とまったく同じに見えるからです。値を別の経路で確認できなければ、トンネルが別途上がるとしても、止まって尋ねてください。

ウィザードを再実行すると設定が変わり、クライアントが再起動することがあるため、作業中のセッションがそのVPNに依存している場合はマシンへの別経路を確保してください。パスワードは通常のプロンプトで入力し、シェル履歴に残るコマンドに埋め込まないでください。

ウィザードが書くファイルを知る

設定は /etc/kerio-kvc.conf にあり、アカウントと固定したフィンガープリントの両方を持ちます。秘密の素材として扱ってください。sudo stat -c '%a %U %G' /etc/kerio-kvc.conf はそれを全員が読める形で表示すべきではありません。

許可された手動編集の後は、ネットワークスタックを再起動するのではなく、ファイルを所有するデーモンを再読み込みします：sudo /etc/init.d/kerio-kvc reload。再読み込みは設定を読み直し、現在のセッションを落とすので、生きた接続では無害な操作ではありません。

何かを変える前に以前のファイルをコピーします。編集後に認証が失敗したら、最後の正常なコピーを戻すのに数秒しかかからず、編集をネットワークから切り離せます。どちらが動いたかを知る最も安い方法です。

生きたセッションと起動時の挙動を分ける

サービススクリプトは現在の接続を制御します：sudo /etc/init.d/kerio-kvc stop は今すぐトンネルを終了し、start はそれを戻します。どちらのコマンドも次の起動時に何が起きるかは決めず、その違いは遠隔で管理するマシンでは重要です。

リンクを外したり何かをマスクしたりする前に、起動の所有者を調べます。パッケージは独自のinitスクリプトを入れることも、unitを生成することも、両方のこともあり、誤った名前を無効にすると再起動後にクライアントが戻ります。systemctl status kerio-kvc をパッケージの文書が使う名前と照合し、そのうえで起動処理が実際に読む経路を無効にします。

設定が似ているからといってOpenVPNのunitで置き換えないでください。このクライアントはKerioゲートウェイと独自のプロトコルで話すため、同じファイルを指す別のデーモンは認証に成功しません。追加の失敗は証拠を読みにくくします。GFIのLinuxクライアントは同時に一つのVPN接続しか保持しませんが、その制限はクライアント側のもので、ゲートウェイの利用者容量とは関係ありません。

ログを読み、それからリソースを検証する

三つのファイルが /var/log/kerio-kvc にデーモンの物語を伝えます：init.log はライフサイクルイベント、error.log は重大な障害、debug.log は詳細です。質問に答える最小の抜粋を読み、どこかに貼る前にエンドポイントとユーザー名を除いてください。init.log でウィザードを実行した前後に隙間があれば、デーモンが一度も再起動していないことが分かります。

有効なパッケージ、稼働中のデーモン、到達できるリソースは三つの別々の結果であり、三つすべてが揃って初めて一覧は完了します。承認された変更の後、ゲートウェイの背後にしか存在しないホストを要求し、その上で通常のサービスを開きます。トンネルが上がっていてリソースに届かないなら、残る不具合はゲートウェイの経路かファイアウォール規則にあり、たった今設定し直したクライアントにはありません。

終えた状態を記録します。パッケージのリリース、アーキテクチャ、フィンガープリントを別経路で確認したか、どの再読み込みや再起動を行ったか。そのメモが、次の人の最初の確認を安くします。