起動時に始まる VPN サービスがキーリングを読めない理由

ログイン後には動くのにその前は失敗する接続は、通常、起動時の試行がシークレットを取得できなかったという意味で、サーバーがシークレットを拒否したという意味ではない。資格情報は存在する。それを求めるコンテキストが存在しないのだ。この一点の区別が、不要なパスワードリセットを省く。

要求をたどろう。デスクトップセッションができる前に何かが接続を開始し、通常は応答するシークレットストアはまだ解除されていない。二つのコンテキストはシークレットの所有者について一致せず、プロファイルはどちらが提供する想定かを記録している。

起動経路が実際に求めているもの

起動時、NetworkManager はユーザーセッションもセッション D-Bus も解除済みのキーリングもない状態でシステムサービスとして起動する。接続プロファイルはそれでも立ち上げられるが、サービス自身が到達できるシークレットを使う場合に限られる。シークレットエージェントが所有するものは、人がログインしてエージェントが現れるまで待つ。サービスは設定どおりに動いている。変えるべきはプロファイルだ。

失敗はキーリングに隠れているのではなく、接続そのものに書き込まれている。

接続のシークレットフラグを読む

接続に何を期待しているかを尋ねよう。デスクトップが何を覚えているかではない。フラグ列がその問いに直接答え、ディスク上のプロファイルファイルに再起動を越えて残る。

プロファイル一覧から始め、どの接続が自動で立ち上がる設定かを確認する。次に一つの接続を出力し、パスワードフラグを読む。

nmcli -f NAME,UUID,TYPE,AUTOCONNECT connection show
nmcli connection show "Work VPN" | grep -i -E "password|secret|key"
journalctl -b -u NetworkManager --grep "secret"

最初のコマンドはどのプロファイルがあり、どれが自動接続に設定されているかを確認する。無人での試行が始まるのはまさにこの経路だ。二番目はフラグの値を明らかにし、三番目は特定のシークレットにどのエージェントも応答しなかったとサービスが訴えている様子を示す。シークレットをエージェント所有と名指すログ行が、一文での診断そのものだ。

接続をシステムスコープへ移すと答えが変わる理由

ユーザー所有の接続はそのユーザーのエージェントの下で有効化されるため、デスクトップが上がれば完璧に動く。システムスコープへ移すとエージェントが経路から外れるので、VPN 設定を一行も変えずに同じプロファイルの挙動が変わる。

この移動は正当な設計であり、一つの要件を伴う。シークレットがシステムサービスから到達できなければならない。プロファイルに保存する、システムスコープの資格情報で提供する、適切な瞬間にインタラクティブなプロンプトを受け入れる、いずれも有効な答えだ。フラグ 1 を残して期待するのは違う。

独自のパスフレーズを持つ秘密鍵は第二の層を加える。保存されたアカウントパスワードでも、パスフレーズを要求する鍵は解除できない。だから何かを変える前に、失敗している段階が実際にどのシークレットを求めているかを確かめよう。

やってはいけないこと、代わりにやるべきこと

すべての資格情報ファイルを誰でも読めるようにする、あるいはプロンプトが不要になるよう認証を無効にするのは、起動時の不便を恒久的な露出と引き換えにしている。どちらも依存関係を解決せず隠すだけで、次のイメージ更新で同じ失敗が戻ってくる。

その段階ではディストリビューションが無人起動のために文書化している仕組みを使い、プロファイルのフラグがそれと一致することを確認する。結果はエージェントがすでにあるシェルではなく、きれいな起動から確認する。接続の所有者、シークレットの出所、機能すべき段階を書き留めておけば、後からの自動起動の変更が、誰かが先にデスクトップを解除するという依存を静かに復活させることはできない。文書化が、直ったサービスと次の四半期にまた壊れるサービスの差になる。

ログイン後の手動の再試行ではなく、制御されたきれいな起動から試す。再試行が成功するのは起動時の試行が失敗した理由のせいであり、それは素早いテストが壊してしまう証拠そのものだ。