openvpn3 session-start が認証情報ファイルを無視する理由

3.x クライアントはセッション開始時に認証情報を受け取り、保存済みファイルを読みません。プロンプトか autoload の経路を使い、それぞれが何を保存するかを把握してください。

2.x クライアントで接続すればプロファイルは機能しますが、同じファイルを 3.x クライアントに渡すとパスワードのプロンプトで止まります。--auth-user-pass creds.txt を openvpn3 session-start に渡しても、新しいクライアントにはそのファイルを読む段階がないため結果は同じです。この拒否は意図的で、認証情報はセッションに属し、セッションは端末のプロセスではなくサービスが作るものです。対話的なプロンプトと autoload ヘルパーのどちらを使うかを選び、それぞれが何を保存するかを理解してください。

保存済みファイルの行き場がない理由

新しい設計では、設定管理とセッション管理はシステムバスを介して通信する別々のサービスです。この分離により、特権デーモンが保護されたパスワードファイルを代理で読まなくても、一般ユーザーがセッションを開始できます。ファイルベースの認証情報は、それらを読むデーモン側の起動処理が存在しないため、そのモデルに居場所がありません。この拒否はアーキテクチャの帰結であり、機能の欠落ではありません。

捨てやすくするために古いやり方を名指ししておくと、プロファイルが認証情報ファイルを参照し、トンネル開始時にデーモンがそれを読むという仕組みです。新しいモデルでは、認証情報はセッションに属し、そのセッションの開始時に渡されます。openvpn3 session-start --config work.ovpn はそれらを尋ね、--auth-user-pass creds.txt は、その経路にはファイルを開くものが何もないため拒否されます。見つかる 2.x の手順はどれも、もう存在しない段階を前提にしています。

設定とサイトローカル設定も分離されており、これが二つ目の驚きを説明します。プロファイルは完全に見えても、それが生み出す接続にルーティングとリゾルバーの設定が欠けていることがあります。それらの部分はインポートされたファイルとは別に、サイトローカル設定として適用されます。

プロンプトの経路と、それが残すセッション

セッション開始時にパスワードを渡すのが想定されたワークフローです。クライアントは一度尋ね、認証情報をセッションのバックエンドに渡して続行します:

openvpn3 session-start --config work.ovpn
openvpn3 sessions-list

その経路ではディスクに何も書き込まれません。セッションは端末を閉じた後も動き続けるため、プロセスがシェルとともに終わると考える人は驚きます。セッション処理をサービスに移す意味はそこにあります。セッションはそれを要求した端末より長く生き、明示的に停止する必要があります。

人の前にいるワークステーションでは、守るべき保存済みの秘密も忘れるべき秘密もないため、これが最も安全な選択肢でもあります。人が入力しない場面でだけ不向きです。

キーボードの前に人がいない自動化

マシンが人の介在なしに接続する必要がある場合、プロジェクトは openvpn3-autoload を提供しています。これはプロファイルのディレクトリと、各プロファイルに対応する記述子を読み、記述子が認証情報を平文で供給します。ヘルパーは /usr/sbin/openvpn3-autoload にある別個のバイナリであり、session-start のフラグではありません。設定するには、ディレクトリを作成し、記述子が期待する名前でプロファイルをコピーし、記述子を書きます。

ユーザーごとの設定は次のようになり、セッションを所有するアカウントで実行します。ディレクトリのモードが他のローカルユーザーを締め出します:

mkdir -m700 -p ~/.openvpn3/autoload
cp work.ovpn ~/.openvpn3/autoload/client.conf
$EDITOR ~/.openvpn3/autoload/client.autoload

記述子は認証情報を指定し、自動起動を要求します。パスワードの値はバージョン管理の外に置いてください:

{
  "autostart": true,
  "user-auth": {
    "autologin": true,
    "username": "svc-vpn",
    "password": "change-this-value"
  }
}

次にヘルパーを一度呼び出し、セッションが現れることを確認します。二つ目のコマンドは確認であり、別の設定手順ではありません:

/usr/sbin/openvpn3-autoload --directory ~/.openvpn3/autoload
openvpn3 sessions-list

起動時には、openvpn3-autoload.service というパッケージ化されたユニットが、ユーザーごとのものではなくシステム全体のディレクトリ /etc/openvpn3/autoload を使います。その場所には root の所有権とより厳しいモードが必要で、記述子は依然としてパスワードを平文で保持します。トレードオフは明白で、パスワードがディスク上に置かれるので、そのディレクトリを秘密として扱い、ホスト外のバックアップから除外し、人がいる場合は常に対話的な経路を選んでください。

パスワード障害に見えるバスの障害

認証情報のせいにされる障害の中には、まったくそうでないものがあります。サービスのアクティベーション経路を名指しする権限エラーは、バックエンドが起動していないか、呼び出し元にそれを有効化する権限がないかのどちらかを意味します。プロファイルの編集ではどちらも変わりません。設定に触る前に、サービスの状態と同梱のバスポリシーを確認してください。

以下のコマンドはこの二つを切り分けます。一つ目はバックエンドが動作しているかを報告し、二つ目は最近のバスエラーを表示します:

systemctl status openvpn3-service-client
journalctl -b -u openvpn3-service-client --no-pager | tail -20

もう一つのよくある誤読は、現れてすぐ消えるセッションです。そのパターンは通常、サイトローカル設定が一度も適用されず、トンネルが有用にするルートとリゾルバーの変更なしに立ち上がったことを意味します。セッションが作成されたか、接続状態に達したか、生き残ったかという三つの別々の事実を、最後の行ではなく経過から読んでください。

古いクライアントがまだ使われている場合

2.x クライアントは今も認証情報ファイルを受け付け、キーリングが秘密をディスクに置かずにプロンプトに答えられます。ラッパーがエントリを解決するので、ファイルはパスワードではなく検索名を記します。この構成はロック解除済みのキーリングに依存し、ログインセッションのないコンテナや、誰かがサインインする前に起動するユニットでは提供できません。すると検索ツールは書き込めないコレクションを報告し、キーリングの障害が認証情報の障害に見えます。

そうしたものを構築する前に、プロファイルの keepalive 設定が再起動の必要性をそもそも取り除くかどうかを確認してください。起動したままのセッションは、自動化しようとしているプロンプトに決して到達しません。

関連記事