nmcli が VPN パスワードを何度も尋ねる: シークレットをローカルに保存する

同じプロファイル、二つのセッション。デスクトップからは接続できるのに、SSH 越しでは何も答えられないプロンプトで止まります。壊れているものも、失われた設定もありません。NetworkManager がシークレットエージェントに認証情報を求めているのであり、シークレットエージェントは、いま使っているセッションには存在しないデスクトップ側のコンポーネントです。

以下の手順を実行すれば、トンネルは GUI なしで立ち上がりますが、シークレットを保存すると、そのプロファイルを使える人が変わる点に注意してください。

何かを編集する前に診断を確認する

対話型と非対話型のアクティベーションの違いが、診断のすべてです。nmcli --ask connection up が成功するのに通常のアクティベーションが止まるなら、プロファイルは正しく、シークレットの取得元が欠けています。この一度の比較で、動いている設定を書き直さずに済みます。

nmcli -f NAME,UUID,TYPE connection show
nmcli connection show "Office IPsec" | grep -i flags

フラグは推測せずに読み取ってください。「エージェントに聞く」を意味する値が探しているもので、正確なキー名は VPN プラグインごとに異なります。キーはプラグイン自身のデータ辞書に格納されているからです。FortiSSL プロファイルと IPsec プロファイルが同じ名前を使うとは限らないので、自分のプロファイルの出力から作業してください。

そのプロトコルのプラグインパッケージがインストールされていることも確認してください。プラグインが欠けていると、未知の接続タイプか、パスワードに何も触れないアクティベーションエラーとして現れ、その状態でシークレットを追うと同じ一時間を二度無駄にします。パッケージを一度問い合わせるほうが、午後まるごとキーファイルを編集するより安く済みます。

シークレットをキーファイルに移す

接続ファイルは /etc/NetworkManager/system-connections/ の下にあります。シークレットは既定ではそこに保存されず、それがいま読んだフラグの意味です。フラグをゼロにすると、値はアクティベーション時に要求されるのではなくプロファイルと一緒に保存されている、と NetworkManager に伝わります。

[vpn]
password-flags=0

[vpn-secrets]
password=YOUR-VPN-PASSWORD

シークレットが二つあるプロファイルでは、パターンが繰り返されます。[vpn] セクションにシークレットごとに一つのフラグ、値は [vpn-secrets] に置きます。IPsec プロファイルは通常、ユーザーの認証情報と並んで事前共有鍵を持ち、プラグインはそれを通常のパスワード欄とは別の名前で呼ぶので、キー名は他のプラグインを使ったブログ記事からではなく vpn.data の出力からコピーしてください。キー名を一つ間違えると、読み込まれてから認証で失敗するプロファイルができ、それはまさに間違ったパスワードのように見えます。再接続する前に、同じプラグインの動作するプロファイルと自分のファイルを比較してください。

スペース、引用符、ドル記号を含む値は引用符で囲んでください。$ を含む引用符なしの値は、解析される場所に応じて文字どおりに読まれるか展開され、その結果の認証失敗は間違ったパスワードのように見えます。

次にファイルの所有者とモードを直します。これらのキーファイルは特権サービスが読み取り、他のユーザーが読めるファイルは信頼できないものとして扱われます。これが、編集したプロファイルが無視されたように見えるよくある理由です。所有者は root、モードは 600、例外はありません。

再読み込みしてから有効化する

ファイルは接続が読み込まれるときに読まれるので、編集するだけでは足りません。プロファイルを再読み込みしてから、接続を明示的に立ち上げてください。

sudo nmcli connection reload
sudo nmcli connection up "Office IPsec"

再読み込みで変更が反映されない場合、サービスの完全な再起動なら反映されますが、まさにその報告もあります。他のリンクが重要なときは再読み込みを選んでください。サービスの再起動は管理下の接続をすべて切断し、リモートホストでは、目的のトンネルが上がる前にセッションが終わる可能性があります。

名前が曖昧なときは UUID を使ってください。顧客プロファイルが複数あるマシンにはほぼ重複がたまり、間違ったものを有効化すると認証情報の問題に見える失敗が起きます。

保存したシークレットが問題でない場合

FortiSSL プロファイルは、クライアントがゲートウェイの証明書を決して信頼しないため、正しい認証情報を保存していても失敗することがあります。その設定はメインダイアログにはなく、VPN の詳細オプションの奥にあり、そこで信頼する証明書のダイジェストを入力します。ログがパスワードではなく証明書に言及しているなら、この分岐であり、[vpn-secrets] をいくら編集しても役に立ちません。

ここにはもう二つの確認があります。プロファイルが、プラグインが読めないパスをまだ指しているファイルからインポートされていないことを確認し、プロファイルが有効なもので、古い重複ではないことを確認してください。どちらも認証エラーのように読めるアクティベーション失敗を起こします。

保存してよいかどうかを決める

保存された PSK とパスワードは、そのマシンで root として動くものなら何でも読めます。自分で管理するマシンなら、GUI なしのサービスのための妥当な取引です。共有ホストなら話し合いに値します。プロファイルには、以前はデスクトップのキーリングで守られていた認証情報が入っているからです。変更を適用した後ではなく、決める前に、そのホストで他に誰が root に到達できるかを尋ねてください。

ポリシーが VPN シークレットの保存を禁じているなら、cron ジョブを動かすためにプロファイルを弱めないでください。エージェントのあるセッションから接続を実行するか、自動化には別の仕組みを使ってください。

最後に、どのプロファイルがシークレットを持つかを記録し、誰かが気づかずにノート PC へコピーしないようにしてください。シークレットのセクションの上に日付と理由を書いたコメントで十分で、後で誰かの気まずいレビューを防げます。