VPNアカウントごとに専用のNetworkManagerランチャーを用意する

VPNアカウントが二つ、ゲートウェイが一つ、そして最後に使った人のまま接続するデスクトップアイコン。よくある原因は、接続直前に共有プロファイルのユーザー名を書き換えるランチャーか、両方のプロファイルが偶然共有する表示名を引くランチャーです。NetworkManagerはすでにUUIDでプロファイルを区別しているので、アイコンはそのうち一つを正確に指定し、身元には触れずにおけます。持ち込むべきでないのはパスワードです。

ランチャーはポインタであり、資格情報の保管場所ではありません。

UUIDを特定し、身元を確認する

保存済みの接続を一覧し、UUID、接続ID、各プロファイルが保持するユーザー名を読みます。何かを作る前に、どのプロファイルがどのアカウントのものかを確認してください。表示名はラベルであってキーではありません。二つのアカウントが別のゲートウェイや別のプロファイルを必要とするなら、それは別の設定作業です。

ランチャーではUUIDを使います。表示名による検索は、誰かがプロファイル名を変えるまでしか機能せず、その後アイコンは誤ったアカウントとして、あるいは何にも接続しません。

デスクトップエントリを書く

デスクトップエントリには種類、名前、実行行が必要です。コマンドはそのUUIDを起動し、NetworkManagerに秘密を尋ねさせます。nmcli --ask connection up uuid ... はそのためのものです。秘密が必要なときにプロンプトが見えるよう Terminal=true を残します。プレースホルダーは実際に確認したUUIDに置き換え、プロンプトを隠すためだけにシェルのラッパーを足さないでください。

Desktop Entry仕様は Exec をプログラムとその引数として定義しています。シェルスクリプトではなく、その必要もありません。

秘密はエージェントに持たせる

秘密はユーザーごとのエージェント、キーリング、または対話的なプロンプトに属します。Exec 内のパスワードはプロセス一覧、デスクトップファイル、プロパティダイアログのスクリーンショットのいずれにも見えます。プロファイルに秘密が必要なら、対応するプロンプトに集めさせ、エージェントにそのユーザーのために覚えさせてください。

--ask は設計上対話的です。無人自動化のレシピではなく、すべての認証チャレンジやプラグインがそもそもスクリプト化できることを保証するものでもありません。

sudoに手を伸ばさない

接続を変更または有効化する権限は、そのポリシーを通じて与えられるNetworkManagerの権限であり、Unixの特権ではありません。sudo でランチャーを実行しても、別のユーザーのキーリングがプロセスに渡るわけではなく、ゲートウェイの拒否も直りません。共有マシンでは、どのローカルアカウントがどのプロファイルを見られるか、各秘密を誰が持つかを確認してください。アイコンを分けても、それだけで分離が生まれるわけではありません。

同じゲートウェイの二つのアクティブなプロファイルは、ルートをめぐって競合することもあります し、並行性の規則に違反することもあります。それはランチャーの不具合ではなく、ポリシーの問題です。

アクション全体を検証する

ランチャーを一度有効化し、三つを確認します。どのUUIDが上がったか、ゲートウェイがどの身元を見たか、期待した場所に秘密のプロンプトが出たか。接続が失敗したら、最初のエラーメッセージを残してください。ショートカットを自己完結に見せるためにパスワードをコマンドラインへ足すと、そのエラーが隠れ、より悪い問題を生みます。

UUIDとアカウントの対応をチームのメモに書きます。次にプロファイルを変える人は、どのアイコンがそれに依存しているかを知る必要があり、そのメモが名前変更を障害に変えないようにします。